ingest: the-5-level-framework-that-explains

Business/Nate Corpus/2026-05-18_the-5-level-framework-that-explains.md

@@ -0,0 +1,161 @@
+---
+title: "Тёмная фабрика: почему большинство разработчиков стали медленнее и как org chart стал главным узким местом"
+slug: the-5-level-framework-that-explains
+source: https://natesnewsletter.substack.com/p/the-5-level-framework-that-explains
+author: "Nate Jones (@natebjones)"
+published: 2026-02-18
+processed: 2026-05-18
+type: video
+tags:
+  - ai-разработка
+  - future-of-work
+  - dark-factory
+  - spec-driven
+themes:
+  - "[[Agentic Workflow]]"
+  - "[[Implementation Layer]]"
+  - "[[Workflow Completion]]"
+  - "[[Frontier Labs]]"
+  - "[[Systems of Record]]"
+  - "[[Implementation Fabric]]"
+frameworks:
+  - "[[Dark Factory]]"
+  - "[[Why Specification]]"
+  - "[[Scenario Architecture]]"
+terminology:
+  - "[[Dark Factory]]"
+  - "[[Why Specification]]"
+  - "[[Evals]]"
+  - "[[Forward Deployed Engineer]]"
+  - "[[Implementation Fabric]]"
+  - "[[Systems of Record]]"
+---
+
+# Тёмная фабрика: почему большинство разработчиков стали медленнее и как org chart стал главным узким местом
+
+## TL;DR
+
+Существуют две несовместимые реальности. На переднем крае (frontier) — три инженера StrongDM запускают полную [[Dark Factory|тёмную фабрику]]: ни один человек не пишет и не ревьюит код. В то же время в рандомизированном контролируемом исследовании опытные разработчики с AI-инструментами выполняли задачи на **19% медленнее**, не зная об этом. Разрыв между этими реальностями объясняется не выбором инструментов, а перестройкой всего рабочего процесса вокруг нового узкого места: **точности спецификации** (why specification), а не скорости написания кода.
+
+---
+
+## Ключевые данные и факты
+
+| Факт | Источник / контекст |
+|---|---|
+| 3 инженера StrongDM управляют фабрикой без написания кода людьми | Реальный кейс, февраль 2026 |
+| 90% кодовой базы Claude Code написано самим Claude Code | Команда Anthropic (Boris Cherny) |
+| Внутри Anthropic: 70–90% AI-written code, некоторые workflow — почти 100% | Внутренние команды Anthropic |
+| Boris Cherny (руководит проектом) не писал код лично >2 месяцев | Там же |
+| RCT: опытные open-source разработчики стали на 19% **медленнее** с AI-инструментами | Рандомизированное контролируемое исследование |
+| Те же разработчики предсказывали +24% скорости; после эксперимента всё ещё верили в +20% | Cognitive bias: иллюзия ускорения |
+
+---
+
+## Как работает [[Dark Factory|тёмная фабрика]]
+
+**StrongDM pipeline:**
+1. Спецификации пишутся в markdown (люди описывают *что должно существовать*)
+2. Агент строит программное обеспечение по спецификации
+3. Тестирование идёт против поведенческих сценариев ([[Scenario Architecture]]) — архитектура специально разработана так, чтобы агенты не могли «подделать» прохождение тестов
+4. Система производит готовые к выпуску артефакты
+5. Люди одобряют **результаты**, а не код
+
+> "The humans approve outcomes."
+> *Люди одобряют результаты.*
+
+**Закрытая петля обратной связи (Closed Feedback Loop):** Codex 5.3 участвовал в создании самого себя. [[Frontier Labs]] уже строят системы, которые улучшают сами себя.
+
+---
+
+## Почему большинство разработчиков стали медленнее
+
+Ключевое разделение — не в качестве инструментов:
+
+- **«AI-native» уровень 2:** читают каждый diff, который генерирует AI → по-прежнему работают в парадигме «написание кода»
+- **Frontier уровень 5:** перестали читать код полностью → работают в парадигме «описание того, что должно существовать»
+
+Узкое место сместилось:
+
+```
+БЫЛО: как быстро ты можешь написать код
+СТАЛО: насколько точно ты можешь описать, что должно существовать
+```
+
+Навык [[Why Specification]] (точная спецификация *почему* и *что*) становится ключевым дифференцирующим навыком.
+
+---
+
+## 5-уровневый фреймворк
+
+> ⚠️ **TBD** — детали уровней 1–5 и 5 промптов для перехода с уровня 2 на уровень 5 находятся за paywall-ом. Содержимое не извлечено.
+
+**Открытый вопрос:** Каковы конкретные критерии разграничения между уровнями 2–4, и какая именно практика [[Why Specification]] отделяет уровень 4 от уровня 5?
+
+---
+
+## Проблемы трансформации
+
+### Проблема org chart (организационной структуры)
+Структуры, созданные под модель «люди пишут код», стали **источником трения**, а не поддержки:
+- Sprint planning → оптимизирован под скорость написания кода людьми
+- Code review → избыточен, когда человек не читает код
+- Engineering management → координирует работу людей, не оркестрирует агентов
+
+### Проблема легаси (Legacy Problem)
+Нельзя применить [[Dark Factory]] к существующим [[Systems of Record]] напрямую. Путь миграции требует отдельного подхода. TBD — детали не раскрыты в preview.
+
+### Кризис талантов (Talent Reckoning)
+- Занятость junior-разработчиков падает
+- Карьерная лестница «выдалбливается» (hollowing out)
+- Планка для «хорошего инженера» повышается: от написания кода — к точному описанию систем и [[Evals|оценке результатов]]
+
+---
+
+## Форм-фактор новой организации
+
+- Маленькие команды генерируют $100M+ выручки
+- Агенты выполняют имплементацию ([[Implementation Layer]])
+- Люди занимают роль, близкую к [[Forward Deployed Engineer]]: ориентированы на понимание задачи и спецификацию
+
+> "The dark factory doesn't run on more engineers. It runs on engineers who can think clearly about what should exist, describe it precisely enough that machines can build it, and evaluate whether what got built actually serves the humans it was built for."
+>
+> *Тёмная фабрика работает не на большем числе инженеров. Она работает на инженерах, которые могут ясно думать о том, что должно существовать, описывать это достаточно точно для машин — и оценивать, действительно ли то, что построено, служит людям, для которых это создавалось.*
+
+---
+
+## Терминология
+
+| RU | EN | Пояснение |
+|---|---|---|
+| [[Dark Factory\|Тёмная фабрика]] | Dark Factory | Производство ПО без участия людей в написании/ревью кода |
+| [[Why Specification\|Спецификация «почему»]] | Why Specification | Точное описание того, *что* и *почему* должно существовать — ключевой навык уровня 5 |
+| [[Scenario Architecture\|Сценарная архитектура]] | Scenario Architecture | Архитектура тестов поведения, исключающая возможность «обмануть» тесты агентами |
+| [[Evals\|Оценка результатов]] | Evals | Человеческая оценка outcome'ов вместо code review |
+| [[Agentic Workflow\|Агентный рабочий процесс]] | Agentic Workflow | Workflow, где агенты выполняют имплементацию, люди одобряют результаты |
+| [[Implementation Layer\|Слой имплементации]] | Implementation Layer | Уровень, где агенты строят системы по спецификации |
+| Закрытая петля | Closed Feedback Loop | Система, где AI улучшает сам себя (Codex → Codex 5.3) |
+
+---
+
+## Что использовать для нашего портфеля
+
+**Мы как AI-интегратор + [[Implementation Fabric]]:**
+
+1. **Spec-first onboarding.** Если клиент не умеет писать спецификации — мы застрянем на уровне 2 вместе с ним. Нужна методология обучения [[Why Specification]] как первый deliverable до старта имплементации.
+
+2. **[[Evals]] как продукт.** [[Scenario Architecture]] StrongDM — архитектурный паттерн, который можно предлагать клиентам: поведенческие сценарии вместо unit-тестов, написанных людьми. Это часть [[Implementation Fabric]].
+
+3. **Org chart как диагностика.** Проблема у клиентов не в моделях — в том, что sprint planning, code review и engineering management созданы под старую парадигму. Диагностика org chart на трение — новая точка входа для PE-канала (Private Equity портфельные компании особенно уязвимы: у них нет ресурса на реструктуризацию eng-процессов без внешней помощи).
+
+4. **[[Systems of Record]] ↔ [[Dark Factory]] gap.** Невозможность применить тёмную фабрику к легаси — наша возможность: миграционный путь «от легаси к spec-driven» — потенциальный framework для engagement'ов. TBD — нужна конкретика по уровням 1–5 из полного материала.
+
+5. **Метрика успеха клиента.** RCT-результат (−19%) — сигнал, что «просто добавить AI-инструменты» не работает. Измеримый outcome-based KPI для внедрений: не «использование инструментов», а [[Workflow Completion]] на уровне агентов.
+
+---
+
+## Открытые вопросы
+
+- [ ] Что конкретно разграничивает уровни 2–4 в 5-уровневом фреймворке?
+- [ ] Как выглядит migration path от легаси [[Systems of Record]] к spec-driven workflow на практике?
+- [ ] Есть ли у StrongDM опубликованная методология [[Scenario Architecture]]?