🧠Agentic Codingについて思うところ

いわゆる[[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> ## AIを使ったPRは多重下請けに似ている #2026/01/28 元々プルリクエスト(機能追加)を受け付けるのはあまり好きではない。 - 自分の方向性と異なるプルリクがくることが多い - 断るにしても既に作成済のため気を使ってしまう - 気を使う必要はないのだけどこれは性分 - レビューが面倒 - コメントするにしても気を使う - 自分で修正するにしても、自分のコーディングスタイルとあっていなかったり、背景を察したり/確認したりするのが面倒 - 自分でやったほうが早いになりがち - プライベートまでマネジメントしたくない - 仕事なら人を動かすのは大事なのでやるけどそれがAIの普及によって悪化していると感じる。特にPRがAI頼みで作られたものだと作成者をブローカーとした不毛なバケツリレーになって旨味が全くない。それなら **AIに直接聞いたほうが速い**。もっと言うと、**自分が欲しい機能なら自分でAIに頼んだ方が速い。** まとめると - 手間がかかる - 気も使う - 時間も使う - (自分が期待する)完成度が下がるということで多重下請け構造の歪に似ていると感じた。もちろん、ちゃんとしたPRに関してはそんなことはないけれど、打率としては下がっているのではという印象。一方で、FRのPoCとしてとりあえず作成したものを動画とかで見せてもらえるのは非常に助かる。認識齟齬が防げるので。 > [!note] > 私は[[OSS]]の機能追加PRは基本拒否している(PR templateで記載している)ので、実際に疲弊しているわけではない。それでもたまに送ってくる人いるけど、ちゃんと警告している以上は拒否してる。 ## AIのオーケストレーションに興味が出てきた #2026/02/20 自己修復力に長けた[[Claude Opus 4.6]]や[[GPT-5.3-Codex]]が登場し、とうとう要件を伝えたら安定してプログラミングをしてくれるレベルに到達した気がする。ともなれば、コーディングという作業自体は丸投げできるフェーズに入ったと思ってもいい。 ### コードを書かなくなった実際のところ、2026年になってから[[Django]]のAPIではソースコードを全く書かなくなった。また、[[Claude Opus 4.6]]が登場してからは、得意分野であるコーディングが好きなWeb/[[TypeScript]]でもソースコードを書く量が激減した。プロダクションコードはもちろんのこと、[[Playwright]]で構成している[[E2Eテスト]]のコードもだ。ベースの設計をしっかりやって責務を分離しておけば、[[Claude Opus 4.6]]はほぼ1発で期待するコードを書いてくれる。planモードでの質問も実にするどく、ここで上流工程の考慮漏れが見つかることも珍しくない。 ### 仕事でちゃんとAIが使えるようになった地味に大きいのが **仕事で使っている[[GitHub Copilot]]の利用制限が事実上無くなったこと**。以前は1ヶ月で300プレミアムリクエストまでという制限があったが、それが撤廃された。制限があったときは、本当に必要なときのために温存しておかなければいけなかったので、なかなか気軽に利用できなかったし、実験をする気にもならなかった。今では迷ったらすぐに利用できる。1プレミアムの価値は実質6円程度で、[[Claude Opus 4.6]]を使っても20円もかからない。人間が数十秒~数分試行錯誤したり考えている方が遥かに高いのだ。トラブルや既存コードの調査、軽微なバグ修正、簡単な機能改修では間違いなく[[AI]]の方が速いと言い切れる。加えて、これはプライベートへも影響する。今までは、仕事でコーディングが必要だったため、プライベートで本腰入れて[[AI]]にダイブする気になれなかった。なぜか。**[[Agentic Coding]]に慣れてしまうと、仕事では逆に成果を出せなくなってしまうから**だ。今は仕事で[[AI]]が普通に使えるようになったので、プライベートで[[Agentic Coding]]にのめり込み上達することは、直接仕事の成果につながる。むしろ悠長にコーディングしている方が、(成長という意味では)まずいだろう。息抜きであれば問題ないが...。 ### [[ターミナルマルチプレクサ]]の伏線ちょうど今月のはじめくらいから、[[Zellij]]に再びチャレンジしたというのも大きい。一度は見送ろうかと思ったが、踏ん張って今ではほとんどの作業を[[Zellij]]上で行っている。キーバインド衝突などの問題に対しても戦略的に解を求めることができた。正直なところ、複数のエージェントをオーケストレーションできるほど[[Zellij]]を使いこなせていないし、自分の脳([[コンテキストスイッチ]])もその段階に至っていない。これから日々鍛錬をすることで、少しずつそのような自分に[[アンラーニング]]して成長していきたいと思う。 [[Neovim]]のときもそうだが、自身の重大な転換期には大体伏線がある。[[Zellij]]もその1つであるだろうという根拠のない自信に満ちているのだ。 ### ベテランの資料を見ていくつか[[Developers Summit]]の良い資料が流れてきた。ちょうど今年度の業務が一段落し、来年度の目標を考え始める段階なので刺激を受ける。 <div class="link-card-v2"> <div class="link-card-v2-site"> <img class="link-card-v2-site-icon" src="https://hirokidaichi.github.io/favicon.ico" /> <span class="link-card-v2-site-name">hirokidaichi.github.io</span> </div> <div class="link-card-v2-title"> なぜ、AIで生産性があがっていると錯覚してしまうのか </div> <img class="link-card-v2-image" src="https://hirokidaichi.github.io/presentation/images/_ogp/devsummit.png" /> <a href="https://hirokidaichi.github.io/presentation/devsummit.html#1"></a> </div> <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で浮いた時間で何をする？ 2026春 #devsumi </div> <div class="link-card-v2-content"> Developers Summit 2026https://event.shoeisha.jp/devsumi/20260218 </div> <img class="link-card-v2-image" src="https://files.speakerdeck.com/presentations/60f6cfd76f22405bbb5398228e8ba9ff/slide_0.jpg?38479424" /> <a href="https://speakerdeck.com/konifar/aide-fu-itashi-jian-de-he-wosuru-2026chun-number-devsumi"></a> </div> また、ベテランエンジニアの風向きも変わってきている気がする。これはモデルやツールの進化が及第点に達し、経験豊富な方々から見ても実用的であると判定された証拠だと思っている。 <div class="link-card-v2"> <div class="link-card-v2-site"> <img class="link-card-v2-site-icon" src="https://iwashi.co/favicon.ico" /> <span class="link-card-v2-site-name">iwashi.co</span> </div> <div class="link-card-v2-title"> プログラミングは今が一番楽しい </div> <div class="link-card-v2-content"> Javaで始まり、WebRTC PF開発、マネジメント、そしてAIコーディングを経て、いま改めてプログラミングが一番楽しいと感じている理由を書きました。 ... </div> <img class="link-card-v2-image" src="https://iwashi.co/assets/images/ogp/2026-02-15-programming-is-most-fun-now_ogp.png" /> <a href="https://iwashi.co/2026/02/15/programming-is-most-fun-now"></a> </div> <div class="link-card-v2"> <div class="link-card-v2-site"> <img class="link-card-v2-site-icon" src="https://assets.st-note.com/poc-image/manual/note-common-images/production/icons/android-chrome-192x192.png" /> <span class="link-card-v2-site-name">note（ノート）</span> </div> <div class="link-card-v2-title"> エンジニアは全員コーディングエージェントにダイブしたらええんちゃう？という話｜牛尾　剛 </div> <div class="link-card-v2-content"> 私も、最近まで、GitHub Copilot や、Claude Code を使ってそのヤバさに気づき、様々な葛藤を体験した。そのあたりは次のブログにも書いた通りだ。しかし、最近考えが変わってきた。これ、クッソおもろいやんw ... </div> <img class="link-card-v2-image" src="https://assets.st-note.com/production/uploads/images/252461431/rectangle_large_type_2_b6947c5ac3a42a540f959b57bebefaf6.png?fit=bounds&quality=85&width=1280" /> <a href="https://note.com/simplearchitect/n/n0de0a2e8bc6e"></a> </div> ### というわけで今年度も残り1ヶ月ちょっと。主に朝の時間を使って、複数のエージェントをオーケストレーションできるようにフローや開発環境・セルフマネジメント方法を改善していきたい。