Я сейчас смог исправить ошибку кривого бэка, валидации и фронта + их несогласованности
Обьяснив модели grok-code-fast-1 — что он в монорепо, что есть shared schema с трансформацией snakeCase -> camelCase и обратно, что логи бэка можно смотреть по docker compose logs directus | head, что можно временно покрыть логами эндпоинт
И самое важное - что не надо прогонять через playwright mcp в браузере каждый раз проверку формы, а можно извлечь запрос, просто через curl его кидать в бэк, а на бэке через directus-mcp можно проверить соответствие данных, и эффект
Он просто взял и за минут 20 вместе со мной, с планированием - просто решил проблему, которую я бы решал приличным когнитивным усилием, и как минимум те-же полчаса.
Вместо этого время было проведено за параллельным просмотром ютубчика 😀
Ну вот прям на сто-оо-олько оно облегчает работу, если разобраться?? 🫢
Я главный противник чистого вайбкодинга, но основной тейк в небезопасных, кривых решениях.
Но как выше уже упомянул, в целом это реально решается прописыванием правил, ревью, направлением модели в нужном направлении и настройкой линтера, проработанным проектированием архитектуры.
---
Честно, хз сколько это стоило бы на claude, gemini, gpt — думаю за день потратил бы спокойно 30-50$
Но мне реально очень нравится как grok-code-fast-1 справляется, эт прям чудо, если ему давать четкие задачи с достаточным контекстом, самому думать. И иногда можно ревьюить или планировать через claude 4.5 thinking, что обходится тоже очень дешево, тк чтение дешевое, за write tokens - только на thinking и сам фактический план. В целом и Opus тут может быть уместен.
Как выведут planning из beta - опробую на Opus попланировать 🤔