Два процесса, одна задача (КК, Глава 1)

Почему отношения «начальник → подчинённый» и «человек → инструмент» не работают. Модель сопроцессоров. Как устроено разделение когнитивной нагрузки. Что может только человек, что может только AI, и где пересечение.

Неправильные метафоры

Когда человек впервые садится работать с языковой моделью над реальным проектом (не над игрушечным «Hello World на Rust» и «TODO-list на React»), а над чем-то, что должно работать в продакшене, — он неизбежно начинает с одной из двух ментальных моделей.

Модель «начальник — подчинённый». Человек формулирует задачу. AI выполняет. Человек проверяет. AI исправляет. Это привычная схема — так устроена большая часть рабочих отношений в индустрии разработки. Начальник знает, что нужно сделать, а подчинённый знает, как это обычно делается. Ответственность это привилегия и проклятье начальника, бездумное исполнение остается на линейных сотрудниках.

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

Но главная проблема не в этих ограничениях. Главная проблема — в распределении когнитивной нагрузки. В модели «начальник — подчинённый» вся интеллектуальная работа лежит на начальнике: планирование, декомпозиция задач, верификация результатов, поддержание общей картины. AI в этой модели — просто чуть более быстрые руки, чем у самого начальника.

Но если вам нужны только быстрые руки, зачем платить за самую мощную языковую модель в мире?

Если вы хоть раз работали начальником, вам должна быть знакома боль, когда исполнители постоянно подходят и спрашивают у тебя «а как это делать, я же не умею!». Время тратится не на настоящую работу (стратегию, вижен, политику, и в конечном счёте — getting things done), а на «руко-водство», т.е. натурально — вождение чужими руками. Если в это слишком сильно залипнуть, то вся настоящая работа будет полностью провалена, и проект пойдет на дно. Наверное, все это видели много раз. Повторить всё то же самое, но только с языковой моделью — было бы вдвойне тупо.

Модель «человек — инструмент». Человек использует AI как продвинутый автокомплит. Пишет начало функции, AI дописывает. Описывает компонент одним предложением, AI генерирует код. Это то, что инфоцыгане называют «AI-ассистент» — помощник, который ускоряет рутину.

Почему инфоцыгане? Да кто бы еще мог внятно объяснить, как эта модель может помочь с чем-то серьезным. Для маркетолога важна красота аналогии, яркость метафоры. Тут метафора ясная, AI-ассистент - это такой виртуальный секретарь, который делает тучу работы, а в промежутках приносит горячий кофе и томно заглядывает в глаза. Теперь вы как разработчик, представьте — вы смогли бы так писать код, общаясь с кодом через секретаря? Постоянно кричать «Аллочка, у нас отмена»?

Эта модель работает для мелких задач. Но для проекта длиной в месяцы она разрушительна. Потому что инструмент не имеет собственного «понимания» проекта. Он не видит общую картину. Он оптимизирует локально — текущий файл, текущую функцию — и может при этом разрушать глобальную согласованность системы. Каждое использование «инструмента» — это отдельный акт, не связанный с предыдущими.

В обеих моделях есть общая ошибка: человек берёт на себя 100% когнитивной нагрузки. AI выполняет механическую работу — набирает текст, генерирует шаблонный код, форматирует. Но думает только человек. А потом человек выгорит в угли, конечно же. К сожалению, человек не железный и не предназначен для 100% загрузки мозга совершенно новыми не-рутинными задачами.

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

Что такое сопроцессор

Есть третья модель, и она работает (по крайней мере у меня). Но она требует ментального переключения, которое многим даётся тяжело — особенно опытным разработчикам.

Представьте себе систему из двух процессоров, работающих над одной задачей. Не один главный и один вспомогательный — два равноправных процессора с разной архитектурой. Как CPU и GPU в современном компьютере: CPU хорош в последовательных вычислениях со сложными зависимостями, GPU — в массивном параллелизме простых операций. Они не конкурируют за звание самого главного и «лучшего». Они разные, и сила системы — в их комбинации.

Человек и AI — это два процесса с радикально разной архитектурой:

Процесс «Человек» оптимизирован для:

• Persistent memory — помнит всё между сессиями, неделями, годами;

• Семантическое понимание — видит намерение за словами, чувствует «дух» решения, а не только его букву;

• Интуиция — ощущает «что-то не так» до того, как может это формализовать;

• Медленная, но глубокая верификация — может проследить цепочку зависимостей через весь проект;

• Принятие решений в условиях неопределённости;

• Вкус — эстетические, этические, UX-решения.

Процесс «Человек» плохо справляется с:

• Высокой пропускной способностью — читает и пишет медленно;

• Механической согласованностью — пропускает опечатки, забывает обновить связанные файлы;

• Удержанием большого количества деталей одновременно (7±2);

• Рутинными повторяющимися операциями;

• Работой под усталостью и стрессом;

• Удержанием фокуса в виртуальном мире — его постоянно отвлекает мир реальный.

Процесс «AI» оптимизирован для:

• Высокой пропускной способности — генерирует тысячи строк кода за минуты;

• Механической согласованности в рамках одной сессии;

• Широкой, хотя и неглубокой эрудиции — знает синтаксис десятков языков, API сотен библиотек;

• Рутинных операций — рефакторинг, форматирование, шаблонный код;

• Работы с формальными структурами — парсинг, трансформация, генерация по шаблону;

• Абсолютной неутомимости (в пределах сессии и квадратичного бюджета токенов).

Процесс «AI» плохо справляется с:

• Persistent memory — забывает всё между сессиями;

• Семантическим пониманием — следует букве, не духу;

• Поддержанием когерентности на длинных дистанциях;

• Принятием решений, требующих контекста за пределами окна

• Обнаружением собственных ошибок;

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

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

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

Также не стоит забывать, что реальные системы редко разрабатываются одним человеком с одним ИИ. Обычно, это коллектив разработчиков с десятками разных AI. Метафора "один к одному" здесь используется для упрощения и будет усложняться по ходу повествования.

Это описание реальной архитектуры, с которой вы работаете каждый день, даже если привыкли её игнорировать. И как любая архитектура, она имеет конкретные следствия для того, как нужно проектировать взаимодействие.

Как выглядит продуктивная сессия

Рассмотрим конкретный пример. Я выберу из своей практики, но вы можете подобрать что-то свое. Представьте, что вы строите сетевой протокол для новой версии Telegram-клиента. У вас есть спецификация, описывающая формат сообщений. Вам нужно реализовать верификацию — проверку, что сообщение, которое пришло от клиента через новую версию протокола совпадает с тем, что было отправлено в Telegram через предыдущую его версию.

(Дальше будет какое-то количество понятий, с которыми вы, вероятно, еще не знакомы. Не потому что вы чего-то не знаете, а потому что я не описал их подробно. Более детально об элементах стека разработки мы поговорим в следующих главах).

Продуктивная сессия выглядит так:

Утро. Вы открываете WAL (Write-Ahead Log — файл, описывающий текущее состояние проекта). Читаете: «PROP-003: верификация. Реализован матчинг по хэшу. Не реализовано: таймауты для неверифицированных сообщений.» Вы думаете: таймауты — это следующий шаг. Открываете спецификацию, перечитываете секцию про таймауты. Решаете: 600 секунд, после чего сообщение получает статус TIMEOUT. Обновляете спеку.

Сессия с AI. Вы пишете: «Реализуй логику таймаутов по spec://oproto/PROP-003#verification.timeout. С прошлой сессии я изменил таймаут с 300s на 600s в спеке — учти. Не трогай матчер, только таймауты.»

AI читает boot-файл проекта, WAL, указанную спецификацию. Генерирует код: фоновый таск, который каждые 60 секунд проверяет неверифицированные сообщения старше 600 секунд и помечает их как TIMEOUT. Пишет три теста. Запускает — два проходят, один падает (ошибка в обработке edge case, когда сообщение верифицируется в момент проверки таймаута). AI исправляет, прогоняет тесты снова — все зелёные. Обновляет WAL: «PROP-003: таймауты реализованы, все тесты проходят.»

Верификация. Вы смотрите diff. Видите: новый файл timeout.rs, изменения в двух существующих файлах, три новых теста, обновлённый WAL. Пробегаете глазами тесты — покрывают ли они то, что описано в спеке? Да. Пробегаете diff в спеках — AI не менял спеку (правильно, вы сами её обновили утром). Коммитите.

30 минут. Одна конкретная задача. Результат: работающий код, соответствующий спецификации, с тестами.

Непродуктивная сессия выглядит так:

Вы пишете: «Допиши верификацию сообщений.» AI не знает, что конкретно «допиши». Начинает с чтения всего кода (тратит токены, вам приходится пополнять кошелёк на очередные 200 баксов). Обнаруживает, что матчер уже написан. Решает, что нужны таймауты (угадал). Но не знает, какой таймаут — в спеке написано 600s (вы обновили утром), но AI читал спеку в кэше из прошлой сессии, где было 300s. Генерирует код с 300s (не угадал!). Попутно решает «улучшить» матчер — добавляет нормализацию Unicode, которая не описана в спеке и ломает существующие тесты.

Вы видите diff: изменения в пяти файлах вместо двух, сломанные тесты, таймаут не тот. Тратите время на разбор: что из этого правильно, что нет. Просите исправить. AI исправляет, но в процессе снова трогает матчер. Ещё итерация. Ещё одна.

Два часа. Неопределённая задача. Результат: код, который может быть правильным, а может быть нет, и вам нужно внимательно вычитать каждую строку, чтобы это понять.

Разница между этими двумя сессиями — не в качестве AI. Это один и тот же AI — та же модель, тот же тулинг. Разница — в том, как человек выполнил свою часть работы. В продуктивной сессии человек:

1. Прочитал WAL (поддержание контекста)

2. Принял решение о таймауте (архитектурное решение)

3. Обновил спеку (фиксация решения)

4. Дал точную задачу с адресом в спеке (коммуникация)

5. Проверил diff (верификация)

В непродуктивной сессии человек сделал одно действие: «допиши». Вся остальная работа — угадывание, восстановление контекста, принятие решений — легла на AI. И AI с ней не справился, потому что это не его сильная сторона.

Разделение когнитивной нагрузки

Из модели сопроцессоров следует конкретная таблица ответственности. В ней минимум абстракций, она применима к каждому рабочему дню.

Только человек (AI может, но плохо):

• Думать о проекте на уровне смыслов и связи с Реальностью

• Принимать архитектурные решения на уровне смыслов

• Определять приоритеты задач

• Чувствовать, что «система ведёт себя не так»

• Помнить контекст между сессиями

• Поддерживать глобальную когерентность

• Решать, когда спецификация устарела

• Общаться с пользователями и понимать их потребности

• Принимать этические решения

Только AI (человек может, но неэффективно):

• Принимать архитектурные решения на уровне мелких деталей

• Генерировать большие объёмы согласованного кода за минуты

• Помнить точный синтаксис тысяч API

• Выполнять механические рефакторинги (переименование, изменение сигнатур через всю кодовую базу) там, где IDE ломается

• Генерировать шаблонный код (тесты, boilerplate, шаблоны, конфиги)

• Проверять формальные свойства (линтинг, типизация, форматирование)

• Держать в «голове» все детали файла одновременно (в пределах контекстного окна)

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

Оба, но по-разному:

• Написание спецификаций. Человек формулирует идею и принимает решение. AI структурирует, формализует, находит пробелы. Человек утверждает финальную версию.

• Код-ревью. AI проверяет формальные свойства (компилируется или нет проходят ли тесты, доволен ли линтер). Человек проверяет семантику (код должен делать что нужно человеку, а не что формально написано в коде или спеках).

• Отладка. AI собирает информацию (логи, стектрейсы, контекст, в реальном времени общается по десяткам debug-протоколов одновременно). Человек формулирует гипотезу. AI проверяет её конкретными тестами.

• Обновление документации. AI генерирует обновление по диффу кода. Человек проверяет, что обновление отражает реальность, а не механическую трансляцию изменений.

Важное наблюдение: граница между зонами подвижна. Она зависит от состояния модели (насколько далеко мы продвинулись в возможностях AI), от конкретного проекта (критичность и сложность предметной области), и даже от времени дня (свежий человек утром берёт на себя больше, чем уставший вечером - ровно как и нейросеть в 12 часов ночи может лечь под нагрузкой на Amazon us-west-1).

Но одно остаётся неизменным: человек владеет когерентностью, иначе говоря — согласованностью между итерациями разработки и областями знаний. Это самая важная роль в системе, и мы посвятим ей отдельную главу.

Shared memory: как процессы общаются между собой

Два процессора бесполезны, если они не могут обмениваться данными. В операционных системах процессы общаются через IPC (Inter-Process Communication): pipes, sockets, shared memory, файлы. На уровне железа процессоры общаются через общую шину, shared memory с протоколами когерентности кэшей (MESI/MOESI) и прерывания — один процессор записывает в память, другой видит изменение и реагирует. У каждого механизма свои свойства: скорость, надёжность, возможность одновременного доступа.

В системе «человек — AI» роль IPC играют файлы проекта и состояние инструментов (например, интерактивное состояние браузера в момент AI-отладки). Но не все файлы одинаково важны. Можно выделить три уровня:

Уровень 1: Управляющие файлы (человек → AI)

• Boot-файл (BOOT.md, AGENTS.md, CLAUDE.md) — инструкции, как читать всё остальное. Аналог конфигурации BIOS.

• WAL (Write-Ahead Log) — текущее состояние проекта. Аналог журнала файловой системы или основного леджера в крипте.

• Спецификации (PROP, FEAT) — описание того, что система должна делать. Аналог shared memory, в которую пишут оба процесса, но с приоритетом человека.

Уровень 2: Артефакты (AI → человек, верифицируемые)

• Код — генерируется AI, верифицируется человеком через diff или суммаризацию diff (если сам diff настолько велик, что неспособен поместиться в быструю память человека).

• Тесты — генерируются AI по спекам, верифицируются прохождением.

• Обновления спек — AI может предлагать изменения, человек утверждает.

Уровень 3: Сигналы (в обе стороны)

• REVIEW-маркеры в коде — AI помечает места, где принял неочевидное решение.

• Git diff — сигнал от AI человеку: «вот что изменилось».

• Changelog в спеках — сигнал об эволюции решений.

• Сломанные тесты — сигнал о расхождении кода и спеки.

У этого IPC есть специфические требования, которых нет у обычной документации:

Адресуемость. Каждый пункт в каждом файле должен быть точно указуем. Когда AI дрифтует — а он будет дрифтовать, это неизбежно — человек должен за пять секунд найти и показать, что именно нарушено. Не «ты неправильно сделал верификацию», а «ты нарушаешь spec://oproto/PROP-003#verification.timeout — таймаут должен быть 600s, а у тебя 300s».

Для этого нужна адресная схема. Мы в Anarchic используем формат:

spec://<модуль>/<документ>#<секция>[.<подсекция>]

URI — это стандарт, который AI хорошо понимает из обучающих данных (ссылки в интернете, RFC, документация). Формат #секция — это стандартные якоря в Markdown. AI может найти файл по пути, секцию по якорю, и процитировать нужный пункт. Минимум токенов, максимум точности.

Атомарность обновлений. Когда AI обновляет спеку или код, изменение должно быть одним логическим шагом, видимым в diff. Если в одном коммите смешаны три несвязанных изменения — человек не сможет верифицировать эффективно. Каждый коммит — это одна мысль.

Практическое правило: один коммит = одно изменение в одной спеке + связанные изменения в коде и тестах. Не больше.

Программисты-люди очень не любят делать отдельные коммиты. Потому что это сложно. Я думаю, всем понятно, насколько чудовищная когнитивная нагрузка ложится на программиста, который прототипировал фичу в течение недели, а теперь ее нужно разбить на 40 разных коммитов с подробным описанием. У нейросетей нет таких проблем, они будут счастливы написать целую поэму в commit message и залить это с произвольной гранулярностью.

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

Иерархия приоритетов:

1. Человек побеждает спеку (человек может изменить спеку)

2. Спека побеждает код (код должен соответствовать спеке)

3. Тесты — это спека в исполняемой форме (если тест противоречит спеке, это баг в тесте или в спеке, но не в обоих)

Камень, ножницы, бумага — камень, ящерица, Спок.

Если AI считает, что спека ошибочна — он не молча переписывает спеку. Он реализует то, что написано в спеке, добавляет REVIEW-маркер («я думаю, здесь лучше сделать X, потому что Y»), и сообщает человеку в отчёте. Человек решает проблему в следующем цикле.

На первый взгляд это выглядит как бюрократия. Но заметьте, основная проблема бюрократии в Реальности — то, что это долго, дорого, и в конечном итоге не приводит ни к чему хорошему. Описанные выше процессы — быстрые, дешевые (явно дешевле в токенах, чем работа в режиме ризонинга с никак не описанным кодом), и приводят к фантастическому росту качества результата.

Технологически, это memory fence из concurrent programming. Без явных правил приоритета два процесса неизбежно создадут race condition, и результат будет непредсказуем. Мы решаем это классическими методами, только в некой лайтовой адаптации на нейросетевую специфику.

Архитектура памяти

Это, возможно, самый важный и сложный раздел во всей AI разработке (по состоянию на начало 2026 года). По сложности это похоже на concurrent programming в классическом программировании. Тем не менее, чтобы освоить самую базу, становиться Лёшей Шипилёвым совершенно не обязательно.

Всё, что мы будем обсуждать дальше — когерентность, дрифт, WAL, стратегия сессий — вытекает из одного фундаментального факта:

AI не имеет памяти между сессиями. Совсем.

Каждая новая сессия Claude Code или GigaCode Agents — это новый процесс, который ничего не знает о предыдущих. Он не помнит, какие решения были приняты. Не помнит, какие подходы не сработали. Не помнит, какой стиль кода вы предпочитаете. Не помнит, что вы вчера потратили два часа на исправление бага в reconnection logic, и что этот код теперь хрупкий и его нельзя трогать.

WAL и спецификации — это единственная память, которую AI имеет о прошлом.

И то, если вы удосужились этот самый WAL организовать вручную. По-умолчанию его нет. Производители AI инструментов сейчас пытаются внедрять свои инструменты для сохранения памяти, всевозможные MEMORY.md. Пользоваться ими можно, но вот какой нюанс: никакие из этих инструментов не знают, что именно вы делаете в вашем коде, как именно устроен производственный процесс. Два разных подхода к программированию требуют два совершенно разных подхода к программированию AI-лога. Это чем-то похоже на разницу между обычными банковскими транзакциями и Биткоином - и у тебя деньги и у меня деньги, в обеих местах база и лог, но есть нюанс.

Давайте это прочувствуем на аналогии. Представьте, что каждое утро к вам в офис приходит новый разработчик. Блестящий, талантливый, знающий все языки и фреймворки. Но каждый вечер он уходит и никогда не возвращается. Завтра придёт другой — такой же талантливый, но без единого воспоминания о вашем проекте. Всё, что он знает — это то, что написано в документации и коде. Если в документации написано «используем SHA-256», а вы вчера решили перейти на blake3, но не обновили документацию — новый разработчик будет использовать SHA-256.

Это точное описание того, что происходит с AI между сессиями. И из этого следует несколько неочевидных выводов.

Вывод 1: Записывай решения, а не факты.

Фраза «используем blake3» — это факт, его видно из кода. Фраза «используем blake3, потому что SHA-256 тянет за собой OpenSSL dependency, а мы хотим минимальный binary size для edge-серверов на слабом железе» — это решение. Второе в десять раз ценнее.

Почему? Потому что факт можно восстановить из кода. А причину решения — нельзя. И когда через месяц вы (или AI) будете думать «а может, перейти на SHA-256?», записанная причина мгновенно ответит: нет, потому что OpenSSL. Без записанной причины вы потратите час на повторный анализ.

Это не уникально для AI-разработки. Это хорошая практика в любом проекте. Но в AI-разработке это критически важно, потому что AI не может «вспомнить» — он может только прочитать.

Также, из этого следует важный и болезненный факт: копировать чужие промты из интернета (например, готовый промт для WAL-лога) — намного менее эффективно, чем поставить задачу для ИИ переизобрести этот лог заново. Нужно копировать не промт-реализацию, а промт-задачу — предварительно переработав эту задачу для каждого конкретного проекта.

Вывод 2: Всё, что не записано — не существует.

В обычной разработке значительная часть знаний о проекте живёт в головах разработчиков. «Почему мы используем эту библиотеку?» — «Потому что Вася три месяца назад попробовал пять альтернатив и эта единственная работала с нашей версией glibc.» Это tribal knowledge, и оно работает, пока Вася в команде. Это common sense — но до тех пор, пока команда не сменилась, и никакого общего сенса с новой командой больше нет.

В системе «человек — AI» tribal knowledge работает ещё хуже. AI не может подойти к Васе и спросить подробности. Если знание не записано в файле, который AI может прочитать — этого знания не существует для AI. И AI примет решение без этого знания. Возможно, неправильное.

Практическое следствие: каждый раз, когда вы принимаете решение — запишите его. Не потому что вы забудете (хотя забудете — через два месяца интенсивной работы). А потому что AI никогда и не знал ничего, и узнает только из записи.

Вывод 3: Контекстное окно — это рабочая память AI, и она конечна.

Claude имеет контекстное окно порядка 200 000 токенов. Это много — это примерно 500 страниц текста. Но это всё: и спецификации, и код, и ваши промпты, и ответы AI. К середине длинной сессии значительная часть окна занята историей разговора, и AI начинает «забывать» то, что было прочитано в начале.

Причём 200 000 — это формальный размер буфера, а не реальная рабочая ёмкость. Часть окна съедают системные инструкции и нарастающая история диалога. Из оставшегося модель эффективно фокусируется на 30–50 тысячах токенов — начало и конец контекста, «горячие зоны». Середина — зона пониженного внимания (эффект «lost in the middle», эмпирически подтверждённый Стэнфордом в 2023 году). Пункт спецификации, загруженный 100K токенов назад, формально «виден», но его вес в матрице внимания статистически ничтожен рядом с последним промптом.

Это не метафора «забывания». Технически, весь текст по-прежнему находится в окне. Можно даже проскроллить его мышкой в окне чата! Но механизм внимания (attention) распределяется на большее количество токенов, и отдельные пункты спецификации получают меньше веса. Результат: AI начинает «импровизировать» вместо того, чтобы следовать спеке.

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

Практическое следствие: короткие сессии лучше длинных. Лучше пять сессий по 30 минут, чем одна на 2.5 часа. Каждая новая сессия — это чистое контекстное окно и свежее внимание. (Мы подробно разберём это в главе о дрифте.)

Архитектура памяти системы

Если свести всё вышесказанное в одну схему:

Стратегия, которая следует из этой архитектуры:

Используй файлы как внешнюю память для обоих процессов. Всё, что важно, должно быть записано. Не потому что AI забудет (хотя забудет). А потому что и ты забудешь. Через два месяца интенсивной работы ты не вспомнишь, почему выбрал конкретную библиотеку для хэширования. Но если в PROP-003 написано «blake3, потому что быстрее в 3 раза и не требует OpenSSL» — вспомнишь за секунду.

Минимизируй нагрузку на рабочую память обоих. Для AI это значит короткие сессии, точные задачи, ссылки на конкретные секции спек вместо «прочитай всё». Для человека — это значит спеки вместо кода, diff вместо полного чтения, чеклисты вместо «держи в голове».

Файлы — единственное пересечение долгосрочной памяти. Всё, что живёт только в голове человека — невидимо для AI. Всё, что AI «понял» в текущей сессии — исчезнет с закрытием сессии. Только файлы переживают обоих.

Что значит «работать вместе»

Мы описали архитектуру. Теперь — что из неё следует на практике.

«Работать вместе» в модели сопроцессоров — это не «ты скажи, я сделаю». Это непрерывный цикл:

В каждом цикле обе стороны делают нечто, чего другая сторона сделать не может. Человек принимает решение (AI не имеет контекста для решений за пределами сессии). AI генерирует артефакты (человек делает это в 10-100 раз медленнее). Человек верифицирует (AI не может надёжно проверить собственную работу). AI обновляет shared state (WAL, спеки, тесты — механическая работа, которая идеально ложится на AI). Человек переносит знания между сессиями (через WAL и свою голову).

Это полноценный симбиоз человека и машины. Убери любую из сторон — система перестаёт функционировать. Без человека AI дрифтует и теряет когерентность за несколько сессий. Без AI человек пишет код в 100 раз медленнее и не успевает к дедлайну.

И последнее, что стоит сказать в этой главе. Модель сопроцессоров — это не конечная точка. Это модель для февраля 2026 года, когда AI достаточно умён, чтобы быть настоящим партнёром, но недостаточно надёжен, чтобы работать автономно. Через год модель изменится. Через пять лет — может быть, до неузнаваемости. Но сейчас — это лучшая модель, которую мы нашли. И она работает.

Что дальше

Это только первая глава книги. Дальше оно будет потихоньку писаться и выкладываться — вначале на сайт, потом на Хабр. Следите за обновлениями в канале Откровения (https://t.me/tg_1red2black) или в X//Twitter (https://x.com/1red2black).