Dan Luu on Agentic Coding: Keep the Loop Bounded

Dan Luu, a widely read engineering blogger, published “Agentic coding notes”: field notes on using AI coding agents for real work. The problem he keeps running into is unbounded loops, where an agent iterates past the point anyone can explain its edits. His practical answer, and the lesson for Cursor users here: keep the loop small enough that a human can understand why the next step happened.

Agentic coding is using a model-driven tool to plan, edit, run commands, and iterate through a task with some autonomy while a developer sets boundaries and reviews the result. That is also the honest center of AI coding on a mixed-experience team: not everyone needs the same autonomy, but everyone needs reviewable evidence.

Dan Luu’s Agentic coding notes landed as the kind of post developers argue with because it feels close to the metal. It is not a vendor launch. It is a field note about using AI while coding and writing, with an appendix on agentic loops that makes the whole thing feel less like a demo and more like someone checking where the sharp edges are.

Read it as a field note, not a manifesto

The interesting part of Agentic coding notes is not that an agent can do work. We know that. The interesting part is the discomfort around the loop: when to let the model continue, when to stop it, and how much context to hand it before the session starts feeling less like engineering and more like babysitting.

The discussion around the post quickly moved to cost, context windows, and whether bigger prompts make old agent-control ideas unnecessary. One person’s rough point was that massive context sizes melt away some earlier cleverness; another worried that API-only model calls make every invocation feel like burning cash unless the context is carefully managed.

Both reactions can be true. Large context windows reduce the pain of forgetting, but they do not remove the need for intent. A megabyte of prompt can still be sloppy if it mixes durable repo rules, half-finished task notes, and old guesses that should have expired three commits ago.

There was also a small provenance lesson hiding in the thread. Commenters noticed an alt-text ambiguity around Galapagos Island, Vancouver, and Haida Gwaii. It is a tiny detail, but it is the same class of problem agents hit all the time: if a label is ambiguous, the system may confidently carry the wrong context forward.

Watch the loop, not just the diff

A good agentic loop has four visible parts: the goal, the files touched, the command evidence, and the reason for the next step. If you cannot reconstruct those four things after the fact, the agent may still produce a good diff, but you cannot learn from the session.

In Cursor that means the interesting artifact is not only the final patch. It is the conversation, the terminal output, the rule files, and the review notes that explain why the agent touched one boundary and avoided another. That is where agentic coding stops being a vibe and starts becoming a repeatable engineering practice for the team.

Don't judge the session only by whether tests pass. Passing tests are necessary, but they are not a receipt for intent. A coding agent can pass the local happy path while deleting an edge-case branch, weakening authorization, or moving logic across a boundary the repo cares about.

A small example: ask an agent to fix a flaky React hook test. A clean loop first reads the hook, reads the test, states the suspected timing issue, changes only the test harness or dependency boundary, runs the narrow test, then stops. A messy loop rewrites the hook, updates snapshots, runs the full suite, and leaves you with a green build and no clear story.

Put the boundary where a hook can enforce it

Agentic coding notes is a reminder that boundaries should be boring. The more dramatic your agent instructions are, the less likely they are to survive contact with a long session. Put the important rules where the editor, repository, or command workflow can keep showing them to the model.

For Cursor users, start with a scoped rule file instead of a giant global prompt. Cursor rules are Markdown-like project rules that can be attached to file globs and kept close to the code they protect.

---
description: React hook edits must preserve public behavior and test evidence
globs:
  - src/hooks/**/*.ts
  - src/hooks/**/*.tsx
alwaysApply: false
---

Before editing a hook:
- Identify the public contract in one sentence.
- Name the test file that proves the contract still holds.
- Do not move authorization, persistence, or network behavior into the hook.
- Run the narrow test before suggesting a wider refactor.

Stop after the first passing narrow test unless the human asks for a refactor.

Then add a local AGENTS.md boundary where the work actually happens. Keep it dull and enforceable.

# src/hooks/AGENTS.md

Permitted commands:
- pnpm test src/hooks
- pnpm lint src/hooks

Do not change:
- src/auth/**
- src/api/client.ts
- database migrations

Review note required:
- list changed files
- paste test command and result
- explain why hook behavior is unchanged or intentionally changed

Don't make the rule file a second README. Rules are not documentation in costume. They are context for a model under time pressure, so they should be short, local, and written as decisions.

If your loop needs live context from GitHub, Linear, Slack, or a database, Model Context Protocol (MCP), introduced by Anthropic is the integration layer worth understanding. MCP is an open protocol for connecting model clients to external tools and data sources. The same boundary question shows up in cloud MCP work too; see Manufact Brings MCP to the Cloud for a related example.

Try one bounded agent loop in Cursor

The safest thing to try after reading Agentic coding notes is one deliberately small loop. Pick a bug where the expected behavior is already known, the test surface is narrow, and the blast radius is obvious.

This is the practical place where coding agents earn their keep on a mixed-experience team. A senior engineer may use the loop to delegate a boring test repair. A newer engineer may use it to see how the repo explains itself. Both should leave with the same evidence: changed files, commands run, and a short explanation of why the patch is safe.

Try this workflow:

• Open the narrow file set in Cursor.
• Attach the scoped .mdc rule.
• Ask the agent for a plan before edits.
• Accept only the first minimal patch.
• Run the narrow test yourself, or have the agent run it and paste the result.
• Review the diff without trusting the chat summary.
• Write a two-line handoff receipt before merging.

A good handoff receipt is plain:

Changed: src/hooks/useAccountStatus.ts, src/hooks/useAccountStatus.test.ts
Evidence: pnpm test src/hooks/useAccountStatus.test.ts passed locally
Boundary: no auth, API client, or migration files changed
Reason: fixed stale timer assertion by advancing fake timers in the test harness

The limitation is obvious and important. This does not prove the agent can safely run through a large migration, design a new subsystem, or act as a custom subagent for a week of work. It proves one bounded loop can produce a reviewable change.

Copy the skill acceptance rubric

Use this rubric when you want to decide whether a coding skill, rule, or agent instruction is ready to reuse. It is intentionally small. If the rubric feels too strict, the skill is probably not specific enough yet.

This also maps cleanly to skill packaging. Anthropic’s Skills pattern uses a Markdown file to package reusable instructions and supporting material. The useful idea is not the file name; it is that reusable AI behavior should have an activation surface, a scope, and evidence that it worked.

Further reading

• Agentic coding notes
• MCP specification
• Anthropic skills on GitHub

Where to go next

Start from AI coding governance.