AI-Assisted Development > AI-assisted coding > Agentic coding tool workflow
What This Covers
This scenario covers designing a workflow for using agentic coding tools on multi-file codebase changes. The focus is on how you scope delegation, review generated edits, and decide what safeguards are needed when local correctness may not fully establish system correctness.
The System
Current State
- The engineering org has a 420k-line TypeScript/Python monorepo with 38 services, 120 shared packages, and roughly 900 active test files.
- Developers already use AI coding assistants for small edits, test generation, refactors within a single package, and documentation updates.
- Larger changes still go through human-led implementation because reviewers report that agent-generated diffs above roughly 15 files become difficult to reason about.
- CI includes unit tests, type checks, linting, contract tests for 11 services, and a nightly integration suite that runs against a staging-like environment.
Proposed Change
- The team wants to introduce an approved workflow for delegating larger tasks to an agentic coding tool, including scoped prompts, repository indexing, automated test selection, and structured human review.
- The initial target is “contained” multi-file work: SDK migrations, API response shape updates, schema-adjacent refactors, and internal library upgrades.
- The goal is to reduce implementation time by 30–40% without increasing review burden or creating codebase navigation problems.
Worked Example: Design Tradeoff
In a previous project, the team considered using AI to scaffold new internal services from a short product spec. The proposed approach was attractive: an engineer could describe the endpoint set, data model, and ownership metadata, and the tool would generate controllers, auth hooks, config, tests, and deployment manifests.
During design review, the team noticed that the generated services were usually runnable, but not always aligned with current platform conventions. Some scaffolds used an older middleware chain, config keys from a prior deployment system, and an auth helper that still existed in the repository but was no longer the preferred path for new services. None of these choices looked obviously broken in isolation; they were plausible because the codebase still contained historical examples.
The team adjusted the design rather than banning the workflow. They created a service template package as the only allowed starting point, added a short “current conventions” file that the tool had to reference, and required review against a checklist covering auth, config, observability, and deployment ownership. The important design lesson was that “the code runs” was not the same as “the code matches the organization’s current operating model.”
The Design Question
The team now wants to expand from scaffolding and small edits to agent-led multi-file changes across existing code. How should they design the workflow so the tool can move fast on broad changes while still giving humans enough leverage to catch issues that only emerge from relationships between files, modules, or runtime configuration?
There is no single correct policy. You might argue for strict task boundaries, stronger automated checks, staged rollout, deeper repository context, narrower approved use cases, or a combination of these.
Anchor Data
Results from a four-week pilot using the proposed workflow on 52 completed pull requests:
| Task Type | PRs | Median Files Changed | Median Human Impl. Time Avoided | CI Pass Rate Before Human Edits | Reviewer Time vs Similar Manual PRs | Post-Merge Follow-up PRs Within 14 Days |
|---|---|---|---|---|---|---|
| Test expansion | 12 | 7 | 2.1 hrs | 92% | -18% | 1 |
| Internal SDK migration | 11 | 19 | 5.4 hrs | 82% | +6% | 2 |
| API response shape update | 9 | 23 | 6.2 hrs | 78% | +14% | 3 |
| Shared utility refactor | 8 | 16 | 4.7 hrs | 88% | +3% | 1 |
| Config/schema-adjacent change | 7 | 21 | 5.9 hrs | 71% | +22% | 3 |
| Documentation-linked code cleanup | 5 | 11 | 3.0 hrs | 96% | -9% | 0 |
Additional pilot notes: 46 of 52 PRs merged within two business days; 39 required fewer than 30 lines of human edits after the agent’s first draft; all merged PRs passed required CI.
Current Observations
- Engineers like the workflow most when the task can be described as “apply this change everywhere this pattern appears.”
- Reviewers say the diffs are usually easy to read file-by-file, but harder to validate as a coordinated system change once more than two packages are involved.
- The nightly integration suite covered only 18 of the 52 pilot PRs before merge; the rest relied on targeted CI plus reviewer judgment.
- Several follow-up PRs were described as “cleanup,” “alignment,” or “missed related update,” rather than urgent fixes.
Constraints
- Leadership wants a recommendation within three weeks so the workflow can be included in next quarter’s engineering productivity plan.
- Platform wants broad adoption, but service owners want the ability to opt out for sensitive areas such as billing, auth, and data modeling.
- The team can add lightweight automation quickly, but deeper CI or repository analysis work would need to compete with planned reliability projects.
What You’ll Be Evaluated On
- Tradeoffs: How well you identify competing concerns and justify your choices.
- Gaps: Whether you find what is missing in the data or proposal.
- Prevention: Whether you anticipate what could go wrong and propose safeguards.
- Clarity: Whether your recommendation is understandable and actionable.
- Prioritization: Whether you focus on the highest-leverage risks and decisions.
- Reasoning quality: Whether your conclusions follow from the evidence and constraints.