Данил Щуцкий | CutCode AI

Есть популярный инструмент для AI-разработки — CodeGraph. Он обещает уменьшение потребления токенов (35%), меньше tool calls, быстрые ответы и лучшее понимание кодовой базы. Звучит как must-have, поэтому я решил проверить его в деле. Прогнал CodeGraph через AI Tester на двух сценариях: простой задаче и проекте покрупнее. А потом добавил длительное исследование от Ичи, разработчика из нашего комьюнити: 300+ тестов и 150 парных сравнений rg против CodeGraph. И вот тут стало интересно. Смотрите в новом видео разбор CodeGraph: https://youtu.be/4W7V4gj_jC8

AI-разработку часто подают как один сценарий: подключил модель, добавил MCP, дал агенту задачу — и команда ускорилась. Но на практике есть минимум три разных подхода: контекстная фабрика, разработка на стероидах и vibe coding, он же prompt casino. В новом ролике разбираю, почему их опасно путать, почему AI не отменяет разработчиков и почему сотни тулов не делают человека AI-native: https://www.youtube.com/watch?v=N_-GFgesQGk

1000 звёзд у AI Factory. Вот это поворот. Честно говоря, я пару раз обновил GitHub, просто проверить - точно ли это происходит с моим проектом. AI Factory добрался до 1000 звёзд! Это мой самый быстрорастущий Open Source. Для меня это не просто цифра. Это знак, что тема AI-разработки болит не только у меня. Мы все видели этот сценарий: дал агенту задачу, он уверенно поехал, а потом ты полдня разбираешь, куда именно. Поэтому AI Factory родился как попытка сделать не prompt casino, а нормальный инженерный workflow: контекст, спеки, планы, проверки, документация, правила для агентов. И самое крутое - проект уже давно не только про меня. В разработку влилось много сильных ребят, появились идеи, правки, обсуждения, и из этого постепенно вырос действительно полезный тул. Спасибо всем, кто поставил звезду, помог кодом, issue, советом или просто поддержал. Двигаемся дальше!

⚡️ Sonnet 5 вышел! Что ж, Fable нам опять не завезли — пока смотрим Sonnet 5. Ещё не успел нормально потестить его в кодинге, но есть ощущение, что тут может повториться старая история, когда младшая модель внезапно оказывается лучше Opus. И да, мысль такая есть: Sonnet 5 вполне может оказаться сильнее Opus 4.8 — как это уже бывало раньше. Кто уже попробовал — делитесь своим мнением в комментариях. Что вам больше зашло: Sonnet 5 или Opus 4.8?

⚡️ В OpenCode и OpenRouter появилась загадочная Ox Alpha — и она неожиданно сильна в кодинге Контекст — 1 млн токенов, есть мультимодальность, reasoning и работа с инструментами. На небольшой выборке из 10 задач DeepSWE она набрала 80%, обогнав Fable 5, GLM-5.3, Grok 4.6 и GPT-5.6 Sol. Прогон: https://x.com/davis7/status/2090655207831298095 Выборка маленькая, поэтому выводы делать рано. Но интереснее другое: по токенизатору, reasoning API и обработке видео Ox Alpha очень похожа на модели Z.ai / GLM. Так что вполне возможно, перед нами новая ещё не анонсированная новая модель GLM. До 27 августа OpenCode обещает почти безлимитный бесплатный доступ: https://x.com/opencode/status/2090544355824038300 Самое время погонять на реальных репозиториях. Кто уже пробовал?

Ошибка, которую одобрили все Интересную ситуацию сегодня анализировал. Есть продукт, где LLM интегрирована практически в каждый этап пайплайна. Сегодня обнаружилась занятная история: — на этапе разработки допустили ошибку — на QA эту ошибку покрыли автотестом как правильное поведение — code review с LLM тоже ничего не нашёл — в итоге весь пайплайн успешно прошёл, а LLM на каждом этапе при наличии спеки провалидировала результат и пропустила дальше Я начал раскручивать цепочку назад, чтобы понять, где именно появилась ошибка. И в итоге дошёл до самого начала — ТЗ. Изначальная задача была про обработку заказов. Заказы приходят из внешнего мира через шину, мы их сохраняем и маппим под структуру нашего сервиса. Никакой классификации заказов в первоначальном ТЗ не было. Задачу сделали, написали тесты, всё работает. Через некоторое время прилетает маленькая задача со скудным ТЗ: забыли учесть, что через ту же шину приходят ещё и возвраты, поэтому у товарных позиций возврата нужно проставлять соответствующий статус. И вот здесь начинается самое интересное. Из контекста предметной области довольно логично следует, что возврат — это не просто другой статус товарной позиции. Нужно ещё разобраться с тем, что сейчас на продажу и возврат создаются отдельные заказы. Но в ТЗ этого нет. Разработчик увидел простую задачу и практически полностью делегировал её LLM. А LLM сделала ровно то, что попросили: проставила статус. Code review с LLM прошло — противоречий ТЗ нет. QA написал автотесты — и они тоже проверяют ровно то поведение, которое описано в ТЗ. В итоге получился прекрасный комбайн, где каждый этап что-то валидирует, всё зелёное, все довольны — а система делает неправильную вещь 😁 И самое интересное: рой агентов здесь, скорее всего, тоже ничего бы не изменил. Можно поставить одного агента писать код, второго — тесты, третьего — ревьюить, четвёртого — проверять соответствие спеке. Они могут идеально проверить друг друга и коллективно приехать ровно туда,