Going Past the Vibes: How to Build Real Apps [Testμ 2026]

The Twelve Letters

The talk is built as an acronym. Seven letters spell WAY PAST, five spell VIBES, and each one names a habit from the prototyping era alongside the thing that replaces it.

W: Write the Skill Once

His example of the habit is one most people will recognise. He would type “redesign the dashboard” and then improvise the rest of the prompt, every time.

The rule he arrived at is a frequency threshold. Anything you do more than twice deserves a skill, and redesigning qualifies.

A skill is a file or a set of files carrying instructions that the agent takes as input when you invoke it, without you prompting for them. In Lovable they live under settings, in the customizations menu, and can be scoped to a whole workspace or to one person. You can import them from GitHub or write them from scratch, and a skill needs only a name, a description and content describing how it works.

Invoking his redesign skill produced several design options rather than one, on brand and consistent with the rest of the application. He also recommended building slide decks this way, calling it an easy use case to understand and one that resonates.

A: Draw the Change

He is direct about the reason this letter exists. He describes himself as a bad designer who still struggles to put visual changes into words, and assumes most of the audience is in the same position.

The alternative is to stop writing and start drawing. Circle an element to change it, put a cross through it to remove it, undo if the drawing goes wrong.

The annotation is rendered as a screenshot, so the agent works from a snapshot of what you drew rather than from your description of it. In the demo the change landed live on screen, driven by the drawing rather than the prompt.

Text is handled the same way, by clicking into the app as though it were a Word document and editing in place. Those visual text edits are free, showing zero credits used.

Y: Your Design System

The problem this letter names is the one people mean by AI slop: yet another off button in yet another off-brand shade, on every screen the model touches.

The answer he demonstrated shipped the day before the session, on Pro and Business plans. You can create a design system and use it as the source of truth for everything built afterwards.

Building one can start from your existing app. While preparing the talk he pointed it at a site and watched it browse the pages, take screenshots and generate colours, typography, iconography and reusable components from what it found. An image works as a starting point too, as do NPM or NPX packages for teams who want to bring their own.

Using it afterwards is a release and an attach. You release a version, click the plus icon, attach the design system, and subsequent work uses those tokens.

His framing of why this matters is about model behaviour rather than about design. AI is creative, likes to deviate and likes to do things its own way, and a design system is the constraint that keeps output on brand anyway.

P: Project Knowledge

Every new chat, every new project, every restart, you re-explain who you are and what the project is. Project knowledge and memory exist to carry decisions and constraints forward instead.

The most reusable thing in this section is not the feature, it is his verification trick. He writes into project knowledge: before any response, say back to me that we are using knowledge.

If the reply opens with that sentence, the agent is reading the file. If it does not, he knows before wasting a build. In the demo, a request to add an about section came back with the phrase, followed by exactly the three things he had specified: what changed, how to test it and what to build next.

Alongside project knowledge there is a memory of you, covering who you are and how you build, and it is editable rather than opaque.

A: API Keys and Secrets

He makes the case from his own starting point rather than from a security team’s. He had never written software before Lovable and barely knew what an API was, so managed secrets were not a preference, they were the only thing standing between him and a leaked key on GitHub.

Lovable ships over 140 connectors out of the box, and custom ones can be added. Connecting the demo app to HubSpot meant entering a client ID, client secret or service key into secure storage rather than into the chat, then approving the connector when it is needed.

Some connectors are restricted by design, so a collaborator inside the same workspace cannot see data they are not meant to.

On top of that, every code change triggers a basic security scan across the code and its dependencies, deeper scans can be run on demand, and the security memory can be edited to emphasise what matters to you. Both the scans and the fixes are free, which is the whole of his answer when the question comes up again in the Q&A.

S: Backend Out of the Box

The anecdote here is the sharpest illustration of the old way in the whole talk. When he started, free-tier limits meant one or two projects per account, so he ended up managing and paying for twenty or thirty separate backend accounts.

Storage, database, AI models and image generation now come switched on by default. Lovable Cloud moves state out of the browser and into storage that persists, and the Lovable AI Gateway covers text generation, analysis, research and image generation when a project needs them.

Social authentication lands in the same prompt. He contrasts it with the older path of opening the Google console and building an API key by hand, then shows a single prompt producing a database, an AI model and Google login together.

The demo ran against a real HubSpot instance, scoring a real lead for likelihood to close. Signed-up users, their sign-up methods, managed secrets and usage in run credits were all visible from the same place, which is the point he draws out: the tool is where you run the thing, not only where you build it.

T: Editing in Production

On most vibe coding platforms, editing a launched project means editing it while users are looking at it. He calls that scary, and it is the letter he says was always the painful one.

Drafts are the answer, still in beta at the time of the session and described as working like branching for anyone who knows git. They currently cover UI changes.

What that buys is genuine parallelism. Two agents run in the same project without interrupting each other, one on main and one on the draft, and he dictates his side of it by voice rather than typing.

When the draft is ready it merges, with Lovable resolving conflicts, and nothing on main is affected until that happens. His demo case was adding light and dark mode, which is exactly the kind of change you would not want to make live.

V: Lovable Everywhere

Here the acronym crosses over. Seven letters are spent, the remaining five spell vibes, and the first constraint he takes on is that building in Lovable used to mean being in Lovable.

Over MCP it now reaches your editor, terminal or chat. He found Lovable among the top connectors in the Claude marketplace, connected his account, and set the permissions, noting that he gives orchestrating agents full permissions so they can work without interruption.

The detail worth keeping is what Claude does and does not do in that setup. It does not build the project. It writes a prompt and sends it into the Lovable chat, and Lovable does the work.

He uses it as an intelligent orchestrator for brainstorming and planning, and pointed out on screen that the prompt which arrived in Lovable had been written entirely by Claude, not by him.

I: Your App as an MCP

He draws a line between two things that sound similar. Using the Lovable MCP is one thing. Turning the app you built into an MCP server is something else.

The agent integrations menu is where that happens. You enable agent integrations, define the MCP tools your app exposes, and publish, since an app has to be published for its MCP to work. Hosting comes with it, on a custom domain or a lovable.app one.

From there you take the MCP link, follow the generated connection instructions, and complete a single OAuth step to connect it to Claude.

His demo app, an agency tool called LaunchLine Studio that scans websites, then answered questions from inside Claude, including requests for its latest audit results. The consequence he draws is the one that matters for teams: not just Lovable, but the app you built on it, usable from any chat.

B: Bugs While You Sleep

He is unsentimental about the models doing the building. AI is still AI, some people call it average intelligence, and he agrees that sometimes it is quite average.

Which sets up the failure he wants to avoid: a bug surfaced on a Sunday afternoon by a customer.

Project monitoring, also in beta, checks code changes and recent error logs on a schedule you set, daily or triggered by an edit. Run history is visible, showing which days it ran and how many issues it found, and it emails what it finds. He showed a real email from an internal Lovable project flagging a problem nobody on the team knew about.

Internally the team calls it a heartbeat. His own description of it is a QA engineer running all night, clicking everywhere, trying to break the application.

E: Enterprise Trust

He named Uber, Nvidia and T-Mobile among the enterprises building on the platform, and framed trust as something that has to be present from day one rather than added when procurement asks.

On Business and Enterprise plans the controls sit at project or workspace level: blocking phishing, auto-fixing security issues, and sensitive data scanning that detects personally identifiable information and can block someone pasting in what they should not.

A workspace owner gets security insights and code analysis, can review secrets, can stop a sensitive project from publishing, and can read an audit log of who did what. Usage controls cover credits consumed for both building and running applications.

He also stated that Lovable recently became the first AI coding agent platform certified against AIUC-1, a standard for AI agents covering data and privacy, security, safety, reliability, accountability and societal risk, with the report downloadable from their site.

S: After You Ship

The final letter answers the question he says always comes: you have shown us how to build, what about afterwards.

Payments come first, through Stripe, Paddle or another provider depending on what is available in your country, with pay-as-you-go pricing and tax and compliance handling. Setup needs an email address, a business or personal name and a supported country, and a sandbox environment comes with it.

His comparison is the one that lands hardest. He once spent six months migrating between payment vendors with a team of ten engineers. The equivalent in the demo was three prompts.

Email follows the same shape, with no API keys and a guided process to bring in or buy a domain and set up a mailbox. Discovery is covered by a Semrush-powered integration that finds and fixes SEO issues, and analytics are built in rather than bolted on with a separate script.

He closed with an Easter egg: the presentation itself is a Lovable app at waypastvibes.lovable.app, and clicking the letter S gives you the brief to build your own version of it.

Q & A Session

Questions went into the Q&A box through the talk, and four made it into the time remaining.

• What is the most challenging feature or function to accurately vibe code?

  Lazar Jovanovic: Not a feature. Everything is buildable if you can describe it, and the difficulty with natural language is that people are not very good at natural language. The concrete failure is expecting something complex to land in one prompt, because a long prompt is not the same as a complete one. Every agent is constrained by the same finite resource, so the skill is estimating how much work fits inside the token budget you have. An about page is one prompt. A clone of Stripe needs planning, specs and perhaps fifteen PRDs supporting a larger piece of work. The real challenge is knowing when to vibe and when not to, and when to prompt versus when to plan.

• What strategies do you use to ensure a vibe-coded app meets security requirements?

  Lazar Jovanovic: I have no strategy. Every code edit triggers a scan for anything the agent may have exposed, and projects are blocked from publishing until major vulnerabilities are addressed. Since both the scans and the fixes are free, there is nothing to strategise about. Over 500 apps in, I have had no security problems so far. He means that as an argument rather than a shrug.

• How will vibe coding differ in 2027 versus 2026?

  Lazar Jovanovic: When Andrej Karpathy described giving in to the vibes in February 2025, that was an accurate account of the experience, and you did have to release control. Security controls, security reviews and a separation between production and development have moved it since. Find me an engineer today not using AI for most of their code. For 2027 I expect less typing and more voice, more agents running in the background from a script or a set of skills, and a job that narrows to judging what should be built in the first place. That is rewarding, because judgement is what humans are for.

• What automated eval framework verifies that an agent-built app is truly production ready?

  Lazar Jovanovic: I am not an engineer by background and I do not go deep into methodology. My approach is to ask Lovable to run an end-to-end test using whatever evaluation approach I ask for, since it can build Playwright tooling, browse its own app, click through it and sign up as fake users. Users do not care about the methodology, only whether the thing works, and a bug reported by a user can be fixed and shipped in five minutes. He is candid about the gap.

That last answer is a fair account of where the practice has got to, and also where the gap still sits. Asking a builder to test its own output catches what it thinks to check, and the failures that reach production tend to be the ones nobody thought to describe.

This session was part of Testμ Conf 2026, which ran across three days of sessions on agentic engineering and quality. Registrations for the next edition are already open on the Testμ Conference 2027 page.