ИИ и увольнения разработчиков: что на самом деле меняется в профессии программиста

Что известно о кейсе Claude Fable 5

В начале июля OECD AI Policy Observatory вынесла в монитор AI incidents карточку с громким заголовком: «ИИ-система Claude Fable 5 привела к массовым увольнениям разработчиков в софтверной компании». В пересказе история звучит как один из самых тревожных сценариев для отрасли: софтверная компания якобы сократила большую часть команды разработки после внедрения ИИ-системы.

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

Новостной повод силен на уровне заголовка, но слаб как доказательство. В карточке OECD AI Policy Observatory говорится о якобы массовых увольнениях разработчиков в софтверной компании после внедрения системы Claude Fable 5. В описании фигурирует утверждение, что из команды примерно в 70 человек осталось восемь разработчиков. Однако это нужно подавать именно как утверждение из непроверенного сообщения: компания не названа, независимого подтверждения в доступном досье нет, первичный источник анонимен.

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

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

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

Цитата в переводе

«Сгенерировано ИИ.»

Цитата в переводе

«Непроверенная и анонимная.»

Цитата в переводе

«ИИ-система Claude Fable 5 привела к массовым увольнениям разработчиков в софтверной компании.»

Почему история кажется правдоподобной

Программирование удобно для автоматизации не из-за простоты. Продуктовая разработка сложна: в ней есть архитектура, безопасность, legacy-код, бизнес-логика, эксплуатация, документация и коммуникация с заказчиком. Но внутри этой сложности много локальных операций, где ИИ получает понятный вход и быстро проверяемый выход: сгенерировать функцию по спецификации, написать unit-тест, объяснить ошибку компиляции, переписать запрос, предложить причину падения теста.

Работа раскладывается на цепочки проверяемых шагов. Если senior-разработчик или менеджер умеет формулировать задачу, ограничивать контекст и задавать критерии приемки, ИИ-инструмент становится не автономным программистом, а ускорителем отдельных этапов. Он может предложить реализацию, создать заготовку тестов, пройти по логам и вернуться с гипотезой. Дальше нужен контроль: ревью, тестовый стенд, проверка безопасности, сверка с продуктовой логикой.

Поэтому возможные сокращения не доказывают исчезновение профессии целиком. Они скорее говорят о смене соотношения ролей. Меньше людей может заниматься первичным написанием однотипного кода. Больше ценности переходит к тем, кто формулирует требования, понимает архитектуру, проверяет машинный output, видит риски эксплуатации и отвечает за итог перед пользователями и бизнесом.

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

Профессия программиста действительно попадает в зону быстрой автоматизации. Причина не в том, что ИИ гарантированно «пишет весь продукт вместо команды». Значительная часть разработки раскладывается на операции с короткой обратной связью: понять задачу, предложить фрагмент кода, написать тест, объяснить ошибку, подготовить черновой pull request, подсказать вариант рефакторинга, то есть улучшения структуры кода без изменения его поведения.

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

Где ИИ экономит время, а где создает новый труд

В повседневной разработке ИИ полезнее всего там, где есть короткий цикл обратной связи. Фрагмент кода можно скомпилировать, тест запустить, ошибку линтера, то есть инструмента автоматической проверки стиля и типовых проблем, проверить, документацию сверить с интерфейсом. В таких задачах снижается стоимость первой версии решения. Но первая версия кода и надежная система в продакшене, то есть в рабочей среде для пользователей, разные объекты.

Новый труд возникает сразу после генерации. Нужно проверить, не придумал ли инструмент несуществующий API, не внес ли уязвимость, не ухудшил ли архитектуру, не создал ли тесты, которые проходят, но ничего существенного не проверяют. Чем быстрее генерируется код, тем важнее фильтр качества. Без него команда получает не ускорение разработки, а ускорение накопления технического долга.

Отсюда растет значение человека в контуре принятия решения. Это не декоративный надзор и не механическое нажатие «принять» в подсказках. Настоящий human-in-the-loop означает, что человек понимает критерии приемки, видит ограничения системы, умеет отклонить красивое, но неверное решение и несет ответственность за слияние изменений в основную ветку.

Для компании это меняет экономику разработки. Если ИИ помогает опытным инженерам закрывать больше мелких задач, работодатель может пересмотреть найм новичков и структуру команды. Но если растут переделки, дефекты, нагрузка на ревью и расходы на поддержку, экономия оказывается мнимой. Поэтому внедрение ИИ нельзя оценивать по строкам кода. Важны время до надежного релиза, дефекты, инциденты, стоимость сопровождения и способность команды обучать новых людей.

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

Как меняется спрос на навыки

В прежней модели карьерного входа junior часто получал небольшие задачи: поправить форму, написать CRUD-метод, то есть типовую операцию создания, чтения, обновления или удаления данных, покрыть код тестами, исправить баг по описанию. Теперь именно такие задачи проще всего частично отдать ИИ-инструменту под наблюдением более опытного инженера. Это не значит, что junior-разработчики не нужны. Это значит, что компаниям труднее объяснить, за что платить новичку, если его тренировочная работа автоматизируется.

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

Отдельный слой: профессиональная работа с ИИ-инструментами. Это не только «умение писать промпты», то есть запросы к модели, а построение процесса: сформулировать задачу так, чтобы ее можно было проверить; дать модели минимально достаточный контекст; ограничить область изменений; потребовать тесты; сравнить варианты; зафиксировать, какие решения принял человек, а какие предложила система. Такой навык ближе к инженерному контролю, чем к диалогу с чат-ботом.

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

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

Один кейс не равен тренду, но сдвиг виден

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

Но признаки более широкого движения есть. Во-первых, сам мониторинг AI incidents выделяет подобные сообщения как общественно значимые события, даже когда они требуют проверки. Это показывает, что трудовые последствия ИИ стали частью повестки рисков, а не только продуктового маркетинга.

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

В-третьих, спрос на инфраструктуру для ИИ и робототехники влияет на смежные технологические рынки. Reuters в материале об Altera связывает возвращение компании к росту со спросом, который подпитывают AI и robotics. Это не статистика занятости программистов, но сигнал масштаба технологического цикла, внутри которого развивается автоматизация разработки.

Осторожный вывод: доказанного массового увольнения программистов из-за Claude Fable 5 у нас нет. Но есть подтверждаемый контекст, в котором ИИ становится частью производственного контура разработки, компании экспериментируют с экономикой команд, а рынок начинает переоценивать навыки, которые раньше считались вторичными по сравнению со скоростью написания кода.

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

Где работодатели могут ошибиться

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

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

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

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

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

Российский контекст: удержание, переобучение и осторожность

Для России в предоставленном досье нет подтвержденного кейса массового увольнения разработчиков именно из-за внедрения ИИ. Поэтому переносить историю Claude Fable 5 на российский рынок нельзя. Можно говорить о другом: тема людей, удержания и перестройки рынка труда уже вынесена в деловую повестку. «Ведомости» по итогам Форума про людей сформулировали сдвиг как переход рынка труда от найма к удержанию.

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

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

Здесь тоже нужна осторожность. Наличие ИИ в названии форума, конкурса или продукта не равно массовому внедрению в рабочих процессах, тем более сокращению программистов. Доказательная формулировка для российского контекста скромнее: работодателям и разработчикам нужно готовиться к росту требований к ИИ-грамотности и инженерному контролю, но утверждать волну увольнений на основании текущего набора источников нельзя.

Для руководителей это означает, что разговор об ИИ в разработке лучше вести не через страх, а через понятные изменения в процессах. Какие задачи автоматизируются? Кто проверяет результат? Как меняется роль новичка? Что компания делает, чтобы не потерять способность выращивать специалистов? Эти вопросы важнее громкой формулы о замене людей.

Граница автоматизации: что остается за человеком

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

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

Это не отменяет реальных рисков для работников. Уязвимее становятся роли, где ценность сводилась к однотипной реализации по четкому шаблону. Но автоматизация операций не равна исчезновению профессии. Она меняет внутреннюю структуру спроса: меньше ценится механическое производство кода, больше ценится способность превращать неопределенную задачу в безопасное и поддерживаемое изменение системы.

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

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

Что это означает на практике

Практический вывод из истории Claude Fable 5 не в том, что программистов завтра заменят. Вывод в том, что участникам рынка нужно перестать оценивать работу разработчика только по скорости написания кода. ИИ делает черновую реализацию дешевле, но повышает цену ошибки в постановке задачи, ревью и эксплуатации.

• Разработчику стоит тренировать не только работу с подсказками, но и постановку задачи, критерии приемки, ревью AI-output, тестирование, безопасность и сопровождение кода.
• Junior-разработчикам важно сохранять базовую инженерную практику: читать чужой код, дебажить, писать тесты, понимать архитектуру. Без этого невозможно надежно проверять предложения ИИ.
• Senior-инженерам придется становиться дизайнерами рабочего процесса: решать, какие задачи делегировать инструментам, где нужен human-in-the-loop и как не превратить ревью в узкое место.
• Компаниям нельзя считать экономию по числу сгенерированных строк. Нужно измерять время до релиза, дефекты, переделки, нагрузку на ревью, инциденты, риски безопасности и обучение новичков.
• HR и руководителям разработки стоит пересмотреть планирование команды: не сокращать роли механически, а описывать новые зоны ответственности, правила использования ИИ и pipeline подготовки специалистов.
• Российским работодателям корректнее говорить о росте требований к ИИ-грамотности и удержании людей, а не о доказанной волне увольнений разработчиков из-за ИИ.

Чек-лист: как внедрять ИИ в разработке без иллюзии экономии

Этот чек-лист можно использовать перед пилотом ИИ-инструментов в команде разработки, при пересмотре ролей или при оценке уже запущенной автоматизации.

Проверить доказательства

Перед тем как принимать кадровые или процессные решения, важно отделить подтвержденные данные от громких историй.

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

Описать задачи, а не роли целиком

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

• Выделить повторяемые задачи с короткой обратной связью: тесты, черновые функции, объяснение ошибок, подготовку документации.
• Отдельно описать задачи, где цена ошибки высока: архитектура, безопасность, доступы, эксплуатация, пользовательские сценарии.
• Назначить, кто имеет право принимать или отклонять предложения ИИ.
• Запретить автоматическое слияние изменений без понятных критериев ревью и тестирования.

Настроить контроль качества

Ускорение генерации полезно только тогда, когда команда успевает проверять результат.

• Заранее определить критерии приемки для задач, которые выполняются с помощью ИИ.
• Измерять нагрузку на ревью и не считать ее бесплатной.
• Проверять, не растет ли технический долг после ускорения разработки.
• Следить за дефектами, инцидентами, объемом переделок и стабильностью тестов.
• Фиксировать, какие решения предложила система, а какие принял человек.

Сохранить обучение новичков

Если простые задачи уходят ИИ, компания должна заново спроектировать вход в профессию.

• Оставить junior-разработчикам пространство для чтения кода, отладки, тестирования и сопровождения.
• Не подменять обучение новичков пассивным наблюдением за подсказками ИИ.
• Назначать наставников, которые объясняют не только правильный ответ, но и причины отклонения машинных вариантов.
• Проверять, не исчезает ли в команде pipeline подготовки будущих middle- и senior-инженеров.

Вывод

История про Claude Fable 5 полезна именно потому, что не дает простого вывода. Заголовок обещает ясную причинность: внедрили ИИ, сократили разработчиков. Проверка показывает другое: это вирусное и непроверенное утверждение, зафиксированное в мониторинге AI incidents, а не доказанный кейс рынка труда.

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

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

Источники

• OECD AI Policy Observatory: AI System Claude Fable 5 Leads to Mass Developer Layoffs at Software Company
• OECD AI Policy Observatory: AI Incidents Monitor
• Microsoft Azure Blog: AI and machine learning
• Microsoft Azure Blog: Developers
• Microsoft Azure Blog: AI tag
• Reuters: Altera returns to growth as AI, robotics fuel demand, CEO says
• Ведомости: «Ведомости» подвели итоги Форума про людей: рынок труда переходит от найма к удержанию
• Ведомости: Искусственный интеллект, роботы и системы накопления энергии : в фокусе внимания конкурса «Энергопрорыв–2026»

Частые вопросы

Доказано ли, что Claude Fable 5 стал причиной массовых увольнений разработчиков?

Нет. В доступном досье это описано как непроверенное и анонимное утверждение. Компания не названа, независимого подтверждения в предоставленных материалах нет, поэтому кейс нельзя подавать как установленный факт.

Значит ли это, что ИИ не влияет на профессию программиста?

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

Какие разработчики становятся наиболее уязвимыми?

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

Что компаниям стоит измерять при внедрении ИИ в разработке?

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

Есть ли подтвержденная волна увольнений разработчиков из-за ИИ в России?

В предоставленном наборе источников такого подтвержденного кейса нет. Для российского контекста корректнее говорить о росте требований к ИИ-грамотности, удержании и переобучении людей, а не о доказанной волне сокращений программистов.

Практический чек-лист

Чек-лист: как внедрять ИИ в разработке без иллюзии экономии

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

Проверить доказательства

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

Описать задачи, а не роли целиком

• Выделить повторяемые задачи с короткой обратной связью: тесты, черновые функции, объяснение ошибок, подготовку документации.
• Отдельно описать задачи, где цена ошибки высока: архитектура, безопасность, доступы, эксплуатация, пользовательские сценарии.
• Назначить, кто имеет право принимать или отклонять предложения ИИ.
• Запретить автоматическое слияние изменений без понятных критериев ревью и тестирования.

Настроить контроль качества

• Заранее определить критерии приемки для задач, которые выполняются с помощью ИИ.
• Измерять нагрузку на ревью и не считать ее бесплатной.
• Проверять, не растет ли технический долг после ускорения разработки.
• Следить за дефектами, инцидентами, объемом переделок и стабильностью тестов.
• Фиксировать, какие решения предложила система, а какие принял человек.

Сохранить обучение новичков

• Оставить junior-разработчикам пространство для чтения кода, отладки, тестирования и сопровождения.
• Не подменять обучение новичков пассивным наблюдением за подсказками ИИ.
• Назначать наставников, которые объясняют не только правильный ответ, но и причины отклонения машинных вариантов.
• Проверять, не исчезает ли в команде pipeline подготовки будущих middle- и senior-инженеров.