ElKornacio

решил пошерить пачку небольших лайфхаков в работе с агентами, в основном про скрипты. думаю, опытным чувакам 90% из этого покажется прописными истинами, но, возможно, кто-то почерпнёт что-то полезное для себя. сохраняйте, шерьте, кайфуйте 🙂 1. не юзайте TUI в VSCode/Cursor для Claude Code / Codex / etc. мерцания интерфейса и проблемы со вставкой текста (в том числе из голосового ввода) - это не баги самих приложений, а баги tty-среды в VSCode. юзайте нативный терминал. 2. если вы хотите, чтобы агент выполнял одну и ту же цепочку действий - вместо описания цепочки в глобальных правилах лучше просто упакуйте её в bash-скрипт. чем писать "ты всегда должен сделать тайп-чек, билд, прогнать тесты, и потом деплойнуть скрипт", просто попросите агента создать ./check-build-test-deploy.sh, и пропишите этот скрипт в правилах. да, современные агенты неплохо следуют инструкциям, но рандома оч много. иногда агент воспринимает "прогони тесты" как pnpm run test, а иногда он по хардкору начинает писать конструкции типа npx ./node_modules/.bin/jest ... --runInBand ..., и спотыкается. скрипты - гарантия повторяемости (это супер-очевидная штука для вещей, которые приходится делать руками самому, но при этом я часто вижу, что люди не заботятся о том, чтобы обеспечить удобство работы агентам). 3. если вы хотите, чтобы агент после какой-то операции анализировал её результат - прокиньте логи/данные сразу в stdout этой операции. это рифмуется и дополняет предыдущий пункт, если вы юзаете конструкции типа "выполни этот скрипт, после чего прочитай логи в ./abc.log", то поставьте tail -n 50 ... прям в конец скрипта. когда я дебажил ESP-плату, у меня билд-деплой кода были на одном скрипте, а чтение serial monitor - на другом. объединение этого в один скрипт аля "залей новый код, сними логи в течение 15 секунд и верни в stdout" улучшило мою жизнь кратно. 4. правило "агент должен иметь возможность самостоятельно проверить результаты своей работы" известно, наверное, уже всем, но как же часто я вижу нарушения этого принципа с отмазками "ну, у нас такая среда, что не автоматизируешь". классические примеры: - tauri/electron-приложение: "мы не можем запустить фронт в playwright/встроенном-браузере, надо руками" - react-native / flutter: "ну, оно в эмуляторе / на телефоне гоняется, надо руками" - любительский embedded, etc давайте честно: вам просто влом. за 20 минут работы агента (https://t.me/elkornacio/505) собирается элементарный runtime-eval-debug сервер, который для веб-приложений позволяет агенту кидать команды напрямую в любую среду (и можно ещё и ключевые части приложения прям в window прокинуть, для удобства). логи из фронта в tauri / electron / react-native / flutter тоже прокидываются минут за 5 (можно связкой "фронт шлёт логи на бек, бек пишет в файл"), без особых проблем. embedded прекрасно умеет слать данные датчиков и дебаг-инфу в serial, а оттуда агент умеет читать. в общем, не убеждайте себя, чтобы ваша среда уникальная: если действие происходит на вашем компе, и не связано с физическим миром, то автоматизировать можно всё. 5. "ой, я же сказал агенту, что после билда надо перезагрузить страницу, а он забыл, и тестировал старую версию, вот дурашка" - дурашка не он. если надо рестартить что-то после билда - (снова пункт 2) - добавьте это прям в скрипт билда. убирайте все места, где агент может выстрелить себе в ногу: если что-то не может работать без какого-нибудь сервера - вновь же, добавьте проверку на "запущенность сервера" прямо в скрипт. это 1 строчка, и сэкономленные часы. 6. пишите советы агенту прямо в stdout ваших скриптов. скрипт обнаружил, что отсутствует важный файл, необходимый для работы? выведите в stdout не только ошибку, но и информацию о том, что нужно сделать, чтобы этот файл появился. исключайте ситуации, когда агент не понимает, что делать дальше, и должен рисерчить кодовую базу в поисках ответа. — кидайте ваши лайфаки в комментах, буду рад что-то для себя почерпнуть 🙂