AI Coding Workflow for TypeScript

Give the agent one named task, only the context it needs and a check you can rerun. A task shaped this way produces a diff small enough to review and a result you can repeat.

Each move fails in its own way. Without a boundary, the agent edits files you never meant to open, and the diff becomes hard to read. Thin context fails more quietly: the code compiles and the tests pass, but the change ignores patterns the rest of the repo follows. Without a check you can rerun, you are taking the agent's word that the work is done.

Asking for a plan before the agent writes code is the easiest step to skip. It means a short wait while nothing visible happens, and the price of skipping it shows up later, in review.

If the plan names files you didn't expect, you learn that before any code exists. If it names the right files, you have a list to check the diff against. Once four hundred lines of diff are on screen, changing the approach means throwing that work away.

The habit that matters most for a team is leaving a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change.

1. 1Pick one real backlog item with a clear owner and expected result.
2. 2Add only the context the agent needs: files, failing output, constraints and done state.
3. 3Ask for a plan before code when the task touches more than one file.
4. 4Run checks that match the risk: unit test, typecheck, visual pass or review checklist.
5. 5Capture the prompt, diff, result and reviewer note so the workflow can be repeated.

Match the effort to the change. A one-file fix needs a clear done state and a typecheck, and a plan adds little. A change across several files is where a plan pays for itself, and where the check should include tests and a reviewer who knows that code.

Keep whatever lets someone rerun the work or pick it up later. A finished task is the merged code plus a short trail that shows how it got there.

• The prompt or plan that shaped the work.
• The files changed and the reason each file changed.
• The command, screenshot or review note that proved the result.
• The rule, checklist or template you would reuse next time.

The last item pays off over time. A rule or template saved from one good run means the next run starts from what already worked, not from a blank prompt.

Start from whichever one you can rerun with a single command, and give the agent its real output instead of your summary of it. In a TypeScript repo, that is usually the compiler. A type error names a file, a line and the shape the compiler expected, which is most of a prompt already. A failing test tells you behavior is wrong without saying where.

The order matters because types and tests fail at different distances from the cause. A type error usually sits next to the mistake. A test failure can sit several layers away, and an agent given only the test will often satisfy the assertion at whichever layer it happened to be reading. That fix lands in the wrong place, and it still typechecks.

When both are broken, fix the types first and rerun the test before you change anything else. The type fix can take the test failure with it, which makes it the cheaper order to try.

Because passing the typecheck and being correctly typed are two different claims. The quickest route to a green build is to make a type less specific: an any, a cast, a non-null assertion, or a generic loosened one parameter at a time. All of those compile, and each one moves a check out of the build and into a later incident.

So read the type edits before the logic edits: scan the diff for signatures that got wider, then look for behavior that changed. The widened signature is the edit that outlives the ticket, because the next person to call that function reads its type as a promise about what it accepts.

None of this is unique to agent-written code, but an agent produces these edits faster than review habits were built to catch them.

Write the boundary down where the package lives. Cursor reads AGENTS.md files in any subdirectory and applies them to files in that directory and its children. It combines them with the parent instructions, and the more specific file takes precedence. A package that must not import from a sibling can say so in its own AGENTS.md, instead of relying on a root file that tries to describe every package at once.

If you use project rules instead, get the extension right first. A plain .md file in .cursor/rules is ignored, because it has no frontmatter to hold description, globs and alwaysApply. Use .mdc, or use AGENTS.md and skip frontmatter altogether.

For a typing convention the agent should apply to every TypeScript file, use globs instead of a description. With alwaysApply: false and a comma-separated pattern list such as globs: **/*.ts, **/*.tsx, the rule attaches automatically whenever a matching file is in context. With a description and no globs, the agent reads the description and decides for itself whether the rule applies. It can get that call wrong on the one edit where the convention mattered.

It is tempting to run the check only on the package you touched. But a package that compiles on its own and breaks its consumers is the standard monorepo failure. The agent reports it as finished, because from inside the package it is. Run the dependent's build before you believe the result.

Hooks cover the mechanical half. They live in hooks.json, and afterFileEdit fires after the agent edits a file. Running formatters after edits is one of the documented uses, so the diff you sit down to read is already formatted.