Golden Rules for Agentic Engineering

Indrajeet Patil

golden rules

for agentic engineering

Boost productivity without compromising quality

Source code for these slides can be found on GitHub. All illustrations in this presentation are AI-generated.

This is a practical talk, not a theoretical one. The goal is to explore how agentic software engineering can make us faster while still protecting quality.

The illustrations are AI-generated, which is intentional: the topic is hands-on use of AI as a tool.

Invite the audience to think about one area of their daily engineering work where they lose time: finding context, writing repetitive code, coordinating changes, or waiting for feedback.

Before we start

Audience

You ship production software

Tests, deployment, security, and maintenance matter.

Exception

Throwaway code

Relax engineering rigour for disposable code; retain safeguards for real data and real actions.

Caveat

No panacea

These are principles that sharpen judgement, not a magic recipe.

On the risks of real actions, see The lethal trifecta for AI agents (Willison) and Excessive agency (OWASP).

Quality gates such as tests, security, deployment, and maintenance are part of the conversation. Throwaway proofs of concept, demos, and prototypes can trade engineering rigour for speed: tests, coverage, and polish can wait until the code starts to matter, which often happens sooner than planned. The consequences of running the code cannot wait. A disposable script can still expose credentials, alter real data, or send something externally, so keep scoped credentials, sandboxes, and approval before the agreed consequential actions. The aim is to sharpen judgement, not to sell a magic solution.

Golden rules

01

Measure the whole job

02

DevEx = AgentEx

03

Define done before delegating

04

Scope control

05

Bound the blast radius

06

Guardrails

07

Session hygiene

08

Know thy tools

09

Meta-automation

10

Be curious. Be humble. Be kind.

01 Measure the whole job

Choose the simplest approach that improves time to an accepted result.

Simplest-solution principle: Building effective agents (Anthropic). The whole-job measures are practical recommendations for coding work.

Decide whether an agent is useful before deciding how to orchestrate one. A direct human edit, an existing tool, or a deterministic script can be the simplest effective answer. Use an agent when its flexibility improves the result enough to justify the extra coordination and verification.

Anthropic recommends starting with the simplest solution and adding complexity when it demonstrably improves outcomes. This is an application of that principle to day-to-day coding work, not evidence that agents always help or always hurt.

Judge the whole job: time from preparing the task to an accepted result, human review and rework effort, defects discovered after acceptance, and maintenance burden. Generation speed and code volume omit much of this work. Include abandoned attempts and track human review time separately so faster generation does not hide extra work for colleagues.

Compare similar tasks and agreed acceptance criteria. Record enough context to interpret the result: task difficulty, the approach used, and relevant conditions. A one-off anecdote cannot establish a universal productivity gain.

Start with a real pain point, try a small change in approach, and keep it when the total outcome improves. Revisit the choice as tools and team practices change.

02 DevEx = AgentEx

If humans hunt for context, agents burn tokens too.

DevEx equals AgentEx: what makes a codebase easy for humans makes it cheaper and safer for agents to work in.

If developers need to hunt through unclear documentation, inconsistent commands, or hidden conventions, agents will struggle too. They burn tokens, make assumptions, or ask for more context.

DevEx = AgentEx: in practice

One setup command. The same starting point for humans and agents.

See the AGENTS.md convention.

A long setup checklist asks every developer and agent to reconstruct the procedure: install the runtime, create an environment, install dependencies, configure variables, install hooks, start services, apply migrations, load fixtures, and verify the result.

Capture that procedure in a maintained setup command. Then AGENTS.md can point to one starting instruction: run make setup. Humans use the same command.

The work still happens; the command owns the sequence, checks prerequisites, and reports useful errors. Keep the implementation reproducible and the instruction current so neither humans nor agents have to guess the next step.

03 Define done before delegating

State the outcome, what must stay unchanged, and the evidence that will show it works.

On specifying success and grading outcomes rather than paths, see Demystifying evals for AI agents (Anthropic).

This combines specifying intent with defining done. Before delegating, agree an observable outcome, constraints, what must remain unchanged, and the evidence needed to accept the result. Let the agent choose the route unless the sequence itself matters.

For example: fix date parsing so invalid dates produce the documented error, preserve the public API and valid-date behaviour, and show a reproduction that fails before the fix and passes after it. Check the expected outcome against the requirement, rather than assuming the existing test is right.

Choose evidence that addresses the task. A bug needs a reproduction and a changed outcome. UI work needs inspection of the rendered interaction, including relevant keyboard and responsive states. Performance work needs comparable before-and-after measurements under stated conditions.

When the agent writes both implementation and tests, both can encode the same misunderstanding. Compare the assertions with the agreed criteria, include relevant unchanged behaviour, and inspect the actual result. More tests or higher coverage alone do not settle the question.

Agents must verify their own work: run relevant checks, inspect results, fix failures, and re-check before reporting completion. Hand over evidence tied to the criteria, including any unresolved limitations. Guardrails provide fast feedback; this rule asks whether the evidence proves the intended outcome.

Prescribe steps when their order matters, such as migrations, incident response, or a proven diagnostic workflow. Otherwise, specify the outcome and constraints, provide strong tools, and retain human review of what ships.

Define done before delegating: in practice

Bug fix

Reproduce the failure. Show the same case succeeding after the fix, and check relevant unchanged behaviour.

UI change

Inspect the rendered interaction, including relevant keyboard and responsive states. A build alone cannot show this.

Performance

Measure before and after under comparable conditions. State the workload and trade-offs.

Check the meaning of the tests. Implementation and assertions can agree with each other while missing the requirement.

Bug and UI checks adapted from Claude Code best practices (Anthropic).

Define the expected result before the implementation. Keep the acceptance criteria independent of the agent’s chosen solution.

Ask for evidence that a reviewer can inspect: the reproduction and check results for a bug, the rendered interaction for a UI change, and before-and-after measurements for performance work. Check both the requested change and the behaviour that must remain unchanged.

A second agent can offer another perspective, but agreement between agents is not a substitute for checking the requirement and observable outcome.

04 Scope control

Small diffs beat heroic prompts.

In brownfield projects, introduce changes in reviewable, reversible chunks. Scope control is the difference between useful automation and an unreviewable mess.

Scope control: in practice

Why

Agents can produce changes faster than reviewers can assess them. Keep each change within review capacity.

How

Prefer narrow tasks: one bug, one refactor, one test gap, one migration step. Each chunk should be reviewable, testable, and revertible on its own.

When the agent discovers broader issues, capture them as follow-up tasks instead of expanding the current change indefinitely.

See Small CLs (Google Engineering Practices).

Agents are good at making many changes quickly, but reviewers need changes that are small enough to understand.

Google’s code review guide lists why small changes help: they are reviewed more quickly and more thoroughly, are less likely to introduce bugs, waste less work if the direction is wrong, and are simpler to roll back. Those benefits matter more, not less, when an agent can generate a large diff in minutes.

05 Bound the blast radius

Limit what the agent can read, change, and execute; agree which actions need approval.

Sources: Git worktrees · OWASP Excessive agency · Prompt injection.

Review before merge governs the diff, but an agent can read secrets, run commands, or affect external systems before there is a diff to review. Set the operating boundary before it starts.

Define what it may read, change, and execute. Enforce the boundary with appropriate filesystem and network restrictions, limited tool access, and credentials scoped to the task. Keep unnecessary credentials out of its environment and protect secrets from prompts, logs, and generated artefacts. A written instruction alone is not an access control.

Agree which consequential actions require human approval, such as deploying, sending messages, or deleting real data, and enforce that checkpoint before the action. Approval should identify the actual target and effect. Existing explicit authorisation can cover the action; the goal is a clear boundary, not repeated permission questions for routine work.

Retrieved pages, issues, documents, and tool output are evidence to inspect. They do not gain authority to change the task or grant permissions just because the agent reads them. Clearly separate external content from authorised instructions; this reduces risk but does not make prompt injection impossible.

Git documents separate working trees and per-worktree metadata alongside shared repository data. This is separation of edits, not an operating-system access control: worktrees share the host’s access and do not provide a security boundary. A sandbox must actually restrict filesystem, process, and network access to contain actions. Check the configured restrictions rather than assuming a tool’s default mode supplies them.

Bound the blast radius: in practice

Access

Allow only the files, tools, network access, and credentials needed for the task. Enforce the limits outside the prompt.

Authority

Treat retrieved content as data. It cannot grant permissions or override authorised instructions.

Approval

Agree the actions that need approval, and place the checkpoint before their real effects.

Worktrees isolate edits; they do not contain actions. Use a sandbox with enforced access limits.

Sources: Git worktrees · OWASP Excessive agency · Prompt injection.

Scope control keeps changes reviewable; bounding the blast radius limits what the agent can affect while making them. Both matter, and a narrow task still needs appropriate permissions.

Start by listing necessary reads, writes, commands, and external access. Remove unused tools and credentials. Confirm that the sandbox and downstream systems enforce the agreed limits. Reserve human approval for the agreed consequential actions before they occur.

06 Guardrails

Fast feedback beats orchestration.

Guardrails are more important than elaborate orchestration. Fast, deterministic feedback keeps the agent’s non-determinism under control.

Guardrails: in practice

The harness

Formatters, linters, type checkers, behaviour-focused tests, Git hooks, and security scans

One command

make qa checks the agreed gates, and CI runs the same gates. Review checks whether we solved the right problem.

Agents optimise for green

Never weaken a check merely to get there. Repairing a wrong gate is deliberate, reviewed work.

See also Harness engineering for coding agent users (Böckeler, martinfowler.com).

An agent can propose changes quickly, but quality comes from the harness around it: tests, linters, type checks, build commands, security scans, and reproducible local setup.

The workflow sends failed checks back to the agent with precise error output. Passing checks lead to human review before merge.

Green checks establish less than “the work is acceptable”. They show that the configured gates pass, not that the requirements were right, that the tests capture them, or that the user experience works. Review answers those questions.

Agents will find the shortest path to green, including lowering a threshold or disabling a check. Do not weaken a check merely to pass. Sometimes a gate really is wrong, such as a flaky test or a rule that does not fit the code; repairing it is legitimate work, but make it a deliberate, separately reviewed change.

Coverage gates invite filler tests. Ask agents to assert behaviour at the boundaries you own (the outbound request, the streamed output, the logged event), never to execute lines for the sake of coverage.

07 Session hygiene

Coherent context beats haunted context.

Sources: Context engineering and Claude Code best practices (Anthropic) · Git worktrees.

Keep sessions coherent, parallel tasks isolated, and durable knowledge in the repository.

Every correction, abandoned approach, and reversed decision stays in the context window. After enough of them, the agent is reasoning over contradictions.

One task per session is a useful default, not an absolute. A closely related follow-up can benefit from the reasoning and discoveries already in context, and restarting has a cost: a handoff can lose an important constraint or a failed hypothesis. Length matters as well as coherence: Anthropic describes context rot, where recall of information in the context degrades as the token count grows. Clear context between unrelated tasks; compact only when continuing related work whose decisions are worth keeping. Restart when the context stops being coherent or is filling with material the next step does not need.

Use one Git worktree per parallel task so each task has its own working directory. Worktrees isolate edits, not permissions; apply the access limits from Bound the blast radius as well. Keep durable conventions, decisions, and lessons in the repository, for example in AGENTS.md, so future sessions can find them without relying on old chat history.

Signs of a haunted session include reviving a rejected approach, confusing earlier and current requirements, repeating the same correction, or continuing after the conversation has outgrown its original task. Claude Code’s best practices suggest a concrete threshold: after two failed corrections on the same issue, start fresh with a better prompt.

Reset with a compact handoff: the goal in one sentence, constraints on what must not change, relevant files to start with, approaches already ruled out, and acceptance checks that show when the work is done.

08 Know thy tools

Sometimes the unlock is a hidden tool affordance.

Official docs: Claude Code voice · Codex images · Copilot CLI computer use.

These are example affordances that users miss, not an exhaustive feature list or a claim that each capability is exclusive to one product. Official documentation and release notes were checked on 8 October 2026.

Claude Code voice mode is prompt dictation: /voice enables speech-to-text input. It requires a Claude.ai sign-in and a local microphone; it is not available with direct API-key or third-party-provider authentication, or in cloud or SSH sessions.

Codex supports built-in image generation for creating and editing visual assets alongside code, including in the CLI. Describe the desired asset and supply a reference image for an edit; $imagegen invokes the skill explicitly. The illustration uses the general product name because this affordance is not limited to the desktop app.

GitHub Copilot CLI computer use entered public preview on 1 October 2026. /computer on enables it in local sessions on macOS and Windows, subject to permissions and organisation policy. It can read, click, type, and navigate desktop interfaces. Use a direct API, CLI, MCP, or dedicated browser tool when one fits the task; computer use is useful for GUI-only workflows.

Read the changelog: a release note can remove a bottleneck you have been working around for months. Availability and commands can change, so revisit the linked official docs when updating this slide.

When results are poor, ask whether the agent had the right context, the right tools, and the right feedback.

Sometimes the limiting factor is not the model; it is the tool interface available to the model.

Agents perform better when they can inspect files, run commands, search the repository, execute tests, and see failures. If a tool is hidden, blocked, or awkward, the agent may appear less capable than it really is.

09 Meta-automation

Automate repeated agent choreography.

Capture once. Run many times.

Once a useful agent workflow repeats and improves the whole job, automate the choreography around it.

Meta-automation: in practice

Prompts, skills, shortcuts, and workflows turn repeated work into reusable automation.

Examples adapted from chatbot-template prompts and its PR screenshot skill.

These are examples of different ways to package automation, not four mutually exclusive systems. A slash command can invoke a prompt or a skill; a workflow can compose both.

The dependency-update prompt in chatbot-template refreshes dependencies, fixes compatibility breaks, runs the project’s quality gates, and prepares a draft PR. The screenshot skill packages the steps for previewing the app, capturing its appearance, and attaching evidence to a PR.

The /address-review command is an illustrative shortcut to the repository’s address-review.md prompt, not a claim that this checkout installs that slash command. Review comments need evaluation; make warranted fixes, verify them, and reply. Resolve only addressed comments or those confirmed to need no change.

The vulnerability-management workflow is adapted from codex-security.md. Scan findings are claims to investigate. Triage checks reachability, existing mitigations, and regression risk before deciding whether a fix is warranted. Confirmed findings with a focused, safe fix proceed to remediation, verification, and a draft PR. Other findings get a recorded reason; no code changes means no PR. Verification includes checking that the vulnerability is resolved and running relevant regression checks. Failed verification returns to the fix step.

Automate coordination: gathering context, running checks, formatting reports, and repeating the process across repositories. Humans evaluate evidence, make trade-offs, and decide what ships. 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 should make us better teammates, not careless or difficult ones.

Be curious about what the tools can do, humble about their limits, and kind in how we review agent-generated work and each other’s experiments.

Be curious. Be humble. Be kind: in practice

Curious

Experiment, prototype, and keep learning the fundamentals the agent is standing on.

Humble

Agents are confidently wrong. So are we. Verify before you trust, including your own prompt.

Kind

Review agent-generated work as carefully as human work, and review humans as kindly as ever.

AI does not remove responsibility. You still own the design, the code, the tests, the security implications, and the communication with your team.

Making it stick

Code generation is the easy part

Everything around it needs planning, especially in teams.

Share

Pool your team’s tips and tricks for agentic coding. Someone has already solved your annoyance.

Fix pain points

Pick a real pain point (slow tests, unclear setup, flaky workflows). Use the simplest effective approach, and measure the whole job.

Frontload planning

Task division, coordination, and reviewability matter more when everyone has an agent.

Challenge your habits

Revisit your workflow as tools change. Keep changes that improve the outcome.

Simplest-solution principle: Building effective agents (Anthropic).

Code generation is often the easy part. The hard part is planning work in a team: dividing tasks, coordinating changes, preserving quality, and making results reviewable.

Further reading

• Willison, S. Agentic Engineering Patterns.

• Anthropic. Building effective agents.

• Anthropic. Effective context engineering for AI agents.

• Anthropic. Claude Code best practices.

• Böckeler, B. Harness engineering for coding agent users. martinfowler.com.

• Lopopolo, R. Harness engineering: leveraging Codex in an agent-first world. OpenAI.

• Beck, K. Augmented coding: beyond the vibes.

• Anthropic. Demystifying evals for AI agents.

• OWASP. Excessive agency and Prompt injection.

• Git. git-worktree manual.

• AGENTS.md: a simple, open format for guiding coding agents.

Thank You

Go forth and delegate responsibly.

Check out my other slide decks on software development best practices