# LLM пишет код вместо тебя. Что осталось разработчику — и что с этим делать
Каноническая страница: https://plainews.ru/posts/programmirovaniye-llm-agenty-chto-delat-razrabotchiku
Опубликовано: 2026-10-20T07:01:46.195Z

LLM-агенты забирают главное удовольствие от кода — решение задач. Разбираемся, кому это выгодно, кому больно и как перестроиться прямо сейчас.
Джереми Шефф сформулировал это точнее всех: программирование было работой, где тебе платили за решение хитрых логических головоломок. Чем хитрее — тем больше платили. LLM-агенты не убили профессию, но вытащили из неё именно ту часть, ради которой многие в неё и пришли. Это не повод паниковать — но повод честно разобраться, что происходит.

## Почему это больнее, чем кажется

Саймон Уиллисон в октябре 2026 года процитировал Шеффа не случайно. Речь не о том, что разработчики потеряют работу завтра. Речь о том, что изменилась природа удовольствия от работы.

Раньше схема была простой: бизнес приносил проблему, разработчик сам определял стратегию, сам выстраивал архитектуру, сам решал, что возможно, а что нет. Это была интеллектуальная автономия — и именно за неё многие терпели легаси-код, митинги и неудобные дедлайны.

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

## Кому LLM-агенты в плюс, а кому в минус

Уиллисон разделяет разработчиков на два типа — и это деление честное.

| Тип разработчика | Что изменилось | Итог |
| --- | --- | --- |
| Кайфует от построения рабочих систем, задача — инструмент | LLM ускоряет доставку, снимает рутину | Выигрывает |
| Кайфует от самого процесса решения задачи | LLM забирает именно этот процесс | Теряет |

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

Важно понимать: это не вопрос квалификации. Сильный инженер может оказаться во втором лагере — просто потому что его мотивация была устроена иначе.

## Что конкретно забирают агенты — и что остаётся

Агенты хорошо справляются с предсказуемыми задачами: написать CRUD, сгенерировать тесты, переписать функцию на другой язык, разобрать стектрейс. Это именно те «хитрые маленькие головоломки», о которых писал Шефф, — только теперь они решаются без тебя.

Что агенты делают плохо или не делают вообще:

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

Это не утешительный приз. Это другая работа — и она требует других навыков.

## Как перестроиться: три направления

**1. Сместить фокус на постановку задачи**

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

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

**2. Стать тем, кто проверяет, а не тем, кто пишет**

Код-ревью меняет смысл. Раньше ты проверял стиль и логику коллеги. Теперь ты проверяешь, не галлюцинирует ли агент, не упустил ли он граничный случай, не сломал ли что-то в соседнем модуле. Это требует глубокого понимания системы — и именно здесь опыт не обесценивается.

**3. Найти задачи, где головоломка остаётся**

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

## Где это ломается

> **Важно.** Перестройка болезненна, если ты не осознаёшь, что именно потерял. Многие разработчики пытаются «использовать агентов эффективнее», не признавая, что проблема не в эффективности — а в том, что работа перестала приносить удовольствие.

Ещё одна ловушка — иллюзия контроля. Агент выдаёт уверенный, читаемый код, который может содержать тонкую ошибку в бизнес-логике. Если ты перестал вникать в детали, потому что «агент справляется» — ты перестал понимать систему, которую обслуживаешь.

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

## Что попробовать дальше

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

---

## FAQ

### Агенты заменят программистов полностью?

Уиллисон и Шефф не утверждают этого. Речь о том, что меняется характер работы: рутинные задачи уходят к агентам, остаются задачи на понимание контекста, постановку проблемы и проверку результата. Профессия трансформируется, а не исчезает.

### Что делать, если мне нравился именно процесс написания кода?

Это честная потеря, и её стоит признать. Варианты: искать задачи, где агенты пока слабы (сложные системные задачи, нестандартная оптимизация), переключиться на смежные роли с высокой долей проектирования, или принять, что хобби-программирование теперь отдельно от работы.

### Как понять, к какому типу разработчиков я отношусь?

Простой вопрос: если бы агент решал все задачи идеально, а тебе оставалось только проверять результат — тебе было бы комфортно? Если да — ты в первом лагере. Если ощущение пустоты — во втором.

### Какие навыки сейчас стоит развивать?

Декомпозиция задач и точная постановка требований, понимание архитектуры на уровне системы, умение проверять и критиковать сгенерированный код, коммуникация с бизнесом без технического жаргона.

### Это уже происходит или пока теория?

По состоянию на октябрь 2026 года — уже происходит. Уиллисон пишет об этом как о текущей реальности, а не о прогнозе. Coding-агенты активно используются в командах, и вопрос не «когда», а «как адаптироваться».

## Источники

- Simon Willison: My obituary for programming