TL;DR — AI handed non-engineers (PMs, POs, BAs, anyone with an idea) a superpower: build something that technically works in an afternoon. It is addictive, and it lies. "Technically works" (in isolation, on happy-path data, on my machine) is a completely different universe from "works well inside the current system, at scale." That second thing is the real engineering, and AI quietly lets you skip all of it. The reframe:

  • "It works in theory" is a starting line, not a finish line. The demo proves the idea is possible, not that it is ready.
  • Use the loop to evaluate options and build conviction, not to convince yourself the thing is done. Let AI run five versions of an idea and tell you which one is worth the real work.
  • Spark, don't ship. The throwaway version is the clearest way to communicate intent. The production version gets rebuilt to live inside the actual platform, and that is the hard, valuable part.
  • Innovation is selection, not invention. For a team, innovating is trying different solutions and keeping what works. AI now surfaces options that neither the PM nor even the architect knew existed, sometimes genuinely great, sometimes overkill. Ask it to explain its choice and you walk away understanding the problem better. The human job is choosing and integrating.

The superpower that feels like cheating

Last month I had an idea on a Tuesday and a working thing by Tuesday afternoon. Not a Figma mockup. Not a clickable prototype with fake data behind it. A thing that took real input, called a real model, and gave back a real answer that was actually right most of the time.

I did not write most of it. Claude did. I described what I wanted, watched it build, poked at the result, described what was wrong, and it fixed it. A few loops later I had something I could run and show.

If you are a PM, a PO, or a BA, you know this feeling now. It is intoxicating. For years the gap between "I have an idea" and "here is the idea, running" was owned entirely by engineers. AI just deleted it, and the first time you cross it yourself, it feels like you found a cheat code.

That feeling is exactly the problem.

"Technically works" is not "works"

Here is the naive mistake, and I have made it plenty, so I am not lecturing anyone.

The thing I built technically works. It runs. It gives the right answer on the input I fed it. And there is a very human jump my brain wants to make right there: if it works, it is basically done.

It is not basically done. It is barely started. "Technically works" is a demo standing on its own in an empty room. It works because I built the room around it. Real software does not get an empty room. It has to live inside a system that already exists, with its own data, its own load, its own constraints, its own history of decisions nobody wrote down.

   "TECHNICALLY WORKS"          "WORKS WELL IN THE SYSTEM"

   +-----------+                +-----------+
   |  my demo  |   <- 10% ->    |  my demo  |
   +-----------+                +-----------+
   on my machine,                   |  the other 90%
   my data,                         v
   happy path,                 - fits the existing architecture
   one user,                   - handles the data you don't control
   right now                   - holds up at 10k users, not 1
                               - errors that don't take the system down
                               - the empty state, the huge state
                               - security, permissions, rate limits
                               - the model being confidently wrong
                               - still works after the next release

None of that lower stuff showed up in my demo, because I never asked and the AI never volunteered. That is the lie. Not that the demo is fake, it is real, but that "it works" quietly means "it works in theory, in a vacuum I control." The distance between that and works well inside the current platform, at scale is the entire craft I skipped.

The gap is the system, not the idea

This is the part I underestimated the most. I used to think the hard part of a feature was the idea, and once the idea was proven, the rest was typing. Backwards.

The idea is the cheap part now. AI makes ideas run in an afternoon. The expensive part is making that idea belong somewhere: threading it through an architecture that already made a thousand choices, respecting the data model you did not design, not breaking the five things next to it, and holding up when the load is 100x your demo.

   what I think is left           what is actually left

   [ 95% done, just wire it up ]  [ make it live in the real system ]
                                  [ make it scale past a demo        ]
                                  [ make it not break everything else]
                                  [ the 90% that never showed up     ]

My scrappy version has none of that context baked in, and it cannot, because I built it in a clean room specifically to avoid all of it. That is not a knock on the version. A clean-room hack is the fastest way to learn if an idea has legs. It is only a problem if I mistake "has legs" for "can run a marathon inside the existing system." Which brings me to what the demo is actually for.

Stop building the product. Start running the loop.

The mistake is thinking the superpower is building the finished thing. It is not. We are all addicts here, and building is the addiction, not the value.

The real superpower is this: I can now try ten versions of an idea before lunch and find out which one is actually worth the real work.

That is a thing no PM could do before. Not "here is my one guess, let us spend six weeks finding out if I was right." Instead: hand the question to the loop, let AI generate several plausible solutions, run them against real-ish data, and evaluate.

   OLD WAY                        NEW WAY

   idea ->                        idea ->
     one guess ->                   AI runs option A, B, C, D, E ->
       weeks of real build ->         evaluate against real data ->
         learn if it worked            keep the 1 worth building ->
                                          THEN plan the real thing

   cost of being wrong:           cost of being wrong:
   weeks of production work        one afternoon + a discarded branch

The output of this loop is not a product. It is conviction, and evidence for it. I am not shipping the hack. I am using the hack to learn which of my five ideas is not naive, so that when the real work starts, it starts on the one that already survived contact with reality, and I can show why instead of just asserting it.

Spark, don't ship

So what do I do with the option that survived? I do not treat it as almost-done. I use it to spark.

The working thing is not a deliverable. It is the clearest possible way to say what I mean. A running demo removes the ambiguity that a doc or a Figma can never fully remove. People see it, get it in ten seconds instead of ten paragraphs, and then the real version gets built properly, to live inside the actual system, by the people who understand the 90% I skipped.

   [ my clean-room demo ]
            |
            v
   "oh, THAT's what you mean"      <- the spark
            |
            v
   now build the version that
   actually fits the platform:
   the architecture, the scale,
   the constraints, the data
            |
            v
   [ the thing that really ships ]
   ( production-ready, not a demo )

The spark was the contribution. Proving the idea is possible, and making it concrete enough that nobody has to guess what I meant. The demo was never the product. It was the fastest way to point at the product.

This is the through-line of everything I keep writing in this blog series: when the PM job got easier and harder at the same time, why the ways we work have to change, and why we are not actually ready to hand everything to autonomous agents. Same discipline every time: know when the obvious work is worth doing yourself, and know when to stop, because the thing you built in a clean room is not the thing that has to survive in production.

   DECISION: what is this demo for?

   just to learn if the idea is
   even possible?  .........................  build it, then throw it away
                                              (it did its job the moment
                                               you learned the answer)

   about to treat it as "basically
   done"?  ................................  STOP -> it works in theory,
                                              not in the system yet

   the real version needs judgment about
   scale / architecture / data I don't
   fully hold?  ...........................  spark it, then build the real
                                              one with the people who do

The hard part is not the building. AI made building easy. The hard part is the discipline to stop building the moment the demo has taught me what it can, and to be honest that "it works" so far means "it works in a room I control."

Innovation is selection, not invention

One more reframe, because I think we have the word "innovation" wrong.

For a team, innovation is not conjuring something new out of nothing. That is romantic and mostly false. Innovation is trying different solutions, seeing what works for us, and going with it. It is selection under real constraints, not a lightning bolt of genius.

And here is the honest part. With AI this good, the purely inventive spark, the "no human has thought of this before" moment, is getting further from what any of us actually do day to day. That used to feel like a loss. I have decided it is not.

Because the flip side is this: AI now regularly proposes a way of working, or a solution, that I would not have thought of. Sometimes one that the architect would not have thought of. It has read more code, more papers, more postmortems than any of us. When I run the loop, it does not just execute my five ideas. It suggests a sixth I did not know to ask for.

And I have learned to learn from that sixth idea, not just accept it. Sometimes what it proposes is genuinely good. Sometimes it is overkill, a cathedral where a shed would do. Either way, the move that changed things for me is simple: I stop and ask it to explain why it chose that shape. It walks me through the tradeoffs, the failure modes it was quietly designing around, the reason it reached for the heavier pattern, until I understand the situation better than I did before I asked. That is the part I did not see coming. The tool that builds the thing is also the most patient teacher I have about the thing. So when I finally bring an option to the team, I am not just carrying a demo. I am carrying an understanding of why this shape and not the other three, and I can tell the difference between the version that is right and the version that is just impressive.

   who has the idea?

   before:   PM ---(one idea)---> team, hope it's good

   now:      PM ---+
                   |
             AI ---+---(a shortlist, some of them surprising)---> team
                   |
       architect --+

             then the humans pick, together, what's worth
             building for real

That is not a threat to the PM or the engineer. It is a third collaborator that occasionally out-ideas both of us and has no ego about which idea wins. Our job shifts from having the best idea to recognizing it, pressure-testing it, and deciding together whether it is worth building into the real system. That job still belongs entirely to humans, and it is more interesting than pretending we invented everything.

What I actually do now

Concretely, the rule I try to live by after fooling myself a few times:

  • Build the demo. Love the demo. Never believe the demo. It works in a room I control. That is a hypothesis, not a shipment.
  • Run the loop to kill ideas, not to finish them. If an afternoon of hacking produced conviction and a discarded branch, it did its job.
  • Say what is actually true. Not "it's basically done," but "it works in theory, here is the one that held up, here is what making it real inside the system would take."
  • Spark, then let the real version get built for the real system, by the people who hold the context I do not.
  • Treat AI as the third person in the room who sometimes has a better idea than anyone, and let the humans do the choosing and the integrating. When it proposes something I do not fully understand, or something that smells like overkill, I ask it to explain until I do, and I come out of it knowing the problem better.

The superpower is real. It is just not the superpower it feels like. It does not turn me into an engineer. It lets me ask far better questions, back them with evidence, and point at exactly what I mean, so the thing that finally gets built is production-ready instead of merely possible.

The demo will lie to you. Let it. Just do not repeat the lie to yourself.

Where has "it works in theory" bitten you? And has AI ever handed you an idea you are now slightly embarrassed you did not think of first?