Why ‘AI-Built Apps in Minutes’ Is a Lie
Generative AI Should Accelerate Discovery, Not Just Delivery
Everyone’s hyped about AI agents building full-stack applications with a single prompt. It looks impressive. But it’s solving the wrong problem.
Shipping code isn’t the hard part anymore. Engineers aren’t struggling to generate boilerplate. What holds teams back is figuring out what to build in the first place—and whether that thing solves a real problem.
Marty Cagan, one of the most influential people in product thinking, argues that if you’re only using your engineers to write code, you’re getting about half their value. The quote comes from an excellent book, Inspired, which, along with Empowered, is a must-read by this author.
So, what’s the fundamental role of the engineering team—and how do AI tools apply to that?
Let’s break it down.
The Hype of GenAI
You probably remember the hype around mobile-first, when every single thing had its own mobile app. Or the crypto/blockchain excitement to decentralize everything, or when everyone was running machine learning on all the data we had.
Years later, we realized that most of what we did brought no value. But among these failures, there were brilliant projects that changed the lives of millions.
Each of these went through Gartner’s Hype Cycle—from innovation trigger, to peak of inflated expectations, hard landing in the trough of disillusionment, to finally ending in the plateau of productivity and mainstream adoption.
What’s happening today with Generative AI is most likely the Peak of Inflated Expectations. We’re being promised magic—AI in every aspect of our work—while countless fresh AI start-ups validate their product-market fit.
Disappointment is close, followed by stabilization and the “Plateau of Productivity.” This can be the perfect time to rethink your AI adoption strategy and plan thoroughly where it can bring the most value.
Delivery Is Execution. Discovery Is Insight.
This is the critical distinction between the two core activities in product development:
Discovery is about figuring out what to build. It involves customer research, ideation, prototyping, and testing. It’s fast, messy, and requires human judgment.
Delivery is about building the thing right. It’s about quality code, automated testing, CI/CD, reliability, and scalability.
Most teams focus heavily on delivery. Same with AI tools these days—they promise us to “build a product with AI within a few minutes.”
However, what everyone overlooks is that the promise is not typically about production-grade software. It’s about fast prototyping, so we know what we should build and what customers will love. It’s about discovery, not delivery.
Discovery is about reducing risk: value risk, usability risk, feasibility risk, and business risk. Delivery is about executing with quality and efficiency. Treating these two phases as a single monolithic workflow overlooks their distinct purposes and skills.
This brings us to one of the most overlooked levers in effective product development: the role of engineers in the discovery process.
Engineering's Role in Discovery
Engineers should be involved from the very beginning of the product lifecycle. Why?
They understand what’s technically possible.
They often come up with innovative solutions through their deep understanding of enabling technologies.
They bring early feasibility and scalability insights into product ideas.
Great product teams aren’t made of handoff-driven roles. Instead, product managers, designers, and engineers collaborate continuously in both discovery and delivery.
However, the reality is that not every company operates in this manner. Software engineers are often excluded from discovery processes because their “coding time” is too valuable to involve them in prototyping, customer interviews, or feasibility studies.
Product management is also afraid that once they give something to build to the engineering team, it will take at least weeks to deliver. On the other side, engineers—once handed the task—assume they need to make it scalable, cover all edge cases, and build production-grade software.
No surprise that product people look for ways to exclude engineering from the loop, and the promise of "build an app in minutes" is tempting.
Let's put it clearly—it’s a dead end. Even if you build such an app, integrating it with the company’s existing tech stack can exceed the original time savings. Most likely, such generated code utilizes different frameworks and solutions, doesn’t follow internal coding standards, and isn’t optimized for scale.
Prototype App in Minutes
But let's reframe our expectations from "let's build" to "let's prototype an app in minutes." This is an entirely different story. Here, you don’t need fully secured, scalable, production-grade code.
You need to build something quickly to validate the usability and feasibility of your future solution (read more: MVP, PoC or Prototype). Basically—you build prototypes to learn what's the right thing to build later on.
As a rule of thumb, an iteration in discovery should be at least an order of magnitude less time and effort than an iteration in delivery.
"Inspired" — Marty Cagan
Production-grade software requires maintenance efforts, good architecture, monitoring, adherence to specific quality metrics (SLA/SLO/SLI), and meeting Non-Functional Requirements. This is why it takes so long to develop.
Working prototypes don’t need that. You can throw them away, start from scratch, try a few different versions. Here's my experience: Before I built functionality for CodeAudits, which involved saving LLM API Keys (a task that took me a few days), I was able to generate three different prototypes of the UI within 30 minutes using the V0 platform. It was a game changer. Thanks to such rapid prototyping, I didn’t waste time building something that didn’t make any sense (iteration 1 or 2).
How AI Can Support Discovery
This is where GenAI shines. It can’t replace human intuition, judgment, or creativity—but it can accelerate discovery work when used right.
Here are a few powerful applications:
Rapid prototyping: Generate quick UI mockups from prompts or sketches.
API simulation: Generate example API contracts before backend work starts.
Diagramming and flowcharts: Create diagrams and flowcharts for user flows, complex algorithms, and decision trees.
DB schema drafts: Generate initial database models based on feature descriptions.
Configuration scaffolding: Create JSON/YAML config files or environment setups in seconds.
Design exploration: Use generative design tools to iterate on UI ideas.
None of these are end products, but they often provide a great baseline to iterate over.
For example, in my work, I find it helpful to ask an LLM to generate a flowchart in Mermaid to visualize user flow. Once have it, I can discuss the expected logic with the product manager to ensure we’ve covered all paths and states in the flow.
Another powerful flow is the one I shared with
in the article How to Use AI to Be a Great Engineering Leader. If a product manager wants to build a new feature, they do it in a "FullStack AI" tool (Lovable, Base44, v0). Once they achieve what they want, they share the complete prompt with the engineering team. Devs put that into Cursor / Copilot and ask AI agents to build such functionality using our internals: libs, design system, architecture components.
A New Mindset for the AI Era
So, how do you actually make this shift from a feature factory to a discovery-driven team?
It’s not about finding a magical AI tool to replace PMs or engineers. It’s about changing your mindset. This is the move from siloed roles to a team of Product Creators (read more in SVPG article: The Era of the Product Creator).
A Product Creator isn't a job title. It's a way of working. It's the belief that everyone on the team—product, design, and engineering—shares responsibility for the outcome. Not just their piece of the output.
What It Looks Like in Practice
For Product Managers: Stop being a backlog administrator. Your job is to be the first prototypist. Use AI tools to bring your ideas to life, test assumptions, and validate value before you write a single ticket. You own the "why," so show it—don’t just tell it.
For Engineers and Designers: You are not ticket-takers. You are problem-solvers. When a PM hands you a prompt from an AI tool, your job isn't just to build it. It's to ask: "Is this the best way to solve the problem with our tech stack and design system?" Use your deep expertise to challenge, refine, and co-create the solution. That’s how you deliver your full value.
For Leaders: Your role is to build the environment for this to happen. Hire for curiosity and a creator mindset—not just technical skills. Reward the team for killed prototypes and valuable lessons learned, not just shipped features. Create a culture where a great idea can come from anyone, and an engineer feels just as responsible for business value as the PM.
Ultimately, the true promise of AI isn't to automate delivery. It’s to supercharge discovery by breaking down the walls between roles. It’s about creating a team where everyone is empowered to figure out what’s worth building, together.
The Role of Engineering in Product Model Transformation
In this article, I intentionally omitted the section on using GenAI in the delivery process. Code completion, AI agents, testing, code reviews, and CI/CD assistants—what's happening now is truly transformative to how we build apps as software engineering teams.
But as long as we build the wrong things, this improvement doesn't really matter. In his book, Transformed, Marty Cagan states that only 10–30% of shipped features actually yield positive outcomes.
The true winners in the AI revolution won't be the ones who build things quickly, but those who build the right things.
How to ensure your engineering team contributes to this success? I invite you to read my series:
AI is just a multiplier. You must make sure it speeds up the right things.