Working with AI Is Just the Beginning
Now You Need to Build Your Intelligence Factory
Jensen Huang has been saying it for two years now. The data center, as we’ve known it, is being replaced by something he calls an intelligence factory. You apply energy to it, he says, and it produces something incredibly valuable. Raw data goes in, intelligence comes out. Every company will need one, Jensen says.
Most people heard a chip salesman pitching infrastructure. Fair enough. NVIDIA sells the shovels. But last week, something happened that deserves closer attention from anyone who runs a team, manages a function, or does knowledge work for a living.
Cursor, the AI-powered coding tool that has quietly become the center of gravity for software development, published a blog post called “The Third Era of AI Software Development.” It describes three phases of how developers work with AI. The first was autocomplete. The second was directing agents through synchronous prompt-and-response loops. The third, arriving now, is something different.
Here’s how Cursor’s CEO Michael Truell described it:
Cursor is no longer primarily about writing code. It’s about helping developers build the factory that creates their software. This factory is made up of fleets of agents that they interact with as teammates: providing initial direction, equipping them with the tools to work independently, and reviewing their work.
Read that again, but replace “developers” with your job title. Replace “software” with whatever your team produces.
Strip away the software context and what remains is a description of management. Of any knowledge work where the output matters more than who physically produced it.
The numbers are already here
This is more than another AI prediction. Cursor shared the data. A year ago, 2.5x more of their users relied on tab-autocomplete than on agents. Today that ratio has flipped. Twice as many users work with agents as use the tab key. Agent usage has grown 15x in a single year. Over a third of the code Cursor’s own team ships is written entirely by agents running autonomously on cloud computers.
And the developers who’ve crossed over share three traits. Agents write almost all of their code. They spend their time decomposing problems, reviewing output, and giving feedback. They run multiple agents in parallel rather than guiding one at a time.
None of those three traits are technical. They describe judgment, decomposition, and quality evaluation at speed. In any other context, we’d call them management skills.
Two factories, one pattern
Jensen Huang talks about AI factories at the infrastructure layer. Energy goes in, tokens come out. The economics of intelligence production. He frames it at planetary scale because he’s building planetary-scale hardware.
Cursor is describing the same factory at the human layer. Challenges go in, solutions come out. Questions go in, opportunities surface that nobody had the bandwidth to explore before. The developer doesn’t write the code. The developer designs the system that produces the code, sets the quality bar, and decides whether the output meets it.
Three weeks before Cursor published, Greg Brockman described how OpenAI itself is reorganizing around this exact shift. His team designated “agents captains” on every team. The goal, by March 31st: for any technical task, the default first move is to interact with an agent, not open an editor. They’re creating living documentation that teaches agents how to work within each project and restructuring their entire codebase to be agent-first.
Three companies at three different scales arrived at the same conclusion. The human role is shifting from doing the work to designing and directing the system that does the work.
Why this matters beyond software
Software is where this is visible first because the tools matured there first. And yes, Cursor has every incentive to frame the shift this way. They’re selling cloud agents. But the framing holds up beyond their product announcement because the pattern is already showing up in places that have nothing to do with code.
Consider what Cursor’s developers actually do now. They take a complex objective and break it into pieces an agent can handle. They define what good looks like before the work starts, then evaluate output against that standard and course-correct when it falls short. They hold the whole picture while agents hold the parts.
That pattern is already emerging outside of software. We work with a firm where the marketing group has quietly become a factory floor. They’re building micro-automations for every repeatable process: content variations, audience segmentation, campaign performance analysis, reporting. No single automation is revolutionary. But taken together, they’ve constructed a system where agents handle the production and humans focus on strategy, quality, and judgment calls. They didn’t set out to “build a factory.” They just kept asking “what can I hand off?” until the answer was: most of it.
The people who thrive in this model aren’t the ones who are best at doing the task. Instead, they’re the ones who can architect the system, evaluate the output, and maintain the judgment that agents can’t supply.
The factory floor changes constantly, which makes this harder than it sounds. The models improve. The tools shift. Workflows that worked six months ago become obsolete or get replaced by better ones. Building the factory isn’t a one-time project. It’s a continuous practice of redesigning how intelligence flows through your work. The durable skills aren’t in any specific tool configuration. They’re in the human capabilities to rebuild when the floor shifts underneath you.
The skill gap nobody is naming
There’s a conversation happening right now in boardrooms and faculty lounges and HR departments about “AI skills.” Most of it focuses on prompt engineering, tool proficiency, learning which buttons to push. That’s the equivalent of teaching someone to type in 1995 and calling it “internet skills.”
The real gap is in the skills Cursor’s developers are using every day, and they look nothing like what most AI training programs teach. Problem decomposition: taking a complex goal and breaking it into components that can be executed independently. Quality criteria definition: knowing what good looks like before the work starts, well enough to evaluate output you didn’t produce. Parallel oversight: holding context across multiple work streams without losing the thread. And system design thinking: understanding how pieces fit together, where failure modes hide, where human judgment adds the most value.
These are human skills. Cognitive and strategic skills that have always mattered in leadership. What’s changed is that they’re becoming table stakes for anyone whose work involves directing intelligence toward outcomes.
The factory question
There’s a fair objection to this entire metaphor: the factory owner doesn’t own the means of production. The models come from Anthropic and OpenAI. The compute comes from NVIDIA’s infrastructure layer. The knowledge worker is renting the machinery, not building it. So where’s the value?
It’s in the orchestration. Factory owners during the Industrial Revolution didn’t build their own steam engines. They bought them from Boulton & Watt. They didn’t generate their own electricity. They bought it from the grid. What made them factory owners was that they designed the production system: the workflow, the quality standards, the integration of machines and people toward a specific output. The value they captured wasn’t in the machinery. It was in knowing how to use it.
Same dynamic here. And as models commoditize, and they are commoditizing, the value shifts further toward the orchestration layer. The person who understands their domain deeply enough to design great agent workflows captures more value as the underlying intelligence gets cheaper and more abundant.
Anthropic’s Dario Amodei offers one way to think about it. He describes AI’s output as a country of geniuses, working around the clock, on every problem you can define. The factory produces the geniuses. Your job is to put them to work on the right things.
Jensen Huang told the audience at Davos in January 2026 that AI helps with tasks, enabling people to fulfill their purpose and become more productive, making workers more valuable. Then he asked a question that should sit with every leader for a long time: “So the question is, what is the purpose of your job?”
Cursor’s blog post offers one answer for developers, arrived at through practice rather than theory. The purpose of the developer’s job is no longer to write code. It’s to build and run the factory that produces software.
The same question is now sitting in front of every professional. If agents can do the task, what’s the purpose of your role? It will almost certainly involve designing systems, defining quality, exercising judgment, and maintaining accountability for outcomes. Agency, in short. The capacity to direct intelligence, not just consume it.
The factories are being built. The infrastructure is live. The shift from “using AI” to “running an intelligence operation” is happening in software right now, and it will reach every function in every organization faster than most leaders expect.
The people preparing for that shift are already thinking less about which tools to learn and more about how to architect the systems those tools will power.






An excellent article and I did enjoy the "factory" metaphor. Ironically I'm staring down the barrel of a significant deployment that would, in bygone days, launch a boatload of developers + UX/UI + Tech stack conversations (and agonizingly long meetings). The allure of this is a "lighter load" but I'm not sure who in my strategy+tech+dev group has the capability to be the factory owner in this new world. Todd - I'd genuinely appreciate what you'd see as the JD for such a person that breaks out both technical and human/empath skills. Thanks as always for your thought-provoking writing.