AIに8割書かせたコード、半年運用の答え合わせ。効いた3つと、腐った3つ

半年前に「AIに8割書かせたコードを、保守できるようにやっていること」という記事を書きました。ありがたいことに、自分がいちばん読まれた記事になりました。 あれから半年、その方針のまま実際に運用してみて、答え合わせができました。先に言うと、保守性は「足す」では買えませんでした。コメントを足す、ドキュメントを足す、きれいな抽象を足す。そのほとんどは、半年後に腐っていました。効いたのは、少数の「効く型」だけです。 この記事では、良かれと思って足したのに無駄だった3つを先に、そのあと半年後も効いていた3つを書きます。前編が「やること」の記事なら、こっちは「やらなくてよかったこと」の記事です。 効かなかった、腐った3つ フェアじゃないので、外した対策から書きます。 1. AIに盛らせた、大量のコメントとdocstring いちばん腐りました。AIは頼めばいくらでもコメントを書きます。半年前の自分は「

[mak_in]

コレ見て改めて思ったのは、結局人間がやってきたソフトウェア開発のノウハウはほぼ活かせる、ということ。ココ以外のAI活用者の意見を多く聞いても色々な開発者が歴史の中で伝えられてきた内容と重なることが多い

[eggplantte]

whatよりwhyを残す、早すぎる共通化/最適化には注意、関数は小さく割る、 テストをしっかり残す。全部AIじゃなくて人間が書く場合でも同じだね

[uehaj]

AIが書いたのに間違いない「地図」多用／"「なぜ」だけ残す、小さく割る、軸を一本握る。どれも、増やす方向ではありません" ←「引く」じゃないし／AIに雑に書かせるとこうなるよね

[circled]

ソースにコメント書かせるよりも、改修の都度AIにAGENT.mdやCLAUDE.mdを最新版に更新させた方が良い。どうせ作業させるのがAIならば、AIに記憶を引き継がせるのはその2ファイルになるのだから

[jb8079431525325]

うーん、このくらいのことは誰でも行き着くレベルだよね。これからAIコーディング始めるぞって人は読んでも良いと思うけど、逆にそういった層にしか必要のない記事

[beejaga]

個人的にはLLMに抽象化をさせてはいけない、レイヤーアーキテクチャ程度でも人間が決め守らせる、ですかね

[e_denker]

“AIは「共通化しましょう」「抽象化しておきました」を、よく提案してきます” あー、これは分かる。私もAIと開発してて何度も「YAGNIなんでいいです」って言った。

[nakag0711]

抽象化は元々コードの未来を予想してやる投資ないし保険なので外れることもあるが、だから不要とも言えない

[jintrick]

【腐った3つ】①大量のコメント、②早すぎる共通化・抽象化、③曖昧な指示。 【効いた3つ】①「なぜ」のコメント、②関数の最小化、③仕様とテストの人間管理。

[secseek]

削る方向が正しいですよね。作るのがより簡単になったからなおさらです

[yarumato]

“保守性のための、コメントを足す（実装と乖離）、共通化や抽象化を足す（重複を放置のほうが、まだ変更が軽かった）は有害。効いたのは：「なぜ」以外のコメントを引く、仕様とテストは自分持ち、関数は小さく”

[ys0000]

docstring は大事だと思うが。余計なコメントは要らない。というかコメントは自分で書けば？気に入らないコードは受け取らない。

[m50747]

改修案件なら過去のプルリクエストなり実装をAIに伝えるそれに合わせて実装してくれる。コメントの書き方はAI任せ。変更が入ったらちゃんと書き換えてくれる。後はチャットの打ち合わせ内容は議事録に残してもらう。

[takafumiat]

結局は設計やコードレビューのノウハウを持ってないとAIの運用は厳しい。AIエージェントに対して自由にやらせるとクソコード量産するだけだからな。クソコードは最初はいいけど仕様変更が増えてくるとカオスになる。

[abababababababa]

良いまとめ。参考になる。

[revert]

AI時代ならHaskellが流行る可能性は十分あると思ってる。手続き型要素があると暗黙的な状態空間が桁違いに大きいので安全性の長期確保が難しい。言語の難しさも今ならAIで踏み倒せるので言語設計レベルのハーネスが必要

[rgfx]

まー確かにLLMはYAGNIを無限にやれるもんな。そりゃponytailみたいなのも出てくるか。 https://ponytail.dev/

[monorod]

結局保守性上げるには、昔から散々ソフト開発で言われ続けてた事をしろってことよな。人間もAIも変わんないわ

[tokuniimihanai]

そもそもAIのコメントは異常に読みづらい。

[moronbee]

人間がコード保守するなら当然の帰結かなと。どこまで属人性を排除してハーネスを残すか、残せる＝コストを賄えるプロダクトかに依るよね

[good2nd]

なんか人間が書くときのノウハウは（少なくとも人間が保守する間は）効くという話だけど、確認しておくのは大事

[mk173]

腐りやすいのはダメな上司がやりがちな指示の仕方かも

[homarara]

『「なぜ」だけ残す』←これは重要だなあ。AIに限らず、「なんでこんな事になってんだ？」と混乱するコードは多いからな。

[baronhorse]

記事をAIに書かせるなよ

[ducky19999]

AIに量を書かせろ&人間が質を担保しろ→しぬ

[ilyaletre]

納得感高い。テスト設計はテスト対象の設計空間を把握することが前提になるので、人間側も理解を腐らせずに維持するのに効きそう。 でもその理解フェーズにボトルネックが移動するだけの話ではある。

[stabucky]

半年前と今では生成AIの性能が上がっているのでこれが正しいやり方とは言えない。

[hogetax]

そろそろコーディングエージェント特有のナレッジが出てこんかな。ちょっと楽しみにしているんだけど

[rna]

頭のデキはそこそこだけど手の速さが半端ない部下をその特性を活かしていかに上手く使うか、みたいな感じ。大規模開発だとまた違うんだろうけど。

[gabill]

今年のAIは来年のAIより性能が低い。今年のAIにドキュメントを残させる行為は、今年のAIの指示で来年のAIを動かすようなもので大きな足枷になる。