AI 时代软件工程师的三条路径

What should an ambitious software engineer do today?

Ten years ago, being a great software engineer gave you an unusual advantage: a rare skill you could apply to almost any industry.

You could build a payments company, improve how hospitals operated, or create a new way for people to communicate. The same underlying ability opened doors into wildly different businesses.

Software was eating the world, and knowing how to build it gave you a seat at the head of almost every table.

“Get really good at software engineering” was remarkably versatile advice. You could acquire the skill first and figure out where to apply it later.

AI is making the ability to produce working software much more widely available. People who couldn’t have built a product a few years ago can now get surprisingly far. Experienced engineers can attempt projects that previously required a team.

Great engineering is still rare. But “I can build it” is becoming a weaker answer to why you, specifically, have an advantage.

The way I see it, there are three paths.

1. Go work on the thing that’s eating software

Help create the technology that is making software engineering more accessible.

That could mean AI research, or the infrastructure, systems, and tools needed to make new capabilities useful. Find problems where technical ability remains a serious constraint, and where solving them expands what other people can do.

2. Find a world-class domain expert and team up

Someone who has spent fifteen years in an industry may know where the expensive mistakes happen, why previous attempts to fix them failed, and who would buy a solution. That knowledge is hard to acquire from the outside.

At SPC, we’re seeing more people become promising founders without much prior software engineering experience. They bring deep domain knowledge and strong instincts about what needs to exist.

These are people worth getting to know. A great engineering partner can see possibilities they haven’t considered and help build something neither person could have imagined alone.

3. Write vanilla code… by shepherding a bunch of agents

This is the direction I find least compelling: doing roughly the same work inside a company, except now you supervise coding agents.

There will be valuable jobs like this. But if your ambition extends only to completing the same backlog faster, you’re underusing the moment.

I’d still get very good at engineering. Then I’d be deliberate about what that ability sits next to: a technical frontier that needs advancing, or deep knowledge of a problem worth solving.

Use the fact that you can build more to take responsibility for something bigger.