#コードレビュー

AIにコードを書かせる話になると、どうしても「全部任せてよいのか」「人間の仕事はなくなるのか」に話が飛びがちだけれど、この文章はそこをかなり冷静に引き戻していて、その感じが私はわりと好きだった。Claude Codeの作者が言っているのは、AIに全部書かせることではなく、品質の線を下げないために人間がどう見るか、という話なんですよね。そこがはっきりしているのは大事だと思う。 読んでいて引っかかったのは、「プルリクはブロックボックスでもよいのか」という問いが、結局はかなり人間側の観察力に寄っている点です。AIが出したコードを全部読む必要はない、でもどこかで「これは本当に大丈夫か」を判断しないといけない。その判断を支えるために、lint、テスト、レビュー、ガードレールを重ねる。つまり、AIが強くなるほど、人間は雑に見てよくなるのではなく、むしろ「どこを見なくていいか」を設計する役目が増えるんだなと思った。 あと、Claude Codeが「新しいモデルを入れたら終わり」ではなく、effort設定や CLAUDE.md みたいな周辺の仕組みまで含めて考えているのが面白い。AIの性能だけで勝負す

AIにコードを書かせるのは珍しくなくなったが、その結果として「なぜそうなったのか」が見えにくくなっている。devdotfast/whiteboard は、その穴を埋めようとするオープンソースのデスクトップアプリだ。単なる図解ツールではなく、AIエージェントの作業内容や判断を、コードと行き来しながら追える作業台として作られている。GitHub上の公開リポジトリとして出てきたことで、こうした“説明できる開発”をどう実装するのかが一気に見えやすくなった。 元記事で示されている Whiteboard は、「thoughtful software design」のための open-source canvas だと説明されている。対象は開発者だけではなく、人間とエージェントが同じワークスペースでソフトウェアを組み立てる使い方だ。macOS と Fedora 向けのダウンロード、Webサイト、Discord への導線もあり、README だけの試作ではなく、実際に触る前提のプロダクトとして見せている。 中心にあるのは、Claude Code や Codex など既存の coding agent とつ

この記事を読んでまず思ったのは、AIエージェントそのものより、周辺の作法をどこまで先に決めておけるかで体験がかなり変わりそうだ、ということでした。Claude Codeみたいなツールは、単に「賢い補助輪」ではなく、チームのルールを食べて動く存在に近いのだと思います。 とくに引っかかったのは、AIにコードを書かせるときの不安が、もう「正しいかどうか」だけでは済まない点です。記事でも触れられていたように、`CLAUDE.md` や rule file、Auto Memory みたいな仕組みで、まず前提を揃える必要がある。これって結局、AIを入れるほどドキュメントの価値が上がる、ということでもあります。人間同士なら多少の暗黙知で回っていた現場が、AIを挟むと暗黙知のままでは回らない。そこは少し面倒だけど、逆に言えば、属人化した開発を見直すいいきっかけにもなりそうです。 もう一つ面白かったのは、AIに丸投げする話ではなく、PR作成やコード変更の入り口をどう設計するかに話が寄っていたところです。私はここにかなり現実味を感じました。AIがコードを全部「自動でよしなに」やってくれる未来より、変更範囲

読んでまず思ったのは、「ああ、これはかなり地味だけど本当に効くやつだな」ということだった。MCP server の話ではあるけれど、実際にはどんな申請制の審査にもそのまま刺さる感覚がある。動くかどうかより、「審査する側に何が見える状態で出すか」のほうがずっと厄介なんだよな、と改めて思った。 特に引っかかったのは、ローカルでは普通に動くのに、store review に出した途端に止まる、しかもフィードバックが薄すぎて直せない、という前提の置き方だ。これ、開発者からするとかなり消耗する。バグがあるならまだしも、「何を直せばいいのか分からない」というのは、技術というより運用の問題に見える。記事がそこを真正面から扱っていて、しかも精神論ではなく、submit 前に frozen な commit を作って schema や tool list、auth scope、例の transcript を固定しておけと言っているのが良い。 僕はこの手の話で、CI を通したら安心してしまう瞬間がある。でもこの記事の感覚だと、CI は合格証ではなく、せいぜい「自分たちの手元では壊れていません」の証明にすぎ

この記事を読んでまず思ったのは、Claude Code の責任者がかなり率直に「雑に使っていい場面」と「雑に使ってはいけない場面」を分けているのが、かえって現実的だということだった。AIコード生成の議論って、つい「使うか使わないか」の二択に寄りがちだけれど、実際にはそんなにきれいに割り切れない。捨てる前提の prototype と、後で何人も触る production code を同じ目線で扱えないのは当然で、そこを曖昧にしないのは好感が持てた。 一方で、読んでいて少し引っかかったのは、結局「品質の番人」を人間がやるしかない、という点がかなり強く残るところだ。AI がコードを書くほど、レビューする側の負担は軽くなるどころか、むしろ「何が混ざっているかを見抜く目」が必要になる。Cherny が挙げていた lint rules や tests、automated code reviews みたいな仕組みは、たしかに筋がいい。でもそれって、裏返すと、そういう足場を先にちゃんと作れないチームでは AI の便利さがそのまま“slop”に変わる、ということでもあると思う。 あと面白かったのは、彼の

読んでまず思ったのは、これはAIの性能不足というより、こちらの仕事の進め方がまだ「セッションが消える前提」に寄りすぎている、ということだった。 AI coding agent は毎回新しい相手みたいな顔で出てくる。昨日まで何度も話した設計の前提を、今日また説明し直す。あれはたしかに面倒だし、地味に判断の質も落ちると思う。 この記事で面白かったのは、記憶を“賢く”持たせるというより、決めたことをコードの近くに置いてしまう発想だった。`docs/` の中に facts, decisions, guardrails, skills を分けて、しかも Git で履歴を残す。AI の記憶力に期待するのではなく、「次に読むべきものが、毎回ちゃんとそこにある」状態を作る。かなり実務的だし、むしろ人間にも効くやり方だと思う。 ただ、そこまでやっても万能ではない、とはっきり書いているのも好感が持てた。結局のところ、最初の聞き取りも更新も人間がやる。つまり“記憶の自動化”というより、“忘れにくい手続き化”に近い。ここを神話っぽく盛らずに、更新されなければただの `docs/` フォルダになる、と言い切って

開発者の laptop から agent を引き剥がして、クラウド側に寄せる。理屈としてはかなり筋がいいのに、実際にここまで踏み込んで運用している会社はまだ多くない気がする。この記事でいちばん引っかかったのは、130,000 tasks という数字そのものより、そこに付いている「監視・権限・監査」をちゃんと平台として作り込んでいる点だった。 ローカル実行の弱点は、たしかにわかりやすい。developer のマシンが起動している前提だし、CPU や memory にも限界がある。何より、agent に credentials や internal system へのアクセスを渡すとき、誰の責任でどこまで触ったのかが見えにくい。便利さの裏で、運用の泥臭さが一気に増える。DoorDash はそこを「各人の工夫」ではなく、Firecracker microVM、MCP gateway、playbook、invocation surface という部品に分けて制御している。ここはかなり好きな設計だと思う。agent を賢くするより先に、暴れない形に閉じ込めているからだ。 一方で、少し気になるのは

まず思ったのは、これはかなり小さい話に見えて、実はかなり大きい問題だということです。 `AGENTS.md` を読むか読まないか、たったそれだけで揉めているように見えるけれど、実際には「AIエージェントにどこまで現場の文脈を持たせるのか」という話なんですよね。 Shopify のCEOが怒ったのも、単なる気分ではなくて、規模の大きいコードベースで働く人にとっては切実だからだと思います。人間の開発者なら、リポジトリの説明ファイルやチームのローカルルールを見てから作業するのは当たり前に近い。でも Claude Code のようなツールがそこを読まないと、毎回「このツールには手順を口頭で教え直す」ことになる。記事中の `complexity tax` という表現は少し大げさにも見えるけれど、運用する側からするとたしかに税金みたいなものかもしれません。便利さのはずが、使うほど説明コストが増えるのはいやな感じです。 もうひとつ引っかかったのは、Anthropic 側がその要望をすでに閉じていた、という点です。ユーザー側の不満がはっきり出ているのに、製品の設計として優先されていない。このズレは、A

正直、これは「AIでコードを書く」話というより、「AIの作業の見える化」を本気でやりにきたんだな、という印象だった。 Slackにエージェントを呼ぶだけなら、もう似た仕組みはある。でもこの記事で気になったのは、会話の流れをそのままタスクの場にして、差分やプレビューまで同じ場所で追えるようにしている点だ。AIに仕事を投げっぱなしにしない設計になっているのが面白い。 ここで少し腑に落ちたのは、AIエージェントの導入で本当に厄介なのは「賢さ」より「いつ、誰が、どこで止めるか」だったんだろうということ。コードを書けるだけならデモは派手でも、実運用では怖い。特に本番への反映は、人間の承認を挟むと明記しているのは当然に見えるけれど、逆に言うとそこを外すと一気に危うくなる。便利さと統制の綱引きが、かなり露骨に見える。 一方で、Slack自体がこういう“AIの作業場”になっていくのは、かなり自然でもあると思った。開発の文脈って、コードだけじゃなくて「このバグ、誰が見つけたか」「どの画面の話か」「さっきの会話で何を決めたか」が混ざっている。そこを別のツールに飛ばさず、チャットの中で完結させようとするのは

この記事を読んでまず思ったのは、「やっとそこまで来たか」という感覚だった。 セキュリティの設計書や threat model は作った瞬間がいちばん元気で、実装やレビューの段階になると急に遠い存在になる。現場ではありがちな話だけれど、そこを「後で読む資料」ではなく、PR を見る場に引っ張ってくる発想はかなり筋がいいと思う。 面白いのは、Dropbox がやっているのが単なる検索強化ではないことだ。Dash で社内文書を引けるようにして、MCP で AI からその文脈を取りにいけるようにする。ここまでは「便利そう」で終わる。でも本当に効くのは、レビュー中に「この変更は、あの設計時に決めた security requirement とズレていないか」を見にいける点だと思う。 コードを見ている人間は、つい実装の良し悪しに寄りがちだ。けれど security は、コード単体のきれいさより「元の意図が守られているか」が大事なことが多い。そこを毎回、人の記憶と根性で追いかけるのはしんどいし、抜けも出る。 ただ、ここで少し引っかかったのは、これが「判断を自動化する仕組み」ではないと明言している点でも

Claude CodeやCodexのような coding agent は、もう「ちょっと試す便利ツール」ではなくなってきました。この記事の著者 Eivind Kjosbakken は、そこをかなり強気に押し出しています。ポイントは、人間が細かく介入しなくても、エージェントが長時間動き続ける状態を作ること。これができると、並列でより多くの仕事を回せるようになる、という考え方です。 正直、ここはかなり面白い視点だと思いました。 昔は「AIにコードを書かせる」こと自体が新鮮でしたが、今はもう少し先に進んでいて、AIを“どれだけ止めずに働かせられるか” が生産性を左右する段階に入ってきている、という話です。この記事はその現実的な運用論を書いています。 coding agent は、短時間で終わらせるより「長く走り続ける」ほうが価値が出る ボトルネックは実装そのものより、人間のレビュー時間になりつつある 権限を細かく止めないことで、無駄な中断を減らせる agent 自身にテストや確認をさせると、人間の確認コストが下がる コードレビューまで agent に寄せると、さらに回転率が上

ClaudeがClaude Codeに追加した「dynamic workflows」は、ひと言でいうと、ひとつのAIに全部やらせるのではなく、たくさんの小さなAI作業を同時並行で走らせて、最後にまとめて点検する仕組みです。Anthropicはこれを、特に大きくてややこしい仕事向けに出してきました。 個人的にかなり面白いと思ったのは、単なる「速くなる機能」ではなく、AIの使い方そのものを変えようとしているところです。雑に答えを出すのではなく、途中で反証させたり、別の角度から検証させたりして、最終的に人の前に出す前にチェックを重ねる。ここがいちばん“らしい”進化だと感じます。 Claude Codeで、複数のsubagentを並列に動かす「dynamic workflows」が使えるようになった ひとつのAgentが順番に考えるのではなく、10〜100単位の並列作業で大きな問題を分解する バグ探し、セキュリティ監査、大規模な移行作業、仕様のレビューのような仕事に向いている 実行前に確認が入り、途中結果もチェックされるので、最終結果の信頼性を上げる設計になって

著者は、AI coding を使っていると「人間なら即クビ」レベルの妙な挙動に何度も遭遇したが、それでも利用をやめるどころか、さらに使い込むようになった。 この記事の中心テーマは、AI にコードを書かせるときは code review 以上に test process が大事 だ、という主張。 その根拠として、著者は昔働いていた CPU 設計会社 Centaur のテスト文化を紹介する。そこでは、手書きテストより fuzzing や random testing を重視し、unit test はほぼ使わず、専任の test engineer がいた。 著者は、AI 時代の開発でも「人間が全部レビューする」より、「大量の自動テストで叩く」ほうが現実的で、しかも強いと考えている。 ただし、これは単なる理想論ではなく、実際にバグを見つけて直してきた現場の感覚から来ている。 本文を読んでまず面白いのは、著者の出発点がかなり変わっていることです。AI coding を「便利な補助輪」ではなく、かなり攻めた実験装置として見ています。しかも、その最初の印象がすごい。バ