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

Основатель exe.dev рассказывает, как за неделю собрал с помощью агентов географически распределённый DNS-сервер, почти не читая код, — и почему Claude стоит считать не компилятором, а «мульти-компилятором», работающим сразу на всех уровнях стека.

Это AI-перевод статьи, сделанный каналом Про AI: Лучшие Статьи и Исследования.

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

Claude Is Not a Compiler Автор: Josh Bleecher Snyder Оригинальный текст:

В начале 2025 года я написал статью «Является ли Claude компилятором?» Тогда мой ответ был: не знаю.

Теперь я довольно уверен, что ответ — «нет, это категориальная ошибка, он лучше компилятора». Но это требует некоторых пояснений.

Компьютерные программы, как известно, устроены запутанно и капризно. Программа работает на предельном уровне точности. Инструкции процессора «ну, как-то так» не существует. Высокоуровневые же цели, наоборот, крайне недоспецифицированы.

В сильно стилизованном представлении о мире софт строится слоями, и каждый слой добавляет спецификации и прячет «ненужные» детали. Видение становится стратегией, продуктовые планы — планами разработки, код — бинарниками. За каждый шаг отвечает своя роль: руководитель, вице-президент, продакт-менеджер, архитектор, инженер, компилятор.

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

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

Хороший, заслуживающий доверия компилятор освобождает разработчика от необходимости принимать эти решения. Большинство инженеров слабо представляют, как устроены компиляторы; им это и не нужно, чтобы работать эффективно.

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

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

Работа поперёк слоёв крайне ценна; механическая эмпатия имеет значение.

Отчасти Эмпайр-стейт-билдинг был построен меньше чем за год и не выйдя за бюджет (!!) именно благодаря системной работе поперёк слоёв. Например, когда решали вопрос о внешней облицовке из хромоникелевой стали:

Когда произносишь это вслух, звучит совершенно очевидно.

И тем не менее на практике мы систематически с этим проваливаемся. Могу лишь представить, до чего были рады металлисты, получившие возможность направить проектирование к чему-то, с чем не мучительно и не медленно работать.

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

Claude лучше компилятора, потому что он умеет работать вертикально, сквозь весь стек. LLM теперь разговаривают на языке стратегии, продукта, архитектуры, кода и машинного кода. Пока (пока?) модель не делает большинство отдельных задач так же хорошо, как опытный человек, посвятивший себя именно этому, но она делает их все — и без необходимости назначать встречи или спрашивать разрешения.

Вот конкретный пример.

У виртуальных машин exe.dev приятные доменные имена: vm-name.exe.xyz. Когда мы запускаем новую VM, мы добавляем одну-три CNAME-записи. Просто, да?

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

Мы сделали очевидную вещь: написали собственный DNS-сервер, чтобы DNS всегда немедленно соответствовал источнику истины. И жизнь наладилась.

Но задержка имеет значение, поэтому мы добавили регионы. И тут же DNS снова стал узким местом, потому что весь DNS обслуживался из Орегона. Кроме того, деплои вызывали крошечные DNS-простои. Чтобы это починить, нам теперь требовался всего лишь географически распределённый, но при этом полностью консистентный DNS-сервер.

Мы поступили так, как поступает всякий разумный инженер, столкнувшись со сложной задачей: сжульничали. Мы vibe-инженерили распределённый DNS-сервер, заточенный под наши конкретные нужды.

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

Самые верхнеуровневые стратегические и архитектурные решения мы обсудили лично. Мы сделаем достаточно универсальный DNS-сервер и наложим сверху наши специфические поведенческие правки, применим модель «звезда» (hub-and-spoke), возьмём стратегию репликации «только добавление» (append-only) и обеспечим персистентность на краях сети.

Оставалось всего лишь это построить.

Я поручил LLM изучить стандартные схемы распределённых DNS-систем, объяснить мне внутреннее устройство и причуды DNS, указать на исторические провалы в безопасности, исследовать альтернативные стратегии реализации (AXFR/IXFR? нет уж, спасибо), изучить open source решения, проиграть сценарии отказов и спланировать стратегии тестирования.

Как только у меня появился первоначальный набросок дизайна, показавшийся перспективным, я запустил несколько параллельных агентных циклов, чтобы построить всю систему целиком, включая тесты и состязательное код-ревью. Агенты задали кучу вопросов — на всех уровнях детализации, от крупных структурных подходов до построчных замечаний по коду. По мере того как я отвечал (или откатывал ответы, о которых потом жалел), я постепенно превращал усвоенное в очень лаконичные письменные указания, фиксируя решения, которые оказались важными.

Затем я попросил новых агентов сравнить готовые реализации и поискать интересные расхождения. Было поразительно, сколько важных решений агенты никогда не выносили на обсуждение, а просто принимали сами — и принимали по-разному.

Вот пример. Репликация использует довольно очевидный подход: догоняем, запрашивая всё, что появилось после последней известной записи, а затем через long polling ждём новые записи. Есть один уродливый нюанс: откаты базы данных. Редкие, но случающиеся, и они ломают контракт «только добавление».

Агенты заметили это и решили проблему совершенно разными способами. Дизайн, на котором я в итоге остановился, был такой: дать каждой строке поле «timeline» — «в какой временной линии ты живёшь?». Значения генерируются случайно, и каждый запрос синхронизации «записи начиная со строки N» включает значение timeline для строки N с точки зрения краевого сервера. Если timeline не совпадает, мы знаем, что история была изменена, и откатываемся к полной чистой пересинхронизации.

Между системами, построенными разными агентами, обнаружились и явные стилистические различия. Claude и Codex оба согласились, что Claude создал более элегантную систему, но Codex был более дотошным.

Я проработал список основных выявленных расхождений, поэкспериментировал, а затем добавил ещё письменных указаний.

Потом я повторил весь процесс дифференциального анализа спецификации — дважды. Я знаю свои афоризмы.

>

>

>

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

Финальная система включала юнит-тесты, end-to-end тесты, теневой режим (shadow-mode) для снижения рисков при выкатке в прод и лаконичный набор документов, написанных агентами и для агентов.

В совокупности это заняло около недели моего внимания. Я прочитал исчезающе малую часть собственно кода.

В конце я представил решение команде. Я планировал запустить сервер и уйти в отпуск. И пока коллеги забрасывали меня вопросами — «Как работает X? Что произойдёт при условии Y?» — я обнаружил, что могу уверенно ответить на все. (И в отпуск я всё-таки ушёл. Количество DNS-инцидентов месяц спустя: 0.)

Claude здесь был не просто компилятором. Я никогда не передавал задачу с рук на руки, позволяя агенту принять кучу решений, чтобы свести её к реализации. Это vibe-coding.

Скорее, Claude был вертикально интегрированным ресурсом, мульти-компилятором. Его способность работать сквозь весь стек ускорила и усилила мою способность принимать множество решений на разных уровнях — включая решения о том, какие решения важны. (Большинство отдельных строк кода в эту категорию не попадают.) Это vibe-engineering.

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

Один из вопросов этой эпохи: что разработчикам нужно понимать о системах, с которыми они работают?

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

Некоторые программные слои умирают, потому что дают удобство, но не дополнительное понимание. (Прости, Tailwind. Я тебя любил.) Но программные слои, которые позволяют выражать важные решения в понятной форме? Такие останутся.

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

Разработчиков растягивают. Это будоражит и изматывает. Но становится ясно вот что: в ближайшем будущем vibe-engineering — это просто… инженерия.

Подпишитесь на канал и каждый день читайте лучшие материалы про AI переведенные на русский!

Нашли интересную статью для перевода? Пришлите нашему боту: @ailongreadsbot