エンジニアtype様にて、7月に行った講演のレポート記事を作成していただきました。誠にありがとうございます！
さらっと流し読みしかしてないんだけど同じことを考えているであろうことが読み取れた。ありがたい
認知負債という言葉は重い。AIに書かせても「理解」を放棄したら非常時に対応できないっていうのは本質
理解する量は有限な資源で、理解の必要性を減らさないとスケールしない。最近はどうやって実現するか、そのことをずっと考えている
システムは現実の課題に相対するものなので、それが何を解決するものかの理解こそが本質。そういう意味ではより哲学的なフェーズになってきたとも言える
「最大のボトルネックは、間違いなく「コードレビュー」にあります」「五つの工程へ分散」/この人は、これでうまくいってるのかな。「「人間の理解」だけは、どこまで技術が進化しようとも委託することは不可能」
そもそもAIが人に意思決定させるなら、意思決定出来るような粒度、資料を提示してくれって思うんよ
実際問題自分で手を入れれるだけで確認しやすさがだいぶ違う
理解は外注できる。聞きたいけど、ユーザ企業はシステム開発を委託開発するとき全て理解すべきなんですか？理解の抽象度を上げるしかない／コードレベルを理解できる量を超える臨界点は必ず来るし、もう来てる
Amazonのジェフベゾスが言うTwo-way door な変更は弱めのレビューにして、問題に気付けば対応するぐらいで良さそうという流れになっていますね。
もうコードレビューなんかしてねーよ。気分は発注者。こんな気持ちだったのね。
コードに限らず、要件定義でもまったく同じことを考えている
レビューという概念が分からない。テストではなくて？仕様書を満たす実装になっているかどうかを検証する必要がある。そういうテストが必要。自然言語は曖昧なので間におちる。
「多分動くと思うからリリースしようぜ」
やはりAIと伴走することで、手綱を引くしかない。 / "AIは組織の強みだけでなく、既存の問題や機能不全も増幅する。" まさにそう。AI任せでレビューなしは、後々取り返しがつかなくなる。
今まであったもの全て理解して作ってたならそれは素晴らしいことだけど、みんなそうだったかしら。
MicrosoftのAIのネーミングは完全に時代遅れなのね。
コードレビューが背負っていた仕事を、開発工程の各所に分散するという考え方
理解を手放さない。ここをどう上手くやるか。
ボブおじもレビューもうしてへんって言ってたしな
「人間の理解」だけはどこまで技術が進化しようとも委託することは不可能 上流の仕様レビュー テスト駆動開発 型システムと制約によるガードレール ビジネスの影響度に基づくリスクマッピング 継続的な理解の形成
“日本でTDDを啓蒙活動してきたが去年2025年は過去最高の普及。 実装前にテストを書かせ、通過するよう実装させるTDDの手順なら、人のレビュー業務を代替させられる。レビューを手放しても「理解」は手放せない”
“レビューを効率化する話だけでは解けない問題があります。”
もうコードレビューはしない。徹底的なテストで戦う。
“「思考は外注できても、理解は外注できない」”
AIでコード生成が加速する一方、レビューが開発の詰まりに。確認の役割を仕様・テスト・型や制約・リスク評価・理解共有の5工程に分散する「レビュー解体」を提案。人間の理解が追いつかない「認知負債」にも警鐘。
AIでコード生成は加速、でも人間の確認が追いつかない問題。t-wadaが示す「レビュー解体」という答え - エンジニアtype | 転職type
エンジニアtype様にて、7月に行った講演のレポート記事を作成していただきました。誠にありがとうございます！
さらっと流し読みしかしてないんだけど同じことを考えているであろうことが読み取れた。ありがたい
認知負債という言葉は重い。AIに書かせても「理解」を放棄したら非常時に対応できないっていうのは本質
理解する量は有限な資源で、理解の必要性を減らさないとスケールしない。最近はどうやって実現するか、そのことをずっと考えている
システムは現実の課題に相対するものなので、それが何を解決するものかの理解こそが本質。そういう意味ではより哲学的なフェーズになってきたとも言える
「最大のボトルネックは、間違いなく「コードレビュー」にあります」「五つの工程へ分散」/この人は、これでうまくいってるのかな。「「人間の理解」だけは、どこまで技術が進化しようとも委託することは不可能」
そもそもAIが人に意思決定させるなら、意思決定出来るような粒度、資料を提示してくれって思うんよ
実際問題自分で手を入れれるだけで確認しやすさがだいぶ違う
理解は外注できる。聞きたいけど、ユーザ企業はシステム開発を委託開発するとき全て理解すべきなんですか？理解の抽象度を上げるしかない／コードレベルを理解できる量を超える臨界点は必ず来るし、もう来てる
Amazonのジェフベゾスが言うTwo-way door な変更は弱めのレビューにして、問題に気付けば対応するぐらいで良さそうという流れになっていますね。
もうコードレビューなんかしてねーよ。気分は発注者。こんな気持ちだったのね。
コードに限らず、要件定義でもまったく同じことを考えている
レビューという概念が分からない。テストではなくて？仕様書を満たす実装になっているかどうかを検証する必要がある。そういうテストが必要。自然言語は曖昧なので間におちる。
「多分動くと思うからリリースしようぜ」
やはりAIと伴走することで、手綱を引くしかない。 / "AIは組織の強みだけでなく、既存の問題や機能不全も増幅する。" まさにそう。AI任せでレビューなしは、後々取り返しがつかなくなる。
今まであったもの全て理解して作ってたならそれは素晴らしいことだけど、みんなそうだったかしら。
MicrosoftのAIのネーミングは完全に時代遅れなのね。
コードレビューが背負っていた仕事を、開発工程の各所に分散するという考え方
理解を手放さない。ここをどう上手くやるか。
ボブおじもレビューもうしてへんって言ってたしな
「人間の理解」だけはどこまで技術が進化しようとも委託することは不可能 上流の仕様レビュー テスト駆動開発 型システムと制約によるガードレール ビジネスの影響度に基づくリスクマッピング 継続的な理解の形成
“日本でTDDを啓蒙活動してきたが去年2025年は過去最高の普及。 実装前にテストを書かせ、通過するよう実装させるTDDの手順なら、人のレビュー業務を代替させられる。レビューを手放しても「理解」は手放せない”
“レビューを効率化する話だけでは解けない問題があります。”
もうコードレビューはしない。徹底的なテストで戦う。
“「思考は外注できても、理解は外注できない」”
AIでコード生成が加速する一方、レビューが開発の詰まりに。確認の役割を仕様・テスト・型や制約・リスク評価・理解共有の5工程に分散する「レビュー解体」を提案。人間の理解が追いつかない「認知負債」にも警鐘。