Утро. Уважаемый разработчик приходит на работу. Открывает IDE. Создаёт новый класс. Потом DTO. Потом mapper. Потом repository. Потом service. Потом controller. Потом пишет тесты. Восемь часов напряжённой интеллектуальной деятельности — и ноутбук закрывается с приятным ощущением хорошо выполненной работы. На свет родились семьсот строк. Хороших. Собственноручных.
А в соседней комнате другой человек утром описал задачу агенту. Дал ему репозиторий, архитектурные ограничения, тестовый контур и критерии приёмки. К обеду посмотрел pull request. Отправил агента исправить три замечания. После кофе принял результат.
Первый написал семьсот строк кода. Второй — примерно двадцать строк инструкций.
И вот теперь надо задать один неприличный вопрос: кто из них сегодня программист?
Арифмометр рядом с компьютером
Я не хочу начинать с того, что один из них — реликт, а второй — пророк. Правда обычно устроена скучнее. Но давайте честно: в две тысячи двадцать шестом году вручную писать большую часть прикладного кода примерно так же странно, как вручную сводить бухгалтерский баланс на арифмометре, когда на соседнем столе стоит компьютер.
Человек может это делать. Может делать очень хорошо. Может испытывать профессиональную гордость от красиво выписанных классов, SQL-запросов, DTO, тестов, REST-клиентов и конфигураций. Рука у него, не сомневаюсь, твёрдая, а чувство прекрасного — острое.
Но возникает неприятный вопрос: а зачем?
Если разработчик по-прежнему измеряет свою профессиональную ценность количеством собственноручно написанного кода, то, возможно, он просто продолжает оптимизировать деятельность, которая перестала быть главным дефицитом. Это как гордиться умением быстро и аккуратно точить гусиные перья в эпоху печатных машинок. Навык настоящий, труд настоящий — а вот дефицит уже не там.
Человек с отвёрткой посреди конвейера
Посмотрите, чем заняты эти два человека на самом деле.
Первый управляет кодом. Он знает синтаксис, framework, API, паттерны, IDE, debugger, библиотеку — и знает, как правильно написать очередной service. Это почтенное знание. Оно не обесценилось ни на рубль.
Но второй управляет фабрикой по производству кода. Он проектирует harness, контекст, правила, инструменты, доступ агента к репозиторию, тестовый контур, quality gates, архитектурные ограничения, процесс декомпозиции, цикл «задача → реализация → тест → review → исправление», допустимую степень автономии, критерии остановки и способ восстановления после ошибки.
Главный инструмент разработчика постепенно перемещается: из IDE — в систему управления агентами.
Вчера хороший программист умел писать хороший код. Сегодня хороший программист умеет сделать так, чтобы хороший код появлялся без его непосредственного участия.
IDE никуда не исчезает, как отвёртка не исчезла после появления сборочного конвейера. Просто странно считать человека с отвёрткой главным производственным механизмом автомобильного завода. Отвёртка осталась. Просто перестала быть тем, чем измеряется профессия.
Harness — это не «хороший prompt»
Здесь обычно вступает хор скептиков: «Ну да, знаем мы ваш agentic — это когда пишешь промпт подлиннее и ждёшь чуда». Нет. Это примерно как сказать, что завод — это «очень большой гаечный ключ».
Prompt — лишь крошечная часть. Harness — это среда, внутри которой агент вообще способен работать полезно и относительно предсказуемо. Инструкции проекта. Архитектурные правила. Репозиторий. Документация. Conventions. Линтеры. Тесты. Build. Sandbox. Доступные инструменты. MCP или иные интерфейсы к внешним системам. История решений. Описание модулей. Правила безопасности. Definition of done. Ограничения на изменение определённых частей системы.
Хороший разработчик нового типа не объясняет агенту каждый раз всё заново. Он строит такую среду, в которой агенту трудно сделать неправильно и легко сделать правильно.
Это, пожалуй, главный тезис всего текста. Остальное — следствия.
Секретарша XXI века
Дальше — следующий уровень. Перестать использовать AI как очень дорогой autocomplete.
Вы наверняка видели эту картину. Человек покупает доступ к сильнейшей модели. Открывает чат. Пишет: «Напиши Java-класс UserService». Получает код. Копирует в IDE. Правит руками. Потом спрашивает: «А теперь напиши unit test». Копирует обратно. И так — полдня, методично, как на конвейере.
Это не agentic development. Это секретарша XXI века, которой разработчик диктует код кусочками. Дорогая секретарша. С очень хорошим почерком и абсолютным непониманием, куда этот кусочек встанет в общую картину.
Настоящий переход начинается тогда, когда агент получает задачу другого уровня. «Реализуй issue N. Изучи существующую архитектуру. Не меняй публичный API. Запусти тесты. Добавь недостающие. Проверь линтер. Покажи diff. Если тесты падают — исправь. Если обнаружишь архитектурное противоречие — остановись и вынеси его на решение человеку».
И вот только тогда человек начинает заниматься не набором текста, а управлением производственным циклом.
Идите пить кофе
Про кофе из заголовка надо сказать отдельно, потому что эта шутка по ходу дела меняет смысл.
В начале она звучит как обещание халявы: настроил агента — иди пить кофе, пусть железный коллега пашет.
В середине выясняется, что кофе пить особенно некогда. Потому что вместо написания одного метода человеку теперь приходится думать: правильно ли сформулирована задача; правильно ли разделена система; достаточно ли тестов; сможет ли агент повредить соседний модуль; какую информацию ему дать, а какую не давать; где должна остановиться автономия; какие решения машина вообще не должна принимать; как несколько агентов будут согласовывать изменения; как проверять результат; что вообще считать доказательством корректности.
Получается неприятный парадокс. AI избавляет программиста от необходимости много кодировать — но совершенно не избавляет от необходимости много думать. Возможно, даже наоборот.
Кофе, кстати, остывает. Но это уже другая проблема.
Кого мы тут, собственно, высмеиваем
Сразу оговорюсь, чтобы не быть понятым превратно. Мишень этого текста — не новички и не люди, которые только учатся программировать. Учиться надо так же, как учились всегда: руками, до крови в подушечках пальцев. Иначе не будет того самого понимания, без которого всё остальное — имитация.
Мишень другая. Это профессиональная идентичность, которая звучит как: «Настоящий программист обязан писать код сам». Вот с ней и поспорим.
Идея, что ручное производство артефакта обязательно благороднее автоматизированного, не выдерживает никакой проверки. Архитектор не обязан сам класть кирпич. Инженер-конструктор не обязан собственноручно вытачивать деталь. Бухгалтер не обязан складывать числа столбиком. Фотограф не проявляет каждую плёнку в ванной. Системный администратор давно не конфигурирует тысячу серверов по SSH вручную. DevOps не доказывает профессионализм тем, что отказывается от Terraform и пишет конфигурацию каждого узла руками.
Почему же программисту вдруг должно быть стыдно не писать код?
А теперь — в другую сторону
Только, пожалуйста, не выводите отсюда лозунг «теперь любой человек нажмёт кнопку, и AI всё сделает». Вот его как раз и надо высмеять следующим.
Чем больше работы отдаётся агентам, тем важнее становятся вещи, которые никакая кнопка не отменит. Архитектура. Постановка задачи. Понимание системы. Инженерные ограничения. Тестируемость. Observability. Безопасность. Умение читать чужой код. Понимание причинно-следственных связей. Способность определить, что результат вообще правильный.
Плохой программист с AI может производить плохой код быстрее. Очень плохой программист с fleet of agents может производить плохую систему с промышленной производительностью.
И вот отдельная мысль, которую стоит произнести вслух: скорость генерации перестала быть преимуществом, если скорость проверки осталась человеческой. Машина научилась строить быстрее, чем мы умеем проверять. Значит, следующий bottleneck — не генерация, а verification. И это уже не про модели, а про нас.
Новый вопрос на собеседовании
Раньше на собеседовании могли спросить: «Как вы реализуете это на Java?» Хороший вопрос. Был.
Теперь всё интереснее спрашивать: «Как вы построите процесс, в котором несколько агентов смогут реализовывать такие изменения безопасно и независимо?» И дальше — что дать агенту в контекст; как разделить ответственность; какие проверки автоматизировать; где поставить human gate; как бороться с context drift; как хранить архитектурную память; как предотвращать локально правильные, но системно неправильные решения.
Это уже другой уровень инженерной деятельности. Не выше и не ниже предыдущего — просто другой.
Короткая экскурсия в историю
Проведём линию. Машинные коды. Assembler. Языки высокого уровня. Библиотеки. Frameworks. Low-code абстракции. Copilot. Coding agents. Agentic engineering.
На каждом этапе кто-нибудь обязательно говорил: «Настоящий программист должен понимать, что происходит на уровень ниже». И это была правда.
Но из этого почему-то совершенно не следовало: «Настоящий программист обязан всё время работать на уровень ниже». Человек, способный написать на assembler, не обязан писать на assembler CRM. Человек, способный вручную реализовать REST endpoint, не обязан вручную реализовывать пятисотый REST endpoint.
Понимать — обязательно. Делать руками — уже нет.
Пять агентов и одна распределённая некомпетентность
Пойдём ещё на слой выше, и картина станет почти организационной.
Один агент исследует репозиторий. Другой предлагает изменение. Третий пишет тесты. Четвёртый делает review. Пятый проверяет документацию. Звучит как мечта — целая команда виртуальных программистов за цену одного кофе.
Но не обманывайтесь: это не магия. Без хорошо устроенного процесса пять агентов способны устроить distributed incompetence значительно быстрее, чем один человек. Каждый по отдельности будет прав, а вместе они соорудят систему, в которой левая рука не знает, что пишет правая, и обе уверены, что именно так и задумано.
Поэтому новый senior — это, в некотором смысле, человек, который строит организацию. Из людей, моделей, инструментов и автоматических проверок. Из процессов, которые не разваливаются, когда один из участников ошибается. Из границ, внутри которых ошибка дёшева, а за пределами — невозможна.
Экономика не прощает сантиментов
И под конец — немного неловкой экономики.
Раньше дорогим ресурсом был квалифицированный человеко-час написания кода. Теперь стоимость производства очередной строки стремительно уменьшается. Зато дорожают другие вещи: правильная постановка; архитектурное решение; знание предметной области; доступ к контексту; проверка; ответственность; понимание бизнеса.
Из этого следует неприятный вывод. Рынок может продолжать высоко ценить разработчиков — но совсем не обязательно будет высоко ценить сам акт написания программного текста. Разработчик может остаться. А «кодер» — действительно оказаться профессией предыдущего технологического слоя.
Не потому что код стал не нужен. А потому что он перестал быть той вещью, за которую платят редкость.
Утро, четыре строки и никакого стыда
Вернёмся к утренней сцене, с которой всё началось.
Уважаемый программист допил кофе. Открыл pull request. Посмотрел, что сделали агенты. Отклонил одно архитектурное решение. Исправил постановку. Запустил новый цикл. Сам написал четыре строки кода — потому что так оказалось быстрее.
И совершенно не испытал по этому поводу ни гордости, ни стыда.
Потому что его работа состояла не в том, чтобы писать код. Его работа состояла в том, чтобы система стала правильнее.
Так что если вы сегодня восемь часов самозабвенно кодировали — это, конечно, прекрасно. Труд честный, уважение заслуженное.
Но, может быть, завтра утром, перед тем как открыть IDE, стоит сначала спросить себя об одном:
А почему это вообще должен делать я?