Я хотела дать AI память. Пришлось организовать работу

Часть I. Как память превратилась в рабочий процесс

У меня есть три правила работы с контекстом.

Первое правило работы с контекстом — выносить его из чата.

Второе правило работы с контекстом — прежде чем выносить, нужно сортировать.

Третье правило работы с контекстом — не в контексте дело.

Только не говори, что дело опять во мне.

Последнюю фразу произношу я, мысленно обращаясь к AI и закатывая глаза. Потому что третье правило звучит подозрительно. Сначала я несколько месяцев старательно строила внешнюю память ^[1], училась сохранять контекст и раскладывала его по полочкам. А потом выяснила, что хороший контекст сам по себе не гарантирует хороший результат.

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

К этому выводу я пришла не в момент озарения ^[2] под душем. Я пришла к нему длинным и местами комичным маршрутом: сначала старалась сохранять полезное, потом спасала базу от избыточного AI‑текста, затем собирала команды агентов, ускоряла ими разработку, ускоряла ими ошибки ^[3], два дня участвовала в псевдорефакторинге и только после этого начала выносить из чата не просто память, а сам рабочий процесс.

Эта история не о готовой идеальной системе. Она о том, как каждое улучшение решало одну проблему и тут же обнаруживало следующую.

Я просто не хотела повторяться

Плотно работать с AI я начала в марте 2026 года. Моя первая мотивация ^[4] была совсем не философской: я не люблю много печатать и особенно не люблю несколько раз отвечать на одни и те же вопросы.

Если я уже объяснила, чем занимаюсь, как устроена моя команда или почему в конкретном проекте принято определенное решение, мне не хотелось повторять ^[5] это в следующем чате. Поэтому я почти сразу начала сохранять полезные промпты, выжимки из разговоров, принятые решения и проектный контекст во внешней базе заметок.

Первые месяцы моя гипотеза выглядела логично ^[6]:

Чем больше качественного контекста я соберу и передам AI, тем качественнее будет его работа.

Частично это действительно сработало. Базовая информация о компании, моей роли и команде накопилась быстро. Хорошо прижился проектный слой: после завершенной итерации было удобно фиксировать принятое состояние, а в следующем чате продолжать не с нуля.

Но повседневная жизнь довольно быстро отказалась жить по моей схеме. Слой быстрых задач и входящих не прижился даже на запись. В самом начале я один раз сгрузила туда несколько задач кучкой; крупные потом выросли в отдельные проекты. Все новое продолжало жить в голове, на стикерах для встреч, в сообщениях самой себе в Teams и в файликах Notepad с именами вроде новый7. Отдельно собирать это в базу не хотелось, а возвращаться потом к накопленному — тем более.

Дорожные карты выглядели солидно, но не помогали принимать решения. Они честно рассказывали, что когда‑нибудь надо сделать, и так же честно оставались непрочитанными. Универсальные паттерны работы тоже возникали реже, чем я ожидала: далеко не каждый хороший чат производит новое знание на все случаи жизни.

Зато постепенно выяснилось, что самой базе нужны специальные правила — метаправила Obsidian. Что загружать в конкретную задачу? Чему верить при конфликте ^[7]? Кто владеет решением? Когда старый текст обновлять, а когда удалять? Ответы начали складываться в архитектуру использования: появилась карта загрузки контекста, а вместе с ней — минимальная загрузка, понятные владельцы и граница между принятым знанием и временным рабочим состоянием.

Сам факт существования заметки еще не означает, что AI найдет ее, правильно поймет, отличит решение от старой гипотезы и не прихватит еще двадцать страниц «на всякий случай». Память пришлось не только наполнять, но и маршрутизировать.

И тут обнаружился следующий парадокс ^[8]. Базу почти полностью заполнял AI. Вообще‑то так и было задумано: я же не люблю печатать. План справился с объемом, но вместе с ним масштабировал и проблему качества.

Сад, который переудобрили

В чатах AI регулярно возвращал мне текст, который был формально правильным, но плохо пригодным для жизни. Длинные введения. Повторы. Объяснения проблемы вместо решения. Текст о тексте. Иногда внезапный переход на английский, потому что, видимо, именно его не хватало для полноты картины.

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

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

Сначала я относилась к тексту бережнее. Потом поняла, что потерять часть текста безопаснее, чем сохранить красивое предложение, которое в следующей итерации разрастется на десять.

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

Постепенно archbuddy перешел от отдельных заметок к крупным материалам. И там окончательно выяснилось, что под одним именем спрятаны две разные работы: убрать типичный AI‑выхлоп и проверить архитектуру результата. Так одна роль разделилась на нулевого ревьюера и архитектора, а проверки переместились туда, где результат еще можно дешево изменить.

Сами роли при этом по‑прежнему жили в длинной инструкции внутри чата. Я должна была помнить, кого вызвать, в каком порядке и что сделать с замечаниями. Иногда забывала я, иногда AI, а иногда мы оба делали вид, что длинный промпт и есть система.

Команда ускоряет и правильное, и неправильное

Первой понятной попыткой собрать полноценную AI‑команду стала разработка AI Limit Tracker — десктопного приложения для отслеживания расхода командной AI‑подписки.

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

А потом приложение начало жить. И ломаться: сначала несколько раз в день, затем немного реже. Так продолжался месяц реальной эксплуатации.

До разработки мы не проработали пользовательские сценарии, тест‑кейсы и критерии результата. Команда быстро реализовала описанное, но описано было далеко не все нужное. Я увидела проблему с образом продукта — и сделала вывод только наполовину. Вместо того чтобы сначала разобраться, что именно и для кого должно работать, я решила еще лучше организовать процесс: усилить тестировщика, добавить автотесты, подробнее расписать передачу работы.

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

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

За два дня мы прошли несколько циклов того, что я теперь называю псевдорефакторингом. Одна итерация исправляла один аспект архитектуры. Следующая улучшала другой и попутно отменяла первое исправление. Третья возвращала прежнее состояние, но уже с дополнительным слоем совместимости.

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

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

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

В dbt-analyst предметного контекста хватало. Не хватало границ, правил миграции и способности признать, что локальные исправления больше не приближают решение.

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

Мне был нужен не еще более длинный промпт. Мне был нужен внешний воспроизводимый процесс.

Работа выходит из чата

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

Контур — не отдельный агент с красивой должностью, а постоянный механизм над конкретными задачами. Его правила задают, как собрать под задачу команду, маршрут, критерии и рабочий пакет. Роли могут запускаться параллельно, а результаты проходят через сборку и проверки. Для каждой итерации есть один владелец итоговой версии. В моей реализации организационную работу делят основной чат и специальный оркестратор; для этой истории важнее их общая функция, чем внутренняя граница.

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

Я по‑прежнему задавала цель, определяла границы, принимала результат и могла остановить неверное движение. Контур забрал повторяемую организационную работу, но не право решать, получилась ли полезная вещь.

На бумаге конструкция выглядела убедительно. Но после AI Limit Tracker и dbt-analyst я уже знала цену решениям, которые только выглядят убедительно.

Оставалось проверить контур на реальной длинной задаче.

Экзамен на семи дашбордах

Команде предстояло разобраться с семью коммерческими дашбордами, сделанными в Power BI и хранившимися в облачном сервисе Power BI и Git‑репозитории. Общая цель была шире: передать отчетность в управляемый аналитический контур. Но AI на этом этапе получил не задачу переноса, а задачу анализа. Сначала нужно было понять, что вообще стоит переносить, что переписывать, а что, возможно, закрыть.

До контура я формулировала проблему и собирала исходный контекст в обычных чатах. Затем прошли три отдельных запуска со своими задачами и сохраненным рабочим состоянием. Запуск и чат не равны, хотя мой рабочий идеал прост: один запуск — один чат. Автономным интервалом я называю участок между двумя точками моего участия, который контур проходит сам.

Запуск 1: прототип, которому я решила поверить

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

Прототип был технически насыщенным и прошел проверки по исходным критериям. Я подозревала, что с понятностью есть проблема, но не стала подробно формулировать требования: рассчитывала, что ролевые проверки сами доведут формат до ума. Это решение быстро оказалось отрезвляющим.

Запуск 2: семь карточек и тупик локальных правок

Во втором запуске контур прошел по всем семи дашбордам и сгенерировал карточки. Первый автономный интервал закончился полным набором карточек. И вот тогда стало видно, что техническая насыщенность не сложилась в понятный результат. Я вернула работу на исправление, но локальные правки начали ходить кругами: формат менялся, а бизнесовый смысл по‑прежнему тонул в деталях.

Остановить цикл помогла не еще одна формулировка «мне не нравится», а конкретная смена приоритета. Сначала нужно было показать назначение дашборда, бизнесовое объяснение и выводы. Технические сведения следовало сохранить, но убрать в доказательный слой.

Запуск 3: переосмысление и принятый свод

Третий запуск начался не со сводной аналитики по старым карточкам, а с переосмысления самого формата. Затем во втором автономном интервале контур по новым вводным пересобрал все семь карточек и сопоставил дашборды по назначению, объему, структуре, зависимостям, рискам и неизвестным местам. Получившийся свод я приняла.

Вклад в итог делился между кодом, AI‑исполнителями, контуром и мной.

• Созданный с помощью AI код извлекал и рассчитывал технические факты.

• AI‑исполнители собирали из них карточки, перерабатывали их и проводили ролевые проверки.

• Контур удерживал маршрут, рабочее состояние и сборку версии между запусками.

• Я задавала цель и критерии, меняла направление и принимала полезность итога.

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

Исследование на этом не закончилось. Мы получили базовый discovery‑срез, но еще не решили, какие дашборды переносить, какие переписывать и какие закрывать.

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

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

Но что именно в устройстве этой работы сделало маршрут воспроизводимым?

Часть II. Как устроена длинная работа с AI и где ее предел

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

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

Три слоя с разным сроком жизни

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

Поэтому сейчас у меня три слоя.

Первый — база знаний. Здесь живет принятое: факты о проекте, устойчивые правила, подтвержденные решения и готовые материалы. Не все, что когда‑либо произвел чат, а только то, что прошло человеческую приемку и должно стать долговременным контекстом.

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

Третий — рабочий пакет задачи. В нем две скорости. Команда, маршрут, критерии результата и проверки собираются под задачу и меняются сравнительно медленно. Состояние конкретного запуска меняется постоянно: что происходит сейчас, какие решения приняты в этой итерации, что заблокировано и что делать дальше.

Разница кажется бюрократической ровно до того момента, когда временная гипотеза через два‑три чата возвращается как «принятое решение». Или когда старый план продолжает командовать новым запуском, хотя половина его предпосылок уже отменена.

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

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

Три слоя разделяют сроки жизни. Само выполнение начинается, когда постоянный контур собирает внутри рабочего пакета конкретную команду.

Команда под конкретное ограбление

Тебе понадобятся три человека, чтобы сдвинуть этот чертов сейф, двое, чтобы пройти через охрану, и лучший щипач в Вегасе

«Одиннадцать друзей Оушена».

Состав AI‑команды определяется конкретным ограблением. Для исследования, архитектурного решения и публичной статьи нужны разные люди у сейфа.

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

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

Нулевой ревьюер, архитектор и остальные взрослые

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

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

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

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

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

Но состав проверяющих — только половина конструкции. Вторая половина — сколько контекста они делят между собой. Со взрослыми можно работать по‑разному.

Первый вариант — ролевой проход в текущем чате. Я прошу посмотреть на результат как редактор, архитектор или будущий получатель. Это дешево и часто полезно, но проверка видит те же предпосылки и может унаследовать те же ошибки.

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

Третий вариант — отдельное исследование качества в новом чате. Для него заново собираются входные данные и проверочная команда. Прошлая переписка не является рабочей средой проверки. Это дороже, но сильнее отделяет проверку от прежних рассуждений.

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

Два цикла и два человеческих решения

Не всякая обратная связь означает одно и то же. Иногда нужно исправить результат. Иногда — признать, что мы решали не ту задачу.

Первый случай обслуживает внутренний цикл:

выполнение -> проверка -> конкретная правка -> повторная проверка

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

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

Здесь появляется одно неделегируемое решение: распознать концептуальный тупик. AI может продолжать выпускать внешне разумные правки, каждая из которых выглядит как работа, хотя вся серия давно стоит на месте. В такой ситуации я должна остановить процесс, вернуться к проблеме и пересмотреть критерии, а не просить «попробовать еще раз, но внимательнее».

Второй случай — цикл с человеческой приемкой:

постановка -> прототип -> человеческая проверка -> новые требования -> новый запуск

Он меняет не отдельную формулировку, а сам образ результата.

Именно так в первой части изменился формат карточек дашбордов: человеческая проверка обнаружила не локальный дефект текста, а неверный информационный приоритет всей конструкции.

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

Дополнительный агент не решит за меня, полезен ли результат и не пора ли остановить процесс, который формально работает, но больше не движется к цели.

Чат закончился. Работа — нет

Чтобы новый запуск не начинался с пересказа предыдущих серий, нужен handoff — актуальный срез рабочего пакета и точка продолжения работы.

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

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

Контекстное окно по‑прежнему можно потратить быстро. В моем контуре вынос части работы отдельным AI‑исполнителям экономнее расходует активный контекст основного чата, но не делает его бесконечным. При этом физический лимит теперь часто наступает позже смыслового.

В длинной переписке остаются старые гипотезы, отмененные решения и формулировки, которые модель продолжает учитывать просто потому, что они все еще находятся рядом. Я уже могла отказаться от идеи, а ее отпечаток продолжает управлять следующими ответами. Поэтому сегодня я чаще меняю чат не из‑за тесноты, а из‑за загрязнения.

Новый чат получает не всю историю, а отобранное действующее состояние. Это не потеря памяти, а ее редактура.

При этом handoff не должен уничтожать доказательства и след решений. Временные материалы можно убрать из активного поля, но важно сохранить, что было принято, почему, какие блокеры остались и на что опирался вывод. Иначе очищение быстро превращается в археологию: «Здесь явно существовала развитая цивилизация. Судя по руинам, она даже что‑то решила».

Когда механизм продолжения уже собран, возникает следующий вопрос: можно ли перенести тот же маршрут в новую область и на гораздо большую пачку?

Шестьдесят шесть дашбордов: стресс‑тест и предел

После семи дашбордов подход переиспользовали в отдельном четвертом запуске, уже в новой области, на 66 дашбордах Power BI из облачного сервиса и Git‑репозитория. Это был не следующий этап исходного кейса, а самостоятельный стресс‑тест переносимости.

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

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

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

AI прекрасно масштабирует производство. В том числе производство чуши, если контроль качества закончился раньше пачки.

Сначала понять, что я вообще хочу

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

«Автостопом по галактике».

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

Перед началом дорогой работы это не полезная опция, а обязательный шаг. Важно сформулировать:

• какую боль ^[9] должен снять результат;

• какие сценарии он должен поддержать;

• как выглядит правильный пример;

• как выглядит неправильный пример;

• по каким критериям результат можно принять.

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

А иногда готового образа нет и у меня. Есть тревога, общее направление и надежда, что хороший результат я узнаю при встрече. Именно на это я и рассчитывала, потому что отдельно заходить в discovery и определяться не хотелось. Но если образа еще нет, узнать его при встрече не получится. Сначала придется выяснить, что именно я пытаюсь получить.

Прототип помогает сделать ожидания видимыми: превращает «не то» в конкретную обратную связь и проявляет требования, которые пришли мне в голову только после просмотра результата. Такие требования я в шутку называю «воображаемыми».

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

Практическая лестница

Полный автоматизированный контур нужен не всем и не для каждой задачи. Его цена — серьезная начальная проработка. Если задача короткая или не стоит формализации, тяжелый процесс все равно окажется дороже результата. Зато его не приходится собирать заново под каждую задачу, и повторное применение обычно снижает стартовые затраты.

Поэтому я вижу три уровня.

Минимум: сформулировать критерии правильности и встроить последовательные проверки. Хотя бы нулевого ревьюера, предметную проверку и взгляд конкретного получателя.

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

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

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

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

Автономность без передачи ответственности

— А что в это время делаешь ты?

— Чай пью и шоколадками заедаю, иначе глаз дергается

«Случайный разговор в коридоре».

У AI есть собственные ограничения. Он может ошибиться, не выполнить хорошую инструкцию или упереться в возможности модели. Этого я не контролирую. Зато я контролирую постановку, критерии, устройство процесса и решение применить результат.

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

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

После этого можно оставить AI выполнять задание и повторить про себя три правила, с которых все начиналось:

Первое правило работы с контекстом — выносить его из чата.

Второе правило работы с контекстом — прежде чем выносить, нужно сортировать.

Третье правило работы с контекстом — не в контексте дело.

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

P. S. Чтобы не поручать AI решать, что в моей статье полезно, я составила список сама

вот ссылка на статью, сделай саммари (что это за материал, о чем и зачем мне его читать), отдельно вытащи перечень полезных приемов, артефактов и важных концепций (сравни с моими материалами в обсидиане по работе с аи, раздели на группы новые приемыизвестные приемы), дай заключение стоит ли мне ее читать и в каком формате (целикомсжатую версиюизбранные выжимки)

«Классическая реакция ^[10] автора на любую статью».

Что стоит завести

Какие практики забрать

• Отвечать за работу ИИ. Человек определяет проблему и образ результата, проектирует границы и контрольные точки процесса и принимает итог.

• Делать прототип до массовой работы. Сначала один пример, обязательные проверки и человеческая приемка формата. Только потом — пачка.

• Проверять результат до человеческой приемки. Минимальный набор — нулевой ревьюер, предметная проверка и взгляд конкретного получателя. Архитектор добавляется, если результат должен встроиться в существующую систему.

• Различать три уровня проверки. Ролевой проход в текущем чате дешев и полезен, но наследует прежние предпосылки. Слепая проверка получает отдельный пакет: результат, критерии, необходимые источники, доказательства и известные риски — без хода прежнего обсуждения. Самая сильная версия — отдельное исследование качества в новом чате с заново собранными входными данными.

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

• Заранее дробить большую пачку. Лучше сразу разделить ее на части и поставить проверки качества между ними, чем ждать деградации или добавлять еще один этаж оркестраторов.

• Не переносить результат в базу знаний автоматически. Сначала человек принимает результат, затем отдельно решает, должен ли он стать постоянным знанием.

Какие роли различать

Индустриальные и функциональные роли могут пересекаться. Например, архитектор бывает предметным экспертом или постоянным проверяющим.

Правило выбора:

• чем конкретнее результат, тем проще задание;

• повторяемую функцию стоит оформить как отдельную роль;

• подробная инструкция нужна для дорогих решений и регулярно используемых ролей;

• одноразовые задания остаются в рабочем пакете, постоянные роли — в контуре.

Реализация контура

Репозиторий хранит инструкции и рабочие файлы, а за соблюдением маршрута следит AI‑оркестратор.

Жизненный цикл запуска

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

Перечень основных файлов:

Новому чату не нужно читать все подряд. Сначала он получает handoff.md, затем постановку, состав команды, план и решения. trace.jsonl нужен только тогда, когда требуется восстановить подробный ход работы.

При завершении работы нужно обновить финальный handoff.md и добавить событие run_closed в trace.jsonl. Затем решить: сохранить ли результат в базе знаний и нужно ли изменить сам постоянный контур. Рабочий пакет может ссылаться на базу знаний, но не изменяет ее автоматически.