Джереми Шефф сформулировал это точнее всех: программирование было работой, где тебе платили за решение хитрых логических головоломок. Чем хитрее — тем больше платили. LLM-агенты не убили профессию, но вытащили из неё именно ту часть, ради которой многие в неё и пришли. Это не повод паниковать — но повод честно разобраться, что происходит.
Почему это больнее, чем кажется
Саймон Уиллисон в октябре 2026 года процитировал Шеффа не случайно. Речь не о том, что разработчики потеряют работу завтра. Речь о том, что изменилась природа удовольствия от работы.
Раньше схема была простой: бизнес приносил проблему, разработчик сам определял стратегию, сам выстраивал архитектуру, сам решал, что возможно, а что нет. Это была интеллектуальная автономия — и именно за неё многие терпели легаси-код, митинги и неудобные дедлайны.
Сейчас агент пишет решение за минуты. Разработчик всё чаще становится тем, кто формулирует задачу, проверяет результат и нажимает «принять». Если тебя кормила именно головоломка — это потеря, и она реальная.
Кому LLM-агенты в плюс, а кому в минус
Уиллисон разделяет разработчиков на два типа — и это деление честное.
| Тип разработчика | Что изменилось | Итог |
|---|---|---|
| Кайфует от построения рабочих систем, задача — инструмент | LLM ускоряет доставку, снимает рутину | Выигрывает |
| Кайфует от самого процесса решения задачи | LLM забирает именно этот процесс | Теряет |
Первый тип получает суперсилу: можно строить больше, быстрее, с меньшим трением. Второй тип получает инструмент, который делает за него то единственное, ради чего он вообще садился за компьютер.
Важно понимать: это не вопрос квалификации. Сильный инженер может оказаться во втором лагере — просто потому что его мотивация была устроена иначе.
Что конкретно забирают агенты — и что остаётся
Агенты хорошо справляются с предсказуемыми задачами: написать CRUD, сгенерировать тесты, переписать функцию на другой язык, разобрать стектрейс. Это именно те «хитрые маленькие головоломки», о которых писал Шефф, — только теперь они решаются без тебя.
Что агенты делают плохо или не делают вообще:
- Понять, какую задачу вообще стоит решать. Это по-прежнему требует человека с контекстом.
- Оценить, насколько решение соответствует реальным ограничениям системы — производительность, безопасность, поддерживаемость.
- Принять решение в условиях неопределённости, когда требования противоречат друг другу.
- Объяснить заказчику, почему «просто добавить кнопку» займёт три недели.
Это не утешительный приз. Это другая работа — и она требует других навыков.
Как перестроиться: три направления
1. Сместить фокус на постановку задачи
Если агент пишет код, то ценность разработчика смещается к точности формулировки. Умение декомпозировать сложную бизнес-задачу в набор чётких подзадач для агента — это навык, который сейчас недооценён и будет дорожать.
Попробуй относиться к промпту для агента так же серьёзно, как раньше к архитектурному решению: что именно ты хочешь получить, какие ограничения, какой контекст агент не знает по умолчанию.
2. Стать тем, кто проверяет, а не тем, кто пишет
Код-ревью меняет смысл. Раньше ты проверял стиль и логику коллеги. Теперь ты проверяешь, не галлюцинирует ли агент, не упустил ли он граничный случай, не сломал ли что-то в соседнем модуле. Это требует глубокого понимания системы — и именно здесь опыт не обесценивается.
3. Найти задачи, где головоломка остаётся
Не все задачи одинаково хорошо решаются агентами. Распределённые системы с нетривиальными гарантиями консистентности, оптимизация под конкретное железо, реверс-инжиниринг чужого легаси без документации — здесь агент пока скорее помощник, чем замена. Если тебе важен сам процесс решения, ищи именно такие задачи.
Где это ломается
Ещё одна ловушка — иллюзия контроля. Агент выдаёт уверенный, читаемый код, который может содержать тонкую ошибку в бизнес-логике. Если ты перестал вникать в детали, потому что «агент справляется» — ты перестал понимать систему, которую обслуживаешь.
Наконец, карьерный трек. Если твой рост раньше строился на накоплении экспертизы в решении сложных задач — этот трек сужается. Не исчезает, но сужается. Стоит заранее думать о том, какую экспертизу ты строишь сейчас.
Что попробовать дальше
- Поэкспериментируй с ролью «агент-оркестратор»: не пиши код сам, но управляй несколькими агентами на одной задаче и смотри, где они расходятся.
- Прочитай оригинальный пост Джереми Шеффа — он короткий и честный.
- Поговори с командой о том, как изменился процесс код-ревью: скорее всего, у коллег те же вопросы, просто никто не поднимал тему вслух.
FAQ
Агенты заменят программистов полностью?
Уиллисон и Шефф не утверждают этого. Речь о том, что меняется характер работы: рутинные задачи уходят к агентам, остаются задачи на понимание контекста, постановку проблемы и проверку результата. Профессия трансформируется, а не исчезает.
Что делать, если мне нравился именно процесс написания кода?
Это честная потеря, и её стоит признать. Варианты: искать задачи, где агенты пока слабы (сложные системные задачи, нестандартная оптимизация), переключиться на смежные роли с высокой долей проектирования, или принять, что хобби-программирование теперь отдельно от работы.
Как понять, к какому типу разработчиков я отношусь?
Простой вопрос: если бы агент решал все задачи идеально, а тебе оставалось только проверять результат — тебе было бы комфортно? Если да — ты в первом лагере. Если ощущение пустоты — во втором.
Какие навыки сейчас стоит развивать?
Декомпозиция задач и точная постановка требований, понимание архитектуры на уровне системы, умение проверять и критиковать сгенерированный код, коммуникация с бизнесом без технического жаргона.
Это уже происходит или пока теория?
По состоянию на октябрь 2026 года — уже происходит. Уиллисон пишет об этом как о текущей реальности, а не о прогнозе. Coding-агенты активно используются в командах, и вопрос не «когда», а «как адаптироваться».
