Тезис о том, что разработчик будущего не пишет код, а управляет агентами, звучит красиво, но остаётся абстрактным. Андрей Карпати в январе 2026 года ввёл термин agentic engineering и описал новую роль инженера как надзор и оркестрацию. Борис Черни, руководитель Claude Code в Anthropic, добавил конкретики: с ноября он не правил ни одной строки руками и закрывает по двадцать с лишним пуллреквестов в день. Оба, однако, обходят стороной главный вопрос: чем именно занят человек в оставшиеся 99% времени и что происходит, когда процесс не выстроен.

За красивыми формулировками скрывается неудобная часть, которую в материалах про ИИ-разработку обычно не упоминают. В январе 2026 года на Hacker News появился тред «Ask HN: Identity crisis as a software engineer because of AI» — за сутки он собрал около тысячи комментариев. Разработчики с десятилетним стажем описывали ощущение профессиональной пустоты: код пишется, продукт работает, но из процесса исчез момент, в котором ты был нужен. Самооценка инженера годами держалась на одной способности — открыть любой файл, разобрать любую строку, написать с нуля всё необходимое. Когда из формулы «я пишу код» уходит глагол, остаётся неуютный зазор.

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

Тред на Hacker News об «идентификационном кризисе» разработчиков собрал около тысячи комментариев за сутки.

Барочная сводчатая зала ночью; архитектор в тёмной мантии стоит у массивного чертёжного стола, на котором раскрыт план с абстрактными геометрическими формами; рядом с планом открытый ноутбук, единственный источник холодного сине-белого свет
Барочная сводчатая зала ночью; архитектор в тёмной мантии стоит у массивного чертёжного стола, на котором раскрыт план с абстрактными геометрическими формами; рядом с планом открытый ноутбук, единственный источник холодного сине-белого свет · Источник: Habr AI

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

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

Это и есть содержание тех самых 99% времени. Не абстрактная «оркестрация», а конкретная работа: диагностика до постановки задачи, декомпозиция на подзадачи с чёткими критериями приёмки, проверка результата, управление выкладкой, фиксация системных проблем в памяти проекта. Такой подход принципиально отличается от простого делегирования: агент без качественного контекста и правильно сформулированной задачи уверенно решает не ту проблему. Человек в этой схеме — не надзиратель, а тот, кто понимает, что именно нужно починить и почему.