認知負債についてのまとめ。結論が重い "対策が分かっていても実行されない理由は、出力量を生産性指標にする組織と、仕事の安定を優先する個人のインセンティブにある"
自動化が進むと人間はリバースケンタウロスになる
/* よくわからないけど動く */
AI生成で爆速リリースしても、後で「これ何だっけ？」ってなる認知のツケが回るだけ。技術的負債の再来やね
aiが作ってaiが理解してaiが修正するが、動作するのは現実の人間の間なので齟齬がある
コピペ時代から理解してません
負債もAIに解消させよう。もう行けるとこまで行こうぜ。
これ読んで、AI生成でテストケースを100%網羅したからテスト完了としても、想定外のソースコードが混じっていて余計な動作をするパターンがありそう。CIでそのケース確認できてたっけ？
なんか大事なこと書いてそうだけど文章が読みにくいので、AIに要約させたらめっちゃわかりやすかった
今までコードを書く以外の部分を後回しにして最低限しかやってなかったのでAIが早めた分だけ負債になっている。解決策としてはこの負債と呼ばれる部分もAIで整備するしかない
ボク、認知負債って何かにゃ？ご褒美くれるなら考えるにゃ！
いいまとめ方
まだ使いこなせてねえんだろうがclaude. mdやらmemory やらドキュメントやら油断するとモリモリ生えてくる
『自動化で人間に残るのは「自動化できなかった残余」であり、最も負荷が高く曖昧なタスクが残る。監視役に回るとスキルが萎縮し、介入が必要な瞬間に最も準備がない』はい、これを強く懸念しております
“対策は既知でも、それを実行するインセンティブが組織にも個人にもない。” ここが悩みどころすぎる。 怪しい仕様を断るコストにくらべて、とりあえずAIで作ってしまう方が簡単になってしまった。
AIにコード任せてよくわからないままリリースすると後で認知負債を払うことになるという話。技術的負債の一種とも言えるか
大変良いまとめ。
なにはともあれこうやって定義されるのが第一歩だな
AIが作ってAIが理解してAIが修正するならコード上の認知負債は存在しないので問題ないぜ⭐️
“LGTM”
そこまで負債あるか？逆に緩和されたと思うが。そもそも全て理解、管理は難しいし必要性もないことの方が多いと思うが。規模によるのか。
ビルゲイツ式の尋問がレビューの代わりになったりして https://web.archive.org/web/20190406043653/http://local.joelonsoftware.com/wiki/%E3%81%AF%E3%81%98%E3%82%81%E3%81%A6%E3%81%AEBillG%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%81%AE%E3%81%93%E3%81%A8
AIを使っていいのは、AIの問題点を自力で把握して解決できる人だけ。AIで解消しようとか本気で言っているような人はAIを使ってはいけない
もしかして分野外の技術分野で人をマネジメントをやるときも同じ問題が発生する？
めんどく債
そろそろAIによる実装のソースコードは、コンパイルされたバイナリコードと同じ扱いにするしかないのでは？ 人間がメンテするのはAIへの指示書。論理回路の自動合成ツール出現時に、これと同じ議論をしてた。
“意図負債”は言語学の語用論の観点からも語れる気がする。
人間が書いたときでも「コピペしてきただけだから仕組みは分からん」や「自分で一から書いたはずだがこれを消すとバグる理由がもう分からんから消すな」まみれだったのをさもAI以前はなかったかのように語りおるわ
本質的な話
航空機パイロットはオートパイロット適応外の状況のための十分な訓練を課されるが正常に行われる99%のフライトにおいて当然コスパは悪くコストカットしようとする零細航空会社は絶えない、みたいな構造を思い出す。
ちゃんと考えて読むの、本当に疲れるんだよな。読まないとやらかすし
「監視役に回るとスキルが萎縮し、介入が必要な瞬間に最も準備がない」｜AI生成の成果物に潜在する問題は、文脈情報（意図と達成方策の連鎖）が欠如してると、事後的にAIに読ませても検出しにくいのでは？
“負債”は「借り物の資産」でネガティブな意味はない
関係ないけどこのサイトなんで一文字一文字spanで囲ってるのかな
『「認知負債」はAI以前から存在するものなので、既知の対策も多い』『白紙から処方箋を作る必要はない』
AIによってコードレビューを減らしてもAIに作らせた仕様書を大量に読んでる
“負債は何を指すか、を切り分ける 「認知負債”
質の低いプログラマーが書いたコードを納期の関係で無理やりリリースするのと同じ問題。つまり昔からある問題。
AI 認知負債
SDLC/ITILは土台だが認知負債対策は意思決定の連鎖を残すこと。企画書は粒度が荒いので、チケット＋ADRでWhy/制約/判断を分解・追跡可能にする運用が現実的。
“監視役に回るとスキルが萎縮”。日本の場合、AIが普及する前からプロジェクト毎に解散する請負で働くプログラマは非正規で元請けの正社員のスキルは萎縮しまくりだったんじゃね？
大丈夫、そのうちできるようになるよ> AIを使っていいのは、AIの問題点を自力で把握して解決できる人だけ。AIで解消しようとか本気で言っているような人はAIを使ってはいけない
こうなるとJavaだとアノテーションで＠Requirementで参照する要件を指すとか、アノテーションプロセッサで要件の充足性を確認するとかまでいかなかったのが悔やまれるな。あったけど日の目を見なかったのかな
品質の検証や設計思想の維持には人間のエンジニアによる判断が不可欠。AI過渡期のエンジニアの仕事はこれになるのかな
「生成過程で形成されるメンタルモデルが形成されなくなった」これだなあ。ここを如何に対処していくかだ
こういう知の結晶のようなものを書けるようになりたい。
認知負債 - kawasima
認知負債についてのまとめ。結論が重い "対策が分かっていても実行されない理由は、出力量を生産性指標にする組織と、仕事の安定を優先する個人のインセンティブにある"
自動化が進むと人間はリバースケンタウロスになる
/* よくわからないけど動く */
AI生成で爆速リリースしても、後で「これ何だっけ？」ってなる認知のツケが回るだけ。技術的負債の再来やね
aiが作ってaiが理解してaiが修正するが、動作するのは現実の人間の間なので齟齬がある
コピペ時代から理解してません
負債もAIに解消させよう。もう行けるとこまで行こうぜ。
これ読んで、AI生成でテストケースを100%網羅したからテスト完了としても、想定外のソースコードが混じっていて余計な動作をするパターンがありそう。CIでそのケース確認できてたっけ？
なんか大事なこと書いてそうだけど文章が読みにくいので、AIに要約させたらめっちゃわかりやすかった
今までコードを書く以外の部分を後回しにして最低限しかやってなかったのでAIが早めた分だけ負債になっている。解決策としてはこの負債と呼ばれる部分もAIで整備するしかない
ボク、認知負債って何かにゃ？ご褒美くれるなら考えるにゃ！
いいまとめ方
まだ使いこなせてねえんだろうがclaude. mdやらmemory やらドキュメントやら油断するとモリモリ生えてくる
『自動化で人間に残るのは「自動化できなかった残余」であり、最も負荷が高く曖昧なタスクが残る。監視役に回るとスキルが萎縮し、介入が必要な瞬間に最も準備がない』はい、これを強く懸念しております
“対策は既知でも、それを実行するインセンティブが組織にも個人にもない。” ここが悩みどころすぎる。 怪しい仕様を断るコストにくらべて、とりあえずAIで作ってしまう方が簡単になってしまった。
AIにコード任せてよくわからないままリリースすると後で認知負債を払うことになるという話。技術的負債の一種とも言えるか
大変良いまとめ。
なにはともあれこうやって定義されるのが第一歩だな
AIが作ってAIが理解してAIが修正するならコード上の認知負債は存在しないので問題ないぜ⭐️
“LGTM”
そこまで負債あるか？逆に緩和されたと思うが。そもそも全て理解、管理は難しいし必要性もないことの方が多いと思うが。規模によるのか。
ビルゲイツ式の尋問がレビューの代わりになったりして https://web.archive.org/web/20190406043653/http://local.joelonsoftware.com/wiki/%E3%81%AF%E3%81%98%E3%82%81%E3%81%A6%E3%81%AEBillG%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%81%AE%E3%81%93%E3%81%A8
AIを使っていいのは、AIの問題点を自力で把握して解決できる人だけ。AIで解消しようとか本気で言っているような人はAIを使ってはいけない
もしかして分野外の技術分野で人をマネジメントをやるときも同じ問題が発生する？
めんどく債
そろそろAIによる実装のソースコードは、コンパイルされたバイナリコードと同じ扱いにするしかないのでは？ 人間がメンテするのはAIへの指示書。論理回路の自動合成ツール出現時に、これと同じ議論をしてた。
“意図負債”は言語学の語用論の観点からも語れる気がする。
人間が書いたときでも「コピペしてきただけだから仕組みは分からん」や「自分で一から書いたはずだがこれを消すとバグる理由がもう分からんから消すな」まみれだったのをさもAI以前はなかったかのように語りおるわ
本質的な話
航空機パイロットはオートパイロット適応外の状況のための十分な訓練を課されるが正常に行われる99%のフライトにおいて当然コスパは悪くコストカットしようとする零細航空会社は絶えない、みたいな構造を思い出す。
ちゃんと考えて読むの、本当に疲れるんだよな。読まないとやらかすし
「監視役に回るとスキルが萎縮し、介入が必要な瞬間に最も準備がない」｜AI生成の成果物に潜在する問題は、文脈情報（意図と達成方策の連鎖）が欠如してると、事後的にAIに読ませても検出しにくいのでは？
“負債”は「借り物の資産」でネガティブな意味はない
関係ないけどこのサイトなんで一文字一文字spanで囲ってるのかな
『「認知負債」はAI以前から存在するものなので、既知の対策も多い』『白紙から処方箋を作る必要はない』
AIによってコードレビューを減らしてもAIに作らせた仕様書を大量に読んでる
“負債は何を指すか、を切り分ける 「認知負債”
質の低いプログラマーが書いたコードを納期の関係で無理やりリリースするのと同じ問題。つまり昔からある問題。
AI 認知負債
SDLC/ITILは土台だが認知負債対策は意思決定の連鎖を残すこと。企画書は粒度が荒いので、チケット＋ADRでWhy/制約/判断を分解・追跡可能にする運用が現実的。
“監視役に回るとスキルが萎縮”。日本の場合、AIが普及する前からプロジェクト毎に解散する請負で働くプログラマは非正規で元請けの正社員のスキルは萎縮しまくりだったんじゃね？
大丈夫、そのうちできるようになるよ> AIを使っていいのは、AIの問題点を自力で把握して解決できる人だけ。AIで解消しようとか本気で言っているような人はAIを使ってはいけない
こうなるとJavaだとアノテーションで＠Requirementで参照する要件を指すとか、アノテーションプロセッサで要件の充足性を確認するとかまでいかなかったのが悔やまれるな。あったけど日の目を見なかったのかな
品質の検証や設計思想の維持には人間のエンジニアによる判断が不可欠。AI過渡期のエンジニアの仕事はこれになるのかな
「生成過程で形成されるメンタルモデルが形成されなくなった」これだなあ。ここを如何に対処していくかだ
こういう知の結晶のようなものを書けるようになりたい。