LLMs can't replace experience

This section is the philosophical core. It will resonate most with experienced developers and challenge the "AI replaces developers" narrative.

The things LLMs can't do

Knowledge, experience, and guiding principles that sit above any specific tool use. LLMs can't relay experience. They are also quite sycopanthic and often times much too agreeable. I find myself often telling the model to behave in a certain, let's call it adversarial, way towards my quries and assumptions. This is the proper way to work, in my opinion, because it gets you closer to the back-and-forth experience of working with other engineers who have different ideas or views on how to approach the problem. It doesn't really matter who found the best approach, but what does matter is the resistance which forces your brain to re-analyze, think it over again and have a holistic view. Ultimately, the decisions made will be imperfect, but at least well understood, which is plenty.

What LLMs are typically bad at:

Taste. "This form has too many fields for the user's actual workflow" isn't something an LLM notices. A human looking at the built UI spots it immediately. The difference between a functional interface and a good interface is entirely in these micro-judgments: which fields to group, which to hide behind an "Advanced" toggle, which to remove entirely because nobody uses them. Sometimes even re-writing the whole damned thing because it just became this unusable monstrosity that no one under the sun will understand.

Subtleties of human-software interaction. And by "subtletlies" what we really mean is annoyances. The difference between "technically correct" and "a user will actually understand this" is entirely human judgment. An LLM will generate a status transition diagram that is logically complete. A human will look at it and say "users will never understand why they can't go from 'in progress' back to 'new' - we need to allow it even though it's technically a regression." That's empathy towards the human being who is supposed to click and use the process, not a logical problem that can be number-crunched. We seek to reduce annoyance, at the cost of being "technically correct and logical".

Vision based on the unwritten future plan. I mean, sometimes even we aren't super clear on the end-goal. Knowing specific details that are irrelevant now, but might be super important in the not-so-distant future is hard to sometimes impossible to put into words or codify at all. But it's a steering wheel that is in the back of your mind and requires a gentle approach. This is not solvable by brute-forcing the problem with a logic-first approach. Having a hunch that a specific entity will eventually need to support multi-warehouse scoping, even though the current spec doesn't mention it, because you've seen three similar systems evolve that way - that is a future problem that fits into large scale thinking. When implementing, LLMs will optimize for the current context but we have to optimize for the trajectory.

The horizontal and vertical landscape. Expanding on the previous point, but it directly affects the architectural decisions: an LLM working on a specific controller doesn't know that a specific process spec is about to change, or that the mobile app needs the API shape to look a certain way for an upcoming feature. It doesn't hold the full picture of what's being built, what's planned, and how the pieces connect across time. So guiding it as the system evolves is incredibly important.

The force multiplier metaphor

LLMs are force multipliers:

• Sometimes incredibly good - doing the right thing right away, one shot
• More often, they add speed but lack good judgment
• They lack overview of the entire system being built
• They miss details that a human looking at the result immediately spots

There is no lack of effort and attention needed to oversee LLMs and their work. Our's is not a "vibe coding" story, it's a genuine approach at serious engineering, just on steroids. Expect to use up copious amounts of energy when you're trying to set up a project of the magnitude we did.

The multiplier metaphor is precise: force times multiplier. If the force is zero: no domain knowledge, no engineering judgment, no taste - the multiplier produces zero. A senior developer with AI ships faster than a junior developer with AI, not because they prompt better, but because they know what to ask for and can tell when the answer is wrong. Also understand that if the approach or assumptions are wrong, you WILL multiply bad times worse and get the expected result. Be careful, it's never fun reversing and cleaning it up, even with model-assisted development.

The silver lining: "Good enough" across everything

Here's where it gets interesting for small teams. LLMs are at a pretty decent level of knowledge across all the diverse areas that we are, by no means, experts at. For some of those areas, we're barely beginners. But we got the work done.

• Need to write hundreds automated E2E tests? No problem. We'll revise and improve later.
• Need a beautiful and functional frontend across many Razor views? Can do.
• Tailwind CSS design system with dark mode? Handled.
• CI pipelines and deployment orchestration? Done.
• Security overview and analysis? Covered.
• Flutter mobile app with Riverpod state management? Built it.
• Docker Compose with Ory SSO, Prometheus, reverse proxy? Set up.
• Production monitoring and structured logging? Configured.

The point is not that LLMs do any of these perfectly. The point is that they do them well enough that two people can cover the surface area of a 5-7 person team. And "well enough" becomes "good" when you layer on proper engineering practices and correct the mistakes as they pop up.

What previously required a team of specialists: product owner, business analyst, QA (manual and automation), frontend and backend developers, DevOps engineer - is now handled by a 2-person boutique studio, at a pace that is impossible to follow manually.

The result

The result is more than adequate for what we set out to do. Not perfect, adequate, good enough. And having an adequate system in a production ERP means: it works, it's secure enough, it handles the edge cases that matter, it's maintainable, and real users can use it without calling support every day. That's a high bar, and we're clearing it.