LLMs in everyday development — where they help and where they get in the way

Writing about language models in development tends to come in two extremes: either "programmers won't be needed soon" or "a useless toy that invents functions." Both are far from what I see in practice.

The site you're reading was built in partnership with a language model: a custom PHP engine, an admin panel, analytics, structured data for search engines. The experience was instructive — partly because a lot of it went fast, and partly because the mistakes were real. I want to describe both sides.

Where the win is obvious

A first draft of anything. The empty file is the most expensive part of a task. A model closes that gap in a minute: a class skeleton, a config structure, a regex, an SQL query. After that you're editing rather than inventing. The speedup isn't tenfold, but it's consistent.

Unfamiliar syntax and forgotten details. The exact .htaccess format, rsync flags, how to do something in this PHP version that a newer one handles in one line. That used to be twenty minutes of documentation and forum posts; now it's one question.

Working with someone else's code. Explaining what an unfamiliar function does, how two similar blocks differ, what breaks if you remove a line. Here a model replaces not a programmer, but a long careful read.

Repetitive work at volume. Translating an interface into a second language, laying text into templates, bringing twenty similar files to the same shape. Boring work where mistakes are easy and verification is simple.

The pattern: models are strong where breadth is needed and the result is easy to check.

Where the problems start

A confident tone while being wrong. This is the main trap. A wrong answer looks exactly like a right one — same calm tone, same tidy reasoning. A person who doesn't know something usually signals it somehow. A model doesn't.

Facts that sound plausible. While working on this site I needed to find information about a person from public sources. The results included a striking headline that fit the meaning perfectly — and belonged to an entirely different person. If that "fact" hadn't been checked, it would have gone straight onto the About page.

The rule here is simple: anything that could be confused with someone else gets verified separately. Especially people, dates, numbers and quotes.

No knowledge of your system. The model doesn't know this server runs an old PHP version, that the hosting config has a non-obvious setting enabled, that a particular directory must not be touched. It will offer a solution that's right on average — and wrong here.

Mistakes born of confidence in action. During a deploy of this blog there was a moment when a local development config overwrote the production one. For a second the site pointed at 127.0.0.1 instead of its own domain. It was caught immediately because a verification step ran after the deploy — but without that step, everything would have looked "successful."

That's perhaps the key conclusion about AI in infrastructure: what matters isn't so much what it can do, as what happens when it's wrong.

The rule that works best

I've reduced it all to one principle: trust exactly as far as verification is cheap.

• Code you can run and see the result of is verified instantly. Move fast here.
• Code that touches data, money or production — only after explicit checks, ideally with a backup first.
• Facts about the real world — always through a source. No exceptions.

From that follows a practical habit that raised the quality of the work noticeably: ask not only for the solution, but for a way to check it. Not "write a function", but "write a function and the command that will show me immediately that it works." Half the errors fall out at that step.

What changed in the process itself

A noticeable shift: the centre of gravity of the work moved. The bulk of the time used to go into writing code, with review being short. Now it's the reverse — a draft appears quickly, and the real work is reading it, understanding it, and deciding what to keep.

That takes a different kind of discipline. The temptation of "looks right, ship it" is strong, especially when the code is neatly formatted and thoroughly commented. But tidy formatting says nothing about correctness — which is probably the most treacherous property of working with models.

And one more thing: you're still the one accountable. Nobody cares who wrote the line that took production down. So code you don't understand can't be passed on, regardless of who composed it.

Whose job does it replace

My experience says this: a model does well what you know how to verify. If you understand the domain, it accelerates you sharply. If you don't, it accelerates the production of code you can't evaluate — which isn't a benefit but a deferred problem.

So the question "will AI replace developers" strikes me as badly framed. Closer to reality is this: the balance of skills is shifting. Writing code is getting cheaper; understanding it, verifying it and answering for it is getting more expensive.

Which, honestly, was always the core of the profession. It's just more visible now.