Попросил ИИ исправить эндпоинт. Он увлёкся

Недавно разбирал такой ответ: отдельный сборщик SQL, новая модель ответа, внедрение зависимостей. Заодно агент поменял поведение API, хотя задача этого не требовала. Потом пришлось сокращать и возвращать исходный контракт.

На такие переделки тоже уходит лимит. Поэтому я бы сначала дал агенту границы: что исправить, что сохранить и как проверить. Например: «Закрой SQL-инъекции в search_products. Сохрани параметры и формат ответа. Пул уже настроен. Проверь пустой поиск и сортировку».

А инструменты выбирал бы под конкретную проблему:

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

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

RTK - сокращение вывода команд. Полезно против повторов и простыней логов. При разборе сложной ошибки всё равно может понадобиться полный вывод.

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

Ещё не стал бы запускать несколько агентов на одну маленькую правку. Каждый читает контекст, а их результаты потом нужно свести. Для независимых задач параллельная работа полезна, но её общий расход нужно считать.

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

Что у вас сильнее жрёт лимит? И какие инструменты реально оставили в рабочем процессе, а какие попробовали и удалили?

Попросил ИИ исправить эндпоинт. Он увлёкся | Сетка — социальная сеть от hh.ru Попросил ИИ исправить эндпоинт. Он увлёкся | Сетка — социальная сеть от hh.ru