How do I move from a vibe coding platform to a normal GitHub workflow?
September 7, 2026
Getting your code out of a vibe coding AI builder/platform like Lovable, Replit, or Emergent is usually the easy part.
The harder question is what you actually get back. Does the project build outside the platform? Did the platform add its own dependencies? Are any integrations still running through the platform? And can another engineer pick up the repository without first cleaning up a bunch of platform-specific work?
Those are the things that determine whether moving takes a few hours or turns into a real migration project.
Why move at all?
Most teams do not move because exporting the code is difficult. They move because their product has become important enough that they want a normal engineering workflow around it.
That usually means being able to review changes before they ship, run the application outside the builder, use the infrastructure and integrations they choose, and let engineers work directly in the repository without depending on the platform that originally generated the app.
You may not need to move while you are still experimenting. But once the application has real users, meaningful revenue, or multiple people working on it, those constraints start to matter.
What you want from the repository
A normal software repository on GitHub should be pretty boring.
It should build on a clean machine. Dependencies should come from places your team can access. Changes should have a sensible history. And closing your account with the platform that helped create the product should not cause parts of the application to stop working.
Vibe coding tools are generally optimizing for something else: getting an application running quickly. That can be a perfectly reasonable tradeoff, but some of the compromises do not become obvious until you try to move away.
There is also a separate issue around services that may never have lived in your repository in the first place, including your database, authentication, payments, and other managed infrastructure. We cover that separately in which parts of my AI-built app do I actually own.
What we actually got back
We tested Emergent, Replit, and Lovable using the same test rounds and looked at how each one handed work back to us.
These tests were run on our own accounts between July and August 2026.
| What we looked at | Lovable | Replit | Emergent |
|---|---|---|---|
| Where it syncs | LovableCreates a new repository. Its settings say importing an existing repository is not supported | ReplitExisting repository | EmergentExisting repository |
| Pull request or branch | LovableOn our project with no repository connected, it created a PULL_REQUEST.md file rather than an actual PR |
ReplitOpened a real PR in one round after another credential grant. In a later round it opened none | EmergentPushes a branch and leaves the PR to you |
| Branch choice | LovableNot applicable | ReplitNot applicable | EmergentOffers your primary branch or a new branch you name. It did not offer the branch its agent had just created |
| What showed up in the repo | LovableCommitted .pyc files |
ReplitAdded two replit-agent commits totaling 71 lines to the primary branch when importing a clean repository | EmergentAdded an .emergent directory and an unrequested memory/PRD.md |
| Cost | LovableIncluded | ReplitIncluded | EmergentGitHub integration requires the $20 tier |
None of the three gave us a completely clean repository in our third round. Some of those issues are minor. Cleaning up generated files or unwanted commits is annoying, but not especially difficult. The bigger problems are platform dependencies that are easy to miss.
Check whether the code still depends on the platform
In our Replit test, it added @replit/connectors-sdk as a production dependency, upgraded Vitest from ^1.6 to ^4.1, and rewrote package-lock.json with URLs pointing to package-firewall.replit.local.
That last one matters. The project may install perfectly inside Replit and then fail as soon as your CI system runs npm ci somewhere else.
Lovable created a different kind of dependency in one of our tests.
We asked it to build a single deployable service using HubSpot and Retell. The Retell integration called Retell directly. The HubSpot integration went through connector-gateway.lovable.dev and used a LOVABLE_API_KEY in addition to the HubSpot credentials.
So if that Lovable account goes away, the HubSpot side of the integration has to be changed.
Emergent was simpler here. It made direct API calls and did not route them through its own service. It also provides fewer application services, so there is less platform infrastructure for the generated application to depend on.
One thing worth giving Replit credit for: its review agent caught several problems in its own implementation, including a missing release method, a contract break, and an event-ordering race. It fixed them without us asking.
So this is not simply a question of whether the generated code is good or bad. Replit did some useful review work and still handed us a lockfile that depended on Replit infrastructure.
Before you move, check how dependent your app is on the platform
There are four things worth checking:
- Does the app build outside the platform? Try running it somewhere else from a clean install.
- Does the code depend on platform-specific services? Look for integrations, SDKs, or infrastructure provided by the builder.
- Is your GitHub history clean? Make sure automated changes have not been pushed directly into your main branch in ways you will need to untangle.
- Will your integrations still work if you cancel? Some services may be routed through the platform rather than connecting directly to the underlying provider.
Those four answers will tell you whether moving is a simple cleanup or a more involved migration.
How Forged handles this
Forged works differently because it starts with the repository you already use.
It is built for teams that expect to keep making changes to the same product, so the GitHub repository is not an export destination at the end of the process. It is where the work happens.
| The Forged approach | |
|---|---|
| Where work begins | The repository you connect, including its existing history |
| How a change arrives | As a pull request you review before it reaches users |
| Existing integrations | Preserved and called directly by your application |
| Customer-owned integrations | Direct application-to-provider connection by default |
| Managed Forged services | Used when you choose them, such as Forged email or hosting |
Just having a GitHub integration is not the difference. Lovable, Replit, and Emergent all have ways to connect to GitHub. The difference is whether GitHub is the working home of the product or somewhere the platform sends the work afterward.
With Forged, a build ends in a pull request in the repository you started with. That pull request includes the acceptance criteria for the work and the evidence produced while testing it.
For integrations you own, Forged also avoids putting itself in the middle by default. If your application connects to HubSpot, Stripe, Retell, or another service, the application connects directly to that provider.
Forged-managed services, such as Forged hosting or email, are different. Those are services you explicitly choose to use.
Your questions, answered
Can I move my code out of Lovable, Replit, or Emergent?
Yes.
All three also preserved an existing Python and Flask codebase when we gave them one.
The question is less about whether you can get the files and more about what cleanup is required afterward. Check for direct agent commits, private package registries, platform SDKs, and integrations that run through the platform.
Will my build still work after I move?
Do not assume it will. Test it.
In our Replit test, package-lock.json contained package-firewall.replit.local URLs. A clean install outside Replit failed because those packages were no longer being resolved in the same environment.
A fresh clone and build on an untouched machine is the fastest way to find this kind of issue.
Can Lovable sync to my existing repository?
Not in the workflow we tested.
Lovable created a new repository, and its settings stated that importing an existing repository was not supported.
If you already have a repository, that means you may need to reconcile the Lovable repository with your existing one.
Does Emergent open the pull request?
Not in our test.
Its Save to GitHub flow pushed a branch and left the pull request for us to create.
The branch selector offered the primary branch, which was preselected, or a new branch we could name. It did not offer the branch its own agent had just created.
How long does moving take?
It depends almost entirely on what the checks above turn up.
Removing generated files or cleaning up unwanted commits may take a few hours.
Fixing a lockfile that depends on a private registry can take longer.
If an integration is running through the platform’s own gateway, you have to replace that integration with a direct connection to the underlying service. That has to be scoped one integration at a time.
See what this looks like in a repository you already own
Connect Forged to the repository you use today.
The first change comes back as a pull request in the same repository and history your team already works in, rather than creating another handoff to clean up later.
Last reviewed: September 7, 2026.