What Stays Human When Everyone Can Build?

Pierpaolo Baccichet on why the "will AI replace engineers" question misses the point, where human judgment matters most when writing code becomes easier, and the contrarian case for people management. A full audio version of this interview is on Spotify.

Three Takeaways

• "Will AI replace engineers" is the wrong question. Baccichet's answer is unequivocal: there's no situation where you shouldn't have people building products for other people. The question worth asking isn't whether engineers are needed. It's where human judgment matters most once writing code stops being the hard part.

• The human work is moving, and not to where you'd expect. Writing code is commoditizing, and even code review is starting to automate. What stays human moves up the stack: planning, context, coordination, and the company-level vision that keeps a fast-moving team from fragmenting into a dozen disconnected pieces.

• The job is getting more human, not less. The individual skills that hold their value are debugging, business context, and collaboration. And at the team level, Baccichet makes a contrarian case: this is a great moment to be a people manager again.

Introduction

The loudest version of the AI story is a replacement story. The narrative goes something like this: software engineers used to write code and bolt the pieces together. Now that AI can do the bolting, the roles go away.

Pierpaolo Baccichet doesn't buy the premise. His belief: there is no scenario where you don't have people. There is always a pool of people responsible for a product, and another pool of people who use it. That's the part the replacement story keeps forgetting.

But If people are non-negotiable, where exactly does human effort go now that writing code is easier? Baccichet has spent his career in a good position to answer it. He was the senior-most individual contributor at Dropbox, ran enterprise engineering at Airtable, and is now a software engineer at Sierra. The question he keeps returning to is not whether humans are needed, but where.

First, Where Humans are Needed Less

Baccichet's framing is to lay an engineer's skills out as a sphere: anything in the middle gets commoditized, and writing code is squarely in the middle. He's candid that this stings for someone who spent years building his skillset in that middle. 

Then there's the more surprising one. Baccichet used to believe code review was a place humans had to stay in the loop. He's changed his mind. The automated reviewers, he says, now leave comments that are simply better than what he'd write himself on the narrow, mechanical parts of a change. They still miss the taste and the business context, but he already relies on them for line-level work. 

So if it isn't the typing, and increasingly isn't the line-by-line review, where do the people go?

Make the Work Coherent

The first answer is perhaps the least glamorous, but arguably the most urgent: someone has to keep the work coherent.

Here's the pattern Baccichet says he now sees in conversation after conversation: It has become trivially easy to spin up your own internal tool for any task (call it Task X). It has not become any easier to find out that a colleague already solved X-prime last week. So teams accumulate X, X-prime, and X-double-prime, with no one positioned to reconcile them. 

His example is simple: if ten people each build their own capacity-planning exercise, you don't just get wasted effort, you get negative value, because ten conflicting plans produce confusion instead of alignment.

There used to be a saying that you ship your org chart. Now, Baccichet says, you ship your agents, and the result is a product that's even more granular and fragmented than before. He points to Linear's CEO, Karri Saarinen, who has been making a related argument in his writing: when execution gets cheap, building more for its own sake fractures the product, and every feature ought to earn its place. Ten capacity-planning tools cost you alignment. Ten features with no unifying vision cost you a customer who can no longer tell what your product is for.

This is the first place where human work matters heavily: collaboration, alignment, and the company-level vision that keeps a swarm of parallel threads pointed in one direction. Baccichet thinks planning in particular is highly underrated right now. Most of the "spend more time planning" advice going around, he says, is really about prompting your own agent better. The thing that's actually scarce is coordination at the level of the team and the company, and that's exactly the part he feels is now often missing. 

The Case for Managing People Again

The second area is the one Baccichet feels most strongly about: this is a great moment to be a people manager again.

The logic is structural, not sentimental. When individual output was capped by how fast a person could type, a team's progress was roughly the sum of its parts, and much of management was just removing blockers. Lift that cap and the binding constraint moves. The risk is no longer that people go too slowly; it's that the fastest people go so fast they come unhooked from everyone else. Isolation here isn't a character flaw but a byproduct of velocity: the more someone can accomplish alone, the easier it is to drift out of contact with the team's direction, and the harder it is for anyone to notice until the work has quietly forked. The 10x engineer who runs unmanaged doesn't pull the team forward. They pull away. (His image for it is a child's cart with a short cord, kept close so the child comes along instead of being left behind.)

That recasts the people-versus-builder debate as a false choice. Keeping a team connected is not a retreat into soft, hands-off management; it still demands knowing what's hitting the codebase and why, why the team chose tool A over tool B, where the system is centered. The manager who matters in this phase isn't the one who writes the most code, nor the one who runs the warmest one-on-ones. It's the one who can do both, and who treats the team's coherence as something to be actively maintained rather than assumed.

What Stays Human for the Individual Engineer

Back to the sphere. If code is the commoditized middle, the durable value sits on the outer edges, and Baccichet names three things:

• Debugging. When something breaks, he says, you can watch a Slack channel fill with people pasting the model's diagnosis of the day and spinning up wild theories, until one engineer who actually understands the system finds the root cause. Underneath debugging is systems knowledge. For people coming out of school, that knowledge is still enormously valuable.

• Business context. Without it, you ship the output of an agent instead of something the product needs.

• Collaboration. Baccichet thinks of engineering as a craft and an ensemble. The point of an ensemble is that a group of people make something together. His worry is that the industry is short on conductors right now: the most capable people are all heads-down playing their own instruments, so no one is directing the orchestra.

In the old world, writing code was slow enough that you could coordinate on a slow cadence: biweekly sprints, a couple of standups a week. Now that the building is fast, coordination has to become almost real-time, spotting a lapse and pulling a person or an agent back in before they've drifted too far. The human work didn't get easier. It got faster, and more constant. The conductor never really gets to put down the baton.

What this Means for Leaders

If human coordination is where the value now sits, the practical move for leaders is to invest in building it out. Historically, a team might put 5 to 10% of its engineering capacity into internal tooling, and usually only when forced to. Baccichet thinks that number is heading toward 20 to 30% in the near-term, and that it will pay off in a way it never has before. The highest-value version of that work is making sure your agents can safely reach the same information a human engineer can, which is harder than it sounds.

There's an economic edge that makes this urgent. Friction in a developer's workflow no longer taxes only human time. It now taxes token spend, too. While more companies are growing increasingly aware of tokenmaxxing’s pitfalls, the reality is that the practice is still rampant, meaning that anything that slows an engineer down is now pulling on two budgets at once.

The industry is organized, for the moment, around how much any one person can produce. Baccichet's case is that the people who matter most in this next phase are the ones doing the work that raw production keeps breaking: holding the product together, keeping the team connected, and remembering that all of it is ultimately built by people, for people. The code was never the point, it was the people.

For more episodes of Stack Trace, subscribe to Span's YouTube channel or to the Stack Trace podcast on Spotify.