They Say AI Writes the Code Now. Their Own Interviews Say Otherwise.

1. The claim

In March 2025, at a Council on Foreign Relations event, Anthropic’s CEO Dario Amodei said this:

“I think we will be there in three to six months, where AI is writing 90% of the code. And then, in 12 months, we may be in a world where AI is writing essentially all of the code.”

Sam Altman has made his own version of the argument repeatedly, that each engineer will do far more and that companies will eventually need fewer of them.

If you are a founder, you have probably had some version of this quoted back to you. Usually by someone explaining why your build should be cheaper, or why the quote you just received is too high, or why they are going to try it themselves first.

2. The hiring

Those same companies hire software engineers, in volume, at high salaries. And when they do, they do not let candidates use AI.

Anthropic publishes this as guidance for candidates. On live interviews: “no AI assistance unless we indicate otherwise,” because “we’re curious to see how you think through problems in real time.” On take-home assessments: “Complete these without Claude unless we indicate otherwise.”

They have gone further and published an engineering post called Designing AI-resistant technical evaluations. Its premise is that every new model release erodes the previous hiring test’s ability to tell a strong engineer apart from a capable model, so the tests have to be rebuilt.

Interview guides compiled from candidate reports describe the shape consistently. interviewing.io’s summary of Anthropic’s loop records a style that is “first-principles and build-from-scratch.” Candidates are asked to build the underlying machinery themselves rather than reach for a ready-made part, to “handle edge cases under pressure,” and to “defend” their choices, with “the reasoning behind every decision … front and center.”

Translated out of hiring language: the test is whether you understand what you produced well enough to argue about it.

Two honest caveats, because the argument is stronger without the overreach. Assessments ban tools to isolate a baseline, the way an exam bans calculators, and that alone is not a verdict on the tool. And the practice is not uniform: Google has piloted the opposite, letting candidates use an approved assistant and scoring how well they use it.

But notice what got chosen as still worth testing, by people who know exactly what these models can do. The models can plainly produce working code, and speed is cheap now too. What still gets tested is whether the person can reason about a whole system under pressure, and say out loud why it is built the way it is. One camp removes the model to see the engineer, the other leaves it in and grades the engineer’s handling of it. Nobody has replaced the interview with a test of how well you prompt.

3. Did it actually happen?

The three-to-six month prediction is now well past due, so it can be checked.

Redwood Research looked into whether 90% of Anthropic’s own code is AI-written and concluded the claim is “probably false in a straightforward sense.” A minority of teams are near 90%. The company-wide average was estimated as “much less than 90%, more like 50%.” And on the thing that actually matters, the productivity gain, the estimate was “much less than 10x and I’d guess less than 2x.”

Not everyone reads it that way. John Gruber’s take is more generous on the raw line count, arguing AI mostly produced code that would never have been written at all rather than displacing human output.

Both readings can be true, and either way the number people repeat is doing different work than the number people measured. “Engineers are roughly twice as productive” and “software engineering is solved” are not the same claim. Only one of them is being sold.

4. Why the gap exists

There is a reason the gap between those two claims exists, and it is not that the models are bad. They are remarkably good at what they do. It is that writing code and building software are not the same activity, and only the first one got cheap.

Think of it as building a house. An AI model is a fast, tireless, genuinely skilled builder who will construct any room you describe, to a good standard, in minutes. What it will not do is walk outside, look at the whole structure, and tell you that the extension you asked for last month is now resting on a wall that was never meant to carry it.

That is the distinction: generation is local, architecture is global.

Ask for one piece of your product and you get a good one, correct in itself. But the questions that decide whether the thing is still workable in eighteen months cannot be answered from inside that one piece:

• These two features look similar. Should they run on the same underlying code, or are they about to grow apart?
• If this step fails halfway through, what is left sitting in a broken state, and who clears it up?
• Does the way we have structured the data survive the third item on the roadmap, or does it quietly force a rebuild?

The newer AI tools can read a whole project and reorganise code across all of it, so this is not a hard limit on the technology. The constraint is subtler. Deciding that two things are really the same thing is a judgment, not a search. It means betting they will still need to behave identically in a year, after the business has changed around them. That is a claim about the future, and it is not written down anywhere in the code.

So the safe move, more often than not, is to write something new rather than reuse something that already exists, because writing new usually works and reorganising might break something elsewhere that you cannot currently see. Do that a few hundred times with nobody standing back to look at the whole, and you arrive somewhere nobody would have chosen, without a single step having been wrong along the way. Every individual addition was locally reasonable. The system as a whole was the only unreasonable thing, and it was the one thing nobody was actually looking at.

The same blind spot covers the failures that actually cost money, which share one property: none of them show up in a demo. A payment system that works perfectly until a customer taps twice on a weak signal and gets charged twice. A booking system that works until two people take the last slot in the same second. Whether your product survives those depends on how the pieces fit together, not on whether any one piece is well written, which is exactly why they sail through the demo and surface later with a real customer. That is the ground we covered in The Edge Cases Are the Product.

Worth noting that Amodei said as much in the same breath as the 90% line. His full remark included the caveat that the programmer still has to specify the conditions, the app being made, and “the overall design decision.” That part travels considerably less well than the headline.

5. What this means if you are buying software

None of this argues for hiring a team that refuses to use AI. We use these tools daily. Writing code by hand to prove a point is theatre that bills you for typing.

It argues for changing what you interrogate. If implementation is the cheap part, the thing you are buying is the judgment above it, and there are two questions that surface it fast. They are the ones we set out in Hiring an App Developer, and they are recognisably the same two things the labs test for.

Why is it built this way? Not what it does. A team generating without deciding will describe behaviour instead of giving a reason, and the substitution is obvious inside five minutes once you are listening for it.

Show me what happens when it fails. Pick something specific: the payment times out after the charge but before the confirmation. You are not checking whether they handled every case. You are checking whether the question is familiar or novel.

The economics run opposite to the intuition here. Cheap implementation means more software gets built, faster, with less deliberation per decision, while the cost of a bad structural decision has not fallen at all. It has risen, because you reach the consequences sooner with more stacked on top. That is where the scarcity moved.

The companies that told you coding was solved are, quietly and at considerable expense, still checking whether the person in front of them can think. That is a reasonable standard to hold your development team to as well.