Once one person can move faster, the constraints around them become more visible: access to systems, timing between people, review capacity, governance, release processes.
We’re seeing that pattern with clients. The first gains often come from individuals using AI well. The next question is harder: what has to change around the work for the team to benefit?
That was the focus of our conversation with Steve Bartlett, CTO at Programa.
We know Steve well. He spent many years at DiUS, and over the past year he has been pushing hard on how AI fits into product development at Programa. What made his story useful was the structure forming around the AI tools used by the team: specs, product context, design artefacts, tests, agents and human review.
The change has moved beyond engineering. It now reaches into product, design and the way non-technical team members contribute.
From tools to operating model
Twelve months ago, Programa looked like many teams do now. Engineers were using Copilot, Cursor and other tools in different ways, with no standard workflow around them.
Since then, Steve and the team have been building a more deliberate delivery system around the tools: clearer specs, shared context, tests, user journeys, design artefacts and harnesses that can direct and check what agents produce.
Steve framed that progression using Dan Shapiro’s five levels of AI-assisted software development. In that model, Programa is operating around level three and pushing toward level four.
At level three, agents produce more code and humans spend more time reviewing it. That creates more throughput, but also more code than people can comfortably inspect.
Level four changes the work again. Humans write and refine the spec, shape the skills and review the plan. Then the system runs for longer stretches without them, with tests and harnesses doing more of the checking before a person reviews the outcome.
Programa is now designing the workflow around agents, rather than leaving each engineer to work out their own way of using the tools.
The adoption work was deliberate. This was not left to individual enthusiasm. It had to come from the top because it affected the whole company, not just engineering. At Programa, the move was tied to business goals: faster growth, higher revenue per employee and the ability to do more with the team they had.
The team also created practical ways for people to contribute. Weekly check-ins, show-and-tells and an RFC (request for comments) process give engineers a way to propose improvements to the AI tooling and rotate into the team working on it.
Early in the year, when the team moved to working in a more spec-driven way, Programa saw a meaningful step-change in delivery speed. Steve was careful about how to interpret that improvement. Cycle time is hard to measure cleanly when the work itself changes. The better test is whether speed creates regressions, review load or new bottlenecks elsewhere.
What changed in the workflow
At Programa, a feature now begins as a spec that gets challenged before an agent writes code.
The agent critiques the spec, asks about edge cases, checks assumptions and helps turn a rough idea into something the system can act on. Product clarifies intent. Designers make interactions and states explicit. Engineers check whether the proposed plan makes sense before implementation begins. The faster implementation gets, the more important it becomes to define the problem clearly before the code is generated.
This also gives non-technical team members a more useful entry point. They can work through the spec with the agent, answer questions about scope or user intent, and see where an idea needs more detail before it becomes engineering work. They are not being asked to make architectural decisions or understand every part of the codebase. The contribution is in shaping the problem clearly enough for the system to act on.
Once the spec is clear enough, the agent turns it into a technical plan. Engineers review that plan, checking whether it touches the right parts of the system and whether it creates risk. The plan then becomes the instruction set for the agent.
Discovery still happens. Teams still see things in the output that are not right: an interaction, a state, a user experience detail. Those learnings feed back into the spec, and the system runs again.
A substantial feature showed what this looked like in practice: work that previously required a larger cross-functional team moving through product, design and engineering handovers is now being delivered by much smaller groups.The hard part did not disappear, the work still needed a clear spec, design input, testing, review and iteration.What changed was where the implementation load sits , with more of it carried by automated checks and repeatable workflows.
Context becomes infrastructure
For an agent to work inside an existing product, access to the codebase is not enough. It needs product context: how domains fit together, which patterns the team uses, what to avoid, and where one change might affect another.
At Programa, that source of truth is documentation. Not one large file, but domain-specific documents the agent can draw on as needed. When review uncovers a pattern they do not want repeated, they add it back into the context so the system avoids it next time. Design needs the same treatment. A design system gives the agent components and constraints, but it does not carry the whole experience. The agent still needs to understand states, transitions, interaction details and where a standard component is not enough.
That changes what designers need to contribute. At Programa, Figma annotations help the agent read more than static screens. Notes about state changes, transitions or interaction behaviour give the system context it would otherwise miss. Designers are also shaping specs, making user journeys clearer and reviewing output more often as implementation comes back faster.
Design is being pulled into the same automation curve, but not in exactly the same way as engineering. Tools can help shape ideas, generate prototypes and turn design intent into implementation, especially when the design system and Figma files carry enough context.Designers still carry the judgement about whether the experience works.
A design system is no longer only a designer-developer agreement. It becomes context the agent needs to use.
How review changes
Programa reached a point where the team could generate more code than people could comfortably inspect. The concern is no longer only whether the code looks right. It is whether the change behaves as intended, avoids regressions, respects security constraints and does not do something the team did not ask for.
That is where harness engineering becomes important. Confidence has to come from repeatable checks around the work, not from reading every line. ITests, monitoring, guardrails and security review provide validation that the output matches the intent. When something is wrong, the feedback goes back into the spec and the change runs again. Review cannot stay the same when the volume of generated code changes.
Where the pressure moves
As engineering throughput increases, teams often find the constraint moves. Product needs to be clearer earlier. Design needs to make interactions and states more explicit. Marketing has to absorb and communicate more change. Users can only take on so many new features at once.
At this maturity level, optimising one part of the system rarely makes the whole organisation faster. It makes the next dependency easier to see and manage, whether that is enablement, release coordination, support readiness, or how change is communicated.
There is a role-shape change teams need to plan for as agent-assisted delivery matures.As more implementation moves into automated workflows, effort shifts towards specification, validation, and risk-based review.,Team tend to get more consistent outcomes when they make those expectations explicit, set quality threshold, and rotate the review load.
Faster engineering is useful only if the rest of the organisation can absorb the pace.
What carries across
Programa’s context is specific: its own product, codebase, design system, commercial pressure and appetite for change. But the pattern carries across.
Individual adoption is not enough. The larger gains come when the work around the tools becomes explicit: clearer specs, better product context, design artefacts the system can read, tests that define expected behaviour, review practices that catch risk earlier, and guardrails that help people contribute safely.
The last issue showed what happens when one engineer starts to orchestrate work differently. Steve’s story shows what happens when that way of working starts to shape the delivery system itself.
The real work is now around the work: making intent clear, giving agents usable context, checking outputs properly and making sure the organisation can absorb the pace.
