What is AI prototyping?

AI prototyping is using AI coding tools to build a real, working version of an idea fast enough to test it, instead of drawing a mockup or writing a spec. Because agentic coding tools now write most of the code, you can describe a dashboard, an internal tool, or a rough product flow and have something usable in a browser the same day. OpenAI's Greg Brockman puts it plainly: the cost of building a prototype is so cheap now that if you want a dashboard, you just build it. The point of an AI prototype is not to ship it; it is to answer a specific question about your product, your users, or your idea, then decide what to do next. Treat it as the fastest way to turn a guess into evidence, not as production software.

Why is human attention the bottleneck in AI development?

Because AI removed the constraint that used to slow everything down. When agentic coding tools went from writing about 20 percent of your code to roughly 80 percent, building stopped being the hard part. What is left is the part only a human does: deciding what to build, reviewing what the agent produced, and choosing what matters. Greg Brockman argues that human attention is now the most important bottleneck in using AI systems, because the models can generate far more than any one person can meaningfully direct or check. The best engineers report they can only track three to five agents at once before their own working memory caps out. So the scarce resource is no longer typing speed; it is the quality and focus of the attention you point at the work.

Should you ship an AI-built prototype to production?

Usually not without a rewrite and a review. A prototype exists to answer a question fast, so it is built for speed, not for correctness, security, or scale. AI-generated prototype code often carries real problems that do not show up in a demo: missing authentication, hardcoded secrets, no input validation, and no error handling. The cheapness of building is exactly what tempts founders to promote a prototype straight to production because it already works on their screen, and that is how vulnerabilities ship. The safer pattern is to treat the prototype as a throwaway that taught you something, then rebuild the parts you keep with the quality bar production demands, including a security review before real users or real data touch it.

How many AI agents can one founder manage at once?

In practice, about three to five at a time. The limit is not the tools; it is human working memory. Engineers running fleets of coding agents consistently report that beyond three to five parallel agents, they lose the thread of what each one is doing and can no longer review the output well. This matters for AI prototyping because the constraint has moved from how much you can build to how much you can hold in your head and check. Running ten agents you cannot supervise produces more code but less useful work, because unreviewed output is a liability, not progress. The practical move is to run fewer prototypes at once, give each a clear question, and actually look at what comes back.

AI Prototyping: Attention Is the Bottleneck

Building a working prototype used to cost days of engineering time. Now it costs a prompt. In a Sequoia conversation, OpenAI co-founder and president Greg Brockman describes the change in one line: "The cost of building a prototype is cheap now. It's so cheap, and if you want to build a dashboard... you just do it now." The thing you would have scoped, staffed, and scheduled, you now just build.

That sounds like pure upside, and mostly it is. But when building gets this cheap, the scarce resource moves somewhere else. Brockman's argument is that the new bottleneck is not compute or code, it is human attention: the models can produce far more than any one person can direct, review, and decide on. The founders who win the AI prototyping era are not the ones who generate the most prototypes. They are the ones who spend their attention well. Here is how to do that.

What AI prototyping actually means now

An AI prototype is not a clickable mockup or a slide. It is a real, working thing you can use in a browser today, built by describing it to an agent instead of hand-writing it. The fidelity that used to take a small team and a week now takes an afternoon.

The examples are getting almost mundane. Brockman's dashboard is one. In a YC Root Access interview, the founder of an AI-native ERP company described how their first working product was built in Google Sheets and usable in a browser, a rough prototype that proved the idea before any real engineering. That is the shape of modern prototyping: get something real in front of the question fast, learn, then decide.

The founder and CEO of Framer, Jorn van Dijk, makes the sharper point that when prototyping becomes easy enough, it starts to eat the other ways teams used to work. Why produce a static design, then a spec, then a build, when you can produce the working thing directly and skip the lower-fidelity steps entirely? For a founder, that collapse is the opportunity: the prototype is now the fastest path from a guess to evidence.

Building got cheap, attention got expensive

The reason to care about your attention is that the numbers moved fast. Brockman describes the jump bluntly: "We went from these agentic coding tools writing 20% of your code to writing 80% of your code." When the tool writes four-fifths of the code, the hard part is no longer the code.

What is left is the part only you can do. Deciding what is worth building. Reading what the agent produced and catching where it went wrong. Choosing which of five prototypes actually answered the question. Andrej Karpathy, who distinguishes vibe coding from professional agentic engineering, makes a related point: even as agents get more capable, your own understanding stays the bottleneck in directing them. The model is not the limiting factor; your ability to hold the problem in your head is.

That limit is concrete. Engineers running fleets of coding agents report that they max out at three to five agents at once, because that is roughly how much a human can keep in working memory before losing track of what each one is doing. Past that point you are not directing agents, you are just launching them. More output, less control. The bottleneck Brockman names is not a metaphor; it is the size of the window you can actually pay attention through.

Prototype to decide, not to ship

Because building is cheap, it is tempting to treat every prototype as the start of a product. That is the trap. A prototype earns its keep by answering one question, then most of it should be thrown away.

Give each prototype a single job before you build it. Will users understand this flow? Does this integration return data we can use? Is this feature worth a real build? A prototype that answers one clear question is worth more than a polished one that answers none. When the answer is in, you have what you paid for: a decision. Keep the insight, discard the code.

Startups feel constant pressure to move fast because runway is finite, and cheap prototyping is a gift to that pressure, as long as you spend the speed on learning rather than on polishing throwaways. The failure mode is using near-free building to produce more unvalidated stuff faster. Brockman's caution fits here: "These models have such power, and really understanding how to operate them well takes thought." The power is real. Operating it well, pointing it at the right question and reading the answer honestly, is the skill.

Run a prototyping loop that respects your attention

Treat your attention as the budget and design the loop around it:

One question per prototype. Write the question down before you prompt. If you cannot state what the prototype will decide, you are not prototyping, you are wandering.
Cap the parallel work. Run three to five prototypes or agents at a time, not ten. The best practitioners of coding agents keep their projects lean, with less code and less plumbing, precisely so they can still understand what is happening.
Timebox and kill fast. Give a prototype an afternoon, not a sprint. If it has not answered its question, that is an answer too. Kill it and move on.
Review what comes back. The output is only useful if you actually read it. Unreviewed agent output is not progress, it is unmeasured risk.

Done this way, AI prototyping is what lets a very small team punch far above its size. Brockman expects the future to lean toward smaller teams and more solopreneurs precisely because tools like these compress the work, an expectation Perplexity's CEO echoes when he says there will be many more companies running with small software teams. The advantage is real, but it comes from directing the tools well, not from generating the most output.

The security line most prototypes quietly cross

A prototype built for speed is, by definition, not built for safety. This is where the CISSP in me gets nervous. AI-generated prototype code routinely ships with hardcoded secrets, no authentication, no input validation, and no error handling, because none of that was the question the prototype was answering. That is fine while it lives on your laptop. It stops being fine the moment cheap building tempts you to push it to real users, because it already works.

The rule is simple: a prototype is a throwaway until it has been rebuilt and reviewed. Keep what you learned, then reconstruct the parts you are keeping to the standard production actually requires, with a security review before real data or real users touch it. And you can turn the same cheap AI power on the problem: agents are now good enough to run end-to-end red teaming against a codebase and surface issues before an attacker does. Point that same power at defense, not just at building.

What to do this week

Pick your three highest-uncertainty questions about your product or idea, the ones you keep debating without evidence.
For each, write the single question a prototype needs to answer, then build the smallest working thing that answers it. Timebox each to an afternoon.
Run them one at a time, or at most three to five in parallel, and actually review the output rather than just launching more.
When a prototype answers its question, record the decision and delete the code. Keep the insight, not the throwaway.
Before anything you built moves toward real users, put it through a proper rebuild and a security review. Never promote a prototype to production just because it works on your screen.

Cheap prototyping is the biggest gift AI has given founders, but it only pays off if you treat your attention, not your build speed, as the thing to protect. Deciding what to build, how to run the tools, and where to point your focus is the operating system we teach in the AI Operating System for Startups. Once a prototype survives and you are ready to build it for real, the discipline for that is in from vibe coding to agentic engineering; if you are a non-technical founder taking a prototype toward a shippable product, see AI app builders.

Sources

OpenAI's Greg Brockman: Why Human Attention Is the New Bottleneck (Sequoia Capital), the conversation this article distills, where Brockman describes the cheap cost of prototypes, the shift from agents writing 20 percent to 80 percent of code, and human attention as the new bottleneck.
CEO of Framer: Why Designers Should Become Founders (YC Root Access), Framer CEO Jorn van Dijk on how easy prototyping starts to replace the other, lower-fidelity ways teams work.
The ERP for the AI Revolution is here (YC Root Access), the founder whose first working product was a prototype built in Google Sheets, usable in a browser.
Andrej Karpathy: From Vibe Coding to Agentic Engineering (Sequoia Capital), on understanding remaining the bottleneck in directing AI agents.
The Tool the Best Engineers Are Using Right Now (YC Root Access), an engineer on being bottlenecked by human working memory at three to five agents at once.
We're All Addicted To Claude Code (Y Combinator), on prototyping fast with coding agents, startup speed pressure, and top practitioners keeping projects lean with less code.
Perplexity CEO on the future of software teams (20VC with Harry Stebbings), on many more companies running with small software teams.
Background on Greg Brockman: Wikipedia and his OpenAI leadership profile, OpenAI co-founder and president, previously CTO of Stripe.