Speed without structure means chaos. How we brought the logic of the Double Diamond into AI-assisted development to define unambiguous problems and validate implementation systematically.
Over the past few months, the rapid evolution of coding agents has completely upended the way we work at Buildo. It was clear we couldn't simply let ourselves be swept along by this change without a precise plan. We had to figure out how to respond to this revolution in a structured way, in order to drive the change instead of being overwhelmed by it.
Our journey was probably similar to that of many other teams. We started with the first code suggestions in our editors, then began using AI to generate small pieces of logic, all the way to implementing entire interactive prototypes and pilot projects developed entirely by AI.
The pace of our work was changing rapidly and the benefits of this approach were evident from the start, but we also realized there was a concrete risk that speed, without a clear structure, could lead to loss of control and chaos.
What worked well for MVPs and prototypes couldn't be applied directly to more structured projects, with precise requirements, mockups to follow, and a formal validation process. Left free, AI often produced a product that worked well enough, but that came with inaccuracies, divergences from the guidelines, and incomplete or imprecise features.
It was clear that we had to rethink the entire system with an AI lens: how we organize work, how we specify tasks and the context needed to implement them completely and unambiguously, how we manage dependencies between tasks and their prioritization, all the way to how we validate what has been built and ensure quality systematically.
In this post we focus on a single building block, going from the specification of a task to its post-implementation validation. It's a deliberate starting point, one that will slot into a broader vision in which AI assists the entire management of the project.
It was clear from the outset how effective artificial intelligence is at exploring, at spotting inconsistencies in reasoning, or at suggesting solutions to follow. That same tendency to always find an answer, however (the very thing that makes it useful in exploration) leads it to fill requirement gaps with the answer that seems most plausible, even when it isn't the one intended.
When we give agents more freedom to act, the risk increases that they go off the rails and build something different from what we had in mind. In projects with less rigorous requirements, such as UI prototypes or MVPs to be validated, this tendency can be an advantage, because we can arrive more quickly at a result complete enough to be tested with the client, also taking advantage of the brainstorming and ideation that AI brings.
In projects that demand more rigor, however, we want agents to follow well-defined paths, limiting as much as possible any deviation from what we set out to achieve. An unplanned screen, an unconsidered state, or instructions that are too vague lead the agent to fill the gaps its own way, with a consequent loss of trust in the result, which can push the developer into excessive oversight of the agents, and therefore cancel out all the efficiency gains that were promised.
We therefore need to find a process that, on one hand, surfaces gaps before they turn into problems and, on the other, gives artificial intelligence (and us) a way to efficiently verify the result produced.
The issue was clear, and in fact independent of the use of AI. We had to strengthen our ability to define the problem, so as to make it less ambiguous, and use AI itself to find any inconsistency or omission that could translate into unwanted results.
Since we at Buildo are used to working closely with designers, we knew their process already tackles a very similar problem. Their mental framework, known as the Double Diamond, splits research and design work into two distinct phases: defining the problem and ideating the solution, each made up of an initial moment of exploration (divergence) followed by one of decision (convergence).
Bringing this principle into development meant creating a process that first focused on understanding and formalizing the problem so as to make it comprehensible to the agent, defining all the parameters that can guide it in the subsequent implementation phase, and only then working together with it on the solution. During the divergent phases, artificial intelligence can be leveraged to explore, identify inconsistencies and specification gaps, and propose a first draft formalization of the requirements or of the solution, while the convergent phase is led by the human, who reviews, refines, and ratifies the final result on the basis of the artifacts generated by the AI.
Let's look in more detail at how we structured the 4 phases on the basis of these principles, arriving at a process supporting the development of a pilot project in the MedTech space. We started from an already completed design phase, which had produced user stories, high-level requirements, and mockups of the main screens.
In this first phase, we give the agent the context of the new development we're about to work on, providing it with all the material gathered about the problem: project notes, requirements, mockups, existing code. We instruct it not to think about the solution, but to identify anything that may be poorly defined or misleading.
The purpose in this phase is not to discuss the solution, but to surface doubts, omissions, and inconsistencies before they become problems during implementation.
In our case, for example, a skill instructs the agent to generate a set of questions addressed to the different roles on the team: product questions for the PO, observations on user interaction to put to the UX designers, and technical and feasibility analyses directed at a software architect.
It's then up to the developer to gather the necessary information from the people involved and provide the answers, so that in the next phase the agent can formalize the specifications that will guide development.
The answers provided in the previous phase, together with all the starting material, now need to take a precise form, structured to be consumed by an AI agent during implementation. This is where we start shifting attention from the problem (the "what") to the solution (the "how").
In our process, a high-level user requirement formalized by the designers — such as "settings must be accessible only to administrator users" — turns into a series of precise scenarios:
Given that the user has an admin role, when they open the menu, the settings link is visible.
Given that the user does not have an admin role, when they open the menu, the settings link does not appear.
Given that the user has an admin role, when they navigate directly to the settings URL, they see the configuration form.
Given that the user does not have an admin role, when they navigate to the settings URL, they are redirected to the homepage.
The format follows the Gherkin structure of Behavior-Driven Development (BDD), a widespread standard in software development for writing requirements in semi-formal language.
Compared with the original user requirements, which focus on the user's goal at a high level, the scenarios written in this phase surface a series of precise technical decisions that generally don't get formalized during design, either because they're obvious to a human reader or because they're too detailed for that phase (e.g. "what happens if an unauthorized user navigates directly to the URL?").
The aim, then, is to close as many gaps as possible in the definition of what will have to be implemented, minimizing the degrees of freedom the agent will have in the subsequent solution-ideation phase, and consequently the risk that it may invent.
Once again, AI is leveraged for its ability to anticipate scenarios we might not think of, while the human steps in to review those scenarios and can therefore lead the convergence phase. By using a readable specification format, we can also involve people other than developers in reviewing these technical scenarios.
Scenarios formalized this way don't just serve as the guide for implementation, but also as the contract to validate during testing, giving agents a precise set of requirements to check in order to assess their own work.
Once we've established what the agent has to build, we can finally focus on the technical solution. Only at this point do we turn to the planning mode of our coding agents, called Plan Mode.
This mode, now present in most AI development tools, requires agents not to modify code directly, but to first produce a document with an implementation plan, which the developer must approve or amend before it is executed.
Plan Mode is by its nature oriented toward finding solutions, so it tends to produce technical plans that are internally coherent, even when they rest on incomplete assumptions. By using it only after having rigorously defined the scenarios, we invite the agent to move freely through the space of possible solutions, without, however, stepping outside the constraints that define the problem.
Once again, the human role will be to validate the technical plan, correct what doesn't add up, and ratify the sensible choices, thereby guiding convergence toward the code.
Once the direction is confirmed, the agent starts writing code following the approved plan. The first step will be to use the scenarios ratified in the previous phases to generate automated tests that will act as the litmus test for knowing when to be satisfied with what's been built: until the acceptance tests pass, the agent cannot consider its work complete.
In the instructions we provide, we also ask that the tests produced generate artifacts to serve as evidence of the task's correct implementation. Since the pilot project on which we tested this flow has a significant UI component, we decided to focus these artifacts on producing screenshots of the user interface, both of the precondition state and of the final state. These artifacts serve a threefold purpose:
In our case we experimented with playwright-bdd to turn scenarios into E2E tests with Playwright.
Once all the acceptance tests pass, the agent enters the code "ship" phase. Before sending the code for review, a series of automated checks is run to improve code quality: removing dead code, eliminating duplicates, and a review against predefined guidelines using the agent's official skills and specific instructions. Only once these checks are passed, and the code improved accordingly, is it published for review.
Once that's done, while waiting for the human review by another developer, we can use the agent to help us with validation. In parallel, then, the agent:
Following the process described above, we're increasingly realizing how our work as developers is shifting toward defining the problem and verifying the result, rather than the code that sits in between.
In practice, the process takes the form of a series of markdown files describing the phases the agent has to follow, and a set of atomic, reusable skills, orchestrated by those files, that handle the generic capabilities which can be shared across multiple projects: the requirements challenge phase, the pre-flight checks before opening the pull request, and so on.
We designed the process so that each individual project can define its own specific workflow based on its context and needs, combining shared building blocks refined over time.
From the very first retrospectives, in fact, it emerged that the process needs to adapt not only from one project to another, but also between tasks of a different nature within the same project.
In more exploratory projects or tasks, for example, we realized that the initial requirements challenge phase can prove very costly if the goal of the project (or of the specific increment) is to reach a rapid prototype implementation to test with the client, refining the requirements only later on the basis of their feedback. In this case, we prefer to iterate faster on the solution (at the cost of leaving the agent more freedom), and then use the scenario-generation skill after the fact, to ratify the choices once they're approved and to guard against regressions in future development.
A different case is that of well-established projects, where the effort shifts from adding new features to fixing bugs in existing ones. At this stage of a project, challenging the requirement will matter less. What will be essential instead is gathering all the clues needed to identify the domain, the feature's original requirements, the observed problem and its cause, and guiding the agent in writing the tests needed to verify the fix. Here too, we reuse existing skills, such as those for verifying and producing acceptance artifacts, to guide the bug resolution.
Given that the nature of the work at hand can vary so much even within the same project, where more exploratory tasks, defect-fixing tasks, and more polished feature implementation tasks can alternate, we're exploring the introduction of a triage phase by the agent itself within the process. Before starting on the assigned task, the agent tries to work out from the context provided (or by asking the developer directly) the nature of the task, and therefore the most sensible process to follow.
This modular architecture is, in fact, a first step toward something broader, which is starting to go by the name of Software Factory. In this vision, automation won't concern just the individual task, but the entire project lifecycle: from managing dependencies between tasks, to maintaining a shared knowledge base, to monitoring the quality of the overall product over time. The process we've described here forms the core of that vision, one which in future may leave agents ever more autonomy in managing the whole project as well.
It's becoming ever clearer how the process can be considered a genuine asset, one that must be tended and made to evolve in order to keep up with the evolution of AI and of the surrounding environment.
A mantra we like to profess at Buildo is that of Continuous Improvement: every process, in order to keep working, must be subject to continuous improvements.
And here too AI itself can help us a great deal. At the end of every task execution session, we have available the entire interaction with the agent, the mistakes made, the corrections that had to be issued, the feedback left following code review, the guidelines not followed, and the deviations from the process. All this material can be used to ask the agent itself to reflect on its own work, and to propose changes to the instructions that could improve future iterations.
This way, we've been able to specify new code guidelines the agent wasn't applying, improve instructions to make it follow steps it tended to ignore, improve the way it verified the work performed (for example by adding tools such as playwright-mcp for real-time verification in the browser), or introduce — at the agent's own suggestion — hooks that injected context to remind the agent of what to do when particular conditions arose (such as the update of a specific file).
In doing so, as the project progressed we observed a continuous improvement in how the process itself worked, further improving efficiency.
The process we've described here is proving robust across projects that are very different from one another.
This isn't a finish line, though. What we're still trying to calibrate is the right granularity for each type of task, so that the process doesn't become a burden but keeps being a real advantage.
One thing we've learned not to underestimate is the role of verification. A solid testing strategy isn't just about making tests pass: it helps the agent validate its work and correct itself automatically, as well as giving developers and the client the artifacts to trust the result without having to read every line of code. Having the right mix of tests, spread across the various types, and making sure they actually verify all the state changes to be observed, becomes essential in guiding the agent toward the correct implementation and further reducing the possibility of drift.
The biggest change we're observing, though, is subtler: code is becoming less and less relevant. We spend more time defining the problem, asking the right questions, judging whether the proposed solution is the correct one. We're refining the ways we define requirements, at different levels of detail, and in such a way that they are exhaustive and unambiguous.
Human judgment hasn't disappeared — it has shifted and grown stronger.
Our ambition is to build a process that leaves AI ever more autonomy in managing the project, allowing the human side to focus on what really matters: understanding user needs, ideating creative solutions, and validating the result against the client's expectations.
If you're interested in working with us on this transformation (as a client, as a partner, or as a colleague), get in touch. We'd be glad to help!
Vincenzo joined Buildo in 2016 as a Fullstack Engineer, with a strong focus on Frontend technologies. He pays close attention to process improvement and team dynamics, working every day to foster effective collaboration and bring out the best in each team member.
Are you searching for a reliable partner to develop your tailor-made software solution? We'd love to chat with you and learn more about your project.
Buildo S.r.l. è certificata ISO 9001:2015 (Sistema di Gestione Qualità) da PJR per la Progettazione e Sviluppo di Software.
