Safety & Control5 min read

Human-in-the-Loop Playbook

Checklists, red flags, and recovery moves for supervised AI work

Nexgile Code is a strong pair programmer — fast, tireless, and good at the mechanical middle of most tasks. But you are the engineer of record. Every safety feature in Nx IDE — approvals, checkpoints, command guardrails, cost caps — exists to keep judgment where it belongs: with the person who understands the system, the users, and the consequences. This page is the field guide for exercising that judgment efficiently: what to check before a task, what to watch during, what never to auto-approve, and how to recover when something goes wrong.

Before you start a task

A one-minute pre-flight prevents most bad runs:

Mode matches intent. Architect to plan, Code to implement, Ask for read-only questions, Debug for diagnosis. The wrong mode either can’t do the work or has more power than the task needs. See Using Modes.
.nexgilerules is present and current — stale conventions produce confidently wrong code. See Rules Files & AGENTS.md.
.nexgileignore excludes secrets and build artifacts so they never enter context. See .nexgileignore & Protected Files.
allowedMaxCost is set — about $5 for a normal task, about $20 for a large refactor.
Checkpoints are enabled (Settings → Checkpoints) and working — no nested git repository warnings.
Working tree is clean (git status empty). Not required, but it makes your final diff review trivial.

A copy-paste version to keep in your project:

## Agent task pre-flight
- [ ] Right mode (Architect plan / Code implement / Ask explore / Debug diagnose)
- [ ] .nexgilerules current; .nexgileignore covers secrets & artifacts
- [ ] Max Cost set ($5 normal / $20 large refactor)
- [ ] Checkpoints on, no nested-git warning
- [ ] git status clean
- [ ] Denylist covers this project's irreversible commands

While the agent runs

Read approval prompts, don’t pattern-match them. The diff in the prompt is the ground truth; the agent’s stated intent is commentary. The moment before you click Approve is your highest-leverage review point.
Spot-check terminal output. The agent reasons from a bounded preview of command output; if its conclusion about a build or test run seems off, open the terminal and look at the full output yourself.
Detect loops early. The same fix attempted a third time will not work the fourth time. Stop the task and rephrase with explicit constraints (“do not modify the config again; the problem is in the loader”).
Watch the cost meter in the task header. A task that reaches its cap gets paused with a Reset and Continue prompt — investigate what it has been doing before topping it up.
Stay reachable. If you enabled auto-answering of follow-up questions, remember the agent takes the first suggestion after the timeout — for delicate tasks, turn that toggle off and answer yourself.

Never auto-approve these

Whatever your auto-approve profile, keep these behind a manual click — the blast radius is too large or the effect irreversible:

Operation	Why it stays manual
Database migrations	Can lock tables or destroy data; often irreversible in production
Auth, session, or token-handling changes	Security and compliance consequences outlast the task
`git push --force`, branch resets	Can overwrite teammates’ work
Edits to `.gitignore` / `.dockerignore`	One removed line can leak secrets into commits or images
Major dependency version bumps	Cascading breakage lands later, when it is expensive
CI/CD pipeline changes	Affects everyone who ships
Writes outside the workspace	Dotfiles and machine config are not checkpointed by your project workflow
Protected-file edits (`.nexgilerules`, `.nexgile/**`, …)	These reshape the agent’s own behavior

The command denylist enforces part of this list mechanically — put git push --force, rm -rf, and your database CLIs in deniedCommands so a prompt isn’t even possible. See Command Guardrails & Limits.

After the task

Run the tests yourself for high-stakes changes. An independent Tester verdict is evidence, not proof.
Review git diff file by file — you are signing this work.
Audit comments the agent wrote. Keep the load-bearing ones, delete narration.
Scan for stubs: TODO, FIXME, throw new Error("not implemented"), mocked returns that were supposed to be temporary.
In delegated runs, open the child task traces — not just the final summary. See Workflow Mode.

Red flags

Red flag	What it usually means
“All tests pass” but no test command appears in the terminal log	The claim is inferred, not verified — run the tests yourself
The agent asks you to bypass a protected-file approval	Never grant it in-flight; stop and make the change deliberately yourself
An instant “approve” verdict on a large diff	The review was shallow — re-review manually
Tester reports success from a one-line test plan	Verification theater; demand a real plan or test manually
Repeated re-reading of the same files, contradicting earlier decisions	Context fatigue — condense or start a fresh task (Context Management)

Recovery

Situation	What to do
Agent broke a file	Restore Checkpoint from the chat row (Checkpoints)
Agent ran a wrong command	Check the terminal and undo manually — checkpoints do not capture terminal side-effects
Delegated chain is stuck	Stop button — it aborts the whole chain
Context-limit errors mid-task	Enable auto-condense and resume, or start a fresh task carrying the current diff as context
Agent loops on the same fix	Stop, then rephrase with explicit “do not try X again” guidance
Cost cap reached	Review recent activity first; Reset and Continue only if the task is genuinely converging

The stance that works

Treat Nexgile Code the way you would treat a very fast, very confident new teammate: give clear briefs, review the diffs, keep the dangerous credentials out of reach, and grow trust one category at a time. The teams that get the most out of the agent are not the ones who approve everything — they are the ones whose guardrails are tight enough that approving most things is safe.