AI App Builders That Fit a Dev Team's GitHub Workflow

AI App Builders That Fit a Dev Team's GitHub Workflow

What AI app builders integrate with a dev team's existing GitHub workflow? If you run a development agency or consult independently — building applications for clients rather than for yourself, with several projects live at once — this is the only question about AI app builders that matters. Not how good the generated code is. Whether the code can live in a repository you control, move through the review process you already run, and be handed to a client without a subscription attached to it.

The honest answer in September 2026 is that the category has split. A few tools behave like a git client — they branch, they open pull requests, they treat your repository as the source of truth. Others hold the code and offer you an exit ramp. Both can be fine. What is not fine is finding out which one you bought after the client asks for the repo.

Here is what to check, what the vendors' own documentation says today, and where Buildra — our own tool — fits and does not.

Ten questions to ask before an AI builder touches a client repo

1. Where does the code live while the AI works — my repository, or theirs? This decides everything downstream.

2. Which branch does it write to? Some builders commit straight to main. On a client project that is a policy violation before it is a technical one.

3. Does it open pull requests, or commit directly? If there is no PR, there is no review gate, and your senior dev reviews nothing.

4. Is the sync one-way or two-way? If your developer pushes a fix from their laptop, does the builder see it, or silently overwrite it?

5. What credential does it hold, and for how long? A stored GitHub App installation with write access is a standing grant. A token used once for a single push is not the same risk.

6. Which App permissions does it request? Contents: write is expected. Administration: write means it can create repositories. Workflows: write means it can edit your GitHub Actions files. Read the consent screen, not the marketing page.

7. Can I get the code out without the integration? A plain download is the fallback when the integration breaks, the plan lapses, or the client will not connect their org.

8. Will the exported code build outside their platform? Code you cannot run without the vendor's environment is a hostage, not a handover. Ask what the download actually contains.

9. What happens at handover? Can the connection be disconnected, transferred to the client's org, and reconnected — or is it one-shot?

10. What breaks if the subscription stops? Does the application still build and run somewhere else, or does it only exist on their host?

Questions 8, 9 and 10 are the ones agencies skip and later regret: more than one tool documents that disconnecting a repository is permanent.

How the builders answer

Each of these is checked against the vendor's own documentation in September 2026, because these capabilities change often and a stale claim is worse than none. Anything I could not verify is not here — ask the vendor using the list above.

v0 (Vercel)

v0 has the closest thing to a real review workflow of the hosted builders. Its documentation says you can start from code already on GitHub, that once a repository is connected "it becomes the source of truth for your project's code", and that v0 creates a working branch and "pushes generated changes here instead of pushing directly to the base branch". Publishing "creates a pull request if the branch does not have one, or reuses its existing pull request".

If branch-per-change plus PR review is a hard requirement, this is currently the most direct fit, and it is worth saying so plainly. The same docs warn that deleting the connected repository may make the code unrecoverable — the flip side of the repository being the source of truth.

Lovable

Lovable's docs describe two-way sync with github.com, GitHub Enterprise Cloud and GitHub Enterprise Server, including branch operations and pull request creation. It creates a new private repository under the account or organization you choose, syncs the default branch by default, and "only edits and syncs one branch at a time".

The detail worth reading before you connect a client org is the permission set its GitHub App requests: Contents (write), Metadata (read), Pull requests (write), Workflows (write) and Administration (write). Workflows write and Administration write are broader than most agencies assume when they click Authorize on a client's behalf.

Bolt.new

Bolt's help docs describe pushing to a new or existing repository, with new repositories starting private on main. It commits automatically — "Every time you make a change that doesn't break the project, Bolt creates a commit for you" — polls GitHub "every 30 seconds for any updates made outside Bolt", and supports creating and switching branches in the app. The documented limit that matters for review: "Bolt currently doesn't support merging branches in-app. You need to merge branches in GitHub." Disconnecting a project "permanently removes its connection to the GitHub repository".

Base44

Base44 documents two-way sync with a set of constraints worth quoting rather than paraphrasing: it requires the Builder plan or higher; the branch "must be named main. Other default branch names, such as master, currently aren't supported"; only app owners can make the initial connection; there is "no option to manually push updates"; and "after disconnecting, you cannot reconnect to the same repository". Read that last one twice before using it on a client project.

Replit

Replit's Git pane is the most ordinary-feeling of the hosted options: initialise, connect and manage repositories, commit, push, pull, create and switch branches, resolve conflicts, and run git commands in the shell with the pane staying in step. Pull request management is not described on that page. If the mental model you want is "it's just git, in a browser", this is the closest.

Cursor and the local-agent category

Cursor is not a hosted app builder and should not be evaluated as one. It works on the checkout already on your disk, so branches, review, CI and handover are whatever they already are — the integration question never arises. The trade-off is the mirror image: no hosted preview URL to send a client on Thursday afternoon, and no deploy. Plenty of agencies run both.

How Buildra answers, including what it does not do

Buildra gives each project its own git repository on Buildra's internal Forgejo, named p-<projectId>, and the agent commits into it. Three doors connect that to your GitHub.

Importing in. Paste a GitHub URL into the composer, or pick a repository from the import menu. The copy is performed by Forgejo's repository migration API, which means the credential exists only in that one request and the outbound call — it is never stored or logged. Public repositories import without connecting anything; private ones need the Buildra GitHub App, which asks only to read the repositories you pick. In the product's own words: it "can't push, open pull requests or change settings", and "Buildra copies the repository into a private project. Your GitHub repository stays as it is."

The import then works out what it copied. If the repository carries a .dsh-template.json manifest, Buildra requires that exact id and version to be a pinned template and answers template-unknown rather than guessing. Without a manifest it reads a fixed list of root files — package.json, the four lockfiles, wrangler.jsonc, wrangler.toml, Dockerfile — infers the package-manager commands, preview port, hosting, database and auth, and writes that inferred manifest back into the Buildra copy, so the guess is visible and editable rather than hidden. A repository with no usable package.json, with unreadable package JSON, or combining Workers hosting with Postgres is refused with a named reason, and the copied repository is deleted so no half-project is left behind.

Mirroring out. In Project Settings there is a section called Mirror to GitHub. You give it a repository URL and a GitHub token, and from then on every commit the agent makes is pushed to a repository you own. Underneath, Buildra hands the token to Forgejo's push-mirror API and triggers the first sync immediately; the service does not persist or log that token, which is the answer to question 5 on the list above.

The mirror is one direction. Commits made in Buildra go out to your repository. A commit your developer pushes to GitHub does not flow back into the Buildra project. Treat the mirrored repository as a faithful copy you can review, diff, tag and hand over — not as a shared working branch.

Downloading. Independently of any integration, Project Settings has a Source and export section: a .tar.gz of the current commit, your code without the dependencies, also reachable from the projects list. This is the fallback that needs no client GitHub org at all, and it is why the delete dialog tells you to download the source first.

Now the part our own marketing page mostly does not say. Buildra does not create a branch per change, does not open pull requests for you to review, has no CI integration and no two-way sync. If your process is "the agent proposes, a human approves the PR, CI gates the merge", Buildra does not give you that today — v0's documented working-branch-and-PR flow fits that requirement better, and pretending otherwise would waste your evaluation week.

When Buildra is the wrong choice

• When review must happen before the commit exists. Buildra's mirror pushes commits that have already been made. If your client's repository requires every change to arrive as a PR from a protected branch, the mirror is the wrong shape.

• When a developer needs to push back into the session. One-way mirroring means hand-edits on GitHub do not return. Work in one place or the other, not both.

• When the client's repository must be the single source of truth from day one. Buildra's working copy is authoritative inside Buildra; the mirror is downstream of it.

• When a local agent workflow is already working. If Cursor and your own CI are fine, a hosted builder adds a boundary to manage rather than removing one.

The short answer

Ask the ten questions, take the answers from the vendor's documentation rather than a sales call, and note the date you checked. For a client project, three of them decide it: which branch does it write to, can I leave with the code, and what happens at handover.

Buildra imports from GitHub, mirrors every agent commit out to a repository you own, and lets you download the source as a tarball at any time, with credentials that are used and discarded rather than stored. What it does not yet do is branch, open pull requests or run your CI. If you need those inside the builder, say so in your evaluation and weigh v0 seriously. If what you need is that the client ends up owning the code, in their own repository, without a subscription attached — that part works today.