Forgive Me, Sam.A, for I Know What Not to Build

PS: Unlike my last note, this blog post isn’t anti AI. I just want to talk about a problem most of us don’t really treat as one and that oversight only increases the damage and cost of whatever we pay for or with. Also need to clarify that i use AI in my development daily, it doesn’t negate the problems discussed here.

These days, every product seems to come with the tagline: “Build anything” And sure, these days, that’s true to some extent it’s tempting, even exciting. But it’s also worth remembering that our energy and time are still finite. Knowing what not to build is just as important as knowing what to build.

Since AI wrote its first “Hello, World” (if it actually did), the speed at which we can crank out code has gone through the roof. Everyone’s shipping code like it’s monday morning which. is great if you’re iterating fast on a feature, an mvp or testing a hypothesis.

But there’s one thing we seem to have forgotten; code is a liability.
Every new instruction increases the chance that something goes wrong. That matters a lot when you’re building accuracy critical tools, at a time when we’re debating whether we even need to read code anymore. Makes you wonder where everyone’s sanity went.

To be clear, none of this depends on whether the code came from a human or an AI. The issue is scale. If AI can generate 1000x (random number, don’t quote me) the code a typical human could, the stakes stack up fast. More code does not equal a better product. The real priority should be getting a feature up and running with as little code as possible.

Hold on, let me ask Claude

Let’s talk about the addictive dependence that creeps in when you let AI take over your project (without oversight) until no part of the codebase looks remotely familiar to the actual developers.

People will say, “Skill issue. You should do it this/that way.” And yeah, they’re right, it is a skill issue. But what they overlook is how it starts.. how it creeps in. you give the AI a simple task. It nails it. Impressively. And then you give it another. And another. Before you know it, you’ve handed over the judge, jury, and executioner roles to a model.

It’s like a drug you can’t let go of. And why would you?
It feels good. It makes your work easier. It strips away the boring stuff and lets you move on with your life. That’s cool, until it’s a project you actually care about.

I know that sounds cringe, “a project you care about”; but when you’re no longer involved in the development process, everything starts to feel foreign. You can’t explain the hows or the whys as clearly as you could if you’d actually been in the trenches. Maybe that’s a personal flaw. But hey, this is my blog post.

Surely, this same problem exists when large teams work on a codebase too. But once again, the more code gets churned out over a short period of time, the bigger the problem becomes.