The Ego Left the Codebase

Engineers get precious about their code.

Critique a function and the author hears a critique of himself. A pull request comes back with forty comments and it turns personal, defensive, a little cold. Designers do it, writers do it, anyone who makes a thing and then has to watch someone poke at it. The work feels like an extension of you, so a poke at the work lands like a poke at you.

I’ve noticed the flinch is weaker when the code came from a model.

When something a model wrote breaks, or someone tears into it in review, the reaction shifts from defense to curiosity. You may have directed it, picked the approach, said what to build, signed off on the output. You’re still on the hook for it. But the lines don’t feel like yours in the same way, so the bug reads as a fact about the code rather than a verdict on you. You just fix it.

That’s a bigger shift than it sounds, because a lot of what makes engineering slow isn’t technical. It’s ego management. People defend bad decisions because backing down feels like losing. They route around someone else’s module because ownership got personal. Review becomes a status negotiation. A rewrite gets blocked less because it’s wrong than because it implies the first version was. I’ve done versions of all of that. Take some of the ego out and that friction softens.

When the code is nobody’s baby, you can be honest about it. You can throw it away. You can say “this whole approach is wrong” without a person across the table hearing “you are wrong.” Watch a review where the diff came from a model: the author reads the comment, nods, and deletes the code. No standoff. Criticism gets cheaper, and cheap criticism is the kind that actually happens, which is how problems surface while they’re still small. The thing that used to feel like an insult becomes ordinary maintenance.

I don’t want to oversell this. Detachment has a cost: it’s easier to ship something you never fully understood, to wave through slop because no part of you is staking anything on the lines. The flinch was doing some work. The bet is that what it protected, care and scrutiny, can be kept without the part that made every review a duel.

Which is the real risk, and it’s worth sitting with. Pride and accountability usually travel together: you sweat the code because it’s yours, and it’s yours because you sweat it. Pull out the pride and the worry is that accountability leaks out with it, and “the model did it” becomes a shrug. That would be worse than the problem it solves. The whole thing only works if ownership stays put while attachment lets go: if I shipped this stays a signature even when I typed this stops being true. That doesn’t happen on its own. A team has to insist on it. But it’s a more honest place to keep responsibility than the old bundle, where caring about quality and feeling personally wounded were the same reflex and you couldn’t have one without the other.

The more interesting question is where the ego goes, because it doesn’t disappear. It moves up a level. The pride leaves the lines and attaches to the taste: what to build, what to keep, what to cut, telling good output from slop. The model is fast, not tasteful. Judgment is the part that’s still yours, so identity migrates to the decisions instead of the implementation, a healthier place for it to live, because decisions are meant to be argued with. Code someone bled over is not, or so the old instinct goes.

None of this makes engineers care less. It lets them care about the right thing. You stop defending a function and start defending an outcome. Review stops being a fight, so it gets faster. And the work gets better because nobody’s guarding a draft that should have been deleted.

The precious phase of software may be ending. If it is, the care was never really about the code. It was about the judgment underneath, and that’s the part worth keeping.