Components, Not Features

Merge conflicts aren’t a team problem. They’re a decomposition problem.

Divide work by feature and you cause the collisions, because a feature reaches across everything: UI, API, data layer, shared utilities. Two developers each “owning a feature” end up editing the same files and stepping on each other. Merge conflicts are the visible version. The worse versions are semantic: two changes that merge cleanly and break each other anyway, because both sides made assumptions about shared state that were true on their own branch.

Divide by component instead, bounded units behind stable interfaces with one owner each, and parallel work rarely touches shared code. I’ll stop short of “collision-free,” because nothing is. The lockfile is shared. The schema is shared. The contracts themselves are shared, and every real repo has one file everybody edits. What decomposition buys you is that collisions become rare, local, and predictable: they happen at the boundaries you drew, where you’re watching, instead of anywhere two features happen to overlap. That’s not perfection. It’s the difference between a border checkpoint and a demolition derby.

The honest cost, stated up front: component decomposition doesn’t remove coordination, it relocates it. You pay front-loaded, in boundary design and interface contracts, and you pay again whenever a contract has to change. The tradeoffs are the classic ones, silos, integration risk, nobody owning the end-to-end experience. None of this is new. Vertical versus horizontal slicing, component teams versus feature teams: the industry has argued this for decades, and the argument usually lands on feature teams, because for humans the end-to-end ownership is worth the collisions.

So why write this in 2026? Because the same discipline turns out to govern AI agents, and there the argument lands the other way, though not for the reason you’d guess.

It’s not the merge conflicts. Agents resolve textual conflicts fine now; the diff collision is cheaper than it’s ever been. The durable danger is the semantic one, and it’s worse with agents than with people. A human developer who hits a confusing overlap stops and asks. An agent doesn’t get confused, it gets confident, and plows ahead on assumptions that stopped being true two merges ago. Nobody in that loop notices until something breaks. Clean component boundaries are how you make the divergent-assumption problem structurally rare instead of hoping a reviewer catches it. I run several products this way now, and the difference between “agents are magic” and “agents are a mess” has been, in my experience, almost entirely a function of how the work was cut before any agent touched it.

One objection I expect from good engineers: “good teams don’t have merge conflicts.” Exactly. Good teams already decompose well, which is why they rarely collide. The point isn’t that decomposition is novel. It’s that the same decomposition good teams were already doing is the thing that unlocks agents. Component thinking turns out to be table stakes for any parallel build, human or machine. It is not what separates teams from solo.

The sharper objection cuts closer to home: you can’t decompose what you don’t understand yet. Boundaries drawn on day one of a new product are guesses, and I’ve argued elsewhere that solo-plus-AI wins precisely at discovery, which is exactly when the guesses are worst and the contracts churn most. So am I prescribing the most boundary-hungry structure for the phase with the least boundary knowledge? Yes, and here’s why it survives: the cost of a wrong boundary isn’t drawing it, it’s redrawing it. On a team, redrawing means meetings, renegotiated ownership, sometimes a re-org. Alone, it costs one decision and an afternoon of moving code. Draw cheap boundaries early, expect to be wrong, and redraw without ceremony. The structure is the same. The price of changing it collapsed.

Which is the frame worth keeping: two layers, not one. Architectural coordination is how you cut the work. Social coordination is how humans stay in sync about the cut. AI didn’t remove the first, and won’t. You still design clean boundaries no matter who or what your workers are, and you still redesign them when they’re wrong. It removed the second. That’s most of the story, and it’s why the oldest skill in software architecture is suddenly the newest requirement for working alone.