The MVP Threshold Just Collapsed

The Operating Model Has Not Caught Up

Jensen Huang said something in 2026 that most companies have not yet processed.

In a Stratechery interview, the NVIDIA CEO said that 100% of NVIDIA software engineers now use coding agents. The important part is not that agents autocomplete code. It is that engineers increasingly describe specifications and architecture, review outputs, orchestrate agents, and decide what gets built and why. The typing is becoming less central. The judgment is becoming more central.

Huang pushed the idea even further around GTC 2026: engineers may eventually need an annual AI token budget on top of salary, so they can deploy agents as productivity multipliers.

If you run a department, a team, or a business outside Silicon Valley, your first reaction may be: "Fine, but that is NVIDIA." Frontier compute. Elite engineers. Huge budgets. Not us.

That reaction misses the point. The shift NVIDIA is describing is not only about engineering talent. It is about who gets to build. And that change is about to hit every organization that runs an IT backlog.

The MVP Threshold Problem

In most companies, the limiting factor on good ideas is not the supply of good ideas. It is the cost of proving them.

Pick any organization with more than fifty employees and you will find the same pattern. Someone in operations has a clear idea for a tool that would save the team six hours a week. Someone in finance can describe a reconciliation workflow that would eliminate a recurring quarterly mistake. Someone in sales knows exactly what kind of lead-scoring nudge would close more deals.

These ideas are everywhere.

Almost none of them get built.

The reason is not always management resistance. Often it is the MVP threshold: the amount of working prototype required before an idea can be evaluated honestly. Without an MVP, an idea is a feeling. With an MVP, an idea becomes a decision. Until recently, building an MVP usually required weeks of a developer's time or an outside agency.

So the IT backlog grew. Jira tickets aged for years. Change requests sat in queues that no one expected to clear. Good people stopped submitting ideas because they had seen what happened to the last one. The backlog became a graveyard of work that was never urgent enough to displace anything else.

That was rational behavior in a world where prototyping was expensive.

Now it is not.

What Just Changed

The shift Huang described is the leading edge of something that already applies to business processes far outside software engineering. The cost of building a working prototype has fallen from weeks to afternoons.

That sentence sounds like hype until you watch someone with deep process knowledge, but no formal programming background, build a small Streamlit app that reconciles two spreadsheets in a few hours with an AI pair. Or scaffold a CRM extension with Cursor. Or generate a working draft of a customer intake flow with v0. The output is not always production-ready. It is often more than good enough to evaluate the idea.

The MVP threshold has collapsed.

That single fact is more disruptive to internal operations than any specific AI tool. The question stops being "can we afford to test this idea?" and becomes "who gets to test it, and under what guardrails?"

A New Operating Model

The companies that figure this out first will not just adopt AI tools. They will rewire who is allowed to build, when, and under what conditions.

Four moves form the new operating model. None of them are purely technical. All four are organizational.

Move 1: Surface The Real Bottlenecks

This sounds obvious. It is not.

Most departmental managers cannot quickly list the three workflows that cost their team the most time, the two missing internal tools that would compound impact, or the one persistent data problem that everyone has stopped complaining about. Not because they do not know. Because they have rarely been asked in a structured way, and because submitting items to "IT" has felt pointless for so long that the mental list has gone dormant.

The first move is to wake that list up. Run a short, structured intake per department:

what eats time;
what data lives in the wrong place;
what report keeps getting built manually;
what application does not exist but should;
what recurring exception people have normalized.

This is the bottleneck inventory. It is the input everything else depends on.

A blank "send me your IT wishes" email gets the same dead response as a neglected Jira portal. A facilitated process, where a manager answers focused questions and receives a prioritized list with impact and effort estimates, produces a different kind of energy.

Move 2: Protected Build Time

Here is the move most organizations skip, and the one most operating-model rollouts fail on.

If you tell employees "you can now build solutions with AI on top of your normal job," you are telling them to do their normal job and extra work in the cracks. Almost no one will sustain that for more than a week. The status quo wins because the status quo gets all the time.

The fix is simple to describe and uncomfortable to implement. Give each willing employee one protected day per week - call it Build Day - for AI-assisted work on the bottleneck inventory. No meetings. No firefighting. No "can you just." Sacred time, defended by the manager who surfaced the bottlenecks in the first place.

This is not a hackathon. Hackathons are sprint events that produce excitement and a long tail of unfinished demos. Build Day is a sustained operating rhythm. Week after week, the same employee works on the same workflow until the prototype is good enough to use or good enough to kill.

The cost of Build Day is real: 20% of participating employees' time. The return, across a department of ten people over a year, can be dozens of workflows tested, a smaller number promoted, and a step-change in how the team feels about its own ability to fix problems it can see.

Move 3: A Safe Sandbox Environment

This is where security, legal, and compliance officers correctly get nervous.

"Let employees build with AI" without guardrails is shadow IT with extra steps. Sensitive data leaks into public chatbots. Production systems get touched without audit. Workflows that should require human review get automated by an enthusiastic intern.

The sandbox layer answers those concerns without becoming the bottleneck itself. It needs four things.

A private AI environment. Data should not leave the organization's control by accident. This can be a self-hosted setup with open-weight models, or a connected commercial API with a data-processing agreement that genuinely covers the use case. The public-chatbot default is not acceptable for most real workflows.

Synthesized or anonymized data. Employees do not need real customer records to test whether reconciliation logic works. They need representative data. The sandbox should provide it.

Clear gates for production. A prototype that works on Build Day does not silently become a production system on Build Day + 1. There must be a review gate where IT, security, and a business owner sign off before anything touches real users or real data. The review should be fast, structured, and yes-or-no.

Full audit visibility. Every prompt, model call, tool call, and human approval gets logged. Not because logging is glamorous. Because when something goes wrong, you need to trace exactly what the agent did, what data it touched, and which human approved the step.

Move 4: A Registry Of Wins

The fourth move turns Build Day from a series of clever individual hacks into institutional capability.

Every prototype that survives the review gate gets entered into a registry. Not a Word document nobody updates. A real, structured catalog:

what the automation does;
which department owns it;
which data it touches;
what model, prompt, or workflow it uses;
who reviews it quarterly;
what it saves in time, money, or errors.

In its simplest form, this can be a single master .md file under version control. In a mature form, it is a small internal tool other departments can browse before building something redundant.

This registry is the antidote to the second-worst outcome of citizen development: twelve teams building twelve nearly identical solutions because no one knew the others existed. The worst outcome is the security incident; the sandbox is designed to prevent that.

The registry also has a quiet political function. It makes the work visible. The CFO can see that the AI program produced 23 active automations saving an estimated 4,200 hours per year. That number is what unlocks next year's budget. Without the registry, the work is invisible and the budget evaporates.

The IT Shift: From Gatekeeper To Coach

This is the part that often gets handled badly, and the part that determines whether the operating model holds together.

In most organizations, IT is the bottleneck by design. Every change request goes through them. Every prototype eventually needs their permission. Every security concern is theirs to surface. They are also, almost always, underwater. The backlog is not their fault. They are the dam holding back the flood.

The new operating model does not eliminate IT. It re-tasks IT.

IT moves from being the only people who build to being the people who enable everyone else to build safely. They run the sandbox. They write the review gates. They coach employees through Build Day. They identify prototypes that should be promoted to real internal products. They kill the prototypes that should not survive.

This is a more strategic role than fixing tickets. For senior IT professionals, it may also be a more satisfying one. The team that used to be treated as a cost center becomes the multiplier.

The Jensen Huang frame applies here too. NVIDIA's engineers did not become useless when AI took over more of the typing. They became more leveraged. Internal IT, given AI-fluent employees to enable, follows the same arc.

Team up, not turf war.

Is This Just Shadow IT With A New Name?

The honest counterargument deserves an honest answer.

Yes, this can become shadow IT very easily. Every previous wave of citizen development - Excel macros in the 1990s, Access databases in the 2000s, low-code platforms in the 2010s - produced both genuine business value and persistent security and maintenance problems. The pattern is real.

What is different now is not the temptation. The temptation is identical. What is different is the cost of governance.

Auditing a sandbox prompt history at scale used to require expensive tooling. It is increasingly affordable for a 50-person company. Synthesizing realistic non-sensitive data used to require a data engineering team. It is now often a model call. Writing the review-gate checklist used to take weeks of senior architect time. It can now be drafted in an afternoon and reviewed by the right people.

The same AI that creates the citizen-developer wave also lowers the cost of containing it. Companies that build only the wave get chaos. Companies that build only the containment get the same dead backlog. The win is doing both at once.

What This Operating Model Is Not

A few honest disclaimers, because over-promising is how this idea dies.

It is not a replacement for IT. It is a re-tasking of IT toward enablement.

It is not a way to clear every backlog item. Some items are in the backlog for good reasons: regulatory blockers, deep infrastructure rewrites, vendor dependencies, complex integrations. Build Day is not the place for those. It is the place for the ten thousand smaller workflows that have been waiting forever because they were never worth the cost of a traditional MVP.

It is not free. Twenty percent of an employee's time is a real cost. The trade is that you stop paying the larger cost of every good idea dying before it can be tested.

It is not a one-quarter project. The registry compounds. The skills compound. The cultural shift from "submit a ticket" to "build a prototype" takes a year or more. Companies looking for a single-quarter AI ROI will miss the point.

The Strategic Shift

The companies that win this transition will not be the ones with the best AI tools. They will be the ones that change who is allowed to build.

For decades, the answer was: specialists, in their own department, on their own timeline, after the budget was approved. The MVP threshold enforced that boundary. With that threshold lower, the boundary is now partly a choice, not only a constraint.

Most organizations will make the wrong choice by default. They will keep the boundary in place because changing it is uncomfortable. They will adopt AI tools without changing the operating model and wonder why nothing changed. They will keep the backlog, keep the gatekeeping, and watch their best people stop submitting ideas.

The companies that make the other choice - bottleneck inventory, Build Day, sandbox, registry, IT as coach - will produce more functional internal software in two years than they did in the previous ten.

Huang is right about engineers. By implication, he is also pointing at the rest of the organization. The age of the orchestrator is starting in software, but it will not stay there.

If your company still has a five-year IT backlog, that is no longer only a resourcing problem. It is a sign that the operating model has not yet caught up to what the tools now allow.