---
id: "lib-2026-10-21-ai-writes-reviews-and-qas-i-started-thinking-of"
type: "library"
title: "AI writes, reviews and QAs; I started thinking of my role as director"
title_original: "AI が書き、レビューし、QA する開発で、私は「監督」の役割を考え始めた"
lang: "JA"
org: "LayerX"
source_type: "Practitioner post"
date: "2026-10-21"
week: "2026-W43"
url: "https://nosov.ai/library/lib-2026-10-21-ai-writes-reviews-and-qas-i-started-thinking-of/"
original_url: "https://tech.layerx.co.jp/entry/engineer-as-director"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "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_basis: "full-text"
original_minutes: "8"
tags: ["coding agents", "ai code review", "qa", "failure modes"]
frames: ["verification-capacity"]
---

# AI writes, reviews and QAs; I started thinking of my role as director

Original title: AI が書き、レビューし、QA する開発で、私は「監督」の役割を考え始めた

Tier 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.

## 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

- 211: PRs the author created and merged to main in 16 business days (24 Sep to 16 Oct 2026)
- ~36 min: average interval between merged PRs over an 8-hour day
- ~90%: share of those PRs still approved by a colleague before merge
- 7: bugs the devqa skill caught before release in nine days in early October
- 6: AI reviewers (3 reviewers, 3 verifiers) that reviewed code without any of the author's changes

## 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) and `devqa` (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.
- `ship` must 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 --stat` after 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

> 私はコードを 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.

> レビュアー 3 体と検証役 3 体は、私の変更が 1 行も入っていないコードを読んで、もっともらしい結果を返してきた。

Three reviewer agents and three verifier agents read code without a single line of my changes and returned plausible-looking results.

> それでも、何かあったら責任を取るのは私になる。

Even so, if something goes wrong, I am the one who takes responsibility.

Original: https://tech.layerx.co.jp/entry/engineer-as-director