«Каждый individual contributor-инженер теперь по сути менеджер первой линии». Эта формула, которую обсуждает продуктивность разработчиков, звучит не как эффектная метафора, а как довольно точное описание новой рутины в командах. Если разработчик все чаще не пишет код руками, а ставит задачи модели, проверяет результат и отвечает за последствия, то для русскоязычного IT-рынка вопрос уже не в моде на AI, а в том, как вообще теперь измерять продуктивность разработчиков.
Именно об этом, как пишет The New Stack, говорит CTO LaunchDarkly Кэмерон Этезади. Его тезис неприятно практичен: генеративные инструменты не просто ускорили набор текста в IDE, а сдвинули саму роль инженера. Теперь отдельный разработчик все чаще ведет себя как менеджер небольшой команды из очень быстрых, очень дешевых и временами крайне ненадежных исполнителей. Он формулирует задачу, подбрасывает контекст, уточняет ограничения, а потом тратит время на ревью, проверку гипотез и отлов ошибок. На бумаге это выглядит как ускорение. На практике все упирается в то, стало ли меньше работы у человека, который несет ответственность за прод.
В этом и главный нерв дискуссии. Еще несколько лет назад разговор об автоматизации разработки обычно сводился к шаблонам, генерации болванок и экономии на рутине. С приходом LLM-инструментов автоматизация зашла глубже: теперь машина лезет не только в «скучные» задачи, но и в код, тесты, документацию, рефакторинг, поиск причин багов. Из-за этого меняется и распределение нагрузки внутри команды. Джуны получают возможность быстрее собирать черновики, но узкие места никуда не деваются: архитектурные решения, безопасность, надежность, совместимость, долгосрочная поддержка все так же требуют взрослого инженерного суждения. Более того, чем больше AI генерирует, тем дороже становится качественная проверка. В такой схеме разработчик действительно начинает напоминать линейного менеджера: он уже не только делает сам, но и координирует чужую работу, пусть этот «сотрудник» и живет в окне редактора.
Отсюда логично вытекает вторая проблема: привычные метрики все хуже объясняют реальность. Если считать строки кода, число коммитов или скорость написания функции, AI почти неизбежно выглядит победителем. Но бизнес редко зарабатывает на количестве символов. Ему важны скорость поставки полезного функционала, частота регрессий, стабильность релизов, стоимость поддержки и предсказуемость команды. Еще в 2023 году исследование GitHub Copilot показало, что участники эксперимента с доступом к инструменту выполнили задачу на 55,8% быстрее. Проблема в том, что лабораторная задача и живой продукт с легаси, интеграциями, требованиями комплаенса и ночными инцидентами — это не одно и то же. Поэтому продуктивность разработчиков в эпоху AI приходится считать шире: сколько времени ушло не на генерацию, а на верификацию, сколько багов просочилось в прод, стало ли проще онбордить новичков, уменьшилось ли число откатов после релиза.
Для вендоров девелоперских платформ такая смена роли вообще выглядит как подарок и вызов одновременно. Если инженер теперь управляет пачкой AI-исполнителей, ему нужны не просто чат в IDE и кнопка «сгенерировать код». Нужны механизмы контроля: кто что предложил, по каким данным, как это проверялось, чем подтверждается качество результата, какие правила безопасности были применены, кто утвердил изменение. Не случайно весь рынок одновременно качает темы evals, policy gates, трассировки, наблюдаемости и управляемых релизов. LaunchDarkly здесь, конечно, игрок не нейтральный: компания живет на инфраструктуре безопасного вывода изменений в прод. Но сама логика шире любой одной платформы. Когда код все чаще сначала предлагает модель, инструменты разработки неизбежно смещаются от «помощников для написания» к «системам управления машинной работой».
Для русскоязычных команд это особенно важный сигнал. Местный рынок уже живет в режиме осторожных экспериментов: кто-то запускает закрытые помощники внутри контура, кто-то подключает модели к внутренней документации, кто-то пытается автоматизировать ревью, саппорт или подготовку тестов. Самая опасная иллюзия здесь — ждать мгновенного сокращения штата или пытаться доказать эффект красивыми демо. В краткосрочном горизонте AI чаще не убирает инженера из процесса, а делает его зоной ответственности шире. Один человек действительно может закрывать больше задач, быстрее собирать прототипы и лучше держать в голове контекст продукта. Но и требования к нему становятся жестче: нужно уметь ставить задачу машине, отличать правдоподобный ответ от корректного, быстро замечать скрытые риски и не путать скорость с качеством. Для нанимающих менеджеров это тоже отдельный разворот: цениться будет не только умение писать код, но и навык управлять машинным выводом, проверять его и брать на себя ownership.
Открытый вопрос теперь звучит не так: «Сможет ли AI писать код?» С этим рынок уже в целом согласился. Гораздо важнее другое: научатся ли компании перестраивать процессы под мир, где инженер все чаще руководит цифровыми стажерами, работающими на безумной скорости и без инстинкта самосохранения. Если нет, рост скорости на входе очень быстро превратится в рост хаоса на выходе.