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.