この資料は以下のイベントの登壇用の殴り書きです
https://hack-at-delta.connpass.com/event/350588/
今までの資料を引用して話すので、この資料はアウトラインです。
- ハイプサイクルにおけるアーリーアダプター相当で手を動かす
- ハイプ・サイクル https://mba.globis.ac.jp/about_mba/glossary/detail-20659.html
- https://www.thoughtworks.com/radar を読む
- イノベーターっぽい人達をSNSで監視してる
- 一定の熱量を感じたら自分でも動かして評価する
- 破壊的イノベーションを逃すな
- 破壊的イノベーション - クリスチャン・クリステンセン https://www.amazon.co.jp/dp/4798100234
- 星取表で考えない。新興技術は初期段階で星取表で負けてる
- 先発から後発へ星取表が出てくる時、大抵は負けはじめたシグナル
- 先発「(後発)は～がない。～もない。私達の製品は～」
- 後発「別にそんなところで勝負してない」
- 特にOSSの世界では先進性によってコミュニティが発生し、星取表は時間で埋まる
- webpack => (rollup, esbuild) => vite
- 経験的に...
- 2012: Docker
- 2015: React
- 2017: Block Chain
- 2020: k8s
- 2025: Cline等のコーディングエージェント
- コーディングエージェントはこれらに相当するものと判断
- 「動きが速すぎるから落ち着いたらやる」は、成長コンテキストを見失って逆に学習コストが上がる
- 専門外でもちょっとずつかじって自分で判断する必要はある
- React のとき...
- もうこれ以上 jQuery で疲弊したくない！！！！
- 「なぜ仮想DOMという概念が俺達の魂を震えさせるのか」を書いた
- 明確な技術的な優位を提示して、現場で使わせてもらう、アーリーアダプターとして経験値を蓄積する
- 日本の技術トレンドは海外と比較して 1.5~2年ぐらい遅い
- 既に GitHub Copilot は手癖になっていた
- 元々
// 関数の実装仕様<TAB>でコードの半数を生成していたはず
- 元々
- mizchi/previs (2023)
- 自然言語からReactのコード生成エージェントを試作
- 当時の結論: モデル性能の進化を待ったほうがいい
https://mizchi-20240920-nextbeat-slide.pages.dev/
最終的には 試行錯誤の手数で人間のプログラマを圧倒する
予想: 人間側がボトルネックになる
実際こうなった。
モデルの性能向上とは別に、プログラミング環境へのアダプタこそが必要だったというオチ。
自分はティム・オライリーが The End of Programming as We Know It を書いたことで、自分の中の踏ん切りがついた。
https://www.oreilly.com/radar/the-end-of-programming-as-we-know-it/
Google 翻訳
今まさに到来しようとしている魔法は、これまでで最も強力なものです。そしてそれは、私たちが探求と創造の深遠な時代に入り、その魔法をどのように機能させ、その力から新たな利点を引き出すかを理解しようと努めていることを意味します。この技術を採用する賢明な開発者は、付加価値を生み出すより高度な創造性に注力することで、これまで以上に多くのことを実現できるため、需要が高まるでしょう
熟練プログラマーであり、先見の明のある技術観察者であるスティーブ・イェッジ氏は、置き換えられるのはジュニアおよび中堅プログラマーではなく、新しいプログラミングツールやパラダイムを受け入れず過去に固執するプログラマーだと指摘しています
シラス氏「産業革命期における動作の自動化との類似点は顕著です。今日の自動化はまだ粗雑です。私たちは、水を汲み上げたり、ハンマーを叩いたりするのと同じような認知的作業、つまり要約、パターン認識、テキスト生成といった基本的な作業を行っています。この新しいエネルギー源のための堅牢なエンジンを構築する方法はまだ解明されていません。AIはまだ機関車の段階にも達していません。」
Google Chromeのユーザーエクスペリエンス責任者であるアディ・オスマニ氏は、これを「70%問題」と呼んでいます。「エンジニアはAIによって生産性が劇的に向上したと報告していますが、私たちが日常的に使用するソフトウェア自体は、目立った改善が見られないのです。」彼は、AIコード生成ツールを扱う非プログラマーは素晴らしいデモを作成したり、簡単な問題を解決したりすることはできるものの、複雑なプログラムの最後の30%で行き詰まってしまうと指摘しています。
これはプログラミングの終わりではありません。プログラミングの新たな改革の始まりです。
https://zenn.dev/mizchi/articles/all-in-on-cline
Cline は暴走列車みたいなもので、最初の指示以外は人間なんかどうでもいいと思っているフシがある。その結果、これ抜きに実現できない速さを獲得し、自分はこれ無しで我慢できなくなった。正直、かなりの中毒性がある。
自分はプログラマが不要になるとは思っていない。プログラマというのはコードを書く作業員ではなく、対象のドメインを抽象して構成要素を分解・再構築する思考訓練を受けた専門家だと思っているからだ。
自分が理解してないものを実装するには「結果から逆算されうる内部構造に対する直感」というかなり高度な思考が要求されることになる。今までプログラマではないから人がプログラマに仕事を依頼する時は、この感覚だったんだと思う。
高度なAIは自分の鏡みたいなもので、AIから引き出せる性能は、自分の能力にそのまま比例する。プログラミング作業が少し自然言語に近づいただけで、実際の動作レベルがプログラミング言語であることは変わらないし、デバッグ時に必要とされる水準は変わっていないし、なんならより難しくなっているかもしれない。
- ここでいう Cline は Cline 型のヘッドレスIDE統合環境のことで、VSCode Cline だけじゃない
- Cursor, Windsurf, CopilotAgent, Claude Code, Codex, Aider...
- 「AIエージェントにシェル実行権限と VSCode を操作する権限を与えるとどうなるか？」というパンドラの箱を開けたことが Cline の歴史的な意義
- 2024末から一部で話題になっていたのを認識
- 2025/2頃に、 Cline+Claude3.5 で実用に足ると判断
- 「AIの胡散臭さ」に対して、実利を提示する必要がある
- 日本のSNSでは画像生成界隈のネガティブイメージもあり胡散臭い
- Cline の強烈さは手元で動かさないと伝わらない
- 暗号通貨と同じハイプ技術扱いされてしまう懸念
- 背中を押すなら、今しかねえ
- LSP/インテリセンス: 静的解析でトップレベルシンボル、または
.から先の補完候補を提案 - Copilot: 現在のファイルを根拠に、
Tab押したときにステートメントや関数ボディ部分まで補完を提案 - Cline: 自然言語によるコードの生成を試み、その修正ループを自動化(上手くいくとは限らない)
https://zenn.dev/mizchi/articles/ai-model-current-snapshot-2025-0414
- モデル
- ショートコンテキストの Claude 3.7
- ロングコンテキストの Gemini 2.5
- 安価でプロトタイピングに便利な DeepSeek v3
- コーディングエージェント
- Cline or Roo
- 最終的にはビルトインの GitHub Copilot Agent が勝ちそうな気がする
Aider のスコア見ると、現時点でコスパ的には Gemini 2.5 Pro 一強
https://aider.chat/docs/leaderboards/
現時点で複数モデルのワークフロー設計は逆に難しい(プロンプトキャッシングの効率性問題)
- 技術検証/プロトタイピングが低コスト化
- Well-Known で Well-Defined な技術範囲は、もはやAIの独壇場
- ウェブ標準仕様や古典的アルゴリズムの参照が容易に
- 大規模コード理解に難があるのは変わらず
- 品質が悪いコードでは、モジュールを組み立てられない
- Claude は 1000 行, Gemini は 3000 行あたりで破綻する
- おそらく期待値コントロールに失敗している
- バイブコーダーに「設計」とは難だったのかが伝わってない
- プロトタイプとプロダクションの間の、深くて険しい壁が認識されてない
- 「難しく考えすぎてません？シンプルに考えましょうよ」問題
- まじめに考えてんだよ！！！！
- 「眼前に存在しない潜在的な状態の組み合わせについて考える抽象能力」は現状プログラマにしかない
- 認識できないものは、語り得ない...
- https://zenn.dev/mizchi/articles/json-for-everyone
- mozilla/readablity を mizchi がバイブコーディングでDOM非依存版に移植
- macopy さんがバイブコーディングで Go に移植
こうやって雑に移植がある程度機能するのはいいが、開発をやっているという感覚がないし、コードに対するオーナーシップも薄い。OSSにおいてコードのオーナーシップはメンテナンスの頻度やissue対応に影響してくる。多分こんな雑実装であるものにそんなに人は頼ってこないとは思うが。。。
また、AI雑ライブラリをうっかり使ってしまって、バグ修正や機能要望をしたものの、作者が飽きたりトークン代を払う金が無い等で対応されないケースも出てくるだろう。しかし人間がみんながみんな継続してパッションを持って手で書いてOSS等を書いているわけでは無いのである。その時はあなたがトークン代を払って問題を解決する未来が来るかもしれない。
(自分も macopy さんも経験豊富な側のプログラマで、あえてバイブコーディングしてるという文脈)
ただし、うまくいったのは、そもそも確率的な処理であること、 ARC90 のコアアルゴリズムを Claude/Gemini が学習済みだったから、という認識
- 今の自分の用途
- ライブラリのAPIの使い方を確認
- 認識したらコード全部捨てて自分で書き直す
- テストコードの量産
- とりあえずカバレッジを上げる
- マークアップ
- お絵かきAPIだと思って複数回 JSON 色付けさせて、いいやつを採用
- write 権限は奪った。レビュー前提
- ライブラリのAPIの使い方を確認
- 大規模化
- 大規模下で明示的にドキュメントを指示すると上手くいくが、人間のコストが重い
- 低レベルエンジニアにコードベース荒らされてる感覚。write_file 権限は取り上げた。
- モジュール単位で分割統治したいが、今の CLINE だと制御しきれない
- 例外設計が苦手すぎ問題
- 全部を try catch して握りつぶしてしまう
- Xでポストしたら賛同が集まったので、そうなんだと思う
- 短期的な変化
- AI(Devin)に勝てないジュニアエンジニアの雇止め
- 既存エンジニアはAI向けのドキュメント検索アダプタ(FunctionCall/MCP)を大量に作ることになる
- フロントエンドは一生 ChatUI 作らされる
- 年内にバイブコーディングへの失望期が来る
- AIの解釈コスト観点で、仕様をプレーンテキストで記述する価値が上がる
- Notion、エクセル、パワポで書かれたリッチテキストは解釈で不利
- 入力コストが 100倍以上のオーダーで違う
- MSから変換ツールが出てる https://github.com/microsoft/markitdown
- Notion、エクセル、パワポで書かれたリッチテキストは解釈で不利
- 長期的な変化
- AIコーディングに適応できないエンジニアが駆逐される
- セキュリティがより攻撃者有利/防衛不利に
- 攻撃側: 攻撃コード生成が高速
- 防衛側: バイブコーディングで中身がブラックボックス化したり、プロンプトインジェクションを受けやすくなる
- AI は選択肢ではなく前提になる
- モデル性能理解と生成されるコードの品質予測が必須のドメイン知識になる
- 言語化・モデリング・概念の理解により比重が置かれる
- エディタ補助が強くなってるので、逆に switch 文の文法が曖昧でもコードは書ける
- コンテキストに応じたドキュメントの参照を指示することが、専門家としての役割になる
- コーディングのためのメタドキュメント整備
- 型と linter に思想を押し込む
- エキスパートのポジションを死守
- エキスパートとして AIに負けないドメイン知識を、最低一つ持つ
- それ自体より、AI を疑うメンタリティを獲得するために必要
- ドメイン知識を MCP/Function Calling として実装していく
- コードを書くことと同じぐらい、コードを生成するパイプライン設計が重要
- 「自分を部分的に再現するプロンプト」を用意して、レビューや初期検証を高速化
- コード評価のサンドボックス設計が重要
- 言語化・設計・検証
- 手を動かして性能を微分することのみ将来の予測が可能になる。手を動かせ。
- 非連続的な進化はそもそも予測できない ので、妄想と切り捨ててよい
- 人類のリソースが注ぎ込まれてるので非連続的な進化が起こること自体は予測可能だが...
- 本当ならエンジニア全員がモデルをチューニングしてる状態が望ましいが、コストとスケール則の関係で厳しい
- 最新モデルは部分的に一般的なプログラマの能力を超えつつある
- 現時点で AI はコンテキストを認識できるレベルにない
- 最終的には人間は手数で圧倒されるのは自明
- 自分がAIにとって語るに足る専門家である必要がある
- ユーザーが認識できないものを指示(プロンプト)で与えても検証できない
- そのうえで、現時点で開発を任せるのは、自分は無理
驚き屋ばっかりで、手を動かした肌感込みの情報が本当に少ない
- https://note.com/npaka
- https://blog.lai.so/
- https://azukiazusa.dev/blog/
- https://joisino.hatenablog.com/
あとはモデル開発側の公式情報と、手を動かした自分だけを信じましょう