Working with Coding Agents

My favorite coworker never sleeps

I use coding agents every day, and I will say the quiet part loud: the difference between a magical experience and a frustrating one is almost never the model. It is how you work with the agent. People who complain that “AI coding does not work” are usually handing the agent a vague task, no context, and then merging whatever comes back. This article is the workflow I wish someone had given me on day one.

A coding agent is an AI that works inside your project: it can read your files, search through them, edit them, and run commands like your test suite. You are not chatting with it — you are supervising it. That is why this article is mostly about how you behave, not about which model you pick.

Words you will see

Give it context before it asks

An agent knows nothing about your project until it reads something. You can let it discover everything by grep — slow and noisy — or you can write the important things down in an AGENTS.md or CLAUDE.md file at the repo root.

Think of that file as a short note to the AI about your project — the same note you would leave for a new colleague on day one: what this project is, which commands to run, which rules to follow. The agent reads it automatically at the start of every session, before you type a word.

1# Project
2 
3Task manager API. TypeScript, Fastify, Postgres, Vitest.
4 
5## Commands
6 
7- npm run dev - start dev server
8- npm test - run tests (always run before finishing)
9- npx tsc --noEmit - typecheck
10 
11## Conventions
12 
13- Routes in src/routes, one file per resource
14- All handlers validate input with zod schemas
15- Soft delete only: set deletedAt, never DELETE rows
16- Tests: describe blocks named after the route

Three things go in: commands (npm test), conventions (where files live, how to name things), and hard rules (never delete rows, always validate input). Three things stay out: history, philosophy, and anything you would not defend in code review.

That file took me ten minutes to write and saves the agent (and me) from rediscovering the conventions in every session. Keep it short — every line competes for attention, so put commands and rules in, philosophy out.

Small, well-scoped tasks

The single biggest lever. “Add authentication to the app” produces a big, hard-to-review blob. “Add a login endpoint that validates an email and password against the users table, with tests” produces something you can actually check.

My habit is to write the task as if leaving a note for a new colleague on their first day: name the files, name the pattern to follow, name how to verify. If I cannot describe the task in a few sentences, I split it first.

Review every diff. Every one.

A diff is just the list of changes: lines added, lines removed, lines edited — the thing you scroll through before clicking “merge”.

This is where enthusiasm meets discipline: you must read every change the agent makes. Not skim — read. Agents write plausible code, and plausible is not the bar; correct is. I review agent diffs the same way I review a junior developer’s pull request, with one difference: I am faster to reject and re-prompt, because regenerating is cheaper than arguing with a diff.

Tests are what make this scale. If the repo has a good test suite, I can trust the green checkmark a lot more — and focus my review on the things tests do not cover: edge cases, security, design.

Git is your safety net

Working with agents changed how I feel about git. Small commits, one logical change each, are what let me experiment freely: if an agent goes down a bad path, I do not untangle it — I reset and re-prompt with what I learned. Ask the agent to commit after each completed sub-task. A clean git history is also context: the next session can read it.

A prompt pattern that works

After hundreds of sessions, my most reliable pattern is three phases:

1. Explore. “Read the relevant files and explain how X currently works. Do not write code yet.” You get a plan-shaped answer and can correct the agent’s understanding while it is still cheap.
2. Plan. “Propose an implementation plan. List the files you will touch.” Small plans get approved, big plans get split.
3. Implement. “Do step 1 of the plan. Run the tests when done.”

For small tasks this collapses into one message — explore implicitly, then act. For anything touching three or more files, I insist on the split.

Your first prompt, ready to paste

Here is the whole pattern as one message. Swap the task and the file names for yours, paste it into your agent, and you will feel the difference immediately:

You are a senior engineer working in this repo.

TASK: add a POST /login endpoint that validates email and password
against the users table, with tests.

CONTEXT:
- Follow the pattern in src/routes/auth.ts
- Validate input with a zod schema
- Only soft delete: set deletedAt, never DELETE rows

BEFORE WRITING ANY CODE:
1. Read the files you need and explain how login works today.
2. Propose a short plan and list the files you will touch.
Wait for my approval. Do not write code yet.

WHEN I APPROVE:
- Implement step by step.
- Run: npm test
- Fix failures yourself, then run the tests again.

FINALLY: summarize what you changed and what you did not touch.

What the agent actually sees

One mental model ties all of this together: everything the agent does — every file it reads, every test run — lands in its context window. That window is finite: it is the agent’s working memory for this session, and once it fills up, the oldest turns get compressed.

Here is a session, played out step by step. Press play and watch the bar:

Two lessons from this picture. First, file reads and test output dominate — which is why scoped tasks matter: fewer files read, less budget burned. Second, long sessions eventually need compaction: older turns get summarized so the session can continue. Tick “simulate context compaction” under the bar: what stays is what you want present after compaction — your conventions, the task, the key files, the plan, the final diff and the green test run. The detours and the noise drop out.

When not to delegate

Some things I still do by hand, and I think you should too:

• Design decisions. Naming, architecture, data modeling — the thinking that is the actual work. An agent can list options; you must choose.
• New domains you are learning. If you delegate it, you learn nothing. Type the code yourself when the goal is your own skill.
• Security-critical code. Auth, crypto, payments. The agent drafts, you verify every line against a checklist — or better, against a specialist.
• Vague tasks. “Make it better” is not a task. If you cannot say how to verify success, the agent cannot either.

Check yourself

Your takeaway

If you change one thing after reading this, make it the order:

1. Spend ten minutes on AGENTS.md today. Commands, conventions, hard rules. It pays for itself in the first session and compounds every session after that.
2. Shrink the next task until it fits in three sentences. Name the file, the pattern to follow and the command that proves it works.
3. Review before you run. Read the diff, then run it yourself. Green tests are evidence, not permission.
4. Commit after every completed step. Small checkpoints turn “the agent went wrong” from a rescue operation into a two-second rollback.

Do these four and the agent stops being a slot machine and starts being the coworker the title promises.