Как я, фаундер без навыков программирования, заставил ИИ не удалять тесты

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

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

Меня зовут Пётр, я соло-фаундер. Мои продукты собираются цепочками ИИ-агентов: Claude Code, Cursor, OpenCode. Я ставлю высокоуровневые цели, а код пишут они. За полгода такой работы я накопил целый каталог историй, от которых у опытного разработчика волосы встают дыбом.

Однажды ИИ жёстко захардкодил API-ключ Stripe прямо в исходниках. Это бомба замедленного действия под любой security-аудит. В другой раз подтянул пакет `reuests` вместо `requests` — опечатка, которая тихо засоряет supply chain и может обернуться установкой чего угодно. Был случай, когда агент закрутился в бесконечном цикле на шесть часов и сжёг восемьдесят долларов на токенах, пока я спал. Был SQL-запрос в продакшене с прямой подстановкой пользовательского ввода — классическая инъекция. И, конечно, история с удалённым тестом, с которой я начал.

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

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

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

Проверки делятся на три слоя. Первый — безопасность кода: перехват SQL-инъекций через принудительные параметризованные запросы, блокировка хардкода секретов (ключи должны жить только в переменных окружения), отлов выдуманных названий пакетов на этапе установки, пометка неаутентифицированных endpoint'ов. Второй — качество: агент не может удалять или ослаблять тесты ради зелёного билда, не может раздувать архитектуру там, где хватит простого решения, а «спагетти», мёртвый код и циклические зависимости отсекаются структурным гейтом. Третий слой — поведение самого агента: защита от бесконечных циклов через circuit breaker, ограничение бюджета токенов на итерацию, контроль за тем, чтобы ассистент не галлюцинировал отчёты о проделанной работе без реальных доказательств.

Layer 0: YOU (читать код не нужно) | цель + критерии приёмки

Layer 1: CONTROL (диал автономии, триаж, дизайн цикла) |

Layer 2: BUILD LOOP (write -> gates -> verify -> commit -> repeat) | периметр супервизии

Layer 3: SUPERVISION (circuit-breaker, stability, self-learning) |

Layer 4: PRODUCTION (observe -> analyze -> fix -> validate -> learn) ```

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

Главный инсайт, который я вынес: человек остаётся в контроле, даже не открывая редактор кода. Достаточно правильно настроить границы.

Когда я показал keelwright знакомым, первый вопрос был предсказуем: «А ты сам-то проверил, что он работает, или это просто красивая идея?» Справедливо. Я не хотел ограничиваться заявлениями, поэтому прогнал честный adversarial-тест.

Брал одну и ту же задачу, одну и ту же модель, и запускал её дважды — с keelwright и без. Если скилл менял результат по существу, значит, он дискриминирует проблему. Если модель и так справлялась — значит, разницы нет. Итоговая метрика, Keelwright Score, считается как произведение доли успешных запусков на долю случаев, где скилл реально повлиял.

Результаты оказались неожиданными. Модели среднего уровня получают от скилла больше пользы, чем некоторые флагманские. Они чаще проваливают базовые проверки вроде SQL-инъекций или отлова левых пакетов, и keelwright просто отрезает обе проблемы до написания кода. А вот слабые модели вообще не способны запустить тесты — они начинают фабриковать результаты, и integrity-гейт ловит каждую подделку. Все цифры лежат на диске и проверяются механически, это не самоотчёты агента.

Попробовать keelwright проще некуда. Это один markdown-файл, который ИИ-агент подгружает как контекст. Никакой установки, зависимостей и конфигурации. Работает с любым стеком — Python, TypeScript, Dart, что угодно.

1. Загрузить keelwright skill в AI coding session

2. Всё

Если вы тоже сталкивались с тем, что ИИ удалял тесты, хардкодил секреты или сжигал бюджет в пустоту — загляните в репозиторий, там же лежит интерактивная архитектура и разбор методологии. Мне интересно, какие failure modes видели вы, и как с ними справляетесь.

keelwright by ratingtesting