AI can write code quickly. That is no longer interesting, and it is no longer the question. The question is whether the code that gets written can be operated, changed, and trusted six months later, and on that question the fast, conversational style of AI coding that became popular over the past two years has a poor record. Generating code from a loose prompt and accepting what comes back, often called vibe coding, is a genuinely good way to explore an idea. It is a poor way to build a system someone has to run.

The teams shipping reliable AI-built software in 2026 have not abandoned AI-assisted coding. They have professionalised it. The discipline that separates exploration from production is the same discipline that always separated them: a clear specification of what the system should do, automated checks that verify it does that, and a record of why it was built the way it was. AI changes how fast the code arrives. It does not change what makes code trustworthy, and pretending otherwise produces software that works in the demo and accumulates problems in production until it cannot be safely changed at all.

The three-month wall

Vibe coding has a characteristic failure, and it arrives on a predictable schedule. The first few weeks are exhilarating. Features appear faster than they ever have, the prototype takes shape in days, and it feels as though the old constraints of software development have simply lifted.

‍

Then the compounding begins. Code generated from loose prompts, accepted without a specification of what it was meant to do, tends to be locally plausible and globally incoherent. Each piece looks reasonable. Together they form a system no one fully understands, with no clear record of why any given decision was made, and with subtle inconsistencies that only surface under conditions the prompts never considered. Around the three-month mark, the velocity that felt like liberation becomes a wall. Every change risks breaking something unrelated, debugging takes longer than building did, and the team discovers it has produced a large quantity of code and a small quantity of understanding. The technical debt was being taken on the whole time. It just was not visible while the demos were going well.

This is not an argument against using AI to write code. The studio uses it daily, and the acceleration is real. It is an argument against using AI to write code without the discipline that makes any code maintainable, because AI removes the time you used to spend understanding what you were building, and that understanding was never optional. It was load-bearing.

Specs and evals are the discipline

The synthesis that works is structured exploration followed by formalisation. Use AI's speed to explore the problem and discover what the system actually needs to do, then formalise that understanding into a specification before the code becomes the thing you depend on. The exploration is where vibe coding earns its place. The formalisation is where it has to stop.

A specification is the statement of what the system should do, precise enough that you can check whether it does it. With AI writing much of the code, the specification becomes more important rather than less, because it is the thing that keeps the generated pieces coherent and the thing a reviewer checks the output against. Without it, there is no standard for the code to meet, only the question of whether it happens to look right.

Evaluations, or evals, are the automated checks that verify the system does what the specification says, and they have become to AI-built software what tests have always been to software, with an added dimension. AI-generated code, and especially AI features whose behaviour is probabilistic, cannot be trusted on the strength of a single successful run. It has to be checked for consistency across many runs, gated in the build pipeline so that failing code does not ship, and re-checked against the real failures that production surfaces. Teams that do this well report spending a large share of their development time on evaluation, not because they are slow, but because evaluation is where trust in an AI-built system actually comes from. The code generation was the cheap part. The verification is the work.

This is how the studio approaches AI-assisted engineering, and it is continuous with how the studio has always built systems meant to be operated rather than merely delivered. Platforms like T-Stats Solutions, which processes 117 million records across 585 trackers and has been continuously developed across more than seven years, do not survive that long because the code was written quickly. They survive because the standards held: clear specifications, layered monitoring with tools like Sentry and Horizon, and an engineering record that lets a change made in year seven be made safely. AI makes the writing faster. The studio's standards are what make the result something that can still be changed in year seven.

Why this matters more, not less, as AI improves

A reasonable objection is that this is a transitional problem, and that as models improve they will produce code coherent enough to need less of this discipline. The objection has it backwards.

As AI writes more of the code, the proportion of a system that no human wrote by hand goes up, and so does the importance of being able to verify, from the outside, that the system does what it should. When a person writes code, the act of writing it produces understanding as a by-product. When AI writes it, that understanding is not produced unless someone deliberately creates it, through the specification that says what the code should do and the evals that confirm it does. The better AI gets at generating code, the more code there is whose correctness rests entirely on external verification rather than on anyone having reasoned through it. The discipline does not become less necessary as the models improve. It becomes the only thing standing between a team and a large, fast-growing system that nobody understands.

What this means for your build

If your team is using AI to write code, the useful question is not how much faster you are going. It is whether you could safely change what you have built in six months. If the honest answer is no, the speed is borrowed against a debt that comes due on schedule, usually around the time the system becomes important enough that breaking it matters.

The practical move is to keep the exploration loose and make the formalisation strict. Let AI help you discover what to build, fast and cheaply. Then write down what the system must do, build the evals that prove it does, gate them in your pipeline, and treat the generated code as something to be verified rather than something to be trusted because it ran once. The teams doing this are shipping AI-built software that holds up. The teams that skipped it are meeting the three-month wall, on time, as it always arrives.