Как ИИ меняет разработку ПО: от индивидуальных ролей к плоским командам

Трансформация конвейера разработки

Крупные организации традиционно выстраивали разработку как конвейер поставки ценности, разделённый на два больших блока: Discovery (что мы делаем — бизнес, продукт-менеджеры, аналитики) и Delivery (как это сделать, выкатить на продакшн и обслуживать). Этот конвейер, по аналогии с идеями Тейлора и Форда, дробился на множество узкоспециализированных этапов, за каждый из которых отвечали люди с отдельными должностями. Индустрия дошла до концепции стрим-элайн команд и платформенных команд (Team Topologies), где в каждой стрим-команде собирались специалисты разных профилей, чтобы автономно выкатывать изменения.

Разделение труда (фронтенд-разработчики, бэкендеры, мобильные разработчики) исторически возникло не потому, что это «правильно само по себе», а потому что производственную систему оптимизировали под определённую метрику — пропускную способность конвейера. Когда сложность каждого домена (например, фронтенд, превратившийся фактически в отдельный вид приложений со своим состоянием и динамикой) перестала помещаться в голову одного человека, компании решали проблему через специализацию: разбивали работу на этапы, чтобы на каждом можно было находить инженеров, дающих предсказуемый повторяемый результат.

Проблема такого конвейера — сложность передачи работы между этапами. Пример из практики: доклад, в котором ради одной фичи требовалось координировать четыре команды, — это не архитектурное решение, а организационная дисфункция, возникшая потому, что работу нельзя было распределить иначе: либо всё держится в голове одного «золотого» инженера с bus-фактором единица, либо распиливается на этапы.

С распространением ИИ-агентов, способных писать основной объём кода, ситуация меняется: отдельные роли (фронтенд- и бэкенд-разработчики, QA-инженеры, аналитики, транслирующие видение продукт-менеджеров в спецификации) остаются нужны по сути, но не требуют отдельного человека под каждую. Команды из 10–15 человек потенциально можно сократить, объединив функции в меньшем числе людей, усиленных агентами. Модели, обученные на огромном объёме публичного кода и синтетических данных, одинаково способны писать и фронтенд, и бэкенд — получается универсальный инструмент («great equalizer»), и вопрос смещается с «кто на каком этапе специализируется» на «куда направить этот инструмент и как проверить, что задача решена». Специализация по типу кода теряет значение, если в домене человек по-настоящему разбирается и способен вникнуть в детали и фронтенда, и бэкенда.

Промежуточный этап: ассистенты вместо агентов

В 2025 году, когда ещё не было полноценных агентов, а были ассистенты, каждый специалист на своём этапе научился ускорять именно свою часть работы (продакты — генерировать требования, аналитики — писать детализацию, инженеры — просить выделить приоритеты). Это создавало иллюзию продуктивности на каждом этапе, но итоговая пропускная способность конвейера в целом росла слабо, потому что передача работы между этапами оставалась узким местом.

Почему это сложно в корпорациях

В стартапах, где процессов немного, переход к более плоским командам проходит легче — люди и так делают всё необходимое. В корпорациях сложнее из-за устоявшихся профессий и должностей, привязанных к конкретному этапу конвейера: люди видят свою цель в качественном выполнении именно своего кусочка процесса, и изменить это организационно тяжело.

Индустрия уже проходила через это со staff/principal-инженерами

Такая же тенденция уже проявлялась в индустрии через роль staff/principal-инженера — сильного специалиста, который решает задачу целиком, а не идентифицирует себя как «Java-разработчик» или «JS-разработчик». Раньше уровень требований для такой роли был очень высоким. Сейчас планка входа резко снижается: желаемый профиль — «продуктовый инженер», который может начинать работать в подобном режиме почти с уровня джуна, при этом оставаясь ближе к продуктовой стороне работы (что мы хотим сделать в продукте), а не к чистому кодированию.

Целевая модель команды

Идеальная (целевая) картина — гораздо более плоская структура:

Продуктовый человек, усиленный агентом, генерирует больше гипотез и передаёт не текстовые требования, а уже проработанные прототипы (в том числе визуальные), собранные и проверенные вместе с агентом.
Продуктовый инженер — по возможности один человек или небольшая автономная единица — берёт эти материалы и доводит их до продакшена, учитывая по пути все горизонтальные требования (безопасность, надёжность, регламенты).
Дальше — команда, которая сопровождает эксплуатацию.

Ключевое условие работоспособности такой модели — экстернализация правил компании (безопасность, надёжность и т. д.) в виде явных политик (policy as code), которые применяются автоматически, а не проверяются вручную постфактум людьми из смежных отделов (условный security-review, который тормозит выкатку на недели). В идеале эти политики должны быть встроены уже во внутренний цикл разработки — превращая исходный интент в проработанные требования ещё до того, как код написан, а не только на этапе финального гейта перед пул-реквестом.

Это выглядит как «волшебный мир», путь к которому крайне сложен.

Вайб-кодинг vs. инженерный ИИ-нативный подход

Ключевое различие — между вайб-кодингом и полноценным AI-native инжинирингом. При старте нового проекта (особенно с нуля) стоит сочетать:

Policy as code — рекомендации и правила, оформленные как скиллы, которые агент применяет по ходу работы.
Детерминированные проверки — набор автоматических тестов и скриптов, через которые обязано пройти каждое изменение.

Практика показывает, что число таких детерминированных проверок в проекте естественно растёт по мере столкновения с новыми проблемами — это нормально и полезно, а не признак раздутости.

Вопросы для проектирования архитектуры под ИИ-разработку

Чтобы построить архитектуру, пригодную для ИИ-нативной разработки, полезно ответить себе на ряд вопросов:

Какую метрику вы реально оптимизируете?
Готовы ли вы объяснять агенту, что сделать, но не готовы объяснять по многу раз, как именно это должно быть устроено (например, архитектура должна быть self-healing, чтобы проблемы обнаруживались на этапе изменения, а не на этапе эксплуатации)?
Что вы можете проверить руками (инкремент), а что нужно проверять только автоматически (регресс)?
Какой у вас профиль изменений — стандартный (например, типовой контент) и нестандартный (глубокий рефакторинг)? Архитектуру стоит оптимизировать под стандартный профиль, не пытаясь одинаково удобно поддержать всё.

Проблема унаследованных (brownfield) проектов в том, что их архитектура изначально оптимизировалась под совершенно другие метрики, и добавление ИИ в существующие процессы тянет за собой большой шлейф необходимых изменений.

Организационная структура: платформа и бизнес-вертикали

В крупных компаниях (банки и подобные технологические организации) типично сосуществуют:

Платформенная инженерия, поставляющая общие инструменты: единая точка доступа к моделям (model gateway — управление квотами, доступами), MCP Hub и Skill Hub (реестр доступных API и проверенных скиллов), песочницы/dev-боксы для запуска агентных сессий не только на компьютере пользователя.
Бизнес-вертикали (инвестиции, банк для юрлиц, банк для физлиц, мобильная связь и т. д.), которые самостоятельно перестраивают собственные процессы разработки.

Возникает дуализм: платформенные команды исторически оптимизировали свои интерфейсы под графический UI для человека, а не под агентов. Когда они просто выставляют CRUD-операции через MCP, ручки получаются слишком вербозными или мелкогранулированными — агенту приходится делать огромное число вызовов, чтобы собрать нужную информацию.

При этом бизнес хочет не просто, чтобы платформа лучше обслуживала агентов, а чтобы бизнес-фичи катились быстрее в целом. Это требует пересмотра:

Состава команд — в одних вертикалях уже есть продуктовые инженеры, в других по-прежнему цепочка продакт → бизнес-аналитик → системный аналитик → несколько инженеров → тестировщики.
Отношений с платформенными командами — быстрые и заряженные команды могут получить пилотный доступ к топовым инструментам под обещание показать результат, тогда как менее активные довольствуются базовыми возможностями платформы. Это создаёт неравномерность: «будущее уже наступило, просто оно неравномерно распределено» — где-то есть яркие кейсы (например, команда, получившая подписку на Claude вместо стандартных ресурсов, перешедшая с Jira/Wiki на собственный AI-native репозиторий с интентами и спеками и запустившая продукт вдвое быстрее меньшей командой), а где-то формальное внедрение ИИ не даёт видимого бизнес-эффекта, хотя объём сгенерированного кода и число pull request'ов выросли.

Нужен ли выделенный человек за процессы

На вопрос, нужен ли в каждой команде отдельный человек, не занятый фичами, а отвечающий за перестройку workflow и гейтов, ответ зависит от масштаба. В крупных вертикалях (сотни-тысяча инженеров) уже существуют собственные централизованные функции — по надёжности, производительности и т. п., — и добавить туда роль ответственного за трансформацию процессов не проблема, если находятся подходящие сильные люди. В Т-Банке с поиском таких людей проблем не было.

Главная сложность — не найти энтузиастов в отдельной вертикали, а генерализировать успешные практики на всю компанию:

Заряженная и прибыльная бизнес-линия может согласовать себе особые условия (доступы, послабления), которые нельзя просто масштабировать на всю компанию.
Централизованные требования безопасности часто смягчены для пилотов, но не готовы к массовому раскатыванию.
Попытки раскатить успешные наработки одной команды наталкиваются на требования безопасности, которые могут ссылаться на ещё не реализованные стандарты (например, будущие версии спецификаций вроде AWS для MCP, ожидаемые через несколько лет), создавая замкнутый круг между «хотим быстрее» и «должно быть безопасно».

Design review вместо code review

Известный тезис (в частности, от Фаулера) о том, что важнее не код-ревью, а дизайн-ревью — то есть согласование того, что мы хотим сделать, до написания кода, — раньше применялось только к крупным, «дорогим» решениям (аналог принципа Джеффа Безоса про one-way door decisions): для них фиксировался лог решений (architecture decision log), обсуждались компромиссы, и только потом решение реализовывалось.

С агентами эту практику стало значительно проще применять на уровне отдельной задачи, а не только крупного изменения:

Есть интент от продуктового человека.
Есть проработанные PRD/спецификации.
Агент предлагает план — его нужно проревьюить.
Дальше агент пишет код, а человек проверяет, готово решение или нет.

Для людей, которым важен результат, а не сам процесс написания кода, это благо — они могут делать больше. Но часть инженеров, которым нравился именно процесс кодирования и состояние потока (flow), теряют этот источник удовольствия: модели работают асинхронно — им ставят задачу, они уходят её выполнять, а человек в это время переключается на другое.

Интерактивная работа с агентом снижает качество

Исследования интерактивных бенчмарков (в частности, от организаций, связанных с Meta и Scale AI, признанных в России нежелательными/экстремистскими), измеряющих, как агенты работают в режиме частичного раскрытия информации и уточнения требований, показали: постоянное «подруливание» агентом в интерактивном режиме (доспецифицирование требований по ходу) драматически снижает качество решения задач. Модели работают лучше, когда всё заранее разложено по спецификации (spec-driven development): требования зафиксированы, ревью пройдено до начала работы, а дальше агент самостоятельно доводит задачу до конца и проверяет критерии приёмки.

Личный опыт: спецификации работают даже в маленьких командах

Практика показывает, что подход со спецификациями и явным дизайн-ревью, который раньше казался «энтерпрайзной» избыточностью, ненужной для маленькой команды, за последние месяцы стал настолько простым и естественным, что от него не хочется отказываться даже при команде из полутора человек. Новые проекты стартуют по этой схеме с самого начала, даже если разработчик работает в одиночку. При этом уровень целесообразности такого подхода варьируется: для одних инструментов (упоминается Spec Kit) он может быть избыточен для небольших open-source проектов, но в целом общая тенденция — заранее формировать и использовать спецификацию на всех уровнях, и не делать этого означает проигрывать тем, кто это делает.

Личный пример: превращение локального приложения в мультитенантную систему заняло один день совместной работы с агентом по спецификации, включая проработку архитектурного решения (ADR) такого качества, на написание которого раньше ушла бы неделя, плюс недели на объяснение решения коллегам и кварталы ожидания реализации.

Эксплицитное знание и точная терминология резко повышают качество работы агента

Ключевой вывод: если требования, критерии приёмки и контекст зафиксированы явно (эксплицитно), агент может не только выполнить задачу, но и оценить, выполнена ли она, и отчитаться. Если же просто сказать «сделай красиво», проверять результат придётся самому человеку.

Отдельно подчёркивается роль точной доменной терминологии:

Когда человек говорит с агентом на обывательском языке, ответ получается дженериковым.
Когда используется чёткий внутридоменный язык, модель находит правильную «репрезентацию» домена и выдаёт значительно более качественный результат.
Это подтверждается и исследованиями (в том числе от Anthropic): доменная экспертиза сейчас важнее чистого software-инжиниринга при делегировании задач агенту — «супербухгалтер» с агентом решит бухгалтерскую задачу лучше, чем «суперинженер», не разбирающийся в бухгалтерии.

Практическое следствие: в проекте с давней историей и «поехавшей» терминологией (например, учебная платформа с 2013 года) стоит проводить рефакторинг именования — приводить названия в коде в соответствие с общепринятыми доменными терминами (например, admission — процесс подачи заявления в вузы), чтобы агент мог делать правильные выводы без дополнительных подсказок.

Внутренние платформы как актив, ставший пассивом

В крупных технологических компаниях (бигтехах) стандартные open-source инструменты часто не выдерживали внутреннего масштаба (тысячи аналитиков, десятки тысяч пользователей), что приводило к форкам популярных продуктов (условные примеры — поисковые/аналитические системы, мессенджеры, ноутбуки для аналитиков) и постепенному наращиванию собственных фич поверх форка. Отчасти это подпитывалось и мотивацией продуктовых менеджеров, которым нужно было показывать собственные идеи и креативность, а не просто следовать апстриму.

С приходом агентов ситуация изменилась:

Агенты отлично натренированы на стандартных open-source решениях и легко бы справились с работой «из коробки».
Но они не знают локальных особенностей форкнутого и доработанного напильником внутреннего решения — про них модель не обучалась.
Раньше кастомизация была активом, обеспечивающим экономию на масштабе. Теперь, в мире агентов, накопленные собственные платформы, непохожие на то, на чём обучались модели, превращаются в пассив: чтобы агент начал ими эффективно пользоваться, требуется огромная работа по донесению контекста.

Попытки компенсировать это скармливанием инструкций в контекст или дообучением (fine-tuning, RL) работают хуже, чем изначальное обучение модели на «претрейн»-данных: заканчивается всё бесконечным дописыванием примеров использования в контекстное окно в надежде, что агент «исправится» — но результат всё равно хуже, чем при работе с оригинальным, знакомым модели инструментом.

Практический вывод из этого наблюдения: выгоднее возвращать собственные наработки к совместимости с апстримными open-source решениями (по интерфейсам/API), чтобы агенты могли работать с ними «из коробки» без огромных затрат на объяснение локальной специфики.

Личный опыт возврата контрибуций в open source

Осознание того, что содержать кастомные доработки внутри компании — избыточно дорого в новом мире, привело к смене привычки: вместо накопления собственных патчей и фиксов их стали активно возвращать в апстрим через pull request'ы (в среднем около двадцати PR за три месяца, сделанных с помощью ИИ прямо в контексте рабочей сессии). Это работает хорошо именно тогда, когда кастомизация была вызвана локальной проблемой/багом, а не потребностью в глубокой архитектурной переделке под масштаб в тысячи инженеров.

Аналогия: гуманоидные роботы как пример «наследия», ограничивающего дизайн

Проведена параллель с робототехникой: гуманоидные роботы (двуногие, с руками) популярны на хайпе, но их востребованность на производстве объясняется не тем, что такая форма оптимальна, а тем, что производственная среда исторически спроектирована под людей, а капитальные вложения в автоматизацию уже сделаны под этот формат. Там, где автоматизировать было легко, это уже сделано роборуками старого типа; человек остался только на тех участках, которые пока нельзя было автоматизировать иначе — и туда пытаются поставить гуманоидного робота как «замену человека», не меняя всю окружающую инфраструктуру.

При проектировании производства с нуля (greenfield), скорее всего, выбрали бы немуманоидных роботов (например, на колёсах, с другим расположением манипуляторов), оптимизируя под пропускную способность и стоимость, а не под совместимость с человеческой средой. Похожая логика применима и к историческим технологическим системам: ранние внедрения (метро в Нью-Йорке и Лондоне, чеки в банковской системе США) остаются наследием старых решений, которые сегодня выглядят как ограничение, хотя когда-то были преимуществом первопроходца.

Хранилища знаний в компаниях

Поднимается вопрос о будущем корпоративных баз знаний: сегодня в крупных компаниях преобладают Confluence/Jira и подобные системы, отделённые от кода. Наметилась тенденция переносить знания ближе к репозиторию (git) через spec-driven development, поскольку git становится более универсальным хранилищем, а не сугубо программистским инструментом.

Указывается, что текущий подход с Wiki/Jira исторически завязан на широкий круг пользователей за пределами разработки — топ-менеджеров, продуктовых менеджеров, дизайнеров, аналитиков разных профилей (бизнес-, системных, количественных, риск-аналитиков), инженеров, саппорт и QA.

Кейс мобильного банка: как менялась работа с требованиями

На конкретном опыте технического директора мобильного банка описывается эволюция подхода к документации требований начиная с 2019 года. Изначально требования писались по принципу «скопировать предыдущую версию и описать новые экранчики» — сплошной текст без структуры, который реально читал только саппорт, чтобы понять отличия версий. Инженеры жаловались на цикличность и бессмысленность этого процесса. Показательный случай: при обновлении главной страницы приложения описание спецификации занимало «пятьдесят страниц» текста без концептуального summary — классический стокгольмский синдром давних сотрудников, которые настолько привыкли к неудобному формату, что перестали замечать проблему.

Продуктовые менеджеры и дизайнеры тем временем работали параллельно и независимо — в Figma, со своими сценариями, — а затем это «превращалось в уродство» текстовой спецификации при передаче инженерам.

Потребовалась смена подхода: переход от описания по экранам к описанию по фичам, чтобы информация была понятна не только «избранным» продуктовым и дизайнерам, но и всем участникам процесса. Ключевые наблюдения из этого опыта:

Изменение процессов работы со знаниями в крупной организации — крайне медленный и трудозатратный процесс. Даже с полномочиями технического директора и выделенным «супераналитиком», который два года системно вёл эту трансформацию, компания в итоге не ушла из Wiki-подобной системы, а лишь реорганизовала структуру информации внутри неё.
Попытка перевести аналитиков на работу через git (GitOps для управления конфигурацией) была реализована, но потребовала огромных усилий и постоянного «драйва» со стороны ответственного человека даже в рамках одного департамента. Экстраполировать такой переход на всю компанию (десятки тысяч сотрудников) практически невозможно.

Проблема внутреннего поиска и «внутреннего Perplexity»

Многие крупные компании пытаются решить проблему разрозненности баз знаний (Confluence, Wiki, GitLab Pages и прочее), построив внутренний аналог Perplexity — систему с полнотекстовым и семантическим поиском, векторными базами данных, иногда с графовыми связями между документами и генеративной частью (RAG).

Фундаментальная проблема такого решения — отсутствие качественного feedback-loop. В обычном веб-поиске relevance улучшается за счёт онлайн-метрик пользовательского поведения (клики, время на странице и т.д.). Во внутреннем корпоративном поиске:

Пользователей мало, и агрегированного сигнала недостаточно для обучения ранжирования.
Возникает эффект самоусиления нерелевантного контента: например, по запросу об общей ИТ-стратегии компании поиск выдаёт топ-5 версий интерпретации стратегии от разных бизнес-линий, потому что эти документы чаще открывают (их авторы и коллеги), а исходный общий документ прочитали один раз и забыли — в итоге он проигрывает по индексу популярности, хотя именно он релевантен.

Вывод: человеческое поведение изменить часто невозможно, поэтому проблему пытаются решить технически — сделать так, чтобы у агентов появлялся нужный контекст независимо от того, как ведут себя люди. Это становится неким базовым уровнем (baseline), а дальше через «сарафанное радио» и модель диффузии инноваций (кривая Роджерса — новаторы, ранние последователи и так далее) наиболее заинтересованные пользователи адаптируют новые подходы, и постепенно к ним подтягиваются остальные.

Битва вендоров баз знаний за будущее

Обсуждается позиционирование традиционных вендоров (условно Atlassian с Jira/Confluence): их value proposition смещается от «мы храним документацию» к «мы храним рабочие workflow и знания процессов, отдайте их нам, и мы сами сделаем слой для выдачи агентам». Это попытка удержать lock-in на уровне процессов, а не просто хранения текста.

На зарубежном рынке молодые и гибкие команды скорее уходят в сторону более гибких инструментов, которые можно настраивать под себя, не привязываясь к тяжеловесным монолитным платформам. В России ситуация иная: облачные версии таких сервисов практически недоступны, компании продолжают пользоваться версиями с локальной установкой, полученными ещё до ограничений, зачастую с нарушением условий лицензии — то есть российский рынок эти вендоры, вероятно, потеряют, тогда как на глобальном рынке предстоит серьёзная конкурентная борьба именно за удержание клиентов на уровне зафиксированных бизнес-процессов, поскольку смена процессов работы для организаций — самое сложное и медленное изменение.

Метрики внедрения ИИ: трёхуровневая модель

Описывается предпочитаемая «школа мысли» по измерению эффекта от внедрения ИИ-инструментов, состоящая из трёх последовательных уровней.

1. Метрики использования и проникновения технологии

Базовый уровень — понять, пользуются ли люди раздаными инструментами вообще. Для агентных сценариев (автоматический код-ревью, автофикс багов и т.п.) — оценить, какая доля целевых сценариев уже покрыта агентами и какой объём работы они выполняют. Здесь же измеряется объём сгенерированного кода — метрика, признанная почти такой же бесполезной и вводящей в заблуждение, как классические lines of code, но полезная как индикатор для выявления отклонений: если часть организации не пользуется инструментами, стоит выяснить причину.

2. Измерение влияния на время выполнения работы (job-based подход Google)

Более глубокий уровень требует построения платформы разработки с инструментализацией — то есть сбором логов из разных инструментов, их превращением в события, а событий — в сессии, привязанные к конкретной задаче (job) и артефакту (код, merge request).

Ссылка на подход Google (Measuring Developer Goals) — компания выделила типовой набор «работ» (jobs), которые выполняют инженеры:

создание изменения (diff);
discovery информации по системе;
принятие архитектурного решения;
код-ревью чужого кода;
устранение инцидента.

Для каждой такой job измеряется время выполнения, и далее можно оценивать, как изменения инструментов (включая ИИ) влияют на это время. Google выстроил такую систему ещё в 2019 году. Мета сделала нечто похожее позже (примерно в 2024–2025) применительно конкретно к созданию diff — измеряли время от начала работы до смерженного изменения, тестируя постепенный rollout автоматизации (например, автоматизацию бэктестов) на части проектов и сравнивая результат с контрольной группой; фиксировали ускорение порядка 10–15%. Похожий эксперимент был с языком Hack: часть тестов получила типизацию (подсказки об ошибках прямо во время написания кода), часть — нет, и разница в скорости работы была измерена напрямую.

Личный опыт: попытка измерить эффект ИИ-агента на скорость от merge request до его смержения не показала эффекта — потому что агент помогает в основном на начальном этапе (от идеи до первого MR), а не на последующей доработке по комментариям. Чтобы увидеть реальный эффект, нужно измерять весь путь от интента до деплоя, а для этого необходимо собирать логи с самого начала работы над задачей — то, что делает Google, но что редко реализовано в других компаниях.

Важная оговорка: сэкономленное время автоматически не конвертируется в бизнес-эффект — работа «занимает всё доступное время, как газ». Если агент освобождает время инженера, это время может уйти как на полезную работу, так и на разговоры с коллегами о том, «какие агенты классные». Как именно освободившееся время конвертируется в реальный эффект — отдельный управленческий вопрос.

3. Замыкание экономики

Третий уровень — попытка связать сэкономленное время с деньгами: посчитать экономию по job-ам и сопоставить её с затратами на платформенную команду, инструментализацию и токены для моделей. Это сложный путь, поэтому чаще компании идут более простым способом — смотрят на flow-метрики: пропускную способность команды (throughput тикетов/сторипоинтов/эпиков), time-to-market, lead time или cycle time для той части процесса, где применяется ИИ.

Важная ловушка: рост throughput без изменения discovery

Ключевое предостережение (со ссылкой на обсуждение с коллегой на подкасте): если throughput вырос на 20%, но при этом не расширена «воронка discovery» (процесс придумывания и проработки полезных задач), то по закону убывающей предельной полезности дополнительные 20% выполненных задач окажутся менее ценными, чем первые 100% — это будут либо «nice to have» задачи, либо технический долг, а не то, что реально нужно бизнесу. Delivery начинает «выгребать» весь бэклог быстрее, чем discovery успевает генерировать по-настоящему ценные задачи.

Практический пример из личного опыта собеседника: ускорение работы команды позволило разгрести годами копившийся бэклог мелких доработок и ошибок за пару дней, но затем стало ясно, что продуктовая сторона не успевает генерировать новые ценные задачи в том же темпе — то есть возник дисбаланс между delivery и discovery.

Обратная ситуация типична для корпораций: не все продукты находятся на стадии активного роста, но команда разработки есть у каждого продукта. Когда delivery ускоряется, менеджер продукта, который раньше растягивал немногочисленные идеи на доступную мощность команды, сталкивается с невозможностью придумывать новые идеи в нужном темпе — и как следствие появляются задачи низкой ценности «для галочки».

Ценность метрик как аргумента в организационных изменениях

Инструментализация и наличие цифр позволяют говорить на языке фактов с людьми, которые сопротивляются изменениям («у меня и так всё работает, менять себя не буду»). Приводится личный пример неудачи: попытка убедить руководство в необходимости выстроить полноценную систему измерения эффективности инженерных процессов была отклонена как «слишком академичная» на фоне грядущих масштабных организационных изменений — с сожалением о том, что не удалось «продать» эту идею и как могла бы измениться ситуация, будь она реализована.

Деградация экспертизы и вопрос будущего профессионалов

Поднимается фундаментальный вопрос: индустрия сейчас проходит период сокращений и оптимизации штата (совпадение экономических причин и влияния ИИ, снижающего потребность в людях), но в какой-то момент неизбежен приток новых кадров — как будет происходить обучение новичков и не приведёт ли это к деградации экспертизы, если люди перестанут понимать нижележащие уровни (пример — споры о том, нужно ли будущим специалистам по ИИ понимать базовые предсказательные модели «на нижнем уровне»)?

Отсутствие единого ответа

Признаётся, что однозначного ответа на этот вопрос не существует, поскольку он одновременно затрагивает тактические и операционные вопросы бизнеса и накладывается на фундаментальную неопределённость движения к некой технологической «сингулярности» — неизвестно, наступит ли качественный скачок (сверхинтеллект) и когда. Если он наступит, то, по сути, можно было бы просто ждать и наблюдать за результатом; вопрос актуален именно для сценария, когда этого не произойдёт или произойдёт не сразу.

Аргумент в духе пари Паскаля

Проводится аналогия с классическим аргументом о вере в Бога (приписывается французским мыслителям, вероятно Паскалю): рационально действовать исходя из предположения о наступлении важного события, независимо от того, произойдёт оно или нет, потому что издержки от «неправильной веры» асимметричны. Применительно к сверхинтеллекту: разумнее действовать проактивно уже сейчас, вне зависимости от того, наступит ли качественный скачок ИИ.

Как выделяться в условиях конкуренции

Ключевой практический вопрос для отдельного специалиста в капиталистическом обществе — как не оказаться в положении полностью взаимозаменяемого товара (аналогия с водителями райдшеринг-сервисов, где единственный дифференциатор — цена, и рынок скатывается к состоянию совершенной конкуренции с минимальными ставками). Ответом может быть уникальное знание или навык, который в сочетании с ИИ-агентом позволяет делать что-то заметно лучше остальных.

Проблема протекающих абстракций

Формулируется важный тезис: любую проблему можно решить добавлением уровня абстракции, «кроме проблемы избыточного количества уровней абстракции» — но при этом абстракции текут (leaky abstractions). Когда происходит нечто нештатное и текущий уровень абстракции перестаёт работать, необходимо «заглянуть под капот» — и здесь ключевое отличие: инженеры с многолетним практическим опытом, работающие сейчас с ИИ-агентами, обладают возможностью нырнуть на более низкий уровень при сбое агента, тогда как специалисты, не имеющие такого фундаментального понимания нижних уровней, такой возможности лишены.

Личная мотивация: любопытство как источник дифференциации

Собеседник формулирует развилку: если наступит настоящий сверхинтеллект, он сам справится с любой проблемой — и тогда непонятно, зачем человек вообще нужен в этом процессе. Но если сверхинтеллект не наступит (или наступит не сразу), умение разобраться в деталях, прочитать ошибки, самому подебажить становится реальной точкой дифференциации между специалистами.

При этом дифференцироваться можно не только «вниз» (в сторону понимания нижних уровней абстракции), но и «вверх» — например, научиться настолько эффективно пользоваться инструментом, что делать работу в два раза быстрее или качественнее остальных, пока это работает, а при сбое — звать на помощь специалиста, который закроет пробел. Именно так уже действуют многие продакт-менеджеры: они быстро прогоняют свои идеи через инструменты, а недостающую глубинную экспертизу докупают у профильных людей, комбинируя роли.

Собеседник признаётся, что лично ему всегда было интересно понимать, как устроен мир — естественные науки, математика, физика давались легко, а вот межличностное взаимодействие и эмпатия — сложнее (в отличие от жены, которая прекрасно считывает эмоциональные состояния, в том числе детей, и помогает рационализировать их для него). Это врождённое любопытство к «внутреннему устройству» перенеслось и на технологии: понимание того, как связаны между собой слои — модели, инфраструктура, агентные обвязки, — помогает лучше предсказывать тенденции: видеть, где узкое место в системе, почему тот или иной архитектурный подход был удачным, и узнавать в новых white paper'ах идеи, которым уже пятьдесят лет, но именно сейчас «выстрелившие» и создавшие нового лидера рынка. Для человека в роли визионера или технического топ-менеджера способность видеть дальше других — не роскошь, а профессиональная обязанность: нужно смотреть не туда, где шайба находится сейчас, а туда, где она будет.

Найм и обучение джунов в эпоху агентов

Как менялась оценка работы начинающих разработчиков

Раньше процесс работы с джунами строился просто: им давали задачи уровня багфиксов или небольших фич, а по готовому артефакту (прошли ли тесты, починился ли баг) можно было судить, сделал ли человек работу самостоятельно и чему-то ли он научился в процессе.

С приходом агентов эта логика ломается: артефакт может быть полностью готов, а понимания у человека — не быть вовсе, потому что всю работу фактически выполнил агент. Из этого следует несколько выводов для организации процесса найма и роста джунов:

Мелкие баги и фичи больше не имеют смысла как обучающая задача — их логичнее закрыть через loop-инжиниринг, когда агент чинит их сам.
Джунам стоит давать задачи покрупнее, которые они решают вместе с агентом, но при этом важно проверять не сам факт готовности фичи, а как именно человек взаимодействовал с агентом: как он специфицировал задачу, ставил критерии приёмки, оценивал предложенные агентом варианты.
Необходимо проверять, чему человек в итоге научился — просить рассказать, как устроена реализованная фича и почему она решает исходную проблему, а не просто принимать смерженный пулреквест.

Это требует осознанного дизайна процесса обучения, если компания действительно хочет растить компетенции людей, а не просто получать закрытые тикеты — ведь ответственность за доехавшее до продакшена изменение всё равно несёт человек, а не агент, и если джун просто «скармливает» задачи агенту без вовлечения, ни ответственность, ни понимание у него не формируются.

Риск утраты низкоуровневых компетенций

Проводится параллель с историческим переходом от ассемблера к языкам высокого уровня: тогда часть низкоуровневых навыков была утрачена, но ответственность за то, что делает написанный код, осталась при разработчиках. Похожая ситуация ожидается и сейчас: вероятно, новое поколение инженеров действительно утратит часть низкоуровневых компетенций, но при этом «спеки» становятся новым кодом, а получившийся артефакт — это уже уровень результата, и всё равно нужно понимать, как это работает.

Проблема традиционного найма (биг-техи)

Найм в крупных технологических компаниях устроен как конвейер: скрининг, несколько технических интервью, фит-интервью, оффер. Приоритет в биг-техах — не пропустить слабого кандидата (минимизировать false positive), даже ценой упущения части сильных (false negative); при точечном найме под конкретную роль логика может быть другой.

Проблема в том, что многие традиционные сигналы найма были основаны именно на том, что легко даётся людям, но сложно — машинам, а сейчас ситуация обратная:

Кодинг-интервью на алгоритмы и структуры данных раньше было хорошей прокси-метрикой знакомства с computer science и способа мышления кандидата. Сейчас агент решает такую задачу без всякого сигнала о самом кандидате.
System design интервью аналогично: получить от агента правдоподобный рассказ о проектировании системы тоже не составляет труда, так что подобное интервью тоже теряет диагностическую ценность.

Возникает потребность в интервью «без ИИ» — но непонятно, как реализовать это онлайн (офлайн-проверка возможна, но дорога и неэффективна). Параллельно нужно добавлять новый тип интервью — оценку того, как человек работает с инструментами, но стандартизировать и оценивать такой этап крайне сложно:

Оценивающий сам должен глубоко разбираться в теме и понимать разные workflow (кто-то работает по OpenSpec, кто-то по GitHub Spec, кто-то использует собственный подход).
Неясно, кого именно нанимают: продукт-инженера, который должен катить фичи, или методолога разработки, способного объяснить, почему процесс работает именно так.

Экономика найма и обучения джунов

Для многих средних и малых компаний сейчас выгоднее нанять опытных инженеров и дать им инструменты, чем вкладываться в обучение джунов — просто потому, что нет ни достаточного потока задач, ни денег на обучение. У крупных компаний обычно есть программы стажировок, куда попадают уже хорошо подготовленные люди (через олимпиадное программирование, сложный предфильтр), и компания «доучивает» их промышленной разработке, получая на выходе быстрый и качественный результат.

Возникает вопрос о балансировке на уровне всей индустрии: если у всех есть стимул «переманивать» готовых опытных инженеров вместо инвестиций в обучение джунов — это структурно напоминает трагедию общин. Однако крупные компании умеют работать с начинающими специалистами и заинтересованы в них: имея готовую систему инструментов и процессов, они способны быстро довести джуна почти до уровня мидла.

Второй собеседник добавляет оптимистичный взгляд со стороны рынка труда: свободный рынок с некоторой инерцией сам решает проблему дефицита кадров — как только появляется устойчивый спрос со стороны компаний, образовательные системы и компании (включая ту, где он сам работает) начинают под этот спрос перестраиваться. Единственная сложность в том, что этот процесс всегда идёт с задержкой: сначала должен возникнуть спрос, а уже потом рынок подстраивается.

Открытый вопрос: что действительно нужно знать разработчику

Несмотря на профессиональное обучение, остаётся неясным глобальный индустриальный вопрос — что именно разработчику необходимо знать «на низком уровне», а что нет. Собеседник приводит личный пример: он понимает язык Go концептуально, но не пишет на нём сам; начиная новый проект на Go, он работает в режиме вайб-кодинга, полагаясь на генерацию кода. При этом он осознаёт, что накапливает «яму непонимания» — по мере роста кодовой базы, появления новых фич и тестов приходит понимание общей структуры (где какая папка, где какие события), но не деталей конкретных кусков кода. В какой-то момент придётся остановиться, вручную прогнать тесты и «руками пощупать» код, чтобы получить нужное «ощущение на кончиках пальцев», и только после этого двигаться дальше — иначе яма непонимания продолжит расти.

Это ставит открытый вопрос: должен ли инженер лично, вручную писать решение задачи на незнакомом языке (например, на Rust), или можно полностью полагаться на агента? Однозначного ответа пока нет, но собеседники сходятся на том, что ответ, вероятно, придёт со скоростью развития моделей и харнесов вокруг них — возможно, уже в следующем году станет ясно, что задача кодинга в значительной степени решена, если снаружи можно чётко специфицировать требования (по аналогии с обсуждавшимся ранее переписыванием бэкенда, когда агент переписывает код так, чтобы все тесты стали зелёными).

Возражение: не все системы одинаково просты для агентов

Здесь возникает важное возражение: пример с переписыванием бэкенда — это частный случай простой с точки зрения архитектуры системы (по сути чистые функции без состояния, простой вход-выход, без сложных пайплайнов). Если писать библиотеку, хорошо покрытую тестами, агент действительно может делать с ней почти что угодно без риска содержательных багов (хотя возможны, например, проблемы производительности или потребления памяти).

Совсем другая ситуация — живые системы с состоянием, миграциями данных и legacy. Пример: если провести миграцию данных «в чистом виде» на продакшене, ничего хорошего не получится — часто требуется гораздо более сложный, постепенный переход от старого формата к новому. Вопрос автоматизации таких сценариев остаётся, по сути, нерешённым.

Ответ: границы применимости агентов и «археология» legacy-систем

Агенты сильны там, где эксплицитно задано, что именно делает система, в каких границах и как это проверить (то есть есть явный feedback loop). Со сложными системами, миграциями и запутанными зависимостями всё иначе — люди распутывают такие «клубки» годами, и распутывание часто заключается не в техническом понимании кода, а в архитектурной археологии: приходится вытаскивать «скелетов из шкафа», нести их бизнесу и получать ответ в духе «мы вообще не знаем, что это, просто сделайте, чтобы работало как раньше». В итоге поведение системы фиксируется как исторически сложившийся эталон, происхождение которого никто уже не помнит.

Иллюстрация этой идеи — притча о жене, которая готовит индейку, отрезая ей ноги перед тем, как положить в кастрюлю, просто потому что «так всегда делали»; в итоге выясняется, что первопричина (у бабушки была маленькая кастрюля) давно неактуальна, но ритуал сохранился. Похожая ситуация типична для legacy-кода: «бабушки», которая объяснит первоначальную причину решения, часто уже не найти, и текущее поведение системы принимается как эталон.

В реальном мире у агентов, в отличие от симуляций (как упоминавшийся ранее пример с батутной техникой или соревнованиями роботов), нет возможности бесконечных прогонов и безопасного отката: если робот на олимпиаде слишком разогнался и упал, разбив себе «голову», в софтверном инжиниринге для аналогичных сайд-эффектов часто просто нет «механизма торможения».

Сложность тестирования систем, привязанных к физическому миру

Приводится пример компании-оператора связи (условно «Мегафон»): для тестирования качества сети и работы функций в разных регионах используются специальные сотрудники, которые физически ходят по территории с телефонами и симками, проверяя связь на месте. Такие задачи, завязанные на физическую среду и выходящие за рамки серверной инфраструктуры, пока крайне сложно полностью автоматизировать и заменить людьми.

Модели мира (World Models) как возможное направление развития

Упоминается направление исследований, связанное с моделями мира (World Models) — в частности, выступления специалиста по имени Ко Веймар (выпускник Физтеха), который много лет занимается self-supervised обучением. Идея таких моделей в том, что предсказание идёт не токен за токеном, как в обычных генеративных моделях, а из латентного состояния сразу предсказывается целевое состояние мира — то, что произойдёт дальше.

Отмечается, что в Meta (организация, деятельность которой признана нежелательной в России) были похожие попытки создания «мировых» моделей для кодинга, во многом благодаря присутствию там Яна Лекуна, который давно и последовательно продвигает идею world models. Такие модели можно тренировать на разных физических процессах — направление скорее исследовательское, чем мейнстримное, в отличие от текущих GPT-подобных систем, в которые уже вкладываются миллиарды долларов и виден конкретный практический результат.

Высказывается предположение, что именно world models могут стать ответом на проблему сложных физических/технических эффектов в реальном мире (в том числе обозначенную выше проблему миграций и legacy-систем) — но это, вероятно, следующий виток развития технологии, требующий на порядок больше вычислительных мощностей. Разговор завершается ироничным замечанием о том, что подобный виток снова приведёт к ситуации, когда обогащается производитель видеокарт (Nvidia), а все остальные участники индустрии судорожно скупают вычислительные мощности.