Humans review only the design doc: rebuilding a bug-fix team's flow with AI-DLC
人間が見るのは設計書だけ ― PdM不在・バグ修正中心のチームで、AI-DLCを開発フローごと作り直した話
A · Strong evidence Canly engineer documents an 11-skill Claude Code workflow for a two-person maintenance team with before-and-after figures from Jira and git, including a result that went the wrong way; small team, but method shown and numbers checkable.
Summary based on the full text·Original: about 30 minutes to read
In short
A Zenn post from Canly (28 October 2026) by the lead engineer on Tostore, a store-listing management product in maintenance ahead of a merger into the company's main product. After an internal AI-DLC workshop in April, he found its mob format, built around a product manager, did not fit a team of two full-time engineers with no product manager and mostly bug fixes. He rebuilt the flow as 11 Claude Code skills. Humans now review only design documents; code is checked by an AI review bot and by running every test item. Record quality rose sharply. Time per ticket did not fall: median days to first merged PR rose from 7.6 to 10.9.
Key numbers
- about 360 to about 3,800 charactersmedian length of bug-ticket descriptions, before (Oct 2025-Mar 2026) versus after (Jun-Sep 2026)
- 0/25 to 28/53bug tickets stating a fix policy, before versus after
- almost 0% to 96-99%share of commit subjects carrying a ticket number (from August)
- 7.6 to 10.9 daysmedian days from bug ticket to first merged PR, before versus after
- 6 of 53post-adoption bugs traced to an earlier fix (regressions), each linked to its source ticket
As reported by the source.
Japanese·Web page·opens zenn.dev
What it reports
- Bug fixes fit AI-DLC by treating the expected behaviour as the intent and splitting cause investigation into its own read-only skill (
incident-triage) before intent. - Skills grew in three stages: 6 in late May (intent to review), entry, triage and PR in July, ticketing and QA support in August. He ran the flow by hand first, had the AI derive the skills from the outputs, used them alone in April-May, then shared them.
- A single entry skill (
start) sets up the branch, offers a light lane for small fixes with explicit criteria, and resumes in-progress work by stating the next skill. Resume was the feature colleagues liked most. - Every skill names the next skill but does not call it, leaving a stop point. Every skill writes lessons back to itself on listed triggers (review fix, new path, same failure twice), committed through normal PR review.
- QA support makes people run every proposed test item, orders them into efficient scenarios, gives one instruction at a time and checks logs in the background. Colleagues say testing got heavier.
- PR flow: open with no human reviewer, iterate with the review bot until comments stop, test on final code, then assign a human to check only the spec.
- Before (6 months) versus after (4 months): tickets naming a cause 5/25 to 32/53; tickets listing rejected hypotheses 0/25 to 13/53; added test lines 557 to about 8,000. Bug tickets rose from 25 to 53, which he attributes to clearer causes, not more defects.
- 31 tickets have design documents since April; over 400 code comments carry ticket numbers. In a sample of 97 lines from core files, 89% traced by blame to old commits with no ticket number, so comments beat commit history for old code.
- Missed scope came from the design side: a term's definition silently excluded one posting path, so
unitsnow forces an in-scope and out-of-scope matrix.
How they got it
The author's own team practice, with skill excerpts and a before-and-after comparison drawn from Jira and git records. He states the limits of each metric in the post.
Limits
- Small samples (25 and 53 bug tickets) and unequal periods; release cycles affect lead time.
- Description length grew partly because the AI writes them; test lines are not coverage.
- Whether regressions fell cannot be measured, since old tickets are too sparse to count the same way.
- No guarantee on performance, rare error paths or authorisation gaps, which he names as a limit of skipping human code review.
- The "comments helped most" finding came from asking the AI, which he notes is self-report.
Why it matters for companies
Most AI-DLC accounts assume new features and a product manager in the room. This one shows the method adapted to maintenance work, and it reports the trade honestly: better records, traceability and tests in exchange for slower individual fixes and heavier testing. The skill design ideas transfer well: one entry point, explicit light-lane criteria, self-updating skills under review, and comment-level pointers from code to design documents. Human review effort moves to specifications, where the team's actual misses occurred.
Key passages in translation
Japanese original
人手を介すと、面倒な部分が静かに削られるという問題です。
The problem is that when work passes through people, the tedious parts quietly get cut.
Japanese original
一方で、1 件のタスクを片づける速さは、数字の上では上がっていません。
On the other hand, the speed of finishing a single task has not gone up in the numbers.
Japanese original
突き詰めると、変わったのは「設計をちゃんとやることを強制されるようになった」という一点だと思います。
In the end, I think the one thing that changed is that we are now forced to do design properly.
Summary based on the full text. Read the original for the full argument and data.Read the original on zenn.dev