I ended the last article with a question:
We used to think through a hundred possibilities so we could afford to build one. What happens when we can afford to build the hundred?
The more I think about that question, the less it feels like a productivity question.
If creating one reality, or several possible realities, starts requiring roughly the same investment as creating a representation of one, then some of the assumptions behind how we work begin to change.
We don’t just get faster at the process we already have.
We have to ask whether we still need the same process.
We built a representation pipeline
Waterfall, Agile, and Lean all evolved around the same economic constraint. They differed in how they managed cost, time, uncertainty, and risk, but all relied heavily on representations to help teams decide what should eventually become real.
Over time, those representations became embedded in the organization itself.
Business analysts produced use cases and requirements. UX produced flows and wireframes. Design produced mockups. Product produced roadmaps and stories. Engineering produced architecture diagrams, schemas, API contracts, and technical designs.
We built roles around owning these artifacts and handoffs around moving them from one discipline to the next.
In many ways, the modern product organization became a representation pipeline.
Now the economics behind that pipeline are changing.
If a functioning experience costs about the same as the wireframe describing it, why create the wireframe?
If several campaign executions cost about the same as the concept deck describing one, why stop at the concept deck?
If multiple working systems can be explored in the time it takes to document one, why make the documentation the destination?
The question is no longer:
“Can AI create this deliverable faster?”
It’s:
“Why are we creating this deliverable at all?”
A different loop
Agile, Waterfall, Lean, even MVPs, need to go.
AI has changed one of the core assumptions they were built around.
So instead of continuing to refine the old process, I’ve started thinking about a different loop:
VET: VISION → EXPLORE → TEST
Vision defines what we’re trying to make true.
Explore creates and lets us experience possible realities.
Test determines which reality fits, how much confidence we need before acting on it, and what we learned that should change the next Vision.
Then the loop begins again.
What I like about VET is that it describes the work directly. Instead of spending most of our energy perfecting a representation of one possible future, we vet the idea by creating possible realities and learning from them.
VET your idea.
Vision
AI can produce an enormous number of polished answers to a poorly defined problem.
Vision keeps that abundance pointed in the right direction.
Who are we solving for? What outcome matters? What constraints are real? What shouldn’t change?
Vision doesn’t describe the answer.
It defines the space worth exploring.
Explore
This is where AI changes the process most dramatically.
Historically, we imagined many possibilities, represented a few, and chose one or two to pursue.
Now we can move much closer to the realities themselves.
If the working experience costs roughly the same as the wireframe, make the experience. If five campaigns cost roughly the same as the concept presentation, make the five campaigns. If several workflows can be built in the time it takes to document one, build them and react to what actually happens.
Explore becomes less about predicting which idea will work and more about creating enough possibilities to find out.
Test
More possibilities make judgment more important.
Test answers three questions:
Which reality fits best?
How sure do we need to be before acting on it?
What did we learn that should change the next Vision?
Sometimes the answer comes from evidence such as customer behavior, conversion, usability, operational performance, or experimentation.
Sometimes it comes from judgment such as customer fit, brand fit, business fit, technical fit, or strategic fit.
Today we tend to distribute those judgments across UX, Design, BA, Product, Architecture, and other roles.
VET doesn’t require the roles. It requires the capabilities.
Those capabilities might exist across a team, require deeper expertise for a particular decision, or exist in one simply capable person.
The point is the judgment, not the job title.
Risk belongs here too.
A reversible landing-page experiment may require very little evidence before moving forward. Pricing, customer data, security, core architecture, or a significant brand decision should require much more.
The cost of being wrong determines the rigor of Test.
And whatever we learn, whether the idea succeeds, fails, or reveals something unexpected, feeds the next Vision.
And then we VET again
VISION → EXPLORE → TEST isn’t really a sequence.
It’s a flywheel.
Test changes Vision. A sharper Vision focuses the next Explore. Explore creates better realities to Test.
The wheel turns again.
As AI makes Explore faster and dramatically larger, I suspect more of the value shifts toward defining the right direction and having the judgment to recognize what fits.
That raises a harder question.
If wireframes, use cases, mockups, roadmaps, specifications, architecture diagrams, and other representations begin to disappear, what happens to the roles and organizational boundaries we created to own them?
The capabilities still matter.
The roles may not.
That’s the part I’m thinking about next.