A specialist can survive

I fancy myself a builder - I’m a product leader who has moved beyond just vibe coding through an appreciation of the engineering work and craft that goes into a scalable, maintainable production codebase.

I didn’t start that way. When Claude Code dropped in early 2025, I was building prototypes daily. Every idea I’d had for the past two years, every backlog item and forgotten fast follow got a prototype.

And out of the hundred or so features I vibed, maybe 10 ended up in our repo. Most projects ended with the same sorts of conversation with my engineering team - ‘that’s not how our codebase works’, ‘you re-created a pattern we already used’, ‘this data model is terrible’, and ‘can you please stop’.

But I didn’t stop. I listened, had lots of fascinating conversations, and asked my coding agents to explain what was going on in the codebase. I started building higher quality features in smaller and smaller chunks. And the features I prototyped began to need fewer changes to become production ready.

In short, I improved my ability to think and work like an engineer. I became a builder.

During my journey of self-improvement, the world gained the capability to run workflows, agents, loops and teams of specialized personas with specific skills.

Now anyone, engineers in particular, can spin up whole teams of specialists in product, design and systems architecture instantly.

Naturally, this led to a few questions:

• When everybody has access to everything required to create software, should the roles we’ve previously held still exist?
• Do we even need engineers or product or design or any humans at all to build new technology?
• Are the lines between functions blown out of the water? Or are they just a little blurred?

What’s happening on the ground

Tech companies have been combining functions for years before AI was on the scene.

Historically, in terms of labor substitution, the most common path was for engineers to become Technical PMs or Product Owners. I’ve spoken with several fintechs at least who don’t have any product roles in their organization anymore, you’re either an engineer or you’re part of the business.

That may work in certain verticals where engineers are building for other engineers. But for every team to adopt it would be short-sighted.

Just as programming patterns, libraries, architectural choices and data model designs should leave scars as you earn as you build and learn, the customer discovery interviews and metric development skills are learned, practiced and honed over time

I think this type of organizational thinking limits innovation and leads to:

• disconnect from product strategy
• difficulty determining the correct outcomes that will drive the business’ key metrics
• lack of context for how the customer operates
• customer request factories

Engineers are still certainly in demand. Product Managers are in demand too. But there are fewer roles per candidate than two years ago. I haven’t seen a Product Designer job description in months. I’m sure they’re out there, but they are scarce. Certainly no open junior roles since manual UI work has been automated away.

Hallmarks of great teams

I’m a firm believer that the best teams are composed of specialists with a general understanding of other functions in the organization. They’re often led by generalists who can spike deeply in an area of expertise. The most successful companies who are harnessing AI to empower their product and engineering teams are maintaining specialized roles. And there are longstanding organizational design principles behind it.

It’s how the world's elite special forces organize themselves, it’s how corporate boards operate, it’s the foundation of trade theory and it’s how every successful movie heist has been pulled off.

Cross-training is critical to leveraging a specialists’ skills and expertise within any team.

The more familiar a team member is with the work of an adjacent teammate, the easier it is to anticipate that teammate’s actions, mutually support one another, build trust, challenge each other’s ideas and engage deeply in the creative process required to innovate.

Specialists will continue to grow their experience in adjacent functions. They’ll undoubtedly learn while doing so, becoming more adept over time. In the process, they will continue to orchestrate and direct fleets of agents.

The organizational design challenge has changed to getting those fleets to work well together, with a decreasing amount of human specialist intervention.

The solution is not to only hire engineers and expect them to be product managers and designers.

Practically, you solve this by harnessing your team.

• Specialists encode their knowledge into sets of rules for how you want the team and their agents to build and work
• These rules are learned, flexible and should evolve over time at the direction of the specialists or context owner
• This way, we reframe the solution to technological capability from doing everything yourself and checking whether it’s correct to thinking about the right work to be done and directing it within the harness
• it’s not a blending of roles, it’s encoding the right behaviors

This all trends toward smaller, flatter product and engineering organizations, but it is a mistake to think that it eliminates the need for specialized functions exercising judgment in their domains and across their agents.

Even though Claude Code was started with just engineers, it grew and scaled with a product manager, a designer and a data scientist - the specialists had their day in the sun.