Skip to main content
onext technology
AI May 18, 2026 - 8 min read

Month 6: why your dev team's AI transformation breaks at that point — and the sustaining system that prevents it

The initial redesign is the easy part. The hard part is keeping it working when the novelty fades.

Jordi García
Tech Lead at onext
Tech Lead reviewing the team's AI workflow metrics dashboard on a code screen

I've spent several years going into repos of teams that have done AI transformation. The pattern is always the same: the first months are enthusiasm, the lanes work, the quality gates do their job. Then comes month 6. And month 6, almost always, is where the transformation dies in silence.

What I find when they call me at month 9

When a CTO writes to ask me to come in and review their AI setup, the conversation almost always starts the same way: "we rolled it out a few months ago, the developers are happy with the tools, but something isn't working. We don't know what."

When I go into the repo and the workflows, I know exactly what I'm going to find. I don't know it by deduction — I know it because I've already seen it in twelve development teams across different verticals, sizes and levels of technical maturity.

The diagnosis is almost always the same: the AI workflows are out of date. The validation rules block things they shouldn't block anymore. The project constitution still says things the code no longer respects. And nobody has updated it — not because the team is careless, but because nobody had the mandate to do it.

That's month 6.

How AI transformation works in the first three months

To understand why month 6 is where everything breaks, you have to see what happens before.

The first two or three months of a well-run AI transformation are enthusiasm with method. The team installs the lanes: who decides what, who reviews what, at which point in the flow the human signs off. The project constitution is defined — the document that codifies the immutable rules the AI must respect: architecture, code conventions, security constraints. The quality gates are established: what the agent validates, what the human validates, what gets blocked by default.

If the installation process is well supported, by month three the team sees tangible results. PR review cycles drop. Production defects fall. Onboarding time for new developers is reduced. The team feels it's going faster — and this time, it's measuring it, so it knows it's not just a feeling.

The organization concludes the transformation has worked. That conclusion is the first mistake.

Anatomy of month 6: what breaks and in what order

The transformation hasn't finished at month 3. It has started. And what happens in the next three months determines whether the investment of the first three will hold or evaporate.

In the twelve teams I've supported, the month-6 collapse always follows the same order:

First

The workflows go out of date

The style guide changes, the stack pivots, new dependencies are added. The project constitution still says what it said in month 1. The agent generates code according to rules that no longer reflect reality. Nobody has updated it because "it was working already".

Then

False positives spike in the quality gates

The validation rules start blocking things they shouldn't anymore. The team starts quietly bypassing them so as not to break the delivery flow. First one developer. Then two.

Next

The constitution disappears as the source of truth

Developers trust the versioned document less and their personal judgment more. The consistency of AI-generated code declines. Code reviews drag on because parts the agent signed off badly have to be rewritten.

Finally

The organization returns to square one

By month 8-9 delivery velocity has returned to the prior baseline. And in the technical committee the conversation is: "we're not seeing a return with this, which tool do we try now?" The loop closes.

Why it looks like a technical problem when it isn't

The month-6 collapse has a very specific operational signature: when it happens, all the symptoms point to the tool. "Copilot signs off things we then have to rewrite." "The agent doesn't understand our architecture." "The tests it generates don't cover the cases we need."

They're real symptoms. But the cause isn't the tool. The tool works exactly the same as in month 1 — probably better, because the underlying model has improved. What has changed is the context it operates in. The project constitution no longer reflects reality. The human-agent lanes are out of date. The agent has less reliable information about what it can and can't do in this specific project.

Updating the tool at that moment is buying more speed for a car that has no road. The problem isn't the speed. It's the road.

This is the same thesis articulated by the 70% gap article: 70% of AI success in a team isn't technical, it's organizational. The month-6 collapse is that 70% becoming visible all at once, after months of building up in silence.

The sustaining system that prevents the collapse

After seeing the pattern enough times, the elements that distinguish the teams where the transformation keeps working at month 9 and month 12 aren't complicated. But they have to exist deliberately — they don't install themselves.

Piece 1

Rotating owner

A role that rotates among 2-3 senior devs with judgment, changing every sprint or every two sprints. A single mandate: check whether the project constitution and the quality gates still reflect the reality of the code. If they don't, update. If they do, do nothing. It's two hours of work per sprint.

Piece 2

A single health metric

The percentage of PRs where the agent signed off something the human had to review in depth — not a minor tweak, but a significant rewrite. If that metric rises month to month: stale workflows. If it drops or stabilizes: you're on track. Easy to pull from any code review tool. It doesn't require a sophisticated dashboard.

Piece 3

A monthly 30-minute ritual

Once a month, the rotating owner calls a 30-minute session with the Tech Lead + 1-2 seniors. Fixed agenda: review the single metric, review whether the constitution needs updating, review whether any gate is generating false positives the team is bypassing. If there's nothing to update: 10 minutes and back to work.

What not having the system costs

The cost of the collapse isn't only the loss of productivity. It's the time invested in rebuilding the transformation once it's already broken.

In the two cases where I've come in to repair a collapsed transformation, the time needed to rebuild the workflows, update the project constitution, recalibrate the quality gates and restore the team's trust in the method was between six and eight weeks. Six to eight weeks of the team's work, while it kept shipping to production.

Compared with that, two hours per sprint from a senior dev rotating as sustaining owner is a trivial investment.

The sentence that best sums up the problem

"Agents aren't yet reliable enough for complex engineering."

— Andrej Karpathy

The operational conclusion isn't "don't use AI". It's: use it with reliable context and active supervision. The workflows, the project constitution, the quality gates — that's the reliable context. The rotating owner and the monthly ritual — that's the active supervision.

Without both, the tool isn't less capable. It's simply operating with degraded information about the environment it works in. And the result is month 6.

Month 6 isn't inevitable. It's the result of assuming the transformation ends the day you install it.

If you run a development team and want to diagnose whether your current setup will hold beyond month 6, Bernat's article with the five organizational dimensions and the four questions for the committee is the starting point: The 70% gap.

If you want to talk about how we've installed the sustaining system in the teams we support: info@onext.es · subject "AI sustaining month 6".

Jordi García
Written by
Jordi García
Tech Lead at onext

Jordi García is Tech Lead at onext. He works on bringing AI into governed production across development and product teams —with Spec-Driven Development, context engineering and human verification at every step— and authors onext's technical insights on the method, quality and cost of applied AI.

LinkedIn →

Does your AI transformation have a sustaining system?

At onext we install the complete system — lanes, project constitution, quality gates and sustaining plan — without stopping deliveries.

See how we work

Without stopping deliveries. Without months of planning.