Core Thesis: While generative AI has drastically reduced the cost of creating demonstrable software, frictionless generation cannot replace the reflective inquiry of genuine product design. As teams quickly generate screens, workflows, and schemas, the instant gratification of a working prototype often obscures whether a feature actually solves a real problem or merely fulfills a prompt. When these interactive artifacts are prematurely elevated to specifications, they embed unexamined assumptions into production code, driving conceptual fragmentation across organizations and creating uncoordinated systems. Ultimately, true product judgment lies not in building software faster, but in exercising the critical discipline required to question assumptions, refine core relationships, and eliminate unnecessary creation before a flawed first guess defines what was needed.
Introduction
Software can now emerge from a sentence, a sketch, or a half-formed idea. Interfaces appear. Schemas appear. Workflows appear. Much of the code appears with them. An application can be deployed and shared before the problem behind it has been properly examined. The cost of making something demonstrable is collapsing.
We are entering the Age of Infinite Prototypes.
A working artifact shows that a capability can be used. It doesn’t mean it’s the best fit for the product or that the product is better because of it. Yet those distinctions are easily lost in the satisfaction of making something work.
It Works!
A common pattern in AI-assisted prototyping starts with a thought: “Could it also do this?”
The tool adds the capability, and the person tries it. If it works, they move on to the next possibility. Each addition provides an immediate reward: something imagined becomes something demonstrable. This process gives the person a sense of progress, agency, and a perceived confirmation of their judgment. But what has been confirmed?
The tool has fulfilled a request, which is a positive outcome. But, this doesn’t necessarily mean it has good design.
Simply saying, “It does what I asked,” doesn’t make it a good addition. Over time, a series of successful additions can lead to the perception of a good product. Every prompt generates accumulation while the whole becomes harder to understand. Features can share typography and navigation while embodying conflicting ideas about how the work should happen. The demonstration can succeed while the design gets worse.
In this feedback loop, the immediate gratification comes from using the tool to generate content. However, we can’t be certain if the user’s output actually meets the specified requirements. The user is likely to be pleased with their own accomplishment and believe that this demonstrates the product’s effectiveness.
Design Decisions Without Design Inquiry
The issue isn’t that design decisions aren’t being made; rather, they’re being made without adequate scrutiny.
The person identifies a need and requests a capability. The agent provides objects, relationships, states, screens, and interactions. The person observes something functioning and proceeds accordingly. A representation has already been selected and serves as the starting point for subsequent additions.
The reflective process of design has been bypassed, leading to an increase in design decisions.
Design involves creating relationships between possibilities. Some should merge, others reveal deeper concepts, some change framing, and many should disappear. Much of this work doesn’t require implementation. We don’t have to build every proposed capability to discover duplication, contradiction, or lack of connection to a need. Without this examination, accumulation replaces conception. The Post-it wall becomes the product.
Fluency in creating artifacts can feel like mastery of the disciplines they represent. For instance, someone who can produce screens, workflows, and code might start to see themselves as a product designer, architect, and software engineer. However, the issue isn’t their job title; it’s the assumption that successful generation implies the judgment needed to decide what should be created. AI can help with this judgment by challenging assumptions and suggesting alternative ideas. But even a generated idea still needs to prove its worth.
When the Prototype Becomes the Specification
Then the application link arrives. “I want something like this.”
The receiving team, engineering, is presented with a solution before they have a clear understanding of the problem. Often, the request is not to preserve the generated code. The author acknowledges that the engineering team may rebuild it. But, what they expect to preserve is what the application appears to do: its features, screens, objects, and workflows. Replacing the implementation does not reconsider the conception.
Even if a team rewrites code, they may still rely on unexamined assumptions. The prototype reflects someone’s understanding of what’s needed, not the requirement itself. Interpretations and design choices exist between the need and the artifact, some from the requester and others from the agent. Some choices are essential, while others are preferences, conveniences, or defaults. The working application doesn’t distinguish between these choices, giving them authority. Before the application, someone might have explained why a feature was included, but afterward, someone else must explain why it should be removed. “Why do we need this?” becomes “Why can’t you build what I’ve shown you?”
The implementation task typically begins by recovering the problem from a flawed prototypical solution.
Recovering the Problem
This isn’t about taking apart the code to understand how it works. Instead, it’s like figuring out how something was built by looking at the choices made along the way, even if those choices weren’t always planned or even thought about.
Consider a prototype showing managers a dashboard of overdue approvals. The dashboard makes several assumptions tangible: approvals are necessary, managers should monitor them, a dashboard is the appropriate mechanism, and overdue status is the right signal. Perhaps those assumptions are justified. But further inquiry might reveal that the underlying concern is preventing decisions from blocking work. That opens other possibilities: changing decision rights, removing unnecessary approvals, routing exceptions, or notifying the responsible person at the moment intervention becomes useful. Demoing the dashboard doesn’t prove it’s the right interpretation of the concern.
That’s why the repeated question matters: Why? Not as a ritual, but as a refusal to stop at the first proposed mechanism. What’s happening? Why is it a problem? What must change? Why should this capability produce that change? The need may require discovery and negotiation. A polished interface doesn’t remove that work. Inspecting the application can’t complete it. The same feature could’ve been proposed for different reasons. The artifact can’t reliably recover intentions that weren’t expressed. The link can begin a conversation. It cannot substitute for one.
The New Spreadsheets
The problem worsens when this pattern spreads across an organization. Each person creates an app for a specific local problem, such as tracking customers, managing exceptions, approvals, planning, reporting, or coordinating work. Together, these apps create an organization of disconnected representations.
We can compare this to spreadsheets, those little tools that quietly evolve into go-to information systems for many. We start using them for our daily tasks, and soon enough, they’re handling more and more responsibilities because they’re so handy. Spreadsheets are great for organizing and analyzing data in a tabular way. But guess what? The applications we create from them aren’t limited to that simple format anymore. With some prompting, generative AI tools can transform almost any need into a screen, database, permissions, and even a fully-fledged business system.
The scope for fragmentation expands with the scope for creation.
The silos are conceptual before they are technical. Separate applications can be appropriate. The problem is separation established by who happened to generate an app, rather than by a considered boundary in the business. Connecting these applications afterwards may move data without resolving incompatible meanings or unclear authority. Many companies will acquire an architecture that nobody deliberately designed.
Production Is Not Just BETTER Code
This is why the phrase “make something like this production-ready” often conceals significant unfinished work.
While reliability, security, testing, and maintainability are crucial, they are not the sole focus. The application must also be integrated into an existing system. Which system holds the relevant information? What do its objects signify in other parts of the company? Who has the authority to modify them? What happens when a local workflow crosses departmental boundaries? Does this capability truly belong in a separate application altogether?
Such questions can’t be resolved by simply refining the prototype. Sometimes, a different workflow is needed to achieve the right result. Multiple prototypes may represent a single need. A seemingly useful feature may be removed because it creates redundancy. The author sees a working application they prompted into existence, while the engineering team sees unresolved business relationships.
The disparity between “already built” and “ready to use” isn’t just about engineering speed. It includes requirements inquiry, conceptual design, organizational decisions, and integration work that the prototype overlooked.
Generating Commitments
Conceptual choices become especially consequential when AI begins generating from them. Names become prompts. Objects become schemas. Relationships become APIs. Workflows become agent instructions. A provisional interpretation can swiftly spread throughout code, tests, documentation, and interfaces. Since everything inherits the same assumptions, everything appears to agree. AI can industrialize a category mistake.
Internal coherence alone is insufficient. A model must maintain the necessary distinctions and relationships to support its intended purpose. But, these choices become increasingly difficult to modify as they are incorporated into stored data, integrations, procedures, and user expectations.
Regenerating the code does not automatically regenerate the organization around it. What was cheap to create can become expensive to question. People have demonstrated it, discussed it, planned around it, and begun to regard its behavior as a commitment. Cheap generation does not make every consequence of generation cheap to reverse.
Prototypes Should Test
None of this diminishes the value of making.
A prototype externalizes a conception. It can reveal awkward relationships, expose assumptions, and allow people to discover needs they could not previously articulate. But its value depends on what we allow it to question. If every test asks whether a feature works, the conception that produced the feature remains protected. The interface improves. The workflow becomes smoother. More cases are handled.
The team may simply be producing a more complete version of the first guess.
A prototype should also provide evidence to determine if its objects, boundaries, and relationships are appropriate. It should help us understand whether the proposed capability is suitable and how it fits into the larger system of work.
Sometimes, this evidence justifies another iteration. Sometimes, it justifies a different conception. Sometimes, it justifies not creating another application. Conceptualization happens before, during, and through making. The point is not to finish thinking before building. It’s to prevent prematurely closing the questions we still need to ask.
The UNSEEN Work
This creates a difficult asymmetry.
Adding something produces a visible result. Recognizing that it should not exist produces nothing that can be demonstrated to others. Someone combines three proposed applications into one shared capability. Someone removes a workflow by clarifying responsibility. Someone introduces a better distinction and avoids months of exception handling. The visible output shrinks. The value appears in work that never becomes necessary.
That saving is real only when the work has been eliminated, rather than hidden or pushed onto users. But when it is real, its absence can make the thinking behind it difficult to recognize. The discarded possibilities are part of the result.
An organization that solely rewards visible creation will face challenges in valuing the judgment that prevents unnecessary creation. The rise of AI has only intensified this imbalance, making it more significant.
Before Another App
The Age of Infinite Prototypes does not make design less important. It makes it easier to proceed without recognizing where design was needed. A working application can now arrive before a shared understanding of the problem, acquire the authority of a specification, and introduce another set of assumptions into the company’s information systems.
The task is not merely to turn those artifacts into dependable software. It is to establish what need they express, which choices are justified, and how they belong to a coherent whole.
A strong product contains a way of seeing. Its boundaries express judgment. Its vocabulary expresses a model. Its omissions express a thesis. Those choices must remain open to examination, even after someone has made them clickable. The danger lies not in building the wrong thing, but in letting the first thing we build define what was needed.