AI writes, reviews and QAs; I started thinking of my role as director
AI が書き、レビューし、QA する開発で、私は「監督」の役割を考え始めた
B · Useful, limited First-person account from a LayerX engineer with concrete throughput and failure details; candid and specific, but one person's self-reported workflow with no team-level quality data.
Summary based on the full text·Original: about 8 minutes to read
In short
A LayerX engineering blog post (21 October 2026) by Hanake, an engineer on the Ai Workforce product. Tickets, implementation, review and dev-environment QA now run almost entirely through Claude Code skills, with Codex mixed in for cross-review. The author stopped reading code line by line and checks instead what the agents read, decided and committed, and how the result feels to use. Human approval and a QA team gate remain. The post describes two worktree failures that went unnoticed because nobody looked at the diff.
Key numbers
- 211PRs the author created and merged to main in 16 business days (24 Sep to 16 Oct 2026)
- ~36 minaverage interval between merged PRs over an 8-hour day
- ~90%share of those PRs still approved by a colleague before merge
- 7bugs the devqa skill caught before release in nine days in early October
- 6AI reviewers (3 reviewers, 3 verifiers) that reviewed code without any of the author's changes
As reported by the source.
Japanese·Web page·opens tech.layerx.co.jp
What it reports
- Four skills:
ship(ticket to merge, including CI fixes and replies to review comments),plan-checker(design review by other agents before risky work such as migrations or auth changes),pr-checker(parallel review by aspect, with a second agent challenging each finding) anddevqa(runs QA scenarios in the dev environment and files bugs). - Up to 10 agent sessions run in parallel tmux panes; about 13 PRs a day.
- 211 PRs merged in 16 business days. Two years ago one merged PR a day marked a fast engineer.
- About 90% of PRs get a colleague's approval; the remaining ~10% skip human approval when they meet team conditions, pass contract checks and are judged low-impact by AI review. The QA team checks before production release.
shipmust stop and return to the product manager when acceptance criteria cannot be met, the design conflicts, or customer-visible behaviour has no clear choice.- Failure 1: a file edited in a worktree landed in the main tree; the commit missed it and four more commits stacked on top before a test failed two hours later.
- Failure 2: a parallel session switched the main tree's branch, so six AI reviewers and verifiers returned plausible results on code containing none of the author's changes. The full review had to be redone.
- Fixes: long tasks get their own worktree from the start;
git show --statafter every commit.
How they got it
Self-observation by one engineer over about three weeks, with PR counts from the repository and anecdotes from the team. The post cites Addy Osmani and Dex Horthy on "dark" and "lit" software factories for context.
Limits
- One engineer, one product area; the author says it is not a recommendation for other teams.
- No defect, incident or rework rates; PR counts measure throughput only.
- Review load shifts to colleagues, who also rely on AI pre-review, so the human check may be thinner than the 90% suggests.
- The claim that Claude Opus 5.5 often writes better code than the author is a personal judgement.
Why it matters for companies
The useful detail is where the control moves once code is no longer read: to the diff metadata, the agent's stated decisions and hands-on testing of the product. The two failures show that parallel agents add environment errors (wrong branch, wrong tree) that AI review cannot catch, because the reviewers only check the code they are given. Teams scaling agent-written code should require a "what was decided and checked" record on each PR and decide explicitly which changes may skip human approval.
Key passages in translation
Japanese original
私はコードを 1 行ずつは読まない。代わりに、AI が何を確かめて何を commit したかと、出来上がったものを見ている。
I don't read the code line by line. Instead I look at what the AI checked, what it committed, and what got built.
Japanese original
レビュアー 3 体と検証役 3 体は、私の変更が 1 行も入っていないコードを読んで、もっともらしい結果を返してきた。
Three reviewer agents and three verifier agents read code without a single line of my changes and returned plausible-looking results.
Japanese original
それでも、何かあったら責任を取るのは私になる。
Even so, if something goes wrong, I am the one who takes responsibility.
Summary based on the full text. Read the original for the full argument and data.Read the original on tech.layerx.co.jp
- Tags
- Coding agents