Спочатку задайте контекст продукту. Будь ласка.

Чому результат так сильно плаває

Ось один і той самий запит, відправлений одній і тій самій моделі з різницею у шістдесят секунд.

Запит: «Напиши критерії приймання для тікета: користувач може налаштовувати параметри провайдера ШІ».

Перша спроба — без контексту: результат виглядає як черговий список. «Користувач може вибрати провайдера ШІ зі списку. Користувач може зберегти налаштування. Користувач бачить повідомлення про успіх». Це міг би бути будь-який продукт, будь-яка платформа і будь-яке десятиліття. Формально тут нічого поганого. Практичної користі — майже нуль.

Друга спроба — з контекстом продукту: результат уже посилається на сторінки адміністратора в Jira Cloud, права Forge resolver, перевірку API-ключів за кожним провайдером (OpenAI, Anthropic, Google, Mistral, xAI), поведінку на рівні організації та проєкту, а також на дії запису, зав’язані на ліцензії. Він згадує, що налаштування зберігаються через @forge/sql, а інтерфейс використовує компоненти Atlaskit і токени xcss. Це вже звучить так, ніби відповідь писала людина, яка реально працювала в цій кодовій базі.

Модель не змінилася. Температура не змінилася. Змінився лише вхід. І цей розрив — між загальним і точним — і є вся тема статті.

Коли результат від ШІ здається нестабільним, перший імпульс — звинуватити модель: змінити провайдера, підняти тариф, підкрутити температуру. Майже завжди це не той важіль.

Кожен запит стартує з нуля. У моделі немає пам’яті про ваш продукт, користувачів, обмеження чи попередню розмову, якщо ви явно не дали їй цю інформацію. «Напиши критерії приймання» означає зовсім різне для вбудованого в Jira застосунку на Forge для продуктових та інженерних команд на 10–100 людей і для споживчого мобільного застосунку про фітнес.

Модель відповідає на той світ, який ви їй описали. Якщо не описати нічого — вона вигадає свій. І майже ніколи це не буде ваш світ.

Ось чому дві людини в одній команді можуть використовувати одну й ту саму модель і отримувати зовсім різні результати. Річ не в рівні майстерності й не в структурі запиту. Річ у тому, чи дали моделі достатньо реальності продукту.

Якщо хочеш спочатку подивитися на ширшу картину того, чому це так боляче проявляється саме в Jira, почни зі статті ШІ не лікує розсинхрон команди. Він його маскує..

Виправляється це не «кращою технікою промптів», а повторно використовуваним шаром контексту — компактним і чесним описом світу продукту, який додається до будь-якого запиту ще до генерації. Пишеш один раз. Використовуєш скрізь. І модель перестає вгадувати.

Чотири шари контексту

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

• Опис продукту пояснює, що робить продукт, для кого він і які результати важливі — робочу суть, а не маркетинговий текст. Різниця величезна. «Інструмент управління проєктами для команд» може описувати що завгодно. А ось «Just — це вбудований у Jira ШІ-асистент для продуктових та інженерних команд на Jira Cloud. Його основна задача — перетворювати розмиті Jira-задачі на структуровані плани виконання: уточнення, покрокові плани й акуратний запис назад у поля Jira — не виходячи з панелі задачі. Це не чат-бот і не окремий інструмент. Він побудований на Atlassian Forge» вже описує один-єдиний продукт.
• Аудиторія описує, хто ці користувачі, що їм потрібно, чого вони очікують і чого не знають.
• Дизайн-мова описує візуальні патерни, бібліотеку компонентів, звички взаємодії й те, чого ви принципово не робите.
• Стек і обмеження описує реальні фреймворки, межі середовища виконання, інтеграції та рішення, які явно лежать поза допустимими межами.

Погана версія кожного поля підходить тисячам продуктів. Хороша — лише одному. У цьому й є головний тест.

Аудиторія — місце, де загальний контекст ламається

Поле з аудиторією — зазвичай перше, яке команди спрощують надто сильно. «Продакти і розробники» звучить розумно. Але це надто розмито, щоб реально допомагати моделі ухвалювати кращі рішення.

Корисний опис аудиторії конкретно пояснює склад команди, рівень знайомства з ШІ, очікування щодо довіри і те, чого користувачі не хочуть. Для Just це означає продактів і сильних інженерів у командах Jira Cloud на 10–100 людей, із середнім рівнем знайомства з ШІ, які самі керують API-ключами й більше цінують надійний результат, ніж ефектну картинку.

Рядок «Не для» важливий не менше. Фраза про те, що продукт не для команд поза Jira Cloud і не для користувачів, які чекають повністю автономних агентів, одразу прибирає цілі класи хибних припущень ще до їхньої появи.

Саме так контекст стає прив’язаним до реальності, а не декоративним. Моделі не просто кажуть, хто користувач. Їй одночасно пояснюють, у якому світі цей користувач працює і які сценарії для нього будуть відчуватися неправильними.

Дістань те, що вже існує

У більшості команд усі чотири шари контексту вже є — просто вони розкидані по кодовій базі, макетах, документації та командній пам’яті, а не зібрані у формі, придатній для ШІ.

Із репозиторію: наведи агента для коду — Claude Code, Codex або щось подібне — на кодову базу й попроси коротке markdown-зведення, яке покриває призначення продукту, стек, межі реалізації й відомі обмеження. Добре структурований репозиторій дає робочий перший чернеток за лічені хвилини.

Із дизайн-файлів: зафіксуй назву бібліотеки компонентів, 3–5 ключових патернів взаємодії, на яких тримається продукт, і 3 речі, яких інтерфейс ніколи не робить. Антипатерни тут такі ж важливі, як і патерни.

Із наявної документації: вступні нотатки, README, внутрішні описи або маркетингові матеріали можуть дати окремі шматки для опису продукту й аудиторії. Їм не треба бути ідеальними, щоб бути корисними.

Із власної голови: якщо нічого з цього поки немає, просто відкрий порожній документ і напиши по одному короткому абзацу на кожне поле. Це буде нерівно. Але навіть нерівний контекст усе одно набагато кращий, ніж жодного.

Тобі не потрібна ідеальна документація. Тобі потрібен компактний і чесний опис світу, у якому живе продукт.

Збережи один раз і використовуй всюди

Контекст починає окупатися лише тоді, коли його можна повторно використовувати. Написати його один раз і вставити в одну сесію корисно для цієї сесії. Зробити його постійним — корисно для всіх наступних.

• У Just в адміністративній панелі є окремі поля для кожного з чотирьох шарів: опис продукту, аудиторія, дизайн-мова і стек. Ти один раз вставляєш контент у кожне поле на проєкт, і всі майбутні інсайти, уточнення, плани та кроки виконання для цього проєкту автоматично отримують цей фундамент.
• Якщо ти не використовуєш Just, заведи один файл context.md у корені репозиторію або в спільній документації. Структуруй його на ті самі чотири секції. І вставляй його на початок будь-якої ШІ-сесії — помічники для коду, чат-інструменти, генератори документів. Формат менш важливий, ніж звичка: спочатку контекст, потім запит.

Стався до шару контексту як до живого документа, а не як до артефакту дня запуску. Переглядай його, коли продукт помітно змінюється — нова інтеграція, сильний зсув аудиторії, перехід на нову дизайн-систему. Але не переробляй його щоспринту. Якщо опис продукту змінюється кожні два тижні, це вже не опис продукту, а нотатки з мітингу.

Контекст — це не магія промптів

Контекст продукту — це не магія промптів. Не трюк, не шаблон і не хитрий прийом. Це просто той самий брифінг, який ти дав би новому підряднику в перший день: ось що ми будуємо, для кого, як це має виглядати і на чому все це працює.

Команди, які роблять це один раз — і потім послідовно перевикористовують, — отримують результат, який відчувається так, ніби його робила людина, яка справді розуміє продукт. Бо в усіх функціональних сенсах так і є. Модель не стала розумнішою. Ти просто перестав просити її вгадувати.