The Client Said: Make It Yellow.

The message was short. A screenshot. “Can you make it look like this?”

Yellow. Green. Everywhere.

Normally this is a designer ticket. Wireframes, feedback round, revision, another feedback round. Three hours minimum if you’re lucky. We did it in 20 minutes with AI. Then lost the work. Did it again in 20 minutes. Then deployed it. And couldn’t see a single new color on staging.

Why Rebranding Is Mechanical Work

Replacing a color scheme sounds trivial. In practice it’s tedious: six to eight different pages — Landing, Success, Verify Email, User Correction, Expired, Coming Soon — each with their own components, Tailwind classes, and custom CSS variables. Gray backgrounds out. Yellow #ffd630 in. White card forms stay, but green #008235 for every button and accent.

This isn’t creative work. It’s search-and-replace with context — find every place the old neutral styling appears, understand why it’s there, and replace it consistently. Exactly the kind of task AI handles well.

The prompt was essentially the screenshot. “Apply this color scheme to all sub-pages. Yellow background, green buttons and accents, white card backgrounds for forms.” One pass. One review round for small details (footer, logo placement). Done.

What would have taken a designer three hours — brief, iteration, feedback, revision — was resolved in a single AI session. The output was clean, consistent, and covered every page the first time through.

The reason it works isn’t magic. It’s that Tailwind CSS and custom CSS variables make color changes systematic. The AI isn’t “designing” — it’s recognizing patterns and applying substitutions. The designer’s three hours include coordination, context-switching, and communication overhead that simply don’t exist when the agent has all the context already.

We Did It Twice

The first rebrand was clean. The AI went through all six pages, applied yellow backgrounds, green buttons, white form cards. Consistent. Done.

Then it disappeared.

Here’s what happened: a burst of requests had come in as messages — not tracked in tickets, just informal asks. “Can you update the footer?” “Can you also migrate the demo environment to staging?” Unstructured. Multiple things at once. Two parallel AI sessions were running.

One session had done the rebrand. A second session was working on something that looked completely unrelated: migrating from demo to staging — the same SCP-based server infrastructure this project runs on. Different task, different concern. Shouldn’t touch each other.

It did.

The migration session reached a point where it needed a clean state. It reset to the last pushed commit — which is exactly what a well-behaved session should do. The rebrand had never been pushed. It was only in the working directory.

Clean reset. Gone.

We went looking with git fsck --unreachable. Found 30+ orphaned commits. None of them were the rebrand. The work had never been committed, never stashed with intent — just local file changes sitting in a working directory. When that directory got cleaned, it left no trace.

So we did the rebrand again. 20 minutes, same as before.

The second time, we committed immediately.

“Why Don’t We See the New Colors?”

The commit was in. The CI build was green. The deployment step — the same SCP-based pipeline this project uses to push Docker images directly to the server — completed without errors.

Then: “Why are we still seeing the old colors on staging?”

A green build does not mean a correct deployment. It means the commands completed. The pipeline had no way to detect a visual regression — whether the right colors actually appeared on the deployed page. Something between “build green” and “visible in the browser” was silently broken, and nothing in the CI chain would ever have caught it.

The debugging started here — and took three iterations to resolve.

Iteration 1: SSH Heredocs fail silently.

The deployment used SSH heredocs to run multiple commands on the remote server in one connection. Works well in theory. The problem: when any command inside a heredoc writes to stderr, the entire heredoc can truncate mid-execution. No error. No warning. The pipeline step reports success. Commands after the break never run.

Fix: Split every SSH command into a separate ssh "remote-command" call. Verbose, but reliable.

Iteration 2: docker compose --force-recreate doesn’t re-resolve images.

The deployment pushed a new Docker image to the server via SCP + docker load. Then ran docker compose up --force-recreate to restart containers with the new image.

--force-recreate creates a new container — but from the same cached image digest it already knows about. Docker Compose caches the digest reference from the previous run. The newly-loaded image has the same tag name but a different digest. Compose doesn’t notice. It recreates the container from the old cached image.

Even docker compose stop && docker compose rm doesn’t fix this. It’s a Compose-level behavior when working with locally-loaded images (no registry involved).

Iteration 3: The only real fix.

Raw docker stop <container> + docker rm <container>, then docker compose up -d. Direct Docker CLI commands bypass Compose’s caching entirely. Docker has to resolve the tag fresh — and picks up the newly-loaded image.

Three iterations, but each one eliminated one layer of assumption. After the third, the colors appeared.

The Real Collaboration

The rebranding was fully autonomous. Screenshot in, colored pages out.

The deployment debugging started with a different kind of input: a screenshot of staging still showing the old colors, and a question. “Why don’t we see the new colors?” That was the trigger — not a log entry, not a failing test, not a monitoring alert. A person looked at the URL, noticed the result was wrong, and asked.

What happened next is where the collaboration gets interesting. The pipeline had no visual regression detection — nothing that checks whether the right pixels appear on a deployed page. A green build is a green build, no more. But the agent had browser access via MCP Chrome DevTools. Once the question was asked, the investigation could proceed autonomously: diagnose the SSH heredoc issue, identify the Docker Compose caching bug, apply each fix — and then open staging directly in the browser, inspect what was actually rendering, and verify whether the colors had changed. No need to hand back to a human to check the URL after each iteration. The loop closed inside the session.

The screenshot and the question provided the entry point. After that, browser tools turned a blind deploy pipeline into something observable.

This is the division that keeps showing up: the human provides the context the pipeline can’t capture — “this doesn’t look right.” The agent provides the investigation and iteration speed the human can’t match. Neither is complete without the other, but the boundary shifts further toward the agent when it has the right tools available.

What Transfers

If you’re using locally-loaded Docker images (SCP-based deploy, no registry), this will happen to you. --force-recreate will lie to you. The containers will restart and look healthy. The old image will still be running.

The fix is two raw Docker commands before your compose up. It’s not elegant. But it’s reliable.

The SSH heredoc issue is subtler. If you have multi-step remote deployments that occasionally fail silently, check whether any step writes to stderr. Separate SSH calls are more verbose but eliminate a whole class of silent failures.

And the rebranding: if you have a Tailwind-based project and a color scheme to change, this is a 20-minute task with AI, not a three-hour design cycle. Give the agent the screenshot, the target pages, and let it work. Review once, ship.

Then there’s the session isolation problem. If you’re running multiple AI sessions in parallel — and you will, because they’re fast — they need real isolation. The same branch is not isolation. One session’s clean reset is another session’s lost work, and it happens silently.

Two approaches work: Track requests in tickets, not messages. If it doesn’t have a ticket, it doesn’t get an AI session. Untracked requests create untracked risk — parallel sessions with no coordination and no record of what’s in-flight. Or use git worktrees. Each session gets its own working directory on its own branch. A reset in one session physically cannot touch another. You merge deliberately when the work is ready. (The deeper problem of how sessions share context and state is covered in autonomous workflow risk.)

The rebrand took 20 minutes twice because neither of these was in place. One message too many, one reset at the wrong moment, and a working directory full of untracked changes became an empty one. The AI didn’t care — it did the same 20 minutes again without complaint. We were the ones who had to explain why yesterday’s colors were still on staging.

The work that takes hours in a traditional workflow often doesn’t need to. The work that evaporates silently is the part to fix first.