Experience Is Not Prompt Engineering

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 don't make judgment calls based on:

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.

Subtleties of human-software interaction. 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 domain empathy, not logic.

Vision based on the unwritten future plan. Knowing that this 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. LLMs optimize for the current context. Humans optimize for the trajectory.

The horizontal and vertical landscape. An LLM working on the Work Order controller doesn't know that the Material Request 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.

The Force Multiplier Metaphor (Precisely)

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. This is not a "vibe coding" story. This is to be expected for anyone who wants to try setting 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.

The Silver Lining: "Good Enough" Across Everything

Here's where it gets interesting for small teams. Claude is 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.
• CI pipelines and deployment orchestration? Done.
• Security overview and analysis? Covered.
• Flutter mobile app with Riverpod state management? Built it.
• Tailwind CSS design system with dark mode? Handled.
• Docker Compose with Ory SSO, Prometheus, Caddy? Set up.
• Production monitoring and structured logging? Configured.

The point is not that Claude does any of these perfectly. The point is that it does 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. 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.