The Last Thirty Per Cent Is Where Your App Is Made
How Charity Majors and Addy Osmani explain the part of building AI helps with and the part it hides.
An agent will take a feature from nothing to almost-done in an afternoon, and the almost is the whole problem. It scaffolds the routes, writes the tests, wires the happy path, and produces something that compiles, runs, and demos clean. Then you reach the part that was always the hard part: the edge cases, the integration with the system that does not behave, the security hole nobody specified, the way it falls over under real production load. The agent delivered you to the eighty-per-cent line at speed and abandoned you at the cliff, and the cliff is the same height it has always been.
Addy Osmani named this the seventy-per-cent problem, and Charity Majors named the thing it threatens. Osmani’s observation is about a single build: AI carries you most of the way and leaves the last portion as hard as ever. Majors’s is about a career: the last portion is exactly the work that used to turn juniors into seniors, and if you let the machine swallow it, you stop forging the judgement you now need more of than ever. The question is no longer only who is in the room. It is where the next generation of judgement is going to come from.
1. The seventy per cent is a gift; the thirty is the job
When you watch a senior engineer work with an AI coding tool, it looks like magic; they scaffold an entire feature in minutes, tests and documentation included. Watch more closely and you see they are not accepting what the model hands them. They are refactoring the generated sprawl into smaller modules, tightening the interfaces, throwing away the clever bits that will not survive contact with the rest of the system. The model is accelerating the part they already know how to do, and their judgement is what keeps the result alive. The acceleration is real. The judgement is what makes the acceleration safe.
Osmani’s term for what happens when the judgement is missing is house of cards code: software that looks complete and collapses under real-world pressure. It is the precise failure of a junior, or anyone, who accepts the model’s output because they cannot yet see what is wrong with it. The thing stands up in the demo. It stands up in the second demo. It comes down the first time the world leans on it, and it comes down in a way the person who shipped it cannot diagnose, because they did not build the parts that broke. The seventy per cent the machine wrote was never the dangerous part. The thirty per cent it could not write is where the building actually happens, and it is the part you now have to be good enough to finish.
2. AI helps the people who least need the help
The most counterintuitive thing in Osmani’s account is the one most adoption strategies get backwards. AI tools help experienced developers more than beginners. He calls it the knowledge paradox: seniors use AI to accelerate what they already know how to do, while juniors try to use it to learn what to do, and only the first of those works. The senior already holds the model of the system in their head, so they can see in a glance whether the generated code belongs in it. The junior has no such model, so they have no way to tell good output from plausible output, and plausible output is exactly what the machine is best at producing.
This inverts the democratisation story the tools were sold on. The promise was that AI would flatten the field, letting the inexperienced perform like experts. What it actually does is widen the gap, because it is a force multiplier and a multiplier rewards whatever you already bring. Bring deep judgement and it makes you formidable. Bring little and it makes you fast at producing things you cannot evaluate, which is worse than slow. An organisation that hands powerful generation to its most junior people and expects it to substitute for experience has misread the tool at a basic level. It does not close the experience gap. It pays out in proportion to the experience you have, and it charges interest on the experience you lack.
3. Software is an apprenticeship trade
Majors states the premise the whole argument rests on with no hedging: software is an apprenticeship industry. You do not learn to be an engineer by reading books; you learn by doing, and doing, and doing again, on a team alongside people further along than you. Most of the learning happens on the job, all of it takes time, and her estimate is that it takes a solid seven-plus years of writing, reviewing, and deploying code to forge someone the job ladder is willing to call senior. There is nothing magic about the number. The point is that the competence is tacit, accumulated, and impossible to shortcut, because it is made of ten thousand small encounters with reality that no course can stage.
And the thing that makes someone senior was never the code. As Majors puts it, being a senior engineer is not primarily about your ability to write code; it is about your ability to understand, maintain, explain, and manage a large system over time, to hold its models in your head, to have judgement and instincts you can trust. That capacity is built from precisely the work an agent now does for you: the routine implementation, the debugging, the repetitive encounters with how things actually break. The apprenticeship was never a tax on the way to the real work. The apprenticeship was the mechanism that produced the judgement, and the judgement is the real work.
4. The trap is generational, and it compounds
Here the two observations lock together into something neither says alone. The work AI absorbs is the seventy per cent: the routine generation, the boilerplate, the first-draft debugging. That seventy per cent is also the substrate of the apprenticeship, the daily reps through which a junior slowly accumulates the model of the system that one day lets them see what is wrong with the other thirty. Automate the reps and you have not just sped up today’s work. You have removed the path by which today’s junior becomes tomorrow’s senior, the one whose judgement the whole arrangement now depends on to catch what the machine gets wrong.
Majors says it plainly: by not hiring and training junior engineers, we are cannibalising our own future. The senior-only hiring reflex that AI encourages is eating its own seed corn. Every organisation that decides it needs only experienced people who can supervise AI is relying on a supply of experienced people that it has simultaneously stopped producing. Camille Fournier put the question that has no good answer: how do people become senior engineers if they never start as junior ones. The pipeline that makes the supervisor and the work the machine now does are the same work. You cannot keep draining it from one end and expect it to keep filling from the other.
5. The measured cost of skipping the apprenticeship
Intuition is no longer the only evidence. A randomised controlled trial run by Anthropic put fifty-two mostly-junior developers in front of an unfamiliar Python library and asked them to learn it, half with AI assistance and half by hand. On a quiz covering concepts they had used minutes before, the AI-assisted group scored seventeen per cent lower than those who had coded by hand, about two letter grades, and the steepest decline of all was in debugging: the exact skill you most need when your job is catching what AI-written code gets wrong. The tool that produces the code you must supervise erodes the capability you supervise it with. That is not an irony; it is a feedback loop, and it runs the wrong way.
The same study holds the way out, and it matters as much as the warning. The outcome turned less on whether AI was used than on how. The developers who kept their understanding were the ones who treated the model as a tutor rather than a vending machine: asking it to explain the code it generated, posing the conceptual question before pasting the answer, writing some of it by hand to keep the muscle live. Those who offloaded the thinking wholesale lost the most. The lesson is not that AI atrophies judgement. It is that AI used as a substitute for thinking atrophies judgement, and AI used as a provocation to think can sharpen it, and the difference between the two is a deliberate choice an organisation has to design for rather than hope for.
6. What this asks of the people who run engineering
The seductive move is the one to refuse: staff only seniors, let them drive agents, skip the expensive years of growing your own. It works for exactly as long as your seniors last, and not a day longer, and you have given up the means of replacing them. The organisations that come through this will treat the apprenticeship as infrastructure, not overhead, and will protect the conditions under which judgement still forms even though the machine could do the underlying task faster.
In practice that means deciding, on purpose, which work a human should do the hard way because the doing is how they are made, not because it is the efficient route to the artefact. It means seniors who teach, and being willing to pay for the teaching, which has always been the historical failure point of apprenticeship: it collapses the moment the masters will not invest in the apprentices. It means juniors who use AI to gain experience faster rather than to bypass it, which is a real distinction with real daylight between its two halves. Writing the code was always the easy part. Owning it, operating it, understanding it well enough to change it safely at two in the morning when it is on fire, that was the job, and that is the part no agent has taken from you. It has only made it easier to arrive at that moment never having learned how.
(An Organisational Prompt is something you can do now....)
Organisational Prompt
Name the work you will keep doing the hard way
Pick one capability your team is now tempted to hand to an agent end to end, because the agent can produce the artefact faster than a person can. Now ask a different question about it than the efficiency question. Ask: is this one of the tasks through which a junior on this team actually learns the system? Is this where the reps live, the small repeated encounters with how things really break that slowly build the model in someone’s head?
If it is, you have found work you should think twice before fully automating, not because the machine cannot do it, but because the doing is how you make the people you will need to supervise the machine. Designate it deliberately. Decide which parts a developing engineer does by hand, on purpose, with a senior close enough to teach, and which parts the agent may carry.
Then change how the agent is used on everything else. Require that the people working with it ask it to explain, not just generate; that they pose the conceptual question before they accept the answer; that they keep writing enough by hand to know what they are looking at. The team that uses AI as a tutor keeps its judgement. The team that uses it as a vending machine loses the judgement precisely where it most needs it, which is in catching what the machine got wrong. You will not get that distinction by accident. You have to build it in.
Further Reading
Addy Osmani, The 70% problem: Hard truths about AI-assisted coding (2024). The origin of the framing this article builds on: the last thirty per cent, house of cards code, and the knowledge paradox by which AI helps experienced developers more than beginners. Short and worth reading in full.
Addy Osmani, The 80% Problem in Agentic Coding (2026). The sequel, written once agents could carry more of the build. The percentage moved; the shape did not. Read it for the inversion of where the time now goes: problem definition and verification, not execution.
Charity Majors, Generative AI is not going to build your engineering team for you (2024). The apprenticeship-industry argument in full, including the seven-year figure, the definition of seniority as something other than the ability to write code, and the warning about cannibalising your own future. The piece every technology leader making headcount decisions this year should read.
Addy Osmani, AI Won’t Kill Junior Devs, But Your Hiring Strategy Might (2025). The pipeline argument applied directly to hiring, drawing in Camille Fournier’s question about where seniors come from if no one starts as a junior.
Anthropic, How AI assistance impacts the formation of coding skills (2026). The randomised controlled trial behind section five: the seventeen-per-cent comprehension gap, the steep fall in debugging skill, and the finding that how AI is used matters more than whether, with treating it as a tutor preserving understanding.
I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.