Вы получили ответ. А кто организовал работу?

Как превратить ИИ из собеседника в рабочую среду — для договора, бизнес-плана и не только

Сергей Авдейчик · DOBROVOLA · 12 сентября 2026 года

Представьте: на столе лежит бизнес-план новой пекарни. Двадцать аккуратных страниц, прогноз выручки, маркетинговая стратегия, убедительный вывод: вторую точку стоит открывать. Текст подготовил ИИ. Руководитель задаёт один вопрос: «Откуда это взялось?»

Откуда взялось число покупателей? Почему аренда именно такая? Учтены ли списания выпечки? Кто проверил, что денег хватит до выхода на устойчивые продажи?

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

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

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

Метод, который вырос из студенческой практики

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

В этой постановке мне близок опыт Андрея Карпати с MenuGen — приложением, которое создаёт изображения блюд по фотографии ресторанного меню. В своём разборе он описал, насколько быстро появился первый интерфейс и сколько дополнительной работы потребовали интеграции и доведение приложения до использования. Между впечатляющим началом и готовым продуктом обнаружился вполне инженерный путь. [1]

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

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

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

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

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

Начать с разговора, а не с идеального запроса

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

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

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

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

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

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

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

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

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

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

GitHub, Linear и агент: три понятные роли

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

GitHub — место для файлов и истории их изменений. Репозиторий можно представить как проектную папку, в которой видно, что изменилось и кто это сделал. Там хранят не только код: GitHub поддерживает файлы, совместную работу и историю версий. [2]

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

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

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

Linear — диспетчерская работы. Здесь видно, что нужно сделать, к какой вехе относится задача, что уже проверено и что мешает двигаться дальше. Вехи в Linear позволяют объединять задачи по этапам проекта и отслеживать их выполнение. [3]

ИИ-агент — исполнитель в подготовленной среде. В такой роли можно использовать, например, Codex или Claude Code. Codex умеет работать с файлами, вносить изменения и запускать доступные инструменты. Из этих возможностей можно собрать не только программирование, но и обработку данных или подготовку документов. Это способ применения агентной среды, а не обещание готового отраслевого решения. [4]

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

GitHub не должен становиться складом всех секретов компании. Сырые клиентские документы, персональные сведения и финансовые выгрузки можно оставлять в разрешённом корпоративном хранилище, а в проекте вести их реестр и контролируемые ссылки. Вопрос размещения данных решается до загрузки, а не после неё.

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

Кейс первый: договор, который можно проверить

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

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

Сначала — блюпринт процесса

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

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

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

Затем — задание на источники и проверки

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

Например, для польского права отправной точкой может быть государственный портал ELI. Он различает опубликованные, сводные и подготовленные информационные версии текстов; уже поэтому недостаточно скачать первый найденный файл и назвать его «законом». [6]

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

Утверждённое задание запрещает придумывать отсутствующие реквизиты и выдавать предложенные условия за согласованные. Неизвестный срок оплаты должен остаться вопросом к сторонам. Каждый существенный правовой вывод сопровождается указанием на конкретное основание; там, где основания не хватает, появляется пометка о неопределённости.

Собранный корпус позволяет работать не только по памяти модели. Но отсутствие документов — не единственная причина вымышленных ответов: модели способны уверенно ошибаться и должны иметь возможность признать неопределённость. [7] Поэтому сама папка с законами ещё не является гарантией. Нужно проверять и то, какой текст использован, и то, действительно ли он поддерживает вывод.

Вехи — через результат, а не занятость

Для этого процесса достаточно трёх понятных вех: «Факты и нормативные основания проверены», «Проект договора и перечень спорных условий подготовлены», «Юрист проверил проект, решения сторон зафиксированы».

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

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

На финальной проверке удобно идти от каждого важного пункта назад: это требование нормы, условие из переписки или предложение, которое ещё предстоит обсудить? Кто подтвердил цену? Где описана приёмка оборудования? Остались ли противоречия между договором и приложением?

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

Кейс второй: бизнес-план, который может сказать «не открывать»

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

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

Блюпринт начинается с решения собственника

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

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

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

Источники важнее уверенного прогноза

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

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

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

Одна цифра меняет весь вывод

Возьмём условную модель. Средняя выручка на один чек — 25 злотых без НДС. Точка работает 30 дней в месяц. Переменные расходы составляют 45% выручки; условные постоянные денежные расходы, включая оплату труда и аренду, — 45 000 злотых в месяц.

При 100 чеках в день месячная выручка составит:

100 × 25 × 30 = 75 000 злотых.

После переменных расходов останется 55% выручки, то есть 41 250 злотых. После постоянных расходов получится минус 3 750 злотых.

При 140 чеках в день выручка вырастет до 105 000 злотых, а результат той же упрощённой модели составит плюс 12 750 злотых. Разницу создало одно допущение — число покупок в день.

Порог покрытия этих расходов определяется так:

45 000 ÷ (25 × 0,55 × 30) ≈ 109,1 чека в день.

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

Теперь возвращается вопрос с начала статьи: откуда взялось предположение о 140 чеках? Его подтверждают наблюдения, тест продаж или только надежда владельца?

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

Маркетинг тоже должен сходиться с расчётом

Предложение «привлекать покупателей рекламой» ещё не отвечает на вопрос, сколько будет стоить дополнительный спрос. Если к постоянным расходам добавить 5 000 злотых ежемесячного рекламного бюджета, при прочих равных порог покрытия расходов вырастет примерно до 122 чеков в день.

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

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

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

Планировать следующую веху из реальности

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

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

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

Каждая задача должна отвечать на простые вопросы: что получить, на каких материалах работать, что не входит в работу и как будет проверяться результат. В юридическом кейсе «проверить источники» означает предъявить реестр и замечания, а в финансовом «посчитать сценарии» — отдать воспроизводимый расчёт с формулами.

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

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

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

Развивать нужно два контура

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

В агентной среде есть собственные инструкции. Для Codex используются файлы AGENTS.md, для Claude Code — CLAUDE.md. В них задают контекст проекта и правила работы. Это обычные текстовые документы, а не материал, доступный только программисту. [8, 9]

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

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

Повторяющиеся процедуры можно оформлять в скиллы: например, как составлять реестр источников или проверять финансовую таблицу. В агентных инструментах скилл объединяет инструкции и вспомогательные материалы для определённой задачи. [10]

Но текстовые правила не заменяют технические права доступа. Запись «не отправляйте документы» — не то же самое, что ограничение возможности отправки. Доступы, подтверждение значимых действий и лимиты расходов нужно настраивать отдельно. Документация Claude Code прямо различает контекстные инструкции и принудительно исполняемые настройки. [9]

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

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

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

«Готово» — это не статус в планировщике

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

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

В конце каждой вехи я предлагаю два вопроса.

Могу ли я простыми словами объяснить текущую веху и её задачи человеку вне проекта?

Если завтра агент станет недоступен, смогу ли я понять, что сделано и почему именно так?

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

Начать с одного процесса, а не с «ИИ-трансформации»

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

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

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

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

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

Иногда лучший результат — не делать

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

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

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

Тогда вопрос «Откуда это взялось?» перестаёт быть неприятным сюрпризом. На него есть спокойный ответ: вот источники, вот допущения, вот выполненные проверки — и вот решение, которое принял человек.

Об авторе

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

Сайт: dobrovola.dev · LinkedIn · Facebook

Какой процесс в Вашей работе уже просится в такую среду — и на каком этапе Вам труднее всего проверить результат? Буду рад обсудить конкретные примеры.

Источники и материалы

Последовательность работы в статье — авторская методика. Внешние источники поясняют возможности инструментов и отдельные ограничения. Оба кейса учебные; расчёты выполнены по явно указанным условным данным. Справочные страницы проверены 12 сентября 2026 года.

[1] Андрей Карпати. Vibe coding MenuGen. Авторский разбор создания приложения, 27 апреля 2025 года. Открыть материал.

[2] GitHub Docs. About repositories. Файлы, совместная работа и история изменений. Официальная документация.

[3] Linear Docs. Project milestones. Вехи проекта и связанные задачи. Официальная документация.

[4] OpenAI. Codex CLI. Работа с файлами, командами и повторяемыми процедурами. Официальная документация.

[5] OpenAI. Model Context Protocol. Подключение инструментов и внешнего контекста. Официальная документация.

[6] ELI, Польша. European Legislation Identifier. Официальные законодательные источники и обозначения версий текстов. Государственный портал.

[7] OpenAI. Why language models hallucinate. Причины уверенных ошибочных ответов и признание неопределённости, 5 сентября 2025 года. Материал исследования.

[8] OpenAI. Custom instructions with AGENTS.md. Контекст и инструкции проекта для Codex. Официальная документация.

[9] Anthropic. How Claude remembers your project. CLAUDE.md; различие инструкций и технически исполняемых ограничений. Официальная документация.

[10] OpenAI. Skills. Повторяемые инструкции и вспомогательные файлы для агента. Официальная документация.