コーディングエージェントが、私が使っていたあらゆるフレームワークを置き換えた
(blog.alaindichiappari.dev)> 「ソフトウェアエンジニアリングが戻ってきた」
- フロンティアAIモデルとコーディングエージェントの進化により、自動化プログラミングの時代が始まり、コードを1行ずつ直接タイプする手作業は消え、ソフトウェアエンジニアが再び本質的な設計と思考に集中できるようになった
- 昨年末からツールとモデルの成熟度が劇的に向上し、よく構成された環境ではアーキテクトの役割に専念しつつ、必要に応じて自ら介入して修正できる作業スタイルが可能になった
- Web・モバイル・デスクトップ開発に蓄積された不要なフレームワークと抽象化レイヤーは、本当の複雑さを解決できないまま、むしろ問題を増やしてきた
- フレームワークが解決すると主張する3つの問題――単純化、自動化、人件費削減――のうち、正当な価値があったのは自動化だけだったが、AI自動化がこれすら代替可能になっている
- Google、Meta、Vercel などハイパースケーラーが設計したシステムのオペレーター(operator)に成り下がるのではなく、自分自身の設計と製品を直接作る、本来のエンジニアリングに戻るべきだ
自動化プログラミングの台頭
- Antirez が名付けた "automated programming" というフレーミングは、「vibe coding」よりも本質をはるかによく捉えている
- 印刷機、織機、組立ラインのように、自動化は歴史的革新の核心であり、今回の変化もその延長線上にある
- 2025年12月以降、フロンティアモデルとコーディングエージェントの能力が劇的に変化しており、注意深く観察している人にはすでに明白なレベルだ
エンジニアの役割の変化
- アーキテクチャ、トレードオフ、プロダクト判断、エッジケースなど、深い思考を要する仕事は今も残っている
- 消えたのは、あらゆるコード行を自分で打ち込む疲弊し消耗する手作業だ
- クリーンで徹底的に整えられた環境でモデルとツールを使えば、レンガを自分で積まなくても建築家の役割を果たすことができる
- 20年間にわたり自分でコードを書いてきた経験がその土台にあり、気に入らなければ自ら中に入って理解し、修正したうえで設定を更新できる
- 必要なツールを即座に作り出せるため、構想した技術を実現することにより多くの時間を割ける
フレームワークと不要な複雑性
- Web、モバイル、デスクトップ開発では、長年にわたりフレームワーク・ライブラリ・ツール群の巨大な汚染が蓄積されてきた
- 意味のあるものを抽象化しない抽象化レイヤーが幾重にも積み重なり、1つの問題を解決すると言いながら10個の新たな問題を生み出す
- 業界全体が、ソフトウェア構築の真の複雑性に向き合って思考を研ぎ澄ます代わりに、既製品の思考を買う道を選んできた
- 折れた脚をシルクで包むことのように、見た目は良くても脚はなお折れたままだ
フレームワークが解決すると主張する3つの問題
- "単純化(Simplification)": エンジニアが自ら設計することを恐れ、他人の構造を盲目的に受け入れる現象
- 目的から逆算して設計する代わりに、ワンサイズフィッツオール(one-size-fits-all)な設計をどこにでも当てはめる
- これは単純化ではなく、知的降伏(intellectual surrender) だ
- "自動化(Automation)": ボイラープレートコード削減という唯一納得できる価値
- ORM、CRUD管理、コード生成、APIドキュメント化など、反復的だが不可欠な作業の自動化
- しかし、まさにこの点でAIがすべてを変えつつある
- "人件費削減(Labour cost)": カンファレンスのスライドには出てこない静かな理由
- Google、Meta、Vercel がプロダクト構築とコード配布の方法を決めるようになれば、ソフトウェアエンジニアの代わりに「React開発者」を雇える
- 教育不要、プラグアンドプレイ、簡単に置き換え可能な歯車(cog)のような人材
- それはエンジニアリングではなく、運用(operating) だ
新しい作業スタイルの実際
- 2年以上このやり方でほぼ欠陥なく開発してきたが、本当の革命は昨年12月から起きた
- 不要な複雑性を取り除き、アイデア中心の複雑性に集中できる機会が開かれた
- ボイラープレート除去コストがほぼ0に収束し、同じコードを2度書く必要がなくなる
- 問題に正確に合った目的特化型の小さなツールを即座に構築できる
- 派手なモノレポマネージャなしでも、シンプルな Makefile で99%のユースケースを満たせる
- 問題が本当に複雑になったときに考えればよく、それ以前に決して先回りして解決しないことこそがエンジニアリングだ
- カンファレンスの壇上で誰かがいつか遭遇すると言った問題ではなく、いま抱えている問題を解決すべきだ
Bash と基本ツールの再発見
- エージェントは、数十年にわたり存在してきた基本ツール(basic tools) の扱いに非常に長けている
- Bash は1989年に誕生し、いまでは最もありふれたモデルでさえ、世界の誰よりも Bash をよく知っている
- コーディングエージェントは、複雑で高コストなMCP構成から Bash ベースのシンプルなエージェントループへ移行しつつある
- 最も古いツールこそ、最も将来に強いツール(most future proof) なのだ
フレームワーク依存のコスト
- ほとんどのユースケースでは、機能の10%しか使わない高価で欠陥の多いフレームワークや付随ライブラリは不要だ
- 保守、セキュリティアップデート、設計上の制約など、見えないコストが大きく、それが開発者の自由を制限する
- このトレードオフを受け入れ続けるなら、数十年に一度の最大の機会を逃すことになる
- Google、Meta、Vercel など大企業の設計思想に従属する構造には警戒すべきだ
- 開発者は自分自身の思考と美意識を信じ、自分だけのツールとプロダクトを構築すべきだ
> 「折れた脚を絹で包むのではなく、本当に自分自身のものを作りなさい」
- 開発者は自分自身の思考と美意識を信じ、自分だけのツールとプロダクトを構築すべきだ
5件のコメント
これこそ、本当の意味で保守を困難にする開発手法ですね。AI時代に合わせて、新時代でも一生自分の居場所を守る方法を実践している方です。
「ほとんどのユースケースで機能の10%しか使わない、高価で欠陥のあるフレームワークや付随ライブラリ」という言い方には、正直あまり共感できませんね……。プロジェクトに合ったサイズの環境をきちんと選ぶことこそ美徳だったのではないでしょうか。大して機能を作らなさそうなら、
expressのような軽いものを使えばいいわけです。わざわざexpressを置き換えるものを最初から作る必要があるのかと……。機能は多いのに大して使わない、という意味なら、むしろ Apache や nginx のようなWebサーバーのほうがそうでしょう。それが重いからといってWebサーバーを最初から作るんですか。普通に設定して使えばいいだけです。
フレームワークという、よく整理されていてAIが十分に学習した資料があるのに、あえて自分だけの新しいものを作る必要があるのでしょうか。むしろ生産性を下げることのように思えます。
アーキテクチャを設計するコストを減らし、本質（サービス）に集中できるようにしてくれたものを、あらためて捨てる必要はないと思います。
うーん……こういうプラクティスって、Cursor が使用量無制限を提供していたときのものではないでしょうか……。むしろ、どうやってトークンを節約しつつ AI をうまく補助するか？ が、少なくとも当分の間はこれからの方向性のように思います。
高価なトークン価格がなくても重複を排除できるのに、フレームワークを使わない理由は何でしょうか？
Hacker News の意見
近い将来、多くの開発者や企業が AIの見栄 によって大きな衝撃を受けそうだと思う
今はAIで何かを作れるが、本当の問題は自分でぶつかってみないと分からない部分だ
結局、「雰囲気コーディング(vibe code)」だけをする人たちは現実的な限界にぶつかり、システムの実際の動作原理を理解する人だけが生き残るだろう
2分でバグを修正してマージできたし、「システムを理解している」ことと「自分でコードを書かない」ことは両立可能だ
AWSはこの方向に巨大な賭けをしており、非決定的ツール がますます安定化するにつれて、人間レベルの品質を超える可能性が高い
理解なしに任せれば、成果物の正確性や保守性、拡張性は保証できない
だが、そういう人たちと一緒に働くなら、なぜ何十万ドルも払って彼らとLLMの購読料まで負担しなければならないのか疑問だ
もちろん「雰囲気コーディング」で作ったアプリが壊れる事例は出るだろうが、テストやバージョン管理、ドキュメント整備を並行して行うチームはむしろもっと繁栄するはずだ
結局、バランスの取れたアプローチが重要だ
そのうち「de-slopperボット」が登場するかもしれない
フレームワークを使う理由は、その設計者たちが自分より 多くの問題やスケール課題 を経験しているからだ
プロジェクト初期は簡単でも、規模が大きくなると再設計は苦痛になる
こういう文章を読んでいると、文章自体がLLMに書かれたように感じることがよくある
「レンガを切って縫い合わせる」式の比喩は、むしろその矛盾を示している
スタック全体を自作するのは今でも非効率で、保守コストも高い
ただし今は、問題に合わせた カスタムコンポーネント を簡単に作れる点が違う
新しいものを学ぶ必要はなく、慣れたフレームワークで十分だ
自分の問題、プラットフォームの問題、そしてフレームワークを迂回する問題だ
コードを書く苦痛を語る文章が妙に感じられる。コーディングはむしろ簡単な部分だ
もし トールキンがAIを使っていたら、プロンプトを磨くことに時間を浪費していた気がする
特に難しい部分ほど、AIの助けはむしろ毒になる
AIの記事では「AIがコードを代わりに書いてくれるので思考に集中できる」と言うことだ
同じ人たちなら矛盾している
最近はClaude Codeに任せると、たいてい数分で解決する
だが私は自分で書いたコードの方を信頼する。結局、速度より 理解の深さ が重要だ
ウォーホルのように新しい道具をうまく活用するなら、それも芸術だ
LLMは創作の初期段階を助ける道具にすぎず、天才性は依然として人間から 生まれる
Node.jsのセキュリティパッチを面倒だと思うのは誤解だ
それは 特権 だ。自作ソリューションにはセキュリティコミュニティもなく、脆弱性も多い
React開発者は簡単に見つかるが、「AIが作った独自フレームワーク」の開発者はいない
大したことではない
コーディングエージェントとフレームワークの中間地点 は存在する
私は今でも同じツールを使っているが、反復作業はエージェントがこなし、
私はアーキテクチャやエッジケースに集中する
エージェントを無視するのも、盲信するのも極端だ
本当の実力は いつハンドルを握るべきかを知っていること だ
この文章の問題は、フレームワークと「本物のエンジニアリング」を 対立的に 捉えている点だ
Vercel、Next.js、Firebaseのようなプラットフォームは 即時デプロイとCI/CD を可能にする
昔Jenkinsで自分でセットアップしていた時代を思えば革命的だ
本当のエンジニアリングとは「再発明」ではなく、素早く顧客に届けること だ
AIが既存フレームワークを 実戦検証なしに再実装 するのは非効率だ
エコシステムや共通パターンがなければ協業は難しい
経験のない開発者がAIを誤用するのは昔と変わらない
自作するとドキュメント、ミドルウェア、保守性のすべてを失うことになる
「APIをつなげられる」と改めて気づくレベルだ
だが、こうした発見が トレードオフの理解 を伴うわけではない
私は最近6か月間、Cursor + Opus 4.x で組み込み開発をしてきた
LLMはソフトウェアだけでなく、回路設計、CAD、CNC まで助けてくれる
たとえばST7789ベースのディスプレイ用ラッパー関数を、3回のプロンプトで完成させた
今ではLVGL、TinyUSB、圧縮、暗号化以外にはライブラリをほとんど使わない
LLMが作った 目的特化型関数 は小さくて速く、不要な抽象化がない
多くのライブラリはもう 退場する時期 だと思う
.NETのようなものは代替不可能だが、汎用関数の集合は十分に置き換え可能だ
ダブルフレームバッファ まで含んだ完成コードをすぐに出してきた
コーディングのつらい部分はタイピングではなく、人との協業、テスト、設計思考 だ
最近いちばん大変だったのは ロックフリー・データ構造 を設計することだった
LLM時代であるほどフレームワークの価値は高まる
LLMは学習データのおかげで、Reactのような馴染みあるパターンに強い
人間が介入してデバッグできる点も重要だ
AGIが来たとしても、効率的なフレームワークを あえて再学習しない理由はない
こうした対話そのものが興味深い実験だ