The Suit Doesn't Make You Tony Stark
AI handed every developer an Iron Man suit. It did not hand them Tony Stark's brain. That gap is the whole story, and it's where the vibe coders have to grow up.
I was building a substitution feature into BenchBoard the other night. Simple idea on paper: a coach drags a kid into a “sub” slot, and the app tracks who’s covering for whom. The kind of thing that sounds like an afternoon and turns into a week.
At some point I hit a question I couldn’t punt on. What happens when a coach drags a player onto a sub slot that’s already occupied? Somebody’s already sitting there. Kick them out automatically, or stop the coach and make them clear it first?
I asked the model. It gave me a clean, confident answer: swap them. Bump the existing sub out to the reserve, drop the new player in, done. One gesture, no friction. Honestly a good answer. I’d endorsed the same approach myself ten minutes earlier.
Then I thought about it from the field and pushed back. Here’s the actual exchange. Watch what happens.
Me: When a starter (or reserve) gets dragged over an existing sub slot, it shows a circle strikethrough icon. [...] OnDrop, we could also fire a popup [...] Then the user just needs to drag that player again. [...] This feels like a much better UX. Thoughts?
Claude: This is better than the swap, and I’ll tell you why I’m now against the swap I previously endorsed: bumping Mariano to Reserve as a side effect of dropping Will is an invisible data change. The user’s eye is on Will; Mariano teleports while they’re not looking, and ten minutes later it’s “wait, why is Mariano in Reserve?” [...] for a lineup tool surprises are the expensive thing.
Read that again. It reversed itself instantly. Not grudgingly. It wrote me a genuinely good argument for why my way was better than the way it had recommended thirty seconds earlier, and it did it with the exact same authority it used to recommend the wrong thing.
Now, I’ll be honest with you about something. A while back I would have looked at that moment and concluded that coding itself wasn’t really the superpower, that the syntax was just a tax and the only thing that mattered was the judgment call. I was wrong, and I want to correct it here, because that framing is lazy and it feeds the worst advice going around right now. What that exchange actually proves is the opposite. Coding is still the superpower. It just got the upgrade of a lifetime. And the upgrade makes the human underneath matter more, not less.
I Have a Jet Pack Now
Boris Cherny, the engineer who created Claude Code, put it better than I can. On The Circuit with Emily Chang, the Bloomberg show, he described what AI-assisted engineering feels like now:
Cherny: I suddenly have superpowers and I have a jet pack and that engineering has never been this fun.
That’s exactly it. Claude Code is my Iron Man suit of choice, the most effective one I’ve used so far. It makes me faster than I have ever been in my life. But here is the part the hype merchants skip past: a jet pack does not fly itself, and the suit does not make you Tony Stark. Stark’s superpower was never the suit. It was the engineering mind that designed it and knew what to do with it. The suit only turned that mind into something that could level a building.
Chang pushed Cherny on the obvious fear, and his answer is the whole thesis of this article:
Chang: All of this raises an obvious question. Will engineers be the first casualties of the AI they’re building? [...] It’s been Revenge Of The Nerds for a while. Is that over?
Cherny (laughing): I think we all become nerds!
Chang: But what happens to the ACTUAL nerds?
Cherny: I think the actual nerds will have to figure it out. I think for a lot of them, the skill that they had before is gonna help them in the future because they sort of have a pretty big headstart. They do a lot of things that are not coding. Engineers also have to talk to users. They have to plan, they have to think about what’s next. And so those are parts of engineering that are gonna stick around.
Boom. The headstart is real. The engineer who already knows how systems fit together, who can talk to a user, who can see what’s coming, walks into this era with the suit fitting like it was custom built. The person who only ever learned to prompt walks in wearing something they cannot actually fly.
So let me say the corrected version plainly. Coding is still the superpower. It’s just upgraded, and far more impactful than it has ever been. But you only get the upgrade if you already have the thing being upgraded.
Knowing What the Code Is Doing
The bug that kicked off that session is the cleanest proof I have of why you still have to know what the code is doing, even if you never type a single line of it.
In BenchBoard, a sub slot is labeled something human like “Sub for Grace.” But under the hood, the slot isn’t keyed to Grace. It’s keyed to a number. The slot means “whoever is batting 7th.” Not Grace the person. The 7th spot in the order.
That distinction seems like nothing. It’s everything. So let me show you instead of telling you, the exact way the model showed me: it laid the lineup out in plain text and asked if this was actually what I meant.
Here’s the lineup. A coach grabs Radford, batting 2nd, and drags him onto Grace’s sub slot, the one labeled “Sub for #7.”
THE DROP: Radford (#2) ─────────► slot "Sub for #7"
Bat # Starter
───── ──────────────
1 Alice
2 Radford ← dragging this player
3 Ben
4 Carla
5 Dan
6 Erin
7 Grace ← you dropped on HER slot ("Sub for #7")
8 HanaNow the naive code does the obvious thing: pull Radford out of the starters, renumber so there are no gaps, then save “Radford subs for #7.” Watch what the renumber does to everyone sitting below him.
Bat # Starter (Radford pulled, gap closed, all shift up)
───── ──────────────
1 Alice
2 Ben (was #3)
3 Carla (was #4)
4 Dan (was #5)
5 Erin (was #6)
6 Grace (was #7) ← Grace slid up to #6
7 Hana (was #8) ← #7 now belongs to HANA
Code saves: Radford.substituteFor = 7
But #7 is Hana now. You meant Grace. ✗ off by oneThat’s the entire bug, sitting right there in the table. You dropped Radford on Grace. The renumber slid Grace up to #6 and slid Hana into #7. The code, still clutching the number 7, just recorded that Radford is subbing for Hana. Your gesture said Grace. The data says Hana.
And here’s the detail that makes it evil: it only happens on downward drops. Drop a player onto a slot above them and nothing below shifts, so it works fine. Drop below and it’s off by one. In testing it looks random, which is the worst thing a bug can look like. Here’s how the model diagnosed it:
Claude: The number 7 is unstable across the renumber, but Grace isn’t. So the handler does the lookup before the world shifts and the write after [...] the player id is the stable handle you carry across the mutation.
And then it named the root cause in one line every developer should tattoo somewhere:
Claude: The schema stores a pointer (substituteFor) in a coordinate system (battingOrder) that mutates underneath it.
In plain English: don’t hold onto the number, hold onto the person. The number is a parking spot anyone can pull into. The player is the car. You track the car.
That’s a sharp diagnosis, and the model wrote it. But it only got there because I knew enough to smell the bug, describe the symptom precisely, and recognize the fix as correct when it came back. Hand that same situation to someone who doesn’t understand what a renumber does to a stored reference, and that explanation is just noise. They’d nod, ship it, and never understand why their app “randomly” assigns the wrong sub.
This is the thing about even the best model, and Fable is the best I’ve used for this kind of deep tracing. Make it Mythos times a hundred. It still does not know what optimal looks like in your system. It knows a hundred plausible ways to do a thing. It does not know which one is right for the product you are actually building, because it has never stood where you stand. You do. That’s not a syntax skill. It’s knowing what the code is doing and why.
A Few Years Ago, This Was a Different Job
Let me tell you what building software used to be, for those of you who weren’t there.
You knew a language. And then you spent half your life Googling to the ends of the earth to find out whether some other engineer had already solved the thing in front of you. Before you wrote one useful line, you set up the lab. Picked the environment. Argued with yourself over the language. Fought the toolchain. Getting the environment to even stand up was a shitload of work that had nothing to do with the actual problem. Then you started typing, and it was a guessing game, because the smartest your IDE could do was autocomplete the back half of a single method if you were lucky.
Today it’s a conversation. I talk to Claude Code and I am more productive than I have ever been. But here is the part that matters: it requires more engineering than ever, not less. Because now you’re going toe to toe with a robot that knows how to code and knows a hundred ways to approach any problem. And even with all of that, the robot can still be wrong. Confidently, fluently wrong, the way it was when it told me to swap Mariano out from under the coach’s nose.
That gap, the robot is fast and deeply knowledgeable and still sometimes wrong, is exactly what separates good engineers from bad ones now. The old gate was “do you know the language.” The new gate is “can you tell when the confident machine is wrong, and do you know what right looks like instead.” That is a higher bar, not a lower one.
The Part That Sticks Around
During the interview with Chang, Cherny named the parts of engineering that survive: talking to users, planning, thinking about what’s next. I’d add one that sits underneath all of those. Not just solving the problem, but deciding how to solve it.
Back in that same session, after I’d tied myself in knots over the off-by-one, I stepped back and told the model I was overthinking it:
Me: I’m over thinking it. Here’s what I want to do [...] Wherever Will C. goes, we just make the shift, do the math and just do it like that. Thoughts?
Claude: Your simplification is exactly the right call, and good news: it’s not a solid-dnd limitation at all. The behavior you want is blocked by two deliberate lines of your own code, not the library.
The model found the two lines. Fast, by location, in seconds. That’s the suit doing exactly what the suit is great at. But the decision to throw out my elaborate version and collapse the whole feature down to “wherever the player goes, do the shift math” was mine. The syntax took a back seat. How the thing got solved did not.
This is the point in your own five points I want to hammer hardest. Problem solving was never only about solving the problem. It’s about how you choose to solve it. Writing the function is the easy part now. Deciding what the function should be, how it should behave, what it should refuse to do, that is the job. That was always the job. We just used to be so busy fighting the language that we mistook the fight for the work.
The Checkpoint
Anyone who grew up on hard games knows exactly what a checkpoint is. You’re deep in a brutal level, the kind with a miniboss waiting at the end, and right before the fight the game drops a checkpoint. A place to respawn. Die to the boss and you don’t restart the whole game, you start right there and go again. Walk away for the night and you pick up where you left off. It’s the line between the part you’ve already conquered and the part you haven’t.
Learning real engineering works exactly like that. Every meaningful skill is a level with a miniboss at the end. You grind through it, you die a few times, and when you finally beat the boss you’ve permanently banked a chunk of software engineering that you carry into every project after. You don’t relearn it. You saved it at the checkpoint.
The off-by-one bug from earlier in this article was a miniboss. The first time you fight “a stored pointer living in a coordinate system that shifts underneath it,” it wrecks you. You can’t even tell why your data is wrong. But beat it once and you own that pattern forever. Next time you see a value stored by its position instead of its identity, you recognize the boss on sight: an array index used as a key, a reference to “row 3” after the rows got resorted, same fight, different skin. You already know the moveset. That’s what clearing a miniboss buys you, the pattern recognition that makes the next version of the level easy.
If you want the purest example of this loop, look at the Souls games. A FromSoftware boss exists to humiliate you. The first attempt is chaos, you have no idea what’s happening, you’re dead in fifteen seconds. You respawn at the bonfire, which is the checkpoint, and you go again. And again. Slowly you stop seeing chaos and start seeing tells: the windup before the big swing, the gap right after it. Twenty deaths later the fight that was impossible is boring, because you’ve internalized the pattern. Then you run into a similar enemy in a later area and drop it on the first try, because you’ve seen this moveset before. That is exactly what building engineering judgment feels like, just with worse graphics.
Now here’s where the AI comes in, and this is the part vibe coders need to hear. Think Mega Man. You beat a boss, you get their weapon. But the genius of Mega Man was never collecting the weapons, it was learning which weapon wrecks which boss. Fire Man melts to the Ice Slasher, but you don’t know that walking in. You experiment, you guess wrong, you learn the matchup, and eventually you stride into a fight already holding the tool that trivializes it.
That’s your relationship with the AI now. Every pattern you’ve conquered is a weapon on your wheel, and the model is one more, an absurdly powerful one. But you’re still the player choosing when to fire it. You learn what it’s genuinely great at, tracing a bug across forty files in seconds, and what it will confidently fumble, like deciding what your product should actually do. You even ask it outright what it’s best for, the same way you’d test a new weapon on a boss to see if it sticks. Then you walk into the next level knowing which tool to bring.
Or think Metroid. The whole game is built on gates you cannot pass until you’ve earned the right ability. You reach the ledge you can’t jump to, the door you can’t open, and you leave. Twenty rooms later you find the High Jump Boots, double back, and walk straight through what used to be a wall. Engineering gates you the same way. There are problems you cannot solve, cannot even see the shape of the solution to, until you’ve earned the underlying skill. The day you earn it, the wall isn’t there anymore.
So to the vibe coders who actually want to take the next step, here’s the good news: you’re holding the most powerful weapon anyone has ever handed a beginner, and nobody is taking it away. But a powerup doesn’t beat the level for you. You still have to learn the patterns. You still need the basics of code, because you can’t aim a weapon you can’t see. You still need to know what the code is doing, because the boss has tells and you have to read them. You still need to understand architecture, because knowing which weapon beats which boss is the whole game. Clear those checkpoints, and the same suit that’s a liability in untrained hands turns you into the player who makes the hard level look easy.
The Brain Behind the Suit
Coding is still the superpower. I was wrong to say otherwise. It just got the upgrade of a lifetime, and like every upgrade, it rewards the person who already knew what they were doing and exposes the person who didn’t.
Fable is incredible, the best model I’ve used for going deep, and by the time you read this something will probably go deeper. It does not matter. The better these get, the more valuable the human who knows where to point them, who knows what good looks like, who can stand in front of a confident machine and say “no, here’s the better architecture,” and be right.
The suit is glorious. Jump in it. Just remember it doesn’t make you Amuro Ray. The brain does. And the brain you can still only build the old way, by actually learning the work.
Sources: Boris Cherny and Emily Chang quotes from The Circuit with Emily Chang, Bloomberg Originals (interview aired June 10, 2026). BenchBoard development exchanges are from my own working session with Claude Fable.
If this resonated, subscribe. I write about the honest, unvarnished experience of building real software with these tools, the parts the hype crowd leaves out.