Библиотека без кода

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

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

Библиотека без кода

A Software Library with No Code Автор: Drew Breunig Оригинальный текст:

Всё, что вам нужно — это спецификации?

Сегодня я выпускаю `whenwords` — библиотеку для форматирования относительного времени, которая не содержит кода.

whenwords предоставляет пять функций для преобразования временных меток в читаемые строки — например, превращения Unix-времени в «3 часа назад».

Существует множество библиотек с похожей функциональностью. Но ни одна из них не является языконезависимой.

whenwords поддерживает Ruby, Python, Rust, Elixir, Swift, PHP и Bash. Уверен, она работает и в других языках — это просто те, что я попробовал и протестировал.

(Я даже реализовал её в виде формул Excel. Правда, установка там требует некоторых усилий.)

Но как я уже сказал: библиотека whenwords не содержит кода. Вместо этого она содержит спецификации и тесты:

• SPEC.md: Подробное описание того, как библиотека должна себя вести и как её следует реализовать.
• tests.yaml: Список языконезависимых тестовых случаев в формате пар ввод/вывод, которые должна пройти любая реализация.
• INSTALL.md: Инструкции по сборке whenwords для вас, человека.

Инструкция по установке комично проста — это промпт для Claude, Codex, Cursor или чего угодно. Она достаточно короткая, чтобы привести её здесь полностью:

1.2.3.4.5.

Выбираете язык, выбираете расположение, копируете, вставляете — готово.

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

Недавние достижения в области агентов для написания кода поражают. Opus 4.5 в связке с Claude Code (агент командной строки от Anthropic) не идеален, но его способность реализовывать точно специфицированный код просто невероятна. Модели и их оболочки преодолели порог в Q4, и все мои знакомые, использующие Opus 4.5, это почувствовали. Не было ни одного языка, где Claude не смог бы реализовать whenwords с первой попытки. Эти возможности поднимают множество вопросов, особенно: «Как выглядит разработка программного обеспечения, когда написание кода становится бесплатным?»

Я немного размышлял над этим вопросом, и эта «библиотека без кода» — осязаемый мысленный эксперимент, который помог конкретизировать несколько вопросов и идей. А именно:

Нужны ли нам ещё сторонние библиотеки с кодом?

Существует множество утилитарных библиотек со схожими функциями, но в виде языкоспецифичных реализаций. Нужны ли они все? Или нам нужен один чётко определённый набор правил, который мы реализуем по требованию, согласно конвенциям конкретного языка и проекта? Для библиотек, являющихся простыми утилитами (в отличие от сложных фреймворков), ответ, возможно, «да».

whenwords — (намеренно) очень простая утилита. Это пять функций, практически без зависимостей, основанная на хорошо определённом стандарте (Unix-время). Это недорогая операция, плохая реализация, скорее всего, не станет узким местом, а сама спецификация занимает около 500 строк.

Но нет причин, по которым мы не могли бы сделать что-то более сложное. Хорошо определённые стандарты (такие как те, что нужны для реализации браузера) могут помочь быстро справиться со сложными частями ПО. Вопрос в том: когда эта модель имеет смысл, а когда нет?

Сегодня я вижу 5 причин, по которым вам нужны библиотеки с кодом:

1. Когда важна производительность

Продолжим пример с браузером. Существуют хорошо определённые, объёмные спецификации для интерпретации HTML, JS и CSS. Можно пойти дальше и создать браузер только на основе спецификаций.

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

2. Когда тестирование становится сложным

«Но Дрю, — скажете вы, — если мы находим проблемы с производительностью в браузере на основе спецификаций, мы можем просто обновить спецификацию». Это правда, но тестирование обновлений быстро усложняется.

Допустим, вы заметили, что в реализации whenwords на Elixir есть баг. Чтобы исправить спецификацию whenwords, вы добавляете строку в SPEC.md для предотвращения бага Elixir. Вы отправляете pull request, и я могу проверить, что это помогает Claude создать работающую реализацию на Elixir.

Но не сломало ли это изменение другие варианты? Работает ли whenwords по-прежнему для Ruby, Python, Bash и Excel? Работает ли она для всех них при сборке через Claude и Codex? А что насчёт Qwen? Получим ли мы CI/CD pipeline (пайплайн непрерывной интеграции), который собирает и тестирует нашу спецификацию на 4 агентах для написания кода и 20 языках? Или мы просто скажем «да ну их» и переложим на пользователей ответственность за сгенерированный код?

Это не огромная проблема для библиотеки масштаба whenwords, но для чего-то умеренно сложного площадь поверхности тестирования растёт очень быстро. В whenwords — 125 тестов. Для сравнения, в SQLite — 51 445 тестов. Я не собираюсь строить на реализации базы данных, основанной только на спецификациях.

3. Когда нужна поддержка и исправление багов

Отлавливать баги в библиотеках на основе спецификаций сложнее, потому что сбои непоследовательны.

Представим будущее, где мы поставляем корпоративное ПО как Claude Skill или какой-то другой подготовленный контекст, позволяющий агентам реализовывать наше ПО для клиентов в зависимости от их среды. Это, по сути, наша «библиотека без кода», доведённая до крайности. И хотя здесь могут быть преимущества, есть и опасности.

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

4. Когда важны обновления

Мне нравится библиотека LiteLLM — AI-шлюз, предоставляющий единый интерфейс для вызова множества больших языковых моделей на разных платформах. Они быстро добавляют новые модели, выпускают обновления для устранения проблем с подключением к разным платформам и в целом очень отзывчивы.

Другие фундаментальные библиотеки (такие как nginx, Rails, Postgres) выпускают критические обновления безопасности. Это зависимости, которые я хочу поддерживать. Библиотеки на основе спецификаций, с другой стороны, вероятно, лучше всего подходят для утилит и функций в режиме «реализовал и забыл» — когда постоянные исправления, поддержка и безопасность не нужны или не ценятся.

5. Когда важны сообщество и совместимость

Через все вышеперечисленные пункты красной нитью проходит сообщество. Много пользователей — больше обнаруженных багов. Больше контрибьюторов — больше исправленных багов. Комплексное тестирование — быстрее принимаются pull request'ы. Большое сообщество повышает шансы найти того, кто поможет. Поддержка сообщества означает, что код поддерживается в актуальном состоянии.

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

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

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

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

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