There are three operational rules that separate teams that scale with AI from teams that only accelerate their own chaos. All three are so clean they fit on a napkin. And almost nobody applies them. We articulate them as canonical claims at onext because they're the foundation of the method with which we redesign development teams — but their value doesn't depend on the method. They're true on their own, and any Tech Lead who internalizes them next week changes how they build software with AI.
Three claims. Three antidotes.
The three claims are these:
None is complicated. None is new at all if you've spent years working in serious engineering. What is new is how easy they are to violate when a whole team starts using Copilot, Cursor or Windsurf simultaneously with no method. The speed of tool adoption outpaces the speed of discipline adoption, and the paradox the METR study documented last year appears: developers who report +20% subjective productivity while being −19% less productive measured in commits, PR cycle and production defects.
The paradox isn't a flaw in the technology. It's the absence of the three claims. And of the three antidotes that go with them.
Claim 1: the model isn't the source of truth
The model — Claude, GPT-5, Gemini, whichever — doesn't remember. It doesn't keep state between conversations. It isn't auditable after the fact. And, above all, it doesn't codify the project's real rules: the style guide, the deprecated dependencies, the architectural decisions the team made two months ago for reasons the current chat ignores. When a developer asks the model "how do I do X in this repo?" and accepts the answer without checking, they're trusting the model's probabilistic memory as if it were the project's official documentation. It isn't. And every time they're confused, there's latent technical debt signed by an agent that tomorrow won't be able to explain why it signed it.
Operational antidote: the team needs an external layer of persistent context that the agent consults every time. Not "the agent remembers" — "the agent reads". Specifically, you need a set of versioned documents that live in the repo (or in a context service) and codify the real decisions: the style guide, the naming rules, the allowed and forbidden dependencies, the detected antipatterns, the architecture agreements. In our work we call this the project constitution — an explicit file or set of files the agent receives as part of every operational prompt, and that keep the model inside the project's frame instead of the frame of "what the web says about this in general".
What matters about the constitution isn't its sophistication. It's that it exists and gets updated. A team that starts with ten rules written in markdown and refines them each sprint moves from "the model decides every time" to "the model applies our decisions". The mental shift is enormous and happens in weeks, not years.
Claim 2: the chat isn't the system
The second violation is the most common and the most invisible. The developer opens a conversation in Claude or Cursor, sends 40 messages until they reach a commit that works, and closes the tab. Three weeks later they need to modify what they did, don't remember why they made each decision, open another conversation from scratch and iterate 40 messages again to reach a different variant of the same problem. The history of the reasoning has been lost. The knowledge has lived only in the chat, which is ephemeral.
When this happens to a developer once, it's an anecdote. When it happens to a team of fifty developers every week, it's the reason the organization feels it has AI but doesn't accumulate advantage. The chat has captured the output — the code — but thrown away the input, the constraints, the context, the reasoning. And without input there's no system, there's repeated improvisation.
Operational antidote: codify workflows with automated quality gates that live outside the chat. The idea is trivial: instead of every conversation with the model being ad hoc, there's a handful of defined flows — idea-to-feature, quick-improvement, spike, audit — that the team executes consistently. Each flow has phases, each phase has a goal and a quality gate that checks whether the output meets objective criteria before moving to the next. The gate can be a linter, a spec validation, a test, a human checklist — but it exists, it's automatic and it's the same for everyone.
The team that codifies four or five workflows with their respective gates moves from "each developer has their own dialogue with the AI" to "the team has a common operating system with AI inside". It isn't optional for scaling beyond ten people working in parallel: with less discipline, conflicts of judgment multiply exponentially. With discipline, the curve flattens.
Claim 3: code isn't the only artifact
The third violation is the hardest to correct because it goes against an intuition professional development has been cultivating for thirty years: "the code is the truth; the documents are going to get out of date anyway; better to save the paperwork and focus on what matters, which is what compiles". It's defensible in a world without AI. In a world with AI it's debt in slow motion.
The reason is that, when an agent collaborates on the code, it needs to understand what the code is supposed to do — not what it actually does. The difference between "what it should do" and "what it does" is where the bugs live. If the team's only artifact is the code, the agent can only infer intent retroactively, and it will get the edge cases wrong — the ones that don't appear in the tests but do appear in the spirit of the specs. If the team maintains specs, acceptance criteria, business rules and design decisions as first-class citizens — versioned alongside the code — the agent can cross-check, and so can the humans who review.
Operational antidote: Spec-Driven Development. The specs are the source; the code is derived. The flow changes: before touching code you update the spec, then you validate that the code meets the spec, then you merge. Implemented well, this means pre-commit validation against the spec (structure, naming, dependencies, coverage) and a merge-blocking hook if the code doesn't comply. It isn't science fiction — they're tools that have existed for years. What's new is the discipline of using them as a mandatory check, not as an ornament.
There's an important secondary benefit: well-maintained specs become the material the agent uses to generate tests, documentation, examples for onboarding new developers. The effort of writing a spec pays off three times over.
What separates "installing Copilot" from "industrializing AI in your team"
Three claims. Three antidotes. External context layer. Workflows with gates. Spec-driven. None is complicated. And yet the teams that apply them are a minority — even among those paying for premium Cursor or Copilot licenses for the whole workforce.
The difference isn't tools. It's disciplines. And disciplines are installed in weeks if there's method; they're never installed if there isn't. That's the real frontier between the teams that scale with AI and those that only accelerate their own chaos.
At onext we call this industrializing development with AI, and it's the core of the transformation program we offer development teams. But the value of the three claims doesn't depend on the program: any Tech Lead can install them on their own if they have the authority, the judgment and the patience for the first weeks to hurt a little. The teams that do it on their own reach the same destination as those who hire help; they take longer and break more glass along the way. It's a legitimate decision.
The honest quote that closes the conversation
"Agents aren't yet reliable enough for complex engineering."
— Andrej Karpathy
The person saying that isn't an anti-AI skeptic. He's one of the most respected AI engineers in the world. The operational conclusion isn't "don't use AI". It's: use it with method. Agents aren't reliable on their own; with the three claims internalized and the three antidotes in production, they're remarkable tools. Without them, they're the illusion of progress.
If you want to take something actionable from this read, we've prepared five questions to audit your AI dev team next Monday. One A4 page, no email required, direct download:
→ Download the 5-question audit
If the five answers leave you satisfied, your team is better than 80% of the market. If they leave you uncomfortable, let's talk: info@onext.es — subject "AI dev audit". A 30-minute conversation, no commitment.
Sources: 2024 METR study on developer productivity with AI tools (the +20%/−19% paradox); public statements by Andrej Karpathy on agent reliability in complex engineering.
Further reading: Spec-Driven Development: the methodology · Context Engineering: the discipline · MVP vs Specification: the Quick Ship bias
