The shouting match

#

If you spend any time where developers gather online, you’ve seen the two camps.

One side says AI-generated code is garbage — that anyone using it is a fraud, that the industry is drowning in slop, and that real engineers write everything by hand like it’s 2009.

The other side says you never need to learn anything again. Just describe your dream app, and the machine delivers. Programming is dead. Ship it.

Both camps are loud. Both are wrong. And both are missing the actually interesting question: what does it take to use this tool well?

I want to write down where I’ve landed, because I don’t just have opinions here — most of what runs on this domain was built with AI in the loop.

What I actually do

#

This site’s admin console. Large parts of the Ethica suite. Half the automation glue in my homelab. All of it was built with an AI assistant doing a serious share of the typing.

But here’s what that looks like in practice, because it’s not “I asked for an app and went to make coffee”:

• I describe what I want built — and why, and what it must not do.
• The AI writes code. I read it. All of it.
• I push back. “Why is this endpoint unauthenticated?” “That query is doing N+1.” “We already have a helper for this.”
• Everything goes through Git. Everything deploys through CI. Nothing gets hand-copied onto a server at midnight.
• When it breaks — and it does break — I’m the one debugging it, so I’d better understand it.

The AI types faster than I ever will. It remembers flag syntax I refuse to memorize. It’s genuinely good.

What it doesn’t do is think instead of me. Every architectural decision, every “wait, that’s not safe”, every “this belongs behind the reverse proxy, not on a public port” — that’s still my job. The tool changed how fast I work. It didn’t change what I’m responsible for.

The person who just asks

#

Here’s where I understand the critics, because there’s a version of this that genuinely worries me.

Someone with no technical background asks an AI to build them a booking system for their small business. And the AI does it! It runs. The demo looks great. They put it on the internet.

That’s the moment the trouble starts, because “it runs” is the lowest bar software can clear.

The app works in the same way a house of cards is technically a structure. It stands — as long as nobody touches it, nobody leans on it, and nobody wants it to fall. The person who built it can’t tell the difference between “works” and “safe”, because evaluating the difference requires exactly the understanding they skipped.

And the AI won’t stop them. It’s not designed to refuse. Ask it for an app, and it gives you an app — it doesn’t ask whether you know what a database backup is.

This isn’t me gatekeeping. I want more people building things — it’s the whole reason this blog exists. But there’s a difference between lowering the barrier to building and pretending the barrier to operating software safely ever went away.

What actually goes wrong

#

This is the part the hype crowd skips and the doom crowd never makes concrete. When someone deploys AI-generated code they don’t understand, the failures are boringly predictable:

Secrets in the code. API keys and database passwords hardcoded right where the AI put them during the demo — then committed, then pushed, sometimes to a public repo. Bots scan for these constantly. Not “eventually” — within minutes.

No real authentication. The AI built an admin panel, because you asked for an admin panel. Whether anything actually protects it is a different question — one you have to know to ask.

Classic injection holes. SQL injection and friends have been on the OWASP list longer than some developers have been alive. Models trained on decades of public code have seen every bad pattern in existence, and under a vague prompt they’ll happily reproduce one.

Hallucinated dependencies. Sometimes the AI imports a package that doesn’t exist. Attackers know this — they register those names and fill them with malware, and pip install will not save you. Your supply chain is now a slot machine.

Deploy and forget. No updates, no patching, no backups, no monitoring. The app that “just works” quietly becomes the app running eighteen months of known CVEs, holding customer data, on a VPS nobody logs into anymore.

None of these are exotic. That’s the point. They’re the basics — and the basics are precisely what you can’t skip by asking nicely.

Doing it right

#

So what does the boring, competent version look like? Nothing revolutionary — the fundamentals didn’t change, they just got easier to apply:

1. Read the code. If you can’t read it, that’s not a reason to skip reading — that’s the signal to slow down and learn. Ironically, the AI is an excellent tutor: paste the code back in and ask it to explain why, line by line.
2. Version control from the first commit. Not because it’s fancy, but because “what changed?” is the first question in every incident.
3. A test environment that isn’t production. Let things break where breaking is free.
4. Secrets belong in environment variables or a secret store. Never in the repo. No exceptions, not even “temporarily”.
5. Least privilege everywhere. Scoped API tokens, containers that don’t run as root, databases that aren’t reachable from the internet.
6. Know your dependencies. Verify that packages exist and are maintained before you install them. Keep them updated after.
7. Treat AI output like a pull request from a brilliant, tireless junior developer — fast, knowledgeable, occasionally confidently wrong. You review it. You own the merge.

Notice that none of this is AI-specific. It’s just software engineering. The tool didn’t remove the checklist — it freed up the time to actually do the checklist.

The tool amplifies the hand

#

Here’s my actual conclusion, and it fits in one line:

AI doesn’t replace understanding. It amplifies whatever understanding you bring.

Bring engineering judgment, and it will multiply your output in ways that still feel slightly unreal to me. Bring nothing, and it will multiply that instead — confidently, fluently, at scale.

The super-negative crowd looks at the second case and concludes the tool is the problem. But we don’t blame the chainsaw for the person who never learned which end to hold. We do insist they learn before pointing it at anything important.

If you’re on the outside wanting in: this is honestly the best time in history to learn how software works, because you now have an infinitely patient explainer sitting next to you. Use it to understand more, not to understand nothing.

That’s the whole take. The tool is incredible. The tool is not the job.

Are you building things with AI — or refusing to? I’d genuinely like to hear which camp you’re in, and what pushed you there. You know where to find me.