Эксперименты с использованием больших языковых моделей (LLM) для разработки и сопровождения инфраструктурного ПО постепенно переходят из разряда развлечения в зону реальной практики. Ондржей Сури, директор по инженерии DNS в ISC, ранее основавший CZ.NIC Labs и участвовавший в создании DNS‑сервера Knot, системно проверил, что именно искусственный интеллект реально может, а где его польза оказывается сильно преувеличенной. В ходе серии экспериментов он пробовал применить AI к коду BIND 9, созданию телеметрии, написанию сетевого ПО на Rust и подготовке учебных материалов для университета. Параллельно похожий подход опробовал директор по инженерии Cloudflare, использовав LLM для быстрой альтернативной реализации API Next.js.
Общий вывод у обоих получился схожим: большие языковые модели отлично подходят для быстрых набросков, черновых решений и исследования незнакомых кодовых баз, но как только задача становится крупной, серьёзной и связанной с продакшен‑кодом, экономия времени становится сомнительной. Слишком много усилий уходит на точную постановку задачи, последующую валидацию результатов, поиск скрытых ошибок и переписывание сгенерированного кода.
Попытка "починить" и модернизировать BIND 9
В первом эксперименте Сури поручил Claude Code проанализировать код BIND 9 с фокусом на безопасности и модернизации. Модель должна была найти потенциальные уязвимости, устаревшие конструкции и предложить улучшения. Формально всё выглядело многообещающе: AI аккуратно прокомментировал участки, указал на возможные проблемы, подготовил патчи.
На практике не было принято ни одного изменения. Причина не в том, что код был синтаксически неверным - наоборот, большинство предложений были технически корректны. Беда в другом: они не приносили реальной пользы. LLM отмечала, например, использование зарезервированных идентификаторов или теоретические целочисленные переполнения, которые уже гарантированно отсекались компилятором и системой сборки. С точки зрения опытного разработчика это - шум, а не сигнал.
В итоге эксперимент был признан пустой тратой времени: для зрелой кодовой базы высоконагруженного DNS‑сервера LLM не смогла предложить значимых улучшений, которых бы не видели сами мейнтейнеры или статический анализ.
Телеметрия с минимальными утечками: быстро, но дорого по времени
Во втором эксперименте задача стала более творческой: Claude нужно было спроектировать и реализовать систему телеметрии, которую можно встраивать в разные пакеты, при этом жёстко ограничивая утечки метаданных и лишней информации. Модель сгенерировала клиентскую и серверную части, предложила архитектуру, API и формат сообщений.
Сури дополнительно привлёк Gemini и ChatGPT, используя их как "перекрёстных ревизоров" - каждая модель проверяла код, сгенерированный другой. Интересный эффект: AI‑модели достаточно хорошо находили ошибки и недочёты в результатах других LLM. Фактически получился автоматизированный "круговой код‑ревью", но без гарантии качества финального решения.
Для быстрых прототипов такой подход оказался применим: архитектура была накидана, основные компоненты обозначены, код компилировался и кое‑как работал. Но субъективное ощущение разработчика оказалось резко отрицательным. Сури описывает, что по сути превратился в "секретаря робота‑повелителя": значительная часть времени ушла на формулировку подсказок, уточнение требований, отсеивание бессмысленных изменений и рефакторинг чрезмерно многословного и дублирующегося кода.
В итоге он пришёл к выводу, что, если бы писал систему телеметрии с нуля сам, суммарно времени ушло бы не больше, а качество изначально было бы выше. AI дал быстрый старт, но затем затормозил процесс за счёт объёма исправлений и ревизий.
Балансировщик нагрузки на Rust: работает, но оценить сложно
Третий эксперимент касался генерации нового проекта: простого балансировщика нагрузки на Rust с использованием crate‑пакетов Domain и Tokio. Claude Code успешно выдал рабочий прототип: код собирался, выполнял основные функции, и на уровне "минимально работающего решения" задача была закрыта.
Однако здесь проявилась другая проблема. Сам Сури не считает себя достаточно глубоко погружённым в Rust и конкретные библиотеки, чтобы компетентно судить о качестве получившейся реализации. Формально балансировщик работал, но был ли он идиоматичным, безопасным, эффективно использовал асинхронность, правильно ли обрабатывал ошибки - осталось под вопросом.
Этот эксперимент показывает важный нюанс: если разработчик не владеет технологией, он не может уверенно оценить качество кода, сгенерированного LLM. Получается своеобразная ловушка: AI позволяет "делать вид", что ты пишешь на новом языке или фреймворке, но без фундаментальных знаний остаётся риск незаметно внедрить в систему хрупкое и уязвимое решение.
AI в образовании: лучший результат, но не без курьёзов
Четвёртый эксперимент был связан не с кодом, а с преподаванием. Ондржей использовал Google Gemini для подготовки вспомогательных материалов к университетскому курсу: тестовых заданий, контрольных вопросов, поясняющих текстов, которые облегчают усвоение сложных тем.
Этот опыт он назвал наиболее удачным. LLM быстро генерирует разнообразные формулировки, примеры и задания, помогая преподавателю расширить и обновить курс без бесконечного ручного перебора вариантов. Однако и здесь не обошлось без ошибок: модель, например, "придумала" несуществующее чешское слово для криптографического термина, выдавая вымысел за реальный термин.
Отдельная проблема - студенческие работы. Всё больше студентов сдаёт тексты, полностью сгенерированные LLM, часто с грубыми неточностями и вымышленными источниками. Такие работы приходится возвращать: формально они выглядят "умно", но уровень аргументации и точность ссылок не соответствуют университетским стандартам. В перспективе преподавателям придётся выстраивать новые правила, системы проверки и форматы заданий, чтобы отличать реальное понимание от имитации.
Альтернативный Next.js: vinext как эксперимент инженерии с помощью AI
Параллельно другой крупный эксперимент провёл директор по инженерии Cloudflare, решив проверить, насколько далеко можно зайти, если целенаправленно использовать LLM для создания сложного веб‑фреймворка. С помощью Claude Code, примерно за неделю и с расходом около 1100 долларов на токены, была создана альтернативная реализация API Next.js, оформленная в виде плагина для Vite. Проект получил название vinext и опубликован на платформе GitHub.
По заявленным результатам vinext показывает впечатляющие характеристики: сборка фронтенд‑приложений получается примерно в четыре раза быстрее, чем у Next.js с Turbopack, а размер итоговых бандлов уменьшается на 57%. Реализовано около 94% из шестнадцати базовых API Next.js, и в большинстве сценариев vinext можно использовать как прозрачную замену Next.js, не меняя привычную модель разработки.
Ключевая идея - освободить API Next.js от жёсткой привязки к конкретной платформе. Vinext позволяет разворачивать приложения на Cloudflare Workers без дополнительных прослоек наподобие OpenNext и без обязательной зависимости от Node.js. Это открывает дорогу к запуску знакомых для разработчика Next.js‑проектов поверх других бессерверных платформ.
На данный момент vinext полноценно поддерживает только Cloudflare Workers, существует экспериментальный прототип под Vercel, а в перспективе рассматривается интеграция с другими провайдерами серверлесс‑вычислений, с которыми умеет работать Vite: Netlify, AWS Lambda и другие. Таким образом, эксперимент здесь заключался не столько в "магической" генерации кода, сколько в проверке, можно ли с помощью LLM ускорить реализацию достаточно сложного инженерного замысла.
Где же "настоящий" эксперимент и почему нет бенчмарков с HAProxy?
Логичный вопрос: если речь идёт о балансировщиках и прокси, почему авторы не устроили лобовое сравнение с уже существующими и отлично зарекомендовавшими себя решениями вроде HAProxy? Ведь тот известен как крайне быстрый, надёжный и хорошо отлаженный инструмент, который в большинстве сценариев "рвёт" более модные, но тяжёлые по накладным расходам Caddy или Traefik.
Ответ кроется в цели экспериментов. Ни Сури, ни инженер Cloudflare не ставили задачу доказать, что AI‑сгенерированный код обгонит ведущие промышленные решения по производительности и безопасности. Основной вопрос был другим: насколько AI может:
- сократить время от идеи до рабочего прототипа;
- помочь разобраться в чужом или незнакомом стеке;
- сгенерировать архитектуру и скелет проекта;
- снять часть рутинных задач с разработчика.
Полноценные стресс‑тесты на выделенном сервере, сравнение с HAProxy и другими зрелыми продуктами потребовали бы отдельного этапа работы: подготовки сценариев, настройки нагрузочного тестирования, анализа метрик, последующей оптимизации. Это уже не эксперимент по возможностям LLM, а классическая инженерная работа по тюнингу и бенчмаркингу - без какого-либо "волшебства" AI.
Важно также понимать: цель vinext - не заменить специализированный балансировщик нагрузки. Это инструмент для фронтенд‑разработки, заточенный под API Next.js и экосистему Vite. В таких задачах критерии успеха - не только "кто быстрее проксирует TCP‑пакеты", а удобство разработки, интеграция с платформой деплоя, поддержка server‑side rendering, routing, data‑fetching и прочих типичных для React/Next задач. В этих координатах сравнивать его с HAProxy напрямую так же некорректно, как сравнивать библиотеку рендеринга шаблонов с чистым HTTP‑сервером.
Зачем всё это, если "старые" инструменты работают лучше и надёжнее?
Скептический вопрос "зачем?" кажется абсолютно оправданным, особенно на фоне высоконагруженных, критичных к отказам систем. Там решения вроде BIND 9, HAProxy, классических nginx‑конфигураций и других отлаженных инструментов остаются безальтернативными: они проверены годами эксплуатации, их поведение хорошо изучено, а сообщество знает все подводные камни.
Ни один из описанных экспериментов не пытается сразу "выкинуть" такие инструменты и заменить их AI‑сгенерированными аналогами. Речь идёт о другом: о проверке границ полезности LLM в инженерной практике.
Сейчас они неплохо справляются с:
- ускорением рутинных операций (написание шаблонного кода, генерация тестов, черновые документации);
- поиском входной точки в незнакомую кодовую базу;
- быстрым накидыванием архитектурных вариантов;
- созданием прототипов, которые потом человек будет доводить до ума.
Но когда дело доходит до:
- серьёзных задач по безопасности;
- высоконагруженных компонентов (DNS, L4/L7‑балансировщики, криптография);
- сложных многокомпонентных систем с жёсткими SLA,
AI оказывается полезен только как вспомогательный инструмент, а не как самодостаточный "автоматический разработчик". Именно это и показывают описанные эксперименты.
AI как "ускоритель черновиков", а не замена инженера
Поведение LLM очень хорошо описывает фраза: "проще переписать". Модель выдаёт быстро, но не всегда качественно. В результате опытный разработчик нередко смотрит на получившийся код и решает, что легче написать всё с нуля, чем разбираться в обилии лишних абстракций, повторяющихся участков и неочевидных решений.
Ситуация напоминает раннюю цифровизацию документооборота: сначала всё радостно переводили в цифру, генерировали PDF и электронные формы, но затем выяснялось, что процессы не стали проще - они просто переехали из бумажного мира в электронный, сохранив все старые проблемы, а иногда и добавив новые. С AI‑кодогенерацией похожий эффект: ускорение на этапе черновиков не означает автоматического ускорения всего цикла разработки.
Тем не менее полностью отмахиваться от таких инструментов было бы стратегической ошибкой. Они уже меняют рынок: заметно пострадал бизнес людей, зарабатывавших на платных рефератах и курсовых; следующей волной станет массовая "борьба" между AI‑генерацией и AI‑проверкой студенческих работ. Аналогичные процессы начинают происходить и в промышленной разработке: части задач, которые раньше занимали много времени у джунов и мидлов, теперь выполняются одной‑двумя подсказками к модели.
К чему это всё приведёт в разработке инфраструктурного ПО
Эксперименты с BIND 9, телеметрией, Rust‑балансировщиком и vinext показывают текущее положение дел:
- LLM не заменяют глубокую экспертизу в системном и сетевом программировании.
- AI может быть полезен как ускоритель исследований и прототипирования.
- Для зрелых проектов и критичной инфраструктуры любые изменения, предложенные AI, должны проходить такой же жёсткий код‑ревью, тесты и аудит, как и обычный код.
- Без понимания технологии разработчик не может адекватно оценить качество AI‑сгенерированного решения и рискует втащить в систему хрупкий компонент.
Вопрос о сравнении с HAProxy, нагрузочном тестировании на выделенном сервере и прочих "настоящих" инженерных проверках уместен, но он относится уже к следующему этапу зрелости. Пока же основная ценность подобных кейсов в другом: они трезво показывают, где AI действительно помогает, а где превращается в дополнительный слой шума, требующий внимательного человеческого контроля.
И в этом смысле главный результат этих экспериментов - не конкретный код и не новые фреймворки, а понимание: искусственный интеллект пока что остаётся инструментом в руках инженера, а не его заменой.
