We built an AI Prototype Factory. Here’s what we learned

Software prototypes are useful because they turn an idea into something people can actually see, click through, and discuss. But building one still takes time. Even with an AI Prototype Factory approach designed to accelerate the process, someone needs to interpret the requirements, design the interface, implement it, test it, and make it accessible.

So we started experimenting with a different approach: could multiple AI agents handle most of that process on their own?

The result is an early internal experiment we call the Prototype Factory — a tool that takes specifications, mockups, and other project context and orchestrates several AI agents to turn those inputs into a working, shareable prototype.

This remains largely an experiment. But that’s precisely what made it truly worth creating.

Why build an AI Prototype Factory?

The original problem came from conversations with our Growth team.

After talking with a potential client, the team may have specifications, notes, mockups, or an idea for an application. Being able to turn those materials into something tangible for a follow-up conversation could make discussions much more concrete.

The question was whether we could shorten the path from those initial materials to a working prototype without requiring a developer to manually build every demo.

That became the basic idea behind the AI Prototype Factory.

The input can be relatively simple: a Markdown file containing requirements, several mockups, additional notes, or a combination of them. The specification can describe the MVP scope, concepts, expected flows, and other context needed to understand what should be built.

Technically, even a prompt such as "Build me a to-do app" can be enough to start. But unsurprisingly, the quality of the result depends heavily on the quality of the context.

The more specific the input, the better the prototype can be.

From there, the interesting part begins.

One AI agent wasn't enough

Instead of giving everything to a single coding agent, we experimented with multi-agent orchestration.

At the center is an orchestrator responsible for managing the process. Rather than doing all the work itself, it delegates individual responsibilities to specialized sub-agents.

Conceptually, the workflow looks something like this:

Input → Orchestrator → Brand analysis → UX planning → Implementation → QA → Deployment

This separation is important.

An implementation agent doesn't necessarily need to spend its context reasoning about the overall time budget. A QA agent doesn't need every detail involved in researching a brand. And the orchestrator doesn't need to write every component itself.

Each agent gets a more focused job and the context needed to perform it.

Different agents, different responsibilities

One of the agents can act as a brand analyst.

If sufficient brand information isn't included in the input, the agent can inspect a website and identify things such as its primary colors. Those findings can then be passed further into the workflow.

Another agent acts more like a UX designer. It takes the original specifications together with available brand information and prepares the UI plan. The process can also use predefined skills and design guidance, which opens an interesting possibility: instead of letting every prototype develop its own visual language, we can provide rules for components, buttons, layouts, and other UI decisions.

The implementation agent then receives the specification and UI plan and turns them into the actual application.

But generating code isn't the end of the workflow.

The AI also has to check its own work

Once the implementation agent thinks the prototype is finished, another agent takes over: QA.

The QA agent launches the application, interacts with it through an agent-controlled browser, clicks through the interface, and checks whether the implementation corresponds to the original specification.

If it finds an issue, it reports the problem back to the implementation agent.

The implementation agent makes changes.

QA tests it again.

That creates a feedback loop:

Implement → Test → Report → Fix → Test again

The cycle continues until the agents are satisfied with the implementation or the overall process reaches its allocated time budget.

This was one of the more interesting parts of the experiment. Generating an interface with AI is relatively easy. Creating a process in which generated work is independently checked, corrected, and verified is a much more useful engineering problem.

From source files to a working prototype

From the user's perspective, the intended workflow is deliberately simple.

Provide the source materials, give the run a name, add any additional instructions, define a time budget, and start the process.

Behind that simple interface, the orchestrator coordinates the individual agents through research, planning, implementation, and QA.

When everything succeeds, the result can be deployed and made available through a shareable link.

During our early tests, one prototype took roughly two hours to generate. After the initial input was provided, the process required no additional user interaction: the agents handled planning, implementation, QA, and preparation of the working prototype themselves.

That's promising, but it's important to put that result into context.

At this stage, we've only run a small number of prototypes through the system. It isn't enough data to claim that every prototype can be produced in two hours — and that isn't really the point of the experiment anyway.

What we wanted to understand first was whether the workflow could work at all.

And it could.

Time changes how the agents work

One interesting aspect of the AI Prototype Factory is that the orchestrator can work with a time budget.

If it has plenty of time, it can perform more research and allow the individual agents to spend longer planning, implementing, and testing.

Give it only 20 minutes and it needs to make different decisions.

For example, there may not be enough time for a brand-analysis agent to investigate an entire website. The orchestrator can skip lower-priority work and focus on producing something useful within the available time.

That introduces a constraint familiar to human engineering teams: you can't optimize everything at once.

Scope, quality, research, implementation depth, and available time all influence one another. Giving an AI workflow a time constraint forces the orchestration layer to make some of those trade-offs explicitly.

The agents don't have to be tied to one model

Another useful property of this architecture is that the individual roles aren't necessarily tied to one AI model or coding harness.

The configuration can determine which agent handles a particular responsibility. An implementation agent can therefore be swapped without redesigning the entire workflow.

In practice, switching isn't completely frictionless. Different harnesses have their own configuration details and behaviors that need to be taken into account.

Still, separating the role an agent performs from the model or tool performing it gives the architecture flexibility.

It also makes experimentation much easier.

Instead of asking "Which model is best?", we can ask a more useful question:

Which model or agent setup works best for this particular task?

Context becomes an architecture problem

Working with several agents introduces another challenge: context.

Giving every agent every piece of information may sound convenient, but it can quickly become inefficient. Different agents need different information to do their jobs.

The orchestrator needs to understand the overall process and keep track of the time budget.

The UX agent needs specifications, brand information, and design guidance.

The implementation agent needs the specifications and UI plan.

The QA agent needs to understand the expected behavior well enough to verify the implementation.

Thinking deliberately about who needs which context becomes part of designing the system.

This is one of the larger lessons from experimenting with agentic workflows: once multiple agents are involved, orchestration isn't simply about launching several models. You need to think about responsibilities, context boundaries, communication between agents, failure handling, and when the process should stop.

And yes, things break

This wouldn't be a Dev Diary if everything worked on the first attempt.

During development and testing, runs failed. Deployment failed during the live presentation. Network interruptions had to be considered. An update to one of the underlying tools broke parts of the Prototype Factory because a version hadn't been pinned.

Agent-based development doesn't make ordinary software engineering problems disappear.

If anything, it adds another layer.

You still need deterministic checks around a non-deterministic process. The AI Prototype Factory therefore verifies that expected artifacts have actually been created and are in the required format before treating the process as complete.

Recovery is another area we're experimenting with. For some failures, the system can detect that an agent stopped unexpectedly and prompt it to inspect the previous error and try again. Other situations still require additional handling.

These aren't side issues. They're part of what turns an interesting AI demo into a system that could eventually be dependable.

What the Prototype Factory can't do — yet

The current version is primarily intended for presentational prototypes.

It doesn't automatically create production systems with real databases and complete backend integrations. Those capabilities could be added for specific use cases, but they would also increase the complexity and time required to generate a prototype.

And that's an important boundary.

The goal isn't to pretend that an AI-generated prototype is production software.

The goal is to quickly turn an idea into something tangible enough to demonstrate a concept, validate a flow, or start a more concrete conversation.

Iteration is another area we're considering. Because the underlying agent session can continue after the initial prototype has been generated, follow-up instructions could be used to modify the result. But supporting a one-shot prototype and supporting repeated, controlled iteration are slightly different problems, and the latter deserves its own design considerations.

What we'd measure next

The Prototype Factory is still at an early stage, so the next step isn't adding a long list of features.

It's running it.

We need more prototypes and more data before drawing conclusions about how useful the approach really is.

Some of the metrics we're interested in are straightforward:

1. time to prototype,
2. consistency of generated prototypes,
3. amount of human intervention required,
4. quality after the first run,
5. reliability of the QA loop,
6. cost of generation,
7. and how much iteration is typically needed before a prototype is useful.

Only after running the workflow repeatedly will we know where multi-agent orchestration genuinely helps and where a simpler approach would be better.

Could a prototype eventually start during the discovery call?

There's an interesting direction this experiment could take.

Imagine a discovery call in which requirements are being discussed with a potential client. A separate AI workflow could process the transcript, extract requirements, and gradually turn them into structured specifications.

Those specifications could then become input for the Prototype Factory.

By the time the conversation ends — or shortly afterwards — the first rough representation of the idea could already exist.

We're not there today, and generating something useful that quickly introduces a completely different set of challenges. But it's an interesting question to investigate.

The bigger opportunity isn't simply making developers type code faster.

It's reducing the distance between an idea and something you can interact with.

What we learned

The Prototype Factory started as a relatively small experiment with a new multi-agent harness. It quickly became a useful way to think about a broader question: what does software development look like when AI agents aren't just assistants, but participants in a structured engineering workflow?

Our early experiments suggest that the interesting part isn't simply giving an AI model a specification and asking it to generate an application.

It's designing the system around it.

Which agent should plan? Which should implement? Who verifies the result? What context does each one receive? How should failures be handled? When should the system stop? And where does human judgment still need to enter the process?

Those questions are much closer to software architecture than prompt engineering.

The AI Prototype Factory is still early, and there's plenty left to test. But that's exactly why we're experimenting with it now.

Sometimes the fastest way to understand what AI agents can actually do isn't to discuss their potential. It's to create something using them and discover where they fail.