Skip to content

problem-solutions.md

Latest commit

 

History

History
180 lines (118 loc) · 8.79 KB

problem-solutions.md

File metadata and controls

180 lines (118 loc) · 8.79 KB
Raw

Когда агент «халтурит»: почему это происходит и как снижать риск

1) Типовые проявления:

  • задача формально закрыта, но часть требований пропущена;
  • сделано «похожее», но не то, что просили;
  • добавлены лишние изменения вне области задачи;
  • не выполнены проверки (тесты/линтер/диагностика), но вывод «готово»;
  • агент уверенно объясняет решение, которое не проходит верификацию.

Важно: в большинстве случаев это не «злой умысел», а следствие качества контекста, постановки и контроля.

2) Почему агент может работать некачественно

2.1 Нечёткая постановка задачи

Если запрос общий («сделай лучше», «поправь это»), агент сам додумывает рамки.

Результат: высокая вариативность и промахи по ожиданиям.

2.2 Недостаток или шум контекста

  • нет ключевых файлов;
  • много нерелевантной информации;
  • противоречивые инструкции.

Результат: фокус рассеивается.

2.3 Нет явного критерия готовности

Агент не знает, что именно считается завершением задачи.

Результат: преждевременное «готово».

2.4 Отсутствие внешней проверки

Если не запускать тесты/диагностику/ревью, ошибки остаются скрытыми.

Результат: ложноположительное качество.

2.5 Слишком большой объём в одну итерацию

Один огромный запрос повышает шанс пропусков и лишних действий.

Результат: нестабильный и трудно проверяемый выход.

2.6 Конфликт или перегруз указаний

Если в запросе слишком много директив или они частично противоречат друг другу, агент начинает следовать формальным рамкам, а не оптимальному пути решения.

Типичный эффект:

  • пользователь ожидает «умного выбора пути»;
  • агент делает «как сказано», даже если технически это хуже;
  • итог выглядит как странное поведение или «халтура».

Как избежать:

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

3) Как отличить «агент не понял» от «агент не смог»

Признаки «не понял»

  • ушёл в сторону от цели;
  • меняет не те файлы;
  • игнорирует явные ограничения.

Признаки «не смог»

  • упёрся в технические ограничения (права, инструменты, инфраструктура);
  • корректно диагностирует блокер;
  • просит уточнение или предлагает обходной путь.

Почему это важно: стратегия исправления разная.

  • «Не понял» лечится уточнением постановки.
  • «Не смог» лечится устранением блокера/сменой стратегии.

4) Практики, которые резко снижают «халтуру»

4.1 Формулируйте задачу как контракт

Минимум в запросе:

  • цель;
  • область изменений;
  • запреты;
  • критерии приемки;
  • формат отчёта.

Пример:

Исправь падение теста X. Менять только src/payments/*. Не трогать публичный API. После правки npm test -- payments должен быть зелёным. В отчёте: причина, файлы, проверка.

4.2 Работайте короткими итерациями

Вместо «сделай всё сразу»:

  1. анализ;
  2. план;
  3. маленький блок правок;
  4. проверка;
  5. следующий блок.

Это даёт управляемость и быстрый контроль отклонений.

4.3 Требуйте доказательства, а не декларации

Просите не «всё ок», а:

  • какие проверки запущены;
  • какой результат получен;
  • где это видно (логи/выводы/файлы).

4.4 Фиксируйте «что нельзя делать»

Явные запреты (negative constraints):

  • не менять структуру документа;
  • не трогать соседние модули;
  • не добавлять новые файлы;
  • не выполнять push без подтверждения.

4.5 Разделяйте роли

Полезная практика:

  • один агент делает изменения;
  • другой проверяет.

Даже лёгкое кросс-ревью заметно снижает дефекты.

4.6 Не пропускайте loopback

После каждого значимого шага:

  • тест/диагностика/лог-анализ;
  • корректировка;
  • повторная проверка.

5) Антипаттерны, которые провоцируют некачественный результат

  1. «Сделай идеально» без ограничений.
  2. «Сделай быстро, детали потом» без критериев.
  3. Смешение нескольких независимых задач в одном запросе.
  4. Игнорирование project policy.
  5. Отсутствие финальной верификации.

6) Как реагировать, если агент уже «схалтурил»

Практический порядок:

  1. Остановить дальнейшие изменения.
  2. Зафиксировать расхождение: что ожидалось vs что получено.
  3. Сузить задачу до одного проблемного блока.
  4. Переформулировать контракт (цель/границы/критерий).
  5. Прогнать короткую итерацию с обязательной проверкой.

Шаблон сообщения:

Расхождение: ожидалось A, получено B. Исправляем только блок C в файле D. Не трогаем E/F. Критерий: тест G зелёный и без изменений API. В ответе — только diff+результат проверки.

7) Связанные материалы

Коротко: агент начинает «халтурить» там, где нет чёткого контракта, проверки и управляемого цикла. Чем лучше инженерная дисциплина постановки и верификации, тем меньше сюрпризов. Или он не может справится с задачей и видит неожиданный для вас путь. Тесты не выполняются? Так надо пойти и поправить тесты. Это для вас очевидно, что это не логично, а для агента - цель выполнить задачу. Задача какая? Что бы тесты были зелеными... Улавливаете ? :)