底上げ（Raising the Floor）とは、Software 3.0 時代、Harness による組織生産性の底上げ が、言語モデルを使ったチームの生産性の下限を引き上げることに付けた名前である。同記事の言い回しでは、チームの最も弱いケースに取り組むことでチーム全体のレベルを引き上げることを指す。前提にあるのは、ツールを制御するノウハウの差がコーディング能力とは独立してチーム内に存在し、その差を埋めることは組織の課題だという考えである。同記事の捉え方では、その差を個人の適性に任せておくことは組織が負う損失である。
同記事はこの差を、同じリポジトリで同じタスクを与えられた 2 人のエンジニアで例示している。1 人は最初にコンテキストを整える。何かを依頼する前に、リポジトリのコーディングガイドライン、lint ルール、既存のコードパターンを与え、10 分でチームの規約に沿った変更を手にする。もう 1 人は素の依頼から始め、汎用的なスタイルのコードを受け取り、1 時間を修正のループに費やす。著者はこの違いを、作業を始める前にコンテキストが設計されていたかどうかだと述べている。
用法
同記事が提案する仕組みは配布である。その具体例は、優れたエンジニアのワークフロー全体を担う 1 つのスラッシュコマンドである。会話を通じて機能のコンテキストを収集し、追跡用のイシューを作成し、ブランチを作り、人間がレビューして承認するための実装計画を書き、実装し、レビュー用のプルリクエストを作成する。これにより、そうした手順を自分では組み立てなかったであろうエンジニアも、コマンドを 1 つ呼び出すだけで同じ品質でそれを実行できる。同じ考え方はチームの規律にも適用される。メインブランチへのコミットの試みを横取りし、代わりにフィーチャーブランチを作成するようエージェントを誘導するフックであり、著者はこれを、エラーを報告してブロックするだけのリンターと対比している。
汎用的なオープンソースのプラグイン集は、そのための正当な出発点として扱われている。同記事はそれを、ターミナルの生産性に対して oh-my-zsh が果たした役割になぞらえている。しかし十分ではないとされる。外部で定義された汎用ツールはチームのドメインを知らず、モデルに任せてよいことと人間が承認しなければならないことの境界は、チームごとに異なるからである。
適用される場面
この用語が当てはまるのは、対処しようとしているばらつきが能力ではなく方法にある場合であり、良い方法が実際に書き下ろされ、呼び出せる形にできることを前提としている。同記事の議論全体は、ノウハウを個人の感覚から、チームが設計して配布するシステムへと移すべきだというものである。また、その配布をサポートするツールも前提としている。同記事は、あるエージェントのプラグインとマーケットプレイスの仕組みを中心に書かれている。
どの程度確立されているか：これは 1 本の記事における 1 人のエンジニアの主張であり、測定された成果ではなく方向性として提示されている。著者自身、この記事を具体的な成功事例というよりも方向性に近いものと述べており、コメント欄では何人かの読者が、抽象的なままにとどまっている点を批判している。
関連用語
実行可能な SSOT（Executable SSOT）、Claude Code プラグインマーケットプレイス、エージェントハーネス、Software 3.0