The eighty-twenty flipCopy link

The 80-20 flip is the moment AI made the first 80% of building software cheap while the last 20% stayed exactly as hard.

Two years of working with AI tools, properly and at depth, has changed my sense of where the expensive parts of software live. They didn’t move. They just stopped being hidden by the cost of typing.

The first eighty percent of any build is now astonishingly fast. Scaffolding, structure, fluent code in any language a model has seen enough of, reasonable patterns, a working demo you can click through. Things that used to take a week now take an afternoon. If you’ve been writing software long enough to remember the alternative, the speed is jarring. The first time I built a real prototype in an afternoon I couldn’t quite shake the feeling that I’d cheated.

The last twenty percent is where it bites. That’s the part where the agent’s output stops being convincing and starts being subtly wrong. Where it builds you something that compiles, runs, and looks right in the demo, but quietly carries decisions you never made. Decisions about edge cases. Scaling assumptions. Security posture. Schema design. The hardest part of software engineering was always that last twenty percent. AI hasn’t changed that. It’s just made it easier to think you’ve already done it.

What actually got cheapCopy link

Be specific about what AI has changed, because the “AI makes software faster” framing is doing a lot of damage by being too vague.

Typing got cheap. Pattern-matching from a brief got cheap. Generating plausible structure got cheap. Producing code that looks like the codebase it’s being added to got cheap. These are the activities that filled most engineering hours. They were the bulk of the work even when they weren’t the hardest of the work.

None of that is the same as “deciding what to build, ensuring it’s right, and proving it stays right.” Those activities are now a much larger fraction of the work, because the activities around them collapsed. They were always the part that mattered. They’re also the part most engineering organisations were quietly skimping on, because the typing was where the visible effort lived. With the typing gone, the skimping is now load-bearing and painfully visible.

What stayed hardCopy link

Three things, in roughly increasing order of pain.

Knowing what to build. A clear requirement, properly scoped, with the implications worked through, was always rare. AI doesn’t produce that for you. It will draft something that looks like a requirement from a thin prompt, but that’s a parlour trick, not requirements work. Knowing what to build is still a human discipline, and it’s now the single most important one.

Knowing whether what got built is right. An agent will tell you it built what you asked for. It might have. It might not have. The way to tell is to have written the acceptance criteria ahead of time, with the tests against them, and to check that what got built passes those tests honestly. This is what the document chain and the build cycle are for. Without them, you’re trusting the agent’s self-report. The agent’s self-report is not evidence.

Keeping what got built right, as the project evolves. The part everyone has always underestimated. A working feature is one thing. A working feature that’s still working in six months, after twelve other features have been added, is a different problem. Traceability and a healthy test suite are the only things that survive this. AI doesn’t make this part easier. If anything, it makes it harder, because it lowers the bar for adding new features and raises the volume of code under maintenance.

Worth saying, before the next section: AI is useful upstream of the build. It streamlines requirements gathering, story drafting, architecture sketching, and the documentation work that surrounds them, provided the human keeps charge of what’s being asked for. That whole topic, AI-assisted upstream work against corporate standards and non-functional requirements, is a separate piece, and deserves its own treatment. It’s also where a lot of the next round of tooling sits. For this page, it’s an aside.

The dangerous version of thisCopy link

A version of the flip is already loose in the wild, and it’s going to be a substantial problem for the industry over the next year or two. Product owners and executives can spring up a working-ish prototype themselves now, in an afternoon. The smart ones know that’s a prototype. The rest convince themselves the hard work is done, then toss it over the fence to an already-overworked engineering team to “just check it and productionise it.” After all, the AI built it. How hard can the rest be? Eighty percent of the work was done in an afternoon.

To be fair to the prototype: when a non-engineer can encode an algorithm, a workflow, or a screen flow in a working artefact, that artefact is a real input to the requirements process. It’s easier to write an AC against something runnable than against a Word document. The mistake is treating the prototype as the build instead of the brief. As an aid to the upstream work, it’s genuinely useful. As a shortcut around the engineering, it’s the trap executives keep walking into.

Most companies have no real plan for how AI-built software actually gets shipped, paid for, and supported. McKinsey’s State of AI work consistently finds that despite near-universal adoption, only a small minority of organisations report material business value from it, and most are still figuring out how to scale beyond pilots. So companies act out of a quiet desperation, push prototypes into production with the engineering effectively skipped, and discover the hard way that “the AI built it” is the easy eighty percent. The hard twenty percent is still sitting there, untouched. They’ll meet it in production.

This is what vibe coding has been quietly normalising. AI as a fast typist, no methodology behind the typing. Drift is the price.

Why this matters for methodologyCopy link

For the thirty years I’ve been in this trade, software methodology arguments mostly came down to a tax on typing. Waterfall versus agile. TDD versus “ship and fix.” Heavy docs versus light docs. The argument was always about how much ceremony you could afford to layer onto the actual code-writing without slowing the team to a halt. Methodologies that imposed too much ceremony got rejected, because typing was the bottleneck and ceremony made the bottleneck worse.

With typing not the bottleneck anymore, the argument changes. The ceremony isn’t a tax on the expensive part of the work. The ceremony is now the work. Writing the requirement properly, breaking it into stories properly, writing acceptance criteria that hold up, sequencing the build properly, reviewing the diff honestly, running the cycle: these activities are no longer overhead. They’re the value-adding part. The typing is the overhead now, and AI ate it.

Teams that figure this out get an enormous lift. The expensive activities are the ones that compound. A clean requirement set survives the project. A thoughtful build sequence shapes the next quarter. A test suite that traces to acceptance criteria protects the product for years. None of those are typing.

Teams that don’t figure it out will keep trying to skip the planning to get to the typing, because that’s what felt productive for their entire careers. Then they wonder why their AI-accelerated team produces twice as much code and twice as many bugs, with less institutional knowledge than before.

This is what AI drift looks like at the team level. The discipline decay that happens when AI-generated code outpaces the engineering practice around it. Distinct from model drift, and a bigger problem. Fast typing without the discipline that used to come with it. The output compounds, but in the wrong direction. Drift is the price of taking the speed and skipping the engineering. The methodology is what keeps the speed without paying it.

The labour situationCopy link

The labour situation has flipped, too. The thing that used to cost the most, the actual writing of code, is now the cheapest part of the stack. Which means, for the first time in my career, there is real room to focus on the parts that were always the actual problem.

The thinking. The structure. The discipline. The engineering, as distinct from the coding.

Software engineering, properly done, was always 80% thinking and 20% typing. Most software organisations spent 80% of their effort on the typing, because that’s where the cost was. The proportions are now reversed, by necessity. Organisations that adapt their effort to where the cost actually sits will build serious things. The ones that don’t will ship a lot of code that nobody can stand behind.

What RCF is for, in this contextCopy link

RCF is the operational answer to “what does the eighty percent that matters actually look like.” The document chain is what the thinking produces. The build cycle is the discipline that survives contact with agents. Traceability is what holds the work together once it’s shipped.

The framework isn’t a heavy ceremony. It’s a small vocabulary, a tight chain, and a five-stage cycle. It runs at exactly the right level for the activity that’s now most expensive. It also happens to be the same activity that was always most valuable, which is why the framework reads as old-fashioned in places. It’s not old-fashioned. It’s the part that always mattered, finally afforded.