Что на самом деле происходит: ИИ не отменяет разработку, а сжимает её по блокам
Профессия разработчика не исчезает целиком, она сжимается по блокам. Первым уходит то, что проще формализовать: генерация шаблонного кода, типовые правки, тесты, обвязка вокруг бизнес-логики. Дольше держится работа, где нужен контекст продукта, ответственность за архитектурные решения и коммуникация с людьми.
Это наблюдение практика, а не результат исследования. Автор эссе «Как мы горим» пишет, что драйвер изменений в индустрии сейчас ИИ, а выгоду от него видят и разработчики, и менеджмент. Дальше он фиксирует то, что видно в новостной ленте: компании, отечественные и зарубежные, всё чаще сообщают об идущих и грядущих сокращениях штата. Свой текст он прямо называет эссе по мотивам наблюдений и общения с коллегами, без претензии на истину.
Метафора «по кускам» точнее описывает процесс, чем разговор о полной замене. Автоматизация приходит не ко всей профессии сразу, а к отдельным операциям: сначала к тем, где вход и выход описываются словами, где мало скрытых зависимостей и где ошибку дешево исправить. Вопрос «ИИ заменяет программистов?» в такой постановке теряет смысл. Правильнее спрашивать, какой именно блок вашей работы уже закрывается инструментом, а какой пока нет.
Почему «оптимизация» значит больше, чем сокращения
В новостной ленте всё чаще появляются сообщения компаний, отечественных и зарубежных, об идущих и грядущих сокращениях штата, которые называют «оптимизацией». Автор эссе отмечает: за этим словом зачастую стоит сокращение штата и «усиление» оставшихся сотрудников ИИ-инструментами. Менеджмент привлекает быстрый результат в виде новых фич и улучшения продукта, ради этого руководство идёт на смелые эксперименты со структурой команд.
Практический смысл для читателя простой. Когда в компании звучит «оптимизация», стоит задать два вопроса. Какие именно задачи планируют закрыть инструментами? Какие роли при этом укрупняют? Ответы показывают, что произойдёт с вашей зоной ответственности через полгода, задолго до официальных объявлений.
Связь между ИИ и сокращениями идёт через экономику, а не напрямую. Инструмент удешевляет единицу работы, и компания решает, куда деть освободившийся ресурс: выпускать больше или сокращать людей. Выбор зависит от рынка, зрелости продукта и стратегии, а не от возможностей конкретной модели. Поэтому одинаковые новости про «оптимизацию» в разных компаниях означают разное.
Что автоматизируется первым, а что держится дольше
Принцип «сначала автоматизируется то, что проще формализовать» объясняет почти весь порядок, в котором ИИ забирает задачи у команды.
| Блок работы | Насколько просто формализовать | Что остаётся человеку |
|---|---|---|
| Шаблонный CRUD, обвязка, конфиги, миграции по образцу | Высоко: задача описывается словами и повторяется из проекта в проект | Проверить стыки с существующим кодом и границы применимости шаблона |
| Типовые тесты, фикстуры, генераторы данных | Высоко: структура известна, критерий проверки очевиден | Решить, что именно проверять, и убедиться, что тест ловит ошибку |
| Рутинные правки и рефакторинг по образцу | Средне: нужен контекст репозитория | Оценка риска, ревью диффа, проверка побочных эффектов |
| Разбор инцидента в проде | Низко: мало данных, много неизвестных | Гипотезы, приоритизация, ответственность за решение |
| Архитектура, границы сервисов, продуктовые компромиссы | Низко: высокая цена ошибки, контекст не формализуется | Всё: выбор, обоснование, последствия |
Разница видна на двух задачах. «Добавь поле в форму и проведи его через API» агент закрывает за один прогон. «Разберись, почему у части клиентов заказы дублируются после ретраев» требует логов, знания истории решений и разговора с поддержкой. Вторая задача съедает больше времени, но именно она держит продукт живым.
Позитивная сторона, которую отмечает автор эссе: многие разработчики наконец запускают проекты, которые долго лежали на полке отложенных, и делятся результатами. Порог входа в собственный пет-проект заметно упал, и это реальный выигрыш от распространения ИИ, а не маркетинговый тезис.
Граница проходит по цене ошибки и по объёму контекста, который нельзя восстановить из кода. Чем дороже стоит неверное решение и чем больше знаний о продукте, людях и истории системы оно требует, тем меньше ИИ может сделать самостоятельно.
Как меняется структура инженерных команд: реструктуризации, укрупнение, режим фулстек
Картина из разговоров с коллегами повторяется в разных вариантах. Три группы по пять человек сводят в одну, освободившихся переводят на другие продукты или не заменяют при уходе. Оставшиеся получают более широкую зону ответственности и тот же срок на релиз. Это наблюдения из общения, а не отраслевая статистика: в разных компаниях процесс идёт с разной скоростью и не везде вообще идёт.
Логика управленца здесь простая. Если инструмент закрывает часть рутины, держать прежнее число людей с прежним разделением труда кажется расточительством. Проверить эту логику можно только одним способом: посмотреть, что произойдёт с качеством и скоростью через два-три квартала. Цифры одной команды за один спринт ничего не доказывают.
Сокращение QA и автотесты с помощью ИИ: что это значит для разработчика
После сокращения QA тестирование не исчезает, оно переезжает в задачи разработчика. Автотесты с помощью ИИ закрывают часть объёма: сгенерировать скелет теста, фикстуры и набор кейсов по описанию эндпоинта занимает минуты. Ответственность за качество остаётся на человеке, и это главное ограничение схемы.
Сгенерированный тест часто проверяет то, что легко сформулировать, а не то, что ломается в проде. Ассерты повторяют реализацию, моки воспроизводят ту же ошибочную логику, граничные случаи пропускаются. Покрытие растёт, уверенность нет. Рабочий приём проверки простой: специально внесите ошибку в код и посмотрите, падает ли тест. Если не падает, тест бесполезен, сколько бы строк он ни занимал.
Второй эффект связан с разделением ролей. QA раньше ловил класс ошибок, о котором разработчик просто не думал, потому что смотрел на код другими глазами. Когда эта функция исчезает, слепые зоны остаются, а носителя другой оптики в команде нет. Компенсировать это можно, если ревью тестов станет отдельным этапом, а не формальностью в конце спринта.
Фулстек как новая норма: плюсы и цена
«Фулстек» в новой конфигурации шире классического «фронт плюс бэк». В него попадают тесты, инфраструктура, наблюдаемость, разбор инцидентов, иногда поддержка и работа с данными.
Плюсы реальные. Разработчик видит задачу от интерфейса до базы, меньше времени уходит на передачи и уточнения, ценность такого человека в плоской команде выше, а решения становятся цельнее: он замечает конфликт между удобством UI и стоимостью запроса.
Цена тоже конкретная. Внимание распыляется между пятью областями, глубина в каждой падает, а сроки на задачу не растягиваются. Появляется риск поверхностного тестирования: человек проверяет то, что сам придумал, и не видит собственных допущений. Выгорание в такой роли приходит быстрее, потому что зона ответственности растёт без роста полномочий и без права сказать «это не моё».
Категоричной рекомендации тут нет. В небольшом продукте с коротким циклом и низкой ценой ошибки широкий профиль окупается. В системе с высокими требованиями к надёжности узкая специализация по-прежнему даёт результат, а универсал без глубины создаёт риск. Смотреть стоит на тип продукта и на то, есть ли в команде кто-то, кто проверяет вашу работу.
Карьерные траектории: почему закрываются junior-ступени и ограничивается рост вверх
Два конца карьерной лестницы сжимаются одновременно. Внизу исчезают задачи, на которых раньше учились новички. Наверху становится меньше уровней, потому что команды укрупняют, а промежуточные роли вроде «senior с половиной обязанностей лида» растворяются.
Junior-разработчики и ИИ: где теперь учиться ремеслу
Раньше junior рос на рутине: правки по шаблону, простые баги, тесты, миграции. Именно эти задачи ИИ закрывает первым, и вместе с ними исчезает безопасная песочница, где ошибка стоила дешево и многому учила.
В описании темы приводится отчёт Anthropic от 16 октября 2026 года, по которому доля junior среди технических наймов упала с 27% до 9%. Первоисточник в доступных материалах не приведён, поэтому цифры стоит воспринимать как заявленные и проверять по публикации Anthropic, прежде чем опираться на них в решениях.
Если ориентироваться на саму логику изменений, вход в профессию смещается в сторону задач, где ИИ выдаёт результат, а человек его проверяет. Практические ориентиры выглядят так:
- читать и разбирать чужой код, в том числе сгенерированный, и уметь объяснить, почему он работает;
- разбираться в тестах: что именно проверяется, какие граничные случаи пропущены, что будет при отказе зависимости;
- брать задачи с ответственностью за результат, а не за объём написанных строк;
- спрашивать «почему так решили», а не «как это сгенерировать».
Главная ловушка для новичка в том, что сгенерированный код выглядит правильным. Он компилируется, проходит часть тестов и читается гладко. Навык сомневаться в этом коде и есть то, что раньше нарабатывалось на сотнях мелких правок. Гарантий трудоустройства здесь никто дать не может, речь только о направлении, где усилия дают отдачу.
Плоские команды и потолок роста
Укрупнение убирает уровни. Если в команде из двадцати человек один лид и нет тимлидов, то вакансий «вырасти в руководителя» внутри просто нет, а конкуренция за те, что появятся, выше, чем пять лет назад. Вертикальный рост упирается в арифметику штатного расписания, а не в ваши навыки.
Работающие альтернативы выглядят скромнее, но они реальны. Углубление в специализацию, где цена ошибки высока: производительность, безопасность, работа с данными, надёжность инфраструктуры. Расширение зоны ответственности за сквозной результат: от требований до эксплуатации. Переход в продуктовую или архитектурную роль, где ценят понимание системы целиком. Риск честно назову: на каждую такую позицию претендентов больше, чем мест.
Автор эссе описывает траекторию, которая была нормой: джуном в галере, затем через несколько языков и проектов до лида в продуктовой компании. Такая лестница ещё существует, но ступени на ней теперь расположены иначе. Рутина исчезает из середины, и переход между уровнями требует доказательств другого рода: не «я написал много кода», а «я отвечал за решение, у которого были последствия».
Что показывают ИИ-инструменты на практике: метрики Claude Code и не только
Метрики продуктивности в этой теме обсуждать сложнее всего: они зависят от команды, процессов и того, что вообще считается работой. Полезно смотреть не на абсолютные числа, а на то, что они измеряют.
Claude Code для разработки: что стоит за цифрами
В описании темы приводится опыт команды Claude Code: число PR удвоилось, а доля откатов упала более чем на 40%. Проверяемого первоисточника по этим числам в доступных материалах нет, поэтому воспринимать их стоит как заявленные командой продукта, а не как отраслевой стандарт.
Если читать цифры осторожно, удвоение числа PR может означать разное: ускорение цикла, дробление изменений на более мелкие, рост доли автоматических правок. Падение доли откатов чаще связывают с качеством ревью и предсказуемостью изменений, но тот же эффект даёт и простая смена правил: если ревьюер перестал спорить о стиле, откатов становится меньше без роста качества кода.
Разбор ИИ-ассистентов в разработке на AI-Manual показывает ту же неравномерность: ускорение на шаблонных задачах соседствует с замедлением на сложных, а понимание кода у новичков страдает сильнее всего. Отсюда практический вывод: считать эффект по одной метрике бессмысленно, нужно смотреть на связку «скорость, качество, стоимость переделок».
AI-агенты в разработке ПО: где помогают, а где нет
Агенты берут на себя цепочки рутинных шагов: сгенерировать изменение, поправить импорт, добавить тест, обновить зависимость, прогнать линтер и вернуть дифф на ревью. Это экономит время на задачах с коротким циклом обратной связи.
Ограничения начинаются там, где контекст не выводится из кода. В незнакомой кодовой базе агент уверенно предлагает решение, которое противоречит принятым в проекте договорённостям, а проверить его может только человек, знающий историю. Задачи с высокой ценой ошибки и работа с данными пользователей требуют ручного контроля. Отдельный риск: агент снижает трение настолько, что ревью превращается в формальность, и тогда ошибки проходят быстрее, чем раньше. Почему часть инженеров сопротивляется передаче кода агентам и где проходит граница авторства, разобрано в отдельном материале.
FOMO-спираль и выгорание: когда разработчик сам автоматизирует свою работу
Отдельный сюжет этой истории психологический. Люди одновременно создают инструменты, которые снижают потребность в их присутствии, и боятся отстать от тех, кто делает это быстрее.
Почему гонка за ИИ-навыками выматывает
Механизм FOMO здесь работает как в любом рынке дефицита внимания. Каждый новый инструмент подаётся как обязательный, время на освоение растёт, а отдача не успевает проявиться до следующего релиза. Разработчик учится пользоваться десятком сервисов на уровне демо и ни одним на уровне рабочего процесса.
Наложение на это укрупнения команд даёт двойную нагрузку: меньше людей, больше зон ответственности, те же сроки. Человек закрывает дыру инструментом, потом обнаруживает, что теперь отвечает и за инструмент тоже. Это гипотеза, которая следует из наблюдений за командами, а не измеренный эффект. Проверить её каждый может на себе: если после внедрения новой автоматизации свободного времени не прибавилось, вы получили не выигрыш, а перенос работы.
Как не выгореть, автоматизируя собственную работу
- Оценивайте инструмент по сэкономленным часам на конкретной задаче за прошлый месяц, а не по качеству демо.
- Ограничьте поток: один-два инструмента за квартал, доведённых до реального рабочего процесса, дают больше, чем десять попробованных.
- Записывайте, что именно автоматизировано и кто теперь отвечает за результат. Без этого ответственность размазывается и возвращается к вам в виде инцидента.
- Отдельно смотрите на задачи, где ИИ заменяет вас целиком, а не усиливает. Их автоматизация бьёт по вашей позиции первой, и приоритет тут стоит выбирать осознанно.
- Договаривайтесь о границах роли вслух. Расширение зоны ответственности без разговора о приоритетах почти всегда заканчивается переработками.
Полезно держать в голове общий контекст: полный отказ от ИИ в 2026 году означал бы отказ от работы и бытовой техники, о чём подробно говорится в разборе цены отказа от ИИ. Вопрос не в том, использовать ли инструменты, а в том, какие и на каких условиях.
Практические выводы: как разработчику адаптироваться к рынку труда
Собрать из наблюдений набор действий можно. Универсального рецепта нет, многое зависит от компании и продукта, но направление усилий определяется логикой автоматизации.
Какие навыки усиливать в первую очередь
- Понимание продукта и домена. Модель не знает, почему скидка не сочетается с самовывозом, а вы можете узнать. Чем специфичнее бизнес-логика, тем дольше она держится за человеком.
- Архитектурное мышление. Выбор границ сервисов, режимов отказа и компромиссов между скоростью и надёжностью плохо формализуется и дорого стоит при ошибке.
- Ревью кода, включая сгенерированный. Чтение чужого диффа с оценкой риска становится основной ежедневной работой, а не дополнительной нагрузкой.
- Тестирование и ответственность за качество. Автотесты с помощью ИИ дают объём, но критерий «тест ловит ошибку» ставит человек.
- Работа с ИИ-инструментами как часть процесса. Навык нужен не в формате «знаю названия», а в формате «настроил поток задач, знаю, где инструмент врёт, умею проверить результат».
Общая логика простая: дольше остаются востребованными навыки, которые трудно описать инструкцией и которые связаны с последствиями решений. Как меняется сама роль разработчика по мере ухода исполнительских задач, разбирается в материале о переформатировании IT-иерархии.
Как позиционировать себя в плоской команде
Когда уровней мало, ценность считается не должностью, а тем, какие решения на вас замыкаются. Работающие шаги выглядят так: брать сквозные задачи, где виден результат от требований до эксплуатации; расширять зону влияния через помощь коллегам с ИИ-инструментами и настройку общих процессов; фиксировать вклад так, чтобы он был виден за пределами команды, а не только в чате.
Ограничения честно назову ещё раз. Конкуренция за немногочисленные позиции выше, часть усилий не окупится, а в некоторых компаниях плоская структура означает не новые возможности, а просто отсутствие роста. Проверить границы применимости ИИ на своих задачах помогает разбор типичного кейса с магазином за два вечера: там видно, как быстро заканчивается демо и начинается работа с реальными требованиями.
Автор эссе, на котором построен этот разбор, прямо пишет, что не претендует на истину и делится мнением по итогам нескольких месяцев наблюдений. Это честная позиция, и она задаёт правильный способ чтения таких текстов: брать из них вопросы, которые стоит задать своей команде, а выводы проверять на собственном контексте, в своих метриках и на своём продукте.