Coding agents & software engineering

why this matters

Coding agents operate over huge, changing state with delayed feedback. Success needs navigation, planning, precise edits, execution, tests, context management, and permission boundaries.

coverage

• Understanding: repository search, symbols, dependency and instruction discovery.
• Planning: scope, change graph, risk, checkpoints.
• Editing: patches, file ownership, generated code.
• Verification: tests, builds, static analysis, failure interpretation.
• Review: diff quality, regressions, user intent.
• Runtime: sandbox, permissions, long tasks, context compaction.
• Contrast: why this is harder than autocomplete.

mental model

The coding loop turns intent into a small verified diff, using repository feedback as evidence.

lessons

worked example

A coding agent makes tests green by deleting the assertion

A task asks for a parser fix. The agent changes both the parser and its tests; the suite passes because the failing assertion was removed.

1. Start from the intended behavior and a small change plan. Capture the original failure or an independent acceptance case.
2. Review the diff as evidence: changed tests require an explanation tied to the requested contract, rather than merely a green result.
3. Run targeted checks and then relevant broader checks in an isolated environment with scoped credentials and network access.
4. Persist the diff, command results, environment, and remaining risks for user review before publication or other external effects.

Design decision: Judge completion through independent behavioral evidence and reviewable artifacts, with permissions around execution.

Limit: A passing test suite establishes only what its assertions and environment cover. It cannot prove all intended behavior or the safety of every tool action.

Teaching scenario · traffic, prices, and capacity values are illustrative.

assignment

Produce: A coding-agent run protocol and an annotated review of two fictional patches.

Paper, a text editor, or a spreadsheet is enough. Model access and paid services are optional.

1. Define repository discovery, planning, scoped edits, verification, checkpoints, and publication boundaries.
2. Create one valid fix and one patch that weakens a check; identify the evidence that distinguishes them.
3. Trace a broken tool command, stale context, and a restarted run; specify what gets persisted and how non-progress is detected.

Change a constraint

• The repository contains instructions in untrusted generated files.
• Tests need network credentials the task should not receive.

Self-review rubric

• Verification checks the requested behavior independently.
• The diff and command results are reviewable.
• Execution and publication permissions have separate boundaries.

If a criterion is missing, revise that part of the artifact before rating your practice below.

Patch A: repair parser branch; keep invalid-record assertion;
         add boundary case + prove original implementation fails it.
Patch B: leave parser behavior; remove failing assertion; suite green.
Review: A changes intended behavior; B changes what “pass” means.
Protocol: inspect instructions/ownership → trace parser callers
          → hypothesis → scoped patch → independent behavior check
          → inspect diff → persist evidence/remaining work
Restart record: objective, constraints, changed files, command results,
                failing cases, next hypothesis, permission boundaries.

cumulative practice

Harbor · build and evaluate a support assistant

Keep one project document across this track. Reconstruct earlier reasoning before opening notes, then revise the same artifact. Use part of the assignment and review budget for this work. If you enter mid-course, sketch the earlier decisions first using the linked chapters.

Add to your project: Harbor's proposed code-change integration, scoped separately from support actions.

Suppose Harbor can propose a documentation/parser fix. Recall durable runs and least privilege. Define a sandboxed patch proposal and independent verification artifact, then handle a green result produced by deleting a failing assertion. Where does human publication authority sit?

Keep your first attempt and revision together. If your answer differs, identify the assumption or mechanism that explains the difference before rating your recall.

senior signal

Connect this to your engineering background: deterministic orchestration, clear contracts, and explicit ownership around a probabilistic planner are strong experience stories.

failure patterns

• Reading the whole repository into context
• Editing before discovering local instructions/tests
• Re-running the same failing command with no new hypothesis
• Declaring success without inspecting the diff and relevant tests

knowledge checks

Start with these quick checks, then explain the closed-book questions in your own words.

1. 01Best way to understand a large repo?

   A.Put every file in the promptB.Search and incrementally build a task-specific mapC.Guess conventionsD.Edit package files first

   select an option to check your answer

2. 02Why is a coding agent harder than autocomplete?

   A.It uses fewer tokensB.It must manage state, tools, delayed feedback, and recovery across many stepsC.It cannot read codeD.It never runs tests

   select an option to check your answer

closed-book recall

interview drill

Design the backend of a coding agent that receives a GitHub issue and returns a reviewed pull request.

• large repos
• untrusted code
• 45 min
• human review

references

• Anthropic: building effective agents ↗reviewed 2026-10
• Anthropic: effective context engineering for AI agents ↗reviewed 2026-10
• Anthropic: demystifying evals for AI agents ↗reviewed 2026-10

Sources offer deeper context. Provider capabilities and API contracts can change; check current official docs before implementing.

notes