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.

That is why developers cared. 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, Anysphere’s AI code editor, 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 ai coding for teams stops being a vibe and starts becoming a repeatable engineering practice.

The trap is judging 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

The trap is making 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.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Cursor artifact first: a .mdc rule stub, an AGENTS.md boundary, a custom subagent note, or a Cursor review checklist.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• What should teams know about ai coding for teams?

  Start by writing down one visible team rule for Cursor, not a loose preference. That is the practical core of ai coding for teams. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Cursor artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a .mdc rule, AGENTS.md note, or review checklist. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Cursor teams deciding which rule, subagent, skill, or MCP boundary to standardize next around “Agentic Coding Notes and Bounded Loops.”
• Best first artifact: turn the named fix into a .mdc rule, AGENTS.md note, subagent receipt, or review checklist before the next automated run.
• Best comparison angle: compare the workflow against the current Cursor review path, connector scope, and team rule file; keep the path that leaves the shortest auditable trail.

Further reading

• Agentic coding notes — source
• Model Context Protocol — specification
• GitHub — anthropics/skills
• developers.google.com: fundamentals creating helpful content

Where to go next

Start from the related training topic and make the first exercise prove scope, verification, and ownership in the PR body.