This is a copy of a blogpost written on June 05, 2026, by me on Medium and published by Comsysto Reply GmbH.
AI is making implementation faster. The specific numbers are up for debate — estimates range from 10% to 20x depending on who you ask and what they’re measuring. It doesn’t really matter. The direction is clear, and it’s real. What’s less talked about is what happens when implementation gets faster.
The effort doesn't disappear — it shifts
Let's simplify feature development to these phases: Refine, Plan, Implement, Review, and Integration.
Side note: feature development is really an infinite loop, and value and trust operate on both sides of implementation. Before you write a line of code, ADRs and design work belong to "building the thing right." After you ship, user feedback and observability data feed back into "building the right thing."
The linear framing is a simplification — and useful for this blog post.
Implementation is the one that is currently in the spotlight for getting faster or fully agentic. In our current experience, the other four phases can be AI-assisted, but the effort doesn't significantly change. In fact, it might even grow — or at least become more visible, because the thing that used to hide some of the effort is shifting.
This is not a criticism — it's just how bottlenecks work. We currently see two of them emerging.
The value bottleneck: building the RIGHT thing
This first bottleneck is the two phases upstream of implementation: refine and plan. It's the hard, slow, human-intensive work of figuring out what actually matters — talking to people, understanding their domain, deciding what to build next, and keeping that understanding shared and current across a team.
This was hard for many teams and organizations before agents arrived. Agents can assist here, but they haven't made it easier. If anything, they've raised the bar: to hand off implementation to an agent, you have to be more explicit than you used to be. The implicit context that lived in someone's head and got filled in during a sprint of coding now has to be externalised upfront. That takes more preparation, more alignment, more shared understanding.
Patrick Debois is saying that this is where competitive advantage arises — his context flywheel frames shared context as something that needs to be engineered, maintained, validated, and owned deliberately across an organization.
We can think of context engineering as one part of an onion.
At the centre: prompt engineering, the craft of deciding what to put in a prompt, how to phrase it, and whether to include examples. Around that: context engineering, the broader practice of shaping the full context window, not just the prompt, and improving it continuously over time. And on the outside: harness engineering, the automated scaffolding of constraints, tests, and guardrails that wraps your agent so you can trust what it produces. Each ring depends on the one inside it.
The trust bottleneck: building the thing RIGHT
This is everything downstream of implementation in the phases Review and Integration. It's about getting the confidence or confirmation that what was built is actually correct. The volume of code coming out of an AI-assisted workflow is higher. That doesn't automatically mean the quality is.
The instinct is to say, "but an agent can help with review and testing, too." It can. But getting that right requires significant skill and judgment — building out the harness for your agents and your domain is work in itself, and it needs ongoing attention and iterative improvement.
Similar to onboarding a new team member, we provide guides, such as coding guidelines or a typical test structure, to explain what we want, and then we apply different sensors, anything from linting to the 4-eye principle in code reviews, to check the work and give feedback.
Birgitta Böckeler’s piece on harness engineering is the best thing written on this so far. The short version: a coding agent is only as trustworthy as the guardrails around it.
The solo developer fantasy vs. software teams
There's a narrative circulating that this AI explosion and agentic hype is all leading up to the solo developer — one person, a fleet of agents, shipping features at speed. No team, no overhead, no communication, no coordination, just output.
We have our doubts about this future. And not just because of the two bottlenecks described above.
The deeper reason is that a lot of the good things that happen in software development happen between people. The conversation in refinement where someone spots that the feature solves the wrong problem. The code review comment surfaces a design assumption nobody had made explicit. The retrospective is where the team figures out why the last sprint felt wrong. These aren't process overhead. They're where judgment gets built and shared, and the things that are built get better.
Some practical considerations on team size, given that throughput is increasing and mental load will too: Teams might shrink — and that's fine, as long as you're honest about the tradeoffs.
Be careful about the bus factor. Below three, you’re fragile. Humans get sick and go on vacation, and you might want to continue to fix bugs and ship features.
A smaller team loses the challenger mindset quickly. Bottom-up ideas and internal disagreement are features of healthy teams and products, not noise.
Shared context and a trustworthy harness are both built over time and through collaboration. You can't shortcut that with headcount reduction.
The agile questions that are coming up
Recently (May 2026), in our lean coffee, someone asked:
are there any reasons left for sprint length >= one week?
It sparked controversy. Several people were enthusiastic about Kanban and development flow. Someone made the point — and a lovely quote — that "it's really important for humans to have a box." Meaning: sprint goals and time-boxing still have value for humans as focus containers, especially when the backlog is effectively infinite.
Scrum and two-week sprints were designed for a world where implementation was the primary constraint. That world is changing. Whether the cadence needs to change with it is a genuinely open question. The group didn't resolve it. Neither will this post.
What seems likely: the value of regular rhythm isn't going away. The specific parameters are worth questioning.
So what happens when implementation gets faster, you might ask? We don’t have a clear answer either. But we highly recommend zooming out and looking at the entire feature development and value creation processes. There will be new bottlenecks, and they will need your attention!