1. Проблема

AI-инструменты для разработки доступны всем. Результаты - нет.

Copilot, Claude, GPT - генерируют код за секунды. Но попробуйте построить
PKI-систему с аппаратным TRNG, тремя MCU-платами и деплоем на ARM64. Не
лендинг. Не TODO-приложение. Систему, где нарушение контракта на генерацию
ключей - не ошибка, а уязвимость.

Проблема не в качестве генерации. Проблема в контексте.

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

Три уровня потери:

Внутри сессии: на 50-м сообщении агент забывает что было на 10-м
Между сессиями: новый чат = чистый лист, каждый раз заново
Между проектами: переключился - потерял всё

На одном проекте это терпимо. На одиннадцати - это стена. 420+ сессий, и каждая
начинается с нуля, если не решить проблему системно.

Вайб-кодинг - термин, который описывает работу с AI без структуры. "Напиши мне
X" -> получил код  -> вставил  -> работает (или нет) -> следующий промт. Для
лендинга хватает. Для системы с аппаратным TRNG, тремя MCU-платами,
SELinux-политиками и FIPS-совместимой криптографией - нет. Не потому что AI
плохой. Потому что без методологии работы с AI сложность побеждает.

Шкала: вайб-кодинг -> структурированные промты -> оркестрация сессий -> полная
система с контрактами. Большинство застревает на первых двух уровнях.

2. Решение: файлы вместо инфраструктуры

Большие компании строят RAG-пайплайны: vector DB, embedding-сервер, chunking,
retrieval tuning, GPU. Месяцы работы команды.

0.agent делает то же самое через readFile:

RAG pipeline -> 0.agent:

Vector search -> ROUTE_CACHE.json (650 строк, 3% контекста)
RAG retrieval -> CONTEXT_LEVEL_1/2/3 (200/700/2000 токенов)
Fine-tuning -> Компетенции + роли (предметные знания проекта)
Evaluation pipeline -> drift_check.py (84 проверки, 0 расхождений)
Стоимость инфраструктуры: миллионы $ + команда DevOps -> текстовый редактор + git

Это не упрощение. Это осознанный выбор: readFile детерминирован, vector search
- нет. Когда речь о криптографических контрактах, детерминированность - не
роскошь, а требование. Ты точно знаешь что загружено в контекст. С RAG - надеешься.

Принцип: файловая система - это база данных. Markdown - формат. Git -
версионирование. Никакой инфраструктуры кроме того что уже есть. Не нужен Redis
для кэша, не нужен PostgreSQL для метаданных, не нужен S3 для хранения. Всё что
нужно - текстовый редактор и git.

Пять механизмов:

 Маршрутизация - JSON-файл, 3% контекста при старте вместо 19%
 Сессии с уровнями контекста - L1/L2/L3, 8 типов включая оркестраторы
 Роли - режимы мышления: analyst видит архитектуру, coder - код, tester - edge cases
 Контракты (SDD/DbC) - формальные PRE/POST/INV на поведение агента
 Правила - кодифицированный опыт, каждое правило - шрам от реальной проблемы

Это не фреймворк, спроектированный на доске. Это система, выросшая из 420+
сессий. Каждый механизм - ответ на конкретную проблему. Вместе - метод
оркестрации AI-агента.

Текущая реализация работает с Claude (Anthropic), но файлы портативны - vendor
lock-in отсутствует. Завтра локальные модели дорастут - система переносится без изменений.

3. Доказательство: pki-on-box

Теория без proof - маркетинг. Вот цифры:

Коммитов: 129
PR (merged): 15
Веток: 34
Дни активной работы: 10 (из 16 календарных, 27.03 - 11.04)
Автор: 1 человек
Python файлов: 36
C файлов (firmware): 19
Тестов: 62 contract + 15 HW + unit (99+ passed)
MCU борды: 3 (STM32G474, STM32G431, STM32H750)
Целевая платформа: RK3328 ARM64 (Cortex-A53, 2GB RAM)
Стоимость железа: ~$129 (SBC $111 + STM32 $18)
Стоимость токенов AI: 1208 руб за 18 из 35 сессий (остальные без трекинга)

Репозиторий: github.com/vasilievsv/hw.pki-on-box

Архитектура: тепловой шум с аппаратного TRNG -> DRBG (NIST SP 800-90A) ->
генерация ключей -> CA -> сертификат X.509. Entropy chain: физический процесс
(тепловой шум на ADC микроконтроллера) -> кондиционирование -> DRBG seed ->
криптографически стойкая последовательность. Три мира: Windows (разработка),
Linux ARM64 (продакшн), MCU (firmware). Деплой через SSH, systemd, без Docker
на железке. Стоимость железа: $129 (RK3328 плата + STM32 борда).
Производительность: 15.6 КБ/с энтропии, 1.6с на выпуск сертификата.

Безопасность: SELinux enforcing + eBPF-фильтры + systemd sandboxing. Zero
trust: HSM изолирован от PKI Core, коммуникация только через unix socket.
Firmware hardening: 12 уязвимостей закрыты по NIST 800-90B (6 CRITICAL). Ноль открытых.

Два кейса:

53 руб / 9 минут - оркестратор-сессия: 99 тестов, zeroization, FIPS
KAT, CI security pipeline. Агент в роли architect декомпозировал задачу на 8
дочерних сессий, каждая со своей ролью.

5 руб / 2 минуты - три MCU-платы (STM32G474, G431, H750),
PlatformIO, firmware для аппаратного TRNG. Класс задач убит: конфигурация
embedded-проекта из "часы мучений с HAL" превратилась в рутину. Агент в роли
firmware-coder знает HAL, знает PlatformIO, знает pinout конкретной борды -
потому что компетенции загружены в контекст.

35 сессий. 6 ролей (analyst, architect, coder, tester, firmware-coder, devops).
3 оркестратора. 906 запросов к модели. 18.4 часа суммарной работы. Один человек.

Для контекста: оценка аналогичной работы без агента - 40+ человеко-часов
квалифицированного инженера. С учётом embedded-части (firmware TRNG, HAL,
PlatformIO) и DevOps (systemd, SELinux, eBPF, деплой на ARM64) - скорее 60+.
Здесь 18.4 часа. Разница не в скорости набора кода. Разница в том, что агент
переключается между ролями без потери контекста: architect декомпозирует, coder
реализует, tester проверяет, devops деплоит - и каждый "помнит" решения предыдущего.

4. Контракты: Design by Contract в эпоху AI

Бертран Мейер сформулировал Design by Contract в 1986 году. Формальные
контракты между модулями: предусловия, постусловия, инварианты. Красивая
теория. Не взлетела - двойная работа: человек пишет и контракт, и код.

AI-агент убирает то, что убило DbC. Человек пишет контракт. Агент пишет код и
тесты. Человек проверяет контракт, а не тысячи строк реализации. Контракт
становится единственной задачей человека. Всё остальное делегировано.

Это не теория. Это рабочий процесс: контракт -> агент генерирует реализацию ->
тесты проверяют postconditions -> автоматическая проверка находит расхождения.

Мейер (1986) -> С AI-агентом (2026):

Кто пишет контракт: Человек -> Человек
Кто пишет код: Человек -> Агент
Кто проверяет: Компилятор Eiffel -> Агент + тесты + автоматическая верификация
Почему не работало: Двойная работа -> Работа делегирована

Реальный контракт из pki-on-box - генерация ключей:

   contract: key_generation
     PRE:
       - DRBG.seeded == true
       - DRBG.reseed_counter { max_requests
       - algorithm  {RSA-2048, RSA-4096, ECDSA-P256, Ed25519}
     POST:
       - private_key.encrypted(AES-256-GCM)
       - nonce.unique()
       - public_key = derive(private_key)
     INV:
       - padding == RSA-PSS (подпись) | RSA-OAEP (шифрование)
       - PKCS#1 v1.5 == ЗАПРЕЩЕНО

Нарушение INV (PKCS#1 v1.5 вместо RSA-PSS) - это не баг. Это атака
Блейхенбахера. Контракт предотвращает класс уязвимостей до того, как код написан.

Контекст: Claude Mythos нашёл 0-day в OpenBSD (27 лет), FFmpeg (16 лет), Linux
kernel, Rust unsafe. AI ломает быстрее, чем люди чинят. Язык не спасает - Rust
unsafe это доказал. Контракты работают выше уровня языка.

DbC Мейера - ответ на угрозу, которую показал Mythos. pki-on-box - живое
доказательство: формальные гарантии на криптографию, не "надеемся что тесты поймают".

Контракт на выпуск сертификата:

   contract: certificate_issuance
     PRE:
       - issuer_ca.valid() && !issuer_ca.revoked()
       - csr.signature.verify() == true
     POST:
       - cert.serial.unique()
       - cert.signature.verify(issuer_ca.public_key) == true
       - cert.extensions.key_usage.set()
     INV:
       - cert_chain.depth {= max_path_length
       - root_ca.offline == true (air-gapped)

Два контракта - два стыка архитектуры. На каждом стыке формальные гарантии.
CRYPTO_COMPLIANCE_REVIEW нашёл 2 CRITICAL проблемы именно через контрактный
подход: PKCS#1 v1.5 padding и неправильный AES mode. Без контрактов это нашли
бы тесты - может быть. Или пентест. Или злоумышленник.

Реализация contract-тестов: test_crypto_engine_contract.py

5. Вывод

Инструмент доступен всем. Метод - нет.

129 коммитов, 10 дней, $129 на железо, один человек - это не про AI. Это про
организацию работы с AI. Вайб-кодинг работает для прототипов. Для PKI с
аппаратным TRNG и формальными контрактами на криптографию нужен метод.

Метод не продаётся и не скачивается. Он выращивается - через сессии, ошибки,
рефлексию. 420+ сессий, 11 проектов, от embedded firmware до DevOps на ARM64.
Каждая сессия - решение, которое стало частью системы. Каждое правило - шрам от
реальной ошибки. Retry limit 3 - после 7 попыток починить один баг. Heartbeat
каждые 3 операции - после двух "завис?" от пользователя. Task focus - после
30-итерационного фикса pytest вместо прогона тестов.

Файлы портативны. Vendor lock-in отсутствует. Завтра локальные модели дорастут - система та же.

Проверьте. Если сможете повторить - вы на правильном пути. Если нет - задумайтесь, почему.

Ссылки
 Meyer B. "Object-Oriented Software Construction" (1988, 2nd ed. 1997)
 Meyer B. "Applying Design by Contract" (IEEE Computer, 1992)
 NIST SP 800-90A: Recommendation for Random Number Generation Using
Deterministic Random Bit Generators
 NIST SP 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation
 pki-on-box на GitHub