I Needed to See the Machine

I Needed to See the Machine

Why this matters

I walked into a demo of our new build system worried about the wrong thing. Watching how it works changed my mind.

TITLE
I Needed to See the Machine
AUTHOR
Leonardo De La Rocha
PUBLISHED
Jun 21, 2026
CATEGORY
The Decision
READ TIME
3 min read
ISSUE
11
LISTEN
[▶ PLAY]
******************************************************************************************

I came into a demo of our new build system worried about prioritization. Seeing how it actually works dissolved that worry and surfaced a harder one.

This week, one of our incredibly talented engineering leaders walked me through an internal system we’re building that automates the full software development lifecycle. I came in skeptical, and skeptical about a specific thing. The system turns raw user voice signal into product work, and my worry was prioritization: user voice doesn’t automatically point at the levers our investors care about (churn, adoption, and upsell), so I expected to spend the hour arguing about what it would choose to build.

That worry mostly dissolved, within the first 10 minutes because he was patient enough to show me how the thing actually works.

It’s agent-based, structured prompts layered over a few operating principles. Each stage of the lifecycle generates an artifact, a research doc, a tech design, then reviews its own work in a fresh context, so there’s a built-in second pass. At every stage there’s a grounding document that shows exactly which files and which data it drew from, which is the part that earned my trust. You can see its work. You can run it in the driver’s seat, using individual skills to help with a PRD or a tech design, or you can hand it the whole thing and let it generate and self-review end to end. He showed me a real feature built from user comments, no code written by hand, the back end wired all the way through.

Seeing the mechanism is what moved me and brought a huge smile to my face. (It was then that he knew he won me over) The prioritization worry I came in with shrank because the fix is now obvious: you encode what the business cares about as skills, so the outputs ladder up to the things we actually measure instead of floating free. That’s buildable. What replaced the worry is a bigger and more honest concern. This only works if people change how they work. It asks a PM to stop drafting PRDs in their own head and their own chat window, and instead pay attention to inputs and outputs and gut-check at a different altitude. That’s a real behavioral shift, and a demo can’t make it happen.

So, I left more excited and more clear-eyed at once. The technology is further along than I expected, and the adoption problem is harder than I had been treating it. Both became true in the same 30 minutes, and only because I stopped reacting to the idea of the system and looked at the system.

The teachable part

When something new makes you anxious, notice whether you’re reacting to the idea of it or to the thing itself. I almost spent a meeting arguing about a problem the mechanism already solved, because I’d formed my objection before I understood how it worked. The patient walkthrough is underrated. Ask for it. And when an abstract worry clears, don’t relax. Usually it’s because a more concrete and more important worry was hiding behind it.

Filed under TD The Decision — What we chose, and why.