Разборы · Статья: · Видео: · 34:49

Agentic AI Engineer: строим и чиним ИИ-агентов тем же циклом, что и код

Разбор доклада Mutagent с конференции AI Engineer: как перенести на ИИ-агентов инженерный цикл — spec-driven и eval-driven разработку, диагностику сбоёв в проде и learned failure modes — и почему на десятках агентов узким местом становится человек.

ИИ Программирование Продуктивность
Смотреть на YouTube

The Agentic AI Engineer - Benedikt Sanftl, Mutagent

AI Engineer · 34:49
Главы видео — нажми, чтобы перейти к моменту 9
  1. 0:18 Тот же loop — теперь для сборки агентов Loop, которым собирают ПО с coding-агентами, авторы применяют к сборке самих ИИ-агентов.
  2. 0:40 Два цикла: офлайн и онлайн Офлайн — итерируешь и оцениваешь при сборке; онлайн — после деплоя мониторишь трассы и возвращаешь их в оптимизацию.
  3. 1:53 Почему ручной цикл упирается в человека Ручной жизненный цикл медленный: узким местом становится ревью и время сборки человеком, это не масштабируется.
  4. 2:53 Стадии: спека, сборка, оценка, деплой, диагностика, оптимизация Полный конвейер от чистого листа: spec → build → eval → ship → diagnose → optimize, и цикл повторяется.
  5. 7:19 Спека как чертёж агента Спека фиксирует ответственности, контекст, инструменты, границы и критерии успеха — против неё сверяется реализация.
  6. 8:51 Сборка: спека отдельно от платформы Спека изолирована от харнеса, поэтому фреймворк можно сменить через год без переписывания агента.
  7. 11:26 Eval-driven development: когда агент готов Аналог TDD: агенту нужен termination gate. Полный eval-suite — продукт открытия, он растёт из сбоёв в проде.
  8. 18:57 Онлайн: диагностика сбоёв и learned failure modes Сбои группируют по первопричинам, копят историю failure modes и код-проверяемые индикаторы.
  9. 25:06 Mutagent: оркестратор, evaluator и diagnose агенты Продукт: оркестратор в coding-харнесе, два агента в research preview, коннекторы к трассам и таргеты вроде GitHub PR.

Коротко

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

Выжимка голосом

Самое ценное из разбора — за пару минут

0:00 2:18
Показать текст выжимки
Если коротко, это доклад стартапа Мьютейджент с конференции эй-ай инженер о том, как строить и чинить искусственных агентов тем же циклом, что и обычный код. Сначала спека — что агент должен делать. Потом сборка. Потом оценки, которые работают как тесты. Потом выкатка в продакшн. А дальше второй цикл: следишь за поведением агента вживую, находишь сбои, разбираешь причину и снова прогоняешь оценки. Простыми словами: пока агентов один-два, человек всё проверяет руками. Но когда их десятки, а трасс миллионы, ручная проверка становится узким местом и стоит дороже, чем сам запуск. Поэтому авторы предлагают отдать и оценку, и диагностику, и оптимизацию самим агентам. Стоит ли смотреть? Да, если вы делаете агентов всерьёз — это плотная методология и хороший словарь, хотя цифр и бенчмарков в докладе нет, а сам он во многом презентация продукта. Кому полезно в первую очередь: инженерам, которые строят агентов, и эм-эл инженерам, которые пишут оценки. Пригодится и тестировщикам, ведь оценки для агента — это по сути тесты, и техническим тимлидам, которые думают, как масштабировать поддержку. Два сильных инсайта. Первый: полный набор оценок нельзя придумать заранее — он рождается из реальных сбоёв в проде. Второй: читать все трассы дороже, чем запускать самих агентов, поэтому нужна умная выборка. Что делать на практике. Начните со спеки и держите её отдельно от фреймворка, чтобы сменить его без переписывания. Предпочитайте бинарные критерии баллам: провал сразу говорит, что чинить. И калибруйте эл-эл-эм-судью, иначе версии не сравнить честно. Важный контраргумент: человек не исчезает из цикла — он всё ещё проверяет допущения агента и выбирает исправления, просто смещается выше. И финальная мысль, чтобы взглянуть иначе: если агенты чинят агентов, встаёт вопрос — а кто диагностирует самого диагноста?

Озвучено синтезом речи · голос alena

Объясни проще

Суть без жаргона

Простыми словами

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

Как ребёнку

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

Аналогия — «это как…»

Это как конвейер контроля качества на заводе: деталь спроектировали (спека), собрали, проверили на стенде (оценки), отправили покупателю (прод), а потом собирают жалобы, находят причину брака и правят чертёж. Только здесь и контролёр на стенде, и мастер по разбору брака — это ИИ-агенты.

Зачем это мне

Когда у команды один-два агента, ручной цикл «поправил — протестил — задеплоил» работает. Но на десятках агентов и миллионах трасс проверка человеком становится узким местом и стоит дороже, чем сам запуск. Материал даёт словарь и рамку (spec-driven, eval-driven, learned failure modes, LLM-as-judge), по которым можно строить надёжных агентов, не утонув в ручном разборе логов.

Для тех, кто в теме

Доклад Mutagent переносит coding-agent loop на весь жизненный цикл агента: offline (spec → build → eval → ship) плюс online (monitor → diagnose → optimize). Ключевые тезисы: спека изолирована от харнеса (смена фреймворка без переписывания); eval-suite как product of discovery, растущий из production-сбоёв; бинарные критерии предпочтительнее score-based ради actionable feedback; калибровка LLM-as-judge против межпрогонной вариативности; code-checkable indicators плюс representative sampling трасс, потому что читать миллионы трасс дороже, чем их исполнять. Продукт: orchestrator плюс evaluator/diagnostics агенты внутри вашего coding-харнеса, коннекторы (LangFuse/Slack/тикеты) к таргетам (GitHub PR / MD-файлы).

Оценка видео

Чем выше — тем больше пользы на минуту

4.1

средняя из 5

Актуальность информации 4.6

Loops, spec-driven и eval-driven разработка агентов — одна из самых горячих тем AI-инженерии 2026 года.

Содержательность 4.2

Плотная методология полного жизненного цикла агента, но без цифр, бенчмарков и кода — местами абстрактно.

Инновационность идей 3.8

Перенос eval/diagnose в автономный агентный цикл свежий, хотя корни в TDD, observability и root cause analysis известны давно.

Практичность 3.9

Даёт рабочую рамку и словарь, но это конференц-питч продукта: конкретики «как внедрить у себя» немного.

Фокус на надёжности в проде 4.1

Сильная часть — learned failure modes, recursive why chain и representative sampling трасс вместо чтения всех логов.

Кому будет полезно

Чем выше оценка — тем больше пользы для профессии. Разверни — почему.

Для AI-инженеров и разработчиков агентов 5 /5

Прямое попадание: весь доклад — про методологию сборки, оценки и поддержки агентов в проде как инженерный цикл.

Для ML-инженеров 4.3 /5

Полезны разделы про eval-suite, бинарные критерии против балльных и калибровку LLM-as-judge от межпрогонного шума.

Для QA-инженеров и тестировщиков 4 /5

Eval-driven development — это TDD для агентов: termination gate, критерии готовности и систематизация failure modes.

Для технических тимлидов и CTO 4 /5

Отвечает на вопрос масштабирования: где именно человек становится узким местом и что отдавать агентам.

Для основателей AI-стартапов 3.8 /5

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

Для продакт-менеджеров AI-продуктов 3.5 /5

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

Инсайты

Нажми, чтобы раскрыть — то, что меняет взгляд на тему

01 Агента строят так же, как пишут код — в цикле 0:40

Ключевой сдвиг взгляда: агент — не разовый артефакт, а объект непрерывного цикла spec → build → eval → ship → diagnose → optimize. И каждую стадию этого цикла можно поручить агенту.

02 Человек — это узкое место, а не агент 2:33

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

03 Полный набор оценок нельзя написать заранее 13:03

Eval-suite — не то, что можно угадать на старте с доменными экспертами. Настоящий, полный набор критериев рождается из пользовательской обратной связи и сбоёв в проде: это «продукт открытия».

04 Бинарные критерии полезнее оценок с баллами 17:20

Балл без чёткого рубрика не говорит, что чинить. Бинарный критерий «прошёл / не прошёл» даёт call-to-action: когда он падает, ты сразу знаешь, что именно сломалось и как это лечить.

05 Читать все трассы дороже, чем их запускать 21:25

Контринтуитивная экономика диагностики: на миллионах трасс полное чтение через LLM стоит больше, чем само исполнение агентов. Отсюда — representative sampling и код-проверяемые индикаторы сбоёв.

Ключевые цитаты

Сильные фразы из видео — нажми тайм-код, чтобы услышать в оригинале

«Узким местом становится ручная проверка человеком и время, которое человек тратит на сборку.»
Bene Почему ручной цикл сборки агентов не масштабируется. 1:53
«Делать это агентно — вот ключ к росту пропускной способности: в то же окно времени влезает куда больше циклов.»
Burak Зачем автоматизировать сам цикл сборки. 2:33
«Чёткая спека становится чертежом для всей дальнейшей разработки, с которым сверяется реализация.»
Burak Роль спеки в spec-driven development для агентов. 8:32
«Настоящий, полный набор оценок — это продукт открытия.»
Burak Почему eval-suite нельзя написать заранее. 13:03
«Твоя работа теперь — проектировать эти циклы с чётким гейтом оценки или условием остановки.»
Burak Как меняется роль инженера, когда рутину делают агенты. 14:43
«Чтобы оценка была полезной, она должна давать обратную связь, по которой можно действовать.»
Burak Что отличает полезный eval от бесполезного балла. 17:20
«Если у тебя миллионы трасс агента, прочитать их все стоит дороже, чем сам их запуск.»
Burak Почему диагностику нельзя строить на чтении всех трасс. 21:25
«Хватит отлаживать вручную — пусть рутину делают агенты.»
Bene Финальный посыл доклада. 34:30

Полезные советы

Что можно применить уже сегодня. Разверни совет — сколько займёт, что даст и что конкретно делать

1

Начни агента со спеки

1–2 часа чертёж, от которого реализация не расползётся

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

Что делать

  1. 1 Выпиши jobs-to-be-done: что агент обязан обрабатывать и что явно вне зоны.
  2. 2 Перечисли требования к контексту, интеграции и инструменты.
  3. 3 Зафиксируй constraints и критерии успеха — по ним потом строятся evals.
2

Держи спеку отдельно от харнеса

30 минут сменишь фреймворк через год без переписывания агента

Пространство агентных фреймворков меняется быстро, и любой упрётся в потолок возможностей харнеса. Если спека изолирована от реализации, coding-агент пересоберёт агента под новую платформу из той же спеки.

3

Веди разработку от оценок (eval-driven)

вечер чёткое условие «агент готов» вместо ощущений

Как TDD для кода: агенту нужен termination gate. Собирай eval-suite из метрик/критериев и датасета кейсов, которые агент обязан удовлетворить.

Что делать

  1. 1 Стартуй с исторических или синтезированных данных из известной выборки.
  2. 2 Прогоняй агента против набора и смотри, где он падает.
  3. 3 Добавляй в датасет edge-кейсы из прода — suite растёт со временем.
4

Предпочитай бинарные критерии баллам

20 минут провал оценки сразу говорит, что чинить

Балльная оценка полезна только при очень чётком рубрике. Бинарный критерий «прошёл / не прошёл» даёт понятный call-to-action при провале.

Что делать

  1. 1 Пройдись по своим score-based метрикам.
  2. 2 Там, где рубрик размыт, переформулируй в бинарный критерий.
  3. 3 К каждому провалу привяжи понятное действие «что чинить».
5

Калибруй LLM-as-judge

полдня сравнение версий агента станет достоверным

LLM недетерминирован: один и тот же судья оценивает одну и ту же задачу по-разному. Без калибровки шум между прогонами не даст честно сказать, что новая версия лучше старой.

Что делать

  1. 1 Прогони судью несколько раз на одних и тех же кейсах.
  2. 2 Оцени разброс оценок и зафиксируй его.
  3. 3 Подкрути промпт/рубрик судьи, пока вариативность не станет приемлемой.
6

Собирай learned failure modes из прода

неделя агент копит историю сбоёв и сам проверяется против неё

Каждый сбой в проде встречается не один раз. Группируй occurrences по первопричинам, выводи из них новые eval-критерии и заводи их обратно в спеку и агента.

7

Не читай все трассы — сэмплируй

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

На масштабе полное чтение трасс через LLM дороже исполнения. Бери представительную выборку умной сегментацией и опирайся на код-проверяемые индикаторы известных сбоёв.

Что делать

  1. 1 Выдели для каждого failure mode код-проверяемый индикатор (контент или последовательность вызовов).
  2. 2 Отфильтруй трассы многоуровневой сегментацией.
  3. 3 Читай LLM только представительную выборку, остальное лови индикаторами.
8

Запусти diagnose-агент в своём coding-харнесе

вечер root cause анализ трасс без ручного чтения логов

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

Что делать

  1. 1 Подключи источник трасс (LangFuse, локальный лог, JSONL-экспорт).
  2. 2 Задай scope диагностики — конкретный агент или скилл.
  3. 3 Проверь блок assumptions, выбери remedies и получи markdown-задачу для правок.

Сценарии применения

Как разные люди применяют это на практике

Я как AI-инженер продуктовой команды

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

Хочу: ускорить итерации, не теряя контроль над качеством

Поможет: статья даёт модель agentic loop: какие стадии автоматизировать и где ставить eval-гейт

Я как ML-инженер по оценкам

Проблема: eval-suite неполный, а LLM-судья шумит, и версии агента невозможно честно сравнить

Хочу: сделать оценки стабильными и информативными

Поможет: разбор объясняет бинарные критерии, калибровку судьи и рост suite из production-сбоёв

Я как QA-инженер

Проблема: непонятно, когда агент «достаточно хорош», чтобы его выпускать

Хочу: формальное условие готовности вместо интуиции

Поможет: eval-driven development даёт termination gate и систематизацию failure modes

Я как Продакт-менеджер AI-фичи

Проблема: жалобы пользователей на сбои агента теряются в Slack и тикетах

Хочу: систематически ловить и приоритизировать сбои

Поможет: diagnose-агент кластеризует failure modes и превращает их в конкретные задачи на исправление

Я как Технический тимлид

Проблема: агентов в продукте всё больше, а ревью и поддержка держатся на людях и не масштабируются

Хочу: понять, что отдать агентам, чтобы вырос throughput

Поможет: материал показывает, где человек — узкое место, и как сделать цикл агентным

Я как Дежурный инженер (on-call)

Проблема: разбор инцидента требует читать миллионы трасс — это дорого и медленно

Хочу: находить первопричину быстро и дёшево

Поможет: representative sampling и код-проверяемые индикаторы дают root cause без чтения всех логов

Я как Основатель AI-стартапа

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

Хочу: масштабируемую модель разработки и эксплуатации агентов

Поможет: доклад даёт целостный вижн offline+online loop, который можно строить агентно

Я как Дата-сайентист

Проблема: эксперименты над агентом неубедительны из-за недетерминизма LLM-оценок

Хочу: воспроизводимо доказывать, что улучшение реально

Поможет: калибровка LLM-as-judge и бинарные критерии снижают шум и делают выводы надёжнее

Логика повествования

Как устроена аргументация видео — пройди по шагам

Предпосылка Аргумент Пример Вывод
  1. Предпосылка Сборка ПО стала циклом с coding-агентами 0:18

    Loops — горячая тема: софт строят в агентном цикле. Это исходная точка рассуждения.

  2. Аргумент Тот же цикл применим к сборке агентов 0:40

    Офлайн-цикл (итерируешь и оцениваешь) плюс онлайн-цикл (мониторишь прод и возвращаешь в оптимизацию).

  3. Аргумент Ручной цикл упирается в человека 1:53

    Ревью и время сборки человеком — узкое место; на многих агентах это не масштабируется.

  4. Аргумент Разложим цикл на стадии 2:53

    spec → build → eval → ship → diagnose → optimize, и всё повторяется по кругу.

  5. Пример Eval-driven development даёт условие остановки 11:26

    Как TDD: агенту нужен termination gate. Полный eval-suite — продукт открытия из production-сбоёв.

  6. Пример В проде агент копит learned failure modes 18:57

    Сбои группируются по первопричинам, появляются код-проверяемые индикаторы для дешёвой диагностики.

  7. Аргумент Читать все трассы дороже запуска 21:25

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

  8. Вывод Каждую стадию делает агент — это Agentic AI Engineer 25:06

    Оркестратор дирижирует evaluator и diagnose агентами внутри coding-харнеса; цикл замыкается автономно.

Подробный разбор

Полный разбор — разверни, если нужно глубже

Развернуть подробный разбор

Стоит ли смотреть целиком

Да — если вы строите ИИ-агентов всерьёз и хотите не отдельных трюков, а целостной инженерной рамки. Ценность доклада не в новых компонентах (evals, трассы, root cause analysis существовали и раньше), а в том, что он собирает их в один замкнутый жизненный цикл: спека → сборка → оценки → деплой → диагностика → оптимизация, где каждую стадию можно поручить агенту.

Держите в голове формат: это 35-минутный конференц-питч Mutagent, а не туториал. Цифр, бенчмарков и живого кода тут нет, демо диагностики — заранее сгенерированное. Поэтому смотреть стоит ради словаря и модели мышления, а не ради готового рецепта внедрения.

Что унести с собой уже сегодня

Три идеи применимы независимо от продукта Mutagent. Первая: относитесь к eval-suite как к продукту открытия — не пытайтесь угадать все критерии на старте, растите их из реальных сбоёв. Вторая: экономика диагностики на масштабе переворачивается — читать все трассы через LLM дороже, чем исполнять агентов, поэтому нужны представительная выборка и код-проверяемые индикаторы. Третья: самый практичный шаг — поручить diagnose-агенту вытащить трассы, найти failure modes и выдать remedies как markdown-задачу для вашего coding-агента, вместо ручного чтения дашбордов наблюдаемости.

План внедрения

С чего начать — отмечай шаги, прогресс сохранится

Выполнено 0 из 7

Проверь себя

Ответь на вопросы, чтобы материал закрепился

Отвечено: 0 / 7 Верно: 0

  1. 1. Что Mutagent предлагает сделать с циклом сборки и поддержки агентов?

  2. 2. Что такое eval-driven development в докладе?

  3. 3. Почему полный eval-suite нельзя написать заранее?

  4. 4. Почему бинарные критерии часто предпочтительнее балльных?

  5. 5. Почему не стоит читать все трассы агента при диагностике?

  6. 6. Зачем калибровать LLM-as-judge?

  7. 7. Что делают два агента Mutagent в research preview?

Словарь терминов

Понять незнакомое простым языком

Показать 12 терминов
Loop (цикл)
Итеративный процесс сборки и улучшения: пробуешь, оцениваешь, правишь и повторяешь. Тот же приём, что при разработке кода с агентами.
Offline / online loop
Офлайн — цикл при сборке (итерируешь и оцениваешь до деплоя). Онлайн — цикл после запуска: мониторишь прод, диагностируешь сбои и возвращаешь их в оптимизацию.
Spec-driven development
Начинать с формальной спецификации агента — ответственности, контекст, инструменты, границы, критерии успеха — и сверять с ней реализацию.
Eval-driven development
Разработка от набора оценок как условия готовности. Аналог test-driven development, но для агентов.
Eval suite
Набор метрик и критериев плюс датасет кейсов, которые агент обязан удовлетворить, чтобы считаться работающим.
LLM-as-a-judge
Использование языковой модели как «судьи», оценивающего выход другого агента. Требует калибровки из-за недетерминизма.
Trace (трасса)
Полная запись пути выполнения агента: входы, вызовы инструментов, промежуточные и финальный выходы.
Trajectory (траектория)
Последовательность шагов и вызовов инструментов, по которым агент шёл от задачи к ответу.
Failure mode
Тип повторяющегося сбоя агента, сгруппированный по первопричине (например, пробел в промпте или неработающий инструмент).
Root cause analysis
Поиск первопричины сбоя. В докладе — через «recursive why chain», цепочку «почему», ведущую к источнику проблемы.
Harness
Среда или каркас, в котором запускается агент (например, Claude Code, Codex, кастомный runtime). Влияет на поведение агента.
Orchestrator
Агент-диспетчер, который распределяет работу между суб-агентами и стадиями цикла внутри coding-окружения.

Критический взгляд

Объективно: с какими тезисами можно поспорить и что преувеличено

Однобоко

Обещание «полностью агентного» цикла разработки

Это конференц-питч продукта в research preview: автономная оптимизация показана концептуально, без цифр, бенчмарков и данных о надёжности на реальном масштабе. Демо диагностики к тому же pre-generated, потому что «прогон занимает заметное время».

Преувеличение

«Человек перестаёт быть узким местом»

Скорее смещается, чем исчезает: человек всё ещё проверяет блок assumptions агента, выбирает remedies (multi-choice) и даёт финальный feedback. Ответственность за решения остаётся на людях.

Упрощение

Бинарные критерии предпочтительнее балльных

Как общее правило спорно: для «мягких» качеств (релевантность, тон, полнота) градация несёт информацию, которую бинарность теряет. Разумнее сочетать типы оценок под задачу, а не отказываться от баллов.

Спорно

Калибровка убирает шум LLM-судьи

Калибровка снижает межпрогонную вариативность, но не устраняет системную предвзятость самого судьи и его слепые зоны. «Откалиброванный» не значит «объективный».

Взгляни иначе

Новый угол, смежные области и потенциал на стыке — пища для размышлений

Другой угол

Кто диагностирует диагноста?

Если diagnose-агент сам ошибается или делает неверные assumptions (авторы честно вводят для этого отдельный блок), встаёт рекурсия: качество автономного цикла упирается в качество агента, который его чинит. Гейт нужен и на мета-уровне.

На стыке областей

Это контроль качества с завода, переодетый в AI

Learned failure modes — это карты дефектов, recursive why chain — «5 почему» из Lean/Toyota, representative sampling — статистический контроль процессов (SPC). Полвека промышленного QA переносится на агентов почти один в один.

Смежная область

Та же методика — для любых недетерминированных пайплайнов

Spec → eval → diagnose → optimize не привязан к «агентам»: так же можно вести ETL, рекомендации, модерацию или скоринг — любую систему, где выход недетерминирован, а сбои повторяются.

Другой угол

Спека — это долговременный актив, а не документ

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

На стыке областей

Код-проверяемые индикаторы = регрессионные тесты поведения

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

Похожие разборы

Разбор

Spec-driven development: спека до кода как способ приручить ИИ-ассистента

Spec-driven development — это писать требования и дизайн-документ в markdown до того, как ИИ-ассистент напишет хоть строчку кода: так модель получает контекст и не сходит с рельсов. Главный вывод — инструмент вроде Kiro лишь автоматизирует процесс, но ответственность, ревью и правка спек остаются на человеке.

Читать → Разбор

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

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

Читать → Разбор

Модель предлагает — платформа решает: инфраструктура надёжности для автономных ИИ-агентов

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

Читать → Разбор

RL-агент для упавших ETL-пайплайнов: восстановление за минуты и дисциплина вовремя остановиться

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

Читать →
← Все разборы Смотреть видео-источник