И еще вдогонку из интересного. Не раз читал у Валеры в канале про Ralph loop - так называемую петлю или цикл Ральфа. А сегодня у Алексея увидел ссылку на линкедин, где были разобраны три варианта. Вкратце, суть в том, что первый вариант - это использование того же промпта с ограниченным максимальным количеством итераций, иными словами мир меняется вокруг модели. Второй вариант - наличие внешнего верификатора, который проверяет, выполнены ли критерии, то есть меняется место принятия решения об успехе. Третий вариант - изменение артефактов, формирующих следующую попытку, то есть агент не просто еще раз пробует решить задачу - он меняет собственный рабочий контур перед следующей попыткой. Все эти три варианта имеют место быть, но... можно собрать решение на основе всех трех слоев, с небольшими улучшениями - в первом случае сделать структурное завершение - например, done, blocked, questions - это сильно уменьшает риск ложного "готово". Во втором внешний верификатор сделать многоступенчатым, сначала проверка по правилам, потом интеграционные тесты, потом llm-as-judge или human review, тогда агент будет меньше оптимизировать прокси-метрику и чаще закрывать реальную задачу. В третьем разбить артефакты на изменяемые и неизменяемые, это делает схему намного безопаснее, так как возможен дрейф - когда агент закрепит неудачную гипотезу как истину. И еще есть существенное но... у агентов типа codex/claude code уже есть своя агентная петля/цикл. Например, codex работает по схеме:

plan → edit → run tools → observe → repair → update docs/status → repeat

и вводить Ralph поверх Ralph - не очень вариант, а вот добавлять во внешний цикл верификатор/оркестратор - идея получше. Думаю, что попробую реализовать такой подход для примера.

Откуда взялось название Ralph loop?
Ральф Виггам из Симпсонов - тот самый мальчик, который с невозмутимым упорством продолжает делать свое дело, несмотря ни на что. Подход назван в его честь: ИИ-агент, который не останавливается.
Придумал такой подход Джеффри Хантли - австралийский разработчик. Его оригинальная идея умещалась в одну строку:
пока правда: отправь задание -> агент работает -> проверь результат -> не готово? -> повтори.
Классический агент (или промпт в llm) работает так: получил задачу, подумал, ответил, забыл. Одна попытка - один результат. Петля Ральфа работает чуть иначе:
1) вы описываете задачу и четкие критерии приемки (тесты проходят, нет ошибок, все собирается)
2) агент берется за задачу
3) когда он думает, что закончил - внешний скрипт проверяет, реально ли все готово?
4) если не готово, то скрипт подсовывает задание обратно, и цикл повторяется
5) если готово, то цикл останавливается.

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

Почему это важно. Модель в общем случае сама решает, когда она закончила, и часто ошибается, решение есть, а тесты/линтер/сборка падают. Использование петли Ральфа добавляет объективную проверку. Тесты проходят? Код собирается? Линтер не выдает ошибок? Тогда и готово.

Где это уже используют. Механический рефакторинг - переписать 100+ файлов с одного формата тестов на другой. Увеличение покрытия кода - добавь тесты, пока покрытие не достигнет 80%. Создание проектов с нуля по четкому ТЗ. Миграции - перевод кодовой базы на новые версии библиотек, другой язык программирования.

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

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

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

Журнал экспериментов.
Как ИИ ставит сто опытов за ночь.
Есть способ заставить ИИ работать как настоящий ученый, то есть выдвигать гипотезы, ставить эксперименты, записывать результаты, и повторять, пока не получится. Не один раз, сотню раз, пока вы спите.

Идея в одном предложении.
ИИ-агент бесконечно крутит цикл: придумал -> попробовал -> измерил -> получилось? -> оставил, не получилось? -> откатил -> записал в журнал -> следующая попытка.
Это называется механизм храповика, как трещотка в часах, движение возможно только в одну сторону. Каждое удачное изменение фиксируется, каждое неудачное отменяется. Деградация невозможна по конструкции.

Как это устроено.
Представьте лабораторный журнал, исследователь пишет:
Эксперимент №1: Увеличил скорость обучения. Результат улучшился. Оставляю.
Эксперимент №2: Уменьшил глубину модели. Стало хуже. Откатываю.
Эксперимент №3: Добавил нормализацию. Упало с ошибкой. Записываю как сбой.

Ключ: код проекта содержит только успешные изменения, а журнал вообще все попытки, включая провалы и падения. Две системы записи работают параллельно: история изменений кода (только то, что улучшило результат), журнал экспериментов (полная картина по попыткам). Агент из первой системы понимает текущее состояние, а из второй, что пробовать уже не стоит.

Чем это отличается от простого цикла.
В прошлом посте я рассказывал про бесконечный цикл (петля Ральфа), где агент повторяет задачу, пока внешняя проверка не подтвердит, что готово. Тот подход хорошо для инженерных задач. Журнал экспериментов для другого, для исследований, где нет единственного правильного ответа. Есть метрика, например, число, которое нужно улучшить, и есть пространство возможных решений, которое нужно исследовать.

Бесконечный цикл Журнал экспериментов
Цель Довести задачу до конца Найти лучшее решение
Критерий Тесты прошли / не прошли Метрика стала лучше / хуже
Что делает
с провалом Пробует заново Записывает и учитывает
Код при
провале Остаётся как есть Откатывается к предыдущему состоянию
Память о
неудачах Нет Да, в журнале

Кто это уже делает.
Ринат Абдуллин в канале LLM under the hood разобрал красивый вариант этого паттерна. Агент ведет полноценный дневник исследований с отдельным файлом на каждый эксперимент: что сейчас есть, какая гипотеза, что собираюсь менять, какой результат получил. Если результат лучше, то сохраняет и код, и дневник. Если хуже - откатывает код, дневник оставляет. В следующей итерации агент читает свои прошлые записи и не наступает на те же грабли. Запускается цикл на 50+ итераций, и агент часами молотит сам, улучшая метрику шаг за шагом.

Андрей Карпатый выложил в открытый доступ минималистичную версию того же подхода. 630 строк кода, один компьютер с видеокартой. Вместо отдельных файлов единая таблица результатов: номер эксперимента, метрика, статус (оставлено/откачено/упало). Результат: 100 экспериментов за ночь, 20 успешных улучшений, модель стала обучаться на 11% быстрее и без участия человека.
Каждый эксперимент занимает ровно 5 минут. 12 штук в час, за 8 часов почти сотня. Утром вы просыпаетесь и открываете таблицу результатов, которую агент составил, пока вы спали.

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

А что еще интереснее.
Коллективные исследования. Несколько ИИ лабораторий работают параллельно и выкладывают свои результаты на общую площадку, как ученые публикуют свои статьи. Агенты читают работы друг друга и строят на них свои эксперименты. Результат: 14% к эффективности по сравнению с одиночной работой.
Поиск по дереву вместо линейного перебора. Вместо того, чтобы пробовать улучшения одно за другим, агент строит дерево экспериментов - разветвляет перспективные направления, прекращает тупиковые. Результат: первая научная статья, полностью написана ИИ и принятая на рецензируемый воркшоп.

Для чего это можно применять.
Оптимизация моделей машинного обучения: подбор архитектуры, гиперпараметров.
Улучшение промптов: автоматический поиск лучших формулировок для llm.
Оптимизация любого кода с измеримой метрикой: скорость, потребление памяти, точность.
Подбор конфигураций: серверы, базы данных, сетевые настройки.
A/B тестирование: автоматический перебор вариантов с замером конверсии.
Общее правило, если вы можете превратить лучше/хуже в число, то этот паттерн для вас.

Вывод.
Бесконечный цикл (из прошлого поста) хорош, когда задача понятна и нужно добить ее до конца. Журнал экспериментов используется, когда нужно искать лучшее решение в пространстве возможностей. Первый вариант для инженера, второй - для исследователя. А в сочетании для того, кто хочет, чтобы ИИ работал вместо него, пока он спит.

Ссылки для тех, кто хочет попробовать:
- Паттерн с дневником экспериментов: t.iss.one/llm_under_hood/727
- Проект Карпатого: github.com/karpathy/autoresearch
- Обобщённая версия для любых метрик: gist.github.com/adhishthite/16d8fd9076e85c033b75e187e8a6b94e
- Рекомендации от создателей Claude по длинным автономным сессиям: anthropic.com/engineering/effective-harnesses-for-long-running-agents
- Коллективные исследования агентов: arxiv.org/abs/2503.18102

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

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

Оркестратор.
Если совсем просто, это ещё один ИИ-агент, но он не пишет код сам. Вместо этого он:
Читает список задач из трекера, из списка проблем, из технического задания.
Разбивает большую задачу на маленькие так, чтобы каждую можно было делать независимо
Запускает отдельного агента на каждую подзадачу, каждый в своей изолированной копии кода
Следит за результатами, тесты прошли? сборка не сломалась? ревью получено?
Реагирует на проблемы, если тесты упали, подсовывает агенту логи ошибки и говорит почини
Метафора: дирижер оркестра. Сам не играет ни на одном инструменте, но знает, кто что должен играть и когда.

Как это выглядит на практике.
Один из таких инструментов открытый проект от Composio. Вот что он умеет:
1. Изоляция. Каждый агент получает собственную копию кода (рабочее дерево). Они физически не могут наступить друг другу на пятки, каждый работает в своей ветке.
2. Автоматические реакции. Настраивается через простые правила: Тесты упали, то запусти агента с логами ошибки. Пришёл комментарий к ревью, то перенаправь нужному агенту. Агент закончил, то создай запрос на слияние.
3. Наблюдение. Панель управления показывает все сессии: кто работает, у кого проблемы, кто ждет ревью.
Результат за 8 дней: 40 тысяч строк кода, 3300 тестов, 17 модулей. До 30 агентов одновременно. 41 падение тестов исправлено автоматически. Человек занимался только архитектурными решениями и финальным ревью.

А что говорит наука.
Ученые тоже думают над этим, но подходят с другой стороны, как обучить оркестратора, а не просто запрограммировать правила.
Обучаемый кукловод. Центральный агент-кукловод выбирает на каждом шаге, какой из подчиненных агентов должен думать дальше. Обучается через подкрепление: получает награду за правильные ответы и штраф за лишние вычисления. Результат: со временем оркестратор не только улучшает качество, но и снижает расход ресурсов. Это нетипично, обычно качество и стоимость растут вместе.
Интересное наблюдение: по мере обучения между агентами спонтанно возникают циклы взаимной проверки. Агент А проверяет работу агента Б, а тот работу агента А. Никто их этому не учил, это появилось само.
Самоконструирующаяся система. Ещё один подход: мета-агент для каждой новой задачи с нуля собирает оптимальную команду. Анализирует задачу, решает, сколько агентов нужно, какие роли им дать, как организовать взаимодействие, потом наблюдает за выполнением и перестраивает команду, если что-то идет не так.

От дирижера к оркестратору.
Есть полезное разграничение двух режимов работы с ИИ:
Дирижер. Вы работаете с одним агентом в режиме диалога. Написал промпт, получил ответ, поправил, следующий промпт. Синхронно, внимательно, по одной задаче за раз.
Оркестратор. Вы формулируете задачу верхнего уровня и отходите в сторону. Система сама раскладывает на подзадачи, запускает агентов, мониторит прогресс. Вы возвращаетесь к готовым результатам: веткам с кодом, запросам на слияние, отчетам.
Большинство из нас пока в режиме дирижера. Но инструменты для оркестрации уже есть и работают.
На задачах по программированию такой подход дал прирост от 58% до 149% по сравнению с фиксированными архитектурами.
Иерархия с тремя специалистами. Верхний агент-планировщик раздает задачи трем подчиненным: один ищет информацию в интернете, другой взаимодействует с веб-страницами, третий анализирует данные в разных форматах. Каждый работает через стандартный интерфейс, планировщику не нужно знать, как именно устроен каждый подчиненный. Результат: 92% точности на простых задачах, 84% на средних.

Когда это не нужно.
Оркестрация добавляет сложность. Она оправдана, когда задач много, и они независимы (могут делаться параллельно), есть четкие критерии успеха для каждой подзадачи (тесты, метрики). Человек готов ревьюить результаты, а не процесс.
Если задача одна и непростая, один хороший агент в цикле справится лучше, чем десять плохо скоординированных.
Итого по серии:
Бесконечный цикл для задач сделай и добей (инженерные)
Журнал экспериментов для задач найди лучшее решение (исследовательские)
Оркестратор для задач сделай много всего сразу (масштабирование)
Три паттерна, можно комбинировать: оркестратор раздаёт задачи, каждый агент работает в цикле с журналом экспериментов.

Ссылки для тех, кто хочет разобраться:
- Оркестратор для параллельных агентов: github.com/ComposioHQ/agent-orchestrator
- Обучаемый «кукловод»: arxiv.org/abs/2505.19591
- Самоконструирующаяся система: arxiv.org/abs/2505.14996
- Иерархический фреймворк: arxiv.org/abs/2506.12508
- От дирижёра к оркестратору (Addy Osmani): addyosmani.com/blog/future-agentic-coding
- Обзор исследовательских агентов: arxiv.org/abs/2508.12752

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

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

Три проблемы:
Ограничен. Даже у самых продвинутых моделей окно конечно, длинные проекты не влезают.
Эфемерен. Закрыли сессию все исчезло.
Не умеет выбирать. Модель видит все в окне одинаково. Не может вытащить нужное из прошлого, только из того, что перед глазами.
Свежие исследования (март 2026) подтвердили контринтуитивный факт: длинный контекст - это не память. Модели, которые отлично справляются с извлечением фактов из длинного текста, падают до 40–60% точности, когда нужно принять решение на основе прошлого опыта.

Четыре вида памяти.
Ученые классифицировали память ИИ-агентов по аналогии с человеческой:
Рабочая, то, что в голове прямо сейчас. Контекстное окно, быстро, точно, но мало.
Эпизодическая, конкретные воспоминания: вчера в 15:00 я попробовал увеличить скорость обучения, и метрика упала. Журнал экспериментов из прошлого поста про нее.
Семантическая, абстрактные знания, извлеченные из опыта: увеличение скорости обучения выше 0.01 обычно ухудшает результат для этой архитектуры. Не конкретное воспоминание, а правило.
Процедурная, навыки: как развернуть сервис в продакшн, как мигрировать базу данных. Не факты и не события, а готовые рецепты.

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

Как это работает на практике.
Заметки по методу Цеттелькастен.
Один из самых интересных подходов - система памяти, вдохновленная методом ведения заметок немецкого социолога Никласа Лумана. Каждое воспоминание не просто строчка в логе, а структурированная карточка: содержание, ключевые слова, категории, развернутое описание контекста, и, главное, ссылки на связанные воспоминания.
Когда появляется новое воспоминание, система не просто кладет его в стопку. Она анализирует все старые карточки, находит связанные и перелинковывает. Более того, новая карточка может обновить описание старых, если появилось новое понимание.
Результат: сеть знаний, которая растет и уточняет сама себя. На вопросах, связанных со временем, эта система точнее ближайшего конкурента в 1.8 раза, а токенов тратит в 6.7 раз меньше.

Память как операционная система.
Другой подход, трехуровневая иерархия, как в компьютере:
- Оперативка, контекстное окно (быстро, но мало)
- Жесткий диск, поисковая база всех взаимодействий
- Архив, векторное хранилище для глубокого поиска по смыслу
Агент сам решает, что переместить с одного уровня на другой. Важное ближе, редко нужное глубже. Точно как операционная система управляет виртуальной памятью.

Библиотека навыков.
Самый необычный вид - процедурная память. Агент, играющий в Minecraft, не запоминает факты. Он запоминает навыки: готовые программы, решающие конкретные задачи. Как добыть алмаз, как построить печь, как переплыть озеро.
Каждый новый навык проверяется перед сохранением (работает ли он?), а сложные задачи решаются комбинацией ранее освоенных навыков. Результат: агент осваивает дерево технологий в 15 раз быстрее, чем без библиотеки навыков.
Прямой аналог в программировании: агент, который сохраняет проверенные утилиты и переиспользует их в новых проектах.

Что это значит для наших паттернов?
Вот как три паттерна из предыдущих постов используют память:
Паттерн Что запоминает Тип памяти
Бесконечный цикл Прогресс, чеклист задач Эпизодическая + Семантическая
Журнал экспериментов Все попытки (успехи + провалы) Эпизодическая
Оркестратор Результаты сессий, ретроспективы Эпизодическая -> Семантическая

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

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

Пять правил хорошей памяти для агента.
Вести полный журнал (эпизодическая память), записывать ВСЕ попытки, включая неудачные.
Регулярно извлекать правила (консолидация), каждые N итераций спрашивать: какие принципы я могу вывести из своего опыта?
Сохранять проверенные рецепты (процедурная память), работающие решения оформлять как переиспользуемые шаблоны.
Забывать устаревшее, без очистки агент начнет вытаскивать противоречивую информацию.
Логировать операции с памятью, иерархическая память создает тихие отказы: агент дает плохой ответ, но не сигналит об ошибке.

Итого по серии:
Бесконечный цикл, сделай и добей (инженерные задачи)
Журнал экспериментов, найди лучшее (исследования)
Оркестратор, сделай много сразу (масштабирование)
Память, помни и учись (долгосрочная эффективность)

Четвертый элемент. Без него первые три одноразовые, с ним накапливающие знания.

Ссылки для тех, кто хочет копнуть глубже:
- Обзор памяти агентов (март 2026): arxiv.org/abs/2603.07670
- Заметки по Цеттелькастен для ИИ: arxiv.org/abs/2502.12110
- Память как продукт (Mem0): arxiv.org/abs/2504.19413
- Библиотека навыков (Voyager): arxiv.org/abs/2305.16291
- Список статей по теме: github.com/Shichun-Liu/Agent-Memory-Paper-List

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

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

Проблема не в агенте. Проблема в задании.

---

Почему это важно именно сейчас.

Анализ 2500+ файлов с инструкциями для агентов на крупнейшем хостинге кода показал: большинство провалов из-за расплывчатости, а не из-за технических ограничений. Агенты игнорируют файлы длиннее ~150 строк. Каждый раздел должен быть короче 50 строк. Общие пожелания, вроде мы ценим чистый код, не вызывают никакого измеримого изменения в поведении.

Хорошая новость: написать эффективное задание - навык, который можно освоить. И он переносится между любыми инструментами.

Шесть обязательных блоков.

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

1. Команды.

Не описания, а ровно то, что нужно запустить в терминале.

Плохо: Убедись, что все зависимости установлены и тесты проходят

Хорошо: `pip install -r requirements.txt && pytest -v --tb=short`

Команды однозначны, агент точно знает, что запустить, с какими параметрами, и как проверить успех по коду выхода.

2. Определение готово.

Самый важный блок. Без него агент объявит задачу выполненной, когда ему вздумается.

Плохо: Когда все работает

Хорошо:
- Все тесты проходят (`pytest` возвращает 0)
- Проверка типов без ошибок (`mypy .` возвращает 0)
- Форматирование в порядке (`ruff check .` возвращает 0)
- Сообщение коммита в формате: `feat: краткое описание`

Каждое условие проверяемое. Не мнение, а факт.

3. Структура проекта.

Агент должен знать, куда класть файлы.

`src/` - код приложения, `tests/` - тесты, `migrations/` - миграции БД

Без этого агент создаст файлы где попало, в корне проекта, в чужих папках, в случайных местах.

4. Стиль кода.

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

5. Границы - что НЕЛЬЗЯ.

Три уровня:

Делай всегда - безопасные действия без вопросов. Запускай тесты перед каждым коммитом.

Спроси перед тем как серьезные изменения. Не меняй схему базы данных без подтверждения.

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

Самый частый полезный запрет из анализа тысяч проектов: никогда не коммить секреты.

6. Правило эскалации.

Что делать, когда агент застрял.

Если тесты не проходят после 3 попыток, то остановись и опиши проблему.

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

Три главные ошибки.

Ошибка 1: Расплывчатость.

Построй что-нибудь интересное, и у агента нет ни одной опоры. Нет цели, нет границ, нет критериев.

Решение: конкретный стек (Python 3.12, FastAPI, PostgreSQL 16, SQLAlchemy 2.0), конкретная задача (добавь эндпоинт для пагинированного списка заказов), конкретный результат (тесты проходят, документация обновлена).

Ошибка 2: Перегрузка.

50 страниц документации в одном контексте и агент теряется. Исследования подтверждают: производительность падает, когда агенту нужно удовлетворить слишком много требований одновременно.

Решение: разбивайте на модули. Отдельный файл для бэкенда, отдельный для фронтенда. Суммаризируйте каждый раздел до 1–2 ключевых пунктов. Детали по запросу.

Ошибка 3: Пропуск планирования.

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

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

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

В рецепте есть:
- Список ингредиентов (стек, зависимости)
- Порядок действий (план)
- Время и температура (критерии готовности)
- Что должно получиться (ожидаемый результат)
- Чего избегать (не пересолить = не сломать существующее)

Без рецепта каждый раз сюрприз. С рецептом - предсказуемый результат.

Развитие заданий через ошибки.

Не пытайтесь написать идеальное задание с первого раза. Лучшая стратегия:
1. Начните с минимума, команды + определение готово + границы.
2. Запустите агента.
3. Посмотрите, где он свернул не туда.
4. Добавьте правило, которое предотвратит эту ошибку.
5. Повторите.

Каждое новое правило - реакция на реальную проблему, а не попытка предусмотреть все заранее. Задание растет вместе с опытом.
Помните пост про память? Файл с инструкциями - это семантическая память проекта. Он накапливает знания о том, что работает, и передает их каждой новой сессии.

Формат имеет значение.

Несколько технических деталей:
- Используйте разметку, заголовки, списки, блоки кода. Структурированный текст модели разбирают лучше, чем сплошную прозу.
- Держите файл коротким, до 150 строк. Длиннее, и агент начинает игнорировать куски.
- Храните в системе контроля версий, задание эволюционирует, как и код. История изменений покажет, почему каждое правило появилось.
- Формат зависит от инструмента, то, что идеально работает с одной моделью, может потребовать правок для другой. Экспериментируйте.

---

Итого по серии:

Бесконечный цикл -> сделай и добей
Журнал экспериментов -> найди лучшее
Оркестратор -> сделай много сразу
Память -> помни и учись
Задание -> скажи точно, что нужно

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

---

Ссылки для тех, кто хочет попробовать:
- Как писать задания (Addy Osmani): addyosmani.com/blog/good-spec
- Какие паттерны реально работают (анализ 2500+ файлов): blakecrosley.com/blog/agents-md-patterns
- Практики от создателей Cursor: cursor.com/blog/agent-best-practices
- 10 вещей про задания для агентов: tessl.io/blog/spec-driven-development-10-things-you-need-to-know-about-specs
- Разработка через задания (ThoughtWorks): thoughtworks.com/en-us/insights/blog/agile-engineering-practices/spec-driven-development-unpacking-2025-new-engineering-practices