Профессия разработчика не исчезнет. Но замена уже началась в менее кинематографичном смысле. Один человек с агентами забирает объём работы маленькой команды, а рынок перестаёт платить за медленное ручное исполнение.
Да, заголовок специально сформулирован так, чтобы разработчик захотел со мной поспорить. Я не верю, что компании однажды уволят всех программистов и заменят их одной нейронкой. Но слово «замена» можно понимать иначе. Если один сильный разработчик с агентами делает работу, для которой раньше требовались трое, двум людям на рынке придётся найти новую ценность.
Под слабым разработчиком я не имею в виду джуна или человека, который пока не знает очередной паттерн. Слабый разработчик продаёт ручное исполнение и защищает привычный процесс от изменений. Он может помнить названия всех архитектурных подходов и всё равно проиграть человеку, который быстрее понял задачу, собрал решение и доказал, что оно работает.
Вайбкодеры показывают неприятную для индустрии вещь. Над ними легко смеяться за плохой код, отсутствие тестов и сломанный прод. Но они уже поняли главное. Код стал способом решать задачу, а не сословным ритуалом.
Вайбкодер без суждения действительно наломает дров. Разработчик, который соединит инженерную глубину со скоростью агентов, поднимет планку для всех остальных.
Поэтому вопрос «заменит ли AI разработчиков» для меня закрыт. Он не отменит профессию. Он изменит объём результата, который рынок ожидает от одного человека. Тот, кто не перестроится, формально останется разработчиком, но перестанет держать уровень.
Самая слабая формулировка про эту перестройку звучит так: «я пользуюсь AI». Это примерно как сказать, что вы пользуетесь интернетом. Непонятно, что именно изменилось в вашей способности выпускать результат.
У меня изменилось почти всё. Год назад большая часть работы проходила в одном диалоге с одним агентом. Я ставил вопрос, ждал ответ, правил промпт и продолжал беседу. Теперь средняя задача, кроме простого поиска, может исполняться несколько часов. Внутри появляются десятки субагентов. Один изучает код, другой проверяет источники, третий ищет ошибки, четвёртый смотрит страницу в браузере. Я могу не знать, что каждый из них делает в конкретную минуту.
С первого запуска это не работает. Система теряет контекст, дублирует работу, уверенно идёт не туда и приносит красивую ерунду. Её приходится проектировать, проверять и улучшать. Но когда цикл замыкается, появляется ощущение суперспособности. Один человек управляет объёмом исполнения, для которого раньше нужна была команда.
Здесь легко сделать неправильный вывод и начать автоматизировать самого себя. Я пришёл к обратному. Производство нужно отдавать машинам как можно агрессивнее. Выбор цели, оценку качества и ответственность нужно оставлять у человека. Иначе вместо рычага получится слоп‑машина, которая быстрее жмёт на кнопки в казино.
1. Перестать общаться с AI и начать строить из него систему
Чат хорошо решает вопрос, который уже помещается в голову. Система нужна, когда у задачи есть исследование, производство, проверка и память. Разница не в количестве открытых окон. Она в повторяемости.
Если я завтра повторю запуск на новой теме, он должен снова собрать источники, выпустить артефакт, проверить критерии и показать, где не уверен. Если хороший результат каждый раз зависит от того, поймаю ли я модель на пятом сообщении, это всё ещё разговор, а не рабочий процесс.
Часть работы | Один чат | Система агентов |
|---|---|---|
Контекст | Копится в длинной переписке | Собирается под роль и задачу |
Исполнение | Одна очередь сообщений | Независимые ветки идут параллельно |
Проверка | Тот же агент оценивает себя | Отдельный агент получает другой контекст и ищет ошибки |
Стоимость | Одна модель на всё | Модель выбирается под цену ошибки |
Память | Остаётся в истории чата | Возвращается в правила, тесты и примеры |
Моя роль | Постоянно веду агента за руку | Задаю цель и принимаю контрольные точки |
Мне нравится думать об этом как о производстве. У линии есть вход, станции, контроль качества и понятный выход. На каждой станции может стоять своя модель. Простую механическую работу делает дешёвая. Сложное решение уходит сильной. Независимый проверяющий получает другой контекст, чтобы не наследовать уверенность автора.
Хороший запуск можно повторить без моего постоянного присутствия, а найденная ошибка делает следующий запуск сильнее.
Такой переход не устраняет работу. Он переносит её выше. Я меньше двигаю строки и больше проектирую контекст, границы, проверки и обратную связь. Чем автономнее становятся агенты, тем важнее качество этой конструкции.
Похожий контур я уже показывал в статье о системе, которая разогнала аккаунты до 50 млн просмотров в месяц. Там исследование, сценарии, производство и аналитика замкнуты в один цикл. В работе с агентами действует та же логика. Отдельный сильный исполнитель полезен, но повторяемый результат даёт связанная система.
2. Время дороже токенов
Я не считаю количество обращений к модели хорошей метрикой эффективности. Иногда второй агент повторяет работу первого. Иногда ревью съедает столько же токенов, сколько реализация. Это нормально, если система экономит моё внимание и сокращает календарное время до результата.
Восемь часов работы, сжатые до четырёх, дают реальный выбор. Можно в два раза больше отдыхать. Можно решить в два раза больше задач. Можно потратить освободившиеся часы на разговор с пользователем, стратегию или ремесло, где человеческое внимание действительно меняет качество. Сэкономленные токены такого выбора не дают.
Поэтому я не автоматизирую ради красивой схемы. Одноразовая задача на двадцать минут часто быстрее делается руками. Система нужна там, где работа повторяется, блокирует другие шаги или забирает часы концентрации.
Я задаю один вопрос. Сколько моего времени и времени команды вернёт этот контур после следующих десяти запусков?
Когда стоит строить систему
Задача повторяется и каждый раз требует похожих шагов.
Части работы можно выполнять независимо.
Готовность можно проверить по наблюдаемому результату.
Ошибки можно превратить в правила или тесты.
Когда проще сделать самому
Задача случится один раз и занимает меньше получаса.
Главная работа состоит в выборе ещё неясной цели.
Нет материала, по которому можно проверить ответ.
Поддержка процесса заберёт больше времени, чем он сэкономит.
3. Когда исполнение дешевеет, цель становится главной работой
Раньше хорошую идею часто останавливала стоимость исполнения. Нужно было найти разработчика, дизайнера, аналитика, редактора, договориться о приоритетах и ждать. Сегодня один человек может самостоятельно исследовать рынок, собрать прототип, написать код, спроектировать экран, посчитать экономику и подготовить запуск.
Ограничение переехало. Теперь страшнее потратить неделю на отлично исполненную ерунду. AI не устаёт и не сопротивляется. Он способен построить очень качественную дорогу к цели, которую никто не проверил.
Скорость исполнения умножает качество выбранного направления.
Перед большим запуском я стараюсь ответить на несколько неприятных вопросов.
Какая проблема здесь действительно важна?
Для кого она настолько болит, что человек уже пытается её решить?
Где деньги?
Почему окно открылось сейчас?
Какой самый дешёвый тест может разрушить гипотезу?
Что я увижу в данных, если оказался прав?
Эти вопросы нельзя делегировать целиком. Агент поможет расширить карту, найти контраргументы и посчитать сценарии. Решение, куда поставить месяцы своей жизни и внимание команды, остаётся моим. Именно поэтому в мире дешёвого исполнения целеполагание становится дорогим навыком.
Здесь работает тот же принцип, который я описал в статье про сильные решения. Мне нужен рычаг, маленькое действие, которое меняет большую часть результата. Агентская система усиливает рычаг, но не выбирает точку опоры.
4. Сто вариантов ничего не стоят. Дорожает способность выбрать один
За минуту можно получить сто названий, логотипов, экранов, текстов или продуктовых идей. Возможность создать ещё один вариант почти обнулилась в цене. Поэтому ценность переехала в judgement, способность увидеть, какой ответ действительно подходит к этой ситуации.
Суждение отвечает на вопросы, которых нет в промпте. Где скрыта ошибка? Какое предположение выглядит убедительно только на бумаге? Что слишком банально? Какой вариант нарушает характер продукта? Что сработает сегодня, но загонит нас в угол через полгода?
Рядом со суждением стоит вкус. Вкус позволяет посмотреть на сто приличных работ и сказать: этот вариант живой, остальные девяносто девять отправляем в корзину. Он рождается из насмотренности, практики, ошибок и понимания людей, для которых ты работаешь. Сгенерировать его по команде нельзя.
Производство вариантов имеет ценность только вместе с независимым шлюзом проверки.
Я вижу здесь опасную ловушку. Если человек отдаёт модели и производство, и оценку, контур становится самодовольным. Один агент пишет, второй хвалит, третий полирует. На выходе много гладкой работы без позиции. Поэтому проверяющий должен знать критерии, иметь право остановить выпуск и по возможности видеть реальные данные.
Я могу не писать каждую строку, но обязан понимать, почему этот результат хорош, какие допущения он делает и какую цену мы заплатим за ошибку.
В инженерной работе это особенно заметно. Агент легко выдаёт код, который выглядит убедительно в одном файле. Он не всегда видит границу транзакции, следующую миграцию, повторный webhook, старого клиента или человека, которому придётся разбираться в этом коде через год.
Фраза «работает» ничего не говорит о поддерживаемости. Она означает только то, что мы увидели один успешный сценарий. Прод начинается там, где появляются настоящие данные, повторные запросы, частичные сбои, права доступа и стоимость ошибки.
5. Широкий доступ не заменяет глубину
AI дал каждому доступ к соседним профессиям. Инвестор может написать внутренний инструмент, проанализировать данные и спроектировать продукт. Инженер может собрать исследование рынка, подготовить продажи, посчитать финансы и сделать первый дизайн. Это огромный рычаг для людей, которые раньше зависели от очереди чужих рук.
Но в чём‑то одном всё равно нужна глубина. Человек, который хорошо знает свою область, замечает, когда модель предлагает правдоподобную чушь. Он понимает, какие детали важны, а какие можно выкинуть. Он умеет задать критерий качества и знает цену компромисса. Без этой опоры AI даёт ширину без направления.
Моя опора лежит на стыке продукта, разработки и роста. Я могу с помощью агентов заходить далеко в дизайн, исследования, редактуру или инфраструктуру. Но ценность появляется потому, что я связываю эти части с реальным продуктом, пользователями и цифрами. Если убрать глубину, останется человек, который умеет просить модель изобразить любую профессию.
Мастерство важно ещё по одной причине. Оно даёт идентичность, терпение и внутренний стандарт, который не зависит от экономической полезности конкретной задачи. Люди продолжат ценить лучших в любом деле, от управления фондом до танцев в TikTok. Инструмент меняет скорость, но не отменяет желание видеть работу мастера.
6. Настоящая инфраструктура агентов состоит из контекста
Оркестратор, интерфейс и выбранная модель важны. Но я всё чаще вижу одну и ту же причину плохого результата. Агент не получил контекст, который человек считает очевидным. Он не знает, почему мы приняли старое решение, какой пример считается хорошим, что запрещено менять и как выглядит завершённая работа.
Контекст для меня шире промпта. Это словарь проекта, решения, инструкции, живые примеры, инструменты, данные, тесты и критерии готовности. Хороший контекст снижает число решений, которые агент вынужден додумывать. Он превращает опыт команды в материал, который можно использовать повторно.
Хороший контекст работает как повторно используемая мастер‑форма. Его улучшают один раз, а эффект получают в каждом следующем запуске.
Отдельный респект Мэтту Пококу за writing‑for‑agents. Он точно разделяет нагрузку на контекст и нагрузку на мышление, показывает progressive disclosure и требует явных критериев завершения. Я советую прочитать весь файл. Он помогает перестать воспринимать документацию для агентов как длинный справочник и начать проектировать путь к нужному решению.
Контекст нельзя один раз «написать полностью». Эксперт не замечает часть собственных знаний, потому что они давно стали для него очевидными. Полнота появляется через обратную связь. Агент ошибся на реальном примере, мы нашли отсутствующее правило, добавили его и снова проверили. Так система учится на ответах без обучения новой модели.
В Viralmaxing одна утечка транзакции когда‑то оставляла соединение в ошибочном состоянии и могла истощить пул. Исправить конкретный ранний выход было мало. Мы перевели путь на безопасный helper и добавили проверку, которая запрещает сырой вызов транзакции в репозитории.
Ошибка стала частью памяти системы. Следующий агент уже не должен знать историю инцидента, чтобы не повторить его.
7. Как выглядит мой запуск задачи сегодня
У меня нет одного универсального промпта. Есть операционная схема, которая повторяется в коде, текстах, исследованиях и дизайне. Масштаб меняется, логика остаётся.
Шаг 1. Назвать один результат
Я формулирую, что должно измениться в мире после завершения задачи. Не список файлов и действий, а проверяемый итог.
Шаг 2. Собрать минимальный контекст
Агент получает решения, ограничения, хорошие примеры, доступные инструменты и способ проверить готовность.
Шаг 3. Разделить работу по ролям
Исследование, реализация, проверка фактов, дизайн и ревью получают отдельные контексты. Для каждой роли можно выбрать свою модель и цену.
Шаг 4. Запустить независимую работу параллельно
Отдельные ветки идут одновременно. Мне не нужно наблюдать за каждым сообщением, если понятны артефакты на выходе.
Шаг 5. Провести независимую проверку
Новый агент не продолжает мысль автора. Он ищет ложные допущения, пропуски, небезопасные ходы и расхождения с задачей.
Шаг 6. Проверить на живом материале
Код проходит реальные данные, текст читается целиком, страница открывается на телефоне, а цифры сходятся с источником.
Шаг 7. Вернуть ошибку в систему
Найденный промах становится тестом, правилом, примером или запретом. Следующий запуск должен быть умнее предыдущего.
На простом поиске часть шагов лишняя. На релизе с деньгами, доступами или данными каждый шаг окупается. Я могу запускать десятки субагентов и не знать их поминутную деятельность, потому что контролирую не сообщения, а договорённости: вход, артефакт, критерий и проверку.
Самый сильный участок этого контура находится в конце. Если ошибка осталась только в моей голове, я заплатил за урок и выбросил половину ценности. Тест, пример, инструкция или автоматический запрет превращают единичный провал в улучшение всей будущей линии.
Поэтому мне близка идея агентов, которые улучшают работу других агентов. Один выполняет задачу на тестовом наборе. Второй читает его рассуждение, группирует типовые промахи и предлагает изменение контекста. Затем цикл повторяется. Человек задаёт метрику и принимает изменение, а система сама делает большую часть механической работы по поиску пробелов.
8. Viralmaxing: где эта система встречается с продом
Я строю Viralmaxing, продукт для команд, которые производят и анализируют короткие видео. Это не лендинг и не одноразовый прототип. В одной системе живут web‑приложение, Go API, фоновые задачи, Postgres, внешние интеграции, Telegram‑бот, инфраструктура и приложение для iPhone.
Контур | Что внутри |
|---|---|
Продукт | Web‑клиент, Go API, фоновые воркеры, роли и платные действия внутри команд |
Данные | Postgres, миграции, история аналитики, очереди задач, идемпотентность и транзакции |
Интеграции | Instagram, GA4, Telegram и внешние события, которые могут прийти повторно или не по порядку |
Доставка | Приложение в App Store, CI, контейнеры, health‑check и проверка версии после деплоя |
Весь продуктовый код Viralmaxing я написал с агентами. Под словом «написал» я не имею в виду ручной набор каждой строки. Я выбирал поведение, принимал архитектурные решения, давал контекст, проверял изменения и отвечал за релиз. Агенты дали мне пропускную способность небольшой команды. Ответственность осталась у меня.
Реальный экран Viralmaxing. Здесь продуктовая аналитика, с которой работают контент‑команды. Это доказательство продукта, а не сгенерированная иллюстрация.
Один из последних релизов собирал AI‑отчёт по аккаунту из 50 роликов. Дешёвый проход разбирал каждый пост, сильная модель сводила наблюдения, а Go‑код привязывал выводы к реальным метрикам и цитатам. Стоимость резервировалась до запуска, списывалась после успеха и возвращалась при ошибке.
На живом прогоне система разобрала 50 постов и 43 расшифровки. Тогда же вскрылись две правдоподобные ошибки.
Postgres enum внутри COALESCE требовал явного приведения к тексту. В другом месте модель вернула идентификатор строкой, а строгий парсер молча выбросил полезные сигналы. Оба хода выглядели нормально в коде. Их поймали реальные данные и проверка результата.
После этого появился терпимый парсер, тесты на обе формы ответа и более точный контракт. Так я и понимаю AI‑native разработку. Скорость релиза имеет смысл, когда прод возвращает знания обратно в систему.
GitHub, последние 12 месяцев: 3 901 contribution. 93% активности составляют коммиты в viralmaxing. Снимок от 24 августа 2026. Это показывает объём и непрерывность работы, но не заменяет проверку качества.
Этот пример заодно показывает границу вайбкодинга. Агент может быстро собрать убедительную функцию. Инженерная работа начинается с вопросов, которые обычно остаются за кадром.
Что произойдёт при повторном запросе?
Где проходит транзакция?
Когда возвращаются деньги?
Что мы сохраняем при частичном сбое?
Можно ли связать вывод модели с реальными данными?
Какая проверка не даст следующему агенту повторить ошибку?
Агент не даёт качество. Он даёт пропускную способность. Плохой процесс начинает быстрее производить плохие решения. Хороший процесс снимает ручную работу с исследования, реализации и проверки, но не отменяет инженерное суждение.
9. AI‑native компания начинается с людей
Долгое время AI был гонкой дорогой инфраструктуры. Нужно было собрать данные, построить хранилище, подготовить таблицы, обучить модель, купить вычисления. Всё это остаётся важным для части задач. Но код тоже был дорогой инфраструктурой, а теперь AI умеет писать его сам.
Нет интерфейса для разметки, можно быстро собрать свой. Не хватает инструмента для агента, можно добавить его в тот же день. Процесс живёт в голове эксперта, можно превратить реальные примеры в проверяемый контекст. Огромное количество старых ограничений оказалось дорогим обходным путём, а не стеной.
Поэтому я бы вкладывался в людей. Один умный человек с глубиной, вкусом и правильным набором инструментов теперь способен найти узкое место, построить вокруг него систему и принести результат, который раньше требовал нескольких функций. Сильная команда может делать то же самое на другом масштабе.
Слой | Кто отвечает |
|---|---|
Цель | Человек выбирает направление: какая проблема важна, почему сейчас, где деньги и какой результат будет считаться успехом |
Контекст | Система хранит решения, ограничения, примеры, инструменты и критерии качества рядом с работой |
Исполнение | Агенты исследуют, пишут, считают, проверяют и собирают результат без постоянного надзора |
Оценка | Человек принимает результат и решает, что выпускать, что переделывать и что отправить в корзину |
Здесь есть психологическая цена. Отмазок становится меньше. Сложнее объяснить, что проект не взлетел из‑за отсутствия разработчика, дизайнера или аналитика. Всё чаще вопрос возвращается к выбору цели, качеству решения и способности довести работу до живого результата.
И всё же я не хочу убирать из жизни любое трение. Иногда полезно самому написать текст, прочитать сложную книгу без краткого пересказа, порисовать, приготовить еду или прожить несколько часов без телефона. Усилие формирует внимание, терпение и вкус. Если автоматизировать каждую сложность, можно сэкономить время и потерять человека, который умеет им распорядиться.
Моя версия AI‑native проста. Исполнение живёт в системе, а цель, суждение, вкус и ответственность остаются у человека.
Я не знаю, какой интерфейс или модель победит через год. Но уверен в направлении. Выиграет человек, который глубоко понимает своё дело, умеет самостоятельно заходить в соседние области и строит процессы, становящиеся умнее после каждого запуска.
Не все разработчики исчезнут. Но рынок уже начал пересчитывать, сколько результата должен давать один человек. Вайбкодер рано или поздно сломает прод. Разработчик с агентами сломает старую норму производительности.
