Я не боюсь, что меня заменит ИИ. Я боюсь работать с ИИ

Хабр привет, меня зовут Никита, я Rust разработчик. Самой первой же статьёй врываемся на хайповую тему: как ИИ меняет разработку ПО и почему я боюсь работать с ним. Понятное дело название немного провокационное, статью не стоит воспринимать серьёзно и буквально. Готовьте свои харнесы ремни, мы начинаем.

Я не боюсь, что однажды модель получит мою должность, а меня пнут под зад. Меня беспокоит более прозаичный вариант: код станет дешевле создавать, его станет больше, а понимать и обслуживать результат всё равно придётся разработчикам или другим людям, которые хоть как‑то понимают, что там внутри происходит.

Об ИИ часто говорят как об автоматизации части разработки. Если модель пишет функцию за минуту вместо часа, кажется, что оставшиеся 59 минут можно ничего не делать удалось сэкономить, но в 99% подозрительно большом числе случаев это не так. Функция не существует в вакууме, она является частью проекта, который уже написан и возможно где‑то крутится в проде, имеет пользователей и приносит деньги. Модель ускоряет только самый заметный участок работы, а остальной цикл разработки ПО никуда не девается.

Более того, для работы самой модели появляется отдельный слой, который также нужно поддерживать. Ей нужно передать контекст, открыть доступ к инструментам, ограничить права, проверить результат и сохранить достаточно данных для разбора ошибки, но это если вы не хотите превратить проект в VaaS (Vulnerability as a Service). Вместо программы мы начинаем обслуживать программу вместе с системой, которая эту программу потом пишет.

TLDR

Конечно же для адептов данного мема как я мог оставить вас без TLDR?

• Ощущение скорости обманывает. Агент генерирует diff быстро, но подготовка контекста, проверка и исправления остаются. Считать нужно время до рабочего изменения, а не до первого ответа модели.

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

• Проект приходится готовить к агенту. Вокруг него вырастает harness: инструкции, sandbox, компилятор, линтеры, CI. Отчёт агента о проделанной работе ничего не значит, значат exit code, тесты и реальный diff.

• Агент усиливает то, что уже есть. Подгонять под него стек бессмысленно: модель поменяется раньше проекта. На понятной базе с быстрыми проверками он ускоряет работу, в хаосе — плодит хаос. Из джуна получится 10x джун, а не мидл.

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

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

• За генерацию всё равно кто‑то платит. Каждый новый diff проходит через CI, сборки, хранилище и ревью. Работа и расходы перемещаются к платформенной команде, ревьюерам и инфраструктуре.

• Метрики легко начинают измерять не то. Лицензии, токены и долю ИИ‑кода удобно показывать в отчёте и легко накручивать. Время доставки, откаты и инциденты выглядят скучнее, зато говорят о результате.

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

• Прямая генерация бинарников ничего не отменяет. Всё равно понадобятся версия модели, контекст, требования, тесты и воспроизводимый процесс. В итоге мы снова получим исходный код, только на русском и с вероятностной компиляцией.

• С агентом можно нормально работать, пока результат ограничен и проверяем. Проблемы начинаются, когда людей становится меньше, план не уменьшается.

Где расходуется время

С агентом легко почувствовать себя в десять раз быстрее. Поставил задачу, посмотрел пять минут на бегущие доллары токены и получил готовый diff. Если считать только эти пять минут, результат действительно впечатляет.

Только таймер задачи запускается раньше и останавливается позже. Агенту нужно передать контекст и объяснить соглашения проекта. После генерации кто‑то (надеюсь) читает diff, разбирает странные решения и проверяет, не задел ли агент код, который вообще не требовалось менять. Неудачный результат можно перегенерировать, но новый diff от этого не становится проверенным.

Про исследование METR, думаю, уже слышали почти все. В эксперименте 2025 года разработчикам казалось, что ИИ ускорил их на 20%, хотя по таймеру задачи выполнялись на 19% дольше. Позднее METR изменили дизайн следующего исследования, потому что инструменты успели измениться. Для меня здесь важен вывод: ощущение скорости и реальное время выполнения задачи могут сильно расходиться.

Теперь инфраструктуру приходится писать дважды

У типичного веб‑приложения уже было два входа: сайт для человека и API для другого кода.

С появлением агентов ни сайт, ни API никуда не делись. Просто появился ещё один клиент, которому те же возможности нужно отдать в другой упаковке.

Методы API теперь приходится представлять как инструменты с понятными для модели названиями, описаниями и схемами параметров. Для этого появляется MCP‑сервер. Репозиторию нужны `CLAUDE.md`, `AGENTS.md` или другие инструкции, которые объясняют агенту как заходить в хату местные правила. Для сайта отдельно описывают ограничения для ИИ‑краулеров в `robots.txt`, а на стороне агента для работы через интерфейс появляется браузерный слой, который позволяет агенту читать страницу и выполнять действия.

MCP упрощает подключение этих инструментов, но не заменяет существующий API. Обычно MCP‑сервер вызывает тот же API от имени агента. В архитектуре протокола между моделью и сервисом появляются host, client и server. У этого слоя свои разрешения, авторизация, журнал вызовов и обработка ошибок.

Получается, один и тот же функционал приходится поддерживать сразу в нескольких формах. Создание задачи в трекере остаётся кнопкой на сайте и методом API, а теперь становится ещё и MCP‑инструментом. При изменении нужно синхронизировать контракт, описание, права доступа и тесты для каждого входа.

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

Разработку частично приходится перестраивать под агента

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

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

Чем точнее ошибка компилятора или теста, тем меньше свободы остаётся у модели для следующей попытки. Сам агент может написать в отчёте, что задача выполнена и все требования соблюдены. Для harness имеют значение exit code компилятора, результаты тестов и реальный diff. Эти сигналы не зависят от того, насколько убедительно модель описала свою работу.

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

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

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

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

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

Есть ещё одна неприятная особенность: агент часто пишет тест одновременно с кодом. Если он неправильно понял требование, то способен закрепить ту же ошибку в ожидаемом результате. Поэтому старые регрессионные тесты особенно ценны, а изменение существующего assert требует такого же внимания, как рабочий код. Зелёный CI, полученный удалением неудобной проверки, означает только то, что проверку удалили.

Агент усиливает то, что уже есть в проекте

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

Знакомство агента со стеком действительно можно учитывать: незнакомая технология потребует больше контекста, попыток и исправлений. Но подгонять архитектуру проекта под ограничения текущей модели не всегда лучшее решение. Модель через полгода поменяется, а выбранный ради неё стек останется с командой.

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

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

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

С разработчиком работает так же. Агент усиливает текущий грейд, но не повышает его автоматически. Джун может сгенерировать в десять раз больше кода, но от этого не научится видеть архитектурные последствия и выбирать компромиссы. Получится 10x джун, НО не мидл.

Вместе с агентом появляется ещё один контур атаки

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

Самый красивый пример — выдуманные библиотеки. Модель уверенно вставляет в код несуществующий пакет, а атакующий публикует пакет с таким именем и вредоносной нагрузкой. При следующей генерации разработчик или сам агент устанавливает уже настоящий пакет. Этот сценарий называют slopsquatting. В исследовании USENIX Security 2025 авторы получили 205 474 уникальных имени несуществующих пакетов в 576 тысячах сгенерированных примеров кода.

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

Есть и prompt injection. Инструкция для модели может находиться не в сообщении пользователя, а в issue, README, веб‑странице или ответе MCP‑сервера. Человек увидит текст, а агент может принять его за команду. Если у него есть доступ к почте, репозиторию или продакшену, проблема быстро превращается из плохого ответа в реальное действие. OWASP описывает эту связку как prompt injection и excessive agency.

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

Код становится дешевле и его становится больше

Даже если агент не установил вредоносную библиотеку и не отправил кому‑нибудь токен от прода, сгенерированный результат всё равно остаётся в проекте. Фраза «больше кода означает больше багов» слишком грубая. Сто строк могут быть сложнее тысячи, а полезные тесты тоже увеличивают репозиторий. Проблема начинается, когда то же поведение размножается по дополнительным веткам, зависимостям и копиям уже существующего кода.

В отчёте GitClear за 2025 год разобрали 211 миллионов изменённых строк. С 2020 по 2024 год доля copy/paste внутри коммита выросла с 8,3% до 12,3%, churn новых строк за две недели — с 3,1% до 5,7%, а доля перемещённого кода снизилась с 24,1% до 9,5%. Это данные GitClear, и они показывают совпавший по времени тренд, но не доказывают, что причиной был именно ИИ, хотя тут как будто очевидно.

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

За генерацию платят люди и инфраструктура

Код можно сгенерировать за несколько секунд, но pull request всё равно проходит анализаторы, тесты, сборку образов и ревью. При массовой генерации оплачиваются не только токены, но и runner, CPU, хранилище, сеть и каждая повторная попытка.

17 августа 2026 года GitHub пережил сбой продолжительностью 7 часов 47 минут. Согласно официальному разбору, трафик достиг нового пика, а критический компонент в одном из дата‑центров не смог масштабироваться. Давление на инфраструктуру затронуло github.com, аутентификацию, Actions, API, pull requests, issues и Copilot.

GitHub сообщил, что с апреля число коммитов в месяц выросло с 1,4 до 2,9 миллиарда. Компания добавила более трёх миллионов CPU‑ядер и 120 петабайт быстрого хранилища. Во время восстановления ошибки сервисов Copilot вызвали цикл повторных запросов, который дополнительно увеличил трафик.

Причиной GitHub называет нехватку ёмкости и рост коммитов одним фактором не объясняет. Но удвоение потока изменений в любом случае требует реальных серверов, дисков и сети.

Так же и с людьми. Генерацию оплачивает не тот, кто её запустил: написанный за минуту diff читает ревьюер, а очередь в CI и счета за токены достаются команде платформы.

Появляется и работа, которой раньше не было. Кто‑то описывает инструменты для модели, поддерживает MCP‑сервер, раздаёт и отзывает разрешения, разбирает трассы вызовов и переписывает проверки после очередной смены модели. Часть ручного программирования при этом действительно исчезает, только освободившееся время уходит к сожалению не в отпуск.

Компания может считать такой перенос выгодным. Сотруднику от этого не обязательно становится проще.

Метрики, которые измеряют не то

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

Так появляются показатели вида: процент сотрудников с активной лицензией, число принятых подсказок, доля строк в PR, написанных моделью, количество задач, закрытых агентом, и потраченные токены. Считать их удобно ещё и потому, что вендор посчитал всё за вас: GitHub отдаёт метрики использования Copilot с adoption, engagement и acceptance rate, то есть процентом принятых подсказок.

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

Токены в роли KPI работают особенно бодро. Чем хуже сформулирована задача и чем больше попыток потребовалось, тем выше показатель. Премию, получается, выдают за плохой промпт.

С долей ИИ‑кода непонятно, что именно туда попадает. Автодополненная закрывающая скобка и сгенерированный с нуля сервис могут оказаться в одной колонке, а где проводить границу для сгенерированного и затем переписанного руками кода, вообще неясно.

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

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

ИИ в объяснениях увольнений

Во время пандемии технологические компании быстро расширяли штат. Онлайн‑сервисы росли, капитал был дешёвым, а руководство ожидало продолжения тренда. Потом спрос изменился, и начались сокращения.

Признать ошибку прогноза компании при этом вполне способны. В ноябре 2022 года Марк Цукерберг написал сотрудникам Meta, что ожидал постоянного ускорения электронной коммерции, увеличил инвестиции и ошибся. Акции от таких признаний тоже не обваливаются: в день объявления о сокращении 12 тысяч сотрудников бумаги Alphabet выросли на 4%.

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

Проверить формулировку снаружи почти невозможно. В обзоре AP об увольнениях в Amazon, Expedia, Pinterest и Dow названа та же проблема: внешнему наблюдателю трудно отделить реальную замену труда от сообщения для инвесторов. Зато внутри компании обещание приходится подтверждать, и делают это оставшиеся сотрудники: меньшим числом, с теми же системами и с новой обязанностью показывать хорошие цифры по использованию агента.

А потом ИИ сгенерирует бинарник и мы все как заживем

Следующий шаг в этом обещании эффективности — убрать не только часть команды, но и сам исходный код.

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

Здесь модель объявляется новым уровнем абстракции, а исходный код деталью реализации этажом ниже. Ассемблер в этой аналогии действительно почти перестали читать, только случилось это по вполне конкретным причинам. У компилятора есть явный и версионируемый исходник. При зафиксированных зависимостях и toolchain сборку можно сделать воспроизводимой, а отладочная информация связывает стектрейс с исходным кодом. Если программа ведёт себя не так, правку вносят в исходник и собирают заново.

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

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

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

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

Когда я согласен работать с ИИ

Я не предлагаю запретить агентов и вернуться в пещеру писать байткод на камнях. Если модель подготовила небольшой diff, который я понимаю и могу проверить обычными средствами проекта, всё отлично. Забираю.

Только экономию нужно считать не до первого сгенерированного ответа, а до изменения, которое доехало до прода и не вернулось оттуда в виде инцидента. В этот срок входят контекст, попытки, ревью, тесты и исправления после merge.

Проблемы начинаются, когда использование агента становится обязательным, людей в команде становится меньше, а план остаётся прежним или, чаще всего, растёт.

В такой системе ИИ не заменил меня. Он стал коллегой, который пишет с огромной скоростью, не помнит историю проекта и никогда не дежурит в проде. Когда всё работает, в отчёте команда ускорилась благодаря ИИ. Когда всё падает, ночью просыпается почему‑то не модель, а я или бедный девопс (хотя, учитывая их ЗП, может и не очень бедный).

Вот этого я и боюсь. Не того, что ИИ заберёт мою работу, а того, что именно это и станет моей работой с ИИ.

P. S. Конечно же, как в конце статьи может не быть ссылки на ТГ канал автора? Мой канал с IT‑мемами: когда будет много человек, я смогу крутить рекламу казика и не работать, спасибо за внимание.