The first crutch prototype worked.
That was nowhere near the same thing as having a crutch company.
I keep thinking about that while building AI software.
Prototypes lie by omission
A prototype answers a narrow question.
Can this geometry move the load off the armpit?
Can this compression pattern change ankle deflection?
Can this model complete this task?
When the answer is yes, it feels like the hard part is over.
Then reality begins.
The crutch has to survive different body sizes, floors, weather, manufacturing tolerances, user mistakes, shipping damage and months of repeated loading.
The sock has to survive sweat, washing, different ankles, different sports and people putting it on incorrectly.
The AI workflow has to survive ambiguous instructions, missing data, weird websites, contradictory business rules, stale information and a user changing their mind halfway through.
The prototype did not lie.
It just answered a much smaller question than the company needed answered.
Reliability is a product feature
In hardware, nobody is impressed that the crutch works 92 percent of the time.
The missing eight percent is the product.
AI software is teaching the industry the same lesson.
A demo can be spectacular even when the system is not dependable enough to enter a real workflow.
That gap matters more as AI moves from generating suggestions to taking actions.
If a paragraph is mediocre, you rewrite it.
If an autonomous system sends the wrong thing to 10,000 customers, the failure has a different shape.
Constraints are part of intelligence
Physical products are defined by constraints.
Weight. Strength. Cost. Materials. Manufacturing process. Human anatomy. Regulations.
You do not get to solve the idealized problem.
You solve the problem inside the constraints.
Good AI software needs the same mentality.
The system needs to know what it can do, what it cannot do, what needs approval, which source is authoritative and when uncertainty should stop the action.
The intelligence is not only in generating an answer.
It is in respecting the boundary.
Users do things you did not imagine
I have written before about two people setting world records with products I built. Neither use case was one we designed around.
That is the terrifying and wonderful part of releasing something useful: the user owns the next experiment.
AI products multiply that effect because the number of possible inputs is effectively unlimited.
You cannot enumerate every way somebody will use a general system.
You need architecture that fails safely and learns from the strange cases.
The system around the product matters
My younger self thought invention was the object.
Then I learned that the company around the object matters just as much: manufacturing, logistics, support, distribution, documentation, quality control, financing.
With AI, the model is the object everybody wants to stare at.
The company is everything around it.
Context. Tools. permissions. evaluations. feedback. data. user experience. human review. escalation.
That is where a lot of the durable value will live.
I am more skeptical of demos now
I still love them.
A good demo is the moment a new possibility becomes visible.
But I have spent enough time taking prototypes into production to know the question that comes next.
Not: did it work?
Did it keep working after the conditions stopped being friendly?
That is the question I ask about YG3 now too.
The AI is interesting.
The system that makes it useful on an ordinary Tuesday for an ordinary business is the product.
