Working with AI Coding Agents
Context is king: a lean project brief, plan before edit, a fresh context per feature, reusable skills and tool connections, small PRs, separate feature and debugging modes, and verification rather than letting the agent rip.
🌱 A rough idea, planted recently. Expect rough edges — it will grow.
On this page
The mental model that works best for me: treat a coding agent like onboarding a junior engineer. Give it enough written context that you never have to repeat yourself, keep the tasks small, and check the output with tests rather than trusting it.
Habits that pay off
- Run it from the repo root, so it sees the whole project rather than a corner of it.
- Keep a project brief (a
CLAUDE.mdor equivalent) that documents the codebase for engineers and the agent. Keep it lean: everything in it costs tokens on every request. - Plan before you edit. Agree what you’re going to do in a planning mode before letting it touch files. Cheap to correct a plan, expensive to unpick a diff.
- Context engineering is the job. Connect the tools that fit the task (for example a design-tool connector for UI work), and leave the rest out.
- Clear the context when you start a new feature. Leftovers from the last task quietly bias the next one.
- Keep notes alongside the project: one short session entry per PR or sub-feature, and keep the features small.
- Prefer up-to-date docs and TODOs in the repo (ideally indexed) over having the agent scan the whole project every time.
- Turn anything you repeat into a reusable skill or command.
Provide enough context that it never needs repeating, exactly as you would for a new junior.
Feature mode vs debugging mode
These are separate modes, and mixing them in one session is where things go sideways.
- Feature mode: give the relevant context, name the frameworks, supply docs with explicit detail, make incremental changes, checkpoint and commit often.
- Debugging mode: first work out how things actually work; learn how to un-stick the model; feed it more information rather than repeating the same request.
Raising quality
Validation is the big topic if you want agentic workflows at all. Make sure tests get written, the code is documented, and the behaviour can be verified, rather than letting the AI rip. Architecture matters too: clear module boundaries and contracts make a codebase easier for an agent (and a human) to work in. I wrote more about verification in Don’t Read the Code? Verifying AI-Written Code.
How inline assistants gather context
Inline completion tools send context (file type, framework, adjacent open tabs) along with the prompt and complete using fill-in-the-middle: the model sees the code before and after the cursor. So keeping relevant files open genuinely improves suggestions, and closing unrelated ones reduces noise.
Related
Starting in an unfamiliar repo? Baseline its health first: First Week in a New Codebase. Splitting the work into reviewable pieces: Slicing Pull Requests. The platform view: Agentic Development Platforms.
- #ai
- #coding-agents
- #context-engineering
- #claude-code
- #ways-of-working
↩ Linked from (2)
It's a good first task to hand to a coding agent too, as long as you check what it reports (Working with AI Coding Agents). Once you start changing things, keep the changes small: Slicing Pull Requests.
…It suits coding agents well: one PR per sub-feature, each with its own fresh context and short session notes (Working with AI Coding Agents). It pairs nicely with Git Worktrees: A Desk per Branch when several slices are…
↪ Links to (4)
Related by topic
- Seedcase study
Cutting CI Feedback Time with Checkpoint Restarts
Developer tooling - Seed
Platform Adoption - Business Case and Rollout Rhythms
Platform engineering - Seed
Strategic vs Tactical Platform Design
Platform engineering - Growing
Where Platforms Fit: DDD Subdomains
Platform engineering