ソフトウェアエンジニアリングの本質は複雑さの管理にある
Software engineering is about managing complexity
AIがコード生成を容易にする一方で、ソフトウェアエンジニアリングの本質はコードを書くことではなく、複雑さを管理することにあると論じる。適切なアーキテクチャの選択は、企業の規模やチーム、インフラ、ビジネス要件など膨大な文脈に依存し、AIはその判断を代替できない。エンジニアはトレードオフを理解し、複雑さをどこに置くかを決定する責任を負う。アルゴリズム的思考の重要性は増しており、AI生成コードの所有権と理解のコストが新たな課題となる。
コードの行は安い。理解は高い。
HNでの議論
83- zug_zug
複雑さの話はすべてまったくその通りだ。
しかし、『エンジニアはトレードオフを所有する』といった言葉で、人間のエンジニアが実際にやっていることを誇張していると思う。私の経験では、雇用されているソフトウェアエンジニアの半数未満が、次のような問いに対して実際の分析を行っていない。
『これらの制約、このチーム、このビジネス、このインフラ、この予算、これらのリスク、そして製品の予想される進化を考慮すると、今日、Xを実装する最も適切な方法は何か？』
したがって、AIはこの記事が認める以上に平均的なエンジニアを置き換えることができると思う。しかし、『平均的なエンジニアリング』の不十分さは、今やもっと明白になるだろう。コードベースは、以前は5年かかっていた規模（説明責任が事実上不可能なタイムスケール）で、今では数ヶ月で扱いにくいほど大きく複雑になり得るからだ。
- cobbal
最初の前提でついていけなくなった。人々はAIがどれほど有用かについて議論できるが、それが必須でないことは明らかだ。なぜなら、私たちは数年前にAIなしでコードを書くことに成功していたからだ。当時のコードの方がむしろ良かったとさえ言える。
コードを書くこととソフトウェアをエンジニアリングすることの2つのタスクは、エンジニアのメンタルモデルの整合性を損なうことなく分離することはできない。コードと関わらなかったアーキテクトは、常に地図と領土の不一致を生み出してきた。
- a2ff6eeb0
AIは要件に基づいてアーキテクチャを生成し、必要な明確化の質問をすることもできる。
システム設計はコードを書くほど得意ではないが、まだ。しかし、同僚のほとんどよりは得意な気がする。
数ヶ月後には、システムアーキテクチャもClaude Codeの瞬間を迎え、人間は能力で追い抜かれるだろうと思う。
- wyum
ソフトウェアの複雑さは、コンポーネントを追加するにつれて超線形に、いや指数関数的に増大する。
エンジニアが曲線を平坦化するためにできること（それが投稿者の複雑さ管理のアイデアだ）はあるが、ソフトウェアに追加し続ける限り、複雑さの成長が線形になることは決してない。
私はこれについてモデル/定理を作り、Xに投稿した： https://x.com/i/status/2027771813346820349
コード生成は、検証がソフトウェアエンジニアリングの中心的な問題であることを露呈させた。そして、それは常にそうだったと思う。
「正しい」とは何かを定義すること自体が難しいことがある。ましてや検証に適したシステムを構築し、検証に時間を費やすことはなおさらだ。ソフトウェアをリリースしてユーザーにバグを見つけさせるのは、負担を分散するため非常に効率的な戦略だ。しかし、ユーザーを失うことと、重要なバグを見つけて修正するのに十分なフィードバックを得ることの間の線をうまく渡っていかなければならない。
AIが私たちの仕事を奪うかもしれないという問題に直面するとき、世界は私たちが想像できる最大かつ最もよく訓練されたAIにとっても複雑すぎるかもしれないという考えに、いくらかの慰めを見出す。ある時点で、世界全体（またはそのかなりの部分）をシミュレートする必要があり、それをすべて計算でやろうとする費用対効果は、現実世界（つまり人間）を検証者として使うことに勝らないかもしれない。
- softwaredoug
時には、こうしたトレードオフは数行のコードに対して半ダースも関わることがある。そして、そこがエージェントに任せるのをためらうところだ。正しいコードを生成するのはうまくやるだろう。そして、他の一つのことについて考えるようにある程度制約することもできる。しかし、それは見失い、制約を無視し、ごまかし、そして複雑さを上に重ねてそれを防ぐのか？それとも、十数行のコードを見て修正するだけか？