From Prototype to Production: The Gap That LLMs Can't Close

Code that an LLM generates is often locally sensible but globally incoherent. Each function works, but the overall structure is a patchwork. Naming conventions drift. Similar problems are solved in different ways in different places. The architecture (if you can call it that) is whatever emerged from the sequence of prompts.

This matters because code is read far more often than it’s written. When something breaks at 2am, you need to understand the system quickly. When you hire your first engineer, they need to get up to speed. When you want to add a feature, you need to know where it should go.

Code health is an investment in your future self.

Every piece of software depends on other software: frameworks, libraries, databases, operating systems. These dependencies have versions, and those versions change.

One of my clients is running a Ruby application. Ruby 3.4 is current; Ruby 4.0 is on the horizon. Within a year or two, they’ll need to migrate. This is normal — it’s part of running software over time.

But if your dependencies were chosen by an LLM that doesn’t know your specific situation, and you haven’t thought about upgrade paths, that migration becomes a crisis instead of a routine maintenance task.

Good dependency management means:

The chat history with your AI assistant is not documentation.

Documentation serves multiple purposes:

Good documentation doesn’t have to be extensive. A clear README, some architecture notes, runbooks for common operations — often that’s enough. But it has to exist, and it has to be maintained.

Your prototype probably has a database. Questions:

Data is often the most valuable thing a startup has. Losing it, or corrupting it, can be existential.

When your prototype breaks, you probably find out because you tried to use it and it didn’t work. That’s fine for a prototype.

When your production system breaks, you need to find out before your users do. You need to know what broke. You need historical data to understand why it broke.

This means:

This one is less tangible but perhaps most important.

LLMs tend to generate code that is more complex than necessary. They reach for abstractions, add layers of indirection, implement patterns they’ve seen in training data whether or not those patterns fit the problem.

Simplicity is hard. It requires understanding the problem deeply enough to find the minimal solution. It requires resisting the temptation to add things "just in case." It requires the confidence to delete code.

Simple systems are easier to understand, easier to debug, easier to extend, and easier to hand off. Simplicity is a gift to your future self and your future team.

I should be clear: I use LLMs extensively in my own work. They’re remarkable tools and they make me significantly more productive.

But "more productive" isn’t the same as "replaceable."

The value I bring is knowing what to ask, recognising when the answer is subtly wrong, and understanding the context that the model doesn’t have — your business, your users, your constraints, your future. An LLM can generate a database migration. It takes experience to know whether that migration will lock your tables for thirty seconds or thirty minutes in production. An LLM can suggest a monitoring setup. It takes judgement to know which alerts will wake you up for real problems and which will cry wolf until you ignore them.

The craft isn’t going away. It’s just being applied at a different level.