← RCF

Concept

What is the 80/20 flip in AI coding?Copy link

The 80/20 flip is the reversal Andrej Karpathy put numbers to in January 2026: coding went from 80% written by hand to 80% written by agents in a few weeks. What flipped, what stayed hard, and why the weighting of software effort is now upside down.

Last updated

The 80/20 flip in AI coding is the reversal Andrej Karpathy put numbers to in January 2026: in a few weeks, his coding went from roughly 80% written by hand to 80% written by agents. The typing flipped to the machines. The hard part of the job stayed human, and the hard part is now most of the work.

Where does the term come from?Copy link

From a post Karpathy wrote on 26 January 2026. He described moving from about 80% manual and autocomplete coding in November to 80% agent coding with 20% edits and touch-ups by December, and called it the biggest change to his coding workflow in around two decades of programming.

He wasn’t announcing a benchmark. He was describing his own working week, which is why the numbers travelled: they matched what a lot of engineers were watching happen in their own editors on roughly the same timeline. The name settled afterwards, as shorthand for the shift his post described.

What actually flipped?Copy link

Who writes the code, and with it where the effort sits. The work itself didn’t shrink. The 80% of a build that used to be typing became the 20%, and the 20% that was always the difficult bit, deciding what to build and proving it got built, became the 80%.

The eighty-twenty flip A before-and-after comparison of where engineering effort goes, shown as two vertical bars of identical total height. Before AI: 80 percent of effort was typing, writing code, generating boilerplate, hand-rolling docs, and only 20 percent was the hard engineering work: requirements, acceptance criteria, architecture, review, traceability. After AI, the proportions invert: 20 percent typing, 80 percent the hard stuff. The total work is the same. The weighting flipped. The hard-stuff segment, shown in burnt orange, is the part where engineering value actually lives, it was always there, just hidden by the bulk of typing. Before AI: 80% of engineering effort spent on typing: writing code by hand, generating boilerplate, hand-rolling documentation. Visible work that masked everything else. 80% Typing Before AI: only 20% on the hard stuff: requirements, acceptance criteria, architecture, traceability, review. The part most organisations quietly skimped on because the typing hid it. 20% The hard stuff After AI: 20% on typing. AI does the code, the boilerplate, the docs. The visible bulk of the old job collapsed. 20% Typing After AI: 80% on the hard stuff. The thinking, the structure, the discipline. Same activities, same scope; now load-bearing because the typing isn't masking them. The engineering, as distinct from the coding. 80% The hard stuff
Same work. Inverted weighting.

The mistakes moved with the effort. Karpathy’s observation was that agent errors are no longer syntax errors; they’re “subtle conceptual errors that a slightly sloppy, hasty junior dev might do”. Wrong assumptions, chosen on your behalf, in code that compiles and reads well. Deciding whether those assumptions were right was always engineering’s job. It just used to hide behind the typing.

Why does the flip matter?Copy link

Because most engineering organisations are still weighted for the old ratio. Hiring, review habits and definitions of done all assume the typing is the job, and the typing has stopped being the job.

A team that takes the new speed and leaves its discipline unchanged ships code faster than it can understand it; that failure has its own page in AI drift. A team that mistakes a rapid first 80% for a nearly finished product is standing in the gap described in demo-ready versus production-ready. And the concrete engineering that hides in the stretch AI skips past, the part that still bites in production, is the longer read on the blog: The last twenty percent.

What does the flip mean for methodology?Copy link

It makes the methodology the work, rather than a tax on the work. When the code itself is nearly free, what a team is actually paying for is the requirement, the acceptance criteria and the verification.

RCF is built on that reading of the flip. Acceptance criteria written before the code give the agent’s output a contract to be tested against, covered in acceptance criteria as the contract. The five-stage build cycle keeps review a separate act from generation. Traceability ties the newly cheap code back to the decisions that made it worth writing. Two years of building this way have held to the same weighting in every real project I’ve shipped: the code got cheaper, the discipline carried more of the load, and the total never really shrank.

Karpathy’s flip took a few weeks. Most organisations will take longer, and the ones that reweight their engineering before the backlog forces it are the ones that will keep the speed.