Claude поймал баг SQLite, живший с 2010 года, за 15 минут
Карл, сотрудник компании Antithesis (делает платформу для детерминированного тестирования и отладки ПО), рассказал, как в 2026 году попросил ИИ-агента Claude найти в SQLite давний баг под названием WAL-Reset, гонку потоков (data race) в подсистеме журналирования с упреждающей записью (Write-Ahead Logging, WAL). Баг жил в коде SQLite с 2010 года и был исправлен в вышедшей ранее в этом году версии 3.51.3. Сама команда SQLite писала о нём: «Это гонка данных с очень жёсткими временными ограничениями. В обычном использовании она почти никогда не проявляется. Разработчикам ни разу не удалось воспроизвести баг органически, пришлось добавить в SQLite специальную тестовую логику, которая намеренно провоцирует условия бага, чтобы подтвердить, что проблема исправлена».
Карл развернул в Antithesis всё ещё содержащую баг версию SQLite 3.51.2, снабдил код проверочными утверждениями (assertions) платформы и попросил Claude написать простую нагрузку: она параллельно выполняет запись и чекпоинты, то, что в реальных базах происходит постоянно. Проверки тоже были самые общие для любой базы данных: «ни одна подтверждённая запись не теряется» и «база не повреждена» (в терминах SQLite, integrity check). На первом же прогоне Antithesis поймала баг за 15 минут. Тот же тест на исправленной версии 3.51.3 прошёл чисто.
Поводом вспомнить об этом стал отдельный пост команды Tailscale, они рассказали, как в 2025 году полгода мучились с нестабильным аптаймом именно из-за этого бага. Вместе с командой SQLite они потратили недели на поиск причины, выкатили и откатили фикс, который сломал кое-что другое, а затем ещё два месяца ждали, чтобы убедиться, что «настоящий» фикс (3.51.3) действительно работает. Сама Tailscale написала: «никто не хотел, чтобы мы полгода искали баги в SQLite, это было крайне тяжело и для наших клиентов, и для нашей команды». Карл отмечает, что нашёл и подтвердил тот же баг примерно за час, с телефона, сидя на склоне холма.
Ключевые факты
- SQLite 3.51.3, вышедшая ранее в 2026 году, исправила баг WAL-Reset, гонку данных в журнале упреждающей записи, существовавшую с 2010 года
- Карл из Antithesis направил Claude инструментировать SQLite 3.51.2 проверками платформы и написать простую параллельную нагрузку из записей и чекпоинтов
- На первом прогоне Antithesis поймала баг за 15 минут; повторный прогон на исправленной 3.51.3 прошёл без ошибок
- Команда Tailscale отдельно описала, как тот же баг вызвал у них полгода нестабильного аптайма в 2025 году, а поиск причины занял недели и ещё два месяца на проверку фикса
- По словам Карла, весь цикл поиска и подтверждения бага занял у него около часа, с телефона
Почему это важно
История показывает не абстрактную демонстрацию ИИ-агента, а конкретный редкий баг, который команда SQLite сама не могла воспроизвести годами, а Tailscale из-за него полгода боролась с нестабильным аптаймом в проде. Claude, получив доступ к платформе Antithesis и написав универсальную нагрузку, поймал баг за 15 минут, это практический пример того, что связка ИИ-агента с инструментом детерминированного тестирования может находить гонки данных, которые не ловятся обычным ручным тестированием.
Кому это важно
Разработчикам баз данных и распределённых систем, инженерам по тестированию и QA, командам, чьи продукты завязаны на SQLite (как Tailscale), и всем, кто следит за практическим применением ИИ-агентов в инженерной работе, а не только в написании кода.
Как это применить
Подход: развернуть проверяемую версию ПО в Antithesis, снабдить код проверочными утверждениями (assertions) вида «нет потерянных подтверждённых записей» или «данные не повреждены», затем поручить агенту (в данном случае Claude с навыками Antithesis) написать максимально общую нагрузку, имитирующую реальное использование, параллельные операции записи и синхронизации. Карл подчёркивает: часто именно простые нагрузки находят самые сложные баги.
Можно ли доверять
Источник, блог самой компании Antithesis, а автор поста, судя по формулировкам («мы это часто делаем в наших POC», «я недавно выпустил наши навыки для Claude»), с ней связан, то есть текст одновременно и техническая история, и реклама продукта. Это личный рассказ от первого лица без независимой стороны, подтверждающей детали, хотя факт исправления бага в SQLite 3.51.3 и связанный пост Tailscale, внешние, проверяемые точки опоры.
Риски и подводные камни
Пост не объясняет технический механизм самой гонки данных, только называет её «гонкой с жёсткими временными ограничениями», без деталей, что именно и с чем гонится. Из одного успешного случая нельзя судить, насколько такой подход к поиску багов с ИИ-агентом и Antithesis обобщается на другие типы редких ошибок; при этом сам пост написан как кейс, продвигающий инструмент компании автора.
«Это гонка данных с очень жёсткими временными ограничениями. В обычном использовании она почти никогда не проявляется. Разработчикам ни разу не удалось воспроизвести баг органически, пришлось добавить в SQLite специальную тестовую логику, которая намеренно провоцирует условия бага, чтобы подтвердить, что проблема исправлена.»
— команда SQLite