You Built It With AI. Here’s How a Developer Takes It Over
A founder describes an app in a chat box, and a few days later there is a working prototype with sign-ins, a database and a live URL. Getting that far no longer requires a developer. The next stage brings real users, customer data, payments and a list of fixes the AI tool keeps getting almost right. That is the stage where a developer takes over.
AI app builders generate ordinary web code in widely used frameworks, so a developer can pick it up and keep going. This guide covers how that handoff works: getting the code into an account you control, what a developer checks first, how to prepare the project, and how to decide between fixing it and rebuilding part of it.
AI-built app handoff: key facts
| Question | Answer |
|---|---|
| What is vibe coding? | Building software by describing what you want to an AI tool in plain language. Collins Dictionary named “vibe coding” its Word of the Year for 2025. |
| Can a developer work on an app built with Lovable, Bolt, Replit or v0? | Yes. These tools generate standard web code. v0, for example, uses Next.js, React, TypeScript, Tailwind CSS and shadcn/ui. |
| How do you get the code out? | Connect the project to a Git repository (all four builders covered here sync with GitHub) or download it as a zip file. Some tools limit downloads to paid plans. |
| Who owns the code? | Lovable’s documentation says the apps and code you create are yours, and v0’s FAQ says Vercel claims no ownership of code produced from your prompts. Check your own tool’s terms. |
| What does a developer check first? | Who can read and write which data, exposed API keys, the packages the app depends on, sign-in and payment flows, and how errors are handled. |
| Is AI-generated code less secure? | Research has repeatedly found security flaws in AI-generated code. In one benchmark presented at ICML 2025, researchers successfully attacked roughly half of the working backend programs each model wrote. |
| Does an AI-built app need to be rewritten? | Not by default. A developer reviews it first. Working parts can stay while the riskiest parts, such as the data and access layer, are rebuilt. |
What is vibe coding?
Collins Dictionary, which named it Word of the Year for 2025, says vibe coding “refers to the use of artificial intelligence prompted by natural language to write computer code” and credits the term to Andrej Karpathy. Its shorter version: “telling a machine what you want rather than painstakingly coding it yourself.”
In practice, people vibe code with two kinds of tools:
- AI assistants like ChatGPT and Claude, where the code arrives in a chat to be copied into files, and coding agents like Claude Code, which read and edit a project’s files, run commands and work with Git.
- AI app builders like Lovable, Bolt, Replit and v0, which bundle the chat, a live preview and often the database and hosting into one web app.
Professional developers use these tools too. In the 2025 Stack Overflow Developer Survey, 84% of respondents said they already use AI tools when they develop software or plan to. The same survey found that “more developers actively distrust the accuracy of AI tools (46%) than trust it (33%),” and 72% of respondents said vibe coding was not part of their professional work. The most common complaint among developers, at 66%, was “AI solutions that are almost right, but not quite.”
AI app builders vs. no-code platforms: two ways to grow
AI app builders and no-code website platforms make a similar promise: start without a developer and bring one in later. They grow in different ways.
Platforms like WordPress and Shopify publish extension points, and a developer adds custom features as plugins or apps on top of the site you already have. The platform stays in place and keeps updating underneath. Website Platforms You Can Start Without Code and Extend Later covers that path in detail.
An AI app builder works differently. It is a workspace that writes code, and the code is the product. There is no plugin system for a developer to build on. The way forward is to take the code out, move it into a repository you own, and treat it like any other software project.
| No-code platform (WordPress, Shopify) | AI app builder (Lovable, Bolt, Replit, v0) | |
|---|---|---|
| What you start with | An editor, a theme and an add-on library | A chat that writes a full app |
| What a developer works on | Plugins, apps and extensions built on the platform’s extension points | The app’s own source code |
| How custom work survives updates | The platform keeps its extension points stable | The exported code changes only when someone changes it, though its dependencies still need updates |
| The developer’s way in | Install an extension on the existing site | Export the code to a Git repository and work from there |
| Where the app runs | On the platform or a host built for it | Anywhere that supports the framework the code uses |
Tool changes are a good reason to own the code. Lovable’s documentation notes that apps started on or after May 13, 2026 are built on TanStack Start, and earlier ones on React and Vite. When code sits in your own repository, changes to the builder’s defaults do not change your app.
How do you get your code out of an AI app builder?
Each of these builders offers a way out, and the details change often. This table reflects each tool’s documentation as of October 2, 2026.
| Tool | Sync to a Git repository | Download | Notes |
|---|---|---|---|
| Lovable | Two-way sync with GitHub, GitLab or Bitbucket | Zip download on paid plans | The database is exported separately from the code. Lovable documents migration to managed or self-hosted Supabase. |
| Bolt | GitHub integration that creates a private repository and syncs commits | Export > Download | Bolt’s instructions for running a download locally are to install Node.js and run npm install && npm run dev. |
| Replit | Connect a repository in the Git tool; auto-sync makes it two-way | Download as zip from the file tree menu | |
| v0 | Two-way GitHub sync with branches and pull requests | Export to work locally | v0 uses Next.js, React, TypeScript, Tailwind CSS and shadcn/ui. |
| ChatGPT, Claude (chat) | Through a coding agent that works with Git | Copy the code from the conversation | Save the code as files in a project folder and commit them to a repository. |
A few points apply whichever tool you used:
- Create the repository under an account you own. Your GitHub account or your company’s organization, not a freelancer’s account and not one you can only reach through the builder.
- Code and data are separate. The repository holds the code. The database, uploaded files, user accounts, environment variables and the domain each live in their own service and need their own export or handover. Lovable’s ownership guide is specific about this: “Moving the PostgreSQL database alone does not move authentication, storage, realtime, or Edge functions.”
- Two-way sync means two editors. Lovable’s docs explain that “commits pushed to the synced branch appear back in your Lovable project.” If you keep prompting in the builder while a developer works on the same branch, agree on who changes what, or use separate branches.
What does a developer check first in an AI-built app?
An AI-built app can work well in a demo and still have security problems, because a demo rarely tests who can see what. Published research points the same way:
- In Asleep at the Keyboard? (IEEE Symposium on Security and Privacy 2022), researchers had GitHub Copilot complete 89 security-relevant scenarios and found about 40% of the 1,689 resulting programs vulnerable.
- In a user study published at ACM CCS 2023, Do Users Write More Insecure Code with AI Assistants?, participants with an AI assistant “wrote significantly less secure code than those without access” and were also “more likely to believe they wrote secure code.”
- BaxBench, a benchmark of 392 backend tasks presented at ICML 2025, found that the best model tested, OpenAI o1, reached 62% on code correctness, and for each model the researchers successfully attacked roughly half of the programs that did work.
These studies tested models released between 2021 and early 2025, and newer models may score differently. AI-written code still needs the same review as any other code before it handles real users. A developer’s first pass maps closely to the OWASP Top 10:2025, the Open Worldwide Application Security Project’s ranking of the top security risks for web apps.
| What a developer checks | What tends to go wrong | OWASP Top 10:2025 category |
|---|---|---|
| Who can read and write which data | Database tables open to anyone who knows the app’s public URL and key | A01 Broken Access Control |
| API keys and secrets | Private keys shipped in the browser code or committed to the repository | A02 Security Misconfiguration |
| Packages the app depends on | Packages that don’t exist, are outdated or are unmaintained | A03 Software Supply Chain Failures |
| Sign-in, password reset and payments | Flows that work on the happy path but can be skipped or replayed | A07 Authentication Failures |
| Errors and logging | Failures that are silently swallowed, leak details to users, or leave no record | A09 Security Logging and Alerting Failures, A10 Mishandling of Exceptional Conditions |
Database access rules
Supabase, a database service that Lovable and Bolt both integrate with, lets the browser read and write the database directly with a publishable key. Supabase’s API key guide is plain about what that means: “Anyone can read it, so it only reaches what Row Level Security allows.” Row-level security is the database’s own set of access rules. The row-level security documentation says to “Enable RLS on every table in an exposed schema,” and explains that once it is enabled, “no data is accessible through the API when using a publishable key, until you create policies.”
This is a known problem area. The U.S. National Vulnerability Database lists CVE-2025-48757, which describes “an insufficient database Row-Level Security policy in Lovable through 2025-04-15” that let unauthenticated attackers read or write database tables of generated sites. Lovable disputes the entry, and the record notes its position: “each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application.” Either way, the data exposed would be the app owner’s and their customers’.
Exposed keys
Front-end code is public. Anyone can read it in a browser. Lovable’s Git sync documentation warns that “Variables prefixed with VITE_ are included in the code your app sends to the browser. Do not add a service role key or any other secret to them.” Supabase’s guidance is similar: “Never use a secret key in the browser or expose it to customers.”
If a secret has ever been committed to a repository, deleting it from the latest version is not enough. GitHub’s guide to removing sensitive data says “as a first step you need to revoke and/or rotate that secret.” A developer will replace any exposed keys first.
Dependencies
AI tools sometimes import packages that don’t exist. A study presented at USENIX Security 2025, We Have a Package for You!, generated 576,000 code samples with 16 models and found that, on average, commercial models invented at least 5.2% of the packages they referenced and open-source models 21.7%. An attacker can register one of those invented names and fill it with malicious code. Models also tend to write code for older versions of libraries, covered in AI Code Generation Has a Version Problem. A developer confirms that every package is real, current and needed.
Does it run outside the builder?
The last first-day check is practical: can the app be cloned from the repository, installed and run on a fresh machine using only what is written down? If it can’t, something important still lives only inside the builder, like an environment variable, a database setting or a manual step.
How to prepare an AI-built project for a developer
A little preparation saves paid hours. Before the first call, gather:
- Repository access. The code in a repository you own, with the developer invited as a collaborator.
- A list of services. Hosting, database, authentication, payments, email, file storage, analytics and the domain registrar, with a note of whose login controls each.
- Environment variable names. List the names, not the values. Share secrets through a password manager, never in email or chat.
- A short description. What the app does, who uses it, what works, what doesn’t, and what you’ve already asked the AI to fix.
- The state of the data. Whether real users or customer records exist yet, and whether there are backups.
- Your prompts. The chat history or project instructions you gave the tool. They show what you meant to build, which helps a developer spot where the code drifted from it.
Should you fix an AI-built app or start over?
Review first. Rebuilding everything throws away the parts that already work and repeats the time it took to get them working.
Signs the existing code is a good base:
- It uses a mainstream framework and builds cleanly from the repository.
- Most features work, and the problems are in specific areas.
- The data model, meaning the tables and how they relate, matches how the business works.
Signs part of it should be rebuilt:
- Access rules are missing or were added as an afterthought across many files.
- The same logic is copied in several places with small differences, so each fix breaks something else.
- The data model doesn’t fit the business, and every new feature needs a workaround.
- The app depends on a builder-specific service with no export path.
There is also a middle path: keep the interface and the parts that work, and rebuild the data and access layer underneath.
Can you keep using AI after a developer takes over?
Yes. In the Stack Overflow survey, 51% of professional developers said they use AI tools daily. What changes is the process around them: changes go through version control, someone reviews them, and tests catch regressions before users do. An owner can keep prompting in the builder for copy and layout changes while the developer handles data, security and integrations, as long as everyone agrees who changes what.
It also helps to separate AI as the tool that built the app from AI as a feature the app runs on. Two Ways to Build With AI: Runtime Dependency vs. Build Tool explains why the difference matters for cost and reliability. For a look at why AI completion still guesses at APIs, see Why Alpine.js Has No Real Autocomplete (AI Doesn’t Fix It).
When to hire a developer for an AI-built app
Common signs it’s time:
- Real users, personal data or payments are about to go live.
- Each fix from the AI tool breaks something else.
- You can’t tell what changed between versions, or why.
- You need an integration, report or workflow the builder can’t produce reliably.
Connor on the Web reviews, secures and maintains web apps, including ones started with AI tools. Day-to-day work happens in VS Code and Neovim, and we publish our own VS Code extensions and Neovim plugins. The process and pricing are published, and you can get in touch to talk through what you’ve built.
