The next hire or the next GPU

One product owner, one architect, one senior engineer, and an agent factory can now do what recently required a conventional software team.

The team has already changed

I do not think the next software team will be a smaller version of the last one. It will be built differently.

Today, a product owner, an architect, and a senior engineer can launch and operate a serious software project without recruiting a conventional development team around them. The reason is not that architecture, judgment, or responsibility have disappeared. The execution layer has moved.

AI agents can research the problem, prepare a plan, write the code, create and run tests, review the implementation, look for security defects, update documentation, prepare infrastructure, deploy the release, monitor the result, and investigate failures. They can do that in parallel and continue when the working day ends.

The people do something else. The product owner decides what should exist and why. The architect decides what the system may become. The senior engineer turns those decisions into work that machines can execute and proves that the result is safe to accept.

The new shape is a human control layer over a software factory. The old rule was simple: more work requires more developers. That rule is no longer generally true. When the factory has more ready work than it can process, the first scaling question is no longer always “who do we hire?” It is “what is the constraint?” More agent processes, more memory, a faster model, more GPU-hours, or a larger API budget may add the missing capacity without adding another permanent seat. This changes the company. It also changes what it means to be a developer.

The new software team

The smallest useful human core is a small group that owns intent, architecture, verification, and consequences.

Layer	Owns
Product owner	The problem, priorities, constraints, and the business definition of done.
Architect	System boundaries, data, interfaces, security model, failure modes, and technical direction.
Senior engineer	Task decomposition, agent context and tools, implementation control, verification, integration, and production diagnosis.
Agent factory	Research, plans, code, tests, reviews, security checks, documentation, CI/CD, deployment work, monitoring, administration, and investigation.

These are roles, not necessarily three job titles in every company. One experienced person may carry more than one of them. What matters is that the responsibilities exist and that they remain connected to a named human. The human core does not manually reproduce every artifact the agents create. If it did, there would be no new operating model. It defines the system, gives the factory bounded authority, and checks the evidence needed to accept the result. Humans remain at the points where judgment cannot be reduced to a completed checklist: ambiguous product choices, architecture with long consequences, access to sensitive systems, irreversible actions, legal or reputational risk, and the final acceptance of production behavior. Everything else is a candidate for the factory.

A small human core owns the decisions. The agent factory performs and checks the work.

A Microsoft Research study of 448 Microsoft developers found that accepted AI autonomy varied across tasks and individuals. Acceptance was lowest for design-oriented and human-facing work, while greater AI experience and the developer’s own risk tolerance were associated with higher accepted autonomy. Task accountability reduced willingness to let AI act independently. The useful boundary is deliberate authority with an accountable owner. (Microsoft Research)

This is not a prediction

At Sugra, the shape already exists. At Sugra, one person currently carries the product-owner, architect, and senior-engineer responsibilities. The agent factory performs the execution layer; accountability stays human.

In Everyone predicts AI will replace engineering teams, I described a system where a queue of work moves through isolated agent environments, implementation, tests, independent reviews, deployment, and live verification. The factory spans seven repositories and three live products. The human is not sitting beside one autocomplete window. The human is directing and accepting a pipeline.

In 6 months, 527 AI code reviews, 4 agents, 61 of 227 completed changes still contained a serious defect when another agent reviewed them. That is why “the model wrote the code” is not a result. Independent review, tests, production checks, and an accountable human are part of the product.

The industry examples have moved beyond toy demos too. Anthropic described a Rust-based C compiler built by 16 parallel agents over nearly 2,000 sessions and two weeks, at a cost just under $20,000. The result was about 100,000 lines and could compile Linux and other real projects. It remained a research prototype rather than a drop-in compiler: it still used GCC for 16-bit x86 boot code, and its generated code was less efficient than unoptimised GCC output. The human built the environment, tests, and feedback loops. The agents performed the volume of implementation. (Anthropic)

The lesson is not that every project can delete its engineering department tomorrow. The lesson is that implementation capacity can already be separated from permanent headcount. Once that separation exists, the structure of the team has to change.

Scale compute before headcount

The traditional scaling function looks like this:

more backlog -> more developers -> more managers -> more coordination

The new scaling function can look like this:

more ready work -> more agent parallelism -> more compute

That second line works only while the work can be split, the context is available, and the human acceptance path keeps up. Compute cannot repair a vague product decision or take responsibility for a bad architecture. But when execution is the constraint, adding another process is different from recruiting, onboarding, and coordinating another permanent employee. This is why I treat compute as engineering capacity.

Three NVIDIA DGX Spark units are a useful example of one basic owned cluster. Together they provide 384 GB of split memory across three nodes and a documented direct-connect topology. The cluster can run and check selected open-weight models. Whether that is enough for ordinary development work is what the pilot has to show. It is a starting resource, not the ceiling. (NVIDIA Docs) (NVIDIA) If that cluster is insufficient, the answer is not automatically another employee. The next unit can be a rented H100, H200, B300, a larger cluster, or an API call to a stronger model. The company should add the resource that relieves the measured constraint. This is the important change: software output no longer has to grow in direct proportion to the number of developers on payroll.

The execution career is disappearing

The junior developer is not being replaced by a better junior. The work that made junior development a paid profession is being absorbed by agents. Take a prepared task. Read the description. Find the relevant files. Write a conventional implementation. Add tests. Fix the linter. Open a pull request. Respond to routine review comments. Update the documentation. This was the entry point into software development. It is also exactly the class of work that agents are learning to perform end to end.

The traditional mid-level role is next. A person who can independently execute familiar work inside an existing architecture is valuable in the old team because execution capacity is scarce. In an agent factory, execution is the resource that can be multiplied. The scarce resource becomes the ability to define the work, understand the system, detect a plausible mistake, choose between tradeoffs, and own the consequences.

I do not expect junior and mid-level development to survive as stable professions in their current form. The titles may remain for a while. The work underneath them will not. Senior engineers and architects remain, but a title does not protect anyone. A senior who forwards prompts and accepts plausible output is performing the same disappearing execution role with a more expensive label.

The profession is moving upward:

• From writing a change to defining the system in which changes are safe.
• From completing a ticket to deciding whether the ticket describes the right thing.
• From reviewing syntax to designing evidence.
• From knowing one stack to understanding boundaries, failure modes, security, and production behavior.
• From being responsible for personal output to being responsible for a fleet’s output.

That is not management in the old sense. It is self-sufficient technical ownership.

Who becomes the next senior?

Removing entry-level work creates a problem that the industry has not solved. If agents perform the tasks through which beginners used to acquire judgment, where will the next senior engineer come from? A 2026 qualitative study based on 14 interviews with junior and senior software engineers in South Korea asks exactly this question. It reports that generative AI is absorbing entry-level tasks into senior-plus-AI workflows while weakening the apprenticeship path that produced future senior engineers. Fourteen interviews are not a labor-market census, but the mechanism is already visible. (Who Will Become the Next Senior?)

The employment signal is visible too. Stanford’s Digital Economy Lab reports that, in data through June 2026, employment among workers aged 22 to 25 in highly AI-exposed occupations stood about 19% below where it would have been had it kept pace with similarly aged workers in less-exposed occupations. The authors describe this as a descriptive pattern, not a causal estimate. It still matters because the first break appears at the entrance to the career. (Stanford Digital Economy Lab)

There is a second risk. A beginner can produce more and learn less. Anthropic studied 52 mostly early-career engineers learning an unfamiliar library. The AI-assisted group scored 50% on the final test, compared with 67% for the group without AI, with no statistically significant speed-up on the assignment. People who used AI for explanation and understanding learned more than those who delegated the implementation. (Anthropic)

A company can get code faster and stop producing people who can understand it. That is not a successful transformation. The replacement for the old ladder cannot be “let the agent do everything until you somehow become senior.” Beginners need a harder and more deliberate path:

• Explain why an agent’s solution works, not only whether its tests pass.
• Find seeded defects and trace their consequences.
• Reconstruct architecture from a live system.
• Write constraints, threat models, acceptance criteria, and rollback plans.
• Diagnose incidents with incomplete evidence.
• Take responsibility in stages, under review by someone who already has judgment.

The next generation will have to enter the profession higher up. They must learn to understand the system, direct the machine, verify its work, and own the result.

Anyone who stops learning is old, whether at twenty or eighty.
Anyone who keeps learning stays young.
Attributed to Henry Ford.

Learning is no longer general career advice. It is the condition for remaining in the profession.

Measure the factory, not the demo

The argument for a new team cannot rest on a successful prompt or a machine running all night. The unit is accepted project capacity. Product ownership is in both options, so the comparison is the engineering layer:

Baseline:
product owner + N engineering seats

Alternative:
product owner + architect + senior engineer + agent compute

Net added capacity:
accepted output(architect + senior + AI)
- accepted output(the same architect + senior without AI)

The architect and the senior engineer stay on both sides. Their pay is not a saving. Three engineers becoming two plus compute avoids one seat. Five becoming two plus compute avoids three.

Scenario	Seats avoided	Replaced layer at $2,000 per month over 36 months
3 engineers to 2 + compute	1	$72,000
5 engineers to 2 + compute	3	$216,000

The $2,000 figure is a deliberately low sensitivity case, not a market estimate. Replace it with the company’s own fully loaded seat cost. Higher seat costs lower the break-even capacity required from the factory.

Count only the execution layer that the factory actually replaces.

If headcount stays the same and accepted output rises, that is added capacity, not a payroll cut. Count the full AI bill: hardware or rental, API calls, power, housing, maintenance, and any new operator. Compare it with fully loaded employment cost, not salary alone. A $100,000 envelope over 36 months is about $2,778 a month. At a $2,000 seat, break-even is 1.39 net FTE. At $6,000, 0.46 net FTE. At the $2,000 sensitivity, avoiding one seat does not justify a $100,000 envelope. The factory must add at least 1.39 net FTE, or its full cost must stay below $72,000. Saying three seats were replaced requires both: net output of at least 3 FTE, and an AI bill lower than those three seats. Cheap compute on the wrong work, or fast output that jams review, has not freed anyone.

A test that can fail

Run the first test on a fixed mix of task types: integrations against an approved contract, reproducible fixes, tests, documentation, and other work with written acceptance criteria. Randomly assign comparable ready tasks across three arms during the same 30-day period:

1. The architect and senior engineer without the agent factory.
2. The local cluster with the same human core.
3. An API or rented-GPU path with the same human core.

Track and normalise human time separately for each arm. Use one acceptance bar. Require at least 20 accepted tasks in each arm; 20 tasks across all three arms are not enough for a useful comparison. A historical baseline can size the test, but cannot replace the human-only control.

For 30 days, record what was accepted, rejected, redone, left unfinished, how long it took, human time, idle compute, and defects after merge. Do not call the pilot on fewer than 20 accepted tasks. Use the worst week, not the monthly average. Day 30 is preliminary: each accepted task still needs its own 60-day defect window before any expansion, so work accepted at the end of the pilot can push the decision to day 90.

Stop if net output misses break-even, if review grows faster than generation, if the API wins per dollar, if the machines sit idle, or if later defects erase the gain. The new team wins only when the accepted result wins.

Own, rent, and use the API

The practical model is hybrid:

owned base capacity
+ rented burst capacity
+ API capability where it wins

The three-unit DGX Spark cluster is the base example. If its speed or split memory becomes the constraint, rent a datacenter GPU. If model quality becomes the constraint, use the API. If acceptance becomes the constraint, strengthen the human core. The goal is not to own the most impressive machine. The goal is to stop treating permanent headcount as the only form of engineering capacity.

The decision

The next software company does not need a person for every recurring task. It needs a small number of people capable of owning the whole system and enough compute to execute the work they define. That makes the product owner, architect, and senior engineer more important, not less. It also removes the comfortable execution layer beneath them.

For companies, the decision is whether to scale accepted output by adding people, adding compute, or changing the process. The answer must come from the constraint and the measured result. For developers, the decision is more personal. Remaining a reliable executor is no longer a durable career plan. The machine is becoming the executor. The next developer must understand the problem, design the system, direct the agents, challenge their output, and accept responsibility for what reaches production.

The next unit of engineering capacity may be compute, not headcount. The open question is who we train to own it next.

Appendix: the compute ladder

This is a reference for scaling the factory, not a claim that hardware creates capability by itself.

Owned base cluster. Three DGX Spark units provide 384 GB of combined LPDDR5x memory across three nodes. The memory remains split. NVIDIA documents a direct ring of three QSFP connections. In February 2026, NVIDIA raised the US MSRP of the DGX Spark Founders Edition from $3,999 to $4,699 because of worldwide memory-supply constraints. Three units therefore have an MSRP of $14,097 before shipping, taxes, cables, power, and bring-up. (NVIDIA) Current availability and partners are listed separately, and that page does not state the price. (NVIDIA Marketplace)

One owned base cluster. Add a different class of resource when the workload proves the need.

Stronger rented capacity. A single H100 has 80 GB of HBM3, an H200 has 141 GB of HBM3e, and a B300 has 288 GB of HBM3e. These are not simple memory upgrades from Spark. They are different machines for different speed, memory, and model requirements. (NVIDIA H100 and H200) (NVIDIA B300)

Resource	Memory	Use it when
3x DGX Spark	384 GB LPDDR5x, split	Selected open-weight models. The pilot confirms whether the workload fits.
1x H100	80 GB HBM3	Faster memory and datacenter throughput matter more than the larger split pool.
1x H200	141 GB HBM3e	One accelerator needs more memory for the selected model or context.
1x B300	288 GB HBM3e	A current-generation accelerator is the measured requirement.

Rental snapshot, September 2026. Nebius then listed on-demand H100 at $3.85, H200 at $4.50, B200 at $7.15, and B300 at $7.85 per GPU-hour, excluding VAT. At that H200 rate, 100 GPU-hours cost $450, and continuous use for a 30-day month costs about $3,240. A burst and a permanent load are different purchases. The list will move. (Nebius)

The API remains on the same ladder. Pay for the strongest hosted capability when it wins. Own the stable baseline when ownership wins. Rent the burst when the need is temporary.