Questioning Tradition in the Age of AI

The software engineering team is one of the most entrenched structures in technology. We take it as a given: engineers must be assembled into teams, huddled around backlogs, standups, and shared responsibility. But is this necessity — or simply tradition?

Services, systems, and features can be scoped tightly enough that one person can own them end-to-end.

The assumption behind teams is that software is too complex to be built by individuals. Yet much of modern work is divisible. Services, systems, and features can be scoped tightly enough that one person can own them end-to-end. When that happens, something remarkable shows up: accountability, clarity, and ownership.

When one person owns a project, evaluation becomes straightforward. Did they deliver the outcome or not? Performance is no longer lost in the fog of group effort. Focus sharpens, distractions fall away, and responsibility rests squarely where it should. Compare this with teams, where accountability is diffused, ownership is diluted, and effort is often spent maintaining the appearance of productivity rather than achieving outcomes.

This isn't just about efficiency; it's about preparing for the future. AI is not going to make engineering more team-dependent — it's going to make it more individual-friendly. One engineer, with AI at their side, can deliver what once required a team. The logic of the past — that many hands are needed for heavy work — no longer holds in the same way. The leverage has shifted.

So why cling to tradition? If the work can be scoped to an individual, it should be. Teams may still serve as cohorts — groups of people in the same domain, sharing ideas and context — but not as units of accountability. The future of software engineering is not about swarming; it's about clear ownership and measurable outcomes.

The question is simple: are teams necessary, or are they just a habit we've mistaken for truth? In an AI-centered future, the answer seems clearer than ever.