AI made the coding fast, that exposed how slow the process around it really is.

Most engineering organisations that adopt AI tooling see the same pattern in the first month. Individual engineers get faster. Pull requests open sooner, boilerplate disappears, and the demo at the all-hands looks great. Then the numbers that actually matter, cycle time, throughput, time from idea to production, barely move.

The easy conclusion is that the tools are oversold. Usually the tools are fine. What has not moved is the process the work flows through, and that process was shaped by a constraint that is now lifting: for most of the last decade, writing the code was the slow and expensive step.

When the expensive part of building software changes, the process built around it has to change with it. Not by adding ceremony, and not by stripping it away, but by shifting where the weight sits. The center of gravity of good engineering process is moving from coordinating the build to designing it, and the teams seeing real delivery gains are the ones that have let it move.

The rituals were built for slow code

Most of the ceremony a modern team runs grew up around a single fact: implementation was slow. A feature took days to build, sometimes longer, and the cost of building the wrong thing was high. It made sense to spend time up front breaking work into estimable pieces, sequencing it, and synchronising everyone around a shared cadence. The two-week sprint, the planning session, the multi-person refinement: all of it was a reasonable response to expensive implementation.

Over the years much of that hardened into routine. Teams run sprints because the calendar says so, not because the work is genuinely synchronised. Stand-ups report status that a glance at the board would already show. Steps survive because they are familiar, not because anyone could explain what would break if they were removed. None of it was wrong when it was introduced. It simply stopped being examined, while the constraint that justified it kept quietly weakening underneath.

The economics flipped

Consider a refinement meeting: five people, two hours, working through a backlog item until everyone agrees on what to build. That is ten person-hours. When the implementation that followed took a week, ten hours of shared understanding was a good trade. The meeting was cheap relative to the work it protected.

Now an agent can take a well-specified item and produce a working implementation in under a day. The ten-hour meeting has not changed, but the thing it feeds has shrunk by most of its cost. Two hours refining a task that takes a day to build is more time coordinating the work than doing it. Multiply that across a backlog and a calendar, and you reach where many teams already are: most of the week in meetings, with the actual building squeezed into the gaps.

None of this means planning stopped mattering. Planning matters more than it ever did. The expense was never the thinking itself. It came from the number of people doing it synchronously and the breadth of ceremony around it. The ratio between deciding and doing has inverted, and the shape of the deciding has to change with it.

The center of gravity moves to the front

Look at teams that have genuinely absorbed AI into how they ship, and a rough balance keeps showing up. Call it 40 / 40 / 20.

About 40 percent of the time goes to planning and technical design: deciding what to build, how it should fit the system, what the constraints are, and what good looks like.

Another 40 percent goes to working with the AI: writing the spec, prompting, and reviewing the plan it proposes before any code exists. This is where a vague intention becomes a precise instruction, and where most of the quality is won or lost.

The final 20 percent goes to reviewing the output: reading the code the agent produced, checking it against the design, and deciding whether it is ready.

What stands out is how far forward the weight has moved. Eighty percent of the effort now lands before the code exists, in design and specification, rather than after it in review. Set that against how most teams are still organised, where technical direction gets something closer to 10 percent, squeezed between meetings, while the bulk of the calendar goes to coordination. When the front of the process is thin, the review pile at the end grows, the output feels uneven, and the natural conclusion is that the AI is not good enough. More often, the design and the spec were never given the room they needed.

Rebalancing, not cutting

The temptation is to read all this as an argument for less process. It is not. A team that responds by deleting its rituals wholesale tends to rediscover, painfully, why each one existed. The move is to relocate rigour, not remove it.

That starts with looking honestly at each ritual and asking what it is actually for. Where the work in a sprint is not genuinely interdependent, the sprint boundary is mostly overhead. Where a refinement meeting exists to turn a vague ticket into a clear one, a sharper specification practice does that better and in a fraction of the time. Where a stand-up only surfaces status, the board can carry it. The rituals that no longer earn their place lose it, and the reason is specific each time.

Estimation deserves a harder look than most. Planning Poker only produces a meaningful number once the spec is already clear. Before that, the team is either guessing or slicing the work into pieces small enough to feel certain about, which is its own kind of waste. Once the spec is that clear, an AI-assisted build is quick and largely indifferent to the size of the task, so the estimate rarely changes what happens next. The effort spent arriving at the number is hard to justify when the number no longer steers a decision.

The time that comes back gets reinvested at the front, and the shape of that reinvestment matters. The goal is depth, not headcount. A vague ticket turned into a clear, testable spec by a senior architect, a full-stack engineer, and a product owner is worth far more than the same hour spent walking a whole team through a board. On smaller pieces of work, a senior developer and a product owner are often enough. The work stays thorough, the group stays small, and the people who are not in the room are building instead of sitting through coordination that does not need them.

This is what moving the center of gravity looks like in practice: design work given real space on the calendar, and the spec and plan review treated as first-class engineering, because that is what now determines whether the output is any good. A day of clear design that saves a week of confused review is the trade the whole rebalance is built on.

Where this leaves engineering leaders

The uncomfortable part is that none of this shows up as a tooling decision. When the engineers are capable, the tools are in place, and delivery still is not moving, the constraint has usually shifted faster than the process wrapped around it. The rituals that defined a good engineering team for the last decade were tuned for a cost that is now falling away. Re-tuning them for the new one is unglamorous, and it is most of the job.

If that describes your team, the place to look is the balance of the week, not the capability of the tools. The center of gravity has already moved. The process is what has to catch up.