In the previous post, I argued that cheaper execution raises the value of judgment.

There is a moment when this is particularly easy to forget.

The prototype works.

It authenticates a user, calls the model, retrieves the right information, and presents a polished response. A comparable demonstration might once have taken a team several weeks. This one took two people and a few days.

The room changes when people see it.

Ideas that sounded speculative on Monday feel inevitable by Friday. Delivery plans contract. Cost assumptions move. The distance between the demonstration and a dependable product begins to look surprisingly short.

I understand the excitement. I have felt it myself.

AI has made it possible to explore an idea at a speed that still feels slightly unreal. A small team can make an experience tangible while the conversation is fresh. That is valuable. It gives everyone something concrete to inspect and challenge.

The trouble begins when we treat the prototype as evidence about how many people the finished system will need.

A prototype answers one important question:

Can we make this idea work under conditions we control?

Production introduces a different question:

Can customers depend on it under conditions we do not?

The space between those questions is where experienced judgment earns its keep.

What the Demo Has Not Encountered Yet

Imagine the prototype is an AI assistant for customer support.

The happy path is impressive. An agent asks a question, the assistant searches internal documentation, and a useful answer appears in seconds. The interface cites its sources. The response sounds natural. The team can already picture the time it will save.

Then the prototype meets the organization around it.

Some documents contain customer-specific terms. Others describe policies that have expired but remain searchable. Access rights differ by region. A correct answer for one product tier creates a contractual problem in another. Support agents need to know when the assistant is uncertain. Security needs an audit trail. Operations needs to understand what happens when the model provider is unavailable. Legal asks where prompts and responses are retained. Finance wants to know how cost behaves during a major incident, precisely when usage will spike.

None of these questions invalidates the prototype.

They reveal the product.

The demo proved that retrieval and generation could create a useful interaction. Production asks the organization to establish the conditions under which that interaction can be trusted.

Those conditions become foundations:

clear identity and access boundaries
reliable sources of truth
data classification and retention rules
evaluation criteria for quality and safety
observability across models, services, and user actions
predictable behaviour when dependencies fail
cost controls that hold under real demand
support and recovery paths for the people affected
ownership after the original team moves on

AI can contribute to every item on that list. It can draft policies, generate tests, inspect traces, suggest failure modes, and help teams compare designs.

Somebody still has to decide what adequate means for this system, in this organization, for these customers.

That decision rarely lives in a prompt. It draws on architecture, domain knowledge, operational history, customer context, and the memory of failures that looked unlikely until they happened.

Why PoC Euphoria Distorts the Picture

A proof of concept concentrates attention on visible progress.

We see the interface, the generated code, the passing tests, and the short time between an idea and something that runs. We see far less of the accumulated knowledge that will determine whether it survives contact with production.

This creates an awkward measurement problem.

The output from AI is immediate and countable. The contribution of an experienced employee often appears as a question, a constraint, or a decision to slow down.

Why are we putting customer data in that index?

Which service owns the source of truth?

How will we revoke access during an incident?

What happens to open conversations when the model changes?

Have we seen this traffic pattern before?

A good question can remove months of rework. In the moment, it may look like resistance to a demo that already works.

High-judgment people create much of their value through events that never occur. The breach avoided, the migration simplified, the dependency isolated, the customer promise protected, the on-call team spared an unrecoverable failure: these outcomes rarely appear beside the prototype in a productivity presentation.

Their salaries do.

This matters when PoC excitement coincides with genuine cost pressure. Businesses reduce spending for many reasons: cash flow, shifting markets, duplicated work, changing portfolios, investor expectations, or simply the need to survive. Payroll is a large and visible cost. AI arrives in that discussion with a compelling demonstration of leverage.

The resulting decision can be understandable and still remove capabilities the organization will soon need.

The risk is greatest when the people who understand production look expensive precisely because their work is less visible than generation. Once they leave, the prototype may continue to advance. The missing judgment becomes apparent later, distributed across integration delays, brittle foundations, repeated incidents, and decisions nobody feels equipped to own.

By then, the spreadsheet has already recorded the saving.

Different Companies Are Buying Different Things

The technology industry makes this harder to reason about because its most visible companies are taking apparently contradictory actions.

Large incumbents are reducing costs, consolidating portfolios, simplifying management layers, and reorganizing around AI. At the same time, frontier AI companies are competing aggressively for a small number of people with exceptional technical judgment. Both stories are described as evidence of AI-driven productivity.

The visible actions are easy to copy. Their operating contexts are not.

A mature company may be removing duplicated structures built over decades. A research lab may be assembling a small group capable of making decisions at the edge of what is technically possible. One is simplifying an existing system; the other is concentrating scarce expertise around an emerging one.

The headcount movement tells us very little by itself.

What matters is the capability that remains after the movement.

This is why copying a prominent company's layoffs while expecting the learning velocity of a frontier lab is such a dangerous shortcut. The reduction is visible. The years spent building technical depth, decision quality, infrastructure, and shared context are not.

Talent density also requires more than retaining a few celebrated specialists. High-judgment employees need access to one another, strong foundations beneath them, and enough organizational trust to challenge an attractive idea before customers carry the consequences.

Otherwise expertise becomes an emergency service: invited after the architecture is fixed, the promise has been made, and the prototype has already become a deadline.

Pay Attention to Who Becomes More Useful After the Demo

The prototype changes what we should look for in a team.

Before it exists, fluency and speed are easy to notice. Who can turn the idea into something tangible? Who knows the tools? Who can get the first path working?

After the demo, a different group of contributions comes into focus.

Someone recognizes that the retrieval design crosses a data boundary.

Someone remembers why an apparently redundant service exists.

Someone understands how the feature will alter the support experience during a failure.

Someone can distinguish a temporary shortcut from a foundation that will quietly become permanent.

Someone knows which customer promise the proposed architecture cannot keep.

These may be the same people who built the prototype. Often they are colleagues whose impact is spread across many teams and therefore difficult to assign to a single feature.

They are worth identifying deliberately.

Ask who improves the quality of decisions around them. Who makes hidden assumptions discussable? Who connects a local implementation to the wider system? Who can explain risk without turning every risk into a veto? Who helps less experienced colleagues develop the same instincts?

That last question matters. Judgment should not remain concentrated in a handful of indispensable people. The strongest employees do more than intervene personally; they leave behind clearer boundaries, better defaults, stronger review habits, and colleagues who can carry the reasoning forward.

AI can amplify this effect.

An experienced engineer can encode architectural constraints into tools and templates. A security specialist can turn recurring concerns into automated checks. A product leader can use prototypes to expose ambiguity while change is still cheap. An operations team can feed incident knowledge into evaluation scenarios before launch.

The result is not one expert supervising a machine. It is expertise becoming easier to apply across the organization.

Bring Production Judgment Into the PoC

Organizations do not need to dampen the energy around prototypes. They need to use that energy more intelligently.

Bring the people who understand production into the work while the prototype is still flexible.

Ask them to identify its assumptions rather than approve its implementation. Give them permission to distinguish experiments from foundations. Let security, operations, architecture, support, and domain experts shape the questions before the first impressive demo hardens into a delivery commitment.

A useful PoC review might ask:

What did we deliberately simplify to learn quickly?
Which assumptions become dangerous at production scale?
What existing capabilities should this build on?
Where does human review belong in the experience?
How will we know when the system is uncertain or degrading?
Who owns each failure path?
What would make us decide not to proceed?

These questions do not turn the PoC into a production programme. They protect the distinction between the two.

They also make workforce decisions more informed. Instead of extrapolating from the speed of generated output, leadership can see the full capability required to turn that output into a dependable service.

Some work will disappear. Some teams will become smaller. Roles will change, and organizations should be honest about that.

But the people who can build sound foundations, recognize consequential trade-offs, and help others exercise better judgment are not residue from a slower era.

They are how AI-generated possibility becomes an operational reality.

The People Between Possible and Dependable

A prototype is valuable because it makes an idea available for learning.

Its speed should widen the space for learning, not close the case for production.

The people who know what happens next occupy an unusual position. They can see the promise in the demo and the conditions required to keep that promise. Their work is sometimes inconvenient, often difficult to measure, and expensive to replace once the surrounding context has gone with them.

Cherish those people.

Give them influence before decisions become commitments. Use AI to extend their reach. Ask them to build foundations that allow many teams to move safely, rather than reserving their judgment for late review and emergencies.

The prototype shows what has become possible.

Production asks what the organization is prepared to stand behind.