sqlite-utils 4.0rc2: Claude Fable написал большую часть кода за $149

Саймон Уиллисон опубликовал sqlite-utils 4.0rc2, и большую часть работы над ним выполнил Claude Fable - буквально за несколько дней до окончания доступа к модели через Max-подписку.

Зачем вообще подключать модель к финальному ревью

Уиллисон придерживается SemVer и старается делать несовместимые мажорные версии как можно реже. Перед отправкой 4.0 в стабильный релиз он запустил Fable через Claude Code for Web прямо с iPhone с простым промптом:

Final review before shipping a stable 4.0 release - very important to spot any last minute things that would be a breaking change if we fix them later

Модель сформировала первичный отчёт и выявила 5 блокирующих багов, которые автор сам ещё не встречал.

Самый серьёзный баг: потеря данных в delete_where()

Fable нашёл критическую проблему в Table.delete_where() (sqlite_utils/db.py:2948): метод запускал DELETE через голый self.db.execute() без обёртки atomic() - в отличие от соседнего Table.delete() в той же строке 2944, который обёрнут корректно.

Результат: соединение застревает в состоянии in_transaction=True, и все последующие вызовы atomic() уходят в ветку savepoint, которая тоже никогда не коммитит. Данные не сохраняются.

Уиллисон прокомментировал это прямо: баг плохой, но не катастрофический - его можно было бы закрыть в 4.0.1, а не форсировать выпуск 5.0.

Цифры сессии

По итогам работы с Fable:

• 37 промптов
• 34 коммита
• +1 321 / -190 изменений строк кода в 30 файлах
• стоимость сессии - $149.25

Пока модель «жевала» очередную задачу (иногда по 10-15 минут), Уиллисон ходил смотреть парад в честь 4 июля в Хаф-Мун-Бэй и проверял статус с телефона.

Новая модель транзакций: что изменилось

Ключевая новинка всей ветки 4.0 - переработанная логика транзакций. В документации к rc2 это описано так:

Каждый метод, который пишет в базу (insert(), upsert(), update(), delete(), delete_where(), transform(), create_table(), create_index(), enable_fts() и остальные), выполняется внутри своей транзакции и коммитит её до возврата. commit() вызывать не нужно, закрывать базу для сохранения изменений тоже.

Две ситуации, где всё же нужно думать о транзакциях:

• хочешь сгруппировать несколько операций в одну атомарную - используй db.atomic()
• управляешь транзакцией вручную через db.begin() - тогда библиотека сама ничего не закоммитит

Отдельно обнаружилась проблема с autocommit=True и autocommit=False из Python 3.12+: эти режимы ломали почти весь тест-сьют. Проблему исправили.

Как GPT-5.5 проверял работу Fable

После того как Fable закончил, Уиллисон скормил изменения Codex Desktop и GPT-5.5 xhigh с промптом:

Review changes since the last RC. Also confirm that the changelog is up-to-date.

Модель от OpenAI нашла два новых [P1]-бага:

1. db.query() с UPDATE-запросом сначала выполнял и коммитил изменение, и только потом падал с ValueError - то есть данные уже записаны, а метод бросает исключение.
2. INSERT ... RETURNING через db.query() коммитил только после полного исчерпания генератора. Вызов next(db.query(...)) или просто неитерированный вызов оставлял транзакцию открытой - вопреки тому, что написано в changelog и документации.

Оба бага подтвердил Fable в отдельной сессии. Оба исправлены в rc2.

Уиллисон признаётся, что раньше скептически относился к идее «одна модель проверяет работу другой» - казалось суеверием. Теперь делает это системно: лучшая модель Anthropic ревьюит работу OpenAI и наоборот, потому что это регулярно даёт результат.

Что это значит

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

Кросс-ревью моделями (Anthropic проверяет OpenAI и обратно) - уже не эксперимент, а рабочая техника, которую стоит добавить в свой процесс.

Источник: Simon Willison, 5 июля 2026 - simonwillison.net