Running an AI Coding Agent in a Repository With No Tests
A verification-first coding agent needs something to verify. See what Wukong Code does when a workspace exposes no runnable test, lint, typecheck, or build command, and why it asks you to acknowledge that before it starts.
> The honest problem with an untested repository
A coding agent that promises verified work has to answer an awkward question: verified against what? Plenty of real repositories — a prototype, a script collection, an inherited service — expose no test command at all.
The tempting answer is to let the model judge its own output and call that a pass. Wukong Code does not do that. When a workspace has no executable checks, the missing evidence is recorded as a fact about the run rather than papered over.
> Check discovery reads the workspace, not a guess
Before a Loop starts, Preflight looks for real check commands declared by the project: root scripts and, in a monorepo, the members that a pnpm, npm, yarn, or bun workspace actually declares. Each proposed check keeps the source locator and definition it came from, so you can see why it was suggested.
You can accept the discovered set, replace it with explicit commands, or exclude discovery entirely. Whatever you choose is frozen into the Gate Plan for the whole run, so an agent cannot quietly drop a check that keeps failing.
wukong loop "fix the CSV importer" --check "npm test" --only-explicit-checks --dry-run
# Preflight prints the frozen Gate Plan and the exact flags a headless start needs.> No executable checks becomes a decision you acknowledge
If discovery finds nothing runnable and you add nothing explicit, the Loop does not silently continue. It produces a versioned no-executable-checks decision that starts in a confirmation-required state and only becomes acknowledged once you confirm it — in the TUI, or in headless mode by passing the exact digest the dry run printed.
The decision carries its own policy version and digest, so the record shows which rule was in force and exactly what you agreed to. Acknowledging it is not a way to make the Gate stricter or weaker; it is a way to make the absence of evidence explicit.
- [+]The decision is versioned and digest-pinned, not a boolean flag.
- [+]Headless runs must pass the digest from --dry-run, so the confirmation cannot be automated away by accident.
- [+]The recorded run shows the workspace had no executable checks rather than implying it passed some.
> What a Gate can still tell you without tests
A read-only reviewer with a fresh context still reads the change and reports blockers, and the built-in risk rules still run. What disappears is deterministic proof: nothing executed, so nothing can be cited as having executed.
That is the point of making the decision explicit. A result produced without executable checks is a weaker claim than one backed by a passing suite, and the record says so instead of flattening both into the same green word.
> The better move: add one real check first
If the repository has no checks because nobody has written them yet, the highest-value first Loop is often the one that adds a single meaningful check — a smoke test, a typecheck, a build — and then leaves every later Loop something to verify against.
Once one command exists, discovery will find it, the Gate Plan can require it, and subsequent runs stop depending on an acknowledgement.
wukong loop "add a typecheck script and make it pass" --check "npm run typecheck" --max-iterations 6 --dry-run
# Review the plan, then rerun the same command with the exact flags it printed.> Related guides
Try the workflow in your repository
Wukong Code is free and BYOK for macOS, Linux, and Windows.
[DOWNLOAD_WUKONG]