The Case For AI, Made Properly

This is the second side of a three-part argument. The first side, the case against, is real and I made it as hard as I could. This one came out stronger, and I want to show you why rather than just assert it. What I actually think, having built both, is here.

Most defenses of AI are bad, and they are bad in the same way. They lead with productivity. It writes your boilerplate, it drafts your email, it saves you twenty minutes, look how fast. That argument loses, and it should, because the other side can always point to the study where the experienced developers got slower, and to the code that decayed, and to the mind that atrophied. If the whole case for AI is a stopwatch, the case for AI is fragile.

The real case is older and much larger, and it has nothing to do with saving twenty minutes. It is this: removing human effort from work is the single most reliable form of progress our species has, we have done it over and over for centuries, it has terrified people every single time, and they have been wrong every single time in the same way. AI is the next instance of the oldest good move we know how to make.

Start with where the gains are actually real

Be specific, because vagueness is where this argument usually goes soft.

In controlled studies, developers given AI on well-scoped, from-scratch tasks finish dramatically faster, in one well-known trial around fifty-five percent faster on building a server from nothing. The enterprise field studies cluster lower but still solidly positive, in the thirty to fifty percent range for the right kind of work. These are not vibes. They are measured, repeated, and large.

Now hold that next to the famous result on the other side, the one where experienced developers got nineteen percent slower. People treat these as a contradiction. They are not. They are a map. The slowdown happened to senior engineers doing deep work in mature codebases they already held entirely in their heads, which is the one situation where there was no effort left to remove, only context to re-explain to a machine that did not have it. The speedups happen on greenfield work, on unfamiliar territory, on the vast middle of ordinary tasks. The two findings together do not say AI is good or bad. They draw a line. On one side of the line the effort being removed was real waste, and the tool is a rocket. On the other side the effort was the thinking itself, and the tool is a drag. That line is the whole story, and I will come back to it.

It lifts the person with less, not the person with more

Here is the part the productivity framing buries, and it is the strongest single thing you can say for AI.

Across study after study, the people who gain the most are the ones with the least. Less experienced developers, lower-tenure workers, people earlier on the curve: they get the biggest lift, consistently, while the experts gain little or sometimes lose. This is the opposite of how most powerful tools work. Most leverage compounds advantage; the people who already have the most get the most out of it. AI, at least at this stage, does the reverse. It is most valuable to the person standing at the bottom of the cliff, looking up at a wall of syntax and convention and accumulated jargon that used to take years to scale.

Take that seriously and the moral weight of the argument flips. The friction AI removes is, disproportionately, the toll booth that kept people out. The hours you spent memorizing the incantations, fighting the environment, learning which of forty ways to do a thing was the blessed one: that was never the work. It was the hazing. It was the cost of admission that happened to be highest for the people with the least time and money and prior access. A tool that lowers that toll is not a convenience. It is a widening of the door.

The ladder is seventy years long and points one way

Now zoom out, because this has all happened before, and the pattern is almost embarrassingly clear.

Programming began as physically rewiring machines, then as machine code, raw numbers a human had to think in. Then assembly let you use names instead of numbers, and the people who thought in raw numbers said the names would make programmers soft and stupid. Then compilers let you write something close to human language and threw away the assembly for you, and the assembly programmers said the same thing: real programmers control the machine, this abstraction will rot the craft. Then high-level languages, then libraries you did not write, then garbage collection that managed memory so you did not have to, then no-code tools, then the cloud. Every rung removed a layer of effort that the previous generation considered essential to the discipline. Every rung drew the identical objection: you are removing the struggle that makes a real practitioner, and you will get a generation that cannot do the fundamentals.

And every time, the objection was true in the small and wrong in the large. Yes, most working programmers today cannot hand-allocate registers, and a few of them probably should be able to. But the abstraction did not destroy the field. It moved the floor of effort up to a more valuable layer. Nobody mourns the lost art of manual memory management as a tragedy for human capability. We took the attention that used to go into the drudgery and spent it on harder, higher things, and the field got bigger and better and more open every single time.

The calculator is the cleanest case. It did not end mathematics or rot the mathematical mind. It ended arithmetic drudgery and freed a generation to spend its attention on structure and proof and modeling, the parts that were actually mathematics. The fear was real and specific and it simply did not come true. AI is plausibly that move, the calculator move, for a sprawling class of cognitive work that has never had its calculator before.

The harms are contingent, and contingent harms get fixed

The case against leans hard on real damage: decayed code, homogenized writing, juniors who do not learn. Take each one seriously and notice the same property in all of them. None is a law of the tool. Each is a way of using it badly that we already know how to use better.

Homogenization is the clearest. The studies that find AI flattening creativity also find the flattening disappears, and sometimes reverses into more diversity than the human baseline, the moment people use varied prompts and varied models instead of all leaning on the same default. The sameness was not the AI. It was everyone using it the laziest possible way. Junior developers have the same answer arriving: the smarter firms are rebuilding the apprenticeship around the tool, having new engineers spend months reviewing AI output, writing the tests, pairing on the design, learning judgment instead of typing. The decayed code is a discipline problem, and we have a long history of inventing the discipline a powerful tool demands after we get the tool, not before.

Contingent harms are the kind that engineering removes. Intrinsic gains, the lifted newcomer, the removed toll, the freed attention, are the kind that bank. Betting against a tool because its first-draft misuse is ugly is betting against every transformative technology in history at exactly the wrong moment.

The crack in my own case

An honest version has to find its own weak point, so here is mine.

My whole argument rests on one claim: the effort AI removes was never building anyone, the way arithmetic and register allocation were never the real work. The compiler removed drudgery and left the thinking. But that is precisely the thing AI might not do. Every prior rung on the ladder automated the mechanical layer beneath the thought and left the thought alone. AI is the first tool that offers to do the thinking itself, the design, the judgment, the sentence you had not yet figured out how to write. If it only ever removed the arithmetic of knowledge work, my case would be airtight. The honest worry is that it does not stop there, and that it cannot tell the difference between the drudgery and the thought, and that it will hand you both with the same cheerful confidence.

So I have proven less than it sounds like. I have proven that removing effort is usually progress, and that this tool removes a great deal of effort that was pure toll and pure waste. What I have not proven is that it only removes that. The other side is making the same bet from the opposite end, and both of us are really arguing about one thing, friction, and which kind of it is on the table. I had to build this case at full strength to see that winning it was not the point. The point was the line I kept drawing and stepping over: the line between the effort that was building you and the effort that was only ever in your way.