My current project spans three layers: C++ at the bottom, Java in the middle, Vue on the front end. The old way of shipping a new feature went like this: pull engineers from all three stacks into the same room and hash out the API contracts. To avoid rework later, we’d freeze a “golden API document” up front, and each stack would build against it.

The cost wasn’t just the meetings. To keep that document stable, we had to anticipate implementation details before any code was written, which front-loaded all the architecture-vs-feature tradeoffs. Every miscall meant downstream coordination pain. As the person sitting between three stacks, I knew that pain well.

A year ago I started folding Claude Code into my workflow, asking: can it eat this coordination tax?

A solo cross-stack experiment

Earlier this year I picked up a feature unrelated to my usual agent-product work. I told my team lead: let me try doing this one alone.

My home turf is C++ and Python; I know almost nothing about Java or Vue. I wasn’t fully confident going in, but I’d been experimenting with Claude Code’s agent-team mode for a while and wanted to push it further.

The setup: in a single session, I had Claude Code spin up a four-member team — Vue Engineer, Java Engineer, C++ Engineer, QA Reviewer. In the main conversation, Claude Code and I pinned down the feature shape and a few key APIs. The three stack-agents then went off in parallel. After every atomic commit, the QA Reviewer stepped in for a review pass.

I told the agents to debate API design among themselves. That alone collapsed the human-to-human coordination cost we used to pay. The bigger win was mid-flight refactoring: previously, changing an API mid-feature meant reconvening three stacks — a deeply unpleasant ordeal. Now, one sentence to the agent team and the whole stack realigned.

This doesn’t mean upfront design disappears. It means what you design up front shifts — there’s less of it. What you think about up front isn’t a frozen API document anymore, but boundaries and constraints — HN has plenty of discussion on this shift.

Now, I’m more of a tech-literate PM.

The sliced-cake problem

The old way of making a cake was layered: bake the base, spread the cream, decorate the top. The new way looks more like slices — each person bakes one complete slice end-to-end, and you assemble them at the end.

But this introduces a new problem. If the slices use different sizes or different recipes, the assembled cake looks weird and tastes off. For someone who cares about quality, that’s unacceptable.

Before merging to main, I asked the most experienced front-end engineer on our team to take a look. He gave me a few notes on code organization and type-checking, and wrote up a short refactoring document. I handed that document to Claude Code, and thirty minutes later the front-end code matched our team’s conventions exactly.

In hindsight, I should have asked for that refactoring spec at the very start. The agents would have been baking the right shape of slice from the beginning.

Two roles, not three teams

This experience made me rethink team structure. I’ve since had this conversation with a few colleagues.

In an agent-native team, you really only need two kinds of engineers:

1. Foundation maintainers — people who own the base, conventions, and tooling for each layer. You don’t need many; one or two per layer is enough.
2. Feature owners — people who understand the business deeply and own a feature end-to-end across stacks.

A few people make the Lego blocks. The rest build with them.