How CaptainCore got built
CaptainCore is a mature hosting control plane. This reads how an agent worked as a second operator on it, hardening its security tooling and then building a live per-site performance monitor.
CaptainCore had run the Anchor Hosting fleet for years before any AI session: a Go CLI and a WordPress control plane for backups, drift scans, and deploys. This reads the chapter where an agent came aboard to extend it, not the years that built it.
The route, plotted
Eight waypoints across two months on a platform that already existed. Hover any marker to read the direction that set it.
Giving the fleet new eyes
The biggest single feature was a live per-site performance monitor. It did not start with code. It started with a plan.
I have an idea for a new feature. Can you help plan it out? I'd like to be able to enable/disable stats per site.
From there the work was almost entirely visual. Every rough edge came back as a screenshot, and the dashboard was tuned in place.
Any other UI improvement recommendations? Maybe move the 5 stats onto the same row.
The final call was not a bug report. It was taste, stated plainly, and it was enough:
I'm still not sure about the UI. Can you look at this UI? It feels so much better.
What the agent worked on
Two months of an agent operating an existing platform. The openers are all maintenance and extension, never a rewrite.
Run the existing tool. Use `captaincore drift` to hunt suspicious plugins across the fleet.
Extend it. Add a new capability to the drift scanner it just ran.
Review the internals. Audit the theme and plugin hashing method the whole fleet relies on.
Sharpen security tooling. "Can you review my malware-hunt script? How can I improve it?"
Build the performance monitor. Plan, then build, a per-site live stats dashboard. Tuned by screenshot.
Archive the logs. "Kinsta only keeps the last few days of server logs." Build a longer-lived archive.
Keep operating. New eyes on the fleet, no code thrown away.
What to borrow
This is the pattern for working with an agent on something that already exists and matters.
The first instruction ran an existing command. The agent read a mature codebase and extended it, rather than building from zero.
"Can you help plan it out?" opened the largest feature. On a system in production, a plan is cheaper than a rollback.
"I'm still not sure about the UI" is vague but honest, and it drove real iteration. You react, the agent proposes.
Reviews of the hashing method and the malware-hunt script improved tools that already ran the fleet, not just shiny new ones.
If you built this again
Knowing that this was extension work on a live platform, here is how you would steer a similar one. Copy a prompt and adapt it.
Tells the agent it is joining an existing system and to read it first, and front-loads the dashboard spec the original built piece by piece.
A reference dashboard beats describing "out of hand."
Framed as production code the fleet already depends on, not a greenfield.
This recap is the output of an editor pass over the project's agent transcripts. A deterministic extract (command-center flow --editor) pulls the direction, the agent trace, and the embedded screenshots from the most representative session. A single model pass captions each image and writes the narrative.
Every quoted heading is verbatim, typos and all. Landmark captions were recovered from images embedded in the transcript, then summarized. The originals are never reproduced or shared.