Optimizing Software Factories
Тунгуз ставит вопрос об устойчивости (а не пропускной способности) при выборе соотношения ИИ/людей в инженерных командах. В команде из двадцати инженеров уход одного — это 5% потери персонала, тогда как в «ИИ-заряженной» команде из трёх человек, управляющей двадцатью автономными агентами, тот же уход означает потерю 33% персонала и трети институциональной памяти. При 10/90 типичный бюджет среднестадийного стартапа содержит ~20 инженеров и привычную иерархию; при 50/50 — ~12 инженеров плюс флот агентов, где инженеры становятся архитекторами решений; при 90/10 — три инженера в центре созвездия автономных агентов без менеджеров и резервирования. Автор обращается к операционным исследованиям: на производстве заводы работают при загрузке 70–90%, а запас (slack) — это не потери, а свойство, обеспечивающее устойчивость системы. Концентрируя оркестрационные знания в трёх головах, вы работаете на 100% загрузки, и большинству стартапов пока не стоит делать такую ставку.
What happens when a startup employee leaves on a Monday?
Что происходит, когда сотрудник стартапа увольняется в понедельник?
In a twenty-person engineering team, one resignation is a 5% headcount loss. The remaining nineteen absorb the work.
В инженерной команде из двадцати человек одно увольнение — это потеря 5% штата. Оставшиеся девятнадцать берут работу на себя.
In an AI-pilled three-person team running twenty autonomous agents, one resignation is a 33% headcount loss.
В «ИИ-заряженной» команде из трёх человек, управляющей двадцатью автономными агентами, одно увольнение — это потеря 33% штата.
The agents do not resign. They keep generating, reviewing, testing, and deploying. But one-third of the institutional memory that trains, prompts, validates, and debugs the agent fleet walks out the door.
Агенты не увольняются. Они продолжают генерировать, проверять, тестировать и развёртывать. Но треть институциональной памяти, которая обучает, формулирует промпты, валидирует и отлаживает флот агентов, уходит за дверь.
The tradeoff at the heart of AI/labor ratio decisions is not throughput. It is resiliency.
Компромисс, лежащий в основе решений о соотношении ИИ и людей, — это не пропускная способность. Это устойчивость.
At 10/90 (10% AI, 90% labor), a typical mid-stage startup engineering budget powers ~20 engineers and a layer of Copilot, Cursor, and inference spend. Traditional hierarchy. Human code review as the bottleneck. The org chart looks familiar.
При 10/90 (10% ИИ, 90% людей) типичный инженерный бюджет среднестадийного стартапа обеспечивает ~20 инженеров и слой расходов на Copilot, Cursor и инференс. Традиционная иерархия. Человеческое ревью кода как узкое место. Организационная структура выглядит привычно.
At 50/50, the same budget powers ~12 engineers and a fleet of agents. Engineers become solution architects, problem decomposers, and prompt designers. Manager span of control widens because agents do not need standups.
При 50/50 тот же бюджет обеспечивает ~12 инженеров и флот агентов. Инженеры становятся архитекторами решений, декомпозиторами задач и проектировщиками промптов. Норма управляемости менеджера расширяется, потому что агентам не нужны стендапы.
At 90/10, three engineers sit at the center of a constellation of autonomous agents that generate, review, test, deploy, monitor, and optimize. No managers. No hierarchy. No redundancy.
При 90/10 три инженера сидят в центре созвездия автономных агентов, которые генерируют, проверяют, тестируют, развёртывают, мониторят и оптимизируют. Никаких менеджеров. Никакой иерархии. Никакого резервирования.
If we are building software factories, maybe it’s time to study operations research.
Если мы строим программные фабрики, возможно, пришло время изучить операционные исследования.
In manufacturing, the rule of thumb is simple: run your factory at 70–90% utilization. At 100%, one breakdown cascades into missed deadlines, burned teams, and lost customers. The slack is not waste. It is the feature that keeps the system robust.
В производстве эмпирическое правило простое: загружайте свой завод на 70–90%. При 100% одна поломка каскадом приводит к сорванным срокам, выгоревшим командам и потерянным клиентам. Запас — это не потери. Это свойство, которое сохраняет систему устойчивой.
Engineering teams are not factories, but the same logic applies. When you concentrate orchestration knowledge in three heads, you are running at 100% utilization.
Инженерные команды — не фабрики, но та же логика применима. Когда вы концентрируете оркестрационные знания в трёх головах, вы работаете на 100% загрузки.
Most startups should not make that bet yet.
Большинству стартапов пока не стоит делать такую ставку.