Я боюсь работать без ИИ

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

Сначала была статья «Я не боюсь, что меня заменит ИИ. Я боюсь работать с ИИ». Потом появилась «Я всё ещё боюсь работать с ИИ». Теперь пишу «Я боюсь работать без ИИ».

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

А болванчиком пользоваться можно?

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

1. «Мы супер-пупер AI-native компания». ИИ в обязанностях, ИИ в требованиях, ИИ в рассказе о культуре. Нужно пользоваться агентами, внедрять агентов и желательно ещё самому быть агентом 007: 0 выполненных задач за дедлайн, 0 релизов без инцидентов, 7 перекуров за час. Что за продукт предстоит разрабатывать не важно, главное что мы AI-native.

2. ИИ по делу. Понятно, что за продукт, какие задачи и зачем тут агенты. Написано, чем можно пользоваться и что оплачивает компания. Вот такое хочется читать. А то требования к моему болванчику уже на полстраницы, а выдадут ли мне вообще подписку, ещё надо спросить.

3. Про ИИ ничего не написано. Rust, PostgreSQL, микросервисы, дружный душный коллектив. Всё по базе. Что будет с твоим привычным способом работы, выяснишь уже при общении.

После некоторых описаний из первого пункта представляешь: «Мы первая AI-native шаурмечная в мире». Почему AI-native? Потому что все картинки в меню сгенерированы ИИ. Хотелось бы всё-таки узнать, как шаурма.

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

С третьим вариантом тоже всё интересно. В вакансии про ИИ ни слова, приходишь на собеседование, а дальше возможны разные условия.

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

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

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

Причём «у нас можно пользоваться ИИ» теперь тоже требует уточнений. Подписку компания оплачивает или предполагается моя? Можно выбрать помощника или есть утверждённый список? Ему разрешено читать репозиторий, запускать проверки, обращаться к рабочим сервисам? Для аутстаффа ещё интересно, согласен ли со всем этим заказчик и знает ли аутстафф, что такие вопросы надо спрашивать у заказчика.

На собеседовании я бы расспросил, как команда решала с агентом какую-нибудь недавнюю задачу. Что ему поручили, к чему у него есть доступ и что пришлось доделывать самим. А то «у нас все пользуются ИИ» может означать и готовое окружение, и «ну мы иногда код в чатик кидаем».

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

Мне нужна ещё и обвязка

Недавно на работе коллега спросил: «Кто каким git-клиентом пользуется?» Я в шутку ответил: «Что такое git-клиент?» Шутка шуткой, но действительно вырастет поколение разработчиков, которое, возможно, даже не будет знать, что такое git-клиент. Для коммита или просмотра изменений им будет достаточно привычного агента. Он сам найдёт что нужно, и предложит варианты действий.

Через MCP и другие подключения агенту можно дать доступ к рабочим инструментам. Тогда в одном диалоге получится посмотреть логи в Elastic, проверить сборку в Jenkins, сделать коммит и обновить статус задачи. К такому способу работы тоже очень быстро привыкаешь.

Например, можно попросить: «После последнего деплоя сервис начал отдавать 500. Посмотри ошибки в Elastic и проверь, какие изменения вошли в этот релиз».

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

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

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

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

Если в компании это уже настроили, я только за. Мне тоже не особо хочется после перехода на новую работу сначала устроиться ещё и разработчиком обвязки для своего болванчика.

Кроме доступа к сервисам, агенту пригодятся объяснения того, почему в проекте что-то сделано именно так.

Например, агент предлагает убрать проверку. Пишу коллеге, который давно на проекте: зачем она тут? Он объясняет, что без неё однажды всё легло. И вот я иду к своему болванчику пересказывать разговор. Подрабатываю мясным MCP-сервером.

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

Найм

Найм и так был мясорубкой, а теперь, как сказал бы один герой из игры, стал скоростной мясорубкой.

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

Теперь готовую реализацию можно получить от болванчика. Ещё в работе 2025 года об олимпиадном программировании авторы сообщали о результате o3 на Codeforces на уровне сильнейших участников.

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

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

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

У меня на работе была задача, где можно было вернуть HashMap, но я специально выбрал BTreeMap. С хэшмапой поля в результатах разных запросов оказывались в разном порядке, и это мешало отлаживать.

У HashMap порядок обхода не гарантирован, а BTreeMap выдаёт элементы по порядку ключей. Мне было важно, чтобы при чтении результата поля оставались на привычных местах. При этом поиск по ключу у BTreeMap имеет сложность O(log n), а у HashMap ожидаемая сложность — O(1). В этой задаче я предпочёл упорядоченный вывод ради удобства отладки.

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

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

Без ИИ я бы за это не взялся

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

Например, у меня есть крейт field-kinds с derive-макросом для получения сведений о полях структуры: имён, категорий типов, тегов и названий с учётом serde. Без ИИ я бы его делать не стал. Кто писал макросы в Rust, думаю, меня поймёт. Я посмотрел, с чем придётся разбираться, и желания делать всё это самому у меня не появилось.

С болванчиком, кстати, тоже делал долго. Всё тщательно разбирал, проверял и тестировал. Довёл покрытие тестами до 100%.

Но крейт в итоге появился. Поэтому на вопрос «сколько времени тебе сэкономил ИИ» тут сложно ответить. Без него я бы потратил ноль часов и ничего не сделал.

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

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

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

Нам повезло сначала научиться

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

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

Мне удобнее разбираться, когда уже есть конкретное предложение, к которому можно придраться. Могу объяснить, где уже видел похожую ошибку, какое поведение ожидаю и почему предложенное решение мне не нравится. Чуть подробнее, чем «какая-то фигня, переделай».

У начинающего такого опыта может ещё не быть. Зато агент уже доступен и готов сразу выдать реализацию вместе с объяснением, почему всё сделано правильно. Спросить «почему» можно. Только насколько легко будет заметить, что в ответ тебе уверенно объяснили ерунду?

В эксперименте Anthropic разработчики осваивали новую библиотеку Trio. На проверке понимания группа с ИИ получила в среднем 50%, без ИИ — 67%. Участники, которые разбирались в объяснениях и задавали концептуальные вопросы, показали более высокие результаты. Это короткий эксперимент с одной библиотекой, а способы работы участников отдельно не распределяли случайным образом. Совет «просто спрашивай почему» из этих цифр не следует.

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

Готовые ответы были и до агентов, привет Stack Overflow. Но там обычно пример для чужой задачи: другая версия библиотеки, другое окружение, вообще половина условий не твоя. Копипастишь, не работает, идёшь читать другие ответы и разбираться, что поменять. Иногда хватало заменить имя переменной, но часто всё-таки приходилось хоть немного вникнуть. А болванчику можно сразу отдать свой код, потом принести ошибку и попросить поправить. И так до тех пор, пока не заработает. Самому разбираться уже не обязательно.

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

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

Обратно уже не хочется

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

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

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