Technical Context
Я дивлюся на цей кейс не як на «прикольного бота», а як на прототип backend-сервісу: агент отримав доступ до API супермаркетів (Mercadona, Consum), сформував меню на сім'ю з трьох осіб і зібрав кошик на заданий бюджет. Стек — Claude Opus 4.6 і Claude Code, тобто зв'язка «потужна агентна модель + інструмент, що прискорює написання та правки коду в проекті».
Важлива деталь: це не просто генерація тексту. Агент виконує ланцюжок дій: планування раціону, обчислення обмежень по грошах і поживності, зіставлення інгредієнтів з каталогом магазину, потім — формування замовлення. Саме такі ланцюжки Opus 4.6 тягне краще за більшість моделей завдяки довгому контексту (до 1M токенів у беті), adaptive thinking та режимам effort, коли я можу керувати балансом вартості/швидкості/якості.
Я також зазначаю, що офіційні матеріали Anthropic про Claude Code і Opus 4.6 добре описують агентні workflow і роботу з кодовою базою, але майже не дають «рецепта» саме для e-commerce інтеграцій. Тому подібні звіти користувачів цінні: вони показують, що технічно все впирається не в те «чи може модель», а в те, як вибудувані інструменти (tool calling), права доступу та контури валідації.
Побічний ефект зі звіту — агент додав багато алкоголю. Для мене це маркер: без бізнес-правил та запобіжників (guardrails) модель оптимізуватиме «смак/різноманітність/вартість» на основі свого внутрішнього уявлення, яке може конфліктувати з очікуваннями сім'ї або політикою сервісу.
Business & Automation Impact
Якщо розкласти ідею по бізнесу, то це прямий удар по класичних сервісах доставки їжі та підписках на меню. Переможуть ті, хто швидше побудує ШІ рішення для бізнесу навколо конкретних каталогів, цін, промо, логістики та вподобань користувачів — тобто навколо даних та інтеграцій, а не навколо «розумного тексту».
Програють ті, хто продовжить продавати статичне меню без адаптації під локальні супермаркети та реальні ціни. У такому ринку value зміщується в автоматичний підбір і купівлю: користувач платить за зняття рутини, а не за PDF з рецептами.
Я б відразу закладав, що промислова автоматизація за допомогою ШІ тут вимагає трьох контурів контролю. Перший — політика купівлі (заборона алкоголю, ліміти за категоріями, алергенні винятки, дитячі вподобання). Другий — валідація кошика (ціна, наявність, заміни, одиниці виміру, дублікати). Третій — фінансова безпека (ліміти, підтвердження, журналювання, відкат).
З нашого досвіду в Nahornyi AI Lab, ключова помилка команд — намагатися «прикрутити модель до API» без архітектури: немає спостережуваності, немає версіонування промптів/політик, немає тестів на сценарії (наприклад, «бюджет 500€, але частина товарів недоступна»). У результаті прототип працює на демо, а в продакшені перетворюється на генератор випадкових кошиків і повернень.
Strategic Vision & Deep Dive
Мій неочевидний висновок: головний продукт тут — не «план харчування», а архітектура ШІ-рішень, де LLM стає оркестратором дій, а якість забезпечують детерміновані модулі. Я вбудовую модель між шарами: (1) нормалізатор потреб (КБЖВ/вподобання/бюджет), (2) оптимізатор кошика, (3) виконавці по API, (4) сувора валідація та симуляція замовлення.
У таких системах Opus 4.6 дає перевагу саме в довгих ланцюжках: можна утримувати контекст сім'ї, історію минулих замовлень, правила харчування та обмеження по бюджету. Але я не довіряю моделі фінальне рішення «що купити» без перевірок: алкоголь у кошику — рівно той клас помилок, який має ловитися не міркуванням, а політикою і тестами.
Ще один практичний патерн, який я використовую: поділ «план» і «виконання». Спочатку агент генерує план-специфікацію (структурований JSON з меню, інгредієнтами, лімітами та припущеннями), потім окремий виконавець перетворює це на запити до Mercadona/Consum. Це знижує вартість помилок і прискорює аудит — особливо коли ви робите впровадження ШІ у процес закупівель для B2C сервісу або корпоративної їдальні.
Я очікую, що у 2026-му з'явиться хвиля «meal-planning-to-order» стартапів, але виживуть ті, хто вирішить інтеграції та операційні деталі: повернення, заміни, промокоди, різні магазини, локальні каталоги, SLA та підтримку. Модель — вже не дефіцит; дефіцит — інженерна дисципліна та грамотна ШІ інтеграція в реальні ланцюжки поставок.
Цей розбір підготував Вадим Нагорний — провідний фахівець Nahornyi AI Lab з AI-автоматизації та впровадження агентних систем у реальному секторі. Я беру такі ідеї та доводжу їх до працюючих продуктів: від прототипу до продакшену зі спостережуваністю, безпекою та інтеграціями. Напишіть мені — обговоримо ваш сценарій (ритейл, фудтех, закупівлі, корпоративне харчування) і зберемо архітектуру під ваші API, бюджет і KPI.