I wrote code with an LLM this morning before I finished my first cup of coffee. It scaffolded a chunk of a feature, I caught two things it got wrong, I kept the parts that were right, and I moved on. That is a normal Monday now. I have used these tools nearly every working day for the better part of two years, and I would not want to give them up.

So understand that when I say the hype drives me nuts, I am not standing on the outside throwing rocks. I am a heavy, happy user. That is exactly why the noise bothers me.

George Hotz wrote a piece last week that named the thing better than I had managed to. He points at two flavors of hype pulling in opposite directions. One is fear: the window is closing, you are falling behind, adapt now or get left. The other is grandiosity: this changes everything, the models are about to run the whole show. Both are loud. Both are designed to make you feel something. And the funny part is that the people selling you the panic and the people selling you the utopia are often the same people.

Here is what neither version tells you, because it does not sell: the useful part of this technology is quiet, unglamorous, and completely dependent on a person who knows what they are doing.

What the tools are actually good at

I can tell you exactly where LLMs earn their keep in my week, because I watch it happen.

They are excellent at first drafts. Give me a rough shape and they fill it in fast. They are good at the boring middle of a task, the wiring and the boilerplate that I have written a hundred times and take no joy in writing a hundred and first. They are genuinely helpful when I step into an unfamiliar library and need to get oriented without reading the whole manual first. On a good run, they compress an afternoon into an hour.

None of that is nothing. Compressing an afternoon into an hour, several times a week, is a real change in how much one person can do. I have written before about how AI shifts the math on team size, and I stand by it.

But notice what all of those wins have in common. Every one of them starts with me deciding what is worth building, and ends with me reading what came back. The tool is in the middle. The judgment is on both ends.

What they are quietly bad at

The models are bad at the two things that matter most, and they are bad at them in a way that hides.

They cannot tell you what is worth building. Ask for a feature and you get a feature, whether or not that feature should exist. The model has no stake in your business and no opinion about whether you are solving the right problem. That part is still yours, and it is the part that actually determines whether the software is worth anything.

And they are bad at knowing when working code is a trap. This is the one that gets people. The code runs. The demo works. Everyone claps. And underneath it is a structure that will fall over the first time real traffic or a real edge case shows up, because the model optimized for "produces output that looks right now," not "holds up in eighteen months." Working is not the same as sound. It never was, and a confident autocomplete does not change that.

The risk nobody puts on the slide

Which brings me to the part that should actually keep a business owner up at night, and it is not "the AI wrote a bug." Bugs are findable. Bugs are fixable. The real risk is subtler.

There is a good thread going around that gets at it: when you let the machine do the understanding for you, you stop understanding the system yourself. You paste, it works, you ship, you move on. Do that for six months and you own a pile of software that runs and that nobody on your team can actually explain. Not because a person left. Because no person ever held it in their head in the first place.

I wrote about the version of this where the one person who understood your software walks out the door. The AI version is worse, because there was never a door. There was never a moment where a human carried the whole thing. You skipped straight to the part where it is a black box, and you did it on purpose, and it felt like speed.

That is the bill the hype does not mention. The panic crowd will not tell you because they want you moving fast and scared. The utopia crowd will not tell you because in their story the understanding does not matter, the machine has it. It does not. Not yet, and not in a form you can put on a payroll or hand to the next developer.

So what do you actually do with this

You use the tools. Hard. I do. But you treat their output the way you would treat a fast, bright, slightly overconfident junior developer's first draft: useful, occasionally wrong in ways that sound completely certain, and never merged into anything that matters without a person who knows the codebase reading every line.

The judgment is the product. It always was. The model just made the drafting cheap, which means the drafting was never the valuable part, which means paying for "someone who can generate code" was always a strange thing to value. What you are actually paying for is someone who knows which code should exist and can tell when the working demo is quietly lying to you.

That is the whole reason I still like this work, and it is how we run AI-assisted builds here. We lean on these tools every day, and the thing we hand a client is software they can actually own: something a person understood well enough to explain, to maintain, to change next year without praying. We have written about what that looks like when the tools are in expert hands, and the short version is that expert hands are not optional. They are the point.

The hype will keep swinging between "you are doomed" and "you are saved." Ignore both. The boring middle is where the real gains are, and the boring middle has a person in it. It has to.