Я всё ещё боюсь работать с ИИ

Хабр, привет! Меня зовут Никита, я — Rust-разработчик. Под прошлой статьёй мне справедливо напихали напомнили, что часть моих претензий к ИИ уже устарела: местами я писал ещё про инструменты 2024–2025 годов. Сейчас агенты пишут код быстро и в целом неплохо. Но я и тогда больше боялся того, сколько кода можно нагенерировать и кому потом во всём этом разбираться. В этой части я продолжу ту же мысль, просто на других примерах.

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

Теперь мы все продуктовые инженеры

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

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

Саму идею придумали не вчера. Ли Робинсон ещё в 2023 году в Product Engineers писал, что деление на фронтендеров и бэкендеров становится менее полезным. Есть нужный пользователю результат, и ты работаешь со всем стеком, чтобы его получить. Глубоко знать каждую технологию, по его определению, необязательно. Инфраструктурой при этом занимаются платформенные инженеры.

Лори Восс в сентябре 2026 года идёт еще дальше: «We are all Product Engineers now». В его прогнозе агенты со временем берут на себя весь технический цикл, а человек выясняет, что нужно людям и каким должен быть результат. Всё это сработает, если агенты действительно освоят остальную разработку. Пока это допущение самого Восса.

Меня беспокоит, что задачи из соседних специализаций могут начать раздавать уже сейчас. Вот красил ты кнопки на фронте, но появилась задача в том старом C++ монолите на 300k строк. Не переживай, всё супер, главное выбери самую последнюю модель, обязательно самый последний thinking mode и не забудь скилл brainstorm подключить. Удачных вам голодных игр, пусть удача всегда будет с вами. А, и да, старого разраба с того монолита мы уволили. Как-то он мало кода писал, и токенов тоже мало тратил, странный тип крч.

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

Одного болванчика уже мало

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

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

Можно попросить первого кратко описать, что уже сделано и на чём остановились. Только этот пересказ тоже желательно прочитать. Иначе вместе с файлами новому помощнику достанется уверенное объяснение, что все проверки пройдены, проблема локализована и осталось буквально чуть-чуть до удаления прод. базы.

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

При этом поведение меняется не только при переходе на новую модель. В апреле 2026 года Anthropic разобрала ухудшение качества Claude Code. Компания обнаружила три причины: изменение глубины рассуждений по умолчанию, ошибку удаления предыдущих рассуждений и правку системного промпта. В одном из случаев попытка сократить многословность ухудшила качество работы с кодом. Эти проблемы исправили.

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

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

Если на работе разрешён только свой болванчик

Есть компании, где вся эта коллекция подписок пригодится тебе только дома. На работе разрешены только свои модели или локальные. Код и данные наружу не уходят, внешними сервисами пользоваться нельзя. Даже со своей подпиской. GitLab, например, описывает такие корпоративные внедрения, где отправлять данные внешним ИИ-провайдерам вообще не вариант.

И вот ты уже привык к сильным агентам от Anthropic и OpenAI, которые сами читают проект, правят код и прогоняют тесты. А на работе выдали помощника, который эм, ну как бы он есть, он сияет...

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

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

Меня бы ещё напрягало, если сроки при этом назначают по демке последней модели Anthropic или OpenAI. Там агент сам разобрался и всё сделал, а у тебя полдня ушло на объяснения рабочему болванчику. Хотелось бы сначала проверить, как он справляется с нашими задачами, а уже потом закладывать замедление ускорение в план.

Meat proxy: я уже переслал твой вопрос нейросетке

Я спросил у ИИшки, есть ли ошибки. Она сказала: нет. В августе 2026 года Никлас Грун написал про meat proxy: человека, который пересылает результат ИИ дальше, не разобравшись в нём и не проверив его. При желании можно перевести как «мясной прокси», но я бы дал ещё одно название: Коллега Driven Development.

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

Пишешь замечание, коллега пересылает его агенту, приносит новый diff. И так по кругу. Ты уже разбираешься в задаче и направляешь реализацию, а коллега освоил Ctrl+C и Ctrl+V. Зато свою часть работы он ускорил, можно отчитаться. Твоё время в этот замер как-то не попало.

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

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

Код пишет агент, а занят всё равно ты

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

Когда пишешь код сам, по дороге успеваешь разобраться, почему решил сделать именно так. А со своим агентом тебе сразу выдают готовое решение. Теперь надо понять, как оно работает и что заденет. Глаза по diff пробежали быстро, а с пониманием как-то не ускорилось.

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

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

Вот в таком режиме я бы и боялся выгореть. Хотел освободить время на тик-токи, а теперь несколько агентов по очереди сообщают, что мне пора поработать.

Даже хорошие результаты могут добавить работы. Мейнтейнер curl Дэниел Стенберг писал про High-Quality Chaos: по его оценке, почти все отчёты о проблемах безопасности теперь пишут с помощью ИИ. Они стали качественнее, но и приходят примерно вдвое чаще, чем в 2025 году. Каждый настоящий баг нужно воспроизвести, исправить и выпустить обновление. Если агент найдёт ещё десять, мейнтейнеров от этого больше не станет.

Теперь нужно читать ещё и спецификации

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

Есть SDD (Spec-Driven Development), то есть разработка на основе спецификаций. Сначала разбираемся, что и зачем делаем, фиксируем требования, а уже по ним строим реализацию. Например, в GitHub Spec Kit ты коротко описываешь, что и зачем нужно, а агент разворачивает это в спецификацию. От неё переходят к техническому плану и задачам, затем к коду и проверке соответствия. По дороге результаты нужно просматривать.

И вот у тебя теперь ревью ещё и markdown-файлов. Агент расписал требования, подготовил план, всё выглядит круто. Только если он неверно понял задачу, эта ошибка может спокойно доехать до кода и тестов. Согласованность будет, а вот нужный результат не факт. Можно попросить выжимку, чтобы меньше читать. Тогда ошибку тебе перескажут покороче. Теперь точно согласовано.

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

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

Репозиторий Шрёдингера

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

Margaret-Anne Storey описывает это как cognitive debt: команда постепенно теряет общее понимание системы.

Помнить каждую строку необязательно. Но если агент предлагает убрать проверку или транзакцию, хорошо бы понимать, зачем она там появилась. Обычно можно спросить того, кто её добавил. А здесь он только проверил, что всё работает. Автор PR есть, git blame показывает на коллегу, коллега показывает на Claude. Разработчик ещё не уволился, а знания уже потеряли.

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

В этом смысле мы и становимся зависимы от агента. Только у него тоже нет гарантированно верного понимания всей системы: он собирает его по доступным файлам и может ошибиться.

Бизнес уже заложил ускорение в следующий план

Допустим, первые задачи с агентом ты закрыл быстрее. Руководство заметило и выдало тебе премию ещё задач. Часть ты набрал и сам, как сотрудники из исследования Berkeley: инструмент помогает, почему бы не воспользоваться. Только в план заложили скорость первых задач, а время ревьюера и твоё «разберусь потом» в эту скорость не попали.

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

Сначала ты задерживаешь PR, чтобы нормально разобраться. Потом ещё один. Каждый раз объясняешь, почему с ИИ всё ещё не готово. Если сроки при этом не меняются, в какой-то момент очень хочется посмотреть только основные файлы и нажать approve. Тесты зелёные, на демо работает, остальное потом.

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

И что в итоге

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

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

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

Надеюсь, хоть немного выигранного времени получится потратить на то, чтобы разобраться в сделанном. А то следующую статью придётся назвать «Я всё ещё боюсь работать с ИИ, но объяснять уже некогда, меня ждут 69 агентов».

P.S. По традиции оставлю ссылку на мой канал с IT-мемами. Спасибо, что дочитали.