Comments 10
Годные советы про кастомную команду plan и итеративное улучшение описание режимов, заберу в копилку и попробую тоже, спасибо!
По общему духу советов снова прихожу к мысли, что для инженера по сути это прокачка базовых компетенций делегирования.
При всей полезности - стиль булшитный, тяжело читать.
Получилась классная коллаборация: он пишет код, а я наблюдаю за его флоу и предлагаю оптимизации по части использования агентов.
Мы дропнули коллабу - я и трактор!
Судя по тексту вам бы не помешало его тоже написать в коллабе и с тремя агентами за спиной тк полезной информации ноль. А вы не могли бы вместо себя сейчас позвать агента? Мне кажется он лучше расскажет чем вы, а вы пока покурите в углу
Не совсем согласен что задачу лучше делить на части. Агент может плохо делать куски задачи. Проще сформулировать всю задачу а потом посмотреть что он проигнорил и повторить.
Переключение моделей тоже спорно. Агент это как коллега в команде. Чтобы с ним сработаться нужно время. Переключение модели ломает магию. Вы больше не чувствуете агента, не можете предсказать что он поймет а что нет, с чем справится а где затупит.
Совершенно согласен, что для агентов чем меньше контекста тем умнее агент. Потому что самый эффективный контекст это тот который агент собрал сам под конкретную задачу.
Так же согласен про правила. Наивно надеяться что вы навалите много правил и агент будет писать как надо. Скорее он проигнорирует правила и станет тупее из за засорения контекста. Лучше вписывать только нужные прямо сейчас правила.
Ещё очень эффективный прием - заставит агента в постановке задачи проанализировать код аналогичной уже реализованной задачи. Так не придется много объяснять и в части задачи и в части требований к коду.
Не совсем согласен что задачу лучше делить на части. Агент может плохо делать куски задачи. Проще сформулировать всю задачу а потом посмотреть что он проигнорил и повторить.
ну просто зачастую не уследишь, где он что упустил. и в этом проблема. и не очень понятно , почему куски задачи делает плохо, но есть ожидание, что при этом как-то справится с большой задачей? Как раз кажется об этом пишите далее, что согласны с необходимостью экономии контекста. И если сразу отдать целую задачу под ключ (достаточно большую), то он сожрет его быстро. Но в любом случае нужно знать меру и понимать, когда стоит декомпозировать, а когда можно отдать целиком.
Переключение моделей тоже спорно.
Я и рассматриваю это, как один из вариантов, когда условно зашел в тупик.
В целом отлично, но... При мелких правках руками в рамках файла в агентском режиме они потом часто затираются. Помогает описание правки в комментариях. Вот прямо написать какая ошибка исправлена или функционал дополнен. Ну и про МСP не хватает. Еслли для браузера встроенного агента добавили, то длля БД, figma и прочих радостей всё равно подключать надо. И бывают нюансы, если хочешь подключиться сразу к нескольким БД.
в агентском режиме они потом часто затираются.
наверно зависит от инструмента, который используешь. В курсоре такой не наблюдал.
Ну и про МСP не хватает.
да, MCP категорически важная штука, тут как-то не акцентировал на этом акцент. А еще более важная она в том плане, что она жрет контекст и нужно очень аккуратно с ними быть
Просим агента создать план на подробную документацию по проекту, ставим speckit, собираем правила через него в автоматическом режиме через агента и на основе этого правила и нашей документации создаём через уже готовый спеккит всю цепочку по созданию нормальных правил, это долго но оно того стоит, а там уже можно подключить кило и опенкод на бесплатных тарифах как доп агенты. П.с. у курсора есть отличный функционал автоматически решать какое правило и какой агент в какой момент будет делать, связки вместе хорошо работают
Мой опыт разработки с агентами: советы