How I Automated Myself Outof a Job (In a Good Way)

I've been trying to hand off one of my clients for months.

She runs a small nonprofit. I built her website, and I've maintained it since. She never found a replacement webmaster, and there is always another request: a line to delete, a price to change, a flyer to fix. So I stayed.

Here's what my job had actually become. She'd text me a request, usually with a screenshot. I'd paste it into my AI coding agent. The agent would make the change. I'd check its work, deploy it, and report back. Then she'd reply with one more tweak, and the whole loop started over.

The agent was doing the work. I was the router, and a slow one, because every request pulled me off whatever I was doing.

So I asked a slightly crazy question: what if I just stepped out of the loop?

Why "just give her an AI tool" doesn't work

A few months ago this would have been a real engineering project. Now most of the pieces exist. But you can't hand a non-technical owner an AI coding tool and point it at her live site. Three things stood in the way.

Credentials. The site runs on a handful of services: hosting, a database, email delivery, payments. She shouldn't be managing keys to any of them.

Context. The site has history. Which email template is load-bearing. Which setting looks harmless and would break checkout. That lived in my head and in my agents' memory, not in anything she could hand an AI.

Judgment. Knowing how production websites break is most of the job. An agent that edits the live site directly will eventually do something expensive.

Step one: write down everything I know

Before touching any AI, I wrote the knowledge down, as a folder of plain documents that lives in the site's own code repository:

• Guardrails: a never-do list. Never edit production directly. Never touch payments without me. Plus every site-specific trap I'd hit before.
• Services: what each service does, and which account owns it.
• A decision log: why things are the way they are, so the agent doesn't "fix" something that was deliberate.
• A persona: how to talk to a non-technical owner. Plain words, at most three questions before showing her something, and never go quiet.
• A rebuild guide, so the whole thing can be stood up again from the repo if the bot platform ever goes away.

The docs are the webmaster. The bot is replaceable.

Step two: pick a home for the agent

I used Grok Bot, xAI's agent product. Each bot gets its own persistent computer in the cloud, with a terminal, a browser and files, so it can clone the repo, run the tests and push branches like a developer would. And I can reach it from anywhere.

I'll call the webmaster Ivan here.

Step three: keep the client away from the machinery

She never touches Ivan directly. A non-technical owner poking at a coding agent can do real damage without meaning to. Instead, Ivan got his own email inbox, and she just emails it. Ivan checks it several times an hour during the day.

Every website change is designed to run through the same pipeline:

1. Acknowledge. Ivan restates what she asked for and gives a time estimate.
2. Build on a branch. Never on the live site.
3. Preview. The change deploys to a private preview link, and Ivan emails her that link.
4. Approve. Nothing goes live until someone approves that specific link, and the approval gets logged: who, which link, when.
5. Publish and confirm. The change merges, Ivan checks the live site, and tells her it's done.

So far exactly one live site change has gone through it, and I approved that one myself. Her first requests were all edits to a flyer image, which skip the preview step and come straight back as a new file.

Not every request gets the same freedom. I split the work into three lanes:

• Lane A: content. Words, images, dates. Ivan handles these on his own, with the preview-and-approve step.
• Lane B: small code changes. These need a regression test, the repo's own checks, and sign-off from a second bot whose only job is reviewing Ivan's work. It's set up to read the diff cold and approve before she ever sees a preview.
• Lane C: anything touching money or personal data. Payments, refunds, the database. Ivan never does these on his own. He files me a ticket instead.

Two safety nets sit underneath all of it: a scheduled health check that pings the site's key pages, and a rollback script I've dry-run. The rules also say that if Ivan fails to fix something three times, he restores the last working version and files me a ticket instead of trying a fourth. That one hasn't been tested yet.

That ticket queue, plus keeping Ivan himself running, is the part of the job I kept.

Step four: test it, then hand it over

I ran a fire drill first. I broke a preview branch on purpose to see what the pipeline would do. It turned up two real problems, which I fixed before she ever saw it. Then I ran a few of her real requests through it myself before letting Ivan email her directly.

Day one

On her first day she asked for seven changes to a flyer in under four hours, and Ivan acknowledged and delivered each one. She still texted me once, asking me to forward a request because she thought Ivan was waiting for my okay.

It was not flawless.

Early on, Ivan mistook a blurry sidewalk photo from my phone for something she'd sent, and politely asked her to resend it. Separately, on one of her requests I'd relayed to him, he reported that the new text "fit cleanly at matching size." When I zoomed in, it was noticeably smaller than the text around it, with a scrap of the old line still showing underneath. It never reached her, and I only caught it because I checked the pixels instead of trusting the summary. That's now a standing rule: when the agent says it's done, open the file.

At 5:41 the next morning she texted me that it was awesome, and thanked me for the recommendation.

What I learned building it

Write the instructions down, not into the chat. For the first few days I shaped Ivan's behavior by messaging him corrections. Then I realized that if I ever had to rebuild him, every one of those corrections would be gone. So I pulled them all into one versioned prompt file in the repo. The repo is the source of truth, and Ivan is told to pull the latest copy before every task.

The first version doesn't have to be the last. Once it worked, I pulled the setup into a reusable template and stood up a second webmaster for a different site. Its first real fix, a product category filter that showed nothing, shipped the same day.

The hard part isn't the AI. It's the context, the permissions and the guardrails. The model was the easy piece.

Where this leaves me

It'll probably save me ten-plus hours a month. More than that, it gets me out of the middle, which was the real cost. Every request used to break my focus twice: once to hand it off, and once to check the result and report back.

I automated myself out of the job I'd been trying to hand off. The edits, the relaying and the reporting back are Ivan's now. What's left for me is keeping Ivan running.

I'm equal parts excited and a little scared about that. This is the starting point.

What's one thing you're still the middleman for?