Шубханкар (Shubs), инженерный менеджер компании Assetnote, опубликовал эссе и реальный диалог со своим подчинённым о том, как в эпоху AI теряется удовольствие от инженерной работы. В диалоге инженер описывает, что больше не понимает каждый коммит целиком и не чувствует авторства результата, а менеджер формулирует диагноз: место проектирования и отладки всё чаще занимают ревью и планирование. Взамен автор даёт приёмы, применимые сразу, — от файлов CLAUDE.md и AGENTS.md вместо ненадёжных встроенных «воспоминаний» до сознательного выбора сложных, а не рутинных задач для AI.

Что произошло

Шубханкар (Shubs), руководящий в компании Assetnote разработкой в области аудита безопасности кода, опубликовал на shubs.io эссе под заголовком «Do we still enjoy software engineering in the age of AI?» вместе с реальным диалогом со своим подчинённым. Инженер в этом диалоге перечисляет конкретные потери: раньше он полностью понимал каждый отправляемый коммит, держал в голове архитектуру кодовой базы и чувствовал авторство результата; теперь AI-инструменты «съедают» критическое мышление, их встроенные «воспоминания» (memories) не запоминают сделанные исправления, а модели и тулинг меняются примерно каждые шесть месяцев, что обесценивает глубокую настройку под конкретный стек. Диагноз, который автор формулирует по итогам разговора: AI превращает инженеров в «средних менеджеров» (middle managers), у которых ревью и планирование заменяют проектирование и отладку.

Контекст

Ценность текста в его статусе первичного документа: это не пересказ чужого опроса, а настоящий обмен сообщениями между менеджером и инженером действующей команды, где проговаривается то, что обычно остаётся за кадром презентаций о росте продуктивности. Сам автор нарабатывал навык аудита исходного кода более пятнадцати лет, и именно на этом фоне он отмечает быстрый успех AI в source code auditing — области, в которую он вкладывал полжизни. Жалоба на то, что встроенные memories агентов не запоминают исправления, согласуется с известными ограничениями агентской памяти: правки, сделанные инженером по ходу работы, не закрепляются между сессиями, и он вынужден повторять одни и те же указания заново.

Почему это важно для индустрии

Для отрасли это не очередная статья о скорости разработки, а карта боли реального пользователя агентов: провалы памяти между сессиями, потеря контекста между промптами и смещение работы инженера в ревью и координацию. Механизм, зафиксированный в диалоге, прост: когда время на написание кода сокращается, доля координации и ревью растёт, критическое мышление замещается управленческим — именно этот сдвиг автор описывает как путь к выгоранию, которого многие инженеры не хотят. Каждый пункт боли — готовый продуктовый крючок: контекст-слой для агентов, память, обучающаяся на исправлениях, review-first UX в агентских платформах. Для работодателей текст — сигнал пересматривать роль инженера и структуру команд, а не только внедрять инструменты; заявленный полугодовой цикл смены моделей и тулинга дополнительно означает, что вложения в глубокую настройку под конкретный стек быстро обесцениваются.

Почему это важно для пользователей

Практическая часть применима немедленно и без покупки каких-либо продуктов. Вместо ненадёжных встроенных AI-memories автор советует вести инструкции и контекст в обычных файлах CLAUDE.md и AGENTS.md в репозитории: они принудительно попадают в каждый следующий промпт агента, поэтому нужные указания не теряются между сессиями. Второй приём — сознательно скармливать AI задачи повышенной сложности, а не рутину. Третий — не списывать со счетов своё до-AI глубокое понимание систем: автор называет его «artisanal programming» и считает суперсилой, которую другие долго не смогут догнать. Дополнительно имеет смысл ввести обязательное ревью AI-коммитов и замерить фактическую долю времени, уходящую на код, а не на координацию.

Что пока неизвестно / ограничения

Источник — личное эссе и один диалог, то есть опыт одного человека: в тексте нет методологии, количественных метрик и воспроизводимых eval'ов, поэтому тезис о превращении инженеров в «средних менеджеров» корректно читать как качественную гипотезу, а не измерение. Сильные заявления о возможностях моделей — быстрый успех в source code auditing, упоминания задач уровня нерешённых математических гипотез и поиска zero-day уязвимостей — остаются без воспроизводимых проверок и неотличимы от анекдота. Наблюдение о полугодовом цикле смены моделей и тулинга согласуется с реальной скоростью релизов, но систематических данных в тексте также нет.

Источники

Автор

Look at AI, редакция