Software Shifts: From Doing to Managing

I used to be proud of how fast I could get software work done. Over a decade of muscle memory and pattern recognition — I could look at a problem and have something working before most people finished reading the ticket.

Now I can watch an LLM do the same work in a few minutes.

And not bad code, either. Functional, reasonable, sometimes better than what I’d have shipped. A properly scoped task — clear inputs, clear outputs, well-defined constraints — can have its code written by a computer now. I’d bet even the unicorn developers are starting to look up from their editors and wonder what the next year looks like.

We’re in the era of orchestration. And I’m still working out what that means for people like me.

The Bolt-Tightening Era Is Over

For years, a huge chunk of software work was maintenance. Fixing bugs in legacy systems. Adding a field to a form. Updating an API to match a new spec. Not glamorous, but steady. You could build a solid career tightening bolts in someone else’s machine.

That work is going the way of the horse-drawn carriage. Someone might still do it by hand, but it’s novelty more than practical. When an AI agent can pick up a Jira ticket, read the codebase, write the code, and open a pull request — the math on paying a human to do the same thing gets hard to justify.

Not a reason to panic. But a reason to be honest. The developers who do well in the next chapter won’t be the ones who type the fastest. They’ll be the ones who think the clearest.

When Building Costs Nothing, Knowing What to Build Is Everything

Here’s the shift I keep coming back to: the cost of development is approaching zero. Not literally — there’s still infrastructure, complexity, the messy reality of production systems with real constraints. But the marginal cost of writing code for a new feature? Dropping like a rock.

When you can build almost anything your team asks for, the bottleneck moves. It’s not “can we build this?” It’s “should we build this?”

The scarce thing isn’t engineering labor anymore. It’s engineering judgment.

The Shift Into Project Management

For me, the first part of this evolution looks like project management. Not the “move tickets around a Kanban board” kind. The real work of understanding your business domain well enough to orchestrate what gets built and why.

What are we actually building? Why does this matter? Who is this for?

A lot of developers — myself included — have dodged those questions for years. Someone else wrote the spec. Someone else talked to the customer. You just built what was on the ticket. I’m finding that era is ending. When building is cheap and building the wrong thing is expensive, the person closest to the code needs to understand the business well enough to push back.

Getting comfortable saying “no” to bad ideas — or at least “let me explain why I think this is a bad idea” — might be the most valuable skill a technical person can develop right now. You’re not just a pair of hands anymore. You’re a translator between what the business wants and what the technology can responsibly deliver.

I’m still growing into this. Pushing back doesn’t come naturally when you’ve spent a decade heads-down executing. But I’m learning that the push-back is the work now.

The Shift Into Product Management

The second part looks like product management. When you can build anything, the temptation is to build everything. New feature? Sure. Another integration? Why not. Rebuild that module from scratch? Let’s go.

This is where engineering judgment earns its keep. Good architecture isn’t about clever code. It’s about practical decisions at scale. Are we reusing existing features, or reinventing the wheel? Are we building on the codebase we already have, or bolting on yet another thing that creates complexity we’ll have to manage later?

When AI can automate the writing of code, the human value is in the decisions surrounding it. Which abstractions matter. Where to draw boundaries. When to say “we already have something that does 80% of this — let’s extend it” instead of spinning up a new service.

These are product and architecture decisions. They need the kind of context no LLM has — deep understanding of your specific system, your specific customers, your specific constraints. That’s the competitive advantage for engineers who’ve been in the trenches. You know things about your production systems that can’t be scraped from a README or achieved through intentional compaction.

From Carriage Driver to Fleet Manager

We were carriage drivers. Skilled, experienced, proud of the craft. And the automobile just showed up.

Some people will keep driving carriages. But I think the ones who build long careers from here will learn to manage fleets instead.

For software people, that means becoming managers of AI agents and advocates for the business. Less time writing code, more time defining work, reviewing output, making architectural calls, and making sure what ships actually serves the people who use it.

I don’t see that as a demotion. It’s harder. More ambiguous. More impactful. It takes everything you learned writing code — plus a whole new layer of communication, business thinking, and decision-making.

Where I’m Landing (For Now)

I don’t have this all figured out. But I think the developers who do well from here aren’t the ones who write the most code — they’re the ones who manage the most complexity. Who understand their business domain. Who push back when something doesn’t make sense. Who orchestrate agents to automate the building while they focus on the thinking.

The era of orchestration is here. The question isn’t whether your job is changing. It’s whether you’re going to evolve with it.

What does this shift look like from where you’re sitting? I’d love to hear how other builders are thinking about this.