#コードレビュー

読んでまず思ったのは、これは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 を「便利な補助輪」ではなく、かなり攻めた実験装置として見ています。しかも、その最初の印象がすごい。バ