AIで無限にAI Slopを作れるようになって（ゴミを）圧倒的生産性で作っても評価されるどころか「ゴミで世界を汚すな黙って死んでろ」ぐらいの扱いになったがAI Slopを作るなはシステムに閉じたレベルでも同じってことよね
どんどんとブラッシュアップしていく。
AIに大量のコードを盛らせるより「なぜ」だけ残すのはガチ。仕様とテストを人間が握るのも納得
半年前のAIって雑魚だったからなあ。先行して頑張ったノウハウはすぐに陳腐化して、急激にAIだけで完結するようになっていく。気づいたら「あれ…俺いらなくね？」ってなってる。
今年のAIは来年のAIより性能が低い。今年のAIにドキュメントを残させる行為は、今年のAIの指示で来年のAIを動かすようなもので大きな足枷になる。
コレ見て改めて思ったのは、結局人間がやってきたソフトウェア開発のノウハウはほぼ活かせる、ということ。ココ以外のAI活用者の意見を多く聞いても色々な開発者が歴史の中で伝えられてきた内容と重なることが多い
頭のデキはそこそこだけど手の速さが半端ない部下をその特性を活かしていかに上手く使うか、みたいな感じ。大規模開発だとまた違うんだろうけど。
【腐った3つ】①大量のコメント、②早すぎる共通化・抽象化、③曖昧な指示。 【効いた3つ】①「なぜ」のコメント、②関数の最小化、③仕様とテストの人間管理。
そろそろコーディングエージェント特有のナレッジが出てこんかな。ちょっと楽しみにしているんだけど
whatよりwhyを残す、早すぎる共通化/最適化には注意、関数は小さく割る、 テストをしっかり残す。全部AIじゃなくて人間が書く場合でも同じだね
半年前と今では生成AIの性能が上がっているのでこれが正しいやり方とは言えない。
納得感高い。テスト設計はテスト対象の設計空間を把握することが前提になるので、人間側も理解を腐らせずに維持するのに効きそう。 でもその理解フェーズにボトルネックが移動するだけの話ではある。
AIに量を書かせろ&人間が質を担保しろ→しぬ
AIが書いたのに間違いない「地図」多用／"「なぜ」だけ残す、小さく割る、軸を一本握る。どれも、増やす方向ではありません" ←「引く」じゃないし／AIに雑に書かせるとこうなるよね
記事をAIに書かせるなよ
『「なぜ」だけ残す』←これは重要だなあ。AIに限らず、「なんでこんな事になってんだ？」と混乱するコードは多いからな。
腐りやすいのはダメな上司がやりがちな指示の仕方かも
ソースにコメント書かせるよりも、改修の都度AIにAGENT.mdやCLAUDE.mdを最新版に更新させた方が良い。どうせ作業させるのがAIならば、AIに記憶を引き継がせるのはその2ファイルになるのだから
なんか人間が書くときのノウハウは（少なくとも人間が保守する間は）効くという話だけど、確認しておくのは大事
個人的にはLLMに抽象化をさせてはいけない、レイヤーアーキテクチャ程度でも人間が決め守らせる、ですかね
人間がコード保守するなら当然の帰結かなと。どこまで属人性を排除してハーネスを残すか、残せる＝コストを賄えるプロダクトかに依るよね
そもそもAIのコメントは異常に読みづらい。
抽象化は元々コードの未来を予想してやる投資ないし保険なので外れることもあるが、だから不要とも言えない
“AIは「共通化しましょう」「抽象化しておきました」を、よく提案してきます” あー、これは分かる。私もAIと開発してて何度も「YAGNIなんでいいです」って言った。
結局保守性上げるには、昔から散々ソフト開発で言われ続けてた事をしろってことよな。人間もAIも変わんないわ
まー確かにLLMはYAGNIを無限にやれるもんな。そりゃponytailみたいなのも出てくるか。 https://ponytail.dev/
AI時代ならHaskellが流行る可能性は十分あると思ってる。手続き型要素があると暗黙的な状態空間が桁違いに大きいので安全性の長期確保が難しい。言語の難しさも今ならAIで踏み倒せるので言語設計レベルのハーネスが必要
良いまとめ。参考になる。
結局は設計やコードレビューのノウハウを持ってないとAIの運用は厳しい。AIエージェントに対して自由にやらせるとクソコード量産するだけだからな。クソコードは最初はいいけど仕様変更が増えてくるとカオスになる。
改修案件なら過去のプルリクエストなり実装をAIに伝えるそれに合わせて実装してくれる。コメントの書き方はAI任せ。変更が入ったらちゃんと書き換えてくれる。後はチャットの打ち合わせ内容は議事録に残してもらう。
マージとかデプロイする前にコメントとドキュメント修正させれば腐らないと思うんだけどどういうこと？CICDにAI噛ませてないのかな
うーん、このくらいのことは誰でも行き着くレベルだよね。これからAIコーディング始めるぞって人は読んでも良いと思うけど、逆にそういった層にしか必要のない記事
docstring は大事だと思うが。余計なコメントは要らない。というかコメントは自分で書けば？気に入らないコードは受け取らない。
“保守性のための、コメントを足す（実装と乖離）、共通化や抽象化を足す（重複を放置のほうが、まだ変更が軽かった）は有害。効いたのは：「なぜ」以外のコメントを引く、仕様とテストは自分持ち、関数は小さく”
AIに8割書かせたコード、半年運用の答え合わせ。効いた3つと、腐った3つ
AIで無限にAI Slopを作れるようになって（ゴミを）圧倒的生産性で作っても評価されるどころか「ゴミで世界を汚すな黙って死んでろ」ぐらいの扱いになったがAI Slopを作るなはシステムに閉じたレベルでも同じってことよね
どんどんとブラッシュアップしていく。
AIに大量のコードを盛らせるより「なぜ」だけ残すのはガチ。仕様とテストを人間が握るのも納得
半年前のAIって雑魚だったからなあ。先行して頑張ったノウハウはすぐに陳腐化して、急激にAIだけで完結するようになっていく。気づいたら「あれ…俺いらなくね？」ってなってる。
今年のAIは来年のAIより性能が低い。今年のAIにドキュメントを残させる行為は、今年のAIの指示で来年のAIを動かすようなもので大きな足枷になる。
コレ見て改めて思ったのは、結局人間がやってきたソフトウェア開発のノウハウはほぼ活かせる、ということ。ココ以外のAI活用者の意見を多く聞いても色々な開発者が歴史の中で伝えられてきた内容と重なることが多い
頭のデキはそこそこだけど手の速さが半端ない部下をその特性を活かしていかに上手く使うか、みたいな感じ。大規模開発だとまた違うんだろうけど。
【腐った3つ】①大量のコメント、②早すぎる共通化・抽象化、③曖昧な指示。 【効いた3つ】①「なぜ」のコメント、②関数の最小化、③仕様とテストの人間管理。
そろそろコーディングエージェント特有のナレッジが出てこんかな。ちょっと楽しみにしているんだけど
whatよりwhyを残す、早すぎる共通化/最適化には注意、関数は小さく割る、 テストをしっかり残す。全部AIじゃなくて人間が書く場合でも同じだね
半年前と今では生成AIの性能が上がっているのでこれが正しいやり方とは言えない。
納得感高い。テスト設計はテスト対象の設計空間を把握することが前提になるので、人間側も理解を腐らせずに維持するのに効きそう。 でもその理解フェーズにボトルネックが移動するだけの話ではある。
AIに量を書かせろ&人間が質を担保しろ→しぬ
AIが書いたのに間違いない「地図」多用／"「なぜ」だけ残す、小さく割る、軸を一本握る。どれも、増やす方向ではありません" ←「引く」じゃないし／AIに雑に書かせるとこうなるよね
記事をAIに書かせるなよ
『「なぜ」だけ残す』←これは重要だなあ。AIに限らず、「なんでこんな事になってんだ？」と混乱するコードは多いからな。
腐りやすいのはダメな上司がやりがちな指示の仕方かも
ソースにコメント書かせるよりも、改修の都度AIにAGENT.mdやCLAUDE.mdを最新版に更新させた方が良い。どうせ作業させるのがAIならば、AIに記憶を引き継がせるのはその2ファイルになるのだから
なんか人間が書くときのノウハウは（少なくとも人間が保守する間は）効くという話だけど、確認しておくのは大事
個人的にはLLMに抽象化をさせてはいけない、レイヤーアーキテクチャ程度でも人間が決め守らせる、ですかね
人間がコード保守するなら当然の帰結かなと。どこまで属人性を排除してハーネスを残すか、残せる＝コストを賄えるプロダクトかに依るよね
そもそもAIのコメントは異常に読みづらい。
抽象化は元々コードの未来を予想してやる投資ないし保険なので外れることもあるが、だから不要とも言えない
“AIは「共通化しましょう」「抽象化しておきました」を、よく提案してきます” あー、これは分かる。私もAIと開発してて何度も「YAGNIなんでいいです」って言った。
結局保守性上げるには、昔から散々ソフト開発で言われ続けてた事をしろってことよな。人間もAIも変わんないわ
まー確かにLLMはYAGNIを無限にやれるもんな。そりゃponytailみたいなのも出てくるか。 https://ponytail.dev/
AI時代ならHaskellが流行る可能性は十分あると思ってる。手続き型要素があると暗黙的な状態空間が桁違いに大きいので安全性の長期確保が難しい。言語の難しさも今ならAIで踏み倒せるので言語設計レベルのハーネスが必要
良いまとめ。参考になる。
結局は設計やコードレビューのノウハウを持ってないとAIの運用は厳しい。AIエージェントに対して自由にやらせるとクソコード量産するだけだからな。クソコードは最初はいいけど仕様変更が増えてくるとカオスになる。
改修案件なら過去のプルリクエストなり実装をAIに伝えるそれに合わせて実装してくれる。コメントの書き方はAI任せ。変更が入ったらちゃんと書き換えてくれる。後はチャットの打ち合わせ内容は議事録に残してもらう。
マージとかデプロイする前にコメントとドキュメント修正させれば腐らないと思うんだけどどういうこと？CICDにAI噛ませてないのかな
うーん、このくらいのことは誰でも行き着くレベルだよね。これからAIコーディング始めるぞって人は読んでも良いと思うけど、逆にそういった層にしか必要のない記事
docstring は大事だと思うが。余計なコメントは要らない。というかコメントは自分で書けば？気に入らないコードは受け取らない。
“保守性のための、コメントを足す（実装と乖離）、共通化や抽象化を足す（重複を放置のほうが、まだ変更が軽かった）は有害。効いたのは：「なぜ」以外のコメントを引く、仕様とテストは自分持ち、関数は小さく”