What to let Corey run on its own

Most advice about AI assistants stops at “review its work”. That is true and useless, because it gives you no way to decide which work. This page gives you the decision.

There are two ways to run Corey, and you want both.

The two modes

The split is not by how hard the task is. It is by whether your judgement is the point.

The rule that decides it

Here is the one worth writing on the wall.

Not “where the task is simple”. Not “where you trust it”. Where something other than you can catch a mistake.

The reason is uncomfortable but worth sitting with. Assistants do not usually fail by producing obvious rubbish you would spot immediately. They fail by producing something plausible that passes every check you happen to have, because you did not have the check that mattered. If your only safety net is that you will notice, you have not automated the work. You have moved it.

What counts as a check

For most businesses this is smaller than it sounds. One command that runs everything, wired into whatever deploys your site:

• the thing builds without errors
• the tests pass
• the links resolve
• the formatting is consistent
• the dependencies you import are actually installed

If you have that, you can hand Corey the keys to that project and go to bed. If you do not, Corey should prepare the change and leave it for you.

The useful consequence is that this is a to-do list, not a verdict. “Corey cannot ship here safely” is not a permanent state. It is a gap, and closing it is usually an afternoon.

Never unattended: anything customers pay for

Draw one hard line that no amount of checking moves.

Your marketing site is recoverable. If Corey publishes a page with a wonky heading, you fix it in ten minutes and nobody churns. Your product is not recoverable in the same way. Neither is billing, nor the dashboard your customers log into.

So: Corey can prepare product changes, write them up, get them ready. You look before they go live. This is a commercial decision rather than a quality one, and it does not relax as the checks get better.

Keep your backlog true

This one catches people out, and it is the failure that costs most.

The moment Corey works from your issue tracker, every open ticket becomes an instruction. A ticket saying “the payment webhook still points at the old endpoint” will send Corey off to fix a thing that was fixed six weeks ago - because the ticket says so, and nobody closed it.

You skim past stale tickets without noticing. Corey cannot. Before you let it work a backlog unattended, get the backlog honest, and prefer telling it to check the code rather than trust the ticket.

Stay out of each other’s way

If Corey is working while you are also working, agree a signal so you never both grab the same job. The cheapest version needs nothing you do not already have: a label on the ticket.

• One label means “this one is mine, leave it”.
• Another means “Corey is on this right now”.
• No label, and Corey takes it.

That is the entire protocol. Resist anything more elaborate; you will not maintain it.

Where to start

1. Pick your least risky project. Usually a marketing site or a content repo.
2. Get one command that checks it end to end.
3. Let Corey run unattended on that project only.
4. Add the next project when it has the same checks.

Expanding one project at a time is slower than switching everything on, and it is the difference between automation you trust and automation you quietly stop relying on.