На моей практике как раз ларавель один лучших. Ставишь mcp - laravel-boost. Агент должен вместо встроенных инструментов использовать ларавелевские по анализу кода/базы данных. Также на каком нибудь ресурсе skills sh либо сам, либо заставь агента поискать навыки по правильной организации rest api. Подключи библиотеку scramble (или подобную) для автоматической генерации спеки openapi (нужно заставить агента на контроллерах писать доку под это). На js потом кидаешь openapi.json и учишь агента работать с ним, фронт знает все ендпоинты, типизацию, коды ответов без боли.
Конкретно мой стек на последнем проекте: под ларавель использую laravel-ddd(тут может быть много холивара на эту тему, я использую базово для разграничения доменов и лучшей работы с типами через dto), laravel-data под dto, laravel-builder-query для быстрого построения фильтров. В проекте 15 доменов, около 60 таблиц в БД(которые по наследству перетекли в проект + формируются новые). Благодаря mcp laravel-boost агент спокойно изучил БД, разложил ее на домены. Далее были сформированы конкретные требования по организации каждого домена(структура, ограничения, проверки, стиль написания), как раз на этом этапе пишется базовое поведение агенту. Эти требования покрывают практически весь проект и включают в себя инструкции как делать правильно(вместо написания «как не надо делать»,но есть исключения). По каждому домену ведётся отдельная память агента, пишутся тесты, оформляются ADR с описаниями как и почему в какой-то момент было принято сложное решение. Все это страхуется коммитами под каждую выполненную задачу. В общем действия агента логируются довольно подробно, чтобы выявлять слабые места и позволять агенту дорабатывать свои навыки. На данном этапе агенту достаточно дать команду и он сам мне даст бриф по проекту и предложит 3-4 задачи для реализации. Закрытие функциональности доменными областями бустит агента прилично, плюс позволяет работать параллельно, если домены не пересекаются.
После генерации документации и пуша на мой гитлаб, там запускается конвейер и отправляет на другой проект спеку openapi, которая собирается в полноценную либу для реакта с использованием react-query. На фронте(next.js) я загружаю обновленную либу и агент работает с уже готовыми методами для доступа к бекенду. Со временем разработки ошибки внедрения новых фич в проект стремятся к нулю.
Ошибочно понимать, что агенты из коробки решат за вас все ваши проблемы. Агенту действительно нужно создавать среду и окружение, в которых ему будет комфортно работать, учитывая текущие архитектурные ограничения самих агентов. И для каждого проекта это все специфично, поэтому некая инженерия тут присутствует.
Я опусом последним пользуюсь, при правильно настроенном проекте прям таких проблем не испытываю. Ну я и работаю на более менее популярных стеках, где модели хорошо обучены изначально.
Поэтому нужны mcp, навыки и ограничения агенту, а если по стеку документация нормальная есть, то и результаты будут другими. Агенты не умеют удерживать весь контекст проекта, поэтому им нужны «артефакты» - краткие сводки изменений и примеров правильного кода.
Сборки на райзене выходили кратно дороже и избыточны. В любом случае, стоял бы тот же дебиан и справлялся с тем же стеком задач, с которым текущий справляется без нагрева.
Это мини-пк, а не полноценный пк. Сетевых карточек туда не добавить, сам он такой же размером с обычный роутер. Вариантов нативно с sfp не придумать, зато можно выйти за пределы обычных сетевых сервисов, производительность получше будет. У меня, например, прикручен винт 2ТБ и установлен jellyfin сервер, весь медиаконтент через него работает. Плюс ко всему различные докеры с тестами разработки, да и в целом x86 для меня привычнее.
При этом тот же MoE, предложенный китайцами, используется во всех флагманских моделях по всему миру. То же самое ждет и этот подход к обучению, если китайцы его успешно протестируют и внедрят.
(Эти логи сыпет уже после того, как я в браузере подтвердил вход) ... [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 подобные воркфлоу создать несложно(вероятно, даже в графических конструкторах агентов можно, сам не пользовался).
У вас была ситуация, когда вы уронили отварную сосиску?
…
На моей практике как раз ларавель один лучших. Ставишь mcp - laravel-boost. Агент должен вместо встроенных инструментов использовать ларавелевские по анализу кода/базы данных. Также на каком нибудь ресурсе skills sh либо сам, либо заставь агента поискать навыки по правильной организации rest api. Подключи библиотеку scramble (или подобную) для автоматической генерации спеки openapi (нужно заставить агента на контроллерах писать доку под это). На js потом кидаешь openapi.json и учишь агента работать с ним, фронт знает все ендпоинты, типизацию, коды ответов без боли.
Конкретно мой стек на последнем проекте: под ларавель использую laravel-ddd(тут может быть много холивара на эту тему, я использую базово для разграничения доменов и лучшей работы с типами через dto), laravel-data под dto, laravel-builder-query для быстрого построения фильтров. В проекте 15 доменов, около 60 таблиц в БД(которые по наследству перетекли в проект + формируются новые). Благодаря mcp laravel-boost агент спокойно изучил БД, разложил ее на домены. Далее были сформированы конкретные требования по организации каждого домена(структура, ограничения, проверки, стиль написания), как раз на этом этапе пишется базовое поведение агенту. Эти требования покрывают практически весь проект и включают в себя инструкции как делать правильно(вместо написания «как не надо делать»,но есть исключения). По каждому домену ведётся отдельная память агента, пишутся тесты, оформляются ADR с описаниями как и почему в какой-то момент было принято сложное решение. Все это страхуется коммитами под каждую выполненную задачу. В общем действия агента логируются довольно подробно, чтобы выявлять слабые места и позволять агенту дорабатывать свои навыки. На данном этапе агенту достаточно дать команду и он сам мне даст бриф по проекту и предложит 3-4 задачи для реализации. Закрытие функциональности доменными областями бустит агента прилично, плюс позволяет работать параллельно, если домены не пересекаются.
После генерации документации и пуша на мой гитлаб, там запускается конвейер и отправляет на другой проект спеку openapi, которая собирается в полноценную либу для реакта с использованием react-query. На фронте(next.js) я загружаю обновленную либу и агент работает с уже готовыми методами для доступа к бекенду. Со временем разработки ошибки внедрения новых фич в проект стремятся к нулю.
Ошибочно понимать, что агенты из коробки решат за вас все ваши проблемы. Агенту действительно нужно создавать среду и окружение, в которых ему будет комфортно работать, учитывая текущие архитектурные ограничения самих агентов. И для каждого проекта это все специфично, поэтому некая инженерия тут присутствует.
Я опусом последним пользуюсь, при правильно настроенном проекте прям таких проблем не испытываю. Ну я и работаю на более менее популярных стеках, где модели хорошо обучены изначально.
Поэтому нужны mcp, навыки и ограничения агенту, а если по стеку документация нормальная есть, то и результаты будут другими. Агенты не умеют удерживать весь контекст проекта, поэтому им нужны «артефакты» - краткие сводки изменений и примеров правильного кода.
Вайб-кодинг в эпоху агентов, которые на ходу уже умеют писать себе навыки для любой задачи? Звучит олдскульно
Тоже не понимаю хейт. Комментарии ещё затемняются заминусованные и выглядит это как представление единственного верного мнения)
Не понял смысла этой поделки. Есть официальный пакет pulse от laravel, а это что?
Сборки на райзене выходили кратно дороже и избыточны. В любом случае, стоял бы тот же дебиан и справлялся с тем же стеком задач, с которым текущий справляется без нагрева.
Это мини-пк, а не полноценный пк. Сетевых карточек туда не добавить, сам он такой же размером с обычный роутер. Вариантов нативно с sfp не придумать, зато можно выйти за пределы обычных сетевых сервисов, производительность получше будет. У меня, например, прикручен винт 2ТБ и установлен jellyfin сервер, весь медиаконтент через него работает. Плюс ко всему различные докеры с тестами разработки, да и в целом x86 для меня привычнее.
Мой миник куплен за 10к примерно. 4lan порта по 2.5g, на базе n150 и 16gb ram. Единственное, вай-фай модуля встроенного нет, докупать пришлось.
У меня сборка на обычном дебиане и мини-пк, решает проблему доступа к сервисам. Со статьи не понял зачем и для чего все эти пляски.
При этом тот же MoE, предложенный китайцами, используется во всех флагманских моделях по всему миру. То же самое ждет и этот подход к обучению, если китайцы его успешно протестируют и внедрят.
❯ /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 подобные воркфлоу создать несложно(вероятно, даже в графических конструкторах агентов можно, сам не пользовался).
И также кодекс есть в курсоре в списке моделей, его можно тянуть по апи куда угодно. Но в статье именно про веб версию.