(Эти логи сыпет уже после того, как я в браузере подтвердил вход) ... [main 2025-11-19T12:23:40.459Z] Using Cloud Code URL: https://daily-cloudcode-pa.sandbox.googleapis.com [main 2025-11-19T12:23:40.462Z] [BrowserOnboardingClientMainService] Starting browser onboarding server [main 2025-11-19T12:23:40.463Z] Error initializing AntigravityAuthMainService: Error: No OAuth token available. User must be logged in. ... [Auth] Localhost server listening on port 49190 [main 2025-11-19T12:24:10.553Z] update#setState checking for updates [main 2025-11-19T12:24:11.972Z] update#setState idle Error confirming user for service: Error: HTTP error: 403 [Auth] Localhost server stopped
При этом визуально бесконечно крутит "Setting Up Your Account".
Можно и за пару часов все лимиты исчерпать. Вот антигайд: - Работать по любой задаче с самой дорогой моделью (Sonnet 4.5); - Штамповать задачи в одном чате, заставляя часто суммаризовать контекст и вываливаться за лимиты общего контекста модели, что приводит к двойным квотам потребления; - Позволять моделям читать жирные логи без фильтрации и лимитов/грузить в одну задачу весь проект для анализа(Если он конечно не на пару скриптов)/использовать тяжелые инструменты(Например, работа с бд, где модель может "случайно" прочитать все данные большой таблицы); - Ну и собственно давать абстрактные задачи, чтобы модель перед тем как написать заветных пару правок - бороздила проект полчаса в попытках понять не создаст ли это сайд-эффектов или еще чего;
Все-таки я считаю, что такими IDE нужно пользоваться, когда сам понимаешь, что делаешь и умеешь управлять процессом, в других случаях в долгосрочной перспективе множество проблем будет.
Фреймворк решает архитектурные проблемы в первую очередь, а при разрастании проекта они будут снежным комом накапливаться. Суммарная польза от фреймворка нивелирует все его накладные расходы, особенно решая проблемы, с которыми вы еще не столкнулись. Учитывая контекст вайб-кодинга - можно взять готовый mcp сервер laravel-boost от разработчиков, он прокидывает документацию, практики и ряд команд для агента, разработка идёт быстро и без ошибок, даже на grok-code-fast.
Подскажите, а почему в качестве бекенда был выбран PHP?
И почему не были использованы фреймворки вроде Symphony или Laravel? Тот же Laravel в базовой комплектации закрывает половину проблем - тот же rate limiting, транзакции с локом таблиц, идемпотентность запросов можно через ключ в заголовке и кэш ключа на сервере на n секунд, ну и так далее. Особенно не нужно думать велосипеды с безопасностью.
Касательно скрытия роутов - затея бессмысленная, имхо. Какая разница, 12 роутов или 1, когда ваш пейлоад итак видно. В качестве альтернативы можно прикрутить вебсокеты и общаться по ним.
Ну а в целом спасибо, что поделились своим начинанием и показали, что с хорошей задумкой можно быстро стартануть - главное желание.
Хотелось бы знать, как именно строился данный агент и вообще агент ли это(вдруг просто один волшебный системный промпт в заголовке, а с остальным модель в едином флоу разбирается сама).
Насколько я знаю, если спроектировать граф с ролями, классификаторами, судьями, суммаризатором, инструментами, внешней памятью - можно добиться вменяемого предсказуемого результата, где на каждом шаге состояние графа не будет перегружать контекст модели и минимизировать галлюцинации. По трейсу можно определять на каком шаге проблемы и корректировать работу конкретной ноды, а не править общий промпт.
Ну подавать все чисто промптом глупо для теста. Я думаю тут должен крутиться граф, множество mcp-тулзов, внешняя память и модели должны сами собирать и анализировать информацию, а потом уже решать открывать ли сделки(или сидеть на заборе). На langgraph подобные воркфлоу создать несложно(вероятно, даже в графических конструкторах агентов можно, сам не пользовался).
❯ /Applications/Antigravity.app/Contents/MacOS/Electron install.sh
(Эти логи сыпет уже после того, как я в браузере подтвердил вход)
...
[main 2025-11-19T12:23:40.459Z] Using Cloud Code URL: https://daily-cloudcode-pa.sandbox.googleapis.com
[main 2025-11-19T12:23:40.462Z] [BrowserOnboardingClientMainService] Starting browser onboarding server
[main 2025-11-19T12:23:40.463Z] Error initializing AntigravityAuthMainService: Error: No OAuth token available. User must be logged in.
...
[Auth] Localhost server listening on port 49190
[main 2025-11-19T12:24:10.553Z] update#setState checking for updates
[main 2025-11-19T12:24:11.972Z] update#setState idle
Error confirming user for service: Error: HTTP error: 403
[Auth] Localhost server stopped
При этом визуально бесконечно крутит "Setting Up Your Account".
Можно и за пару часов все лимиты исчерпать. Вот антигайд:
- Работать по любой задаче с самой дорогой моделью (Sonnet 4.5);
- Штамповать задачи в одном чате, заставляя часто суммаризовать контекст и вываливаться за лимиты общего контекста модели, что приводит к двойным квотам потребления;
- Позволять моделям читать жирные логи без фильтрации и лимитов/грузить в одну задачу весь проект для анализа(Если он конечно не на пару скриптов)/использовать тяжелые инструменты(Например, работа с бд, где модель может "случайно" прочитать все данные большой таблицы);
- Ну и собственно давать абстрактные задачи, чтобы модель перед тем как написать заветных пару правок - бороздила проект полчаса в попытках понять не создаст ли это сайд-эффектов или еще чего;
Все-таки я считаю, что такими IDE нужно пользоваться, когда сам понимаешь, что делаешь и умеешь управлять процессом, в других случаях в долгосрочной перспективе множество проблем будет.
Фреймворк решает архитектурные проблемы в первую очередь, а при разрастании проекта они будут снежным комом накапливаться. Суммарная польза от фреймворка нивелирует все его накладные расходы, особенно решая проблемы, с которыми вы еще не столкнулись. Учитывая контекст вайб-кодинга - можно взять готовый mcp сервер laravel-boost от разработчиков, он прокидывает документацию, практики и ряд команд для агента, разработка идёт быстро и без ошибок, даже на grok-code-fast.
Подскажите, а почему в качестве бекенда был выбран PHP?
И почему не были использованы фреймворки вроде Symphony или Laravel? Тот же Laravel в базовой комплектации закрывает половину проблем - тот же rate limiting, транзакции с локом таблиц, идемпотентность запросов можно через ключ в заголовке и кэш ключа на сервере на n секунд, ну и так далее. Особенно не нужно думать велосипеды с безопасностью.
Касательно скрытия роутов - затея бессмысленная, имхо. Какая разница, 12 роутов или 1, когда ваш пейлоад итак видно. В качестве альтернативы можно прикрутить вебсокеты и общаться по ним.
Ну а в целом спасибо, что поделились своим начинанием и показали, что с хорошей задумкой можно быстро стартануть - главное желание.
Жаль, что технических подробностей нет.
Хотелось бы знать, как именно строился данный агент и вообще агент ли это(вдруг просто один волшебный системный промпт в заголовке, а с остальным модель в едином флоу разбирается сама).
Насколько я знаю, если спроектировать граф с ролями, классификаторами, судьями, суммаризатором, инструментами, внешней памятью - можно добиться вменяемого предсказуемого результата, где на каждом шаге состояние графа не будет перегружать контекст модели и минимизировать галлюцинации. По трейсу можно определять на каком шаге проблемы и корректировать работу конкретной ноды, а не править общий промпт.
Ну подавать все чисто промптом глупо для теста. Я думаю тут должен крутиться граф, множество mcp-тулзов, внешняя память и модели должны сами собирать и анализировать информацию, а потом уже решать открывать ли сделки(или сидеть на заборе). На langgraph подобные воркфлоу создать несложно(вероятно, даже в графических конструкторах агентов можно, сам не пользовался).
И также кодекс есть в курсоре в списке моделей, его можно тянуть по апи куда угодно. Но в статье именно про веб версию.
Автор писал про codex - это веб инструмент, который вносит правки напрямую в гитхаб репозиторий и входит в состав основной подписки на чатгпт.