PRODUCT ARTIFICIAL INTELLIGENCE FORGE · 2026 PAIF: как сделать ИИ частью ИТ-производства, а не ещё одним окном чата Архитектура управляемого изменения продукта в эпоху ИИ Публичный обзор концепции / версия 2.0 / 2026 PAIF / WHITEPAPER 02 02 Введение PRODUCT ARTIFICIAL INTELLIGENCE FORGE Содержание . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 О чём этот текст . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Локальное ускорение и системная медлительность . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Продукт, который помнит не только код . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Четыре опоры PAIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Два пространства: факт для машины и смысл для человека . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Три контура без главного командного пункта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Путь одного изменения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Адаптивность без методологического театра . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Доказательство — не статус и не ссылка . . . . . . . . . . . . . . . . . . . . . . . 18 9. ИИ вошёл в работу быстрее, чем организации научились им управлять . . . . . . . . . . . . . . . . . . . . . . 23 10. Соседи по ландшафту: от кодинг-агента до системы риск-менеджмента . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. Capstacking: параллельная работа без коллективной амнезии . . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. Масштабирование: один продукт, один эталон, много областей . . . . . . . . . . . . . . . . . . . . . . . . . 29 13. Что меняется для руководителей — и чего модель им не обещает . . . . . . . . . . . . . . . 31 14. Внедрение: сначала один честный маршрут, а не новая религия для всей компании . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 15. Пилот как эксперимент, а не театральная постановка . . . . . . . 36 16. Четыре разных утверждения: описано, реализовано, доказано тестами, подтверждено эффектом . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 17. Ограничения и зоны, где PAIF может не окупиться . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 18. Вместо фабрики кода — производство изменений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Источники к внешнему контексту PAIF / WHITEPAPER 02 03 Введение PRODUCT ARTIFICIAL INTELLIGENCE FORGE О чём этот текст За несколько лет генеративный ИИ прошёл путь от курьёза до обычного рабочего инструмента. Он пишет код, тесты, требования и служебные записки. Ищет ошибки, объясняет незнакомые системы, помогает при инцидентах. В производстве его, впрочем, обычно включают точечно — чтобы ускорить отдельного человека или операцию. У бизнеса другой масштаб вопроса. Красноречивый ассистент и рекордная выработка кода сами по себе его не решают. Изменение продукта должно сохранять связь с исходной целью; риски должны быть видны до релиза, а решение о готовности — опираться на доказательства. После выпуска нужен ещё один честный ответ: принесла ли дорогая работа ожидаемый эффект. PAIF — Product Artificial Intelligence Forge — смотрит на внедрение ИИ с этой точки. Предмет модели — архитектура ИТ-производства, где люди и интеллектуальные механизмы работают с одним версионным знанием о продукте, а каждый участник действует в ограниченной роли. Коллекция удачных подсказок или мечта о «конвейере без людей» такой архитектуры не даёт. Этот whitepaper объясняет концепцию, но не служит инструкцией по сборке системы. Здесь подробно разобраны управленческая логика, границы ответственности и путь изменения. Внутренние схемы артефактов, служебные поля, протоколы передачи, топология контрольных точек, профили агентов и механика развёртывания остаются за его пределами. Статус утверждений в тексте принципиален. Архитектура PAIF описана в двух проектных документах. Это не равнозначно тому, что каждый описанный механизм уже реализован . Реализация, если она рассматривается, требует отдельного указания на исполняемую систему. Формулировка доказано тестами допустима только при наличии воспроизводимого тестового свидетельства и относится лишь к проверенному свойству. Формулировка подтверждено эффектом требует эксплуатационных данных за заранее определённый период. Если специального свидетельства рядом нет, утверждение этого whitepaper следует читать как описание модели, а не как отчёт о внедрении. 1. Локальное ускорение и системная медлительность Представим обычную продуктовую команду. Аналитик с помощью языковой модели за полчаса готовит черновик требований, на который раньше уходил день. Разработчик просит агента написать каркас сервиса. Тестировщик генерирует набор сценариев. Каждый из них действительно стал быстрее. Но какой факт о продукте получила модель? Какую версию архитектурного решения она считала действующей? Знала ли о бизнес-ограничении, записанном два года назад в протоколе совещания? Понимала ли, что соседняя команда уже меняет контракт, от которого зависит новый сервис? Локальная скорость не складывается автоматически в скорость системы. Иногда происходит обратное. Черновиков становится больше, проверять их некому, а происхождение решений становится ещё труднее восстановить. Старая проблема «код живёт отдельно от документации» получает новую форму: теперь код, документация и пояснения могут быстро порождать три разные модели одного продукта. Здесь проходит граница между инструментом и производственной моделью. Инструмент отвечает на вопрос «как выполнить эту операцию». В PAIF производственная модель должна определить допустимую операцию, действующие данные, владельца решения, способ проверки результата и его место в общем знании о продукте. Без этих ответов ИИ одинаково быстро умножает и полезную работу, и несогласованность. К этому добавляется проблема ответственности. Когда автором результата формально остаётся человек, а фактически большую часть работы сделала модель, легко соскользнуть в фиктивный контроль. Подпись есть, но содержательной проверки не было. Сотрудник видел гладкий текст, узнаваемую структуру и зелёные отметки в отчёте — и принял выдачу за доказанный факт. Поэтому для системного применения ИИ мало научить модель делать. Нужно так же точно сказать, чего она не имеет права делать и какое решение не может подтверждать от своего имени. PAIF / WHITEPAPER 02 04 1. Локальное ускорение и системная медлительность PRODUCT ARTIFICIAL INTELLIGENCE FORGE Рис. 01 От локального ИИ — к управляемому изменению Источник: Источники и метод — в подписи исходной фигуры и аппарате. Ограничение: Показан публичный принцип, без внутренней топологии и служебных полей. Третий излом лежит между выпуском и ценностью. Версия может успешно собраться, пройти тесты, получить одобрение и попасть в продукт. Это может подтвердить прохождение заданных инженерных проверок и принятие версии в установленном маршруте, но только в пределах их критериев и доказательств. Частота возвратов клиента, скорость обработки заказа и доход компании остаются за пределами такого доказательства. Бизнес часто подменяет одно другим: технический факт получить проще, чем выдержать период наблюдения и сравнить эффект с исходной гипотезой. PAIF строится вокруг трёх разрывов: между скоростью операции и скоростью системы; между технической возможностью и полномочием; между готовностью версии и подтверждённой ценностью. Это не три побочных риска внедрения ИИ. Это три разных проявления одной проблемы: организация пытается встроить новую вычислительную силу в старые границы знания и ответственности. 2. Продукт, который помнит не только код В большинстве компаний продукт рассыпан по нескольким системам. Код и конфигурации лежат в репозиториях. Требования — в трекере. Решения архитектурного комитета — в вики и протоколах. Продуктовые метрики — в аналитической системе. Часть договорённостей остаётся в переписке и памяти участников. Каждая система разумна в своей области. Вместе они не всегда дают один ответ на простой вопрос: что представляет собой продукт сейчас? Человек умеет собрать такой ответ из контекста. Он помнит, какая запись устарела, кто из двух архитекторов имел в виду какой вариант, и почему в трекере до сих пор висит задача, которую уже отменили. Машина не имеет такой привилегии. Если ей дать три документа с разными формулировками, она может изобретательно их примирить. Но изобретательное примирение — не то же самое, что знание о действующем решении. PAIF / WHITEPAPER 02 05 2. Продукт, который помнит не только код PRODUCT ARTIFICIAL INTELLIGENCE FORGE Рис. 02 Локальные ускорения, общий разрыв Источник: PAIF: концептуальное описание. Ограничение: Образ служит редакционным контрапунктом и не является доказательством эффекта. В PAIF репозиторий — не обязательно одна физическая система и точно не папка, куда свалили все файлы. Это логически единое версионное пространство. Данные могут физически оставаться в привычных инструментах, но для модели они имеют единые правила идентификации, доступа, версионности и журналирования. У факта есть одно действующее представление; остальное — либо ссылка, либо слепок с известной версией, но не вторая независимая «истина». Формула «один факт — один экземпляр» не исключает рассинхронизацию. Она задаёт другое правило: система не выдаёт дублирование за норму. Версия и происхождение снимка известны; канонический факт меняется только через управляемое изменение. Такая дисциплина снижает риск появления независимых и конфликтующих версий одного знания. Магической целостности здесь нет. У такого единства есть цена. Нужно явно различать действующий факт, предложение, историческую версию и человекочитаемое представление. Нужно не переписывать историю задним числом. Нужно признать отказ проверки нормальным исходом, а не аварией, которую удобнее скрыть. Без этого общий репозиторий быстро превратится в очень большую папку. PAIF / WHITEPAPER 02 06 2. Продукт, который помнит не только код PRODUCT ARTIFICIAL INTELLIGENCE FORGE Рис. 03 Версия хранит не только результат Источник: PAIF: концептуальное описание. Ограничение: Образ служит редакционным контрапунктом и не является доказательством эффекта. 3. Четыре опоры PAIF Концепцию PAIF можно свести к четырём опорам. По отдельности ни одна из них не выглядит экзотически: машиночитаемые знания, проверяемая ценность, активное, но ограниченное участие ИИ и адаптивность маршрута. Но работать они должны вместе. Если убрать любую, система либо теряет доверие, либо возвращается к быстрому, но локальному ассистенту. 3.1. Машиночитаемое знание Первая опора — машиночитаемое знание. Тысячи новых страниц документации задачу не решают: они быстро устаревают. Знание должно быть доступно для чтения и проверки. Абзац прозы о правиле предметной области человек истолкует, а машина перескажет. Явно обозначенные условия, исключения, связи и версию уже можно использовать в автоматической проверке. PAIF / WHITEPAPER 02 07 3. Четыре опоры PAIF PRODUCT ARTIFICIAL INTELLIGENCE FORGE Рис. 04 Продукт существует как актуальная версия знания Источник: PAIF: концептуальное описание. Ограничение: Показан публичный принцип, без внутренней топологии и служебных полей. Машиночитаемость сосуществует с языком для людей. Хорошая система умеет перевести формальное знание в понятное объяснение и обратно. Бизнес-владельцу для решения не нужна схема данных. Агенту нельзя угадывать действующее правило по слайду трёхлетней давности. Два представления дают два способа работы с одним фактом, без дублирования знания. 3.2. Ценность как проверяемая гипотеза Вторая опора начинается с неудобной мысли: даже прекрасно реализованная функция может оказаться ненужной. Техническая команда чаще всего не может доказать ценность до выпуска. Но она может ещё до начала работы зафиксировать, какой эффект ожидается, с какой бизнес-целью он связан, по какой метрике будет виден, откуда возьмутся данные и какой период наблюдения имеет смысл. Такая фиксация не гарантирует результат. Она защищает от подмены. Если критерий успеха появляется после того, как команда увидела метрики, она всегда найдёт что-то положительное. Но это будет история о совпадении, а не проверка гипотезы. PAIF требует связать изменение с ожидаемой ценностью заранее, а после выпуска сохранить исход наблюдения как часть знания о продукте. PAIF / WHITEPAPER 02 08 3. Четыре опоры PAIF PRODUCT ARTIFICIAL INTELLIGENCE FORGE Рис. 05 Четыре опоры удерживают изменение в производственном контуре Источник: PAIF: концептуальное описание. Ограничение: Показан публичный принцип, без внутренней топологии и служебных полей. Отсюда следует ещё одно ограничение. Внутри самого маршрута можно проверить полноту требований, соответствие реализации проектному решению, прохождение тестов и допуск версии. Достижение продуктового эффекта проверяется в другом временном масштабе и на других данных. Закрытая рабочая область не возобновляется ради того, чтобы «доказать» её успех. Если эффекта нет, это новый факт о продукте и, возможно, основание для нового изменения, а не повод переписать прошлое. 3.3. ИИ как участник с ограниченной ролью Третья опора часто трактуется неверно. Активный ИИ — не синоним автономного ИИ, которому «дали цель и не мешают». В PAIF участие ИИ ограничено назначенной функцией, релевантным контекстом и проверяемым результатом. Техническая возможность сделать нечто сама по себе не даёт системе права это делать. Конкретное устройство ролей, прав и активаций относится к внутренней реализации и в этом документе не раскрывается. Активность здесь означает, что ИИ не ограничен режимом «ответь на вопрос». Он может анализировать вход, готовить материал, сопоставлять результат с правилами, запускать разрешённую проверку, обнаруживать остановку маршрута и сообщать о ней владельцу решения. Но он не принимает вместо уполномоченного человека бизнес-цель, допустимый риск или смысловое решение. Конкретные полномочия агента определяются отдельной ограниченной ролью и в этом whitepaper не раскрываются. Создание результата и его независимое подтверждение разделены. Агент, написавший артефакт, не становится независимым проверяющим после повторного чтения своего ответа. При недостатке доказательств или выходе за установленные границы работа останавливается. Так устроена управляемая агентная система: она умеет остановиться. 3.4. Адаптивный маршрут, а не религия процесса PAIF / WHITEPAPER 02 09 3. Четыре опоры PAIF PRODUCT ARTIFICIAL INTELLIGENCE FORGE Рис. 06 Полномочие не следует из возможности Источник: PAIF: концептуальное описание. Ограничение: Образ служит редакционным контрапунктом и не является доказательством эффекта. Четвёртая опора направлена против привычки объявлять один способ работы универсальным. Неопределённая функция в зрелом продукте, миграция финансовых данных и исправление опечатки не нуждаются в одинаковом маршруте. Если принудить их к одному, либо простое изменение потонет в церемонии, либо критичное не получит нужной глубины проверки. PAIF не отменяет Agile, Waterfall или гибридные схемы. Он не должен переписывать календарь всей организации. Вместо этого для конкретного изменения формируется подходящий путь с учётом зрелости команды и продукта, критичности, обратимости и ограничений. Путь вступает в силу только после верификации пользователем. Это важная оговорка: объяснимый расчёт маршрута не равен праву машины самостоятельно определять, как команде работать. Адаптивность здесь подчинена правилам. Одинаковые входные условия должны давать одинаково объяснимый выбор. Если человек его оспаривает, исходное решение сохраняется, а возражение становится новым фактом для будущей калибровки. Даже накопив историю успехов и отказов, система не меняет правила незаметно. Она готовит предложение; новая логика вступает в силу новой версией после решения уполномоченного участника. PAIF / WHITEPAPER 02 10 3. Четыре опоры PAIF PRODUCT ARTIFICIAL INTELLIGENCE FORGE 4. Два пространства: факт для машины и смысл для человека Многие попытки цифровизовать разработку строятся на неявном предположении: будто машина и человек могут работать с одним и тем же представлением информации. Отсюда появляются две крайности. В первой всё описывают свободным языком, а потом надеются, что ИИ разберётся. Во второй людей заставляют думать в терминах схем и полей, превращая любое решение в заполнение формы. PAIF разводит эти способы работы по двум связанным пространствам. В цифровом пространстве живут версионные факты, правила, решения и артефакты. С ним работают автоматические проверки, сервисы и ИИ-агенты. В экспертном пространстве люди формулируют гипотезы, обсуждают компромиссы, принимают архитектурные и управленческие решения, оценивают риск и наблюдаемый эффект. Рис. 07 Техническая возможность не равна полномочию Источник: PAIF: концептуальное описание. Ограничение: Показан публичный принцип, без внутренней топологии и служебных полей. Это не два независимых мира. Каждое значимое решение должно замкнуть цикл. Если цифровая система подготовила заключение, которое требует экспертного решения, оно должно быть представлено человеку в понятной форме. Если человек принял, отклонил или уточнил решение, оно должно вернуться в цифровое пространство с автором, основанием и точной связью с тем, что рассматривалось. Решение, которое осталось в видеозвонке, для PAIF ещё не стало действующим фактом. Люди здесь не «поставляют решения» машине, которая затем делает всё остальное. Граница полномочий вообще не совпадает с границей между мышлением и исполнением. Агент способен провести сложный анализ, предложить неочевидный вариант, связать артефакты или заметить пропущенный человеком риск. Процесс определяет статус вывода. Где-то это автоматически проверяемый результат, где-то — материал для эксперта. Готовым решением он станет лишь в предусмотренном порядке. Принцип двух пространств нужен и для защиты от подмены экспертизы. Гладко написанный текст легко выдать за правильный. Машиночитаемый пакет так же легко выдать за полный, если не проверить связанные с ним факты. Поэтому на границах между пространствами должны встречаться две логики: PAIF / WHITEPAPER 02 11 4. Два пространства: факт для машины и смысл для человека PRODUCT ARTIFICIAL INTELLIGENCE FORGE техническая проверка точных версий и связей и смысловое решение уполномоченного человека. Рис. 08 Значимое решение замыкается между двумя пространствами Источник: PAIF: концептуальное описание. Ограничение: Показан публичный принцип, без внутренней топологии и служебных полей. 5. Три контура без главного командного пункта Разделение на три контура — самая заметная часть PAIF, но её легко понять неверно. Master, Framework и Slave — не три департамента, не три класса агентов и не три ступени иерархии. Это три границы владения. Каждая отвечает за свой класс объектов и переходов. Ни одна не получает права принимать все решения. Такое разделение нужно не ради архитектурной красоты. Если хранение эталона, выбор маршрута и исполнение окажутся в одних руках, та же система сможет придумать путь, пройти его и записать себе успех. Формально все журналы будут заполнены. Но проверяемость будет фиктивной, потому что владение результатом и право изменить критерий совпадут. 5.1. Master: что есть продукт Эталонный контур хранит каноническое состояние продукта. В нём знания о бизнес-процессах, правилах, метриках, архитектурных решениях и связях не отделены принципиально от актуальных артефактов реализации. Внешний код, схема или контракт могут физически лежать в другой системе, но Master знает их точную версию и происхождение. Знание и реализация обновляются как одна версия. Только Master фиксирует новое эталонное состояние продукта. Это не делает его «начальником» остальных. Он не выбирает метод работы и не исполняет проектную работу. Его задача — принять входящее намерение, сопоставить его с действующим знанием, предоставить исполнению определённое основание, а после требуемых проверок зафиксировать новую каноническую версию и сообщить о ней всем активным работам — независимо от того, признаны ли они затронутыми изменением. Сама фиксация версии ещё ничего не говорит о достигнутой бизнес-ценности. У Master есть память о смысловых событиях. Обычный технический журнал покажет изменённые строки. История продукта должна восстанавливать замысел изменения, принятый путь и основание, по которому новая версия стала действующей. Состав внутренних записей и связей в публичном описании не раскрывается. Форма журнала вторична; существенно различие между хранилищем файлов и эталоном продукта. 5.2. Framework: как делать именно это изменение PAIF / WHITEPAPER 02 12 5. Три контура без главного командного пункта PRODUCT ARTIFICIAL INTELLIGENCE FORGE Методологический контур формирует способ проведения конкретного изменения. Эталон продукта и код остаются вне его полномочий. Для выбора пути ему нужны тип задачи, состояние продукта, зрелость команды, цена ошибки, обратимость решения, внешние обязательства и неопределённость. Результатом становится версионная карта маршрута. Название «гибкий» или «каскадный» её не заменяет: нужен понятный путь с результатами, проверками и границами. Человек должен увидеть причину выбора и верифицировать путь до начала исполнения. В ходе работы Framework следит за сохранением применимости маршрута, а не за каждым движением исполнителя. Рис. 09 Три ответственности, одна работа Источник: PAIF: концептуальное описание. Ограничение: Образ служит редакционным контрапунктом и не является доказательством эффекта. Здесь есть тонкая, но принципиальная граница. Framework может обнаружить, что карта больше не соответствует реальности, и подготовить новую ревизию. Но он не переделывает артефакты рабочей области, не перепроверяет смысловой критерий вместо его владельца и не назначает исполнителей. Он отвечает за устройство пути, но не за содержательное решение на каждой его точке. История маршрутов позволяет методологическому контуру учиться, но не самовольно. Успехи, отказы, возвраты, пересмотры и сроки накапливаются как наблюдения. Из них можно вывести предложение о калибровке. Но только утверждённое изменение становится новой версией методологической логики. Действующие маршруты не переключаются на новую логику автоматически. Если изменение должно затронуть активную работу, Framework выпускает новую ревизию маршрута, которая вступает в силу только после повторной верификации уполномоченным участником. 5.3. Slave: где изменение становится реальностью Рабочий контур состоит из изолированных областей исполнения. Каждая связана с одним определённым изменением, известной версией продукта и утверждённым маршрутом. Внутри создаются необходимые проектные и технические результаты. Изоляция нужна для того, чтобы незавершённая работа не стала каноническим состоянием незаметно для остальных участников. Рабочая область не изменяет Master напрямую. Она готовит результат и проходит предусмотренные проверки, после чего решение о новом эталонном состоянии остаётся за Master. Переход должен сохранять целостность версии: продукт не может считаться обновлённым наполовину только потому, что отдельная часть результата уже готова. Конкретный формат передачи и публикации является внутренним механизмом. PAIF / WHITEPAPER 02 13 5. Три контура без главного командного пункта PRODUCT ARTIFICIAL INTELLIGENCE FORGE После принятия результата область перестаёт быть активным исполнителем, но её происхождение и связь с изменением сохраняются в истории. Отменённая работа тоже не должна маскироваться под часть актуального продукта. Публичной концепции достаточно этого инварианта; точный состав архивных материалов и состояния закрытия не раскрывается. 5.4. Распределённая оркестрация После такого описания естественно спросить: кто же всё это оркестрирует? Короткий ответ — никто не владеет всей оркестрацией. Она распределена по границам ответственности. Master управляет переходами, относящимися к эталону и версиям. Framework — жизненным циклом маршрута. Рабочая область — внутренним исполнением. Сквозной координатор может видеть, что изменение остановилось или расходится с ожидаемой последовательностью, и направить сигнал нужному владельцу. Но он не изменяет эталон, не перестраивает маршрут и не вмешивается в артефакты исполнителя. Он не становится четвёртым контуром. Это роль наблюдения и эскалации, а не центр власти. Этот принцип сложнее реализовать, чем нарисовать. Любая операционная система тяготеет к единому диспетчеру, потому что так проще показать общий статус. Но в PAIF удобство наблюдения не должно превращаться в право переписывать чужие состояния. Источником достоверного состояния объекта остаётся его контур-владелец. Рис. 10 Три контура делят ответственность, а не власть Источник: PAIF: концептуальное описание. Ограничение: Показан публичный принцип, без внутренней топологии и служебных полей. PAIF / WHITEPAPER 02 14 5. Три контура без главного командного пункта PRODUCT ARTIFICIAL INTELLIGENCE FORGE 6. Путь одного изменения Разобраться в PAIF проще всего на одном обычном изменении. Представим, что интернет-магазин хочет показывать постоянному покупателю персональный порог бесплатной доставки. Гипотеза звучит правдоподобно: если человек видит, сколько ему осталось добрать до выгодного условия, он чаще добавит товар в корзину. Бизнес ожидает роста конверсии и среднего чека. Пока это не факт, а предположение. В обычной практике гипотеза быстро превратится в набор задач: добавить виджет, изменить расчёт, провести событие в аналитику. Но до появления задач нужно выяснить, не противоречит ли идея действующим ценовым правилам, промоакциям, договорам с логистическими партнёрами и принятой логике возвратов. Формулировка «постоянный покупатель» тоже требует точности: по сроку жизни, числу заказов, статусу в программе лояльности или другому критерию? Путь начинается с проверки входа. Изменение сопоставляется с эталоном продукта и намерениями уже активных рабочих областей. Пробел или конфликт нельзя замазать угадкой; запрос возвращается на уточнение. Такую процедуру легко назвать бюрократией. Она спроектирована так, чтобы не переносить известную неточность дальше в код, тесты и релизные материалы. Когда вход стал достаточно определённым и допущен к дальнейшей проработке, Framework формирует маршрут. Для персонального порога доставки он может оказаться итеративным, если продукт зрелый, команда знает предметную область, а риск обратим. Если же расчёт встроен в партнёрские финансовые обязательства, а команда недавно собрана, появится более каскадная логика с тяжёлыми проверками на границах фаз. В гибридном варианте критичные решения могут проходить фазовую проверку, а поведение интерфейса уточняться итеративно. Проект маршрута не скрывается от команды как решение «чёрного ящика». Уполномоченный участник видит его человекочитаемое представление: какие результаты ожидаются, где потребуется экспертное решение, каковы критерии готовности, какие риски учтены. Только после его верификации карта становится действующим основанием исполнения. Если её оспаривают, то не стирают исходное предложение, а фиксируют новое обоснованное решение. Затем начинается изолированное исполнение, связанное с определённой версией продукта и утверждённым маршрутом. Внутреннее устройство передачи контекста между контурами в публичной версии не описывается. Для понимания модели достаточно трёх условий: основание работы известно, действующая версия маршрута определена, а результаты нельзя выдать за часть эталона до независимого решения на границе Master. Исполнение охватывает гораздо больше генерации кода. Для порога доставки потребуются расчётная модель, правила округления, поведение при возврате или отмене заказа, показ в интерфейсе, события аналитики, миграции, контракты и тесты. Агенты могут сделать часть этой работы; другая часть потребует инженерного решения. На значимых границах появляется экспертное решение. Расход человеко-часов и машинных циклов вторичен. Главное — связь каждого значимого результата с конкретной версией, проверкой и решением. PAIF / WHITEPAPER 02 15 6. Путь одного изменения PRODUCT ARTIFICIAL INTELLIGENCE FORGE Рис. 11 Путь изменения не заканчивается выпуском Источник: PAIF: концептуальное описание. Ограничение: Показан публичный принцип, без внутренней топологии и служебных полей. Отказ внутренней проверки не разрушает модель: это нормальный исход, требующий исправления или пересмотра. Глубина повторной проверки определяется влиянием изменения. Локальная техническая правка и изменение смысла требования не должны получать одинаковый режим. Прошлые решения при этом не переписываются; они остаются историческими свидетельствами, но не переносятся автоматически на изменившийся результат. Конкретная механика возвратов и повторов является внутренней частью реализации. Когда работа завершена, команда должна уметь объяснить, что изменилось, зачем, как это проверялось и какие части продукта затронуты. Человекочитаемое объяснение не заменяет технических свидетельств, а технические материалы не заменяют экспертного решения. Master получает достаточно оснований, чтобы решить, может ли результат стать новой версией. Внутренний состав передаваемых материалов и протокол их доставки намеренно не раскрываются. На границе Master проверяет не только убедительность объяснения, но и связь результата с точными версиями и свидетельствами проверок. Ссылка на тестовый отчёт сама по себе не является доказательством, если неизвестно, какая версия проверялась, каковы критерии и не изменилось ли содержимое после прогона. Только после положительного решения новая версия может стать канонической; до этого прежняя версия остаётся действующей. Транзакционная механика такой фиксации остаётся за рамками whitepaper. На этом заканчивается путь создания версии, но не путь гипотезы. После фактического выпуска начинается отдельное наблюдение по заранее определённым условиям. Интеллектуальный механизм может сопоставить данные с ожиданием и оценить их качество, но решение о ценности принимает уполномоченный человек; внутренняя структура записи и набор исходов здесь не раскрываются. Для нашего порога доставки это означает, что релиз не получит автоматическую метку «успех». Может оказаться, что виджет правильно работает и даже повышает средний чек, но снижает маржу из-за неожиданно высокой стоимости доставки. Или растёт конверсия, но эффект возник из-за параллельной промоакции. Система не должна скрывать эту неопределённость под красивым отчётом. Её задача — сделать основание вывода наблюдаемым и не подгонять критерий после того, как цифры стали известны. PAIF / WHITEPAPER 02 16 6. Путь одного изменения PRODUCT ARTIFICIAL INTELLIGENCE FORGE 7. Адаптивность без методологического театра В индустрии накоплено много противопоставлений. Agile обычно связывают с быстрой обратной связью, Waterfall — с контролем и предсказуемостью, гибрид — с попыткой взять от обоих лучшее. Затем спор превращается в столкновение мировоззрений: кто-то защищает спринты, кто-то — фазовые ворота. PAIF переносит дискуссию из области веры в область условий конкретного изменения. Итеративный маршрут имеет смысл, когда команда умеет доводить малые инкременты до состоятельного показа, продукт достаточно зрелый, а ошибка обратима. Его главная сила — ранняя смысловая обратная связь. Показ работающего поведения заставляет заметить то, что не было видно в тексте. Цена тоже честная: владелец решения и другие эксперты заняты на всей длине пути. Если команда не умеет готовить проверяемый инкремент, каждая итерация превратится в новый черновик. Каскадный маршрут оправдан, когда цена ошибки высока, внешние обязательства жёстки, а команде не хватает опыта в данной области. Перед реализацией в таком случае тщательнее проверяют проектные решения, контракты, схемы данных и миграции. Поздняя обратная связь о работающем поведении — осознанная цена этого выбора. Она должна быть видна в карте до начала работы. Гибридный маршрут сочетает фазовую дисциплину для критичных решений с итеративной обратной связью внутри исполнения. Его цена — более сложная карта и необходимость согласовать два режима контроля. Точное число, расположение и условия внутренних границ в публичном описании не раскрываются. Существенно, что во всех трёх вариантах меняется внутренний ритм, но не архитектура ответственности. Вход всё равно сопоставляется с эталоном. Маршрут верифицируется человеком. Рабочая область остаётся изолированной. Исход связывается с доказательствами и канонической версией. После появления новой версии каждая активная работа должна проверить, сохраняется ли её основание и не изменился ли смысл локального намерения. Получение уведомления не означает автоматического переключения. Методология здесь — способ пройти по местности, а не способ отменить законы этой местности. Адаптивность должна быть воспроизводимой. Нельзя каждый раз выбирать путь по настроению руководителя и называть это «гибкостью». Поэтому Framework опирается на версионные и объяснимые правила. Одинаковые входы должны давать одинаковый вывод, а оспаривание должно оставлять след. Только так можно отличить адаптивность от непоследовательности. PAIF / WHITEPAPER 02 17 7. Адаптивность без методологического театра PRODUCT ARTIFICIAL INTELLIGENCE FORGE Рис. 12 Маршрут меняется под условия, архитектурная рамка остаётся Источник: PAIF: концептуальное описание. Ограничение: Показан публичный принцип, без внутренней топологии и служебных полей. 8. Доказательство — не статус и не ссылка В трекере задач можно увидеть статус «готово», в системе непрерывной интеграции — зелёный прогон, в документе — подпись согласующего. Каждый из этих сигналов полезен, но ни один не является доказательством сам по себе. Статус может быть поставлен ошибочно. Тест мог прогоняться над другой сборкой. Подписавший мог не увидеть важного ограничения. Доказательство в PAIF — это проверяемая связь между точной версией результата, критерием, проверкой и её исходом. Ссылка на артефакт без подтверждённой связи с проверенным результатом сама по себе ничего не доказывает. Такой подход может показаться избыточным в бытовом сценарии. Но как только в процессе появляются генеративные агенты, способные за минуту пересобрать документ или код, неизменность проверяемого объекта становится базовым условием. Доказательная цепочка связывает исходный запрос, маршрут, результаты, решения и каноническую версию. Если проверяемый объект изменился, прежнее свидетельство нельзя автоматически приписать новой версии. Но это не значит, что каждое прошлое экспертное решение всегда нужно принимать заново. Объём повторной верификации определяется влиянием: чем глубже изменение затрагивает смысл, риск и зависимые решения, тем шире проверка. Если влияние неопределённо, применяется более строгий режим. Точные правила расчёта этого объёма и механика возврата остаются внутренними. Эта логика особенно важна для агентной переработки. Любое изменение, выполненное агентом, создаёт новую версию результата. Агент не имеет права прикрепить к ней старый зелёный отчёт, даже если изменение кажется ему незначительным. Субъект переработки — человек или ИИ — фиксируется для происхождения и ответственности. Но объём повтора определяется не типом исполнителя, а реальным влиянием его работы. Отказ проверки в такой системе перестаёт быть красной лампой, которую нужно любой ценой погасить к отчёту. Это данные о системе. Повторяющиеся отказы на одном месте могут говорить не о плохой команде, а о неверно выбранном маршруте, неполном входе или нереалистичном критерии. Из статистики можно подготовить предложение о калибровке. Но изменять правила на лету и переписывать прошлое нельзя. PAIF / WHITEPAPER 02 18 8. Доказательство — не статус и не ссылка PRODUCT ARTIFICIAL INTELLIGENCE FORGE Рис. 13 Ссылка на результат ещё не образует доказательство Источник: PAIF: концептуальное описание. Ограничение: Показан публичный принцип, без внутренней топологии и служебных полей. 9. ИИ вошёл в работу быстрее, чем организации научились им управлять У PAIF есть внутренняя логика, и её нельзя выводить из рыночных опросов. Но внешние данные нужны, чтобы понять, почему вообще возник запрос на системную модель. К середине 2020-х спор о том, «будут ли компании использовать ИИ», в значительной степени потерял предмет. Интереснее другое: какая доля этого использования стала обычной производственной способностью, а какая осталась набором пилотов и личных привычек. Годовые опросы McKinsey, воспроизведённые в Stanford AI Index, показывают резкий рост самоотчётов о внедрении. Доля респондентов, сообщивших об использовании ИИ хотя бы в одной бизнес-функции, выросла с 55 % в 2023 году до 78 % в 2024-м. Для генеративного ИИ рост составил с 33 % до 71 %. 1 В опросе 2025 года эти значения достигли 88 % и 79 % соответственно. 2 Опрос измеряет ответы респондентов. Глубину внедрения, качество процесса и экономический результат он не показывает и переписью компаний мира не является. Зато направление сдвига видно: инструмент стал массовым. Масштабирование отстаёт. В том же исследовании McKinsey 2025 примерно треть респондентов сообщила, что их организации начали масштабировать ИИ-программы по организации. 23 % сообщили о масштабировании хотя бы одной агентной системы, ещё 39 % — об экспериментах. 12 Категории опроса не образуют воронку, а слово «масштабируют» ещё не доказывает эффект. Однако разрыв между доступом к ИИ и его превращением в общую организационную способность виден. PAIF / WHITEPAPER 02 19 9. ИИ вошёл в работу быстрее, чем организации научились им управлять PRODUCT ARTIFICIAL INTELLIGENCE FORGE Рис. 14 За три волны опроса ИИ стал обычной частью бизнес-функций Источник: Источники и метод — в подписи исходной фигуры и аппарате. Ограничение: Показаны несопоставимые наблюдения без сведения к общей шкале. В разработке похожая картина. В Stack Overflow Developer Survey суммарная доля тех, кто уже использовал ИИ-инструменты или планировал начать, составила около 70 % в 2023 году, 76 % в 2024-м и 84 % в 2025-м. 345 Сравнение требует осторожности. Годовые выборки не являются одной панелью; «используют» и «планируют» — разные статусы. Для инженера ИИ тем не менее уже перестал быть экзотикой. Широкое распространение не означает высокого доверия. В опросе Stack Overflow 2025 среди 33 244 ответивших на вопрос о точности 46 % скорее не доверяли выводам ИИ, 33 % — доверяли. Среди ответивших о проблемах 66 % отметили «почти правильные» решения, 45 % — более долгую отладку сгенерированного кода; это был вопрос с множественным выбором и базой 31 476 ответов. 5 Опрос измеряет опыт и отношение, а не частоту дефектов. Ответы указывают на издержки проверки: правдоподобный результат нередко требует дополнительной отладки. PAIF / WHITEPAPER 02 20 9. ИИ вошёл в работу быстрее, чем организации научились им управлять PRODUCT ARTIFICIAL INTELLIGENCE FORGE Рис. 15 Используют ИИ — 88%; масштабируют программы — около трети Источник: Источники и метод — в подписи исходной фигуры и аппарате. Ограничение: Показаны несопоставимые наблюдения без сведения к общей шкале. Одну цифру «ускорения разработки» из исследований вывести нельзя. В лабораторном эксперименте GitHub 95 профессиональных разработчиков решали одну ограниченную задачу на JavaScript; группа с Copilot завершила её на 55 % быстрее, с заявленным 95-процентным доверительным интервалом прироста скорости 21–89 %. 6 Объединённый анализ трёх полевых рандомизированных экспериментов Microsoft, Accenture и одной компании Fortune 100 с 4 867 разработчиками оценил увеличение числа завершённых задач в группах с ИИ-ассистентом в 26,08 % при стандартной ошибке 10,3 %; отдельные эксперименты были статистически шумными. 7 Другой эксперимент дал противоположный знак. METR провёл рандомизированное исследование на 246 реальных задачах, которые выполняли 16 опытных сопровождающ