Про плотность типов точно, у меня то же на плотности абстракций в плане. На задачах вида «поправить дженерик в трёх местах» батч держит 10-15 файлов. Когда план трогает type inference, режу до 3-5; дальше агент теряет нить между файлами. «Контекст расплывается» это в точности то ощущение, что у тебя на дженериках.
Согласен, критик тоже галлюцинирует, не панацея. У меня он ловит другой класс ошибок: провисшие допущения из плана. Например, план говорил «функция идемпотентна», критик идёт проверяет, а что будет если её случайно вызвать дважды? Тесты этого не проверяют, билд зелёный, допущение тихо не работает.
Финальное «годен/негоден» всё равно у меня. Цепочка агент → критик → я. Без понимания бизнес-логики на моей стороне ничего не починить, тут согласен.
Метрики работают, у меня что-то похожее. Завожу на уровне типов операций. Агент целиком слишком крупная гранула для алёрта. Алёрт выскакивает когда «сборщик отчётов» за час сделал outbound HTTP-запросов в два раза больше своего baseline. Сработало пару раз, один false-positive (легитимная массовая выгрузка), но это норм. Сложно с калибровкой baseline: для агентов, которые сами решают что делать, он плавающий.
У меня то же — пишу компилятор с агентами. LangChain прошёл и слез, AutoGen после рассказов знакомых даже пробовать не стал. Сейчас просто план + критерии приёмки, агент исполняет, второй проверяет. Без оркестрации. Работает.
Про лимит инструментов подтверждаю — у меня пять, и то иногда не тот выбирает.
А что у тебя в проде из перечисленного реально кормит?
Зацепило про tool chaining. У меня в команде было ровно такое: чтение CRM безобидное, отправка письма безобидная, а вместе получилась тихая эксфильтрация на пару недель. Заметили только по нетипичному объёму исходящих, по логике не отличить.
У меня свой слой рядом с твоими — после задачи отдельный агент гоняется по коду и смотрит допущения, на которых тесты держатся. Это про корректность результата, runtime ты уже закрыл.
Про silent logic change — тот же класс ошибок у меня на компиляторе. Был план, где агент перетипизировал утилитную функцию, тесты прошли, а через день я случайно открыл вызов из другого модуля и увидел что возвращается не то.
Помогает второй агент — после закрытия плана отдельный смотрит допущения, на которых тесты держатся. Пару раз ловил то, что ревью пропускало.
5-15 файлов в батче — это эмпирика? У меня плавает.
Близко по ощущениям. У меня не SaaS, компилятор — но та же штука: агенты неделями пишут код, всё локально работает. А когда первый раз показал репозиторий знакомому, он спросил «и что я с этим должен делать?». Само наличие компилятора без документации, примеров и объяснения зачем оно нужно — никому не интересно. И вот это уже агентам не отдашь.
Хороший выстрел. Признаю — текст руками, но идею про low-effort vs high-effort обкатал с агентом сначала: он защищал что метки ловят 80%, мне пришлось переубеждать. Это и есть high-effort процесс, который никакой AGENTS.md не отличит от ручной работы: внутренняя итерация в споре, не финальный вывод.
Парадокс: чем серьёзнее работа с AI — тем меньше внешних признаков что AI вообще был задействован. Метки ловят только неаккуратное использование.
Точно — говорим о разных уровнях. Твоя статья про каркас (как запустить агента с произвольной логикой), у меня про дисциплину поверх (как валидировать что агент сделал что нужно, особенно на длинных задачах).
Эти штуки не конкурируют, скорее ортогональны: на твой каркас можно накатить мой цикл аудита, и наоборот — мои планы можно гонять через твою систему systemd+email вместо ручного запуска.
Спасибо за статью, идея «email как универсальный протокол» интересная.
Согласен — для конфигов в git и так есть восстановление через git checkout. У меня вопрос был больше про более сложные ситуации, когда агент в длинной автономной сессии может накатить архитектурную правку и сломать собственный цикл работы.
Интересно «я пытался» — пытался конкретно с email-циклом или с подходом «план как контракт» в принципе? У меня работает когда задача разбита на 5-15 минут исполнения с явными критериями приёмки. На задачах с непредсказуемым исполнением — ломается так же.
Сходный паттерн на разработке компилятора — гоняю агентов автономно часами через тот же подход: план как контракт, нулевая регрессия тестов как жёсткий барьер. Без email/systemd, но идея та же — несколько часов работы без присмотра.
Самый частый сбой — не сам код, а уверенность агента в том, что проверил. Тесты проходят в одном канале исполнения, ничего не знают про второй. Решил через отдельный цикл аудита: после закрытия плана другой агент с другим системным промптом ищет дыры в допущениях. Поймало 3 критических дыры в корректности на одном из планов, которые мои обычные тесты пропустили.
Как у тебя с самомодификацией — есть какой-то антифриз чтобы не самостирался?
Делаю похожее со стороны разработчика — пишу свой язык под AI-агентов (месяц, ~1000 тестов проходит, 125 планов закрыто автономно). Согласен что главное противоречие — «agent-first» как фича языка vs как свойство экосистемы. Язык сам по себе мало что меняет, если нет методологии работы с агентами (план как контракт, цикл аудита, эскалация по порогам).
Конкретно у меня: AI-агент уверенно ошибается в 4 типах ситуаций — выдуманные факты, защита старых решений, выход за пределы привычного, эхо-камера. Безопаснее всего ловить это другим агентом-критиком с обратным углом, не сильнее «правильного» промптом.
А ты пробовал Zero на длинных задачах (часы автономной работы), где агент сам держит цикл «спроектируй, проверь, сдай»?
Совпадает, но добавлю — изменилось не содержание промптов, а распределение труда. Раньше: 70% на тонкий промпт, 30% на проверку ответа. С рассуждающими моделями наоборот: 30% — короткий промпт с контекстом, 70% — критерии приёмки и проверка после.
Побочный эффект: стало можно запускать модель автономно по плану на часы, без присмотра — она сама держит цикл «проверь, сдай». Старый промпт-инжиниринг такого не давал.
Похожий опыт на компиляторе (эффекты + GC, не Rust). Сильнее всего бьёт не код сам по себе, а уверенность агента: настаивает что работает, а тесты в одном прогоне проходят, в другом падают.
Твои нарушения алиасинга — типовое заимствование там, где оно запрещено. У меня защита — отдельный агент-критик: проверяет допущения, а не код. Miri у тебя играет ту же роль, только снаружи.
А на unsafe Rust ловил случаи когда модель упирается в своё решение недельной давности, хотя новые данные говорят против?
Интересно с producer-side: автономно гоняю агентов на разработке компилятора, коммиты проходят review без меток «AI-сгенерировано». Разница не в «использовал агента vs не использовал», а в наличии плана + acceptance criteria + аудит-цикла перед коммитом. Если есть — markers из твоего списка не появляются (агент не оставляет cargo-cult, лишних импортов, «TODO: handle errors»).
Возможно правильный фильтр — не «AI vs human», а «low-effort vs high-effort». AGENTS.md ловит первое, но не второе — а второе и становится новой нормой.
Похожий опыт на разработке компилятора (с эффектами + GC, не Rust). Catalog’ил 4 категории сбоев: hallucinated facts (агент утверждает что фича работает — тесты PASS в одном пайплайне, FAIL в другом), defending past positions (защищает свой же дизайн недельной давности под новыми данными), off-distribution (стандартный паттерн на нестандартный nuance), echo chamber (множество reviewer-агентов с одинаковым системным промптом валидируют друг друга).
Твои aliasing violations попадают в #3 — стандартный borrowing паттерн в unsafe-контексте, где он invalid. У меня митигация — отдельный audit-агент с adversarial framing’ом, проверяет assumption holes, не код. Miri в твоём случае внешний механизм с той же ролью.
Какие из patterns 1, 2, 4 ты у себя видел на unsafe Rust?
Про плотность типов точно, у меня то же на плотности абстракций в плане. На задачах вида «поправить дженерик в трёх местах» батч держит 10-15 файлов. Когда план трогает type inference, режу до 3-5; дальше агент теряет нить между файлами. «Контекст расплывается» это в точности то ощущение, что у тебя на дженериках.
Согласен, критик тоже галлюцинирует, не панацея. У меня он ловит другой класс ошибок: провисшие допущения из плана. Например, план говорил «функция идемпотентна», критик идёт проверяет, а что будет если её случайно вызвать дважды? Тесты этого не проверяют, билд зелёный, допущение тихо не работает.
Финальное «годен/негоден» всё равно у меня. Цепочка агент → критик → я. Без понимания бизнес-логики на моей стороне ничего не починить, тут согласен.
Метрики работают, у меня что-то похожее. Завожу на уровне типов операций. Агент целиком слишком крупная гранула для алёрта. Алёрт выскакивает когда «сборщик отчётов» за час сделал outbound HTTP-запросов в два раза больше своего baseline. Сработало пару раз, один false-positive (легитимная массовая выгрузка), но это норм. Сложно с калибровкой baseline: для агентов, которые сами решают что делать, он плавающий.
У меня то же — пишу компилятор с агентами. LangChain прошёл и слез, AutoGen после рассказов знакомых даже пробовать не стал. Сейчас просто план + критерии приёмки, агент исполняет, второй проверяет. Без оркестрации. Работает.
Про лимит инструментов подтверждаю — у меня пять, и то иногда не тот выбирает.
А что у тебя в проде из перечисленного реально кормит?
Зацепило про tool chaining. У меня в команде было ровно такое: чтение CRM безобидное, отправка письма безобидная, а вместе получилась тихая эксфильтрация на пару недель. Заметили только по нетипичному объёму исходящих, по логике не отличить.
У меня свой слой рядом с твоими — после задачи отдельный агент гоняется по коду и смотрит допущения, на которых тесты держатся. Это про корректность результата, runtime ты уже закрыл.
Про silent logic change — тот же класс ошибок у меня на компиляторе. Был план, где агент перетипизировал утилитную функцию, тесты прошли, а через день я случайно открыл вызов из другого модуля и увидел что возвращается не то.
Помогает второй агент — после закрытия плана отдельный смотрит допущения, на которых тесты держатся. Пару раз ловил то, что ревью пропускало.
5-15 файлов в батче — это эмпирика? У меня плавает.
Близко по ощущениям. У меня не SaaS, компилятор — но та же штука: агенты неделями пишут код, всё локально работает. А когда первый раз показал репозиторий знакомому, он спросил «и что я с этим должен делать?». Само наличие компилятора без документации, примеров и объяснения зачем оно нужно — никому не интересно. И вот это уже агентам не отдашь.
Хороший выстрел. Признаю — текст руками, но идею про low-effort vs high-effort обкатал с агентом сначала: он защищал что метки ловят 80%, мне пришлось переубеждать. Это и есть high-effort процесс, который никакой AGENTS.md не отличит от ручной работы: внутренняя итерация в споре, не финальный вывод.
Парадокс: чем серьёзнее работа с AI — тем меньше внешних признаков что AI вообще был задействован. Метки ловят только неаккуратное использование.
Точно — говорим о разных уровнях. Твоя статья про каркас (как запустить агента с произвольной логикой), у меня про дисциплину поверх (как валидировать что агент сделал что нужно, особенно на длинных задачах).
Эти штуки не конкурируют, скорее ортогональны: на твой каркас можно накатить мой цикл аудита, и наоборот — мои планы можно гонять через твою систему systemd+email вместо ручного запуска.
Спасибо за статью, идея «email как универсальный протокол» интересная.
Согласен — для конфигов в git и так есть восстановление через git checkout. У меня вопрос был больше про более сложные ситуации, когда агент в длинной автономной сессии может накатить архитектурную правку и сломать собственный цикл работы.
Интересно «я пытался» — пытался конкретно с email-циклом или с подходом «план как контракт» в принципе? У меня работает когда задача разбита на 5-15 минут исполнения с явными критериями приёмки. На задачах с непредсказуемым исполнением — ломается так же.
Сходный паттерн на разработке компилятора — гоняю агентов автономно часами через тот же подход: план как контракт, нулевая регрессия тестов как жёсткий барьер. Без email/systemd, но идея та же — несколько часов работы без присмотра.
Самый частый сбой — не сам код, а уверенность агента в том, что проверил. Тесты проходят в одном канале исполнения, ничего не знают про второй. Решил через отдельный цикл аудита: после закрытия плана другой агент с другим системным промптом ищет дыры в допущениях. Поймало 3 критических дыры в корректности на одном из планов, которые мои обычные тесты пропустили.
Как у тебя с самомодификацией — есть какой-то антифриз чтобы не самостирался?
Делаю похожее со стороны разработчика — пишу свой язык под AI-агентов (месяц, ~1000 тестов проходит, 125 планов закрыто автономно). Согласен что главное противоречие — «agent-first» как фича языка vs как свойство экосистемы. Язык сам по себе мало что меняет, если нет методологии работы с агентами (план как контракт, цикл аудита, эскалация по порогам).
Конкретно у меня: AI-агент уверенно ошибается в 4 типах ситуаций — выдуманные факты, защита старых решений, выход за пределы привычного, эхо-камера. Безопаснее всего ловить это другим агентом-критиком с обратным углом, не сильнее «правильного» промптом.
А ты пробовал Zero на длинных задачах (часы автономной работы), где агент сам держит цикл «спроектируй, проверь, сдай»?
Совпадает, но добавлю — изменилось не содержание промптов, а распределение труда. Раньше: 70% на тонкий промпт, 30% на проверку ответа. С рассуждающими моделями наоборот: 30% — короткий промпт с контекстом, 70% — критерии приёмки и проверка после.
Побочный эффект: стало можно запускать модель автономно по плану на часы, без присмотра — она сама держит цикл «проверь, сдай». Старый промпт-инжиниринг такого не давал.
Похожий опыт на компиляторе (эффекты + GC, не Rust). Сильнее всего бьёт не код сам по себе, а уверенность агента: настаивает что работает, а тесты в одном прогоне проходят, в другом падают.
Твои нарушения алиасинга — типовое заимствование там, где оно запрещено. У меня защита — отдельный агент-критик: проверяет допущения, а не код. Miri у тебя играет ту же роль, только снаружи.
А на unsafe Rust ловил случаи когда модель упирается в своё решение недельной давности, хотя новые данные говорят против?
Интересно с producer-side: автономно гоняю агентов на разработке компилятора, коммиты проходят review без меток «AI-сгенерировано». Разница не в «использовал агента vs не использовал», а в наличии плана + acceptance criteria + аудит-цикла перед коммитом. Если есть — markers из твоего списка не появляются (агент не оставляет cargo-cult, лишних импортов, «TODO: handle errors»).
Возможно правильный фильтр — не «AI vs human», а «low-effort vs high-effort». AGENTS.md ловит первое, но не второе — а второе и становится новой нормой.
Похожий опыт на разработке компилятора (с эффектами + GC, не Rust). Catalog’ил 4 категории сбоев: hallucinated facts (агент утверждает что фича работает — тесты PASS в одном пайплайне, FAIL в другом), defending past positions (защищает свой же дизайн недельной давности под новыми данными), off-distribution (стандартный паттерн на нестандартный nuance), echo chamber (множество reviewer-агентов с одинаковым системным промптом валидируют друг друга).
Твои aliasing violations попадают в #3 — стандартный borrowing паттерн в unsafe-контексте, где он invalid. У меня митигация — отдельный audit-агент с adversarial framing’ом, проверяет assumption holes, не код. Miri в твоём случае внешний механизм с той же ролью.
Какие из patterns 1, 2, 4 ты у себя видел на unsafe Rust?