AI агенты не заменяют разработчика — они повышают цену правильного разработчика
Когда мне говорят «вы скоро потеряете работу», я вспоминаю один конкретный баг.
Claude написал функцию пагинации. Уверенно, быстро, без единого предупреждения. Функция прошла ревью — потому что выглядела разумно. Семь дней она работала в проде. Потом мы нашли edge case: при точном кратном значении курсор сдвигался на одну позицию, и каталог начинал пропускать товары. Тихо. Без ошибок в логах.
Не Claude виноват. Никто не объяснил ему, что это за система. Вот в чём проблема.
Что происходит: компании режут команды и не получают ROI
Начало 2026 года. Тренд понятен: компании нанимают AI-инструменты и сокращают команды разработки. Особенно — junior и middle-уровень. Логика выглядит простой: Claude пишет код, зачем платить $3000/мес программисту?
На Habr и HN это обсуждается как факт свершившийся. Но уже появляются обратные истории: студии, которые срезали команду до минимума, через полгода возвращаются с задачами типа «у нас в проде баги, которые никто не понимает» и «новый подрядчик не может разобраться в кодовой базе».
ROI не сошёлся не потому что AI плохой инструмент. А потому что AI умножает то, что уже есть в команде. Если убрать людей с системным мышлением — умножается хаос.
Что изменилось в моей работе
Я веду несколько активных проектов. С середины 2025 года примерно 65% кода пишу с помощью Claude Code. Звучит как много. На практике это значит: я пишу спецификацию, Claude пишет реализацию, я проверяю контракт.
Задачи, которые отдаю без вопросов:
- покрытие тестами для существующей логики
- рефакторинг с явным контрактом на входе и выходе
- шаблонный код: CRUD-контроллеры, миграции по шаблону, конфиги
Задачи, которые не отдаю никогда:
- архитектура новой подсистемы
- решения про кэш-стратегию в Bitrix под нагрузкой
- всё, что касается 1С-синхронизации (слишком много неявных инвариантов)
Принцип я описывал отдельно: Claude пишет тесты, архитектуру — нет.
Это не осторожность. Это вывод из опыта: Claude не знает, что не знает. Он не спросит «а у вас точно один инстанс приложения или несколько?» Он предположит.
Баг в проде: семь дней
Тот случай с пагинацией — не единственный. За шесть месяцев активного использования Claude Code я насчитал три производственных инцидента, связанных с AI-сгенерированным кодом.
Все три объединяет одно: код выглядел правильно. Он прошёл code review. Он соответствовал условию задачи — именно так, как она была сформулирована. Но в каждом случае была системная деталь, которую я не описал в задаче, потому что считал очевидной.
AI не знает про ваши очевидные детали. Задача senior-инженера — знать, что надо описать.
Это навык. И он, судя по всему, становится редким. Я писал об этом подробнее в разборе конкретного инцидента.
AI умножает мышление — поэтому мышление в дефиците
Я наблюдаю одну закономерность: чем лучше инструменты, тем дороже ошибка размытой задачи.
Раньше junior мог реализовать нечёткое ТЗ за неделю итераций. Теперь то же нечёткое ТЗ реализует Claude за час — но неправильно. Потом кто-то тратит три дня, чтобы понять почему.
Что изменилось в требованиях к инженеру: нужно уметь формализовать контекст. Не «добавь поиск», а «добавь нечёткий поиск по полю NAME с fuzziness AUTO и prefix_length 2, кириллица через анализатор russian». Это навык, который раньше считался приятным бонусом. Теперь без него Claude производит правдоподобный мусор.
Ещё важнее — знать инварианты системы. Что нельзя менять, даже если это нигде не написано. Claude не спросит. Он предположит.
Это не «10x-программист» в смысле скорости набора. Это инженер, который знает систему достаточно, чтобы задать правильный вопрос. И который понимает, что AI умножает привычки, а не только скорость.
Парадокс рынка: junior дешевле, senior — редкий
Парадокс 2026 года: junior-разработчик в самом деле стал дешевле в производительности на задачу. Потому что Claude берёт на себя значительную часть механической работы.
Но senior-инженер с архитектурным мышлением не стал дешевле. Он стал редким.
Причина проста: людей с этим мышлением не было много и раньше. Теперь компании начали это замечать — потому что без них AI-инструменты производят дорогой технический долг с высокой скоростью.
Я видел это на нескольких проектах, которые ко мне приходили после «оптимизации команды». Кодовая база растёт. Тесты есть. Документация сгенерирована. Но никто не понимает, почему при определённой нагрузке падает кэш. И никто не может объяснить, почему 1С-синхронизация ломается раз в неделю в определённый день.
AI написал всё это. Но ни одной из этих проблем он не предусмотрел.
Кого ищу при найме — и почему это изменилось
Раньше при найме я смотрел на скорость. Может ли человек за разумное время написать рабочую функцию?
Теперь первый вопрос другой: может ли человек объяснить, почему он принял конкретное архитектурное решение? Не «потому что так написано в документации», а «потому что в нашей системе вот такой инвариант, и он диктует этот выбор».
Если человек не может ответить на этот вопрос про чужой код — он не сможет ставить задачи AI. Он будет получать правдоподобный, но неправильный код.
Собеседование я теперь начинаю не с технического задания. Три вопроса, которые стали постоянными:
Первое. «Расскажи про момент, когда код был написан правильно по условию задачи, но неправильно для системы.» Если человек не может привести такой пример из своей практики — он либо не работал с реальными системами, либо не рефлексирует.
Второе. «Как ты передаёшь неявные ограничения системы новому участнику команды?» Ответ «есть документация» не считается.
Третье. «Что ты не делегируешь AI и почему?» Если ответ «я всё делегирую» или «я ничего не делегирую» — оба тревожный сигнал.
Что это значит для нанимателя
Если вы сейчас строите команду разработки и думаете «у нас есть Claude, зачем нам senior» — это честный вопрос.
Claude хорошо пишет код, который вы умеете описать. Он плохо работает с тем, что вы считаете очевидным и не описываете. Чем сложнее система — тем больше таких «очевидностей».
Senior-инженер нужен не для того, чтобы писать код вместо Claude. Он нужен для того, чтобы знать, что именно сказать Claude — и поймать момент, когда тот что-то предположил молча.
Я уже вижу проекты, где этот вопрос решили неправильно. Результаты сейчас как раз начинают проявляться.