Rust-разработчик Никита (NikTimf) в колонке на Хабре «Я боюсь работать без ИИ» описывает, как наличие ИИ-агента стало для него самостоятельным условием при выборе работы. Он спрашивает на собеседованиях, какого помощника дадут, что разрешено, что оплачивает компания и какие доступы будут у команды. Стек и задачи остаются важными, но ответ про агента теперь влияет на решение не меньше. Помощника он называет «болванчиком» и говорит, что спрашивает о нём при найме.
Это продолжение серии его текстов: сначала «Я не боюсь, что меня заменит ИИ. Я боюсь работать с ИИ», затем «Я всё ещё боюсь работать с ИИ». Новый материал называется «Я боюсь работать без ИИ». Позиция автора изменилась не потому, что прошлые опасения исчезли. Он прямо пишет, что они остались, но после привыкания к агентам отказаться от них уже трудно.
Оговорка: это личный опыт одного Rust-разработчика, а не исследование рынка труда. В колонке нет количественных данных о том, как часто разработчики выбирают работу по такому критерию. Зато есть набор проверок, который можно примерить к собственной ситуации.
Почему ИИ-агенты стали критерием выбора работы
Для Никиты критерий складывается из ежедневной практики. Агент нужен не для демонстрации прогрессивности, а чтобы быстрее проходить рутину, проверять гипотезы и не тратить часы на механические фрагменты кода. Чем чаще разработчик пользуется помощником, тем дороже оказывается переход в команду, где привычный способ работы исчезает.
Этот эффект связан с общей проблемой: ускорение генерации кода не отменяет ревью, передачу контекста и проверку результата. В разборе о нагрузке на разработчика показано, почему агенты могут добавлять работу, даже когда пишут код быстрее человека. Никита проверяет не обещание скорости, а условия, в которых эту скорость можно использовать.
Что изменилось после привыкания к агентам
В первых статьях автор писал о страхе: агент может подменить навык, выдать неверный код, сделать разработчика зависимым от инструмента. В новой колонке страх остался, но практика оказалась сильнее. Никита формулирует это коротко: после привыкания к агентам отказаться от них очень трудно.
Причина не в восторге от технологии. Агент забирает часть работы, которую разработчик и так не любит: поиск по репозиторию, черновые варианты, объяснение незнакомого API. Ответы приходится проверять, и это стоит времени. Но без помощника часть задач просто не начинается.
Одной подписки автору уже мало. Ему нужны подключения к рабочим сервисам и доступ к объяснениям, почему в проекте всё сделано именно так. Запрос к работодателю расширяется: важен не факт наличия чат-бота, а среда, в которой агент видит код, задачи и контекст решений.
Три типа вакансий: как читать описание ИИ в объявлении
Никита сам называет деление условным. Он выделяет три варианта по тому, как в вакансии рассказывают про ИИ. Для читателя это удобная рамка: она помогает быстро понять, что проверять на собеседовании.
| Тип вакансии | Что видно в тексте | Что проверить |
|---|---|---|
| «AI-native» без конкретики | ИИ в обязанностях, требованиях и культуре, продукт и задачи размыты | Что делает компания, какие задачи у команды, какие инструменты и оплата |
| «ИИ по делу» | Понятны продукт, задачи, роль агентов, инструменты и оплата | Совпадает ли текст с реальной практикой команды |
| Без упоминания ИИ | Стек, инфраструктура, коллектив, про инструменты молчание | Разрешены ли агенты, есть ли доступ к репозиторию, кто платит |
«AI-native» без конкретики: красные флаги
Первый тип Никита описывает так: ИИ есть в обязанностях, требованиях и рассказе о культуре, а что за продукт и какие задачи, не важно. Цитата «Мы супер-пупер AI-native компания» показывает главный признак: ярлык сильнее содержания.
Красные флаги выглядят предсказуемо. В тексте много слов про инновации, но нет описания продукта. Не названы инструменты и порядок оплаты. Требования к ИИ-навыкам есть, а к домену и задачам почти нет. Рассказ о культуре занимает больше места, чем описание работы.
Ирония автора про «первую AI-native шаурмечную», где ИИ сгенерированы только картинки в меню, точно показывает границу. Ярлык может означать что угодно. Проверять надо продукт, команду, доступы и оплату. Что стоит за модным термином в организации, разбирает отдельный материал об AI-native компаниях.
«ИИ по делу»: какие формулировки искать
Второй тип автору хочется читать. В тексте понятно, что за продукт, какие задачи и зачем тут агенты. Написано, чем можно пользоваться и что оплачивает компания. Это не гарантия честности, но хороший сигнал: работодатель думал о рабочем процессе, а не только о заголовке вакансии.
Маркеры такого объявления:
- назван продукт и пользователь, а не только отрасль;
- описаны задачи, где агент помогает, и границы его применения;
- указаны инструменты, подписка и порядок доступа;
- есть информация о ревью, тестах и ответственности за изменения;
- условия по ИИ выглядят частью работы, а не бонусом за лояльность.
Если в объявлении есть конкретика, на собеседовании проще задавать уточняющие вопросы. Сравнивать офферы можно по фактам, а не по обещаниям.
Вакансии без упоминания ИИ: что выяснять при общении
Третий тип выглядит обычно: Rust, PostgreSQL, микросервисы, дружный душный коллектив. Про ИИ ни слова. Это не значит, что агентов запрещают. Реальные условия выясняются при общении. Молчание в объявлении может скрывать и строгую политику, и нормальную практику, о которой просто не написали.
Отсутствие упоминания не стоит считать отказом. Стоит задать те же вопросы, что и к AI-native вакансии, и посмотреть на ответы. Если компания не использует агентов, это тоже ответ: дальше важно понять, насколько такая среда подходит вашим задачам.
Что на самом деле значит «у нас можно пользоваться ИИ»
Фраза «у нас можно пользоваться ИИ» описывает слишком широкий диапазон условий. В одной команде это личная подписка на чат-бота, в другой корпоративный тариф с утверждённым списком инструментов и доступом к репозиторию. Для ежедневной работы важны детали, а не сам факт разрешения.
Никита проверяет не лозунг, а среду: чья подписка, что оплачивают, какие сервисы доступны, можно ли подключить агента к рабочему контексту. В колонке он отмечает, что ему нужны подключения к рабочим сервисам и доступ к объяснениям, почему в проекте всё сделано именно так.
Чья подписка и что оплачивает компания
Личная подписка перекладывает расходы и риски на разработчика. Корпоративная снимает вопрос оплаты, но добавляет правила: какие модели разрешены, можно ли отправлять код во внешний сервис, кто следит за лимитами. Компенсация расходов выглядит компромиссом, однако требует ручной отчётности и не решает вопрос доступа к внутренним сервисам.
Конкретные тарифы и лимиты зависят от провайдера и договора компании. В статье-источнике цен нет, поэтому проверять надо не прайс из объявления, а порядок оплаты и ответственного за инструменты. Полезно уточнить, что происходит при исчерпании лимита: разработчик ждёт следующего месяца, просит бюджет или переходит на другой инструмент.
Доступ ИИ-агента к репозиторию и рабочим сервисам
Агент, который видит только вставленный в чат фрагмент, работает как автодополнение с памятью на один экран. Агент с доступом к репозиторию может найти связанные модули, проверить использование функции и предложить изменение в контексте проекта. Разница в качестве ответов огромная.
У доступа есть цена: риск утечки кода, лишние права, случайные изменения. Практичный минимум, который стоит обсудить: доступ только на чтение, отдельная ветка, обязательное ревью, запрет на секреты и продовые сервисы без подтверждения. Это не универсальная политика, а рамка для разговора с работодателем.
Политика безопасности важна не меньше удобства. Если компания разрешает агенту читать репозиторий, но не описывает, какие данные можно отправлять в модель, разработчик остаётся один на один с риском. Ответ на такой вопрос показывает зрелость процесса лучше любого лозунга про AI-native.
Утверждённый список инструментов и пересказ контекста
Утверждённый список инструментов задаёт ежедневную механику. Если компания разрешает один чат-бот, а команда работает в другом, разработчик тратит время на обходные пути. Если список слишком широкий, растёт риск неконтролируемой отправки данных.
Никита отдельно отмечает бытовую проблему: пересказывать агенту каждый разговор с коллегой надоедает. Агенту нужен рабочий контекст, иначе человек становится переводчиком между командой и моделью. Чем больше контекста приходится копировать вручную, тем меньше выигрыш от помощника.
Практический вопрос к работодателю звучит так: какие источники знаний доступны агенту и нужно ли каждый раз собирать контекст вручную. Ответ помогает понять, получится ли встроить помощника в ежедневный цикл или он останется отдельной вкладкой.
Какие вопросы про ИИ задавать на собеседовании
Список ниже собран вокруг опыта автора и практических рисков. Он не заменяет разговор о задачах, но помогает не выяснять условия уже после выхода на работу.
Вопросы про инструменты и оплату
- Какого ИИ-помощника дадут в команде и для каких задач?
- Это корпоративная подписка, личная с компенсацией или собственный выбор разработчика?
- Есть ли утверждённый список инструментов? Кто его обновляет?
- Что компания оплачивает: подписку, API-лимиты, локальные модели, рабочее железо?
- Можно ли использовать агента в личных проектах и есть ли ограничения по коду?
Вопросы про доступы и безопасность
- Сможет ли агент читать репозиторий или только вставленный код?
- Какие рабочие сервисы доступны агенту: трекер, документация, CI, логи?
- Есть ли политика по секретам, персональным данным и коду клиентов?
- Кто отвечает за инцидент, если агент предложит небезопасное изменение?
- Нужно ли ревью для всех изменений от агента?
Вопросы про практику команды
- Кто в команде реально пользуется агентом каждый день, а кто нет?
- Как агент встроен в процесс: генерация, ревью, тесты, документация?
- Какие ограничения соблюдаются на практике, а какие остались на бумаге?
- Можно ли получить доступ к истории решений и объяснениям, почему код устроен именно так?
- Что происходит, когда агент ошибается: кто разбирает и как фиксируют выводы?
Ответы стоит записать и сверить с тем, что покажут на технической секции. Если на словах агент разрешён, а на встрече никто не может назвать инструмент и порядок доступа, это сигнал о разрыве между презентацией и практикой.
Практика: чему агент помогает и чего не заменяет
Самый полезный аргумент в тексте Никиты - не список функций, а пример проекта. Он показывает, где агент меняет решение начать работу, а где ответственность остаётся у человека.
Кейс field-kinds: что сделал агент и что осталось человеку
Автор описывает, что часть проектов без ИИ он бы вообще не начал. Крейт field-kinds с derive-макросом появился благодаря агенту. При этом помощник не избавил от долгой проверки и тестирования. Без агента, по словам Никиты, он потратил бы ноль часов и ничего не сделал бы.
Это честная картина распределения ролей. Агент снижает порог старта: помогает набросать структуру, разобраться с синтаксисом макроса, пройти первые ошибки. Ответственность за качество остаётся у разработчика. Проверка, тесты и понимание поведения крейта требуют времени, и агент их не отменяет.
Для читателя вывод практический: агент полезен там, где проект иначе не начался бы. Ждать, что он автоматически сделает проект качественным, не стоит.
Где агент ускоряет, а где мешает
В знакомой области опыт помогает спорить с агентом. Разработчик видит, когда ответ противоречит устройству проекта, и может выбрать другой вариант. В новой области такой опоры нет: советы приходится проверять по документации, эксперименту и коду. Никита прямо пишет, что в новой области ему ещё предстоит разобраться, насколько хороши советы помощника.
Отсюда граница. Агент ускоряет черновую работу и исследование, если человек может оценить результат. Он мешает, когда ответ принимают без проверки или когда контекст проекта слишком велик для одного запроса. В обоих случаях проблема не в модели, а в процессе: кто формулирует задачу, кто проверяет и кто отвечает за итог.
Как ИИ-агенты меняют найм и требования к опыту
Классическое собеседование проверяет, как человек пишет код. Когда тот же код за минуту выдаёт агент, секция меньше говорит о ежедневной работе. Это не значит, что алгоритмы больше не нужны. Меняется то, что именно стоит проверять.
Почему алгоритмические секции теряют смысл
Никита пишет, что на собеседовании хочет показать работу с привычными инструментами и обсудить, почему выбрал конкретное решение. Пример - компромисс BTreeMap ради удобства отладки. BTreeMap хранит ключи упорядоченно, порядок обхода предсказуем, поэтому отладка становится проще. Такой разговор показывает инженерное мышление: какие ограничения учли, что потеряли, почему вариант подходит задаче.
Алгоритмическая секция с написанием кода с нуля проверяет память и скорость. В работе с агентом важнее постановка задачи, проверка результата, выбор между вариантами и умение объяснить компромисс. Если компания хочет оценить именно это, формат интервью придётся менять. Категоричных выводов для всех компаний здесь нет: многое зависит от роли и уровня.
Как новичку набирать опыт с агентом под рукой
Автор ставит вопрос, как приобретать опыт, когда готовый ответ выдаёт агент. Вопрос касается новичков и тех, кто давно пишет код. Практические ориентиры можно вывести из его же логики: проверять советы агента, разбирать компромиссы, самостоятельно писать тесты и объяснять каждое изменение до того, как его примет ревью.
Ещё один ориентир - спор с агентом. Опыт помогает замечать неверные допущения и задавать уточняющие вопросы. Новичку этот навык только предстоит получить, поэтому полезно просить агента объяснять выбор, а затем проверять объяснение по документации и экспериментам.
В сообществе есть и другая реакция: часть разработчиков не хочет отдавать код агенту, потому что видит в программировании ремесло. Разбор позиций помогает понять, где делегирование ускоряет работу, а где разрушает мотивацию. При выборе команды этот фактор стоит учитывать так же, как доступ к инструментам.
Как использовать этот критерий при выборе работы
Наличие агента не гарантирует хорошую работу, а его отсутствие не всегда красный флаг. Критерий полезен, когда превращается в набор проверяемых условий.
- Прочитайте описание вакансии и отнесите её к одному из трёх типов. Если про ИИ много слов и нет продукта, задавайте больше уточняющих вопросов.
- На собеседовании выясните инструмент, оплату, доступы и ограничения. Ответы запишите, чтобы сравнить офферы.
- Попросите показать реальную практику: кто пользуется агентом, как проходит ревью, что считается допустимым доступом.
- Сопоставьте условия с задачами. Если работа состоит из задач, где агент почти не нужен, низкий уровень доступа может быть не минусом. Если вы каждый день работаете с большим кодом, отсутствие интеграции станет ежедневным трением.
- Учтите личную границу. Кому-то важна корпоративная подписка, кому-то возможность использовать свои инструменты и получать компенсацию.
Для Никиты ответ оказался достаточно важным, чтобы спрашивать о нём при найме. Его опыт не описывает рынок целиком, зато даёт готовую рамку разговора. Работодателю можно задать те же вопросы, что он задаёт себе: какой помощник, что оплачивают, к чему есть доступ и кто отвечает за результат.
Следующий шаг простой: перед откликом на вакансию выпишите три условия, без которых работа с агентом не складывается. Например, корпоративная подписка, доступ к репозиторию и понятное ревью. На собеседовании проверьте каждое. Если хотя бы одно условие не подтверждается, решение принимайте по полной картине задач, команды и ограничений, а не по слову AI-native в заголовке.