Agility in the age of AI: when production speed is no longer the problem

Integrating AI into software engineering workflows is profoundly transforming how software is produced. Code-generation capacity has been multiplied. Technical exploration has accelerated. The cost of prototyping has become marginal.

But one thing hasn’t kept pace: organizations’ ability to understand, govern and validate what is produced. Human understanding of code has not been multiplied. Business alignment has not accelerated. And the methodological frameworks we use were designed for a world where production was the limiting factor.

This observation comes back, engagement after engagement, in the projects we run at Beorn. It led us to rethink the way we work. Here is what we take from it.

The bottleneck has moved

For twenty years, the dominant constraint of a software project was production capacity: code was slow to write, iterations costly, validation arrived at the end of the cycle. Agile methods — and they did it remarkably well — optimized human coordination around this constraint. Sprints, velocity, story points: the whole machinery aimed to smooth and accelerate production.

That constraint is disappearing. With AI assistants, producing is no longer the limiting factor. The bottleneck moves downstream: business alignment, validation, technical governance and mastery of what has been generated. It’s not Scrum that’s being questioned, but the context in which it applies. When production ceases to be the main constraint, some practices benefit from being rebalanced to account for the new stakes of validation and governance.

This phenomenon is not limited to application-code generation, incidentally. On the enterprise-platform projects we run, we observe it whenever AI accelerates the production of technical components, whatever their nature: configuring digital experience platforms, developing enterprise portals, integration connectors, agent orchestrations, flows between information systems. And in contexts where several dozen teams contribute to a single information system, the imbalance amplifies: the ability to produce components grows faster than the organization’s ability to check their consistency with its overall architecture. It’s an enterprise-architecture stake as much as a delivery stake.

In the projects we support, this uncontrolled acceleration creates two recurring risks:

The validation bottleneck on the client side. When production doubles, the business cannot absorb the validation load. Feedback piles up, decisions stall, and paradoxically perceived quality drops — even as the team has never delivered so much.

Invisible technical debt. Components generated quickly may be poorly understood, insufficiently reviewed, introduce unmanaged complexity and weaken the architecture. This risk is all the more insidious because it appears in no velocity metric — it’s paid later, in production.

Acceleration without discipline degrades robustness. That’s the starting observation.

The principle: validation precedes velocity

Our conviction is not that production should slow down, but that what is produced should actually land. In projects heavily assisted by AI, performance no longer depends on execution speed, but on the quality of co-construction and the mastery of industrialization.

This translates into three shifts in the workflow.

1. Accelerate understanding, not production

AI makes it possible to prototype at marginal cost. We use it first as a thinking tool. Concretely, we run live prototyping workshops with the client: the developer builds the scenario before the Product Owner’s eyes, with AI as copilot, and each step is validated in the session.

The value of the exercise does not lie in the code produced — the prototype is not meant to automatically become the production foundation. Its function is to accelerate shared understanding: to surface the business’s unspoken assumptions, the implicit architectural hypotheses, and above all the edge cases that never appear in a user story written in isolation. Our experience shows that in two hours of workshop, you capture what would otherwise have taken several sprint round-trips.

2. Let discovery converge before building

We observe that many teams still use the sprint as a space for functional discovery. In a context heavily assisted by AI, this practice becomes particularly costly: you can now produce a lot, very fast, on ambiguous foundations — hoping the questions will resolve along the way.

So we introduce an explicit checkpoint before any industrialization: the user scenario is formalized and validated by the business, the prototype has been explored and debated, and the end-to-end tests are defined before implementation. No ambiguity survives this step. This is not bureaucracy: it’s a contract of intent that protects the client as much as the team.

3. Industrialize with awareness

Once convergence is reached, the sprint changes nature: it is no longer exploratory, it becomes a stabilization phase. Refactoring, hardening, thorough testing, observability, documentation — you raise a component whose purpose is already validated. Then comes the hardening: monitoring, retrospective, continuous improvement.

This sequencing — explore, converge, industrialize, stabilize — is not opposed to Scrum. It integrates into it, and restores the sprint’s effectiveness by relieving it of what it does poorly.

AI governance is not optional

An AI-native workflow raises a question few organizations have formalized: who knows what the AI has produced in your information system?

The question goes beyond the development team’s comfort. An organization will soon need to be able to explain its engineering decisions as well as its code: why this architecture, why this library, which alternatives were evaluated and set aside, on what criteria. And, for each component: what share was generated, by which tool, what was modified, what was refactored, which human validations were carried out. Code provenance becomes an architectural datum on par with its dependencies.

That’s why we systematically record both chains: the traceability of engineering decisions on one hand, the traceability of AI contributions on the other. Knowing that a module is “generated code then reworked” or “written entirely by hand” changes how you review it, how you maintain it, how you extend trust to it. This double traceability is the best protection against invisible technical debt — and the condition for the auditability of AI-integrating systems, a topic that demanding environments will no longer be able to defer.

A simple rule sums up our position: no generated component should remain unexamined. AI increases power, not judgment. The engineer’s responsibility is not diminished by AI — it is engaged earlier, and more deeply.

Measure what matters

If production is no longer the limiting factor, velocity loses its status as the central metric. It’s not to be banished — it becomes a consequence, not an objective.

What we measure instead: the rework rate, the post-release defect density, the delay between clarifying the need and industrialization, stability in production and Product Owner satisfaction. These outcome-oriented metrics tell the true story of a project: are we building the right thing, and does it hold over time?

Our experience is consistent on this point: velocity comes naturally when clarity is there. The reverse never holds true.

Building systems that last

This approach requires no particular stack, no specific tool, no abandonment of agile rituals. It demands three conditions: a business that is available and engaged in the convergence phases, engineering teams that accept that discipline precedes acceleration, and leadership ready to steer by something other than story points. Adoption is progressive: one project, one workshop, one first formalized convergence point — then an extension as maturity settles in.

Fundamentally, AI does not replace the principles of software engineering; it makes them more demanding. When producing costs almost nothing, value shifts toward what remains rare: shared understanding, architectural coherence, the ability to justify your choices and answer for them over time. Differentiation between organizations will no longer come from their ability to produce more — it will come from their ability to build durable, governed and evolving systems.

That’s the meaning of our work at Beorn: designing, architecting and governing digital platforms in the age of AI — by applying to our own projects, first, the discipline we recommend.