いわゆる[[AI]]に丸投げして行うコーディング、いわゆる[[Agentic Coding]]について思うところ。 ## 元気なときにやったほうがいい 以前は『疲れているときにやったほうがいい』と思っていた。コーディングは疲れる作業なので、要件だけ伝えて実装してもらえるならそっちのほうが楽だなと。ただ、実際は違うと思った。 脳が疲れていると的確な指示ができないし言語化もできない。曖昧で的を得ていない指示をAIにしてしまうので、AIの方も確度が低くなる。気が利かないAIの場合は愚直に間違えた実装、運が悪いとゴールのない実装に突進していく。気が利くAIも選択肢が多すぎて迷ってしまうし、確認してくれてもこちらが脳が動いてないので余計混乱させる。 [[Agentic Coding]]をするなら朝の元気なうちにやるのが、実は一番効果的だとも思った。 ## どこまで権限を委譲して任せるかという話 組織が大きくなると、個人の権限を他の人に委譲したほうがいいというのは説明するまでもないだろう。 システム開発はどうしても運用・保守が伴うので、権限が集中しているとそれらのタスクを分散できない。新規開発をした人が都度それらを担うとどこかで破綻する。だから、権限と一緒にタスクや役割を他の人に委譲する。委譲した人は新たな業務を行えるようになる。委譲された側も、今までと違った業務から学びを得ることもできるだろう。 結局のところ、リスクと効率性はトレードオフであり、人間の組織だけでなく[[Agentic Coding]]でも同じだなと思った。 AIのやる方やコーディングを100%信頼することは難しいかもしれないし、リスクかもしれない。でも、部分的に信頼したり委譲したりすることはできる。委譲の具体例としては、コマンド実行権限やdiffの確認/承認なしでファイル編集できる権限などが挙げられる。 ## 開発の種類によって何で保証するかが変わる 一般的なユーテリティ処理だったら、実装もテストも任せてしまって良さそう。パフォーマンスもパフォーマンステスト書いてもらえば担保できる。気をつけるとしたらコードに脆弱性がないかどうかくらい。 逆に、ドメインロジック(ビジネスロジック)が絡む処理だと、テストコードは自分で書いたほうがいいかもしれない。実装はテストが全て通ればユーティリティ処理同様に問題ないので、任せてしまってもいい。しかし、テストコードの妥当性はAIの学習した知見が役に立たない(むしろハルシネーションを生む)場合も多いので、仕様に基づいて自分で書いたほうが手堅い。 『じゃあ、仕様(ドキュメント)をちゃんと書いておけばテストコードもちゃんとできるから、AIに任せてもいいのでは？』と思うかもしれない。たしかに、常に正確な仕様とドキュメントが書けるならその方が良い。ただ、実際は仕様書の書き漏れはあるし、仕様自体の設定ミスもある。 そして、これに気づくのは対象工程と対称となる工程であることが多い。つまり、仕様書作成の漏れはテスト設計で気づくことが多く、テストの漏れは実装で気づくことが多い。なので、要件や仕様が一般的でなくミスする確率が高い場合は、テストに関する主導権を人間のほうで握って置いたほうが早期にAIの方向性をコントロールできていいかなと。 ## 書くスピードの価値は下がるのか？ よく言われることとして『実装は[[AI]]がやる時代だから、コードを素早く編集する必要はなくなる。なので[[Vimmer]]になる必要はない』みたいなのがある。これは半分正しくて半分間違っているかなと。 たしかにソースコードを素早く編集する機会は大幅に減るだろう、適切な情報を与えれば[[AI]]が一瞬で編集してくれるからだ。以前、[[Windows]]で[[GitHub Copilot]]を使っていた時はコード編集がめちゃくちゃ遅くてイライラしていたが、[[MacBook Pro M4 Pro]]に変えて[[Claude Code]]に編集してもらう今は編集が速すぎて確認が追いつかないほどである。([[VSCode]]+[[GitHub Copilot]]も今の環境だと高速であるとフォローしておこう) 代わりに書くことが増えた言語がある。日本語だ。英語でもいいけど。自然言語を使って[[AI]]に指示をすることが多くなったからだ。それも、[[AI]]には『○○機能を実装して』みたいなアバウトな処理は逆効果になることが多く、指示する文章量は必然的にそれなりのものになる。それすらも[[AI]]に出してもらうという技もあるが、単に自然言語のタイピング時間を狭めるためだけに[[AI]]を使うのは、かえって待ちやレビューに時間がかかるというものだ。 ソースコードの記述速度に対する重要性はたしかに下がったと言えよう。だが、代わりに自然言語の記述速度の重要性が上がっていることは事実であり、それが達成できる道具が[[Vim]]や[[Neovim]]であるなら、[[Vimmer]]になる意味合いはまだあると思う。 ~~まあ、プログラミング言語以外、特に日本語になると旨味がかなり減るのは事実だけど~~ ## コードに対するこだわりを捨てる そこそこの経験値をもつ人が、『綺麗でメンテナンスしやすい』と感じるコードを書くことが、プロダクトないしはエンジニアのためになると信じてずっとコードを書いてきた。それは、**コードを読んだり書いたりするのはエンジニアである**という絶対的な揺るがない前提があったからだ。 ところが今はどうだろうか。コードを読むのはほぼ[[AI]]の仕事になっている。ちゃんとしたモデル([[Claude Sonnet 4]]など)を使っていれば、[[AI]]の方が読むスピードはもちろんのこと、正確さや文書化のスピード/詳細さも圧倒的に上である。比較にならない。たまに命令を無視したり、勘違いすることもあるが、確率的には人間がミスしていることのほうが高い。 そして最近は、特に[[Claude Code]]によってコードを書くのも[[AI]]の仕事になりつつある。**コードを書くのが人間だから、人間が読んだり編集しやすくする必要があるのだ**という免罪符がもはや使えなくなりつつある。むしろ[[AI]]が読んで、[[AI]]が編集しやすいコードを書くことの方が重要かもしれない。 だから、**コードの中身を人間の感性でレビューし、[[AI]]にダメ出しするのは時代遅れ**と言えるのではないだろうか。コードの可読性にこだわりを持っている身としては身が削られる思いではあるが、別の人に引き継いだプロダクトのコードに外野が口出ししないのと一緒で、[[AI]]のやることに必要以上に口出ししないほうがいいだろう。老害にならないためにも。 でも安心してほしい。人間による可読性が全く不要になったわけではない。コードの代わりに**ドキュメントの可読性は今まで以上に求められる**だろう。なぜなら、ドキュメント、すなわち仕様の正誤を判定できるのは(今のところ)人間だけであり、少なくとも人間はドキュメントを読んで確認する必要があるからだ。 また、[[AI]]に対して指示をするのも、[[AI]]が仕様を理解するために読むのもドキュメントだ。今までコードの綺麗さにこだわりを持っていたのであれば、その軸をドキュメント(日本語や英語)に移してみてはどうだろうか。 ## [[Agentic Coding]]の位置づけ [[AI]]が自走する[[Agentic Coding]]は歴史的にどのような位置づけなのか？ - 単なる一過性のブーム - 新しいツール - 新しい言語 - 新しいパラダイム 自分は間違いなく**新しいパラダイム**だと思っている。これは15年に1度発生する大きな歴史的な動きの一貫だと思う。 | 年代 | 一般人含む全員 | エンジニアのみ | | -------- | --------------------------- | --------------------------- | | 1995年頃 | インターネット/PHS/携帯電話 | ??? (まだ小さかったので...) | | 2010年頃 | スマホ | GitHub(OSS)/AWS | | 2025年頃 | AI | [[Agentic Coding]] | エンジニア界隈では毎年のように各分野でそれなりに大きな変化はあるものの、[[AI]]や[[Agentic Coding]]はこのレベルかなと。それくらいの覚悟をもって[[アンラーニング]]していかなければ時代に取り残され、エンジニアの一線としてはやっていけないだろうと思っている。 - 2005年にインターネットも携帯も使わない人や企業はどれだけいただろうか？ - 2020年にスマホを使わない人や企業はどれだけいただろうか？ - 2035年に[[AI]]や[[Agentic Coding]]を使わない人や企業は**どれだけいるのだろうか？** ## オートのシミュレーションゲームみたい [[Claude Code]]で[[Agentic Coding]]をやってて思ったのは、シミュレーションゲームみたいだなと言うこと。あらかじめ戦略や装備を整えておいて、本番は黙って見守りつつ、必要に応じてピンポイントにチャチャを入れる感じ。例えるなら - ダビスタのレース - 英雄伝説3の戦闘 - FC版ドラクエ4の戦闘 みたいな感じ。昭和の一部の人にしか伝わらないかもしれないけど。 マニュアルでの操作や指示と異なり、思い通りにいかなくてイライラすることも多いが、上手くいったときの快感や、指示を待たずに自走するからこその瀬戸際での対応力は[[AI]]の方が強い。ドラクエ4の例だと、敵に先制攻撃をされたターンだけピンポイントに回復魔法を使うのは人間には不可能だろう。 というわけで、突き詰めた先には[[プロダクティビティ]]の向上があるかもしれない。いや、ほぼ確実にあるだろう。まずは[[現状維持バイアス]]を乗り越えようとする姿勢が大事。 <div class="link-card-v2"> <div class="link-card-v2-site"> <img class="link-card-v2-site-icon" src="https://publish-01.obsidian.md/access/35d05cd1bf5cc500e11cc8ba57daaf88/favicon-64.png" /> <span class="link-card-v2-site-name">Minerva</span> </div> <div class="link-card-v2-title"> 📗最低1ヶ月は試す </div> <div class="link-card-v2-content">新しい習慣やツールを取り入れるには現状維持バイアスを乗り越え、最低1ヶ月継続することが重要です。行動や継続のコツ、習慣化、変化への抵抗対策について解説します。</div> <img class="link-card-v2-image" src="https://publish-01.obsidian.md/access/35d05cd1bf5cc500e11cc8ba57daaf88/%F0%9F%93%97Productivity%E3%82%92%E4%B8%8A%E3%81%92%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AB%E5%A4%A7%E5%88%87%E3%81%AA100%E3%81%AE%E3%81%93%E3%81%A8/attachments/productivity100.webp" /> <a data-href="📗最低1ヶ月は試す" class="internal-link"></a> </div> %%[[📗最低1ヶ月は試す]]%% ## 仕様などのドキュメントは自分で書いたほうがいい 0 -> 1 で作ってもらうケースや、英語で作ってもらうケースは頼んだほうがいいけど、そうじゃないケース、特に仕事の[[DDD]]に関するドキュメントは自分で書いたほうがいい。 [[GitHub Copilot]]に任せたら、仕様では気にするべきでない実装やDBに関する情報までつらつら書かれてしまって、これメンテできんだろってなった。 まあ、AIがプロダクト終了まで責任もってやってくれるならそれでもいいけど。ただ実際はそうはならんよねっていう。AIの立場としては実装するときに欲しい情報だと思っているので書いてるんだとは思うんだけどね。 それと、変数名とドキュメント上の名称が完全一致してないと、別の[[ユビキタス言語]]と判断されることが多かった。それは同じにすればいい話なんだけど、スコープが狭い変数とか省略したくなるじゃんという。 ## 品質とAgentic Coding #2025/07/06 [[👤t_wada]]さんの最新のを見て。 <div class="link-card-v2"> <div class="link-card-v2-site"> <img class="link-card-v2-site-icon" src="https://d1eu30co0ohy4w.cloudfront.net/assets/favicon-bdd5839d46040a50edf189174e6f7aacc8abb3aaecd56a4711cf00d820883f47.png" /> <span class="link-card-v2-site-name">Speaker Deck</span> </div> <div class="link-card-v2-title"> AI時代のソフトウェア開発を考える（2025/07版） / Agentic Software Engineering Findy 2025-07 Edition </div> <div class="link-card-v2-content"> AI時代のソフトウェア開発を考える（2025/07版）開発生産性 Conference 20252025年 7月4日（金）https://dev-productivity-con.findy-code.io/2025 ... </div> <img class="link-card-v2-image" src="https://files.speakerdeck.com/presentations/8ea3dd02d66343099e2099f5000880c6/slide_0.jpg?35723342" /> <a href="https://speakerdeck.com/twada/agentic-software-engineering-findy-2025-07-edition"></a> </div> ほぼ同じ認識なので一安心。一応時代にはついていけてそう。 内部品質との付き合い方にパターンが増えて難しくなってきたり、賭けるのではなく両睨みが必要といったあたりが特に。 とはいえ、個人開発に関しては現状[[Claude Code]]が圧倒的に有利だと思っている。[[GitHub Copilot]]や[[Cursor]]の[[Notes/Claude|Claude]]モデルは制限厳しくなっているのも加えて。 ## ツケは忘れないうちに回ってくる #2025/08/17 コードの負債というのは忘れた頃に回ってくるものだ。大抵は早くても数ヶ月後、遅い場合は年をまたいでやってくる。そして、運が良くなければその負債を作った人は大抵その場にはいない。これはAIなし開発の場合である。 [[Vibe Coding]]は論外として、では[[Agentic Coding]]はどうなのかというと、そのツケはかなり早いうちに回ってくると感じている。早ければ1週間以内、遅くても1ヶ月以内というスピード感だ。そして厄介なのは、**当時AIのコードをなんとなく確認したときは ==『うん。LGTMだ。やるねぇ...』== と本気で思っていたところが、ことごとく牙を向いてくることである。** そう。AIのコードは一見してめちゃくちゃ良さそうに見えてしまうのである。かなり熟達した言語やフレームワークのコードを見ていてもうっかり見逃してしまうので、習熟度の低い言語やフレームワークではその違和感にも気づくことができないだろう。更に厄介なことに、この性質は **テストコードで特に顕著** だと思っている。 ちゃんとやるならば、すべてを疑ってレビューする必要がある。しかし、**そんなことをするなら最初から自分でやった方が速いのではないか？** もちろん人によってボトルネックは違う。コード生成速度が遅い人ならば、AIがとりあえず一瞬でコード生成したあとに、目視で確認して指摘をしながら仕上げていくほうが嬉しいのだと思う。しかし、**コード生成速度に自信があり、考えながらコーディングして即座にフィードバックできるスキルがあるならば、自分でやった方が総合的には速い**と思えるのだ。 以下スライドの内容は非常に共感できるとともに、人間の感覚はあてにならないと改めて思ったものだ。 <div class="link-card-v2"> <div class="link-card-v2-site"> <img class="link-card-v2-site-icon" src="https://d1eu30co0ohy4w.cloudfront.net/assets/favicon-bdd5839d46040a50edf189174e6f7aacc8abb3aaecd56a4711cf00d820883f47.png" /> <span class="link-card-v2-site-name">Speaker Deck</span> </div> <div class="link-card-v2-title"> 生成AIによるソフトウェア開発の収束地点 - Hack Fes 2025 </div> <div class="link-card-v2-content"> 登壇資料　HackFes.2025 | 日本ハッカー協会 https://hackfes2025.hacker.or.jp/ </div> <img class="link-card-v2-image" src="https://files.speakerdeck.com/presentations/001b6adcdd1f4202a701809c88ac44d6/slide_19.jpg?36255054" /> <a href="https://speakerdeck.com/vaaaaanquish/sheng-cheng-ainiyorusohutoueakai-fa-noshou-shu-di-dian-hack-fes-2025?slide=20"></a> </div> こちらの記事もよい。コメントは盛り上がっているが、記事にもある通り、この方はかなりのやり手であり、実際に新技術を試した上で筆を走らせていることがわかる。(正解とかはないと思うが、少なくとも私と同じような歩みをしてそう) <div class="link-card-v2"> <div class="link-card-v2-site"> <img class="link-card-v2-site-icon" src="https://cdn.qiita.com/assets/favicons/public/production-c620d3e403342b1022967ba5e3db1aaa.ico" /> <span class="link-card-v2-site-name">Qiita</span> </div> <div class="link-card-v2-title"> 私がバイブコーディングにあまり興味がない理由 - Qiita </div> <div class="link-card-v2-content"> 表明しておかないと、自分が最新技術を毛嫌いしてるだけの人と思われるかもと思ったので、いったん自分の考えを吐き出しておく。 自分は、情報を評価・抽出する系の作業 (文章を要約するとか、コードをレビューするとか) を AI にや ... </div> <img class="link-card-v2-image" src="https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFtYXpvbmF3cy5jb20lMkYwJTJGMzgyNDQlMkZwcm9maWxlLWltYWdlcyUyRjE1MDYwOTE4MTg_aXhsaWI9cmItNC4wLjAmYXI9MSUzQTEmZml0PWNyb3AmbWFzaz1lbGxpcHNlJmJnPUZGRkZGRiZmbT1wbmczMiZzPTRiY2RkOTIxMDYyMWFlY2Y2MjcwN2Y1NDFhZjk4Zjlh%26blend-x%3D120%26blend-y%3D467%26blend-w%3D82%26blend-h%3D82%26blend-mode%3Dnormal%26s%3Db4da4c032f8f8a2f9766383ad6aac47f?ixlib=rb-4.0.0&w=1200&fm=jpg&mark64=aHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JUU3JUE3JTgxJUUzJTgxJThDJUUzJTgzJTkwJUUzJTgyJUE0JUUzJTgzJTk2JUUzJTgyJUIzJUUzJTgzJUJDJUUzJTgzJTg3JUUzJTgyJUEzJUUzJTgzJUIzJUUzJTgyJUIwJUUzJTgxJUFCJUUzJTgxJTgyJUUzJTgxJUJFJUUzJTgyJThBJUU4JTg4JTg4JUU1JTkxJUIzJUUzJTgxJThDJUUzJTgxJUFBJUUzJTgxJTg0JUU3JTkwJTg2JUU3JTk0JUIxJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LXBhZD0wJnM9MTJjMjk2YjhjYTU1ZjhmNjQ0NzYzYThmYzY3NmQ5YTQ&mark-x=120&mark-y=112&blend64=aHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBtYWdpY2FudCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1wYWQ9MCZzPTIyNTg2MTExZGU4ZWZhMTJiN2FiNjRjY2M0Y2YwOTZh&blend-x=242&blend-y=480&blend-w=838&blend-h=46&blend-fit=crop&blend-crop=left%2Cbottom&blend-mode=normal&s=9fd1662bc1e14fc4cc31d495d0ce3ca3" /> <a href="https://qiita.com/magicant/items/7095f78f6897808597ab"></a> </div>