# Golden Rules for Agentic Engineering

Author: Indrajeet Patil
Format: Quarto RevealJS presentation
Canonical URL: https://www.indrapatil.com/agentic-engineering-golden-rules/
Source: https://github.com/IndrajeetPatil/agentic-engineering-golden-rules/
License: CC0 1.0 Universal
Publication date: 2026-10-08
Language: English

## Summary

This slide deck presents ten golden rules for agentic engineering: using coding agents to boost productivity without compromising quality. Its central claim is that code generation is the easy part. Quality comes from the engineering system around the agent: a codebase that is easy to navigate, a deterministic harness that gives fast feedback, observable acceptance criteria, enforced permission boundaries, tightly scoped tasks, clean context, measured outcomes, and a team culture that keeps humans responsible for what ships.

The talk is aimed at software engineers who ship production software and have at least some experience with coding agents such as Claude Code or GitHub Copilot CLI.

## The golden rules

1. Measure the whole job. Choose whether to use an agent: a direct human edit, an existing tool, or a script may be the simplest effective approach. Judge time to an accepted result, review and rework effort, later defects, and maintenance burden, including preparation and verification. Compare similar tasks against the same acceptance criteria. Generation speed and code volume omit much of the job. Start with a real pain point and add complexity only when it improves outcomes.
2. DevEx = AgentEx. If humans hunt for context, agents burn tokens too. Clear structure, one-command workflows (such as make setup and make qa), deterministic QA, living documentation (including a short AGENTS.md), and modular design help humans and agents alike.
3. Define done before delegating. Combine intent with observable acceptance criteria: state the outcome, constraints, what must stay unchanged, and the evidence needed to accept the result. Prescribe steps when sequence matters, such as migrations, incident response, or proven diagnostics. Reproduce bugs before fixing them, inspect rendered UI interactions, and measure performance under comparable conditions. Implementation and tests can share a misunderstanding; compare both with the requirements. Agents verify their own work, inspect results, fix failures, and re-check before handing over evidence for human review.
4. Scope control. In brownfield projects, introduce changes in reviewable, reversible chunks. Keep each change within review capacity. Capture broader issues as follow-up tasks.
5. Bound the blast radius. Define and enforce what the agent may read, change, and execute, with task-appropriate filesystem, network, tool, and credential access. Protect credentials and distinguish retrieved content from authorised instructions. Agree which consequential actions need human approval before their effects. Review before merge does not control earlier actions. Git worktrees isolate edits but are not a security boundary; use a sandbox with enforced access limits.
6. Guardrails. Fast feedback beats orchestration. Use a deterministic harness (formatters, linters, type checkers, behaviour-focused tests, Git hooks, secret, dependency, and infrastructure scans, and accessibility audits) to keep the agent's non-determinism in check. Invest in one reliable command that checks the agreed gates and run the same gates in CI; human review still checks whether the work solves the right problem. Never weaken a check merely to get green; repairing an inappropriate gate is deliberate, reviewed work.
7. Session hygiene. Coherent context beats haunted context. Long sessions accumulate stale assumptions and conflicting instructions. Default to one task per session, but keep a closely related follow-up in the same session when its reasoning and discoveries still help; restarting can lose a constraint or a failed hypothesis. Length matters as well as coherence, because recall degrades as context grows (context rot); clear context between unrelated tasks and compact only when continuing related work. Use one Git worktree per parallel task to isolate edits, not permissions, and keep durable conventions, decisions, and lessons in the repository (for example, AGENTS.md) rather than in chat history. Reset with a compact handoff: goal, constraints, relevant files, approaches already ruled out, and acceptance checks.
8. Know thy tools. Sometimes the unlock is a hidden tool affordance. Example affordances that users miss include Claude Code voice dictation, Codex built-in image generation, and GitHub Copilot CLI computer use. Read the changelog; these examples are not exhaustive. Official docs were checked on 8 October 2026. When results are poor, check whether the agent had the right context, tools, and feedback.
9. Meta-automation. Automate repeated agent choreography with prompts, skills, slash commands, and workflows once the approach improves the whole job. Examples include a dependency-update prompt, a PR screenshot skill, an illustrative review-command shortcut, and a vulnerability-management workflow that triages findings, verifies warranted fixes, and records reasons for rejected findings. Automate coordination; keep judgement human, and run unattended agents only in isolated sandboxes with scoped credentials.
10. Be curious. Be humble. Be kind. AI is not an excuse to become incompetent or disagreeable. AI does not remove responsibility for design, code, tests, security, or communication.

## References discussed

- Simon Willison, Agentic Engineering Patterns.
- Anthropic, Building effective agents.
- Anthropic, Effective context engineering for AI agents.
- Anthropic, Claude Code best practices.
- Birgitta Böckeler, Harness engineering for coding agent users (martinfowler.com).
- Ryan Lopopolo, Harness engineering: leveraging Codex in an agent-first world (OpenAI).
- Kent Beck, Augmented coding: beyond the vibes.
- Anthropic, Demystifying evals for AI agents.
- OWASP, Excessive agency and Prompt injection.
- Git, git-worktree manual.
- AGENTS.md, an open format for guiding coding agents.

## Retrieval notes

The canonical HTML page is the primary version of the presentation. This text file exists to give search engines, answer engines, and agentic assistants a concise, non-JavaScript-dependent summary of the deck's content and citation metadata.