The Rise of the Generalists

How many people does it take to build enterprise software?

For twenty years, the answer was seven or more: a product manager, a business analyst, a business stakeholder, an architect, a designer, a QA tester, and a support engineer — plus the developers actually writing code. Shipping anything meaningful took a quarter, often two.

This article explains what happened to the other six chairs, because the answer matters to anyone who builds software, buys software, or is planning a career in either.

The Old Assembly Line

The traditional model was an assembly line of specialists, and every station produced something for the next station to consume.

The business stakeholder brought the need and the budget. The product manager turned that into a roadmap and requirements. The business analyst turned requirements into detailed specs and acceptance criteria. The architect turned specs into technical design. The designer turned them into screens and flows. Developers turned all of it into code. QA turned code into bug reports, which went back to developers. And once it shipped, a support engineer triaged everything the process missed — forever.

Count the arrows in that chain. Every arrow is a handoff, and every handoff is a translation. Meaning leaks at each one. I spent over a decade working with companies and watching this play out: a requirement leaves a stakeholder's mouth, passes through three translations, and arrives in the codebase as something the stakeholder never asked for. Then the whole chain runs in reverse to fix it. The person who understood the problem was always four steps removed from the person typing the solution.

That structure existed for one reason: no single human could hold all seven jobs at once. So we parallelized, and we paid for parallelization with coordination — meetings, tickets, specs, status calls. On most enterprise projects, coordination consumed more calendar time than construction did.

The New Org Chart: The Builder and The Architect

Agentic development collapses that chain into two roles.

The Builder owns the problem end to end. The Builder talks directly to the stakeholder, shapes the requirement, directs the agents that write the code, and verifies the output against the original intent. The Builder is the product manager, the business analyst, and the developer collapsed into one person — because when agents handle construction, there is nothing left to parallelize, and the translation layers between those roles lose their purpose. The person who understands the problem is now the person shipping the solution.

The Sr. Architect validates the architecture the agents propose. Agents are extremely competent architects. In the new model, the agents still design the system and its features — they propose the data model, the service boundaries, the integration approach. What they need is a professional validator. A Builder without an architecture background has no way to judge whether a proposed approach is the right one for this system, this tech stack, and the next five years of its life. The Sr. Architect does.

The stakes here are foundational. A system's architecture is its backbone. Get it wrong early, and every enhancement and every support ticket for years afterward becomes a nightmare. The Sr. Architect is the technical generalist standing guard over that backbone: someone who understands coding principles, architecture standards across varied tech stacks, and CI/CD. In practice, these are engineers who moved into the role as demand for human developers declined. Their implementation years became their qualification for judging implementations they never have to write.

That is the nucleus of the new application development team. Two humans, and a harness that carries the institutional knowledge of the roles that used to sit between them.

Where the Other Five Roles Went

This is the question that decides whether you trust this model, so I will answer it directly. The work went to three places.

Absorbed into the Builder

Product management, business analysis, and stakeholder liaison work still happen — the Builder does them directly. These roles existed to move understanding between people. When one person carries the understanding from conversation to production, the roles merge into that person.

Encoded into the Harness

Architecture review, QA, and design standards moved into automated contracts and gates. And here is the number that surprises people: in our builds, verification effort now runs at roughly four times construction effort — a Build:Verify ratio approaching 1:4. Quality assurance grew. It moved from a person running test plans at the end of the line to a system enforcing standards at every step of it.

Automated by Agents

Test generation, regression runs, documentation, and first-line support triage are now agent work, executed continuously instead of scheduled into sprints.

The work survived. The coordination died. Seven people's worth of output still gets produced — by two people directing systems that carry the other five roles' knowledge.

What This Means for Speed

The speed gain comes from removing handoffs, not from typing faster.

Agents write code quickly, but that is the smaller effect. The larger effect is that nobody waits for anybody. There is no ticket queue between the requirement and the build, no sprint boundary between the build and the test, no escalation path between the bug and the fix. It took 6 months and 1 Builder to build Luna, our cutting edge Agent Workforce platform. The old model would have quoted a team of eight and 2+ years for the same scope, and most of that time would have been spent in the arrows between the boxes, not in the boxes themselves.

Days replace quarters because the human team got smaller, and the human team got smaller because translation became unnecessary.

What This Means for You

If you are wondering where you fit in this model, the skills that matter have shifted.

A good Builder needs product judgment and domain fluency more than syntax. If you can effectively state a problem, define what "done" looks like, anticipate the edge cases, then you can direct a build. The scarce skill is knowing what to build and recognizing when the output is wrong.

A good Sr. Architect needs breadth over depth: coding principles, architecture standards across stacks, and CI/CD fluency, combined with the judgment to look at an agent's proposed design and say "yes, this holds up for five years" or "no, this collapses at scale." The leverage multiplied — one validator's judgment now shapes every system that ships, and the engineering career path leads here as human implementation demand declines.

And an honest word about the transition: the seven-role model employed a lot of people, and this model employs fewer per product. The people who thrive in it are the ones from those collapsed roles who move toward ownership — the BA who becomes a Builder, the QA lead who becomes the Architect of the verification gates. The specialist chairs are disappearing. Welcome to the rise of the Generalists.

The Answer

So, how many people does it take to build enterprise software?

Two. A Builder who owns the problem and a Sr. Architect who guards the backbone. And you scale that base team up based on complexity and workload. 

We are proving this daily at Lunari. If you want to see what this new way of working ships, follow along.

Lunari builds agentic enterprise platforms and advises leadership teams deploying them. If this maps to a problem you are working on, we should talk****.