There is a version of this story that should worry you. One engineer, no second reviewer, no QA team, no release manager, pushing software that moves real money for a Northeast Florida commercial contractor several times a week. For most of software history that is the opening line of an incident report.
It is not, and the reason is narrow enough to state plainly: I do not follow the lifecycle, the tooling does. The discipline is not in my head where it can be tired or rushed or talked out of a step. It is wired into commands I cannot skip.
Why it has to be this way is the part worth your attention. The portal exists to replace per-seat ERP licenses with software the contractor owns. So far that is $150,000 a year off their bill, and it grows every time they add a project manager who would have been another seat. A number like that, riding on software one person maintains, is only sane if the process carries the weight a team normally would. Imagination is the bottleneck, not AI: I can picture the app worth building and an agent can write most of it in an afternoon. What stops that from becoming a liability is the loop around the writing.
The loop is three commands. Write the spec, cut the branch, ship. /prd turns a change into a requirements doc scoped to a single pull request, and if the scope will not fit one PR it gets cut until it does. /sprint cuts a fresh branch, plans, and stops dead until I approve the plan before any code exists. /ship takes a clean tree to a merged PR: an independent gate, changelog, one commit, push, open the PR. Around those sit eighteen skills and three review subagents, and a /retro command that reads the results back out.
Two constraints do most of the real work.
One commit per sprint. It sounds fussy until you see what it protects: a history where every commit is one coherent unit of intent.
The diff budget is the other. A normal change is capped at eight files and three hundred changed lines. Go over and /ship stops and makes me either split the work or write a one-sentence reason that gets logged. This is the guardrail I would keep if I could keep only one, because the failure mode of an AI agent is not bad code. It is a confident flood of plausible code, more than anyone can actually read, delivered in a single pass. A budget forces the work into slices a human can still hold in their head, and that is the only kind a solo maintainer can keep honest.
The piece I am quietly proudest of does nothing a user will ever see. Every /ship appends one line of JSON to a local log: the risk tier, how long the gate took, whether tests passed, any override and why. After a couple of months that is a dataset. I can see which changes are slow, how often I override the budget, whether the gate is catching things or just adding latency. A process you only believe in is a process you are running on faith, and faith is the first thing that fails when the team is one person.
None of this makes me fast. The agent makes me fast. The loop is what keeps fast from turning into reckless, and on a system that has taken six figures a year off a real company's cost base, that distinction is the whole job.
I build the custom software that puts AI to work inside a business, embedded on the team, shipping into the client's own cloud. The harness above is how one engineer does that at the quality a production system demands instead of the quality a demo gets away with. If you are carrying per-seat software you suspect you could own instead of rent, that conversation starts at /contact.