Solution · Add dark mode
Add dark mode across your app, delivered as a reviewed PR
Connect your GitHub repo and ask for dark mode. The agent indexes the code, makes the change in a sandbox, verifies it builds, and opens a pull request for you to review.
For developers · connect a repo → reviewed pull request
At a glance
Is this the right pattern for you?
The short version, before the detail — who this is written for, what you start from, and what exists at the end.
| This solution | |
|---|---|
| Written for | Developers with an existing codebase |
| You start from | A GitHub repository and a change you want made |
| You end up with | A scoped, verified pull request awaiting your review |
| The path runs | Connect → index → edit → verify → pull request |
| Built on | GitHub PR agent · Code intelligence · Sandbox verification |
| Plan needed | Pro — GitHub repositories and pull requests are a Pro capability |
No timings are quoted anywhere on this page, because how long a build takes depends entirely on what you asked for.
The challenge
Why this is usually hard
Worth understanding before the how — because the reason this is difficult is not the reason most people assume.
Dark mode looks like a styling task and behaves like a refactor. It is not one change in one file; it is a rule that has to hold everywhere at once. Theme tokens have to exist, every component that hard-codes a colour has to stop, borders and shadows tuned for a light ground have to be reconsidered, and a toggle has to persist a preference and apply it before the first paint so nobody sees a white flash.
The failure mode is specific and familiar. The screens you were thinking about get themed, and the ones you were not — an error state, a print stylesheet, a modal nobody opens often, a chart with colours set in JavaScript — stay stubbornly light. You find out weeks later from a screenshot in a support thread. The work is not hard, it is exhaustive, and exhaustive is exactly what manual search is worst at.
The second problem is the diff. A change that touches a hundred files is unreviewable in the way that matters: reviewers approve it because reading it properly is not realistic, which is the opposite of what a wide-reaching change deserves. So the useful version of this task is not just "make it dark" — it is "make it dark everywhere, prove the app still compiles, and hand me something I can actually review."
How it works
From a connected repo to a reviewed PR
Every stage in order, including the ones that happen without you asking.
- 1
Connect your repository
$ connect repoPoint the agent at your GitHub repository. Nothing is written to your branches — the connection exists so the code can be read and indexed, and so a pull request can be opened later. You can scope or revoke it whenever you want.
- 2
The codebase is indexed before anything is touched
The repository is indexed twice over: semantically, so the code responsible for a behaviour can be found even when you cannot name the file, and by symbol, so the agent knows what a definition is used by. For a theming change this is the difference between covering the screens you mentioned and covering the ones you forgot.
- 3
Describe the change in your own terms
$ add dark mode across the appAsk for dark mode across the app, with a toggle that remembers the choice. You do not have to enumerate the components, produce a list of files, or know where colour is currently set — locating that is the indexing step’s job, not yours.
- 4
Edits happen in an isolated sandbox clone
Theme tokens are introduced, hard-coded colours are replaced, and the toggle is added — all inside a sandbox clone of your repository. Your real repository is not being edited while this happens, so an in-progress or abandoned change cannot leave anything behind.
- 5
Typecheck, tests and build have to pass
verifyThe same gates you would run yourself run against the clone. If one fails, the agent keeps working in the sandbox rather than handing you something broken — the failing state is its problem to resolve, not a review comment for you to write.
- 6
A pull request arrives, scoped and explained
$ open prYou get a standard GitHub pull request with a summary of what changed and why, already green. It is scoped to the theming work rather than mixed with unrelated tidying, which is what makes a wide diff reviewable at all.
- 7
You merge, or you do not
Your repository changes at exactly one moment: when you merge. Until then it is a branch and a proposal. Nothing is pushed to your default branch, and nothing is merged on your behalf.
Why code-anything
What you get out of the box
Not a feature list — the specific things this pattern removes from your side of the work.
Coverage, not just the obvious screens
Semantic and symbol-aware indexing finds the components, theme files and stray colour values across the project — including the ones you would not have thought to list. Exhaustiveness is the whole difficulty of this task and it is the part being automated.
Verified before you ever see it
Typecheck, tests and build all run against the sandbox clone first. The pull request arrives already known to compile, so review is about whether the change is right rather than whether it works.
Reviewed, never auto-merged
The only thing that ever reaches your repository is a pull request. There are no direct writes to your branches and no automatic merges, so the final decision on a wide-reaching change stays where it belongs.
Your code stays isolated while it works
Every edit happens in an isolated sandbox clone. A change that goes wrong halfway through goes wrong in the sandbox, leaving nothing to clean up on your side.
A diff shaped for reading
The pull request is scoped to the theming change and comes with a written summary of what it did. A hundred-file diff you can follow is a different object from a hundred-file diff you have to trust.
You keep working meanwhile
The exhaustive part — the search, the sweep, the compile-fix loop — happens away from your machine. You come back to a proposal rather than spending an afternoon grepping for hex codes.
In practice
What it looks like
The shape of this flow is deliberately unexciting, and that is the point. Connect, describe, verify, propose — with the two steps that protect you (an isolated clone, and gates that have to pass) sitting between the request and anything reaching your repository.
Note what is absent. There is no push to your branch, no merge, and no moment where the agent decides the change is good enough. The last word is a pull request, which is the review mechanism your team already uses.
$ connect repo acme/web-app
$ add dark mode across the app, with a toggle that persists
✓ indexed the repository (semantic + symbol)
✓ added theme tokens, replaced hard-coded colors
✓ added a persisted theme toggle
✓ typecheck · tests · build all pass
→ opened a pull request "Add dark mode"What you get
- A dark theme applied consistently across the app, not just the screens you named
- Theme tokens in place of hard-coded colour values
- A toggle that remembers the user’s preference
- Typecheck, tests and build passing against the change in an isolated clone
- A pull request scoped to the theming work, with a written summary
- A repository that is unchanged until the moment you merge
What it involves
The honest shape of the path
Stage by stage: what the platform does, and what is genuinely still asked of you.
| Stage | What actually happens | What is asked of you |
|---|---|---|
| Connect | You authorise a GitHub repository. Nothing is written to your branches. | One authorisation, scoped and revocable. |
| Index | The repository is indexed semantically, so behaviour can be found without a file name, and by symbol, so the agent knows what a definition is used by. | Nothing. This runs on connection, before any change is proposed. |
| Edit | The change is made inside an isolated sandbox clone of your repository. | A description of the change in your own terms — not a list of files. |
| Verify | Typecheck, tests and build run against the clone. If a gate fails, the agent keeps working rather than handing you broken code. | Nothing, though the value of this step is bounded by how real your own checks are. |
| Pull request | A scoped pull request is opened with a summary of what changed. | A review, and the merge — which is the only moment your repository changes. |
The stage names above are the product’s own: connect, index, edit, verify, pull request. How long a pass takes depends on the repository and the change, so no figure is quoted here.
Connecting a GitHub repository and opening pull requests is a Pro-plan capability, so this path needs Pro. Sandbox verification — typecheck, tests and build running before you see a change — is included on every plan. See the full plan comparison.
What you own
What you are left holding
On a codebase that already exists and already matters, the interesting question is not how fast a change can be produced but what is true about it by the time you are asked to look at it. Here is exactly what the arrangement guarantees, and what it deliberately leaves to you.
What is true before you see it
- Every edit happened in an isolated sandbox clone, never in your repository
- Your own typecheck, tests and build were run against the change and passed
- The work is scoped to what you asked for rather than mixed with unrelated tidying
- The pull request carries a written summary of what changed and why
What stays your decision
- Whether to merge — a pull request is a proposal, and your repository is unchanged until you accept it
- The agent never pushes to your branches and nothing is merged on your behalf
- You can leave a pull request unmerged at no cost beyond the time spent reading it
- The GitHub connection is yours to scope or revoke whenever you want
FAQ
Common questions
Keep looking
Other reference patterns
Every solution is a worked end-to-end example. If this one is not quite your situation, one of these probably is.
Fix failing tests
Connect your repo and point at the broken test. The agent reproduces the failure, finds the cause, fixes it, re-runs the suite green, and opens a pull request.
For developersJS to TypeScript
Connect your repo and name the components to convert. The agent adds real types, fixes the fallout, verifies the build, and opens a pull request you can review.
For developersOr the other way of working — describe an app in plain English and get a live, hosted result:
Bakery website
Describe your shop in plain English and watch a real website build itself in a live preview — complete with a contact form that emails you every enquiry.
For anyoneBooking app
Describe the booking flow you want and get a working app — a calendar customers book into and an email confirmation sent on every appointment, all wired up for you.
For anyoneStripe dashboard
Describe the numbers your team cares about and get a private dashboard — revenue, growth and customers — with sign-in, built without touching a line of code.
For anyoneBuild add dark mode the way it should have been.
Connect a repository and describe the change. Every edit happens in an isolated clone, clears your own typecheck, tests and build, and arrives as a pull request you review.