Domain 3 · Lesson 4 · Claude Code Config (20%)
Iterative Refinement & CI/CD Integration
Task Statements 3.5 & 3.6 — refinement techniques, and running Claude Code in a pipeline.
Course progress: Domain 3 ▸ lesson 4 of ~4
Iterative refinement techniques (3.5)
| Technique | When it's the right tool |
|---|
| Concrete input/output examples | Prose descriptions get interpreted inconsistently. 2–3 examples of the exact transformation communicate it best. |
| Test-driven iteration | Write the test suite first (behavior, edge cases, performance), then iterate by sharing test failures to guide fixes. |
| Interview pattern | Unfamiliar domain — have Claude ask you questions first to surface considerations you didn't anticipate (cache invalidation, failure modes) before implementing. |
One message vs sequential
Interacting problems (fixes affect each other) → put them all in one detailed message so Claude reconciles them together. Independent problems → fix sequentially. Guess wrong and you either lose the interactions or create needless coupling.
CI/CD integration (3.6)
| Flag / concept | Purpose |
|---|
-p / --print | Non-interactive mode: process the prompt, print to stdout, exit. Prevents pipeline hangs waiting for input. |
--output-format json + --json-schema | Machine-parseable structured findings — post as inline PR comments. |
| CLAUDE.md in CI | Supplies project context (testing standards, fixtures, review criteria) to the CI-invoked run. |
Two reliability points
1) Session context isolation: the same session that generated code is worse at reviewing it (it retains its own reasoning) — use an independent instance to review. 2) On re-runs after new commits, include prior findings in context and tell Claude to report only new/unaddressed issues — avoids duplicate comments.
Automated test generation in CI
Two levers keep generated tests high-value instead of noisy:
- Provide existing test files in context so generation doesn't re-suggest scenarios already covered by the suite (the test-gen equivalent of "report only new" for reviews).
- Document testing standards, what makes a test valuable, and available fixtures in
CLAUDE.md so CI-invoked runs generate tests that match your conventions and skip low-value output. CLAUDE.md is the mechanism for passing project context (testing standards, fixture conventions, review criteria) to a CI run.
Check yourself
Your pipeline runs claude "Analyze this PR" and the job hangs waiting for input. The correct fix is to:
- Set an environment variable
CLAUDE_HEADLESS=true before running
- Add the
-p (--print) flag for non-interactive execution
- Redirect stdin from
/dev/null to satisfy the input prompt
- Add a
--batch flag so the command runs without a session
Correct: option 2. -p/--print is the documented non-interactive mode: process, print, exit. CLAUDE_HEADLESS and --batch are non-existent; the stdin redirect is a Unix workaround that doesn't address Claude Code's syntax.
You want the freshest, most objective review of code Claude just generated. Best practice:
- Ask the same session to re-read and critique its own output
- Enable extended thinking in the generating session before review
- Run the review in an independent instance without prior reasoning
- Increase the context window so the generator sees more at review
Correct: option 3. The generating session retains its own reasoning and is less likely to question its decisions. An independent instance (no prior reasoning context) catches more. Self-review and extended thinking don't remove that bias; window size is irrelevant.
Decision rules
Inconsistent from prose → give I/O examples. Unfamiliar domain → interview pattern first. Interacting fixes → one message; independent → sequential. CI hang → -p. Machine-parseable findings → --output-format json+--json-schema. Objective review → independent instance. Re-run → include prior findings, report only new.
Ask your teacher. Ready for the
Domain 3 quiz. Ask if CI structured output or the one-message-vs-sequential rule is unclear.