Building Safer Vibe Coded Applications

The question behind the work

In A Safe Path From What If to Real Change we asked how a business user could be granted a temporary “What If” environment to vibe-code an idea without touching the live system. The thesis is that this allows fast prototyping that can then enter a verification step once complete. In this piece we explore a method for keeping part of an application free for business users to change while controlling its higher-risk parts at the same time.

A membership organisation came to us with this problem. In the past their systems had become museum pieces, encapsulating the technology of the moment they were built. They wanted a modern AI-based platform their business users could update, in the way Replit or Lovable allow, but they had areas, memberships, payments and renewals, where their current level of proficiency and comfort made that kind of system inappropriate for now.

So the work was not “build this app.” It was to find a way for the organisation’s own people to be free to build, while holding safe the parts of the application that carry risk, then give each side tooling that suited it.

The background: a growing choice of tooling

Desktop and cloud agents like Claude Cowork, OpenAI Dots or Grokbot are, for many users, the first port of call for personal applications, and now that most of them integrate with tools like Slack they are a good fit for teams too. They create their user interface ephemerally, just in time, incredibly satisfying for power users but less of a fit for a workflow that needs to be predictable, audited and repeatable.

AI app builders like Lovable or Replit let a user with strong functional understanding describe intent and watch an application appear, then edit and iterate in long-running conversations. Unlike previous generations of low-code technology they are not fixed into a specific user interface paradigm of content blocks and rules. They are much more likely to produce something that matches the user’s intent, and that a sophisticated user can take to a high level of unique quality. They benefit from a constantly upgraded corpus of application frameworks and tooling, and they increasingly do a good job of verifying their own quality and completeness. For smaller organisations, or for business-unit-specific apps, they have become legitimate options for applications with small to moderate risk: databases, different levels of user security, taking payments, or integration with accounting platforms like MYOB or Xero. In many cases the output is still similar for end users and the economics can be quite low and predictable once the application is constructed, you can even run your app off the platform into your chosen enterprise friendly runtime environment.

AI coding platforms like Codex, Devin or Claude Code sit at the other end. An engineer or team directs many agents through a continuously improved pipeline, and every change moves through custom suites of tests, reviews, pull requests and releases. The output is software, held to engineering discipline. This asks for more of a software factory mindset, or in a business unit the kind of skills which at least require an engineer on retainer committed to the continuous improvement of the factory and the business application.

Declarative application frameworks are an interesting toolset to reduce the risk of purely vibe-coded applications. It is still true that the safest code is the code nobody has to write, and the common create, read, update and delete work of a business application can be a reusable component, not a fresh generation each time, trading off some flexibility for trusted assurance. FusionFrame is just one example, and features built-in software lifecycle tooling that creates enterprise artefacts describing the system, which update as the application changes, this pattern is one that every software house is bound to adopt.

The SaaS platforms are repositioning. Despite predictions of a SaaSpocalypse, platforms built to be the whole application now present themselves as a trusted layer for whatever comes next.

In each case the platform keeps the records, the permissions and the audit trail, and gives up its monopoly on the screen.

That is what the membership organisation’s request was really pointing at: a stable spine and a free surface.

What we built

We split the system in two, along the line the requirements had already drawn.

The main app: a surface the business updates

The main app holds content and presentation only. A business user vibe-codes it in an AI builder, and it is synchronised to source control and staged for deployment. This layer holds no secrets, no database key and no backend of its own. The AI builder will offer to add one, so the design uses contracts and verifiers in the deployment pipeline to enforce the rule, and skills and knowledge at the front end to guide the user.

Because the main app has nothing to protect, the business user can be given real freedom. Pages can be rebuilt, restyled and rewritten in the editor. The brand design system is shared with Core, and neither side hand-writes a brand colour, so a sign-in screen built by an engineer looks like a page built by the business user.

Core: a spine under change control

The higher risk data and services live in a separate Core, built on our AI development pipeline with the discipline that implies: typed contracts, unit tests, review on every pull request, and releases cut from a workflow rather than a laptop. The core is small. That is the point. The primitives are few enough that an engineered core stays legible, and a legible core can be kept under change control without becoming a bottleneck. Core also decides what the main app may ask of it: a short list of paths built for it, and nothing else, enforced on every request. The shape of each answer, a member, a dashboard, a renewal, is one contract file both repositories read, so the business user’s pages and the engineer’s endpoints are built against the same definition.

Designing against real states without real data

A business user working in the AI builder sees their page on a staging site, where Core serves simulated data instead of real records: a persona for each target use case, realistic enough to work with, in the shape of the real answer. The same pages, once deployed, run against live data. So they can build and test every state of a page, from the renewal reminder to an overdue invoice, and what they see in the editor is what a signed-in member will see in production.

What makes the safety line hold

Every tool in the chain was willing to blur the boundary. The AI builder is happy to create new connections and backend services on demand, but without the necessary secrets, and informed by the contract, it stays within the agreed design.

Knowledge: decisions codified as you go. The rules are written into the AI builder’s knowledge, so the platform can explain them to the user as it works.

Skills: pointers to the best path. Skills are created in the AI builder describing how to perform common tasks in line with the design.

Contracts: rules that can be verified, not suggested. Knowledge and skills are not enough on their own. Contracts in the deployment pipeline enforce the rules the builder has already been guided on, so “the main app may call these paths and nothing else” is checked rather than hoped for.

Verifiers: enforcement that needs no discipline. A check fails if the contract drifts, or if the brand is overruled. The tests for Core’s list of open paths run on every change. None of it depends on anyone remembering, which is the point: the business user’s freedom rests on verification that runs whether or not anyone is paying attention.

Two more things stood out.

Business-user-built surfaces have a look, and it cuts both ways. A recent Dreamforce session showed an early, large-enterprise version of this pattern: business teams building their own interfaces over the platform’s records. What stood out to us was how home-made and quirky those designs looked next to professional software we would hold up as high quality. For a small team a quirky app might earn affection, but as new users meet it, it is likely to reduce trust in the system. Our answer was to make building the brand system the first task.

The risk moved, and became easier to see. The likeliest failure is now a page that shows the wrong thing: visible, reversible and the business user’s to fix. The failure least allowed, a failed registration or an incorrect payment, sits where review and tests are routine. That is the whole argument for the split.

How much freedom, how much guidance?

As more control moves to business users, it is tempting to treat the choice as all or nothing: either the AI builds it or engineers do. Neither extreme fits a real organisation. A layer that holds nothing can be fully free. A layer that holds identity or money should be change-controlled. The grey area in between will remain a job for humans, who will keep improving the methods for verifying change. The evidence from this engagement is that a well-guided surface produces better, lower-cost systems than a locked-down one, because the person who cares about it holds the editor.

Where this goes

The pattern is the one the large platforms are arriving at from the other direction, and the one the what-if environment serves from the leader’s side: a stable, governed spine that owns the records, the permissions and the audit trail, and a free surface over it that the organisation’s own people can shape. For a membership body the spine is a few hundred lines of policy and contract; for an enterprise it is a system of action with thousands of agents. The question is identical: what should be free to change, what should not, and how is that line held?

If your organisation is weighing whether a vibe-coded application can be trusted with real work, or wondering why the thing that was meant to make everyone faster has instead made a few people nervous, that line is usually the conversation worth having first.

Helikona helps organisations navigate how to choose and adopt AI capability through short, focused engagements.

Implementation note: this engagement used Lovable as the AI builder, and Claude and Devin for AI coding.