You Can't Prompt Your Way to Quality

Something has shifted recently. At meetups and conferences, the conversations around AI are more sober than they were a year ago. Fewer people claim that engineering is done. More people are asking what these tools are good at and where the limits are. That's a change in tone I welcome.

LLMs are useful for coding. I use them daily and they help me move faster, explore ideas and get through boilerplate that would otherwise slow me down. I am not here to argue against that.

While the louder version of “engineering is dead” may be fading, the quieter version is still everywhere. The idea that anyone can now “just prompt” their way to production-quality software misunderstands what building software actually is.

Two Trajectories

There are two trajectories I keep seeing and they diverge fast.

Without discipline, this is what happens when you generate code without understanding what you're generating. It starts at whatever quality level the LLM gives you, which can be surprisingly decent. Then it drops. Quickly. Every prompt adds more code that nobody fully understands. Inconsistencies pile up. Small decisions that seem fine in isolation create structural problems that compound. The code works until it doesn't, and when it breaks, nobody knows why.

With discipline, the trajectory looks different. It stays roughly where it started, maybe dips here and there, but trends upward over time. The people on this trajectory do something that prompting alone cannot accomplish. They tend to the codebase. They refactor. They question. They notice when something is off and fix it before it becomes a problem. They understand what the LLM gave them before they accept it. That work also helps the LLM. A well-structured codebase gives it better context, so the output improves. That makes the next round of work easier.

Death by a Thousand Prompts

I don't have one dramatic project failure to point to. What I have is over a year of daily LLM-assisted development and the patterns that kept showing up.

A function that works but whose name doesn't match the language the team uses for that concept. An abstraction the LLM introduced that nobody asked for, solving a problem you don't have. A test that passes but tests the implementation rather than the behaviour. Three different files solving the same problem in three different ways because each was generated in a separate conversation.

None of these are catastrophic on their own. That's the point. It's the accumulation that creates the first trajectory. Each one is small enough to ignore and each one makes the next problem slightly harder to see.

The people on the second trajectory catch these things. Not because they're smarter, but because they know what to look for and they are paying attention.

The Work That Prompts Can't Do

Quality is not a state you reach. It's a practice. It requires someone who notices that a module is doing too many things. Someone who sees that the naming is inconsistent and fixes it before it becomes too hard to change. Someone who understands the domain well enough to know that the LLM's plausible-sounding answer is wrong.

None of this comes from better prompts. It comes from experience, taste and the discipline to care about things that don't show up in a demo.

An LLM can generate a working solution in seconds. But “working” and “good” are not the same thing. The difference between the two is engineering.

A Tool, Not a Replacement

LLMs amplify what you already have, and that goes both ways.

If you bring engineering discipline, they amplify that. You move faster without cutting corners. You use the time you saved on boilerplate to think more carefully about design.

If you bring inexperience or indifference toward quality, they amplify that too. You produce more code, faster, with more problems baked in. The speed feels productive, but it is not.

The claim that “anyone can code now”, while true, confuses producing code with building software. Understanding the problem, making trade-offs, maintaining a system over time, communicating intent through structure. That's where the work is. LLMs don't do that for you. They can help, but the judgment has to come from somewhere.

If you use LLMs but question and reshape what they give you, you are doing engineering. The LLM is a tool in that process and a good one.

If you're using LLMs and accepting whatever comes out because it passes the tests or looks right, you know which trajectory is waiting for you.