Article based on the talk by Rodolfo Arocena, presented at Open Tech 2026, organized by Pyxis on September 5, 2026.

An AI agent doesn’t ask about what it doesn’t know: it fills in the gap and keeps going. Rodolfo Arocena shared his team’s first experience building their own framework based on specs, a technical harness, and checkpoints versioned in Git. His conclusion: yes, you can trust an agent with your code, but with guidance and controls.

Summary

With AI, implementation has become fast and cheap, but errors speed up too: ambiguous requirements, unvalidated assumptions, and technical debt spread at the speed of code. Rodolfo Arocena argues that the bottleneck is shifting from implementation to definition, and he explains two concepts for tackling it: Spec-Driven Development (SDD), where the specification is the source of truth, and the harness, everything that surrounds the model to guide and control it.

Drawing on an experience at a client, he describes how they built their own framework, what results they got, and where human controls are still needed.

Everything Was Green

Rodolfo opened the talk with a classic case. A request comes in, it gets developed, everything works, the automated tests pass, and the pull request is reviewed without objections. Everything is green. The only problem is that what was built doesn’t do what it was supposed to do: it’s not what was asked for or what was expected.

It’s not a new problem, and teams have learned to compensate for it. Often the developer, thanks to their knowledge of the project, senses that something doesn’t add up. And that’s what daily standups and planning and refinement meetings are for: spaces where doubts get talked through before they turn into code.

What happens to that mechanism when the one developing is an AI agent? An agent doesn’t ask much: it looks for a solution, it’s very eager to help, and sometimes it does more than it was asked. But there’s a lot it doesn’t know.

A New Developer, Every Day

By default, an agent doesn’t know the context: what code exists, what architecture is in use, what the requirement is, what the full application looks like. It also doesn’t share the team’s priorities. Rodolfo reminded us that there’s math and probability behind it: the agent looks for the solution that, by its own calculations, fits best, fills in the gap, and moves on. It won’t detect ambiguity.

To explain it, he compared it to the arrival of a new developer. For that person, you put together an onboarding: documents, three or four meetings, the architecture, the conventions. With an agent, you have to do that same work.

The difference is one of scale. With AI-assisted development, or fully agentic development, code is generated much faster, and with it errors, technical debt, and ambiguous requirements spread faster. AI helps build faster, but it also amplifies and accelerates problems.

The Bottleneck Moved

Until now, implementation was the longest stage of a project. If analysis or design had gaps, they were made up for there, with iterations, short sprints, and meetings.

Today implementation is very cheap and very fast, and the bottleneck becomes having a good definition: changes end up landing on analysis and design. The challenge, according to Rodolfo, is to give agents a framework to work in so they do what we actually want.

Spec-Driven Development: The Specification as the Source of Truth

That’s where the first central concept of the talk comes in. Spec-Driven Development is a methodology based on specifying what you want first, in a structured way, so that an agent can understand it. The specification is the primary artifact: the source of truth.

The idea isn’t new: we’ve been writing user stories, architecture documents, and ADRs for a long time, and TDD and BDD were already based on specifications. But before, if a spec failed, a conversation with the developers solved it. With an agent it’s harder, which is why the approach gained importance and also took on technical aspects.

There’s no standard: each framework has its own way of working and its own document structure. What they have in common is that the specification has to be interpretable and executable by an agent, and that there are both human and automated checkpoints. Rodolfo estimates that the human ones will decrease over time, but today they’re still needed to validate that what was built is the right thing.

All of this is managed in a Git repository. The idea is for business specifications to live alongside the code, evolve together with it, and provide traceability between what was requested and what was developed.

The Harness: Everything Around the Model

The second concept is the harness. Rodolfo cited a mental model that’s going around: an agent is an LLM plus a harness, which is everything that surrounds the model: skills, tools, specifications. In his words, it’s the software infrastructure for developing with agents.

It comes in layers. Providers ship their agents with their own harness; for example, Anthropic with Claude Code and its skills, libraries, and orchestration procedures. On top of that comes the user’s harness, which each team builds: platform, architecture, stack, commit and code conventions. And only then, at the top, the specifications for the change being assigned to the agent.

But the harness doesn’t just politely ask the agent to behave a certain way: it also checks that it does. Technical specs, like business ones, should have acceptance criteria. If one says not to call the database directly from a controller but through a repository layer, you have to spell out how it counts as fulfilled. That way the agent iterates until it gets there.

Sometimes it doesn’t, which is why there’s a later control layer. Some controls are computational, such as a linter or a rule that detects direct database access. Others are inferential and require another model, ideally a different one from the agent that did the development. That’s also where business acceptance criteria get verified, beyond the tests. Not for everything: for what the team considers most important.

Validating Is Not the Same as Verifying

One distinction runs through the entire proposal. Validating means deciding whether what was built is the right thing; verifying means checking that what was defined was done. For Rodolfo, humans shouldn’t spend their time verifying: everything that can be automated, such as code structure or coverage, should go to automated controls.

But a verification always has to be against something. That’s why well-organized, well-structured specs matter: without that reference point, the agent’s assumptions can slip through code review without anyone noticing.

Why They Built Their Own Framework

There are several SDD frameworks. Rodolfo said he had only tried OpenSpec, with very simple tests. Each one defines its own folder structure, specifications, and harness, and all of them have a learning cost.

In the project he presented, they didn’t use any. Not because he thought they were bad, but because adopting one meant tying themselves to a way of working and learning it, and there was urgency. The initiative started this year at a client where development is mostly outsourced.

The motivation had two sides. On one hand, the need to incorporate AI into processes. On the other, people from non-IT areas began developing applications and asking for them to be published as official. The company encourages that experimentation, but it needed to be governed.

So they started with what they were sure to need: the harness. And instead of adopting a framework, they built their own, drawing on practices and ideas from the existing ones. Without inventing too much, as Rodolfo himself made clear.

The Process: The Usual Stages, Assisted by AI

The flow respects the classic stages: analysis, design, implementation, and validation. The difference is that all of them are AI-assisted and each one works as a loop, with its own input and output.

In analysis, starting from a need, they work with AI until they get the requirements specification; they’re developing a custom agent for that. In addition, they prototype a high-fidelity wireframe with vibe coding to visualize usability and look and feel.

The business specs, the prototype, and the harness are the input of the design loop, which produces an implementation plan. Rodolfo stressed that this plan is also design, not just a task list. Then a developer reviews it. As he described it, the developer no longer develops: they read, approve, question, and interact.

With the design approved, the plan and the harness enter the implementation loop, which outputs the code and the pull request. For now they work at the epic level, trying to keep epics from getting too big.

Skills, Open Questions, and Dependencies

The framework is a repository that contains the harness, with commands and skills; three of those skills support the stages. The first one initializes each initiative’s repository and loads the harness into it according to the type of application. Today a DevOps person runs it, and the skill assists them by asking, for example, which architecture archetype will be used.

The technical specs are organized by application type, on TypeScript: front end, back end, monolith, security constraints, and code conventions. The responses are still non-deterministic, but the harness keeps them within a certain margin.

The design skill asks questions, tries to detect dependencies, and pushes back. The idea is for it to make its doubts visible, flag open questions, and suggest which ones are blocking, so the developer decides. It’s a conversational stage, but it’s where they validate that things are on the right track or whether more rules need to be added to the harness.

Rodolfo highlighted two especially valuable aspects. One is that classification of what remains open: the agent asks for confirmation to continue and records in the repository what gets postponed. The other is dependency control: it reviews the designs and specs of other epics, tries to detect whether its proposal could affect them, and updates a dependency table. That control, he said, gave good results.

Human review of the design is one of the most important parts of the flow. In implementation, on the other hand, the goal isn’t to review all the code, but to run a test or look at a few key points.

What the First Experience Left Behind

Rodolfo was clear that this is a framework under construction. The validation layer isn’t automated yet: today the agent self-validates, and adherence to the specs doesn’t reach 100%. Even so, they already have four relatively simple applications in production. One had an adherence of around 70%, but all of them are working. None has gone through major changes yet, so evolution is a pending topic: managing business specs as a versioned object, with history, is something new. More feedback and more controls are also still needed.

Two of those applications were developed by department heads: engineers, but far removed from implementation. And another practice that gave them good results was adversarial review, with a reviewer agent different from the one that did the development.

The path had its cost: they had to generate quite a bit of documentation, ADRs, and architecture design documents that later fed the specs. They also reviewed the architectures, because developing fast isn’t enough if the rest of the stages are still heavy. For very simple applications they opted for a monolithic format, with less infrastructure and fewer steps.

Yes, But With Guidance and Controls

So, would you trust an agent with your code? Rodolfo’s answer was yes, with one condition: give it all the scaffolding. Nobody hands a person joining a team the repository and asks them to just start programming. The same goes for an agent, with one advantage: if the documentation is well built, organizing the agent is a lot easier.

His recommendations were concrete. You don’t need a framework to get started: the harness is something any organization or project can build up gradually, and it already adds value. The stops to make decisions are still important, especially in design; you can start with more manual steps. And the repository is one of the approach’s great advantages.

The talk leaves an idea that goes beyond tools: when writing code stops being the hard part, the value shifts toward defining well what you want to build and being able to confirm that’s what got built. What Rodolfo shared isn’t a closed recipe but a first run through, with concrete results and acknowledged open items.

At Pyxis, we believe experiences like this, told with their successes and their limits, enrich the conversation about how to bring AI into software development responsibly. That’s why we share them in spaces like Open Tech.