coding in the LLM era

LLMs did not make programming disappear. They made programming stranger.

The work now has two layers running at the same time. There is still the ordinary work of understanding a system: reading code, noticing constraints, deciding what should change, testing the result, and accepting responsibility for whatever ships. But next to that, there is a new conversational layer, where some of the typing, searching, and first-pass synthesis can be delegated to a model.

That delegation is useful. It is also easy to misunderstand. An LLM can produce code faster than I can type it, but speed is not the same thing as direction. If I do not know what I want, the model usually gives me something plausible. Plausible is dangerous because it looks finished before it has earned trust.

The best use of LLMs in coding is not asking them to be the programmer. It is asking them to be an accelerant for specific pieces of the programming process. Summarize this file. Find where this behavior is implemented. Sketch three approaches. Write the boring adapter. Explain this test failure. Refactor this small, bounded thing. Check whether this assumption is contradicted elsewhere in the codebase.

Those are good requests because they keep ownership with the developer. The model can move quickly inside a frame, but the frame still has to come from someone who understands the product, the architecture, and the cost of being wrong.

The funny part is that LLM coding feels most powerful when it is least magical. The small chores are where the tool shines: renaming things consistently, filling in repetitive tests, translating an API shape into another one, writing a first draft of documentation, or producing a quick local script that will be deleted after it answers one question.

The dangerous part is the same as with every abstraction. The more the tool can do, the easier it is to stop looking. That is where code review gets harder, not easier. A patch generated in seconds can still take serious time to understand. The cost moves from production to verification.

This changes the developer’s job, but not in the way the hype suggests. It rewards sharper taste, clearer intent, and better decomposition. Vague prompts produce vague work. Precise prompts require precise thinking. The model can multiply the effect of good judgment, but it can also multiply confusion.

So coding in the LLM era is not about replacing understanding with generation. It is about learning where generation helps, where it hides mistakes, and where the old discipline still matters. Especially there.