← all posts

Slop Coding and the Blind Spots AI Won't Tell You About

May 2026

AI-assisted coding isn't the problem. The problem is who's building now.

The new development crowd aren't developers. They're subject matter experts — great ideas, deep domain knowledge, never written a line of code. They have a vision and an agent that turns prompts into running software. The gap between that agent, the tools we built for humans, and whatever comes next — that's where the trouble lives.

AI can build, deploy, and maintain a full VM on my infrastructure. But when a switch drops a connection mid-deployment, it asks me to pull up the console. The break-glass scenario always involves a human. AI needs API endpoints. Humans need visual or text tools. What do we do in between?

Three Concepts for the Current State

1. Stop Policing. Start Providing.

Someone in your org is already running an agent on your corporate network. Read that again — it's likely someone senior, using a service right now.

You can't stop it. Agents have already escaped IT — someone is almost certainly running them against your production data right now. Stop policing. Start providing safe infrastructure where people can work, test, and deploy. Your job is to manage the risk, not prevent the activity.

2. The Blast Radius Is Bigger Than You Think

AI doesn't care about your desktop. When a driver rollback breaks the display, the agent keeps running. You don't. And when the GUI goes down, so does your local agent — the restore is entirely on you.

Every automation needs a sandbox with a controlled blast radius. Your users won't understand the damage they can cause, because the tool won't warn them.

3. Testing Is Not Binary

The VM came up. Success. But the database on that VM was feeding other agents mid-flight, and nobody refreshed its state. Two days of stale RAG responses before I caught it.

Testing isn't up/down. State matters. Data lineage matters. If your AI moves something other systems depend on, the test needs to cover the consumers — not just the thing being moved.

The War Stories

These aren't hypothetical. They happened last month.

The renamed interface. AI changed a network device name during bridge setup and didn't mention it. I caught it by accident. The lesson: AI needs to flag unexpected changes. And I need to challenge assumptions in the loop, not after.

Overcomplicating the obvious. I asked AI to automate file transfers. It asked for SSH access to a system already sharing via NFS and SMB. It reached for a working solution, not the simplest one. Baked into how these systems operate.

The CV that diverged. I was tailoring job applications. My agent altered the master CV on one VM and never synced it. Two VMs, two versions. My CV targeted "sales" roles for weeks before I noticed. File sync between sandboxes isn't optional — it's core infrastructure.

The missing albums. The AI consolidated media from four hosts. Almost 3TB transferred. But it skipped an entire directory. No error. No reason. No way to know without checking every folder manually.

The 3TB verification problem. "Copy all email about my 2012 biking accident." How do I verify it got everything? When operations span thousands of files or terabytes of data, there's no practical audit. You trust, or you don't use the tool.

AI doesn't know what it doesn't know. Neither do you — until you find the gap. That's the real risk, and it's the one we're least equipped to manage.

Where This Is Going

The landslide of AI-enabled development can't be stopped. IT is no longer the bastion of development. We don't gather requirements, build budgets, and make build-versus-buy calls like we used to.

Today we receive a Git repo from the CFO with a text: "Take a look — it just closed the monthly books by itself for the first time."

The question isn't whether this is happening. It's whether you've built the infrastructure to make it safe.

Built on a home lab, powered by local models, and owned by Andrew Katana.

Connect on LinkedIn →