LLMが登場し、コードを書けなくてもソフトウェアを作成できるようになったといわれています。既存の開発者もコーディングの手間を極力減らし、設計に注力することが望ましいと言われていますが、それははたして真実なのでしょうか。
ThoughtworksのDistinguished EngineerであるUnmesh Joshi氏は、ブログ記事「The Learning Loop and LLMs」を公開し、LLM時代のコーディングの有用性を強調しています。
記事によると、ソフトウェア開発は、物理工学のように設計と実装を分離できるものではありません。設計はコードを書く過程で徐々に明らかになり、実装そのものが学びの手段となります。開発者は単なる実装者ではなく、設計を発見し、形にしていく中心的な存在なのです。
近年の大規模言語モデル(LLM)の登場により、コード生成が一瞬で行えるようになりました。しかし、これは「設計が終わった後に実装だけを自動化すればよい」という誤解を助長しかねません。著者は、自身の分散システム構築の経験を通じて、LLMを「アイデアの壁打ち相手」として活用することの有効性と限界を実感していると主張しています。生成されたコードはしばしば意図とずれ、結局は自分で書き直す必要があったからです。
学びのループ：観察・実験・応用
ソフトウェア開発における学びは、次の3つのステップを繰り返すループで成り立っています。
- 観察と理解：ドキュメントや既存コードを読み、仕組みを把握する。
- 実験と試行：実際にコードを書いて動かし、手を動かして理解を深める。
- 想起と応用：新たな課題に直面したとき、過去の経験を引き出して応用する。
このループを回すことで、知識は断片から実践的なスキルへと昇華します。
LLMは「始めるハードル」を下げるが…
LLMは、プロジェクトの初期段階で特に有効です。依存関係の解決やビルドファイルの作成など、面倒な初期設定をスムーズに進める手助けをしてくれるからです。しかし、「Hello, World」が動いた瞬間からが本当の勝負となり、そこから先は、試行錯誤と学びの連続となります。
ローコードやスターターキット、LLMによるコード生成は、初期の開発スピードを飛躍的に高めます。しかし、それらは多くの設計判断や文脈を「圧縮」して提供しているに過ぎません。少しでも要件が外れると、ブラックボックス化したコードの理解に膨大な時間がかかり、かえって生産性が落ちてしまうのです。これが「保守の崖」と呼ばれる現象です。
LLMのもう一つの強みは、自然言語からさまざまな技術的言語（Gradle、SVG、vmstatなど）への翻訳能力です。人間の意図をコードに変換する力は確かに魅力的ですが、それはあくまで「翻訳の流暢さ」であり、「言語の理解」ではありません。
同氏は、各技術の設計思想や制約を学ぶことこそが、変更に強いシステムを作る鍵になると強調しています。
ツールは進化しても、学びの本質は変わらない
LLMは、探索や初期設定を滑らかにし、開発の入り口を広げてくれます。しかし、真の力は「学びのループ」を回し続けることでしか得られません。ツールがどれだけ進化しても、深い理解と経験に裏打ちされた判断力こそが、持続可能なソフトウェア開発を支えるのです。
Hacker Newsでもこの記事に関する議論が行われており「ソフトウェア開発＝学びの行為」という主張に共感が寄せらています。Alan Kayの思想や建築家クリストファー・アレグザンダーの著書『A Pattern Language』への言及も見られました。興味のある方は参照してみることをおすすめします。
