-->

Engineers Aren’t Going Away. They’re Just Changing

In May and June of 2026, Jensen Huang repeated the same message from the stages of Computex and GTC Taipei: “Every engineer is going to have and manage hundreds of agents.” For anyone who believed that writing code directly was the entirety of an engineer’s job, this declaration strikes at the foundation of their career.

Yet this statement is not about the elimination of jobs. Break apart the phrase “going to have and manage” and you find that the engineer is still the subject, with agents as the resources they operate. Just as factory automation didn’t eliminate factory workers but made floor managers more important, the age of agents demands orchestrators.

This essay examines what questions that transition poses for organizational culture. It is not a summary of technology trends — it is a cultural essay asking how teams should be structured, how work should be distributed, and how performance should be measured.

The 100:1 Organizational Unit

In a Fortune interview in March 2026, Jensen Huang put a specific number on it. NVIDIA is preparing for a future in which 7.5 million AI agents coexist alongside its 75,000 employees. That is, by simple math, 100 agents per human.

Even if that figure is an exaggeration, the direction it points is clear. If organizations once gauged scale by headcount, going forward the number of agents will be the substantive resource metric. The structure in which a startup of ten people can take on competitors with hundreds is already underway.

From an organizational design perspective, this is not merely a productivity improvement — it shakes the management structure itself. Traditional teams were squadded by headcount, and leaders generated results by managing people. But how does a conventional manager oversee an engineer running a hundred agents? Instead of “What did you get done this week?”, the right question may now be “What are your agents handling right now?”

What It Means to Manage Agents

Around the same period, Huang explained in another statement why software companies aren’t dying: “AI agents still need an application layer to convert tokens into actual workflows.” The logic is that the more agents proliferate, the more important the layer that coordinates them — orchestration capability — becomes.

The work that remains after automation is not simple repetition but judgment and coordination. What to assign to an agent, how to verify what an agent produces, and by what standard to arbitrate when agents conflict — all of this remains human work.

Paradoxically, the proliferation of agents increases the scarcity of judgment. Not the person who codes well, but the person who knows what should be built, who can critically evaluate an agent’s output, and who can decompose a task objective into clear instructions — these are the organization’s core resources.

This changes hiring and evaluation criteria. “Are you good at Python?” matters less than “How would you catch an agent when it’s wrong?” It is not an overstatement to say that hiring for mindset over tech stack has already begun.

The nature of onboarding changes too. Traditional new-engineer onboarding meant getting familiar with the codebase and the pull-request process. In the age of agents, onboarding means understanding the team’s running agent portfolio — which agent handles which task and where human intervention is required. What a new hire must learn first may not be system architecture but the agent ecosystem.

What Happens When Tokens Are Half Your Salary

At the GTC Taipei keynote in June 2026, Huang floated a more radical idea: paying half of an engineer’s base salary as a token allocation, with the goal of achieving 10x efficiency. This is not merely an HR policy idea — it is a declaration to change the very unit by which productivity is measured.

Until now, metrics for measuring developer productivity have always been imperfect. Commit counts, PR counts, lines of code have weak connections to actual business impact. DORA metrics (deployment frequency, change lead time, mean time to recovery, change failure rate) serve as supplements but are still indirect.

The idea of a token allocation opens a different angle. The compute resources an agent consumes define the scope of the work, and whether the output justifies the token cost becomes the performance metric. This may sound extreme, but it creates a cultural pressure to show in data how efficiently you used AI infrastructure this month.

An engineer handed a token budget must design and operate their own agent portfolio. Which agents to spin up, when to intervene, when to trust the automation — these abilities cannot emerge without experience and context. That is why the meaning of seniority changes. System judgment over coding experience, the ability to decompose tasks over technical depth — these become the markers of tenure.

There is a paradox here too. The person who consumed the most tokens did not necessarily produce the most results. The engineer who ran agents efficiently to achieve the same outcome with fewer tokens may be the better engineer. This has the same structure as cloud infrastructure cost optimization. The era in which writing a lot of code quickly was a virtue is giving way to an era in which correctly directing agents and achieving maximum output with minimum resources is the virtue. What an organization praises and what results it measures define that organization’s culture. The token budget idea is also a proposal to change that unit of measurement.

When the Factory Becomes the Robot: Implications for Organizations

In a Fortune interview in May 2026, Huang extended his gaze to the physical world: a world operated by agents, managed by more robots, where the entire factory becomes one robot. This is not science fiction — it is already underway in semiconductor fabs and logistics warehouses.

From a cultural perspective, the implication of this change is not speed but the redistribution of accountability. When an automated system makes a mistake, who is responsible? When an agent deploys faulty code or handles an error incorrectly — was it the person who designed it, the person who gave it instructions, or the person who skipped the review?

These questions existed before the age of agents. When an automation script wiped a production database — was it the person who wrote it, the person who ran it, or the person who didn’t review it? That debate is not unfamiliar. The difference is scale. If agents number in the hundreds and the work they handle extends beyond code deployment to business decisions, the size of the risk from unclear accountability structures changes entirely.

Organizations that already have answers to these questions cause fewer incidents. Clearly defining the boundaries of automation scope, establishing by procedure which decisions always require human approval, and having the entire team share the habit of verifying agent output — that is what quality culture in the age of agents looks like.

This issue appears beyond software teams in broader organizational units as well. When a sales agent quotes a customer an incorrect price, when a legal agent misinterprets a standard contract and guides someone to sign — these are already scenarios in which “agent error” becomes corporate risk. That is why adopting agents is both a technical decision and a governance decision. Deciding which agents to grant which permissions, and which tasks always require a human to confirm, is not solely the CTO’s decision — it must be a decision for the entire executive team.

For AI infrastructure platform teams, these discussions have already arrived as real operational questions. When scheduling agent tasks, automating deployments, and running dozens of agents simultaneously in a multi-tenant environment, the question “who is watching this?” is not a surveillance problem but a problem of accountability structure. Technically building an orchestration layer and embedding an orchestration culture inside the organization are entirely different undertakings.

Conclusion: Three Things Organizations Must Develop in the Age of Agents

The pace at which Jensen Huang’s vision becomes reality is difficult to predict. But the direction is clear. The proliferation of agents does not eliminate human work — it demands a different kind of work. Organizations that fail to embody this transition as culture will end up with the tools but not the capability.

Three things organizations must develop in the age of agents:

A culture that builds judgment. The better agents become, the more refined the judgment humans must exercise. What to automate, how to notice when an agent’s output is wrong, and how to decompose goals into instructions — these abilities are not technical skills but trained competencies. Without a structure inside the team for building this judgment, agents will amplify risk rather than reduce it.

A structure with accountability attached. As agents multiply, attributing a specific outcome to one person’s credit or fault becomes harder. Leaving that ambiguity unaddressed creates a culture where no one is responsible. It is necessary to assign ownership to agent portfolios, explicitly state the boundaries of automation scope, and turn verification into procedure.

Intentional pauses within speed. Agents are fast. Accepting that speed without review turns the entire organization into a machine that repeats fast mistakes. The stages where agents process quickly and the stages where humans pause for a beat at important decisions must be consciously designed.

The world Huang has drawn is not yet complete. But that direction is already in motion. Tools can be purchased, but the culture to wield them cannot.

Sources

참고