The biggest tension in product engineering: PMs want a prototype tomorrow; engineers push it two sprints out with forty story points and a dozen questions 🤷.
That’s why vibe-coding platforms are exploding — promising prototypes in hours, without engineers, using natural language and some drag-and-drop logic.
The debate is loud. On one side: messy AI-generated code, technical debt, and unscalable hacks. On the other hand, working on apps with real UIs built in a day or a few.
But here’s what everyone misses: we’re mixing two very different processes — Discovery and Delivery.
The Real Gap: Discovery vs Delivery
Discovery is about figuring out what to build. It’s messy, fast, experimental. You prototype, test, and throw away. Human judgment drives it.
Delivery is about building it right. CI/CD, reliability, scalability, tests, schemas, long-term maintainability.
PMs reach for vibe-coding tools because they’re still in Discovery mode. Engineers resist because they’re wired for Delivery mode (I covered this in depth here).
Unless you separate the two, you’ll keep fighting.
Vibe-Coding Platform vs Internal Prototyping
Why PMs Love Vibe-Coding
It’s no accident Lovable is one of the fastest-growing startups. Instead of waiting weeks for a “real” prototype, PMs can hack together a clickable — even functional — version overnight.
Normally, it takes days or weeks to prepare high-fidelity or interactive prototypes for usability testing (read more: MVP, PoC, or Prototype). Not to mention porting that Figma/InVision work into real code.
Vibe-coding cuts this to hours. You get a prototype that looks and behaves like a real app, sometimes with a working backend and database. There’s literally zero engineering involvement.
But there are limits: it’s hard to make the app look like yours. In companies with an established design system, a vibe-coded app can look… scammy. Using internal data is tricky, too — few want to expose production databases to AI-generated software on an external platform.
And if the idea does click, translating a vibe-coded app into production-grade software on your stack can erase the initial time savings.
The alternative: bring the vibe-coding mindset inside your codebase. Below are principles that keep you aligned with your tech stack and make it easier to translate work from Discovery to Delivery.
Leaders Metrics — Team Health
In my own app, Leaders Metrics, I wanted a lightweight way to track team health through 1:1 check-ins. I had no data model, no schema, no UI plan — just a clear outcome.
But I knew this:
I needed an input form that I could fill out in under 30 seconds, right after a 1:1 meeting.
Inputs had to be structured to capture critical clues about the teammate.
I needed a dashboard to visualize trends over time — both positive and negative — for each person and the team.
That’s when I realized: I wasn’t in Delivery mode at all. I was still discovering. And those two modes demand different playbooks.
Side Note
I just released the workbook From Engineers to Operators – AI Strategy Workbook for Engineering Leaders.
It expands on the themes here — Discovery vs Delivery, context and constraints, the Operator role — with practical frameworks, workshops, and real artifacts from my AI-assisted project.
Delivery vs Discovery in AI-Agentic Work
In regular Delivery tasks, I follow the Context × Constraints approach.
Tasks are self-contained with:
Clear specification (what we need),
Evals (how we’ll verify we got it),
Context (where/under what constraints it’s implemented).
We have the desired architecture, tests, definition of done, schemas, and data models — all explicit.
In Discovery, we don’t need all that. In fact, building full data models, updating schemas, or splitting logic per architecture specs wastes time and shrinks the context window (the model focuses on the wrong things).
The entire article and related content are available only for paid subscribers. I cover Discovery Mode, related AI Agentic flows, pros of hallucinations and more.
You can use the training budget (here’s a slide for your HR).
Thanks for supporting Practical Engineering Management!