Попросил ИИ исправить эндпоинт. Он увлёкся
Недавно разбирал такой ответ: отдельный сборщик SQL, новая модель ответа, внедрение зависимостей. Заодно агент поменял поведение API, хотя задача этого не требовала. Потом пришлось сокращать и возвращать исходный контракт.
На такие переделки тоже уходит лимит. Поэтому я бы сначала дал агенту границы: что исправить, что сохранить и как проверить. Например: «Закрой SQL-инъекции в search_products. Сохрани параметры и формат ответа. Пул уже настроен. Проверь пустой поиск и сортировку».
А инструменты выбирал бы под конкретную проблему:
Graphify - граф связей кода. Удобно искать вызывающие функции и связанные модули в большом проекте. Построение и обновление графа тоже требуют ресурсов, а найденное нужно сверять с исходником.
Ponytail - skill против лишней архитектуры. Использовать то, что уже есть, менять необходимое, не выкидывать важные проверки. Он влияет на поведение агента, а не сжимает контекст.
RTK - сокращение вывода команд. Полезно против повторов и простыней логов. При разборе сложной ошибки всё равно может понадобиться полный вывод.
Context7 - документация библиотек под нужную версию и задачу. Лучше спросить про конкретный метод, чем принести агенту всё руководство целиком.
Ещё не стал бы запускать несколько агентов на одну маленькую правку. Каждый читает контекст, а их результаты потом нужно свести. Для независимых задач параллельная работа полезна, но её общий расход нужно считать.
Смотрел бы на всю задачу: токены, время, переделки и проверки. Экономия на первом ответе мало помогает, если результат потом приходится чинить.
Что у вас сильнее жрёт лимит? И какие инструменты реально оставили в рабочем процессе, а какие попробовали и удалили?
· 20.10
Репозитории, о которых написал:
Graphify: https://github.com/Graphify-Labs/graphify Ponytail: https://github.com/DietrichGebert/ponytail RTK: https://github.com/rtk-ai/rtk Context7: https://github.com/upstash/context7
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён