The "Negative split" software engineering effect¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
マラソンの「negative split」、つまり後半を前半より速く走る考え方を、ソフトウェア開発と AI コーディング導入にたとえた記事。 最初から速く進めすぎると、技術的負債、設計のショートカット、チームの疲弊が蓄積し、後半で失速する。 AI 導入でも、早くコードを書くことだけを追うと、将来のプロンプト、レビュー、本番障害で支払いが発生する。 短期的に遅く見えても、文脈、ガイドライン、組織固有の知識レイヤーを整え、後で速くなる土台を作るべきだと主張している。
本文¶
記事は、長距離走では前半を抑えて後半にペースを上げる negative split が強い、という比喩から始まる。 心拍や燃料消費を無視して最初に速く走ると、30km 付近で失速する。 ソフトウェア開発でも同じように、初期の進捗や AI による生成速度を追いすぎると、技術的負債や設計ショートカットが蓄積し、長期戦の途中で速度が落ちる。
著者は、自身のマラソンで予定よりわずかに速く入った結果、後半で苦しんだ経験と、マネージャーとしてチームに早期成果を求めすぎた経験を重ねている。 重要なエンジニアが「ペースは外圧で変えるものではない」と示したエピソードから、複雑でリスクの高い局面に備えて安定した速度を保つ価値を説明する。
AI 導入の文脈では、CTO が「数か月後には手でコードを書かない状態」を目指す一方で、短期的には遅くなる覚悟を示したことが良い例として紹介される。 LLM に機能を書かせて失敗したとき、すぐ人間が手で書くのではなく、何の情報が足りなかったのかを調べる。 その答えは、個々のプロンプトの工夫だけでなく、会社固有の文脈、過去の判断、ガイドライン、コードベースの慣習を保つレイヤーにある。
記事の批判対象は、AI で「とにかく速く」進める positive split 的な導入。 mediocre なコードを速く積む、または人間がすぐ正解コードを書いてしまうと、その場では進んだように見える。 しかし将来のすべてのプロンプト、レビュー、修正で余計な調整が必要になり、生成コードの品質問題が本番へ漏れる可能性も上がる。
結論は、遅くなること自体が目的ではなく、後で速くなるために土台を作ること。 プロトタイプや捨てる前提のコードなら sprint でよいが、長期的に持つコードでは、AI 導入も開発マネジメントも negative split を意識する必要がある。
要点¶
- 開発初期に速く進めすぎると、後半で技術的負債と疲弊によって失速する。
- AI コーディング導入でも、生成速度だけを追うと positive split になりやすい。
- LLM が失敗したときは、すぐ手で書くのではなく、足りない文脈やルールを特定する。
- 組織固有のガイドライン、過去の判断、コードベースの慣習を維持する文脈レイヤーが重要になる。
- 捨てるコードは速く書いてよいが、長く持つコードでは短期速度より後半の持続速度を優先する。