Everyone can prototype with AI now. Here is why that is just the start.

Something remarkable has happened in the last two years. The tools for building with AI have become so accessible that almost anyone can create a working prototype. A marketing manager can build an email triage bot. A teacher can create a document summariser. A founder can wire together an AI-powered workflow over a weekend.

This is genuinely exciting. The confidence that comes from building something that actually works is transformative, and more people should experience it.

But starting and finishing are different disciplines. The gap between a prototype that works on your laptop and a product that works reliably for thousands of users is where most ideas quietly die. We have been on both sides of that gap, and this is what we have learned.

This is not hype. No-code and low-code platforms have matured to the point where non-technical people can build genuinely useful things:

• Automated workflows that sort emails, extract key data, and update systems without human input
• AI assistants trained on internal documents and knowledge bases
• Content tools that draft, summarise, and translate at speed
• Internal apps with forms, dashboards, and approval flows
• Data pipelines that pull from multiple sources and generate reports

McKinsey's 2024 Global Survey found that while 72% of organisations had adopted AI in at least one function, the biggest barrier to capturing value was not technology. It was the distance between the people who understood the problems and the people who could build solutions 1. No-code tools are compressing that distance. For the first time, the person with the idea can also be the person who builds the first version. As Chris Anderson argued in Makers, we are entering an era where the tools of production are being democratised at an unprecedented rate 11.

Ethan Mollick, professor at Wharton and author of Co-Intelligence, argues that the best way to understand AI is to build with it, not to read about it 2. We experienced this ourselves. When we started building CLARA, an AI research product we collaborated on with the University of Oxford, the early prototypes taught us more about what researchers actually needed than any amount of upfront planning could have. Once something is working, the conversation changes from "is this possible?" to "what else could I do?"

This is where most articles about no-code stop. For us, this is where the real work started.

The hallucination problem at scale

When we were testing early versions of CLARA with 20 queries, an AI that was right 92% of the time felt impressive. But researchers do not need impressive. They need correct. At 2,000 queries a day, 8% errors means 160 wrong answers. Some of those would be confidently wrong, which is worse than having no answer at all. Research from Stanford's Institute for Human-Centered AI has shown that even state-of-the-art models produce factually incorrect outputs at rates that are unacceptable for high-stakes applications without additional engineering safeguards 5.

Getting AI to behave reliably was not about writing better prompts. It required structured evaluation frameworks, retrieval-augmented generation to ground responses in real data, systematic testing across edge cases, and ongoing monitoring. Chip Huyen covers this comprehensively in AI Engineering, arguing that the real challenge of deploying AI is not building models but building the systems around them 12. These are engineering problems, not prompt engineering problems.

CLARA Research is an AI research assistant built as a collaboration with the University of Oxford 6. It helps researchers explore, search, and analyse large archival document collections and returns answers with full citation trails so every response can be verified.

The first prototype could search documents and return relevant passages. It was impressive in a demo. But it was not a product. Making it into one meant solving a completely different set of problems: building retrieval pipelines that handled the nuances of academic documents, implementing citation verification so researchers could trace every answer back to a source, designing for the kind of precision that academic work demands, and testing relentlessly against edge cases where a wrong answer would undermine trust.

That journey, from a prototype that searched documents to a product that over a thousand researchers now use, is the clearest example we can give of what "the gap" actually looks like. A prototype can find answers. A product has to be right, and has to prove that it is right.

Security and data governance

When a tool handles real data, a set of questions emerge that no-code platforms are not designed to answer:

• Where exactly is data being stored and processed? Which country? Which provider?
• Is the AI model retaining inputs for training? Are you inadvertently feeding proprietary data into a public model?
• Who has access, and how is that access controlled, logged, and audited?
• Does this comply with GDPR, SOC 2, or sector-specific regulations?

The EU AI Act, which came into force in 2024, introduces specific requirements for high-risk AI systems around data governance, transparency, and human oversight 7. The UK's ICO has issued clear guidance on the data protection implications of AI tools that process personal data 8. These questions need architecture, not configuration, to answer properly.

Integration with the real world

Prototypes typically live in isolation. They take an input, process it, and give an output. Production systems have to live inside existing ecosystems:

• Authenticating with enterprise identity providers
• Reading from and writing to databases that other systems depend on
• Handling API rate limits, timeouts, and partial failures gracefully
• Maintaining state across sessions and users
• Producing audit logs that meet compliance requirements

Each of these is solvable. None of them are solved by dragging and dropping components in a visual builder. Sam Newman's Building Microservices remains one of the best references for understanding the architectural complexity that emerges when systems need to communicate reliably at scale 13.

The 2am test

When something breaks at 2am on a Tuesday, can anyone diagnose it? No-code tools abstract away the internals, which is a feature during building and a risk during debugging. Production systems need observability: structured logs, error alerting, performance metrics, and the ability to trace a failure back to its root cause.

"Production-ready" is one of those phrases that gets used without much precision. When we were building CLARA, we had to get specific about what it meant for us. In practice, it meant a system that satisfied all of these:

A prototype might tick one or two of these. Production requires all of them. As Martin Fowler argues in Refactoring, the cost of changing software that was not designed for change increases significantly over time, and retrofitting quality into a system is almost always harder than building it in 10.

Despite everything we have just said about the gap, the prototype phase was the most valuable part of building CLARA. Not because the prototype became the product, but because it taught us what the product needed to be.

Before we had a working prototype, our understanding of what researchers needed was theoretical. Once they could actually use something, we learned things that no amount of planning would have uncovered. Which queries tripped up the AI. Which citation formats mattered. Where trust broke down.

The Standish Group's CHAOS Report has consistently found that fewer than 35% of software projects are completed on time, on budget, and with the required features, with poor requirements being a leading cause of failure 9. A working prototype changes this completely:

• The person with the problem has already worked through the edge cases
• The engineering work is informed by real usage, not assumptions
• Scope is grounded in reality, not aspiration

The prototype does not need to be elegant. It needs to be specific. A messy working example communicates more than a polished proposal ever could.

Not every idea needs production engineering. Not every idea should stay as a prototype. When we are deciding what to build at Tremoli, we think about three things:

1. 1Who is going to use it? If it is just us or a small team, a well-maintained no-code workflow might be all it ever needs. If real users are going to depend on it, it needs more.
2. 2What happens when it fails? If a failure is a minor inconvenience, the tolerance for imperfection is high. If it means wrong answers, lost data, or broken trust, the tolerance is zero.
3. 3How long does it need to last? A three-month experiment has different requirements than a product that will be running in five years.

We have found that the mistake is treating every idea as production-grade from the start. The cost and timeline become too high to justify experimentation, and nothing gets built.

The line between what anyone can build and what requires serious engineering is moving fast. Gartner has identified AI-augmented development as one of the defining technology trends through 2030 3. Microsoft's 2024 Work Trend Index found that the majority of AI users in organisations were already experimenting ahead of any formal strategy 4. The tools will keep getting better.

But capability is not the same as readiness. The fact that a model can generate code does not mean that code is secure, tested, or maintainable. The fact that a visual builder can create a workflow does not mean that workflow handles failure gracefully. The gap between "it works" and "it works in production" is narrowing, but it has not closed.

We will keep building. CLARA was our first product to make this journey from prototype to production, and it will not be the last. Every product we build teaches us something new about what it takes to make AI work reliably in the real world. Eric Ries made the case for rapid prototyping a decade ago in The Lean Startup 14. What has changed is that AI tools have made the prototyping phase accessible to everyone, not just developers. Andrew Ng's AI For Everyone course made a similar argument from the technical side: the biggest value comes from deploying AI broadly, not from perfecting individual models 15.

We are excited about what comes next.