Autofix: turn a client's edit into a dev-approved PR

Here's a ticket every web developer has closed a thousand times: "Can you change the phone number in the footer to 555-0192?" It's a fifteen-second edit. But it doesn't cost you fifteen seconds. It costs you the context switch, the "which site was this again," the finding the string, the deploy, and the "done!" reply. Do that across a portfolio of care-plan sites and the fifteen-second edits are what actually eat the month.

I've been doing this for twenty years. The single most expensive category of work I do is not hard — it's small, frequent, and badly specified. So when I built SiteUpdate's intake to kill the "badly specified" half, the obvious next question was: if the request is precise enough, why am I still the one typing the change?

The request that arrives with its fix already written

Autofix is that idea taken to its conclusion. When a client uses the widget to point at the footer and edit the phone number inline, we don't just file a clean ticket. We take that captured edit — the exact old text and the exact new text — locate where it lives in your GitHub repo (or the WordPress post), and hand you a Proposed Fix: a red/green diff, a confidence score, and one button.

Approve it, and on a git-backed site we open a pull request. On WordPress we apply it directly. Either way the loop closes itself: when the PR merges (or the WordPress change goes live), the request flips to live and the client gets told, without you touching it.

The reporter never sees any of this. They pointed at a phone number and typed a new one. That's the whole job, on their end.

The part that actually matters: it can't redesign your site

If you're a developer, your first reaction to "a tool that edits my site from a client's request" is a flat no. Mine was too. An automated change you don't trust is worse than no automation — one bad edit to a live site and you've lost the client's confidence and a weekend.

So the guardrails aren't a feature of Autofix. They are Autofix. Here's what a proposed fix can and can't be:

• Text only, and size-capped. A fix replaces a run of plain text with another run of plain text. It cannot introduce markup or a script — the replacement is rejected if it contains a tag, and WordPress strips tags a second time on the way in. No layout, no CSS, no JS.
• One exact match, or it doesn't run. Autofix only applies when the captured text appears on the page exactly once. If the same string shows up twice, it won't guess which one you meant — it stays a normal ticket for a human. So it can't quietly change the wrong thing.
• It stays in its lane. Autofix only edits files under the content paths you allow, and it will never touch package.json, a lockfile, .env, CI config, or wp-config.php — that deny list ships on by default and you can add to it.
• Protected pages are off-limits. Mark /checkout, /pricing, anything legal — Autofix will never propose a change there. The client can still file a request; it just always comes to a human.
• You can see it before it's live. On WordPress you get a preview link that renders the change on your real site without publishing it.
• One-click rollback. Changed your mind after it shipped? Git gets an inverse PR; WordPress restores the previous content. Instantly.
• It heals itself. After a WordPress change goes live, we re-check the page. If it broke — a 500, a PHP fatal, a page gone blank — Autofix rolls it back automatically and emails you "we caught it, nothing shipped." You find out about the problem and the fix in the same sentence.
• Every change is on the record. Proposed, approved, shipped, live, rolled back — the full history is on the request, and the owner is emailed the moment anything goes live.

And the one that underwrites all of it: Autofix never merges for you. On git, a human reviews and merges the PR — your CI runs, your review stands. Nothing reaches a visitor that a developer didn't approve.

Where it fits

This isn't for your next redesign. It's for the long tail — the phone numbers, the typos, the "change 'Monday–Friday' to 'Monday–Saturday'" — the requests that are too small to feel worth a deploy but too frequent to ignore. Autofix turns each one from a context switch into a diff you approve between two other things.

The suggestion is free to look at on every plan, because looking at it is how you decide whether it's any good. Only the ship step — the PR, the live change — is part of Pro. That's the deal I'd want as the developer paying for it: I don't pay to be shown a fix, I pay for the ones I choose to send.