«100500 простых задач» — в такую формулу автор публикации называет нормальную школу для начинающего инженера. Проблема в том, что ИИ в разработке уже научился быстро закрывать именно этот слой работы: мелкие багфиксы, служебные модули, шаблонный код, черновики документации. Для русскоязычной IT-аудитории это не абстрактный спор о будущем, а вопрос о том, кто через несколько лет вообще дорастет до мидла и сеньора.
В колонке в корпоративном блоге ISPsystem, как пишет Habr / Карьера, разработчик разбирает не столько возможности нейросетей, сколько побочные эффекты их массового и слишком доверчивого использования. Главный тезис звучит неприятно, но внятно: если новичок отдает ИИ свои первые учебные и рабочие задачи, он ускоряет не свое развитие, а собственную профессиональную пустоту. В краткосрочной перспективе это выглядит как экономия времени. В долгосрочной — как ситуация, где junior формально есть, а полезной инженерной базы под ним нет.
Логика автора строится на простом наблюдении из реальной практики. Никто не дает вчерашнему выпускнику архитектурную задачу или сложный продовый инцидент. Почти все начинают с небольших исправлений, второстепенных модулей, локальных доработок, с того, что опытный инженер действительно может сделать десятками за день. Но ценность этих задач не в объеме и не в сложности. Они нужны как вход в кодовую базу, в культуру команды, в правила проекта, в технический язык компании. Если этот слой полностью уходит ИИ, у новичка пропадает не рутина, а учебный полигон. Он не ходит по коду вокруг ошибки, не выясняет, почему система устроена именно так, не набивает руку на мелких, но показательных сбоях. В лучшем случае он читает готовый дифф на десять строк. В худшем — просто относит его старшему разработчику на ревью.
И вот здесь, пожалуй, самая болезненная мысль из текста. Когда junior приносит результат, который по сути произвел ИИ, команда получает не усиление, а дополнительную нагрузку. Сеньору приходится проверять не работу коллеги, который постепенно учится думать, а работу модели, которая может быть уверенной, гладкой и при этом неверной в деталях. Автор честно формулирует неудобный вопрос: если ИИ сделал задачу, а старший инженер потом вынужден разбирать ее последствия, то зачем в этой цепочке нужен человек посередине и за что ему платить «большую IT-шную зарплату»? Для менеджеров этот аргумент звучит как оправдание сокращений. Для отрасли в целом — как сигнал опасности: слишком ранняя вера в самодостаточный ИИ в разработке может разрушить сам механизм воспроизводства кадров.
В тексте есть и более широкий контекст. Автор замечает, что часть разработчиков и без нейросетей работает по принципу «подобрал решение, раз оно собирается». Он приводит характерный пример с собеседований: кандидаты предлагают использовать умные указатели для «сборки мусора» в реализации списка, не очень понимая, как работают сами указатели, стек и базовая механика C++. Еще лет 20 назад фраза «написал так, потому что по-другому не собиралось» звучала бы как профессиональный провал. Сейчас это уже почти рабочий стиль. Добавьте сюда генеративные модели, и инженерная магия становится еще гуще: код есть, результат вроде бы есть, объяснения, почему это должно работать и где именно оно сломается, — нет. Для рынка это, вероятно, один из главных рисков бума AI-инструментов: они ускоряют не только сильных, но и тех, кто уже привык обходиться без понимания основ.
При этом автор не играет в лагерь техноскептиков и не предлагает выбросить нейросети из рабочего контура. Наоборот, он описывает ИИ в разработке как нормальный инструмент разработчика, а не как замену разработчику. Пример понятный: сегодня почти никто добровольно не пишет код в простом текстовом редакторе, игнорируя IDE, автодополнение и рефакторинг. AI-помощник в этом смысле продолжает ту же линию автоматизации. Он полезен там, где съедает рутину, помогает с шаблонными кусками, подсказывает стандартные подходы, ускоряет черновую работу. Автор отдельно отмечает автодополнение и документацию: второе особенно показательно, потому что писать docs любят немногие, а нейросеть хотя бы умеет пройтись по связанным местам и не забыть половину изменений.
Но полезность инструмента у него всегда идет с оговоркой: ИИ нельзя оставлять без надзора. В статье есть частный, но очень показательный пример собственной утилиты автора для тестирования HTTP-сервисов. Она устроена не по самым типовым лекалам, поэтому модель без дополнительных пояснений не улавливает ее логику, хотя в целом пишет тесты «неплохо». Это важная деталь для любой команды, которая всерьез внедряет ИИ в разработке: нейросеть обычно уверенно чувствует себя на стандартных фреймворках и популярных паттернах, но начинает путаться там, где у компании накоплены свои инженерные допущения, внутренние инструменты или просто нестандартный ход мысли. То есть ИИ хорошо снимает массовую, повторяемую нагрузку, но не отменяет необходимости понимать собственную систему лучше, чем ее понимает статистическая модель.
Отдельная сильная линия текста — не про производительность, а про обучение. Автор фактически признает, что классическое «погугли» уже меняется на «спроси у ИИ», и в этом есть практическая польза. Модель может подсветить функцию API, конструкцию языка или подход, который разработчик не знал, не вспомнил или просто не держал в голове. В условиях, когда стеков, библиотек и фреймворков слишком много, это выглядит не как читерство, а как нормальный способ расширять рабочий кругозор. Но только при одном условии: человек использует ответ как повод разобраться, а не как индульгенцию ничего не понимать. ИИ может быть похож на сильного напарника по парному программированию или на опытного ревьюера нового языка, который не читает лекцию по азам, а сразу показывает, где решение противоречит идеологии инструмента. Для зрелого инженера это действительно способ выйти на новый уровень абстракции и лучше формулировать задачи.
На выходе получается не спор в духе «заменит или не заменит», а куда более приземленный разговор о том, какие именно звенья в профессии нельзя делегировать машине без потерь. ИИ в разработке уже помогает писать код, тесты, документацию и подсказки к API. Но если вместе с рутиной он заберет у новичков право на медленное, местами скучное, зато настоящее вхождение в профессию, отрасль рискует остаться с дефицитом тех, кто умеет не только нажимать Enter после промпта, но и отвечать за результат, когда промпт внезапно закончился.