- ソフトウェア開発の新しい時代の中で変化を感じている：自分がやっていることへの関与が薄れている
- LLMを通じて関数の作成やエラー修正作業を委任することで、没入感が低下
- 手動からauto-pilot状態へ移行し、LLMの作業をレビューして受け入れる過程が繰り返される
- 誰かが自分の技術に没頭すると、フロー（Flow）の状態に入る。これは職人になることに近い
- 主体と客体の境界が消え、複雑な問題解決に深く没頭する状態を意味する
- 多くの人は、プログラミングのワークフローにおけるLLMの最近の利用増加は、より高いレベルの抽象化作業を導入しているにすぎないと主張する
- Binary → Assembly → C → 高級言語への発展過程では、徐々により多くの権限が与えられてきた
- しかしLLMの導入は、単なる別の抽象化レベルへの変化ではない
- 上記のバイナリからアセンブリ、アセンブリからCへの変化は、認知負荷を減らし、論理に集中できるようにした
- LLMはプログラムの論理ではなく全体構造に焦点を向けさせる → 従来の変化とは異なる
- プログラムは断片が集まって作られる
- 私たちは、プログラムを組み立てるすべての断片を理解することで、自分たちのプログラムを理解する
- いまや断片を作ることを委任することで、職人の仕事を委任し、作ることを管理している
- 作ることへの関与が薄れ、LLMが作るコードに対する私たちの所有感も小さくなる
- つまり、私たちはクラフトマンシップをマネジメントに置き換えた
- 自分たちが作る正確な断片よりも、作業の結果により関心を持つようになった
- プログラミングが目的ではなく手段になってしまった
- 幸いにも、あるいは不幸にも、コードでは依然として問題が発生し、コードの文脈を把握して修正しなければならない
- これは、プログラミングの過程で依然として人間の介入が必要であることを意味する
- LLMエージェントを使うことで、プログラミングにより深く没頭できる可能性がある
- 私たちは高レベルの抽象化に集中し、LLMエージェントは懸命に変更を進める
- しかし、まだ適切なツールがない
- 連続する多くの変更に対する認知負荷が大きく、これを処理する方法が必要
- 人間の記憶には限界があり（短期記憶では7±2個の項目しか記憶できない）そのため、さまざまなレベルの抽象化で情報を表現できるようにうまく設計されたツールが必要
- そうすれば、細部を把握しつつ、より大きな全体像へとズームアウトしていける
2件のコメント
マネージャー(Manager) vs. 職人(Craftsman)
クラフトマンシップは、必ずコードに対してだけ持つべきものなのでしょうか？ ソフトウェアや、プロダクトそのものに対してクラフトマンシップを持つこともできるのではないでしょうか？
もともとプログラミングは目的ではなく手段でした。
こうしたツールの発展は、人間がつまらないことではなく、より大きな思考やデザインに時間を注げるように進んできたのです。
コンパイラ、オペレーティングシステム、スクリプト言語など..