AI writes bad, insecure code? It writes exactly the code you ask for
You know the takes from LinkedIn and the pub alike: "AI generates low-quality code." "It's a security time bomb." "Nobody will be able to maintain it in two years." And the obligatory punchline: a real programmer would never let AI near production code.
We have hundreds of hours of AI-assisted production development behind us — and this article is the answer we give the skeptics. Not because the criticism is entirely wrong. But because it aims at the wrong target.
Where the skeptics are right
Let's start honestly, because without this the whole text would be just another fanboy piece.
Yes — if you let AI generate code with no brief, no context and no oversight, the result will be mediocre to dangerous. Studies about vulnerabilities in AI-generated code exist and aren't made up. "Vibe coding" — someone with no development background clicking together a whole app and deploying the output straight away — produces exactly the disasters that circulate on social media: SQL injection, API keys in the code, zero input validation, zero tests.
But here's the important question: whose failure is that?
If you tell a junior developer "build me a login" without a single word about security, with no code review and no tests, and they deliver a form storing passwords in plaintext — is that the junior's failure, or yours? What if you do the same with an outsourced agency? What if you do the same with AI?
The tool changed. The rules of the craft didn't.
AI writes the code you ask for
Here is the thesis of this whole article: AI doesn't generate bad code. It generates code exactly matching the quality of the brief and the process around it.
A prompt is a specification. And specifications obey the same law they've obeyed for fifty years of software engineering: vague brief → random result. The only difference is that AI delivers that random result in thirty seconds instead of two weeks, so a broken process shows up faster and more visibly.
Concretely: write "make an endpoint for file uploads" and you'll get an endpoint for file uploads. You asked for nothing more. Write "make an endpoint for file uploads — validate type and size, store outside the webroot under a random name, add rate limiting consistent with our other endpoints, and write tests" and you'll get exactly that. Try it. The difference isn't in the model — it's in the brief.
- ✗A one-line prompt with no project context
- ✗Security and maintainability never mentioned
- ✗Output copy-pasted and deployed straight away
- ✗No tests, no review, no static analysis
- ✗One giant prompt for the whole app at once
- ✓AI knows the project rules: conventions, architecture, forbidden patterns
- ✓Security, performance and maintainability are an explicit part of the brief
- ✓Every output goes through code review — machine and human
- ✓Tests, lint and typecheck run automatically; failures send the work back
- ✓Work is split into small, verifiable steps
The four pillars that make the difference
1. Explicit briefs
AI doesn't know you care about security until you tell it — just like no contractor before it did. Professional AI work means having standards written down and enforced: which conventions the project uses, what is forbidden (string-built SQL, secrets in code, unvetted dependencies), what every change must include (tests, error handling, documentation). Write it once, enforce it every time. We call these project rules, and the AI reads them before every task.
2. Orchestration
No sane person assigns a human "write the whole e-shop" in a single e-mail. It's the same with AI. Big work gets split into small, independently verifiable steps; each step has a clear input, output and definition of done. For more complex jobs we deploy multiple AI agents in different roles — one writes, another plays the adversary and hunts for holes, a third verifies nothing broke. Sounds like sci-fi, but it's just good old division of labour and the four-eyes principle, only faster.
3. Verification
This is where the haters ironically describe our actual workflow while believing it doesn't exist. No AI output reaches production unverified. Code review, static analysis, type checking, lint, build. If any of it fails, the work goes back. And AI happens to be a brutally effective reviewer of its own output — give it the review as a separate task with fresh eyes and it finds bugs that would slip past many a human review.
4. Testing
Code without tests was a bad idea before AI and it's a bad idea with it — except now it's cheap to fix, because AI writes tests willingly and well. Our rule: a feature without a test doesn't exist, and before deployment the change gets actually run and clicked through, not just "it compiled". We wrote a whole article about what happens when testing gets skipped — and AI changed nothing about it.
"But I've seen AI code and it was terrible"
I believe you. So have we — we've seen terrible code from AI, from agencies, from seniors with twenty years of experience, and from ourselves. Terrible code wasn't invented in 2023.
What matters is what surrounded that code. Almost every time someone shows us a horrifying AI example, everything above is missing: the brief was one sentence, security was never mentioned, no review happened, tests don't exist. That's not evidence that AI can't write code. That's evidence that a broken process produces broken results regardless of who types the letters.
And one more uncomfortable truth for both sides: AI is an amplifier. For a good team with a solid process, it dramatically raises speed and quality — more time is left for architecture, edge cases and tests, because mechanical typing got cheap. For a team without a process, it accelerates the production of technical debt. AI doesn't choose the direction of amplification. That's your job.
A checklist for a fair argument
Next time someone tells you AI writes dangerous, unmaintainable code, ask them:
- Did the brief say a word about security, performance or project conventions?
- Did the AI have the project context and its rules?
- Did the output go through code review — human or at least machine?
- Do tests exist, and did anyone run them?
- Did anyone verify the behaviour at runtime, not just "it compiled"?
Five questions. If the answer is "no" five times, the argument isn't about AI quality — it's about process quality. And if the answer is "yes" five times and the result is still bad, we'd genuinely love to hear about that case, because we see those rarely.
By the way — the website you're reading this article on was largely built with AI. Under human direction, with project rules, code review, type checking and tests before every deployment. Judge the quality yourself: it's fast, secure, and ships every week.
Conclusion: the craft didn't change, it got cheaper
History repeats. The same debates raged about compilers ("real programmers write assembly"), open source libraries ("you can't trust someone else's code") and the cloud ("our data outside our server, never"). Every time, the winner was whoever learned to use the new leverage with discipline — not the one who ignored it, nor the one who used it blindly.
AI in development is exactly there today. It is not a replacement for engineering thinking. It is its multiplier — and you set the sign.
At Reactive Studio we build production apps with AI for a monthly subscription — using the process described above. Curious what it would look like for your project? Book a consultation or get a price estimate in two minutes.
