通常のコードレビュー中に、異なる場所にわたる構成変数の同期を自動化する新しい「Skill」ファイルが発見されました。AIフックと自動化スクリプトを備えており印象的でしたが、このソリューションはエンジニアリング努力の疑問視される使い方でした。問題はコードの質が悪かったのではなく、そのコードが存在すべきではなかったということです。プロジェクトがDRY原則に従っていれば、構成の一元的な情報源が存在したでしょう。これは、回避可能な設計上の決定から生じる問題に対して、進歩と見なされる強力なツールが対処するという傾向を浮き彫りにしています。 この「生産性の幻想」は、より多くを行うこととより良く行うことを混同し、高度な自動化で構造的な問題を隠蔽します。これは、存在すべきではない問題に対してハイテクソリューションを使用する、現代的な過剰設計の形態です。かつては修正に費用がかかった技術的負債は、AIによって安価になり、皮肉なことに、開発者がアーキテクチャ的な修正ではなく、複雑なAI駆動の回避策を選択するため、その延期につながっています。根本的な問題は、問題がどのように提示されるかということです。開発者は、一元的な情報源のような原則の価値を理解していない可能性があり、AIが最適化されていないアプローチを最適化することにつながります。 このパターンは、進歩として見える目に見える自動化、設計品質よりも機能へのインセンティブ、および短期的な最適化によって推進されます。複雑な分散システムではある程度の自動化が必要ですが、その区別は、それが固有の制約に対処しているか、回避可能な設計上のギャップに対処しているかにあります。開発者は、反復的なタスクにAIを使用する前に立ち止まり、そのタスクが真の複雑さから生じているのか、それとも回避可能な設計上の欠陥から生じているのかを自問すべきです。AIは、新しいフロンティアを探求し、複雑さが避けられない場所を最適化すべきであり、弱い基盤を補うべきではありません。目標は、最小限の複雑さで問題を解決することであり、非効率性を自動化することではありません。