Этот текст — для тех, кто по-прежнему косится на agentic coding с недоверием. И для тех, кто уже не спорит с трендом, но всё ещё, если честно, не до конца понимает, что он сделает с их профессией через год-два. Заголовок, да, отсылает к Zen of Python Тима Питерса. Только я не гуру и не проповедник. Скорее человек, который пытается спокойно, без фанфар, зафиксировать момент: где мы вообще находимся и куда всё это катится. Последний год я почти каждый день работаю с coding agents, а ещё помогаю командам внедрять AI-агентов и автоматизацию так, чтобы не развалить надёжность, безопасность и здравый смысл по дороге.

1. Разработка ПО в старом смысле умирает
2. Код стал дешёвым
3. Рефакторинг больше не драма
4. И техдолг — тоже не приговор
5. Все баги теперь ближе к поверхности
6. Делайте короткие циклы обратной связи
7. Почти любой стек теперь вам по зубам
8. Агенты нужны не только для написания кода
9. Главное узкое место контекста — у вас в голове
10. Стройте так, будто мир завтра снова поменяется
11. В споре Buy vs Build всё чаще побеждает Build
12. Быстрый мусор всё равно остаётся мусором
13. ПО — обязательство, продукт — актив
14. Защитные рвы стали дороже и хитрее
15. Проектируйте продукты для агентов
16. Заранее думайте о режимах отказа

Разработка ПО в старом смысле умирает

Если совсем по-простому: сегодня уже можно не писать код руками на постоянной основе. Вообще. При нормальной постановке задачи coding agents закрывают огромный пласт программной работы сами.

Но это не значит, что инженеры больше не нужны. Вот уж нет. Просто центр тяжести сместился. Роль разработчика всё меньше про набор символов в редакторе и всё больше про формулировку задачи, сбор контекста, ограничения, проверку результата и инженерную ответственность. Не романтично? Может быть. Зато честно.

Предельная стоимость кода падает почти до смешного быстро. А когда код становится дешёвым, меняется не одна метрика — меняется вся экономика разработки, архитектуры и архитектуры AI-агентов в целом.

Код стал дешёвым

Экономика software, по сути, перевернулась.

Когда реализация почти ничего не стоит, она перестаёт быть главным ограничением. Можно параллельно собрать пять, десять, пятнадцать вариантов решения. А вот принять по ним решения, провалидировать, протестировать, согласовать с продуктом, безопасностью, эксплуатацией и потом ещё выпустить — это уже совсем другая история. И тут начинается весёлое.

Стоимость задержки переехала. Раньше она жила в часах и днях работы разработчиков. Теперь она сидит в других местах: в неясных требованиях, в product decisions, в security review, в пользовательском тестировании, в релизных процессах, в операционных рисках. Агенты умеют накачать пайплайн кодом так быстро, что эти очереди просто распухают. Незавершёнка растёт. Lead time — тоже. И, ну да, задержка становится дороже, а не дешевле.

Отсюда и новый приоритет: максимальный эффект дают не задачи «написать ещё кусок кода», а всё, что сокращает путь от «мы можем это собрать» до «мы можем этому доверять». Тесты. Evals. Guardrails. Observability. Внятные acceptance criteria. Всё это уже не бюрократия, а инфраструктура скорости.

И да, агенты могут помогать и здесь — не только в кодинге, но и в анализе, проверках, автоматизации процессов. Если тема вам близка, посмотрите, как это обычно решается через разработку AI-агентов для бизнеса, а не только для IDE.

Рефакторинг больше не драма

Цена смены решения упала. Сильно.

То, что раньше ощущалось как архитектурный брак на годы, теперь чаще выглядит как временный выбор. Выбрали React, а через пару месяцев поняли, что промахнулись? Неприятно, конечно. Но уже не смертельно. Агент может переписать проект, мигрировать слой за слоем, а вы — сосредоточиться на том, чтобы не потерять смысл и качество.

И тут есть важный, чуть контринтуитивный момент: несовершенное решение теперь часто полезнее идеального плана. Черновая reference implementation даёт агенту куда более плотный контекст, чем безупречная, но абстрактная спецификация. Модели, как ни крути, лучше работают с конкретикой. С артефактами. С тем, что можно потрогать, пусть и кривовато.

Быстрая итерация стала нормой. Не праздником, а рутиной. За последние месяцы мы несколько раз полностью пересобирали CMS с разной архитектурой — и каждый раз яснее видели, что нам действительно нужно. Иногда только через переделку и понимаешь, где была настоящая задача. Такая уж штука.

Когда код дешёв, можно позволить себе больше маленьких ставок. И это, честно говоря, освобождает.

И техдолг — тоже не приговор

Оправданий для залежавшихся зависимостей и пропущенных security patches стало заметно меньше. Обновить библиотеку, мигрировать API, привести код к современным паттернам — всё это теперь часто действительно в пределах одного хорошего промпта. Или нескольких, если без магии.

Подрезайте кодовую базу регулярно. Обновляйтесь смелее. Держите поверхность системы чистой — не стерильной, нет, а именно чистой. Это разные вещи.

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

Особенно если речь идёт о рисках в проде и о безопасности AI-агентов, где «потом поправим» обычно заканчивается не очень весело.

Все баги теперь ближе к поверхности

Закон Линуса говорил: «при достаточном количестве глаз все баги поверхностны». Что ж, теперь этих «глаз» у нас с избытком. Иногда даже чересчур.

Можно дать код одной модели на ревью. Потом второй. Потом попросить обеих предложить исправления. И забавно, но они нередко находят разные классы проблем. Одна цепляется за логику, другая — за крайние случаи, третья внезапно замечает дыру в безопасности. Не всегда. Но часто.

Конечно, баги не испаряются по щелчку. Агенты не идеальны, и верить им на слово — идея так себе, если мягко. Но практический лимит теперь не в количестве ревьюеров. Он в качестве и плотности ваших feedback loops.

Отсюда неприятная, но полезная мысль: понимать кодовую базу построчно уже не обязательно, а вот уметь проверять, где модель врёт уверенно и красиво, — обязательно. Иначе будет беда. Тихая, липкая, дорогая беда.

Делайте короткие циклы обратной связи

Иногда агент действительно может выдать решение one-shot. Бывает. Но редко.

Да, мы видели сценарии, где агент за один проход собирал полностью кастомный маркетинговый сайт. Красиво, быстро, почти без вмешательства. Но это скорее исключение, чем правило. В реальной жизни лучшие результаты приходят там, где агент двигается итеративно — маленькими шагами, с понятной целью и с постоянной обратной связью.

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

Второй цикл — CI. Третий — логи. Четвёртый — визуальная проверка UI. Пятый — evals на реальных сценариях. И так далее. Чем богаче среда обратной связи, тем выше шанс, что итерации будут сходиться к корректности, а не уезжать в правдоподобную чепуху.

Скорость без обратной связи — это не ускорение. Это занос на мокрой дороге.

Почти любой стек теперь вам по зубам

Если по выбранному стеку есть достаточно данных и практики в мире, агенты обычно чувствуют себя в нём вполне уверенно. А раз код в значительной степени пишете уже не вы, личная привязанность к одному-единственному стеку теряет былую священность.

Не ограничивайте себя только тем, что знаете руками. Концептуальное понимание переносится дальше, чем кажется. Иногда намного дальше.

Не хватает терминов? Не уверены в специфике домена? Попросите агента быстро ввести вас в курс дела, собрать карту решений, объяснить компромиссы. Порог входа в незнакомые экосистемы стал ниже. Не нулевой — не надо сказок, — но заметно ниже.

Агенты нужны не только для написания кода

Кодинг — это лишь первая, самая очевидная остановка.

AI-агенты полезны в business analysis, UX-исследованиях, инфраструктуре, операциях, маркетинге, аналитике, документообороте и даже в скучных бухгалтерских workflow. Там, где раньше задача упиралась не в сложность, а в то, что до неё «никак не доходили руки», агенты часто оказываются неожиданно эффективны.

Я, например, однажды перенёс сразу несколько WordPress-блогов с неоправданно дорогого хостинга на Hetzner буквально за считаные минуты — хотя до этого откладывал миграцию месяцами. И причина задержки была не технической. Просто не хватало внимания, энергии, фокуса. Знакомо, да?

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

Главное узкое место контекста — у вас в голове

Context engineering стал лучше. Инструменты — тоже. Память, RAG, внешние знания, оркестрация — всё это заметно продвинулось вперёд, и если вам нужна такая инфраструктура, обычно её собирают через агентную память и RAG.

Но при параллельной работе нескольких агентов реальный bottleneck часто не в токенах и не в окне контекста. Он в человеке. В вас. В вашей способности удерживать картину целиком.

Нужно помнить, кто что делает. Какие предположения уже были приняты. Где агент срезал угол. Где он, наоборот, перестраховался. Какие вопросы задать дальше. Какая ветка вообще ещё жива. Это всё не glamorous work, но именно оно становится дефицитным ресурсом.

Ограничение теперь не только в модели. Ограничение — в когнитивной координации. И это, если честно, довольно странное ощущение.

Стройте так, будто мир завтра снова поменяется

Новые модели выходят постоянно. Новые возможности — тоже. Фреймворки, подходы, интерфейсы, практики, требования к надёжности. Почва под ногами шевелится почти ежедневно.

Одна модель лучше рассуждает. Другая лучше пишет код. Третья сильнее в переводе, четвёртая — в инструментальном использовании. Сегодня ваш workflow выглядит разумно, а через месяц уже кажется тяжеловатым. Это нормально. Немного раздражает, но нормально.

Поэтому гибкость должна быть встроена и в процессы, и в продукт. Не как красивое слово на слайде, а как инженерный принцип: возможность быстро экспериментировать, менять компоненты, адаптировать поведение агентов, пересобирать контуры автоматизации без капитального ремонта всей системы.

В споре Buy vs Build всё чаще побеждает Build

Когда код был дорогим, покупка готового решения почти всегда выглядела разумнее. Сейчас расчёт меняется. И меняется быстро.

Каждый внешний API, каждый SaaS, каждый сервис теперь вызывает вопрос: а не проще ли нам собрать это внутри? Не всегда. Но всё чаще — да.

Например, если команде нужен QA-агент, который делает full-page screenshots живых сайтов, можно купить API. А можно развернуть Playwright в AWS Lambda, подогнать под свои сценарии, встроить проверки, усилить контроль и не зависеть от чужих ограничений. Иногда второй путь оказывается не только дешевле, но и надёжнее в долгую.

Это не манифест против SaaS, конечно. Поддержка, масштаб, безопасность, SLA и зрелость поставщика никуда не делись. Но множество средних и небольших сервисов, которые раньше было проще купить, теперь реально находятся в зоне досягаемости собственной команды. Особенно если у вас выстроена мультиагентная система и понятная инженерная дисциплина.

Некоторые называют это концом SaaS. Я бы не спешил. Но трещины в старой логике уже слышны — и довольно отчётливо.

Быстрый мусор всё равно остаётся мусором

Скорость пьянит. Это правда. И в этом же её подвох.

Теперь можно генерировать тонны кода почти без трения. Но количество строк никогда не было хорошей метрикой прогресса. И не станет. Хоть сто раз назови это acceleration.

Да, рефакторинг подешевел. Но ещё дешевле — как можно раньше понять, что вы вообще идёте не туда. Иногда лучший результат недели — это не новая фича, а вовремя убитая плохая идея. Звучит грубо, но так и есть.

Дисциплина в эпоху AI нужна не меньше, а больше. Потому что соблазн наделать лишнего вырос в разы. И, ну, руки чешутся. У всех.

ПО — обязательство, продукт — актив

Любое software требует сопровождения. Оно ест время, деньги, внимание, инфраструктуру, нервы. Активом оно становится только тогда, когда создаёт ценность для реальных пользователей или для бизнеса. Всё остальное — обязательства, аккуратно завёрнутые в красивый интерфейс.

Это было правдой всегда. Просто сейчас об этом легче забыть, потому что создавать стало слишком просто. Почти опасно просто.

Добавлять функции теперь невероятно легко. Поэтому сопротивляться этому желанию стало сложнее. Но сопротивляться всё равно нужно. Делайте то, чем пользуются. Удаляйте то, чем не пользуются. И не влюбляйтесь в собственный backlog — он не ответит взаимностью.

Защитные рвы стали дороже и хитрее

Функциональные разрывы закрываются стремительно. То, что раньше копировали годами, теперь могут воспроизвести за месяцы. А то, что занимало месяцы, иногда повторяют за дни. Неприятный факт, но лучше смотреть ему в лицо.

Набор фич больше не тянет на устойчивый moat. Слишком легко догнать. Слишком быстро стирается преимущество.

Защитные рвы смещаются в другие зоны: дистрибуция, данные, бренд, сетевые эффекты, регуляторика, интеграция в экосистемы, доверие, соответствие требованиям. Да-да, скучные вещи снова становятся самыми важными. Иронично.

Барьер входа падает. А барьер защищаемости — наоборот, растёт. Особенно в корпоративном сегменте, где AI compliance и соответствие требованиям уже не факультатив, а часть сделки.

Проектируйте продукты для агентов

Появляется новая иерархия. Внизу — модели. Над ними — агенты. Ещё выше — сервисы, с которыми эти агенты работают.

Пока что агенты в основном пользуются сервисами, созданными для людей. Это терпимо, но неэффективно. Следующий логичный шаг — сервисы, спроектированные сразу под агентное взаимодействие: со структурированным контекстом, machine-readable интерфейсами, понятными ограничениями, явными правами доступа и предсказуемым поведением.

Иногда для этого хватает markdown endpoint. Иногда нужен полноценный agent-first слой продукта. А иногда приходится пересматривать вообще всё: API, модель надёжности, метрики, сценарии доступа, логику разрешений. Небольшая переделка? Ха. Не всегда.

Agent-first — это не просто выбор инструмента. Это продуктовое и архитектурное решение. Оно меняет то, как вы проектируете интерфейсы, как думаете о пользователе и как строите цифровые сервисы в мире, где пользователем всё чаще становится не человек, а агент.

AX — новый UX. Коротко, но, похоже, надолго.

Заранее думайте о режимах отказа

Не путайте компетентность с безошибочностью. Это разные вещи. Очень разные.

Если продолжить инженерную метафору: ваша задача уже не в том, чтобы класть кирпичи самому. Ваша задача — убедиться, что мост не рухнет, когда по нему поедут первые грузовики. И когда поедут сотые — тоже.

Агенты будут ошибаться. Будут сходить с курса. Будут вносить тонкие дефекты, которые сразу не заметишь. Будут создавать уязвимости. Один из моих, например, однажды попытался закоммитить .env в git. Мелочь? Ну да, конечно. Прямо подарок.

Поэтому думайте на шаг вперёд: где это может сломаться, что может утечь, какие данные раскроются, какие тихие предположения агент уже сделал без вашего ведома. Игра «а что если» здесь не паранойя, а базовая гигиена.

Стройте guardrails. Автоматизируйте проверки. Жёстко ограничивайте permissions. Изолируйте среды. Добавляйте мониторинг. Делайте rollback банально простым. Проектируйте системы, которые ожидают сбой и умеют деградировать аккуратно, а не эффектно.

Именно здесь проходит граница между просто software development и настоящей software engineering.

Чем я занимаюсь

Я работаю с engineering- и product-командами, которые внедряют агентов в реальную практику. Цель простая: выпускать быстрее, не опуская планку качества, надёжности и безопасности.

Обычно я помогаю в двух направлениях.

Agent-first software engineering
Мы встраиваем агентов в систему работы команды так, чтобы они были не игрушкой и не модной нашлёпкой, а рабочим элементом процесса. Проектируем workflows, guardrails, контуры проверки, вспомогательные инструменты и правила эксплуатации, чтобы делегирование задач агентам было управляемым, а не азартным.

Если вы хотите внедрить coding agents в операционную практику и не превратить codebase в казино, это вполне решаемо.

Agent-first product strategy
Я помогаю компаниям переводить продукты от human-centric интерфейсов к agent-accessible, а там, где это действительно оправдано, — к agent-first модели. Это включает прояснение ролей агентов, ограничений, сценариев доступа, требований к API, permissions, надёжности и всей продуктовой поверхности, которая должна поддерживать новый тип пользователя.

Обычно на выходе получается roadmap по agent access, operating model и приоритизированный набор продуктовых изменений, которые делают агентов пользователем первого класса — без лишней мистики и без маркетингового дыма.

Я сооснователь WhiteBoar, где AI-агенты помогают создавать бренд и запускать визуально сильные маркетинговые сайты с профессиональным многоязычным контентом за минуты, а не за месяцы. Связаться со мной можно по адресу [email protected].