What cheap AI does to the developer's job

This started as a talk with a blunt title: what cheap AI does to the developer's job. The argument underneath it is not really about AI at all. It rests on two ideas that are older than the current models, and once you have them in hand, most of the confusion about coding and AI gets quieter.

The first idea comes from AI research. The second comes from economics. Neither is complicated. Both have been true for a long time, in places that had nothing to do with chatbots. The reason they matter now is that cheap, capable models put them on a collision course with the daily work of building software.

If you are learning to build today, you do not need to predict the future to make good decisions. You need to understand these two ideas well enough to see which of your habits are worth keeping and which were always going to be temporary.

Rich Sutton, a researcher who spent decades in AI, wrote a short essay called The Bitter Lesson. The pattern he noticed: over and over, the methods that win are the ones that lean on raw computation, not the ones built from handcrafted human cleverness. People spend years encoding their knowledge of chess, or language, or vision into careful rules. Then a simpler approach that just uses more compute comes along and beats it.

It is called bitter because it stings. The clever, human-shaped work is the part we are proud of, and it keeps losing to the brute approach that scales. The lesson is not that cleverness is worthless. It is that betting against more compute has been a losing trade for a long time.

For someone building with AI, this has a very practical edge. The clever scaffolding you wrap around a model (the elaborate prompt templates, the hand-tuned rule chains, the rigid pipelines that try to outsmart the model) tends to age badly. The next model is often better than your workaround. So keep your own scaffolding thin. Lean on the model. Build the part that is genuinely yours, and let the model carry the part that compute is already good at.

Thin scaffolding is not laziness. It is a bet that the model underneath you will keep improving, and that the lighter your structure, the more of that improvement you get for free.

The second idea is from a 19th-century economist named William Stanley Jevons. He noticed something odd about coal. When engines got more efficient and used less coal per unit of work, people did not burn less coal. They burned far more. Efficiency made coal cheaper to use, so it got used everywhere, and total demand went up.

That is Jevons Paradox: making something more efficient often raises its total use rather than lowering it. It feels backwards the first time you hear it, and then you start seeing it everywhere.

Now put intelligence in place of coal. The price of GPT-3.5-level intelligence fell from about 20 dollars per million tokens to about 0.07 dollars per million tokens in roughly eighteen months. That is not a discount. That is the floor dropping out. And true to Jevons, we did not use less of it. We used far more. Things that were never worth paying a person to do, or never worth the engineering time, suddenly became cheap enough to just do.

So the cheaper code gets, the more code gets written, generated, and thrown away. Demand for the output goes up, not down. The work does not evaporate. It floods in. The question is what kind of work it becomes.

Put the two ideas together. Compute keeps winning, so the model does more of the typing. Intelligence gets cheap, so we ask for far more of it. The result is that the work does not disappear, it moves up a level. It moves toward specifying what you want, reviewing what comes back, and judging whether it is right. It moves away from typing every line yourself.

This is not the first time a tool has done this to a job. ATMs did it to bank tellers: the machine handled the cash, and the teller's work moved toward the things a machine could not do. Spreadsheets did it to accountants: the formula did the arithmetic, and the accountant moved up to judgment and analysis. Compilers did it to programmers: nobody hand-writes machine code anymore, because the compiler does the tedious translation and the programmer works at a higher level.

In none of those cases did the tool simply delete the job. Each time, it moved the job up a level. The boring, mechanical part got automated, and the part that needed a human moved to where the human was still needed. Cheap AI is the same shape of change, pointed at writing code.

If that pattern holds, the fear that the job vanishes is aimed at the wrong thing. The typing was never the job. The typing was the cost of doing the job.

Here is the useful part if you are learning today. The skills that hold their value are the ones the model cannot do for you, and they are exactly the ones the historical pattern points at.

First, describing what you want clearly. A model will build what you ask for, which means a vague ask gets you a vague result. Being precise about the goal, the constraints, and what done looks like is now a core skill, not a soft one. Second, reviewing what the model produces. Cheap generation means a flood of output, and someone has to read it with a careful eye and catch what is wrong. Third, judging whether it is right. Not whether it runs, whether it is actually correct and actually what was needed. That judgment is the part that stays yours.

And carry the Bitter Lesson into how you build: keep your own scaffolding thin and lean on the model. Do not spend your energy building elaborate structure around the model that the next version will make pointless. Spend it on the parts that are genuinely yours, the specifying, the reviewing, the judging.

None of this requires you to be an economist or to predict where the models go next. It asks something simpler. Learn to say clearly what you want, learn to check what you get, and learn to tell whether it is right. Those skills were valuable before cheap AI. They are just more of the job now.