エンジニアリングのボトルネックは移った

長年にわたり、私はエンジニアリング上の決定を一度下したら石に刻まれたかのように扱ってきました。間違った抽象化を選べば、何年もその代償を払うことになります。間違ったサービスの境界を選べば、四半期単位でそれを解きほぐすことになります。そのコストが、私の行動の慎重さを形作っていました。つまり、仕様をどれだけ注意深く定義するか、レビューをどれだけ実施するか、何かにコミットする前にどれだけ待つかということです。

この直感が完全に間違っているとは思いませんが、最近ではその重要性が薄れてきていると感じます。AI支援開発により、最初のパスを作成するコストが非常に安くなり、ボトルネックは静かに移動しました。高価な部分はコードを書くことではなくなりました。今では、何を書くべきかを知ること、微妙に間違っている箇所を見つけること、そして実際に何が重要かを判断することです。

言い換えれば、以前は慎重さが重要でした（特に大規模な場合）が、今では判断力がその役割を引き継いでいます。特にここ数ヶ月で、エンジニアリングに対する考え方が変わりました。

前後の考え方

AI支援開発以前は、依存関係の変更や負債の整理には特定のコストが伴っていました。それは時間だけでなく、注意力とリスクです。インターフェースに手を加えるということは、まず全ての下流コンシューマーを監査することを意味しました。コアモジュールをリファクタリングするということは、全ての呼び出し箇所をマッピングし、見落としを吸収することを意味しました。

私は設計を守り、クリーンアップを先送りし、抽象化を健全な期間以上に守り続けました。なぜなら、混乱を引き起こすには、スプリントの途中で正当化できない労力が必要だったからです。

しかし今では、AIによって検証、移行、リファクタリングが十分に安価になり、試して、検査して、取り消すことができます。移行パスをドラフトし、差分をレビューし、間違っていれば午後にはアプローチを放棄できます。実際の時間や労力の損失はありません。

かつて無期限に先送りしていた探索的リファクタリングも、今ではそれらを明らかにした機能作業と同じセッションで行われます。

本当の変化は、注意力をどこに使えるかです。コードに触れることが高価だったときは、それを守りました。安価になった今では、それを探索できます。

現在、慎重さは本当に逆転が難しい決定にのみ属します。ロールバックのないデータ移行、外部依存関係のあるAPI契約、トポロジーに組み込まれたアーキテクチャの選択などです。それ以外はすべて自由に扱え、それが設計に対する考え方を最初から変えます。

3つの具体的な変化

古い本能は純粋さを追求することでした。つまり、正確なバージョンを固定し、フォークを避け、すべての上流依存関係を神聖なものとして扱うことです。新しい本能はより実用的です。AI支援検証により、局所的にパッチを当てた依存関係を自分の関心領域に対して数秒でテストできるようになりました。さらに良いことに、モデルは依存関係からの移行も同様に容易にしてくれるため、本当にロックインされることはありません。「試して、次に進む」は上流を待つよりも優れており、特に上流が準備できたときにモデルに再度移行を依頼できるからです。

古い本能はクリーンアップ作業を専用のスプリントに溜め込むことでした。負債の返済は高くつくため、まとめて処理するか無視していました。私のスタックは主にDevin、Cursor、Codexで構成されており、リファクタリングやスタイル修正が非常に高速に行えます。それでも、厄介なバグを掘り下げる必要がある場合に備えて、人間が読みやすいコードを好みます。この段階的なクリーンアップは、専用のサイクルだけでなく、機能の間にも実行可能になりました。これにより計算式が変わります。負債はそれほど怖くなく、先送りするものではなくなりました。しかし、それは依然として現実です。AIツールは労力を圧縮しますが、何をいつ修正すべきかを判断する能力は圧縮しません。

チャットやエージェントインターフェースは、画面中心の考え方にペナルティを課します。製品のコアロジックが特定のUI形状に密結合している場合、インタラクションモデルが変わるたびに再構築する必要があります。そして今、インタラクションモデルは急速に変化しています。新しい本能は、UIを明確に定義された動作の上の薄くて使い捨て可能な層として扱うことです。変更や削除が容易なシステムを構築してください。システムが何をするかというセマンティクスに投資し、どのように見えるかというピクセルには投資しないでください。固定されたインターフェースを過剰に設計することは、新しい時期尚早な最適化です。

チームプラクティスへの影響と依然として重要なこと

AI支援開発はイテレーションサイクルを圧縮し、コードの書き方だけでなく、エンジニアリングの戦略立案方法を変えます。

これまでのチームへの影響：

• より積極的に委任する。生成は安価なので、ジュニアエンジニアがより多くの領域を担当できます。あなたの仕事は、制約を設定し、成果をレビューすることに移ります。
• リスクをレビューし、スタイルはレビューしない。コードレビューは「大規模または負荷のもとで何が失敗するか」になり、「どうやって書いたか」ではなくなります。
• 可逆的な依存関係を選ぶ。高速なイテレーションは、悪いロックインをすぐに露呈させます。スプリント内で交換可能な契約を優先してください。
• 削除を前提に設計する。AI生成コードはより頻繁に置き換えられます。モジュール化され、境界が明確な設計は、単にエレガントなだけでなく、これまで以上に実用的です。
• 味覚を教え、構文は教えない。メンターシップは、エンジニアがもっともらしく見えるが間違った出力を認識できるように支援することに移ります。

依然として重要なこと

AIはかつてない速さでコードを書けますが、それが正しいとは限りません。エラーなく実行されるが、間違った問題を解決するコードを生成することがよくあります。誰かがそれを読み、保守し、間違いを見つけなければなりません。その誰かとはあなたです。

変わらないことがいくつかあります：

• 正しいソリューションがどのようなものかを決める必要は依然としてあります。AIはあなたほどビジネスニーズを理解していません。
• コードは読みやすいままであるべきです。問題が発生して自分でデバッグする必要がある場合、コードが何をしているか追跡できることに感謝するでしょう。
• ユーザーが実際に苦労していることを理解できるのは実際の人間だけです。AIはそれを感じ取れません。

より速く動くことは素晴らしいですが、最終判断は依然として人間に委ねられています。ツールは作業を加速させましたが、判断力は依然としてあなたのものです。

最後に

AIはエンジニアリングから難しい仕事を取り除くのではありません。それを再配置するのです。かつてレガシーコードの解きほぐし、脆弱な統合の修正、誰も完全に理解していないシステムの保守に費やされていた時間は、今やより良いもの、つまりユーザーの理解、適応可能なアーキテクチャの設計、そして本当に重要なものの構築に使うことができます。

メンテナンス税はなくなりませんが、縮小しています。その回収した注意力をどう使うかが本当の問いであり、それにうまく答えるエンジニアこそが、このソフトウェア開発の時代を定義する存在となるでしょう。