Comments 49
а как вы клауд оплачиваете из россии?
Куча фирм-прокладок работает для оплаты, дают номер карты с нужной суммой и всё. У них курс доллара несколько выше, но работает железно, и хорошая поддержка. Сам пользуюсь. А если надо большие суммы, чувствительные к завышеному курсу, то получается турецкая карта (надо ехать лично) и с нее можно платить.
Использую сервис-прокладку, нашел в инете. Общение и выбор тарифа на Claude Code через Telegram (и не только Claude Code у них есть). В целом таких сервисов на рынке немало, kenomimi уже описал в ветке. Курс выше биржевого, конечно, но работает. Там, где платил я, могу дать ссылку в личке.
Спасибо, очень интересно. Написать с помощью ИИ игру в змейку или сконструировать простенькую формочку, это одно. Разработка компилятора это задача совсем другого порядка. С первого раза мало что понял, ибо опыта с ИИ не имею никакого, всегда всё писал ручками. Забил в закладки, буду перечитывать. Пока из того что понял, вопросов всего два.
1) Пытались ли Вы разбираться в каком-то коде, который сгенерирован ИИ ? Насколько этот код читаем и понимаем человеком ?
2) Пытались ли Вы какие-то фрагменты кода сгенерированного ИИ, переписывать вручную ? Насколько сгенерированный код уступает (или наоборот превосходит ???) рукописному ?
В целом ещё раз, огромный респект. Проект интереснейший. С нетерпением жду продолжения Ваших приключений.
P.S. Бегло глянул на гитхабе. Ну что тут сказать... К сожалению я наСИльник, а не РАСТаман. По первому впечатлению код как бы это сказать... Довольно мусорный. Загрязненный совершенно лишними комментариями о каких-то планах, явно сгенерированными ИИ. У меня подход немного другой. Каждый файл в шапке содержит описание, для чего он нужен, и общий обзор алгоритмов "с высоты птичьего полёта". Далее комментарий перед каждой функцией, что она делает. И в редких случаях комментарии внутри функции. В связи с этим ещё один вопрос
3) Можно ли заставить ИИ комментировать в таком стиле ?
P.P.S. Ещё один вопрос.
4) Во сколько Вам этот месяц обошелся по деньгам ?
Время редактирования комментария истекло. Поэтому задаю следующий вопрос в отдельном комменте.
5) Не могли бы Вы по шагам, по этапам описать процесс разработки, начиная с самого первого промпта ? Для совсем тупых, таких как я. Думаю многим было бы интересно.
Спасибо! Хороший вопрос, точно тема для отдельной статьи. Если кратко: начинаю с шаблона плана. Агенту говорю, что хочу сделать. Агент генерит черновик плана. Дальше итерационно обсуждаю с ним черновик, прошу добавить критерии приёмки, тесты, эскалацию. Руками сам почти не правлю, всё через диалог с агентом. Когда план готов — даю агенту примерно такой промпт на выполнение:
выполни все пункты плана NNN без упрощений (как для прода) и без остановок по всем пунктам, не забудь обновить спеку, D, Q и документацию по выполненной работе, сделай позитивные и негативные тесты, проверь результат по критериям приёмки, коммить после каждой большой задачи, если задач несколько — разбей на несколько коммитов по типам работ, работай по плану изолированно, запиши в план статус по завершении
Без такого промпта агент часто пытается упростить задачу или остановиться раньше времени.
Запишу себе в заметки, поделюсь подробнее в одной из следующих статей серии.
Да, обязательно читаю результат. Недавно вышла Claude 4.8 — пока самое лучшее впечатление, справляется бодро. На 4.7 код почти всегда идёт без правок. На 4.6 бывают огрехи: не всегда правильно планирует выполнение, иногда пишет неоптимально. 4.5 для кода вообще не рекомендую — слишком часто ошибается. Без хотя бы беглой вычитки закрывать план рискованно: даже хорошая модель может сделать что-то формально работающее, но неудобное в дальнейшей работе.
Руками не переписываю. Если нахожу недочёты, прошу агента исправить. Это работает: на двух-трёх итерациях обычно получается то, что нужно. Заодно правки попадают в один стиль со всем остальным кодом, без скачков.
Про мусорные комментарии справедливо. У меня в шапке многих файлов есть мета-комментарии «Plan NNN: добавлено X», они нужны мне для трассировки между планом и кодом, но визуально засоряют. Имеет смысл переносить такие маркеры в commit-сообщения вместо самого кода.
Можно. Через явные правила в AGENTS.md: например, «каждый файл начинается с // Overview на 5-10 строк». ИИ это держит, если правило сформулировано однозначно. У меня применяется частично, не везде довёл до системы.
Кстати про размер файлов — как-то спрашивал у самого агента, какой размер ему комфортный. Ответил, что до 30 тысяч строк нормально, дальше желательно делить. Это тоже стоит зафиксировать в AGENTS.md правилом.
Около 20 тысяч рублей в месяц на Claude Code. В статье есть кусок про расходы и сравнение с инженерным временем.
Спасибо за подробные вопросы и за честный фидбек по коду, именно это и нужно слышать на ранней стадии.
Вопросы не мне, но могу поделится своим опытом, что есть.
1. Да, хорошо читаем. Не хуже человеческого, часто лучше, так как нет такого, что названо "утка", а там цапля. Комментарии, названия переменных, методов всегда соответствуют коду и содержимому.
2. Переписывать не пытался, так как смысла нет. Если сделано не так как хочешь, можно выделить кусочек, кинуть агенту и сказать "переделай так-то и так-то".
3. Да, это решается правилами проекта/пользователя. У меня в правилах написано "Не делай очевидные комментарии". После этого комментариев стало мало, только там, где они реально нужны. Можно добавить, что бы делал описания модулей, ну и любой другой каприз...
3) Можно ли заставить ИИ комментировать в таком стиле ?
Да.
Стандартный подход в Cursor, когда используете Claude Plugin:
1. в корневом CLAUDE.md добавляете:
---------
Mandatory rules - load before starting matching work
| If the task involves… | You MUST first Read |
|—|—|
| Writing, editing, or reviewing comments in source code (any language) | docs/rules/code-comments-policy.md |
---------
2. А в доках, в подкаталоге rules, добавляете файл с инстукций code-comments-policy.md. И реализуете там свои хотелки.
Спасибо, рецепт хороший, у меня попроще сделано. В AGENTS.md есть таблица ключевых файлов и жёсткое правило “перед изменением семантики языка сначала читай spec/decisions”. Но именно условной маршрутизации “если задача про комментарии - читай docs/rules/comments” у меня нет, только общий свод. Ваш подход с раздельными правилами под тип задачи выглядит чище, заберу к себе.
del
Интересно, но недостаточно метрик. Из статьи не очень понятно, какая часть успеха связана именно с Claude Code, а какая с выстроенным процессом (планы, аудит, несколько ревьюеров, регрессия, ручной контроль). Многие описанные сбои вроде давно известны: неполное покрытие, anchoring, пропуск edge cases и коррелированные ошибки ревьюеров. Было бы особенно интересно увидеть статистику: какой процент планов проходит с первого раза, сколько переоткрывается после аудита и сколько решений пришлось выбросить полностью.
А почему одно отделяется от другого? Процесс вокруг инструмента и сам инструмент - это единое целое. Голый станок без обвязки рабочим процессом это просто станок.
Справедливо. Прямой метрики по разделению «Claude vs процесс» у меня нет — контрольной группы «то же самое без планов и аудита» я не делал. Сужу косвенно: ранние попытки без структуры расползались за две-три недели, с дисциплиной темп держится второй месяц. Про «давно известные» сбои — согласен, ничего радикально нового. Ценность скорее в том, что они переносятся на агентов почти один-в-один, только в более острой форме: confirmation bias сильнее, edge cases пропускаются чаще. Лечится тоже плюс-минус знакомыми методами.
Глянул проект глазами агента.
Судя по всеми у вас в методологии разработки нет регулярных ревью кодовой базы. Поверхностный аудит находит ряд проблем. Агент утверждает, что проект местами нарушает декларированные правила, есть нарушения заявленных границ. Не берусь оценить, действительно ли это так, но агент ревьювер вещает недовольно.
Меня, как матёрого вайбкодера, больше тревожит вот это: emit_c.rs 28,944 строк, types/mod.rs 16,757, parser/mod.rs 9,896, field_cache.rs 8,987. Агентам сложно работать в крупных файлах. claude этим особенно страдает. Если бы проект проходил регулярный анализ, файлы были бы давно распилены.
Агент утверждает, что emit_c.rs - цитирую: "занимается локальным type inference, registry population, monomorphization details, protocol boxing, diagnostics, runtime lowering, special cases для stdlib, result/option tracking, contracts runtime emission и кучей фазовой логики".
Плохой запах.
Этих гавриков надо посылать не только на ревью последних изменений, но и проект в целом смотреть регулярно. Иначе монолиты растут как снежный ком
Этим там Sonnet занимался в CLI. А это самая слабая модель.
Видимо автор сильно экономил деньги.
Это как заявится на World Rally Championship с ВАЗ-2107 и пытаться там учить как взять приз.
Не, статья ничего не говорит о реальных расходах на таких проектах.
Определённо нет. С аудитом кода прекрасно справляется даже qwen3.6-27b. Не верю, что sonnet мог пропустить emit_c.rs
Этим там Sonnet занимался в CLI. А это самая слабая модель.
Если не переключать модель руками, то он сам ее перещелкивает, когда более слабая не справляется, и потом возвращает назад. Я ничего у себя не переключаю, но всегда вижу расход токенов по нескольким моделям сразу.
У автора есть явная инструкция когда использовать Sonnet. Эт не я выдумал. Это он сам. Это делается для экономии.
Но если его статья об экономии, то тема не раскрыта совсем.
Про sonnet ничё не знаю. Знаю, что профилактика не проводилась
На самом деле модель я выставляю вручную, обычно Opus. Sonnet включаю редко, под конкретные мелкие задачи. Авто-переключение моделей у меня не замечал, видимо зависит от настроек — у меня основной режим вручную с Opus.
Явных инструкций «использовать только Sonnet ради экономии» у меня нет, специально проверил свой AGENTS.md и другие конфиги.
Статья при этом не про экономию. Цифра по Claude Code (20 тысяч/мес) там для контекста, главное про методологию и где агенты ломаются.
Спасибо, что прогнали. Дрейф между правилами и кодом — реальная вещь, у меня для этого есть аудит-цикл (про него в статье есть кусок), но и он не покрывает 100%. На больших объёмах правил всегда есть отстающие места, особенно когда сами правила итерационно меняются.
Если не сложно, поделитесь конкретными местами, которые ваш агент пометил как нарушения границ или правил? Если это общая точка — добавлю в шаблон аудита, если частная — починю и зафиксирую. Свежий взгляд со стороны почти всегда ценнее моего собственного прогона.
Да нет там ничего ценного. Там самый общий базовый прогон. Ваши тоже самое увидят.
Я лучше статьёй поделюсь. Думаю, завтра уже выложу. Там и про ревью и про правила как раз будет. И много ещё про чего
Понял, спасибо. Будет интересно посмотреть вашу статью — про ревью и правила тема живая. Скиньте ссылку когда выложите, приду почитать.
Кстати, ваш аудит как раз в тему. Сам вижу что несколько codegen-файлов разрослись неприлично: emit_c.rs под 31 тысячу строк, types под 18 тысяч. Для агента это реальный налог - чтобы понять файл, нужны десятки Read и Grep, плюс растёт риск что правка заденет не то место.
Сделал план декомпозиции: разбить монолиты на связные подмодули по 2-4 тысячи строк, без изменения семантики. Главный страховочный момент - побайтовое сравнение сгенерированного C до и после рефактора, чтобы гарантировать что поведение не поехало. Плюс эмпирический критерий приёмки: после распила агент должен находить нужный метод за заметно меньшее число обращений к файлам.
Стартую после релиза 0.1, чтобы не ловить merge hell с текущими фичами. Сам план, если интересно: https://github.com/nv-lang/nova/blob/main/docs/plans/129-codegen-decomposition.md
Четыре тысячи строк всё ещё много. Две тысячи строк - верхняя граница. По хорошему тревогу надо поднимать уже на полутора тысячах. Хорошо, если файл не уходит за тысячу.
У клода есть отдельный пунктик про 2000 строк. До какого-то момента, времён этак 4.5 (надеюсь Антропики это уже починили), клод даже просто разобрать файл свыше двух косарей на части толком не мог. Приходилось других агентов на помощь звать. Но так-то это их общее слабое место.
Очень интересный опыт, плюсую все с удовольствием.
Сам тоже активно использую ИИ в пет-проектах, но не в таких грандиозных масштабах. Впечатления использования ИИ очень необычные, я ощущаю некое "могущество", когда могу делать то, на что раньше требовалась целая команда. Это реально очень круто, жду продолжения)
Спасибо, плюс взаимно! Ощущение очень знакомое — то самое «могущество», когда один человек проворачивает объём команды. Но именно этот восторг был для меня главным риском на первых неделях: пока всё летит, легко не заметить как агенты тихо накапливают долги в коде. У меня это вскрылось через несколько недель в виде серии багов, которые в моменте казались мелочью.
Если будете дальше масштабировать, рекомендую заранее ввести аудит-цикл — даже простой: второй раз пройтись по результату с другой моделью или хотя бы с другим промптом. Снимает ровно тот класс проблем, который «могущество» помогает накопить незаметно.
как именно у вас организована работа с несколькими агентами? как настроен их запуск, полностью ручной после каждого цикла беседы с ИИ?
что у вас - рабочее место?
Сейчас запуск ручной. Под каждый план — отдельный worktree (как в схеме на третьей диаграмме), в нём своя сессия Claude Code. Параллельно держу 4-7 сессий, в них могут быть разные стадии: кто-то работает по большому плану, у кого-то мелкие правки или ожидание моего ревью. Когда сессия закончила, смотрю результат, либо мерджу в main, либо перезапускаю с правками плана.
Рабочее место — Windows, ноут, нахожусь в добровольно- принудительном отпуске. Никакой специальной оркестрации: VS Code + окна с Claude Code. VS Code использую, чтобы ходить по файлам, смотреть код на Nova с подсветкой синтаксиса. Код на Nova, кстати, тоже пишет сам Claude Code. Из железа критичны быстрый SSD (параллельные билды) и побольше RAM (несколько worktree активны одновременно).
В Claude Code 4.8 (вышел недавно) появилось автоматическое разбиение задачи на подпланы при выполнении: он умеет сам запустить в фоне несколько внутренних агентов под разные части плана. То есть то, что я месяц делал руками через несколько сессий, сейчас Claude Code делает автоматически.
Очень интересный и перспективный проект. Обычно стандартом зрелости языка является написание компилятора языка на самом языке. Можно ли это ожидать? Было бы очень здорово для развития проекта.
Да, цель такая есть, изначально держу в уме. Сейчас рано: std пока только формируется, синтаксис Nova на стадии стабилизации. Но направление чёткое — постепенно дотягиваю std до уровня, на котором можно делать на Nova что-то рабочее в проде. Реалистично через год-полтора попробую переписать сначала самые статичные части (lexer, базовый AST), дальше итерациями.
Это будет ещё и хорошим тестом самосогласованности: писать компилятор на самом языке заставляет столкнуться со всеми его неудобствами и пробелами на собственной шкуре.
Чтоб я так comments в code write. Такой fabric, очень fashion.
Поразительно ненужная трата токенов и долларов. Откуда такая страсть изобретать сломанные велосипеды?
В пересчёте на день получается порядка восьми-десяти закрытых планов. Один человек физически такое количество кода за такое время не напишет.
А планы-то пишет кто? 2 килознака на план это не сказать, чтобы малое количество текста. Если человек способен в день выдавать 20 килознаков в день на планы, то и код вполне способен выдавать в немалых количествах и в лучшем качестве.
CI весь красный. вы б хоть тесты туда докинули
Про CI - спасибо, реально был красный, уже починил, сейчас зелёный.
Теперь про математику. План это не 2 килознака текста, который я печатаю руками. Моя реальная работа на план ближе к “сформулировать цель и проверить что агент понял правильно”. На это уходит куда меньше времени, чем заняло бы написать соответствующий код руками.
Да и сама скорость набора у агента несравнима с человеческой. Плюс колоссальная нагрузка при ручном кодинге - держать в голове всю систему сразу: типы, инварианты, граничные случаи, связи между модулями. Агент снимает и это. План формулирует “что”, а детальное “как” во всех частностях на порядок объёмнее, вот его и пишет агент.
Сбой 1. Уверенные галлюцинации
В идеале нужно использовать другую модель или хотя бы с очень другим промптом. Например, я частенько добавлял в промпт: перепроверь с чистого листа то-то и то-то…
Если запустить новую чат-сессию для анализа проблем в предыдущей, в моем случае получается наслоение галлюцинаций и полная каша.
Пока единственное решение в личном осмыслении происходящего и контроле сложной архитектуры и логики.
Сбой 2. Защита прошлой позиции
Напоминает Specification Drift.
Сложно отследить и пока склоняюсь к внешней спецификации и контролю выполнения согласно спеки. Project Specs задается снаружи (иерархическая структура), создает тикеты в Bug Tracking System (Jira), и проверяет соответствие выполнению подглядывая в IDE (Cursor + Claude Plugin).
Спасибо за разбор по пунктам, видно что сами через это прошли.
По Сбою 1: согласен, новая сессия не панацея, наслоение галлюцинаций тоже ловил. У меня чуть помогает то, что критик не видит историю предыдущей “переписки” - ему даётся только артефакт (код плюс план), без диалога, который привёл к ошибке. Когда нет цепочки рассуждений, за которую можно зацепиться, меньше шансов унаследовать ту же галлюцинацию. Но полностью не лечит, тут согласен.
По Сбою 2: Specification Drift - точное название, заберу. У меня похоже устроено, только без Jira: спека и план лежат в git как markdown, решения с обоснованием в отдельном журнале. Контроль соответствия делает агент-критик, сверяет результат с критериями приёмки из плана. Внешний трекер тикетов, наверное, дисциплинирует сильнее, но мне пока хватает текстовых артефактов в репозитории.
Очевидный третий вариант развития будущего, впрочем не исключающий первые два, состоит в резком повышении цен на услуги ИИ. Сейчас ИИ-конторы сидят в жёстких минусах ради захвата долей рынка, но это явно временно. Будет не $20 в месяц, а $20 в час. Особенно в профессиональных задачах, а не просто "поболтать"
Не верю в этот вариант. По ценам api у них не минуса. По подпискам - может быть. Так что выше цен апишек вряд ли смогут поднять. Даже в Америке два конкурента, а на пятки очень мощно Китай наступает, никак не расслабишься. Посмотрите цены на GLM, а она хоть и пониже лидеров, но не так уж и радикально.
Причем много довольно не плохих моделей с открытыми весами (вроде и GLM открыта?). Тут точно не поднимешь намного выше себестоимости - ну иначе просто будут рядышком подниматься сервера. Корпоративные, да и на продажу услуг api.
Локальные модели действительно могут отожрать кусок рынка, и тут не только GLM5, бытовое железо для которой будет очень нескоро, но и Gemma-4. Как только выйдут карты на 32гб vram, Гемма станет реально домашней/soho альтернативой большим моделям. По крайней мере в типичных офисных задачах.
Но это тем более откусит у больших АИ "длинный хвост" людей на подписке, которые пользуются режиме поболтать, и опять же заставит повышать цены для остальных.
Вот-вот. По профилю нагрузки автора, не верю в себестоимость 20К в месяц. Оценил бы затраты в ~10К в день
У меня тариф Claude Code Max 20x, фиксированная подписка, выходит примерно 20К рублей в месяц с учётом курса. Сумма не зависит от того, сколько токенов агенты нагенерили за день - хоть весь день гоняй в пределах лимитов плана, цена та же.
Оценка в 10К/день получается, если считать по API-ценам за токены при нагрузке 24/7. Подписочные тарифы как раз для плотного использования и сделаны: per-token по полной ставке за такой объём действительно вышел бы кратно дороже, поэтому и беру подписку.
Двадцать тысяч на AI-агента — это в десятки раз меньше, чем стоимость работы инженера, который сделал бы такой же объём вручную
Не пробовали локальные агенты? Интересно насколько реально собрать что-то работающее на 16Gb VRAM + 64Gb RAM с локальной моделью.
Собственно за 2 месяца оплаты можно взять начальную видео карту на 16Gb.
Я пробовал то, что предлагает cline бесплатно. Какой-то kat coder pro. Сейчас у них другие бесплатные модели, этой уже нет. Размеры их не помню. Пробовал в качестве кодера. Впечатления очень грустные. В общем, даже на кодера не тянут, только простые не автономные вещи типа "сдалай процедурку", "сделай тут такой-то цикл". Может, флеш игру закодируют или страницу сайта. Но не большая кодовая база и простая архитектура.
А это всего лишь роль "кодер", на архитектора для анализа кода и плана нужна модель еще сильнее. Поэтому уверен - не потянут модели серьезное кодирование ни с 16 видеопамяти, ни с 32. Побаловаться - да. Серьезное применение - только топы.
На мой взгляд, проблема не в том на каком масштабе ломаются агенты, а где сломается процесс если агентов вдруг не станет. Если единственный способ поддержки и разработки агенты - это вечный пет проект. В таком случае, перестают быть важны выкрутасы со спеками, просто будем ждать ту модель, чей вендор даст гарантии качества.
Тут соглашусь частично. Зависимость от скорости агентов есть: пропадут агенты - темп упадёт в разы, это честно. Но проект от этого не превращается в нечто, что без агентов не живёт.
Код на выходе обычный Rust, человекочитаемый, я его ревьюю и понимаю. Если завтра агентов не станет, проект можно вести руками - медленно, но он не рассыпется. Это не сгенерированная каша, которую без автора-агента не поддержать.
Спеки и планы по сути обычная документация, не что-то специально для агентов. Зачем принято решение, какие критерии приёмки, что должно тестироваться. Полезно и человеку, который придёт в проект через год. И ещё момент: чем строже процесс, тем меньше роль конкретной модели внутри. Так что зависимость от вендора скорее падает.
Гарантий качества от вендора, кстати, ждать ещё долго. Ровно поэтому процесс вокруг инструмента и нужен.
Месяц пишу язык программирования Nova с Claude Code. Где ломаются автономные агенты