У Лондоні команда Braintrust разом із залізничним сервісом Trainline провела практичний воркшоп для інженерів, які вже вміють зібрати LLM-демо, але не знають, як перетворити його на надійну продакшн-систему. Сесія зосереджена не на «магічних» промптах, а на тому, що зазвичай болить найбільше: операційна зрілість, спостережуваність, відлов фейлів і безперервне покращення багатокрокових агентів та пайплайнів з інструментами.
У ролі ведучих — інженери Braintrust та двоє сеньйорів з Trainline, які будують агентні продукти навколо LLM у реальному бізнесі. Вони пропонують учасникам пройти повний шлях: від простого промпт-демо до поетапної, інструментованої, оцінюваної та задеплоєної системи на прикладі вигаданого агента для тріажу звернень у сапорт.
Чому «воно працює в демо» — ще не інженерія AI
Організатори одразу окреслюють головну прірву: зробити прототип на локальній машині сьогодні легко, але змусити його стабільно працювати з реальними користувачами — зовсім інша дисципліна.
У класичній розробці діє проста логіка: 1 + 1 = 2, поведінка коду детермінована, а відтворюваність проблем — очікувана норма. У LLM-системах усе інакше: одна й та сама підказка може дати різні відповіді, моделі іноді «галюцинують», а поведінка змінюється від оновлення моделей або контексту. Це створює особливо гостру проблему для компаній, які працюють у регульованих галузях або з місієкритичними сценаріями.
На воркшопі прямо артикулюють кілька типових пасток:
По-перше, хибне відчуття безпеки після кількох вдалих демо. Коли одна «крута» промпт-конструкція працює на сцені чи в тестовому середовищі, її часто намагаються майже без змін викинути в продакшн. Але під реальним навантаженням, з різноманітними запитами користувачів і неочевидними кутовими кейсами, така система розсипається.
По-друге, спроби «лікувати» продакшн через хаотичне редагування промптів. Щось зламалося — інженер заходить у промпт, підкручує формулювання, і начебто все знову працює. До наступного збою. Без системного підходу до відстеження змін, фіксації фейлів і перевірки регресій це перетворюється на нескінченний ручний «патч-менеджмент».
По-третє, підміна спостережуваності звичайними логами. Логи показують, що сталося, але не пояснюють, чому система повелася саме так. Для складних агентних пайплайнів цього недостатньо: потрібен глибший рівень інструментації, який дозволяє розібратися в поведінці моделі, послідовності викликів інструментів і впливі змін на кінцевий результат.
Саме ці проблеми воркшоп і намагається розв’язати, переводячи розмову з площини «як написати правильний промпт» у площину «як побудувати надійну AI-систему з операційною зрілістю».
Воркшоп як інженерний маршрут: від простого промпта до продакшну
Сесія в Лондоні побудована як покроковий практичний маршрут для інженерів, які хочуть не просто «погратися» з LLM, а навчитися їх шипити. Учасники підключаються до Slack-організації AI Engineer та публічного каналу «ai-engineer-europe-2026-braintrust-workshop», де отримують підтримку під час вправ. Для роботи потрібні безкоштовний акаунт у Braintrust і ключ OpenAI API.
Технічна основа — репозиторій на GitHub з усіма активами, Node.js v22, pnpm і make як обгортка для команд. Кожен етап воркшопу позначений окремим Git-тегом, тож учасники можуть у будь-який момент зробити checkout на конкретний чекпоінт і запустити робочу версію коду. Для тих, хто відстає, є детальний «cheat sheet» з покроковими інструкціями.
Але ключове не в інструментах, а в структурі самої подорожі. Воркшоп розбитий на кілька логічних фаз, які відображають типовий життєвий цикл сучасної AI-системи.
Спочатку учасники збирають базову реалізацію: одноразовий промпт, який вирішує задачу «в лоб». Це той самий рівень, на якому зазвичай зупиняються внутрішні POC у компаніях.
Далі система ускладнюється: додаються локальні інструменти для підвищення детермінізму, вводяться спеціалізовані стадії — фактично формується агентний, багатокроковий флоу. На цьому етапі стає очевидно, що простих логів уже недостатньо, і в гру входить інструментація.
Наступний крок — підключення Braintrust для трейсингу й оцінювання. Система починає збирати детальні трейси: від рівня запиту користувача до окремих викликів інструментів і токенів. На основі цих даних учасники вчаться будувати «золоті» набори для тестування, виявляти типові режими відмов і перевіряти, чи не ламають зміни вже працюючі сценарії.
Фінальна фаза — розгортання та операційне управління. Мова йде про перехід від «воно працює на моїй машині» до продакшн-середовища, де є моніторинг, онлайн-скоринг, аналіз продакшн-логів і безперервний цикл покращень.
Таким чином, воркшоп не обмежується побудовою одного агента. Він фактично моделює повний життєвий цикл AI-продукту — з усіма типовими болями й точками прийняття інженерних рішень.
Від логів до спостережуваності: чому «бачити що» замало без «розуміти чому»
Один із центральних меседжів сесії — чітке розрізнення між базовим логуванням і повноцінною спостережуваністю (observability) для AI-систем.
Логи відповідають на запитання «що сталося». Вони фіксують факти: який запит прийшов, яку відповідь повернула модель, які помилки виникли. Для класичного бекенду цього часто достатньо, щоб локалізувати проблему.
У випадку з багатокроковими агентами та пайплайнами з інструментами цього вже не вистачає. Коли система складається з кількох стадій — збору контексту, тріажу, перевірки політик, генерації відповіді, ескалації — важливо розуміти не лише кінцевий результат, а й увесь ланцюжок рішень, який до нього привів.
Спостережуваність у такому контексті означає можливість:
бачити повний трейс проходження запиту через систему, включно з усіма проміжними кроками;
аналізувати поведінку моделі на рівні окремих інструментальних викликів і токенів;
пов’язувати зміни в промптах, конфігураціях або версіях моделей із конкретними змінами в поведінці системи;
виявляти системні режими відмов, а не лише поодинокі інциденти.
Braintrust у воркшопі позиціонується саме як платформа для такої спостережуваності, а також для оцінювання й управління промптами та викликами інструментів. Вона дозволяє трасувати складні агентні флоу до рівня інструментальних викликів і токенів, підтримує керовані промпти й керовані tool calls, що хостяться в її інфраструктурі, і при цьому залишається платформно-агностичною щодо фреймворків агентів і постачальників LLM.
Але важливо, що в рамках цього воркшопу Braintrust — не самоціль, а інструмент для демонстрації принципу: без глибокої спостережуваності неможливо серйозно говорити про надійні AI-системи в продакшні.
Flywheel AI-інженерії: як побудувати безперервний цикл покращень
Ще одна ключова ідея, яку організатори впроваджують протягом сесії, — це «flywheel» підхід до AI-інженерії. Замість лінійного процесу «зробили — задеплоїли — забули» пропонується безперервний цикл, у якому кожен етап живить наступний.
Цей цикл складається з кількох повторюваних кроків.
Спочатку система інструментується. Це означає, що ще на етапі розробки в неї вбудовуються механізми збору трейсів, метрик і контексту виконання. Важливо не відкладати це «на потім», бо без даних неможливо буде зрозуміти, що саме потрібно покращувати.
Далі збираються трейси. У міру того, як система обробляє запити — спочатку тестові, потім реальні користувацькі, — формується масив даних про її поведінку в різних сценаріях. Саме ці трейси стають сировиною для наступних кроків.
На основі зібраних даних ідентифікуються режими відмов. Це можуть бути як очевидні помилки, так і більш тонкі проблеми: неконсистентні відповіді, порушення внутрішніх політик, неправильні рішення щодо ескалації. Важливо, що мова йде не про одиничні інциденти, а про повторювані патерни.
Після цього відбувається ремедіація — цілеспрямоване усунення виявлених проблем. Це може включати зміну структури пайплайна, розбиття великого промпта на спеціалізовані стадії, додавання нових інструментів або правил, а також коригування самих промптів. Ключове — робити це не «наосліп», а спираючись на конкретні трейси й оцінки.
Оновлена система шипиться в продакшн, де за нею продовжують спостерігати. Моніторинг продакшн-логів, онлайн-скоринг і нові трейси з реального трафіку знову повертають інженерів до початку циклу, але вже на вищому рівні якості.
Таким чином, flywheel-підхід перетворює AI-інженерію на процес безперервного вдосконалення, де кожна ітерація робить систему більш надійною, а не просто латкою на чергову проблему.
Вигаданий агент сапорту як полігон для реальних проблем
Щоб зробити всі ці принципи максимально конкретними, воркшоп використовує один наскрізний приклад — вигаданого агента для тріажу звернень у службу підтримки. Це не просто «іграшковий» чат-бот, а повноцінний пайплайн із кількох стадій.
Спочатку агент збирає контекст: витягує релевантну інформацію із запиту користувача, історії звернень, внутрішніх даних. Потім виконує тріаж — класифікує звернення, визначає його пріоритет і тип проблеми.
Далі йде перевірка політик: чи відповідає потенційна дія внутрішнім правилам компанії, чи не порушує вона обмежень щодо компенсацій, безпеки або регуляторних вимог. Лише після цього агент формує чернетку відповіді користувачу.
Фінальний крок — рішення про ескалацію. Агент має визначити, чи достатньо автоматичної відповіді, чи потрібно передати кейс живому оператору або в іншу команду.
Такий сценарій обрано не випадково. Він добре відображає типові виклики продакшн-систем: складну бізнес-логіку, необхідність дотримання політик, важливість коректної ескалації й чутливість до помилок. На цьому прикладі легко показати, чому один «великий» промпт, який начебто робить усе одразу, погано масштабується й важко контролюється.
Протягом воркшопу цей агент послідовно еволюціонує: від одноразового промпта до багатостадійного агентного флоу з інструментами, трейсингом, оцінюванням і продакшн-орієнтованими практиками. Саме на ньому учасники відпрацьовують flywheel-підхід: інструментують, збирають трейси, знаходять фейли, виправляють, деплоять і знову спостерігають.
Таким чином, вигаданий кейс стає полігоном для реальних інженерних рішень, які потім можна перенести у власні продукти — чи то в транспорті, як у Trainline, чи в інших галузях.
Чому інженерія важливіша за «ідеальний» промпт
Один із найпослідовніших акцентів воркшопу — зміщення фокусу з крафтингу «ідеального» промпта на інженерію навколо нього. Організатори прямо говорять: один промпт, який працює в демо, не є достатньою основою для продакшн-системи.
По-перше, тому що реальний світ завжди ширший за тестовий набір. Навіть якщо промпт добре поводиться на десятках чи сотнях внутрішніх кейсів, реальні користувачі принесуть тисячі варіацій формулювань, контекстів і кутових випадків, які неможливо передбачити наперед.
По-друге, тому що промпт — лише один із елементів системи. На поведінку впливають версія моделі, конфігурація температури, набір інструментів, структура пайплайна, механізми валідації й постпроцесингу. Зосередженість лише на тексті промпта відволікає від архітектурних рішень, які часто дають більший приріст надійності.
По-третє, тому що без системи оцінювання неможливо об’єктивно сказати, чи став промпт кращим після зміни. Воркшоп показує важливість «золотих» наборів даних і автоматизованих оцінок, які дозволяють вимірювати якість до й після змін, а не покладатися на інтуїцію інженера.
У підсумку формується інша картина ролей. Промпт-інжиніринг залишається важливою навичкою, але стає частиною ширшої дисципліни AI-інженерії, де ключовими є спостережуваність, оцінювання, операції та безперервне покращення.
Висновок: від ентузіазму до зрілості
Лондонський воркшоп Braintrust і Trainline показує, що перехід від прототипів до продакшн-готових AI-систем — це насамперед питання інженерної культури, а не лише вибору моделі чи фреймворку. Багатокрокові агенти, інструментальні флоу й реальні користувачі вимагають іншого рівня дисципліни: глибокої спостережуваності, системного оцінювання, чіткого управління змінами й готовності працювати в безперервному циклі покращень.
Вигаданий агент сапорту в цьому контексті — лише зручний навчальний приклад. Справжня цінність воркшопу — у демонстрації flywheel-підходу до AI-інженерії, який можна перенести в будь-яку галузь. І головний меседж звучить просто: епоха «воно працює в демо, значить, усе добре» для AI вже закінчилася. Настає час продакшн-орієнтованих практик, де промпт — лише початок розмови.