Describe a change in plain language. AI writes the code and opens a pull request. Your team reviews the diff and decides whether to merge, using the same workflow they already have.
An AI-generated pull request is a code change written by AI and delivered as a pull request on GitHub, GitLab, or similar platforms. Same format developers already use to propose changes.
Here's what happens:
Someone describes a change in text, a visual annotation, or an issue tracker ticket. The input is intent, not code.
AI reads the relevant codebase. The actual files, dependencies, patterns, and conventions. It understands how your project is structured before generating anything.
AI generates code changes: new lines, modified lines, deleted lines across one or more files. These are concrete edits, not suggestions or pseudocode.
Changes are committed to a branch and submitted as a pull request. The PR includes a diff showing exactly what changed, file by file, line by line.
Human reviewers evaluate the changes and decide whether to merge. Nothing reaches production without explicit approval from someone with repository access.
The output is identical to what a human developer would create: a branch, a commit, a diff, a PR description. The only difference is who (or what) wrote the code.
Generating a pull request from a plain-language request involves several stages. Each one feeds into the next.
The change request includes a description of what should change, the target page or component, and optionally visual annotations showing which elements are affected. It could be as simple as "change the CTA button text to 'Start Free Trial'" or as detailed as a marked-up screenshot with multiple annotated regions and an explanation of what each one should become.
AI indexes the repository: file structure, dependencies, framework conventions, design tokens, component hierarchy. If the project uses Vue with Tailwind, it knows that. If there's a shared component library, it finds it. If there's a CLAUDE.md or similar conventions file, it reads that too. Without this step, the AI would generate code that technically works but doesn't match how the project is actually built.
AI identifies which files need to change. A CTA text update might touch a Vue component, a translations file if the project uses i18n, and a test file. A color change might affect a CSS file, a Tailwind config, or design tokens. The AI traces dependencies and conventions to find all files that should be updated, not just the obvious one.
AI generates the specific code changes. It follows existing patterns: if the codebase uses Tailwind utility classes, it uses Tailwind rather than inline styles. If there's a design system with defined color tokens, it references those tokens. If the project uses TypeScript, it generates TypeScript. The output matches the project's conventions because the AI already read them in the analysis phase.
Changes are expressed as a diff: additions in green, deletions in red, with unchanged context lines surrounding them. Every developer reads this format, and every code review tool renders it. A reviewer sees exactly which lines changed without reading entire files.
A new Git branch is created from the main branch. Changes are committed with a descriptive commit message. A pull request is opened against the target branch. The PR description explains what was changed and why, referencing the original change request for context.
Once the PR is created, the repository's automated pipelines take over. Tests run, linters check code style, build processes verify that the application compiles, accessibility scanners flag problems. If something breaks, it gets caught here, before any human reviewer even opens the PR. Same pipeline, same rules as human-written code.
AI could modify files directly. It could push changes straight to production. Pull requests exist to prevent exactly that kind of recklessness, regardless of whether the author is human or not.
A diff shows exactly what changed. The actual lines of code, with surrounding context. Reviewers evaluate changes at the code level and spot issues that no summary could convey. They see what was there before and what will be there after, side by side.
Nothing reaches production without human approval. The PR must be reviewed and merged by someone with repository access. A junior developer's code goes through this. A senior engineer's code goes through this. AI-generated code goes through it too. The merge button is always pressed by a person.
Every PR is a discrete change with a clear boundary. If something goes wrong after merging, revert the PR and the site returns to its previous state. Try doing that with manual CMS edits, where reverting one change often means losing other changes made around the same time.
Git history records who requested the change, when it was submitted, who reviewed it, what feedback was given, and when it was merged. Six months from now, someone can look at the commit history and understand exactly what changed and why. That matters for compliance. It also matters when something breaks at 2 AM and you need to figure out what happened.
Pull requests trigger automated checks: tests, linting, build verification, accessibility scans, whatever else the team has configured. A failing test suite blocks the merge automatically, before anyone has to spend time reviewing code that doesn't even compile.
PRs support comments, inline suggestions, and requested changes. A reviewer can approve the overall direction but ask for a wording tweak on line 42. Feedback is given, changes are made, the PR is re-reviewed. This back-and-forth works the same way whether the original code came from a person or an AI.
Pull requests are the industry standard for a reason. AI-generated PRs get all of these properties for free because they use the same format and the same workflow.
Different roles get different things out of AI-generated PRs. Here's what that looks like in practice.
Marketers, product managers, founders, and content teams can make website changes without waiting on engineering:
Engineering teams keep full control and stop spending time on text swaps:
Quality standards stay the same, but engineers stop getting pulled into low-value work:
A few tools can generate PRs today. They differ mainly in who they're built for and how the user describes the change.
Generates pull requests from GitHub Issues. You describe a task in an issue, and Copilot plans and implements changes across the repository. You need to know how to write a good issue and evaluate the generated code. It's a developer productivity tool, not something you'd hand to a marketer.
Automated PR generation from GitHub Issues. You tag an issue and Sweep generates a PR for routine tasks like bug fixes, small features, and docs updates. Like Copilot Workspace, it assumes the user can write a clear technical issue and review the resulting code.
Generates PRs from visual annotations on live websites. You point at elements on your actual site, describe a change in plain language, preview the result on the live page, and AI creates a pull request against your repository. The input is visual, not textual. You don't write an issue; you point at your website and say what should be different. Built for non-developers making website changes.
The real difference is who the tool is for. Developer tools start from written issues and assume the user reads code. Intentify starts from a visual interface on the actual website and assumes they don't. Either way, the output is a pull request with a clean diff that goes through standard code review.
Yes, because they go through the same review process as human-written code. A developer reviews the diff, CI/CD runs automated checks, and nothing merges without approval. The PR format is specifically designed for safe, reviewable code changes.
For content, styling, and layout changes, AI-generated code is highly accurate. It reads your existing codebase and follows your patterns. For complex logic changes, accuracy depends on the specificity of the request and the complexity of the code. All changes are reviewed before merging.
The same safeguards that protect against human errors protect against AI errors: code review, automated tests, CI/CD pipelines, and staging environments. A broken change is caught before it reaches production.
Close it. Like any pull request, you can reject it, request changes, or close it entirely. The original codebase is unchanged until a PR is explicitly merged.
Create a free account and submit your first change request in under five minutes.
Get Started FreeFree to start. No credit card required.
