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.
No comments yet.