Один человек управляет 117 AI-агентами, которые пишут код. Не прототипы, не наброски – готовый, рабочий код. Пост из LinkedIn облетел профессиональное сообщество и вызвал предсказуемую реакцию: одни увидели будущее, другие – очередной хайп.

В нашем чате этот пост спровоцировал дискуссию на 300+ сообщений. Не абстрактные рассуждения о «будущем технологий», а конкретный вопрос: если один человек заменяет команду из 117 разработчиков, то что делать остальным 116?

Спор обнажил фундаментальный разлом в сообществе: оптимисты верят в масштабирование моделей, скептики – в непреодолимые ограничения архитектуры трансформеров. И у каждой стороны есть аргументы, которые нельзя отмахнуть.

«Готовый код – всё понятно»

Первая реакция на пост с 117 агентами была ироничной. «Не прототип, не набросок. Готовый код – всё понятно» – моментальное раскусывание маркетинговой обёртки. За громким числом скрывается вопрос, который LinkedIn-пост элегантно обходит: кто несёт ответственность за этот код?

Ответ очевиден: тот, кто релизит. И это ключевое наблюдение, которое меняет всю дискуссию. AI может генерировать код. AI не может нести ответственность за продакшн. Между «написать» и «выпустить» – пропасть из тестирования, ревью, понимания контекста системы, оценки рисков.

Отсюда родилась первая модель будущего: разработчики не исчезают, а превращаются в SRE нового типа. Их работа – код-ревью, QA, поддержка и принятие решений о том, что именно попадёт в продакшн. Не кодеры, а стражи.

Может ли аналитик заменить разработчика?

Самый провокационный тезис дискуссии: если AI пишет код, то для валидации достаточно системного аналитика. Логика такая: аналитик умеет писать техническое задание. Если ТЗ достаточно формализовано, то результат можно проверить без понимания реализации – достаточно конвертировать код в артефакт, понятный аналитику.

Возражение пришло мгновенно: LLM не знает ничего об изменяющейся системе. Модель видит код, но не видит контекст: какие миграции запущены, какие сервисы деплоятся параллельно, какие договорённости существуют между командами. Человек-разработчик держит этот контекст в голове. Аналитик – нет. AI – тем более нет.

Это не вопрос «умности» модели. Это вопрос доступа к информации. Разработчик знает, что вчера коллега начал рефакторинг авторизации, потому что обсудил это в курилке. Модель этого не знает, пока ей не скажут. А кто ей скажет, если разработчика уволили?

Математика деградации: почему 90% – это катастрофа

Допустим, модель выдаёт 90% хорошего кода за одну итерацию. Звучит неплохо. Но вот незадача: код – это не единоразовое действие. Это итерации.

Вторая итерация: 90% от 90% = 81% хорошего кода. Третья: 72,9%. Пятая: 59%. Десятая: 34,9%. Формулировка из дискуссии была грубее: «С каждой итерацией говно будет плодиться. Через 10 итераций там будет одно говно».

Это не теоретическое упражнение. Это описание реального рабочего процесса, когда AI дописывает код, сгенерированный AI, который был основан на коде, сгенерированном AI. Каждый слой добавляет технический долг, который модель не осознаёт как долг – для неё это просто контекст.

Контраргумент оптимистов: человеческий код деградирует точно так же, просто медленнее. Любой проект без рефакторинга через пять лет превращается в легаси. Вопрос не в том, деградирует ли код – а в скорости деградации и способности это контролировать.

Планка человека не так высока

Скептики исходят из предположения, что человек-разработчик – это высокая планка. Но так ли это?

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

Ответ скептиков: белки – это закрытая система с фиксированными правилами. Софт – открытая система с меняющимися требованиями, политическими решениями и человеческими договорённостями. AlphaFold не общается с продакт-менеджером, который меняет требования в пятницу вечером.

Но оптимисты парируют и это: средний разработчик тоже не блещет. Код, который пишут 80% программистов в ежедневной работе, – рутина. Формы, API-эндпоинты, миграции, конфигурации. Для этого не нужен искусственный интеллект – достаточно автоматизации с проверкой.

Фундаментальный разлом: масштабирование vs ограничения

Дискуссия выявила два лагеря, которые говорят на разных языках.

Оптимисты верят в масштабирование. Модели становятся лучше с каждым поколением. То, что GPT-3 делал плохо, GPT-4 делает хорошо. То, что GPT-4 делает посредственно, следующее поколение будет делать отлично. Экстраполяция – их главный аргумент. Тренд не сломался ни разу за последние пять лет.

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

Требование скептиков: «Источник уровня trust me bro?» Они хотят доказательств, что масштабирование приведёт к качественному скачку, а не количественному улучшению. Оптимисты отвечают: доказательство – сами модели. Каждый релиз – это доказательство.

Этот спор не имеет решения в 2026 году. Но у него есть практические следствия.

Реальная угроза: не замена, а обесценивание

Разработчиков не заменят одномоментно. Это не выключатель «был нужен – стал не нужен». Это постепенный процесс, при котором стоимость определённых навыков падает.

Написание бойлерплейта уже стоит меньше, чем год назад. Через год будет стоить ещё меньше. Разработчик, чья ценность – в скорости написания стандартного кода, конкурирует с машиной на территории машины. Это проигрышная стратегия.

Что остаётся ценным:

  • Понимание бизнес-контекста и перевод его в технические решения
  • Владение системой целиком – не отдельными файлами, а архитектурой
  • Принятие решений в условиях неопределённости
  • Коммуникация с людьми, которые не знают, чего хотят
  • Ответственность за последствия

Иронично: это описание работы тимлида. Не кодера – а того, кто думает и отвечает за результат.

Что конкретно делать

Дискуссия не дала однозначного ответа на вопрос «заменит ли». Но дала ответ на вопрос «что делать, пока не заменили»:

1. Перестаньте соревноваться с AI в скорости написания кода. Это гонка, которую вы проиграете. Соревнуйтесь в понимании.

2. Учитесь работать с AI, а не против него. «Если реально самому работать, а не запускать автономных агентов – сложно упереться в лимит» – наблюдение из практики. Человек + AI эффективнее, чем человек или AI по отдельности.

3. Инвестируйте в системное мышление. AI плохо контролирует общее направление проекта. Он мечется между подходами, когда в проекте намешано несколько архитектурных стилей. Человек, который держит целостную картину – незаменим. Пока.

4. Не доверяйте AI ответственность. Код-ревью, валидация, принятие решения о деплое – это человеческие функции не потому, что AI не умеет, а потому что кто-то должен отвечать за последствия.

5. Следите за качеством, а не за скоростью. Когнитивный долг – реальная проблема. Чем быстрее вы пишете с AI, тем быстрее теряете понимание собственного проекта. Контролируйте это осознанно.

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

Если вы руководите командой, вопрос «заменит ли AI разработчиков» – не философский. Это вопрос о планировании найма, обучения и архитектуры команды на следующие 2–3 года.

Наймёте 10 джунов на бойлерплейт? Через год их работу будет делать один человек с AI. Наймёте двух сильных инженеров, которые понимают систему целиком? Они останутся ценными независимо от того, чья модель будущего окажется правильной.

Не ставьте на один сценарий. Стройте команду, которая ценна в обоих.

Эта статья основана на дискуссии в сообществе «Тимлид не кодит» 14–20 апреля 2026 года. Полный обзор обсуждений недели – в инсайтах за 14–20 апреля. Присоединяйтесь к обсуждению в Telegram.