Claude - не компилятор

Июльская статья 2026 года Джоша Бличера Снайдера (Josh Bleecher Snyder) на blog.exe.dev, где он возвращается к вопросу, оставленному открытым в начале 2025 года на commaok.xyz ("Является ли Claude компилятором?", ответ на тот момент: "не знаю"). Теперь ответ таков: сам вопрос был некорректен - "это категориальная ошибка, он лучше компилятора".

Почему аналогия с компилятором была соблазнительной

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

Каждый из этих шагов - это принятие решений, потому что уточнение спецификации и есть принятие решений. Он попутно отмечает: именно поэтому один из двух его критериев найма инженеров - здравый смысл и рассудительность (второй - уживчивость).

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

Поэтому в 2025 году, когда LLM выдавали небольшие фрагменты кода, самым естественным казалось появление нового слоя между инженером и компилятором, компилирующего естественный язык в код. Его ценность была бы прямо пропорциональна надёжности, умноженной на масштаб решений, которые он может на себя взять.

Почему эта картина неверна

Абстракции протекают, слои конфликтуют друг с другом, и мы сами пробиваем в них бреши, даже когда они герметичны. Сквозная работа между слоями ценна; mechanical sympathy имеет значение.

В качестве примера он приводит Эмпайр-стейт-билдинг: его построили меньше чем за год и уложились в бюджет во многом благодаря систематическому игнорированию границ между слоями. По вопросу облицовки из хромоникелевой стали никто из участников не чувствовал себя достаточно компетентным, чтобы решить в одиночку. Поэтому собрали одну общую встречу: заказчик, архитекторы, строители, субподрядчики по прокату стали, рабочие по её обработке, монтажники и инспекторы. На словах это кажется очевидным, но на практике мы регулярно этого не делаем: отчасти из-за непонимания, о чём вообще стоит спросить, отчасти из-за снобизма ("что мне может подсказать обычный рабочий?"), но главным образом из-за коммуникационных и организационных накладных расходов. Слои существуют не просто так - сокрытие информации позволяет организациям масштабироваться.

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

DNS-сервер

Практический пример взят из собственной инфраструктуры exe.dev, и за развитием этой цепочки интересно наблюдать, потому что каждое исправление порождало следующую проблему.

Виртуальные машины exe.dev получают имена вида vm-name.exe.xyz, то есть при создании VM нужно добавлять CNAME-записи. Но их VM запускались настолько быстро, что пользователям приходилось ждать распространения DNS - иногда по несколько минут. Поэтому они написали собственный DNS-сервер, который всегда оставался строго синхронизированным с источником истины. Затем из-за задержек пришлось добавить регионы, и DNS снова стал узким местом, так как всё раздавалось из Орегона; к тому же развёртывания приводили к кратковременным сбоям DNS. Теперь им требовался географически распределённый, но абсолютно консистентный DNS-сервер.

Верхний уровень стека люди спроектировали сами: DNS-сервер общего назначения с нужными им надстройками поведения, топология hub-and-spoke, append-only репликация, персистентность на edge-узлах.

Всё, что лежало ниже, отдали агентам, и сам процесс здесь интереснее всего - общий метод описан на странице differential-spec-analysis. Снайдер поручил LLM изучить типовые архитектуры распределённых DNS, объяснить ему внутреннее устройство и тонкости DNS, вытащить исторические проблемы безопасности, разобрать альтернативы (AXFR/IXFR - "нет уж, спасибо"), сделать обзор open source решений, просчитать сценарии отказов и спланировать тестирование. Затем он запустил несколько параллельных агентских циклов, чтобы с нуля собрать всю систему целиком, включая тесты и adversarial review. Агенты задавали вопросы на всех уровнях, от архитектуры до отдельных строк кода; ответы на них (и откат неудачных решений) оформились в ёмкие письменные инструкции.

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

Конкретный случай: догон репликации запрашивает все записи начиная с последней известной, а затем переходит в long-polling. Откаты баз данных случаются редко, но бывают, и они нарушают append-only гарантии. Это заметили все агенты, и каждый решил проблему по-своему. В итоговом варианте каждой строке присваивается случайное поле timeline ("в какой временной шкале ты живёшь?"), и каждый запрос "записи после строки N" передаёт значение timeline для N, известное edge-серверу. Несовпадение означает, что история изменилась, и edge-узел уходит в полную чистую повторную синхронизацию.

Были и стилистические различия. И Claude, и Codex сошлись во мнении, что система у Claude получилась элегантнее, а у Codex - основательнее.

Он разобрал расхождения, поэкспериментировал, дополнил инструкции и повторил весь цикл ещё дважды - цитируя Брукса ("планируйте выбросить одну версию; вы всё равно её выбросите") и замечание Крейга Зеруни ("если вы планируете выбросить одну, вы выбросите две"). В итоге сформировался документ из рубцовой ткани (scar-tissue document): эмпирически выверенный набор инструкций, позволяющий провести агента по всем важным решениям - от целей и архитектуры до таких деталей, как точный тип данных для высоконагруженного конкурентного кэша.

Финальная версия ушла в прод с модульными и сквозными тестами, shadow-режимом для безопасного выкатывания и комплектом документации, написанной агентами для агентов. Суммарные затраты: около недели его рабочего внимания. Сам он прочитал исчезающе малую долю кода.

Проверка надёжности была скорее социальной и эксплуатационной, чем метрической. Перед уходом в отпуск он презентовал систему команде, получил шквал вопросов в духе "как работает X, что будет при условии Y" и уверенно ответил на каждый. Он ушёл в отпуск. Число инцидентов с DNS за следующий месяц: ноль.

Vibe-coding против vibe-engineering

Различие, которое он проводит, касается того, кто принимает решения, а не того, сколько кода вы читаете. Отдать задачу и позволить агенту довести её до реализации - это vibe-coding. В данном же случае Claude работал как "вертикально интегрированный ресурс, мультикомпилятор", ускоряя принятие решений человеком на каждом уровне - включая метарешение о том, какие именно решения существенны. Большинство отдельных строк кода в эту категорию не попадают. Он называет это vibe-engineering; концепция подробно описана на vibe-engineering.

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

Заключительный вопрос

"Что именно инженеры-программисты должны понимать в системах, над которыми работают?"

Его ответ: удачно выбранные слои дают понимание, и именно это служит критерием выживания. Фундаментальная физика более всеобъемлюща, чем классическая механика, но хуже объясняет, почему при аварии лучше оказаться в автобусе, а не в машине. Слои, созданные лишь ради удобства, отмирают - он с сожалением называет Tailwind. Слои, позволяющие понятно выражать важные решения, останутся.

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

Место в контексте

Это конструктивное дополнение к agent-principal-agent-problem от той же компании: Крошоу диагностировал причины кризиса код-ревью и описал компенсаторные механизмы абстрактно; эта статья - полноценный практический пример применения таких механизмов на реальной системе с чётко названным артефактом (документом из рубцовой ткани).

В вопросе чтения кода позиция близка к control-the-ideas-not-the-code - antirez тоже полностью контролирует архитектуру и пропускает построчное ревью, - но механизм другой. antirez расспрашивает одну модель о её дизайне, проверяя собственную ментальную модель; Блихер Снайдер получает ту же информацию, собирая систему несколько раз параллельно и сравнивая результаты через diff. Обеим позициям противостоят reviewing-ai-code и cult-of-vibe-coding, а danluu-ai-coding-testing занимает третью сторону (исчерпывающее тестирование заменяет ревью).

Связанные страницы

• vibe-engineering - концепция и её границы по отношению к vibe-coding
• differential-spec-analysis - сборка N раз, diff, кодификация; повторно используемый метод
• exe-dev-blog, crawshaw-blog - блог компании и личный блог сооснователя
• agent-principal-agent-problem - проблема, практическим ответом на которую служит этот опыт
• control-the-ideas-not-the-code, reviewing-ai-code, danluu-ai-coding-testing - три позиции по поводу ревью кода от агентов
• peril-of-laziness-lost - противовес безудержной генерации кода
• starling-desktop - применение этого метода в масштабе, который никто не замерял: Linux-десктоп на 335 тысяч строк, созданный одним человеком за полгода без описанного здесь ритуала валидации