AI Coding Workflow for TypeScript

The working pattern for TypeScript AI coding is small enough to review and specific enough to repeat. Give the agent a named task and only the context it needs, then tie the result to a check you can rerun. The table below breaks that into moves.

Each of those moves fails in its own particular way, and the order they come in is doing more work than it looks like it is. Skip the boundary and you get a diff nobody wants to read, because the agent has quietly rewritten files you never meant to open. Thin context fails more quietly: the code compiles, the tests pass, and it ignores every pattern the rest of the repo follows. Then there's the check, which to me is the real one, because it's the whole difference between a result you verified and a result you're taking someone's word for.

The step people skip is the plan. I think it's because it feels like overhead, thirty seconds of nothing visibly happening while you're trying to get work done. Actually, that's not quite the reason. It's that the cost of skipping it lands much later, so it never registers as the mistake it was. If the plan names files you didn't expect, you've learned something for free. If it names the right ones, you've got a reference to check the diff against when it arrives. And once there are four hundred lines on the screen, changing the approach means throwing that work away, which nobody is good at.

Running TypeScript AI coding as a team comes down to one habit: leave a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change, so nobody has to reverse-engineer what the agent did.

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.

Keep whatever lets you rerun the work or hand it to someone else. A finished task is the merged code plus the short trail that explains 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.

Start from whichever one you can rerun in a single command, and hand over its actual output instead of your summary of it. In a TypeScript repo that is usually the compiler, because a type error names a file, a line and the shape it expected, which is most of a prompt already written for you. A failing test tells you behaviour is wrong without saying where.

The order matters more than it sounds, 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 from it, and an agent handed only the test will often satisfy the assertion at whichever boundary it happened to be reading. Which is the wrong place, and it typechecks perfectly.

Say both are broken. Fix the types first and rerun the test before saying anything else, because often enough the type fix takes 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 the type less specific. An any, a cast, a non-null assertion, a generic loosened one parameter at a time. All of those compile, and each moves a check out of the build and into an incident later.

So read the type edits before the logic edits. In practice that means scanning the diff for places where a signature got wider rather than places where behaviour changed, which is, I think, roughly the opposite of how most people read a pull request. The widened signature is the edit that outlives the ticket, because the next person to touch that function reads its type as a promise about what it accepts.

None of this is unique to agent-written code, honestly. It is that an agent produces it faster than review habits were built to catch.

Write the boundary down where the package lives. Cursor reads nested AGENTS.md files from any subdirectory and applies them automatically to files in that directory and its children, combining them with the parent instructions so the more specific file takes precedence. A package that must not import from a sibling can say so in its own AGENTS.md, rather than in a root file trying to describe every package at once.

Get the extension right before writing the rule at all. A plain .md file inside .cursor/rules is ignored, since it carries no frontmatter to hold description, globs and alwaysApply. Use .mdc, or use AGENTS.md and skip frontmatter altogether.

For a typing convention you want enforced rather than merely considered, reach for globs over a description. With alwaysApply: false and globs provided, the rule auto-attaches whenever a matching file is in context. With a description and no globs, the agent reads that description and decides for itself whether the rule applies. globs: ["**/*.ts", "**/*.tsx"] is the difference between a convention and a suggestion.

The temptation is to scope the check to the package you touched. Actually, the check that decides it is the one on the dependent. A package that compiles in isolation and breaks its consumers is the standard monorepo failure, and it is the one an agent reports as finished, because from inside the package it genuinely is. Run the dependent's build before you believe the result.

Hooks cover the mechanical half of this. They live in hooks.json, afterFileEdit fires once a file has been written, and running formatters after edits is one of the documented uses, so the diff you sit down to read is at least not half-formatted.