Sorry, your AI is only as good as you

Every AI coding demo looks the same. Two sentences of prompt, thirty seconds of streaming text, and a working app appears. The audience is impressed — and to be fair, the demo is real. I've lived one myself. The first prototype of my medical voice-dictation product — local-first speech recognition for Polish doctors, noise suppression, a working UI — came together astonishingly fast. Roughly a weekend of prompting.

Then I spent months turning that demo into a product. It is still teaching me lessons. And somewhere along the way I wrote down a sentence I keep coming back to: your AI is only as good as you.

That sounds like a criticism of the models. It isn't. It's a criticism of the mental model most of us bring to the table.

The vending machine fallacy

The popular picture of AI-assisted development is a vending machine: insert prompt, receive software. It works beautifully for demos and collapses the moment you need a product, for one simple reason: you cannot compress a product into a prompt.

However hard you try, there will always be assumptions. Which error states matter. What "fast enough" means. Whether that config value can change at runtime. How the new module should relate to the three that already exist. You can't enumerate all of it up front — partly because it's too much, and partly because you don't know all of it yet either.

An AI model, faced with a gap, does not stop and raise a blocker. It fills the gap with something statistically plausible. Multiply that by a few hundred small decisions and you get software that works — in a way known only to the model.

A better mental model: you just hired a team

Here is the frame that actually changed how I work: treat the AI not as a tool, but as a development team that just showed up at your virtual office. Absurdly fast, never tired, broadly read, surprisingly skilled. But still — a team.

And every engineering lead knows the uncomfortable truth about teams: unless you've somehow hired a group of supernaturals, the team's output can only be as good as your input. Even excellent engineers, with the best intentions, cannot read your mind. What they need is exactly what an AI needs.

Requirements — functional and non-functional. Nobody writes "must be debuggable" or "must degrade gracefully when the network drops" into a two-line prompt, and then everybody is surprised that the result is neither. The non-functional ones are the first casualties, because they are invisible in a demo and painfully visible in production.

Context. What already exists, what to reuse, what must not be touched, which conventions the codebase follows. A new hire who starts committing on day one without reading the repo produces exactly the kind of mess you'd expect. So does a model.

Constraints and hints. Where the traps are. Which trade-off matters here and which doesn't. Which use cases are real and which are imaginary. "Keep it simple, we don't need multi-tenancy" is one sentence that saves a week of speculative architecture — and a lot of duplication and accidental complexity.

Attendance. This is the part people skip. A real lead answers the team's questions, asks their own, challenges a suspicious design, discusses the pros and cons, sometimes throws in the missing idea. AI-assisted development is the same loop, just compressed from weeks to minutes. Modern systems are genuinely complex; intuition alone will not carry anyone through the trade-offs — not a human team, and not an agent.

Skip all of that and an unattended team will still produce something. Something compiles. Something demos well. But UX, predictability, debuggability, ease of maintenance, documentation — those don't happen by accident in human teams, and they don't happen by accident with AI either.

Verification is where the product is made

Even with great input, you don't ship a team's work unread. You review it. The same applies here, and it's not bureaucracy — it's the actual job. The model does not know your definition of done. It doesn't feel the difference between "passes the happy path" and "I'd bet my invoice on it."

So you read the diff. You question the abstraction that appeared out of nowhere. You ask why a dependency was added and whether the retry logic actually retries. And when something smells wrong, you say so — because, much like a good team, the model usually fixes things quickly once it's told what is wrong, not just that something is.

Skip verification, and you're not shipping your product. You're shipping the model's assumptions with your name on them.

The ceiling

And now the loop closes, because these two threads — "treat it like a team" and "it's only as good as you" — are really one thought:

You can't specify what you don't understand. You can't verify what you can't judge.

If non-functional requirements aren't part of your vocabulary, they won't be part of your prompt. If you can't smell a bad abstraction, you'll approve it. If you've never debugged a production incident at 3 a.m., you won't know why observability belongs in the instructions. The model will follow you off any cliff — confidently, in fluent prose.

Agents don't work on their own. They don't invent on their own. They don't innovate on their own. At minimum, they need a prompt — and that prompt is an instruction to a development team, polished only as well as you can polish it. It carries everything you know. It also carries everything you don't.

That's why AI is not a replacement for engineering judgment. It's a multiplier of it. Multiply solid architecture instincts, clear requirements, and a habit of honest review, and the throughput is genuinely remarkable — I would not have built my product solo without it. Multiply zero…

Well. The math does the rest.