Pride in Software When Code Is Cheap

Coding agents are making it easier to throw code away and start over, and I think that’s changing our relationship with the work. There’s less investment in any particular implementation when generating another one takes relatively little effort. That can be great, especially when something needs to be rewritten, but it can also make the code feel disposable enough that we stop caring about its quality. I see both of those things happening, and I’m trying to figure out how we keep the willingness to replace code without losing the pride that makes us want to do good work.

I’ve had plenty of arguments with other developers about implementations that needed to change. We could go through the reasons an approach was causing problems, but sometimes the conversation kept coming back to keeping what was already there. Oftentimes, it was more of "it's not that big of a deal" type of thing. That doesn’t mean every disagreement was about ego, or that I was automatically right about what needed to change. There are legitimate reasons to avoid a rewrite, but there were times when you could see how much of the resistance came from the effort somebody had already put in. They were proud of what they’d written, they didn’t want to redo it, and questioning the implementation started to feel like questioning their ability. Separating those things was often harder than fixing the code itself.

Agents help with this problem because they reduce the cost of changing direction. When replacing an implementation takes less effort, there’s less reason to defend it just because it already exists. We can try another approach and evaluate what happens instead of spending all our time arguing about whether trying it would be worth the work, and I think that’s a substantial improvement. Being willing to throw something away is useful in software development, and it gets easier when throwing it away doesn’t mean losing days of work. There’s also less personal attachment when I didn’t spend those days writing every line myself.

The same thing that makes a rewrite easier, though, can make careless work easier to accept. If I can have an agent generate another version whenever I need one, I can start treating the current version as something I don’t need to think about very carefully. It works for now, and I can always fix it later. That’s a useful option to have, but it can become an excuse to leave problems I already recognize. Generating a replacement doesn’t mean I’ve understood what was wrong, and it doesn’t mean the replacement will be better. Somebody still has to care enough to examine the result and decide whether it’s appropriate.

One other concern I have is how easy cheap code makes duplication. A model may not have the context of what it wrote earlier or what already exists elsewhere in the project, so it can create a helper function in one class, then create the same function in a second class, and possibly again in a third. A developer paying attention would usually remember writing it, get annoyed at repeating the work, and move it into a shared helper or maybe a library that other projects could use. There was a time advantage to that: spending a little extra effort on the abstraction saved you from writing the same thing again. With agents, that immediate incentive is weaker because generating another copy takes so little effort, but maintaining those copies is still a problem. If I decide to change how that function behaves, I now have to find every place it was duplicated and make sure each copy gets the appropriate change. I can send a model to crawl through the code, but that’s more work to check than changing a shared implementation or updating a library and its consumers. That’s one small example of how making code cheaper to produce can leave us with more work later.

I think maybe that means pride has to move up a layer. Choosing the appropriate architecture still matters, along with deciding what the software should do, how its parts fit together, and how much complexity the problem deserves. I don’t think I’m going to take much pride in a well-crafted prompt. I might be pleased that I explained something effectively, but that alone isn’t going to give me much satisfaction in the finished software. The decisions behind the implementation seem like a more meaningful place for that pride to go. Of course, I can get attached to an architecture I chose just as easily as somebody else gets attached to a function they wrote. Moving up a layer doesn’t automatically remove the ego, and that’s the part I don’t think we’ve worked out yet.

Pride can make us careful, and it can make us stubborn. Making code cheaper gives us a chance to let go of some of that stubbornness, but I don’t want to lose the care along with it. I still think producing good software requires taking pride in something: the judgment behind it, the way it solves the problem, or the quality of the result. I’m still figuring out what that looks like when less of the work involves writing the code myself.