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

Ключевой тезис материала — ИИ перестал быть личным делом разработчика и превратился в условие найма, которое нужно прояснять до выхода на работу. Никита предлагает смотреть на вакансии не только через стек, зарплату и формат занятости, но и через вопрос о том, чем в компании разрешено пользоваться. Он выделяет три условных типа объявлений: «AI-native» с ИИ в обязанностях и культуре, но без понятного продукта; вакансии, где ИИ упомянут по делу с описанием доступных инструментов и компенсации подписок; и объявления, где про ИИ не сказано ничего. В последнем случае реальные условия выясняются только на собеседовании, и там возможны как запрет на внешних помощников, так и полностью настроенное окружение. Отдельно автор отмечает, что формулировка «у нас можно пользоваться ИИ» требует уточнений: кто платит за подписку, есть ли утверждённый список инструментов, разрешён ли агенту доступ к репозиторию, проверкам и рабочим сервисам, а для аутстаффа — согласен ли с этим заказчик.

С технической стороны Никита описывает, как выглядит привычная ему обвязка. Через MCP и другие подключения агент получает доступ к рабочим инструментам, и в одном диалоге можно посмотреть логи в Elastic, проверить сборку в Jenkins, сделать коммит и обновить статус задачи. В качестве примера он приводит запрос: после последнего деплоя сервис начал отдавать 500, нужно найти ошибки в Elastic и проверить, какие изменения вошли в релиз. Автор признаёт, что одной подписки ему уже мало — нужны подключения к сервисам и доступ к объяснениям, почему в проекте всё сделано именно так, поскольку пересказывать агенту каждый разговор с коллегой утомительно. Он также шутит, что растёт поколение разработчиков, которое может не знать, что такое git-клиент: для коммита или просмотра изменений им достаточно агента.

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

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

Если сравнивать с альтернативами, то выбор сводится не к «ИИ или без ИИ», а к степени интеграции. Локальные ассистенты без доступа к инфраструктуре дают предсказуемость и контроль, но требуют ручного копирования контекста; агенты с MCP и подключением к рабочим сервисам экономят время, однако расширяют поверхность доступа и повышают требования к проверке результатов. Корпоративные платформы с утверждённым списком инструментов снижают риски, но могут ограничивать выбор. Никита не делает окончательного вывода, а фиксирует личную позицию: он хочет пользоваться агентами и готов обсуждать компромиссы, включая выбор BTreeMap ради удобства отладки, но рассчитывает, что работодатель заранее расскажет, что именно доступно в команде.

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