The bounded process: agent-assisted coding I recently had a project owner ask me about my process using agent-assisted development. Here’s a tightened version of my response. Phase 1 I point Claude to the GitHub repo issue number and ask it to define a statement of work — a concept statement plus a task checklist. It analyzes the codebase and returns a series of tasks. I prefer small, well-bounded issues, especially when I’m new to the codebase. We work through the list until we have a first pass, then I walk through the code in VSCode. Phase 2 — Iteration Each cycle follows the same pattern: work order, my review, repeat. - Magic numbers or unwarranted assumptions? - DRY violations or multiple sources of truth? - Idiomatic naming for functions, variables, and constants? - Correct scoping throughout? - Stale, unnecessary, or inaccurate comments? - Is the uncommitted code well-structured? Phase 3 — Code Smells I ask Claude to hunt for code smells. Three passes minimum, four or five if I’m not satisfied. Same cycle as above. Phase 4 — Standards - Does the uncommitted code comply with the repo’s standards and practices? - Does the repo have PR submission guidance? Phase 5 — Submit PR Background I’m a retired developer, project manager, and exec. This process is essentially what I used with human developers for two decades. My background is mainly C#; I’ve been working with Rust for about a year. On agent-assisted coding generally: you have to put bumpers on the agent. Iterate, refactor, walk through the code. A tight regime produces good work. If you think otherwise about this process, I’d genuinely like to hear it. |