You Need Human Beings “Involved” in Your Code

May 3, 2025

🎧 Listen to this article: Play recording

Introduction

A troubling trend I see nowadays with people I work with is this constant push to pass the buck. I'm willing to bet that Zuck, Altman, Nadella, and the other people pushing AI don't like what I'm about to say. And I don't care. I can't tell, but part of the snake oil people push around is that you can take your hands off the code. The machine will do it for you. It's like copying and pasting code snippets and examples from Stack Overflow. UI libraries that people stop maintaining and break. Maybe we can call this the "old AI."

The Hands‑Off Coding Myth

I get code from clients who say, "Oh yeah, I just copied this Facebook Messenger example. Let me get you that code." My first response is always, "No—I don't want to see that code. That isn't even how I work." Why? My approach is to build things carefully from the ground up, get involved personally, understand each element piece by piece, and methodically ensure each component works ideally before moving on.

Marie Kondo Your Codebase

Never pile stuff you don't understand on top of more things you don't understand. Because if you think you're going to skip fundamentally getting involved, guess what you'll get? You'll get broken code that's a complete mess where you don't know your (three-letter word for donkey) from your elbow. Let's return to an even more straightforward analogy: cleaning your room, Marie Kondo style. How are you going to clean your room without getting involved? You must get involved in every decision personally—do we keep or toss this item? What's the best way to get organized? Simplify, simplify, simplify. Discard, discard, discard. I had a friend for whom I felt genuinely bad. She could never get her apartment clean. Why? Her parents constantly dumped old stuff from their storage unit into her living room. Throw that stuff out! It was old stuff she no longer needed, making her life harder. Do you think AI is going to help you do that? I've seen duplicated views, redundant view models, extraneous logic, and "cool new features" generated by AI that confuse, break, and gum up the project. AI can easily slow you down if you don't have a human engineer managing and taming it every step of the way.

Why AI Won’t Replace Engineers

I know—you don't want to pay. You don't want to hire engineers. You want AI to take care of it for you for free. You want to do it all yourself because Cursor paints the seductive illusion that you can. Big tech CEOs confidently say that half their code will be AI-generated within a year. But here's the snake oil they're selling you: AI isn't managing the code. Sure, it can spit out quick boilerplate and sketches. Still, when it comes to performing the Marie Kondo on your codebase—getting it running like a finely-tuned piece of cutting-edge machinery—that's the brilliant human engineer's job. That's the one who sees everything, understands the context, and cleanses the garbage. I'm betting my money (and my business) that it'll be long before you can replace that engineer. Now that AI is pumping out more code, you might even need more engineers than before. Don't get me wrong—after I threw down all my thoughts, AI polished this article, and Grammarly AI proofread it. AI has its place. But the ideas, strategic organization, pruning, and discarding extraneous and wasteful elements are all mine. And I don't see how that will ever go away. "Okay, got it—I'll use AI to write the code and be that Marie Kondo manager." No, you have no computer science degree. AI will mess up your code in ways you don't understand. You won't know why you can't use a Firebase ID macro as an identifiable/hashable value on your messages at runtime because you have to set its default value in code (it's optional) and retrieve the actual value in a fetch, causing navigation link resets and breaking your navigation flow. Experienced programmers understand these details. Think AI will debug that for you? I've even managed to spin AI around in endless circles, trying to fix a bug, watching it continually add layers of code and fixes without truly understanding the context. The problem gets more and more messy. People prompt the AI for hours until they realize they're just prompting in circles. That's when I got the call. Trust me, you don't "get it." You can't just casually do it yourself unless you commit to becoming a software engineer like me. Great, now you're a software engineer. You can do it yourself. I even have clients who do their programming. But realistically, how many teams consist of just a single engineer over the long term? You're inevitably going to need backup. Meta, X, Microsoft, and Apple employ teams of thousands of brilliant people. And that's the next part where the snake oil fails: the idea that with AI, everyone will become an army of one. It's simply not going to happen. Just face it—you don't want to admit it. Put that drink down. You need to pay the engineers.

Interviews, LeetCode, and Reality

Even Big Tech doesn't like paying engineers. They think they will solve the money problem by building a vast walled garden, keeping out all but those they believe are the most efficient engineers—the ones who can solve the most challenging LeetCode problems, tests of algorithmic memorization rather than genuine problem-solving skills. LeetCode monkey robots. Oh, wait, that was 2 years ago. AI robots will write the code, according to Zuck and Nadella. They're not going to hire LeetCode Monkey Human Robots. They're going to hire nobody! Brilliant. But Leetcode Robot Monkeys and AI Agents Robots aren't engineers who excel at solving real-world problems, which are always new and unpredictable. Some are far more mundane than LeetCode. But somehow, always more real, original, and authentic. Created by original human thought in response to new human situations, not algorithms that have been solved a hundred times in a textbook somewhere. I have yet to go on an interview with a big company where they gave a damn about what I've already built successfully for countless clients. They'd rather run down their set list of weed-out questions, which they think are relevant from the box they are living inside. Their stock is down. Boo hoo. Then there are smaller, semi-established companies, where they give you the take-home problem. Then, when they get you on a technical screen, they throw the addendum to the technical problem up. You can't instantly snap back with a solution in 5 seconds? Well, we only want senior engineers here. Never mind that solving these problems takes extensive thought, something that is hard to assess in real-time. My value has been proven to my clients over months and years, let alone minutes. Why don't you ask about what I've done for them?  So what if I can't spit back a solution to the one complex problem you've been tweaking for months? What about the issues I've mulled over and solved for my people in the past months? You're fooling yourselves. This context is the context in which real engineers live. Not LeetCode. Not some contrived situation the interviewer made up. It's not something where you can snap back the solution in 5 seconds and "look like" you know what you're talking about. You, software interviewers, want to convince yourself it's a good proxy, but it is not. You are losing track of what's essential. But hey, they sure can reverse a binary tree or solve that contrived water levels problem you made up to be hard. And they sure can manufacture AI snake oil. That's in demand now. I'm sorry for breaking the bad news. It's inevitable; you need humans. You will pay. You can come out of your dream world now.

Have questions? Drop me a message, and let’s chat.

← Back to all posts