BRYAN HUNT

Software Developers == Mass Cultivators?

What is the new paradigm in product development with AI?

I bounce back and forth between my feelings: future financial stress, career outlook dread, marveling at the science fiction we live in, and an expansive mindset of optimism. I’m certainly feeling the full spectrum of emotions.

My first reaction is typically, software developers will be replaced as we know it today, so I better get on board.

Then I think code is easy to write now, so there’s going to be more software, and more need for humans to shape it in a way that suits us and influences the way AI shapes it for itself.

Then I realize, the development career I’ve come to love is already gone. It’s changed dramatically in the past 5 years, whether I like it or not. It’s already different, from my perspective, for better or worse. Maybe that’s why I’m feeling the full spectrum of emotions: I’m grieving the loss of my old career, and embracing the new world.

So it had me thinking: what is the new paradigm? Things have already shifted, so where is it headed? What are the new problems we face that need to be addressed?

Here’s where I’m currently skating, hoping I’ll find the puck:

Code used to be expensive. It required human time, attention, knowledge, and coordination between people to release production code.

Code: Now, code is cheap. I can generate a green-field app to my liking in minutes. I can fix bugs without understanding the issue via the almighty prompt: “fix bug”.

Time: Developer time used to be expensive. Now, developer time has been reduced dramatically. I can generate a template without leaving my editor. I can refactor code, review in-line, revert, replace, update, etc, in a few minutes. It’s still expensive in the full breadth of my time. I can simply produce more code and features now and with less help, less input, and competently cross the threshold into other expertise (e.g. marketing and design).

Mass: Mass used to be expensive... ...and it still is. A slow query burning resources is still a slow query burning resources. A feature that has all of the bells and whistles still has all of the bells and whistles that add complexity and edge cases. An insecure endpoint that gets exploited still costs more time and money.

So is my job less about producing working code and more about the insights into what kind of code is costly, and what kind of code is not? What sort of features are bug-prone and flaky, and what is rock solid? Is my job now AI “middle to high-level” management? To direct Michelangelo’s ghost to chisel the statue of David how the church intends vs how it asks?

That sounds like a temporary position to me. AI can manage itself or at least it’s getting there.

But it still doesn’t seem to really understand mass the way we’ve come to understand it and I don’t think it ever will. I don’t think AI will ever become annoyed with fixing a circular edge case (fix one thing, break another, repeat). AI won’t care if you ask it to figure out the issue at 1AM and it won’t feel shame when you spin up another agent to fix its mistakes.

So why are human devs so intimately aware of mass? Because of the trial by fire over years of building? Because of the personal nature and responsibility we claimed when things went well, or broke, or we were the experts of the domain that carried the mass?

Here’s my personal example: vibe-coded PRs aren’t bad if they’re respectful and easily reviewable. But often, the code carries mass that wasn’t considered. Yes, it works, but at what cost? That cost may be meager for some organizations, or dismissible for most use cases. Or it may add unnecessary drag that burns tokens, developer time, and money.

So what is the new paradigm? Are we software developers or are we now “mass cultivators”? Or am I overestimating on software mass?