Quint Code 5.0 — решения как живая инфраструктура проекта.

18 марта 2026

Недавно я был на подкасте у Родиона Мостового, где мы говорили про FPF, вайбкодинг, инженерию решений и про то, почему “руление” AI-агентами – это совсем не интуитивный навык. Мы не успели пройтись по всем темам, и я обещал слушателям развернутый пост. Вот он.

А еще по ходу разговора на этом подкасте я понял, что пора воскрешать Quint Code. И я его воскресил, влюбился в этот инструмент заново. Но обо всем по порядку.

Код подешевел. Решения — нет.

Все сейчас вайбкодят. И это прекрасно, даже уже когда речь идёт только про пет-проект, тулзу на выходные, или прототип для хакатона. Нет, с переменной долей успеха люди уже начали создавать довольно крупные программные системы с помощью AI. Дьявол хоть и кроется в деталях, но совершенно точно что все кто до сих пор пеняют на AI Assisted Engineering, принципиально не используют эти инструменты – безнадежно, безвозвратно отстали.

Если вас тоже интересует не только интуитивный кайф-вайб-кодинг, а именно AI assisted engineering, то вы уже не раз сталкивались с тем, что когда мы несем ответственность за код, когда на этот код завязан бизнес — тупо “вайб” это вообще не стратегия.

Дело в том что код всегда был малой частью работы в IT. По-настоящему толковые инженеры и раньше были не только инженерами, но в какой-то ощутимой степени менеджерами: моделировали домен, понимали что и для кого строили, организовывали людей. Просто раньше был разрыв между теми кто этим занимается, и теми на кого просто вешают текучку.

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

”Humans steer. Agents execute.”

Буквально недавно (но по меркам сингулярности это уже прошлый век) OpenAI выкатили harness engineering пост — о том как они большую репу “чисто навайбкодили”. Ноль строк кода от людей. Звучит очень круто!!!

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

В этой статье непозволительно мало информации о том какие именно умения нужны для этого эффективного “руления”. Исполнение подешевело и очень ускорилось — а именно руление стало узким местом.

Прочитав harness engineering статью может сложиться впечатление что это можно легко повторить – добавить разных интеграций, тестами покрыть, и вперед…

AI-агенты, если ими рулить неправильно, все еще часто допускают джуновские ошибки. Хорошо что они допускают их быстро — потому что мы не через неделю перед релизом узнаем об этих ошибках а почти сразу. Здесь любители тезиса “ну покрыть тестамиии ну оно само может!!! Я даже тесты не ревьювлю уже! Все само!”

Да, но… Я с трудом верю что вы ни разу не сталкивались с необходимостью всё-таки отревьювить сгенерированный код, или проверить поведение. Потому что иногда это всё-таки нужно делать. Иногда! Но когда это самое иногда случается мы сразу садимся в лужу, потому что оказывается резко нужно обладать некоторыми прикладными компетенциями. Можно конечно продолжать по кругу спрашивать AI, просить помочь, но вы точно знаете что вообще спрашивать? На такие потуги может уходить непозволительно много времени.

Так что мы в ситуации, когда нам все еще:

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

Интуитивные подходы тут работают плохо. Практически не работают вовсе.

Три класса задач

Анатолий Левенчук в своих недавних постах очень чётко определил три класса задач с которыми мы сейчас имеем дело:

Класс 1: “Крути пока тесты не пройдут.” Есть чёткий критерий правильности, и проверить ответ дешевле, чем его найти. Математика, алгоритмы, код с тестами. AI-агенты уже закрывают этот класс в автономном режиме — генерируют варианты, прогоняют через проверку, бадаются до финиша! Это быстро коммодитизируется: ценность перемещается от умения решать к умению ставить задачу. Вы же не думаете до сих пор что поставить задачу это “просто промпт написать?”

Класс 2: Проверка дороже решения. Реальные инженерные системы — распределённые сервисы, платформы, продукты с пользователями. Здесь зелёные тесты не доказывают… ничего :) Система может проходить все проверки и при этом быть хрупкой, не выживать под нагрузкой, незаметно дрейфовать от требований. “Построили” — но построили ли то, что нужно? Верификация требует экспертного суждения, она дороже и медленнее самой разработки, и её нельзя автоматизировать до конца.

Класс 3: Сама постановка проблемы — проблема. Не определены ни решение, ни критерии его проверки — потому что не определена сама задача. Что строить, для кого, зачем — всё это нужно нащупать. Единственный верификатор здесь — реальность: рынок, пользователи, последствия. Проверить результаты можно только зондированием, выпуском продукта в реальность.

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

FPF в одном предложении

FPF (First Principles Framework) — набор инженерных принципов, грамматика для мышления, а еще точнее – операционная система мышления! FPF задаёт структуру мышления так, что трудно пропустить что-то важное. Это не энциклопедия, не методология, не привязка к инструменту. Набор мощных правил. Набор первых SoTA принципов!

Quint Code 5.0: что это и зачем интерфейс переписан с нуля

Quint Code — это decision engineering system для AI-ассистентов. Набор инструментов, которые превращают разговор с вашим любимым AI-агентом в структурированный инженерный процесс.

Версия 5.0 — это полный редизайн. Предыдущая архитектура (ADI цикл с фазами, гипотезами, уровнями L0/L1/L2) была правильной по духу но неправильной по форме. Слишком жесткая, слишком церемонная, контекст перегружался моментально. Для задач средней размерности старый QC вносил только боль и страдание, поэтому я сам не пользовался им последние 2 с половиной месяца!

За это время я пользовался FPF в ChatGPT и Claude Deskop – работает хорошо, очень хорошо если просто добавить спецификацию в контекст чата или проекта (конечно оно индексируется под капотом). Но иногда мне нужен был именно агент с выходом на файловую систему и код, но такой который понимал бы FPF и мог работать хоть сколько нибудь используя его принципы. Так что я предпринимал несколько попыток вроде нарезки скиллпака из спецификации — это была очень тяжёлая история. Скиллпак с хуками… я очень быстро похоронил эту попытку :)

Что изменилось в Quint Code?

Главный сдвиг: от “фазовой машины гипотез” к “проблема → решение → решение записано как контракт”.

В v4 был жёсткий цикл: инициализация → гипотезы → проверка → аудит → решение. Это работало для одного конкретного flow, но было негибко. Далеко не все задачи вписывались в этот конвейер.

В v5 — семь инструментов, каждый самостоятельный. Можно использовать один. Можно все. Можно в любом порядке — система сама подсказывает что делать дальше. Но если хотите получить максимум от инженерного рассуждения — есть протокол, и мы его рассмотрим ниже. Можно просто поставить и вообще ничего не использовать – он сам начнет записывать потихоньку знания и вызывать q-reason когда будут попадаться сложные задачи. Уже выигрыш! То что нужно, поставил и забыл – проект эволюционирует.

Пока я писал этот пост я уже почти доделал версию 5.1 в которой я представляю вам… Specification Coverage! Quint Code будет делать все что может чтобы следить за вашим проектом, за актуальностью decisions которые вы приняли, и даже пытается читать coverage вашего кода спецификациями :) Вы где нибудь такое видели?

Семь инструментов

1. /q-note — запись микро-решений на лету.

Самое лёгкое что есть. “Мы решили использовать X для Y потому что latency критична.” Записано, привязано к файлам, автоматически протухает через 90 дней. Если через три месяца X уже не актуален — система напомнит, и мы проверим, если надо – обновим decision/specification! Живая документация, блин!

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

2. /q-frame — определи проблему прежде чем бросаться решать.

Это где Quint Code уже сильнее всего отличается от “просто спроси AI”. Вместо “как нам сделать X?” — “какую проблему мы решаем? какие ограничения? как мы узнаем что решили?”

Это не бесполезная формальность. Формальность вообще не бывает бесполезной! Это тот самый золотой момент, где 90% проектов могли бы сэкономить недели или месяцы переработок, потому что без чёткой постановки — вы строите “что-то”, и узнаёте что это “что-то” совсем не то что было нужно, только когда уже поздно, когда переписывать будет очень больно. Конечно Quint Code сейчас фреймит проблему только в рамках одного проекта, но я уже вижу как этот момент может расширяться и на командную разработку, и на интеграции со всякими базами знаний команды/компании, но это долгий роадмап.

3. /q-char — определи критерии сравнения до того как увидишь варианты.

Тут мы пытаемся выделить критерии выбора до того как будем генерировать варианты и сравнивать их. Это защита от подгонки — когда выбираешь критерии под заранее “понравившийся” вариант.

Каждый критерий сравнения имеет роль:

constraint — жёсткое ограничение, должно выполняться (latency < 100ms)
target — то что оптимизируем (throughput)
observation — то что мониторим но НЕ оптимизируем (Anti-Goodhart!)

Зачем observation? Закон Гудхарта: когда метрика становится целью — она перестаёт быть хорошей метрикой. Если оптимизируешь throughput — можешь незаметно убить reliability. observation говорит: “следи за этим, но не гонись”.

4. /q-explore — сгенерируй разные варианты, не три вариации одного и того же!

Варианты решения проблемы должны отличаться по сути, а не по степени. “Redis vs Memcached vs in-memory cache” — это три вариации одного подхода. “Кэш vs CDN-оптимизация vs перепроектирование запросов” — это три действительно разных варианта.

Для каждого варианта обязательно понять самое слабое звено. Что ограничивает качество этого подхода? Это не про “минусы” в духе стандартного SWOT — это про то, что сломается первым! И это продолжение той самой “истории” которая начинается во время /q-frame, с каждым шагом полного цикла мы уточняем, думаем, подходим к более лучшему решению.

5. /q-compare — сравнение на Парето-фронте.

Теперь когда критерии определены заранее — приложи их к вариантам.

Тут мы смотрим на Парето-фронт, выбираем не “лучший вариант”, а набор вариантов где каждый может быть (и как правило будет) лучше остальных по одному измерению, но хуже по другому.

Дальше остается лишь ваш осознанный выбор.

6. /q-decide — зафиксируй решение как контракт.

Мы получаем на выходе не заметку в Notion, не замороженный ADR-файл который никто не читает.

Мы получаем контракт с четырьмя компонентами:

Постановка проблемы — зачем вообще решали?
Решение/Контракт — что выбрали, инварианты (что ВСЕГДА должно быть истинным?), предусловия, постусловия
Обоснование — почему это, а не другое? Сохраняем таблицу сравнения, слабое звено, требования к доказательствам
Последствия — план отката (в случае чего надо откатиться? Как? Какой blast radius если всё-таки “не так” возьмет да и пойдет?), а так же формальные триггеры для пересмотра, затронутые файлы

Это не церемония ради церемонии, но спецификация которая работает. Через три месяца, когда придёт новый инженер и спросит “а почему мы используем X?”– очень велик шанс что он найдет исчерпывающий ответ!

Хотелось бы чтобы была полная магия и Quint Code мог отслеживать любые условия и их изменения, но он уже старается делать много – есть таймер устаревания (До какого времени это решение считается актуальным? Когда стоит его если не пересмотреть, то просто проверить что оно актуально?), и почти готова “слежка” за затронутыми файлами.

7. /q-refresh — решения стареют, и это нормально!

Да, я уже начал об этом в прошлом пункте – любое решение имеет срок годности. Бенчмарк годовой давности, документация устаревшей версии, решение принятое при другой нагрузке, решение принятое просто… полгода назад. Quint Code стремится отслеживать это автоматически.

Каждое решение имеет computed trust score — R_eff. Это вычисляемый показатель: минимум из всех доказательств (weakest link principle — прочность цепи равна прочности самого слабого звена), с штрафами за контекст (доказательство из другого проекта менее ценно чем из этого же).

R_eff > 0.5 — решение здоровое
R_eff < 0.5 — решение устарело, нужно пересмотреть
R_eff < 0.3 — AT RISK, требуется немедленное внимание

Когда вы запускаете /q-refresh — он показывает что протухло, и предлагает: продлить (с обоснованием), заменить новым решением, или депрекейтнуть. Ну и идет разбираться что там протухло. У нас же всё-таки AI агент а не чатик!

Три режима работы

Быстрый — для очевидных решений, но нам хочется сильного мышления от AI! Определи проблему (frame) → реши → зафиксируй (decide). Это минимум который дает все полезные артефакты, ништяк!

Полный — для архитектурных решений, ну и вообще решений когда мы не уверены. Я рекомендую почаще прислушиваться к своей “интуиции”, намного чаще чем вам кажется ваши “интуитивные” решения не самые лучшие! Это увлекательно – проверять свои “интуитивные” решения полным циклом quint code – Frame → Characterize → Explore → Compare → Decide.

Авто — /q-reason. Эта команда – дистиллят ядра FPF + весь FPF в формате FTS5 индекса доступного через cli, агент сможет подгружать любую часть FPF по необходимости! Вы тоже можете вызывать q-reason при любой задаче – эффект будет исключительно положительный. На самом деле это не slash-command а skill, как и /q-note, поэтому ваш агент будет стараться использовать и то и другое вовремя. Если вы просто зададите агенту задачу и попросите “подумать”, то почти всегда этот скилл будет вызван. Это то чего не хватало старому Quint Code – интеллектуальной мощи доступной быстро и почти бесплатно.

Где FPF не нужен, а где — незаменим

Не надо стрелять из пушки по воробьям, дорогие друзья!

Медленное и инженерное мышление не нужно для:

“Покраски кнопки интерфейса в красный”
Исправления бага в эндпоинте где надо проверять поле X а не Y
Написать CRUD endpoint, такой же какой уже есть но “немного другой”
Любая иная задача где решение очевидно а цена ошибки ≈ 0

Quint Code при любой тривиальной задаче уже прямо на /q-frame скажет вам “Чувак, это тривиально, давай сразу сделаем и зафиксируем?”

Но медленное и инженерное мышление нужно когда задача:

Разделена между людьми, командами, или AI-агентами
Обратная связь от реального мира запоздалая, шумная или дорогая (смотрите классы задач ранее в посте)
Трейд-оффы между скоростью, качеством, риском нам надо делать явно, цена не верной ошибки высока
Вы “чувствуете” что существующие, знакомые вам подходы сломаются, не справятся с этой задачей (или вы уже наблюдали как эти подходы с подобными задачами не справляются)
Цена ошибки в принципе выше нуля (и ты это узнаешь через полгода)

На основании всего этого я сделал вывод что FPF нужен в любом реальном, живом продакшене, а значит мне надо удешевить использование спецификации, и сделать максимальное количество преимуществ доступным наиболее широкому числу разработчиков. А значит – надо воскрешать Quint Code!

Ожидание vs реальность

Люди думают что код станет лучше сам собой, если мы будем по кругу мучать агентов, или применять громкие прикладные технологии. Но нет. Лучше становятся только решения. Это про upstream quality. Код — это всегда downstream. Если решение правильное, код (даже сгенерированный AI) может быть разного “прикладного качества”, но скорее всего он будет в рамках правильного решения, понимаете? Если решение кривое — никакой линтер и ральф-цикл вас не спасет.

Что дальше: Roadmap Quint Code

Codebase Awareness — в работе прямо сейчас

Самая большая проблема текущей версии: Quint знает про решения, но слеп к связи кода и спецификации. Но я уже заспойлерил что это почти решилось пока я писал это письмо!

Мы решили эту проблему в три уровня:

Level A — File Drift Detection: когда код под решением меняется — решение автоматически помечается как потенциально устаревшее. QC детерминированно определяет ЧТО изменилось (хеши файлов, diff), и ваш агент проверяет и оценивает — ВАЖНО ли это изменение или косметическое.

Level B — Module Coverage Map: Quint Code старается понимать структуру проекта — какие модули есть, какие из них покрыты решениями, а какие — слепые зоны. “Модуль payments/ — 12 файлов, ноль решений. Это ваше самое рискованное слепое пятно.” Если честно я в восторге от этой фичи.

Level C — Dependency Impact Analysis: И наконец, когда модуль A меняется, Quint Code в какой то момент увидит это в графе зависимостей и отметит решения по модулям B и C которые зависят от A. Это уже серьезный кросс-модульный архитектурный анализ. Ни один инструмент сейчас этого не делает — IDE показывают код, ADR-тулы показывают решения (и то не факт что не устаревшие). Никто не связывает одно с другим. Quint Code только начал пытаться это делать, фича сырая, но даже в таком виде она просто великолепна. Я очень постараюсь сделать ее настолько стабильной насколько можно.

Что ещё виднеется на горизонте, но не факт что мы туда придем

Несколько идей которые я исследую:

Cross-Project Decision Memory — ~/.quint/global/, персональная база знаний которая растёт между проектами. Решил “PostgreSQL вместо MySQL” на проекте A с пруфами почему. На проекте B возникает аналогичная проблема — Quint Code говорит: “Ты уже принимал это решение, вот аргументы. Но давай всё-таки перепроверим, потому что это другой проект, значит другой контекст, доверие снижено, но идея то может быть хорошая!” В общем – каждый проект делает вашего агента умнее.

Adversarial Verification — перед записью решения, второй проход: контраргументы, проверка на self-referential evidence (когда агент ссылается на собственные выводы как на доказательство), атака на заявленное слабое звено. Если решение выживает — получает верифицированный статус. Если нет — возвращается на доработку.

Adversarial Verification уже в dev ветке, минимальная реализация оказалась тривиальной – поправить промпт команды /q-decide.

Team Decision Sync — совместная работа нескольких инженеров над одной .quint/ базой. Когда Вася и его агент решают задачу по стратегии кэширования — Семен с его агентом это увидят. Когда доказательства Семёна опровергают решение — оно автоматически устаревает. Это наверное самая большая “фича”, очевидно что тут надо будет разрабатывать целую платформу вокруг quint code.

Decision-as-Infrastructure — решения перестают быть документацией в коде и выходят на уровень инфры. Можно было бы сделать CI/CD гейты на базе R_eff. PR-чеки которые показывают какие решения затронуты изменениями! То есть это ход на автоматическое превращение результатов тестов в улики, которые обновляли бы базу решений проекта. Но и это большая “фича”, опять про платформу.

Заключение

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

Просто установите Quint Code и попробуйте – весь цикл, или самый простой режим. Я буду очень рад услышать ваши отзывы и предложения!