NVIDIA CEO Jensen Huang expects software engineers to manage hundreds of AI agents, assigning work and judging the results rather than writing every line of code themselves. That is a forecast, not a description of the average engineer’s job today. Existing agent tools can already perform tasks across software systems, but making their work dependable still requires preparation, precise direction and human review.
From writing code to directing work
In Huang’s proposed workflow, an engineer defines the architecture, writes specifications, divides a project into tasks and sets quality criteria. Agents carry out delegated work; the engineer checks whether the pieces fit the plan. The shift is less about removing the engineer than changing where the engineer spends attention: on ideas, connections between tools and decisions about completed work.
Huang uses a hypothetical annual budget to convey how much AI computing he thinks an organization might allocate to one engineer. Tokens are units of text that an AI model processes, and token spending is one way to pay for that computing.
| Item in Huang’s example | Annual amount |
|---|---|
| Engineer’s salary | $500,000 |
| AI token spending he considers too low | $5,000 |
| AI token spending he proposes | At least $250,000 |
These are figures from Huang’s scenario, not a demonstrated budget that every engineering team needs. His broader argument is that abundant agent computing could change which projects seem feasible. In practice, more computing does not by itself supply a sound specification or a reliable way to assess the output.
▲ Task delegation and result inspection
What current agents show—and what they do not
OpenClaw illustrates an existing way to connect an AI assistant to everyday work. It is an open-source local assistant for macOS, Windows and Linux, with persistent memory across sessions and connections to messaging services. It can interact with the operating system to handle files, forms, commands and multi-step tasks. Those capabilities show how an agent can act beyond a chat window; they do not establish that hundreds of agents can run a complex engineering project without supervision.
One entrepreneur has described using Claude and agents to replace an enterprise software stack and its associated workloads in a 90-minute session. The execution time is only one part of such a project. Data preparation, application programming interface (API) configuration and pipeline infrastructure—the systems that move and prepare data—can require weeks or months before an automated run begins. Developers may also need to refine instructions, wait through iterations, debug edge cases and revise generated code before it is ready for production.
For a team considering agents, the useful distinction is between time spent running an automated task and time spent making that task possible and checking its result. A short run should not be mistaken for a complete account of the engineering effort.
Familiar software becomes the review surface
Huang argues that agents may increase use of established software rather than replace it. Human users currently limit how often many tools are used; fleets of agents could query databases and work inside design applications on their behalf. That growth in software use is a projection. The immediate engineering question is how to connect agents to tools people already use and inspect the work they return.
For example, an agent working on a design could use a specialized application, while an engineer reviews the result there. Huang points to tools including Synopsys, Cadence and Blender as places where agent output can meet established professional workflows. SQL, a language used to query databases, offers another route for agents to work with existing information.
Model Context Protocol (MCP) is a way to connect AI models with external tools. Connections involving Blender, Unreal Engine, Godot and Unity point toward agents creating or changing 3D assets and environments inside familiar workspaces. The important handoff is back to a person who can inspect the generated result against the project’s requirements.
▲ Review inside a design workspace
Building the workflow around the tools
The choice of model is only part of this system. Proprietary models can serve general tasks, while open-weight models—models whose weights are available for others to use and adapt—offer another path for specialized work. A routing system could send different tasks to different models. Long-running background agents could use server capacity such as GitHub Actions minutes or dedicated hardware, though that infrastructure would still need testing and oversight.
The practical starting point is a well-defined task, not a target number of agents. Specify the architecture and success criteria, prepare the data and tool connections, then allow time to iterate. Review outputs in the applications where the work will be used. Huang’s vision points to engineers coordinating far more automated work; today’s tools make parts of that vision possible, while responsibility for direction and quality remains with the engineer.