What you need to know
The value of AI-assisted development comes from improving the workflow a team already has, not from bolting a chat window beside it. The architect's job is to put assistance where it helps and to keep the quality bar where it was.
Where assistance fits
| Stage | How Claude helps | What still needs a person |
|---|---|---|
| Understanding | Exploring an unfamiliar codebase, explaining code, tracing a flow | Judging whether the explanation is right |
| Planning | Proposing an approach and the files to change, before any edit | Approving the plan |
| Writing | Implementations, tests, boilerplate, refactors from a clear specification | Correctness, security and design review |
| Reviewing | Summarizing a diff, flagging likely issues, checking conventions in CI | The decision to merge |
| Debugging | Hypotheses from symptoms, logs and traces | Confirming the hypothesis against evidence |
Practices that make the output better
- Explore, then plan, then code. Asking Claude to read the relevant code and propose a plan before editing produces better changes than asking for code straight away. A read-only planning mode helps.
- Give it a way to check itself. Tests, a build, a linter, a screenshot to compare against: when Claude can run the check, it can find and fix its own mistakes before a person sees them.
- Small, reviewable changes. Large AI-generated diffs are hard to review well. Break work into steps a reviewer can actually read.
- Parallel sessions for independent work, each in its own working copy (for example git worktrees), so tasks do not interfere.
- Automation in CI. Running Claude non-interactively with structured output lets it review pull requests, triage failures or update documentation as pipeline steps, with deterministic checks (hooks, tests) around it.
The verification discipline
AI makes code cheaper to produce, so more of it reaches review. The bar does not move. A team checklist for any AI-assisted change covers:
| Dimension | The change passes when |
|---|---|
| Correctness | Tests cover the requirement and its edge cases, and they pass |
| Security | No secrets, inputs validated, least-privilege access for any new calls |
| Maintainability | It follows team conventions and introduces no unexplained complexity |
| Understanding | The author can explain what it does, why, and how it handles inputs no test covered |
The risk the last row guards against is judgment erosion: a team that ships code it no longer understands because it looked right and passed shallow checks, until an input nobody reasoned about reaches production.
Measuring the effect
Track workflow outcomes, not just usage: pull request cycle time, review rework, escaped defects, time spent on toil. A tool that speeds up writing but slows down review, or raises defects, has not improved the workflow.
In the exam
Workflow questions describe a team using AI tooling and a problem: low quality, slow reviews, unclear ownership, uneven use. Strong answers place assistance at the right stage, give Claude a way to verify its work, keep changes reviewable, keep humans accountable with a verification checklist, and measure workflow outcomes rather than usage.
Check your understanding
Claude's changes to a service often compile but break behaviour elsewhere. What change helps Claude most?
Show answer
Answer: B. When Claude can run the checks, it can catch and correct its own mistakes. Instructions and explanations do not give it that feedback.
A team merges AI-generated pull requests once CI passes and an AI reviewer approves. What is missing?
Show answer
Answer: A. Human understanding and accountability are the guard against judgment erosion. More automation of the same kind does not add it.
Which TWO practices make AI-assisted changes easier to review well?
Show answer
Answer: A, B. Plans and small changes keep reviews meaningful. Large combined diffs and skipped tests make problems easier to miss.
Apply it: Improve Quillstone's pull request workflow
Quillstone's median pull request cycle time is 26 hours. Three months into the pilot, champions report: AI-assisted pull requests are larger, reviewers struggle with them, and two recent incidents came from generated code that "looked fine" and that the author could not later explain.
- Redesign the workflow from task to merge, showing where Claude helps and where people decide.
- Write Quillstone's verification checklist for AI-assisted changes, with one concrete check per dimension.
Done when: the understanding check would have caught the two incidents. - Choose three measures to show whether the changes worked.
Show model answer
1. Workflow
- Engineer asks Claude to explore the relevant code and propose a plan (read-only planning). Engineer approves or edits the plan.
- Claude implements in small steps, running tests and the linter itself; the secrets hook blocks any commit with credentials.
- Engineer reviews the diff locally and annotates anything non-obvious.
- Pull request opened, kept under an agreed size; the CI review bot (lesson 3.1) adds comments.
- A human reviewer decides; the author answers review questions themselves.
2. Verification checklist
| Dimension | Check |
|---|---|
| Correctness | New behaviour has tests, including at least one failure or edge case, and all tests pass |
| Security | No secrets (hook passes); new inputs validated; new calls use existing scoped credentials |
| Maintainability | Follows the service's conventions; no new dependency or abstraction without a reason in the description |
| Understanding | The description explains in the author's words what changed and why, and how it behaves on an input the tests do not cover; the reviewer may ask the author to walk through any generated section |
3. Measures. Median pull request cycle time and review time per pull request; pull request size distribution; incidents and reverts traced to AI-assisted changes.