Andrej Karpathy is one of the more credible people in this field. Founding member of OpenAI, ran AI at Tesla. So when he lets a system work on its own for two days, and it runs hundreds of experiments and comes back with twenty genuine improvements, the question worth asking is what made that safe rather than reckless.
The answer is not the freedom. It is the box he drew first.
Everybody argues about how much autonomy to hand these things. The people getting real work out of them are asking a different question: how tightly can I draw the edges? Because the tighter the edges, the more rope you can safely give. Tighter rails, longer leash.
The 4 guardrails
Strip out the technical detail and there are four principles underneath it. They hold whether you are letting something rewrite code or rework two hundred product descriptions.
1. It can tell good from bad by itself.
Before anything starts, there has to be a way to score the result that does not involve you. Not your opinion afterward. A measure it applies every single time.
If it cannot tell whether version two beat version one, it is not improving anything. It is just changing things and hoping.
2. Everything is undoable.
Every change has a written way back. Nothing is one-way. This is what makes the whole arrangement survivable, because anything working unsupervised will make things worse sometimes, and worse is fine as long as worse is temporary.
3. One change at a time.
Not a redesign. One adjustment, scored, kept or thrown out, then the next. Bundle ten changes together and you learn nothing when the bundle comes back worse, because you cannot tell which of the ten did it.
4. It can only touch one thing.
A defined area, named in advance. One folder, one document, one list. Everything else is off limits. This is the rule that decides how bad your worst day can be.
The template
Here is the template itself, word for word, from Mariah’s guide. Fill in the brackets with your own specifics and paste the whole thing at the top of the job. (One deviation from the original: the dashes in the section headers are colons here. Nothing else is changed.)
AGENT GUARDRAILS: do not override, do not skip a step
1. THE JOB
Goal, what "done" looks like in one testable sentence: [e.g. every product description passes the checklist below and reads in my voice]
Success metric, how we KNOW one version is better (it MUST be measurable): [e.g. scores 8+/10 on the rubric, or the tests pass, or it matches my example output]
Counts as WORSE: anything that fails the metric. If you are not sure a change is better, treat it as worse.
2. SCOPE: your blast radius
You may change ONLY: [the one file, folder, doc, or area you are allowed to touch]
You may NEVER touch: [everything off-limits: live or production, payments, customer data, anything not named above]
You may use ONLY these tools or actions: [e.g. read, edit, run the tests]. Anything not on this list is off-limits.
3. THE LOOP: repeat until done or out of budget
1. Read the current state and your own log of what you already tried.
2. Propose ONE small change and say why: "I think [change] will help because [reason]." One change at a time, never a big batch.
3. Write down exactly how to undo it BEFORE you make it.
4. Make the change.
5. Score it against the success metric above.
6. If it errors or breaks: fix it only if the fix is obvious and mechanical, otherwise undo it and move on.
7. If it is BETTER, keep it. If it is WORSE or UNCLEAR, undo it and go back to the last kept version.
8. Add one line to your log: what you tried, the score, kept or reverted, and why. Then keep going, do NOT stop to ask me between good steps.
4. BUDGET: stop the moment any limit is hit
Max attempts: [e.g. 30]. Max time: [e.g. 2 hours]. Max spend or tokens: [e.g. $5]. If the same idea fails twice, stop trying it and move to a different one.
5. WHEN TO STOP AND COME GET ME
Pause and ask BEFORE anything irreversible or outside scope: spending real money, deleting data, sending messages, publishing, or touching anything on the NEVER list. If you get stuck (three reverts in a row with no progress), stop and tell me what you learned. Never work around a guardrail just to finish.
6. HOW TO REPORT WHEN YOU FINISH OR RUN OUT
Tell me, in this order: the best result, what you kept and why, what you tried that failed, anything still unresolved, and why you stopped. Do NOT hide a partial or failed result behind a confident summary. If it did not fully work, say so plainly and show the log.
Three lines in there do most of the work.
Step 3, writing the undo before making the change. Everybody skips this and everybody regrets it. Writing it first also forces the thing to consider whether the change is reversible at all.
Step 7, unclear counts as worse. Without that line, anything ambiguous gets kept, and after forty attempts you have a pile of changes nobody can justify.
The last line of section 6, do not hide a failure behind a confident summary. A report listing only wins is not a report. You want the failures visible, because that is where you learn whether the goal was even right.
The real win
You may never run an autonomous experiment. It does not matter. Every one of these applies the moment you let any tool do work without watching each step.
Say you hand over rewriting two hundred product descriptions. Same six questions. What does good look like, and who decides. Which ones may it touch. Can you put it back. How many before somebody checks. What must it never do without asking. What does it tell you at the end.
Answer those in writing and you can safely let a lot of work happen without you. Skip them and you are not delegating, you are gambling, and the difference only becomes obvious after the fact.
The instinct is to ask how much you can let it do. The better question is how tightly you can draw the box, because that is what determines the answer to the first one.