Comments 11
Да заметил тоже такое , я даже пишу специально , проведи анализ и дай на выбор лучшие решения. А в промпт вставляю ревью от другого агента .. видимо его промпт воспринимается как конфликт правила уж я не знаю , но он игнорирует первые предложения в том плане , что сначала давай подумаем и выберем , а не приступать к первому попавшемуся решению , которое еще и может сломать что либо параллельно.
Поэтому свод актуальных правил должен отдаваться автоматом, AI-индустрия к этому идет, но пока что большинство застряли в skills.md. Я для себя пишу на эту тему инструмент, и он реально помогает.
Наступал на это ровно три месяца назад. Попросил агента проверить почему падает один тест, через пять минут он переписал три файла, добавил хелпер и вынес конфиг. Тест прошёл, но в проде это выявило регрессию, потому что никто не ожидал изменений в этих файлах и ревью проходило по-другому. Решение, которое сработало: в CLAUDE.md жёсткий протокол для диагностических задач, агент останавливается после постановки диагноза, показывает список файлов которые собирается трогать, ждёт явного подтверждения. Замедляет цикл на 30 секунд, но снимает именно эту проблему. Способность сделать и право сделать разные вещи, и без явного барьера в инструкциях агент их не разграничивает.
Лично я пошёл по самому простому пути - делегирование. За написание кода у меня полностью отвечает агент. Код получается ужасный. Но... он работает.
На мой взгляд, дело не в полномочиях агента, не в разрешениях. Дело в минимизации ущерба, когда он возникнет. В общем, я думаю, примерно с такими же проблемами сейчас сталкиваются руководители софтварных "галер" на несколько десятков команд, работающих одновременно над несколькими проектами, иногда даже конкурирующих друг с другом заказчиков. И у них уже есть решения. Просто разработчики вращаются в другой среде и этих решений не знают.
вы серьезно ? режим обращения ask , plan не слышали?
Серьезно.
интерено, дочитали ли вы до фразы
Если продолжить аналогию, plan mode — это выключатель света, конечный автомат — логика умного дома, а чекпоинты — журнал его событий.
не дочитал, но какой смысл дочитывать, если проблема решается через ask plan, к чему статья
Эту статью поймут те, кто кнопку plan mode давно перерос. Разве у вас не бывало так, что включил план мод, вроде все описал, переключился в act, и получил поломанный проект. причем проект ломаться постепенно, иногда заметить это можно случайно, когда уже на гит надежды нет. Время потрачено, токены потрачены, настроение испорчено.
Сейчас будет немного длинно, но вот пример диалога с агентом в режиме act:
значит дефекты надо устранить, если они есть, создавай задачу
четверг 09:17
Работал на протяжении 1m 55s
Задача создана через SloplessCode MCP:
1054b22f-f11b-457d-93b7-195afd9644e8
Название: Semantic artifact retrieval and orphan-reference diagnostics
Статус: open, не взята в работу.
Зафиксированы два дефекта:
семантические запросы ошибочно сводятся к нефильтрованному лексическому поиску;
устаревшие ссылки вторичного индекса не диагностируются как orphaned refs.
SQLite остаётся единственным source of truth, Qdrant только выдаёт кандидатов. Write-тесты разрешены исключительно в Docker.
четверг 09:19
продолжай
четверг 09:25
Работал на протяжении 20s
Постановка задачи 1054b22f
Проблема: семантические запросы ошибочно маршрутизируются в лексический list_artifacts/list_open_tasks. Дефект снова воспроизведён при получении контекста этой задачи.
Цель:
отдельный маршрут семантического поиска;
Qdrant только формирует кандидатов;
каждый кандидат проверяется и загружается из SQLite;
orphaned refs доступны лишь как диагностические, не как существующие задачи.
В объёме: маршрутизация, ранжирование, подавление служебных слов, aliases, все статусы и типы артефактов, диагностические receipts.
Вне объёма: восстановление или удаление данных, миграция рабочей базы, признание индекса источником истины.
Критерии готовности:
запрос про reconstruction bundle находит релевантные материалы;
нет скрытого отката к lexical search;
8f39fa86-... показывается только как orphan diagnostic;
точный lookup остаётся fail-closed;
все write-тесты выполняются только в Docker.
Риск: утечка или ложное признание артефакта существующим. Защита: обязательная SQLite-валидация.
Первое действие: после claim исследовать текущие маршруты поиска и диагностический контур без записи в рабочую БД.
Подтверждаете старт реализации этой постановки?
четверг 09:26
да
четверг 09:27
Работал на протяжении 22m 42s
Задача 1054b22f-f11b-457d-93b7-195afd9644e8 выполнена и закрыта, claim освобождён.
Реализовано:
отдельный semantic_artifact_lookup;
Qdrant используется только для кандидатов;
SQLite-валидация tasks, improvements, memories и project-tree;
stale candidates отбрасываются;
orphan refs показываются как неавторитетная диагностика и не удаляются автоматически;
обычный exact lookup остаётся fail-closed.
Проверка: 503 passed в Docker. Рабочая БД не использовалась. Live restart не выполнялся, поскольку отдельного разрешения на live validation не было.
09:17 значит дефекты надо устранить, если они есть, создавай задачу
09:19 продолжай
09:26 да
Именно это я считаю программированием на вайбе
Разрешения на любые тулзы должны быть детерминированы, а не зависеть от решения llm, это да.
Но изобретать столь сложный процесс кажется переусложнением.
Если в процессе исполнения плана внезапно нужно менять сам план - как будто что-то пошло не так на этапе планирования или потерян контроль над проектом.
А если агент своевольно при исполнении отклоняется от плана - как будто нужно смотреть промпты или скилы, либо же модель не заточена под агентский цикл.
Тут все немного сложнее:
1. Большинство популярных CLI помимо основного тела запроса пользователя агенту добавляют много сопутствующей информации, считаемой авторами CLI нужной и полезной.
2. Многие пользователи бездумно добавляют MCP, skills и прочий балласт, в надежде, что это улучшит ответ модели.
3. LLM на самом деле воспринимает ограничения как рекомендации, т.е. "нельзя, но если хочется то можно".
4. Пользователь часто не хочет или не может досконально описать все условия постановки задачи. Эту проблему очень хорошо демонстрирует фильм "Ослепленный желаниями".
Наложение вышеперечисленных факторов, часто взаимоисключающих. позволяет LLM трактовать коллизии в свою пользу.
Самая опасная ошибка AI‑агента — не плохой код