«Конец программирования» — так обозвал свою статью в блоге Пол Дикс, создатель InfluxDB. Поводом стала новость о том, что Bun переписали с Zig на Rust: один разработчик с пререлизной моделью Claude Fable и армией агентов (на пике около 64) за 11 дней прогнал механический порт с одного языка на другой. Исходник — 500k строк Zig без комментариев; в merge ушёл diff порядка +1 миллиона строк. Масштаб поражает.
Bun — это среда выполнения и тулкит для JavaScript/TypeScript, современная альтернатива Node.js и Deno. В декабре 2025 Anthropic купил Bun — в том числе как инфраструктуру вокруг своего Claude Code; проект остаётся open source.
Подобная миграция раньше заняла бы множество человеко-часов и команду инженеров, хорошо разбирающихся в системном программировании на достаточно нишевых Zig и Rust (ну, согласитесь, это вам не Java и JavaScript).
Но «конец программирования» — ложный вывод из демо и громких миграций. Мертва роль кодера-переводчика: человека, который прочитал документацию и напечатал на клавиатуре код как перевод требований в язык, понятный машине.
Эту модель ИИ автоматизировал. Она мертва. Не мертва инженерия. Скорость генерации — ещё не готовность системы.
Вайб и нейрослоп
Люди с GPT Astra показывают невероятные 3D-демо-игры, агенты клепают клоны привычных редакторов и досок, а Miro на фоне этого уходит к Bending Spoons за всего за $1 млрд — холдинг, который скупает умирающие стартапы. А когда-то ее стоимость оценивали в 20 млрд и пророчили будущее Figma, но LLM с легкостью генерит свои собственные решения по типу досок или замен трекеров, вроде Jira. Зачем тогда покупать?
Смотря на это безобразие, легко сделать ошибочный вывод: инженеры больше не нужны, и с лучшей подпиской на последнюю модель можно сделать всё что угодно.
На деле всё это может вылиться в мусорный и багоопасный нейрослоп. Задача переписать решение с одного языка на другой не выглядит как проектирование с нуля — и в этом главный нюанс. У Bun был оракул: тот же test suite, те самые quality gates. Это мерило успеха или провала работы LLM. Сейчас модное слово для обвязки вокруг агента — harness: всё, что мы строим, чтобы он выдал ожидаемый результат. Без gates миллион строк — не подвиг, а риск.
ИИ-агент генерирует много кода и лучше ориентируется в огромном контексте — в этом он превосходит типичного «кодера». Вопрос цены токенов и электричества остаётся, но он вторичен рядом с вопросом: как проверить, что сгенерированное вообще то, что нужно.
Недетерминизм
Самая главная проблема моделей — они недетерминированы. Когда мы раньше писали код, мы были уверены: вот этот алгоритм из миллиона прогонов даст один и тот же результат — определённый input даёт определённый output. Так работает математика, так работает физика, так работала информатика. ИИ выдаёт различный результат на одни и те же входные данные. С этим инженеры раньше почти не сталкивались: непредсказуемым в разработке ПО был человек, не машина.
Компьютерная инженерная система должна быть детерминированной, предсказуемой, точной. Как добиться этого с ИИ? Ответ скучный и старый как мир: тесты.
В инженерных кругах любят придумывать новые слова, но очень часто это упаковка старых практик. AI Evals как часть harness — это просто quality gates: те же проверки кода и логики, которые инженеры годами настраивали до этого.
У меня есть старая статья, где я конспектировал различные виды автоматизированных тестов и упоминал о TST — Total System Testing, тотальное покрытие системы тестами. Тогда я говорил, что это сказка, к которой лучше не стремиться: такие наборы тяжело поддерживать. Прагматичнее баланс — пирамида или трофей тестирования, покрытие где-то около 80%.
Сейчас всё немного изменилось: тесты тоже генерит агент, писать и чинить их стало дешевле. Если тест поломался — перегенерили. Кажется, что можно стремиться и к плотному покрытию: модульные, интеграционные, системные. Плюс простой — имея такие gates, мы меньше боимся недетерминированности агентов. Оговорка конечно остаётся: дешёвые тесты это не значит полезные. Мусорный сгенерированный suite тоже нейрослоп, только с другой стороны.
Ещё один ложный успокаивающий жест — /multi-model-review: пусть одна модель (или субагент) ревьюит результат другой. Это не заменяет quality gates. Там тот же недетерминизм: модель проверяет модель, и на выходе снова вероятностный текст, а не формальный оракул. Циклы вроде Ralph loop, в которые так уходит кодогенерация, иногда просто неоправданны: агенты как машины пытаются перебрать все случаи и проблемные кейсы — даже когда это не нужно. Нет механизма компромисса. Эту роль раньше выполнял человек: он брал на себя ответственность за угловатости системы и её несовершенство. ИИ же стремится к оверинжинирингу как к точке «совершенства» и перфекционизма — и без внешней рамки может крутиться в этом цикле бесконечно.
Сначала спека
Если системы ещё нет, а мы хотим её разработать с помощью ИИ, не умея программировать, сначала нужно описать ожидания. Желательно — в виде тестов, которые потом проверят результат работы агента.
Тут всплывает подход, который описал Кент Бек, — Test-Driven Development. Сколько лет мусолят эту тему? И как будто в природе этот зверь не встречается: в 90% команд тесты пишут постфактум. Я сам когда-то был поборником TDD, пиарил его — и потом забил: против течения тяжело плыть. При этом Бек подход не придумал: нашёл в инженерной книге отца. В зачатках XP это называлось Test-First — сначала тест, потом реализация. В этом невероятный прагматизм, который сейчас заиграл новыми красками.
Всё это трансформировалось потом в Behavior-Driven Development: сначала формулируем поведение системы, из него — тесты, потом код. Мне кажется, BDD — фактический эквивалент того, что сейчас пиарят как Spec-Driven Development. Просто слова поменяли. Specification-Driven — тот же уход в DSL, описывающий поведение. Нам нужна сначала спека.
Появляются даже фреймворки, как описывать спеки — например OpenSpec. Забавно: раньше были фреймворки на языках программирования, на фронте и бэке. Теперь — фреймворки, чтобы правильно описать markdown: глобальная спека, локальная, ещё какая-то. Смешно, не смешно — но это реальность. И в этом есть прагматизм: описать в балансе — не слишком подробно и не слишком на верхнем уровне — то, что хотим получить. На основе спецификации ИИ генерит код. В самом простом варианте это скилл /plan, который предшествует реализации и сохраняет контекст постановки. Поэтому опытные инженеры знают: ставить задачу агенту надо со спеки.
Инженерия - это процесс от проектирования, дизайна и планирования до реализации, отладки и тестирования.
Реализация и отладку, то что посередине, теперь на себя забирает ИИ. Проектирование и планирование фундаментальные фазы — это все еще на инженере-программисте.
Чтобы проверить работу, нужны точные тесты — желательно до того, как что-то уйдёт в продуктив. Желательно, чтобы они описывали то поведение, которое мы хотим от системы. Старые практики — модульные, интеграционные, e2e, BDD, TDD — остаются актуальны даже в эпоху кода, который уже не пишут люди.
Вот тут должна появиться реклама инфоцыгана, который продаёт курсы по вайбкодингу. Раньше такие люди учили JavaScript и React — хоть какой-то уровень инженерии всё же требовался. Теперь будут учить правильно писать markdown-спеки на русском или английском. Лучшее обучение по-прежнему одно: брать и делать. Книжки по React и раньше выглядели кринжево; книжки «как правильно вайбкодить markdown» будут апофеозом кринжатины в инженерии.
AGENTS.md - Нам нужна химия, а не алхимия
Всё, что касается обвязки из правил на естественном языке, — чистой воды алхимия, подкреплённая в лучшем случае индивидуальными субъективными выводами. Люди всё так же ищут серебряную пулю — только теперь в markdown-файлах, а не в шаблонах проектирования и алгоритмах на формальном языке. Правда в том, что нет и не будет универсального текста для AGENTS.md. Даже попытки слепить универсальные промпты и скиллы вроде ponytail «на все проекты» — провальная идея.
Нужно формировать правила под каждый конкретный проект. AGENTS.md должен быть сбалансированным: не огромным и не пустым, только базовая, но специфичная проекту информация. Всё остальное уходит в rules — правила, к которым агент подчиняется при определённой работе. Модели учились на открытых источниках, и в некоторых областях они слабы или просто упускают важное, если явно не указать. Безопасность, доступность — половина интернета имеет проблемы с accessibility, модель училась на этих примерах, поэтому явные правила в этой категории обязательны.
Без явно заданной в правилах и спецификации архитектуры непонятно, как агент пойдёт строить приложение: какие библиотеки выберет, писать своё или переиспользовать, как разделить доменные модели (Domain-Driven Design). Даже простое: Tailwind или SCSS Modules? Это техническая информация, которую человек без понимания технологий не сформулирует.
Сгенерировать простой сайт-визитку в сдержанном дизайне с приятным интерфейсом — это одна задача, разрабатывать сложную веб-систему с сотнями отдельных экранов на консистентной дизайн системе — это другая задача. Нужна формализация дизайн системы, порядок в Figma, MCP-коммуникация к трекеру, где описания задач и к Figma, где есть макеты. Формализация стэка и библиотек, а также screenshot-тесты.
Можно ли не формулировать? Пускай ИИ сам решит. ИИ ничего не решает — он делает по образу и подобию того, что превалирует в весах его знаний. Велик риск быстро прийти к энтропии, где система превратится в один большой и неповоротливый нейрослоп.
Подобно тому, как вечная борьба с энтропией приводила разработчика к необратимой встрече с рефакторингом, необратима и постоянная переработка правил агента и текста в rules и AGENTS.md. Harness нельзя упаковать в фреймворк по типу React и переиспользовать «как есть».
Это, кстати, одна из услуг будущего: раньше нанимали сервисную компанию, чтобы трансформировать легаси; по тому же принципу будут нанимать инженеров, чтобы привести в порядок нейрослоп, который на коленке склепали непрограммисты в желании сэкономить на инженерах.
Что выживает
Принципы вроде SOLID, YAGNI, KISS, DRY, ETC по-прежнему помогают формулировать верные ожидания — и от системы, и от обвязки, которая её разрабатывает.
Нужно ли учить конкретный язык? Наверное, нет: языки годами эволюционировали ближе к DSL, чтобы быть читаемыми для человека, оставаясь формальными. Сейчас они могут быть нечитаемыми, но оптимальными — LLM переведёт. Как переводит русский на английский и обратно.
Но архитектурное и инженерное мышление, принципы, подходы в дизайне — это всё будет нужно. Нужны высококвалифицированные архитекторы и оркестраторы систем: те, кто может правильно задать вопрос, сформулировать мысли и ожидание. Исполнители, не умеющие думать, нужны в меньшей степени.
Вернёмся к Bun. Миллион строк за одиннадцать дней — не доказательство, что программирование кончилось. Это доказательство того, что при жёстком harness и quality gates недетерминированный агент может выдать рабочий результат. Без рамки тот же масштаб — просто очень быстрый путь к нейрослопу.