Очень точное наблюдение, причём с конкретным примером - спасибо, такое ценнее всего.
Да, вы поймали реальную вещь. spec/decisions это журнал решений с обоснованиями, он писался для агента: почему выбрали так, какие альтернативы отвергли и почему. Отсюда вся эта манера через отрицание - «никаких ~T, никаких borrow». Агенту это помогает не предлагать заново уже отвергнутое, а человек читает и тонет в отсылках.
Справедливости ради, тематические руководства для человека в проекте есть: docs/ много материалов по фичам - каналы, контракты, cli, очистка ресурсов и так далее, например: https://github.com/nv-lang/nova/blob/main/docs/nova-cli.ru.md. Но вы смотрели на spec/decisions, а она правда перетягивает внимание на себя и выглядит как основная документация. Чего реально не хватает - единой обзорной точки входа «архитектура целиком, с чего начать», которая связывает разрозненные руководства в цельную картину. Плюс часть из них наверняка подустарела. Так что ваш «поймёт как применять, но не как разрабатывать» - в точку. В планах поправить после выпуска.
Соглашусь, целюсь в 2к как потолок, 4к в плане это скорее верхняя терпимая граница для самых связных кусков, которые резать дальше уже искусственно. По хорошему да, большинство модулей хочется в районе тысячи.
Про пунктик Клода на 2000 строк интересно, не сталкивался явно, но косвенно сходится: на больших файлах агент заметно чаще промахивается мимо нужного места. На 4.8 стало терпимее, но порог никуда не делся, просто отодвинулся.
Принято, видимо я неправильно прочитал тезис. Тогда мы согласны больше чем я думал: тесты защищают гипотезу агента, и работают. У меня агент тоже сам пишет и чинит тесты, я больше слежу за тем что именно проверяется, руками не пишу.
Расхождение тогда только в акценте. У меня регресс-барьер жёсткий: красный тест блокирует закрытие плана автоматически, агент не может проскочить. Видимо у вас агент сам решает, чинить код или тест под новое поведение - чуть больше доверия агенту на этом шаге.
Про мультиагенты интересно, что вы их в полностью автоматическом режиме гоняли. У меня всё-таки человек в петле на ключевых решениях. Было бы любопытно почитать отдельно, если соберётесь написать.
Кстати, ваш аудит как раз в тему. Сам вижу что несколько codegen-файлов разрослись неприлично: emit_c.rs под 31 тысячу строк, types под 18 тысяч. Для агента это реальный налог - чтобы понять файл, нужны десятки Read и Grep, плюс растёт риск что правка заденет не то место.
Сделал план декомпозиции: разбить монолиты на связные подмодули по 2-4 тысячи строк, без изменения семантики. Главный страховочный момент - побайтовое сравнение сгенерированного C до и после рефактора, чтобы гарантировать что поведение не поехало. Плюс эмпирический критерий приёмки: после распила агент должен находить нужный метод за заметно меньшее число обращений к файлам.
Хорошее эссе, по психологии агента подписываюсь под каждым пунктом, особенно про буквальное понимание и оптимизацию репозитория под агента.
По тестам поспорю мягко. У меня обратный опыт: пишу компилятор с агентами, юнит и регресс-тесты (около 2000) держат как раз то, что интеграционные и визуальные не ловят - тихие поломки в уже работавших местах. Агент закрыл план, регрессия красная - план не закрыт. Без этого барьера агенты накапливают незаметные регрессии очень быстро. Возможно зависит от типа проекта: у компилятора цена тихой поломки высокая, визуально её не увидишь.
Многоагентность - да, на старте у меня тоже эхо-камера получалась, дорого и без толку. Но когда ревьюеры с разным фокусом и контекстом, выхлоп оправдывает.
У меня тариф Claude Code Max 20x, фиксированная подписка, выходит примерно 20К рублей в месяц с учётом курса. Сумма не зависит от того, сколько токенов агенты нагенерили за день - хоть весь день гоняй в пределах лимитов плана, цена та же.
Оценка в 10К/день получается, если считать по API-ценам за токены при нагрузке 24/7. Подписочные тарифы как раз для плотного использования и сделаны: per-token по полной ставке за такой объём действительно вышел бы кратно дороже, поэтому и беру подписку.
Спасибо за разбор по пунктам, видно что сами через это прошли.
По Сбою 1: согласен, новая сессия не панацея, наслоение галлюцинаций тоже ловил. У меня чуть помогает то, что критик не видит историю предыдущей “переписки” - ему даётся только артефакт (код плюс план), без диалога, который привёл к ошибке. Когда нет цепочки рассуждений, за которую можно зацепиться, меньше шансов унаследовать ту же галлюцинацию. Но полностью не лечит, тут согласен.
По Сбою 2: Specification Drift - точное название, заберу. У меня похоже устроено, только без Jira: спека и план лежат в git как markdown, решения с обоснованием в отдельном журнале. Контроль соответствия делает агент-критик, сверяет результат с критериями приёмки из плана. Внешний трекер тикетов, наверное, дисциплинирует сильнее, но мне пока хватает текстовых артефактов в репозитории.
Спасибо, рецепт хороший, у меня попроще сделано. В AGENTS.md есть таблица ключевых файлов и жёсткое правило “перед изменением семантики языка сначала читай spec/decisions”. Но именно условной маршрутизации “если задача про комментарии - читай docs/rules/comments” у меня нет, только общий свод. Ваш подход с раздельными правилами под тип задачи выглядит чище, заберу к себе.
Тут соглашусь частично. Зависимость от скорости агентов есть: пропадут агенты - темп упадёт в разы, это честно. Но проект от этого не превращается в нечто, что без агентов не живёт.
Код на выходе обычный Rust, человекочитаемый, я его ревьюю и понимаю. Если завтра агентов не станет, проект можно вести руками - медленно, но он не рассыпется. Это не сгенерированная каша, которую без автора-агента не поддержать.
Спеки и планы по сути обычная документация, не что-то специально для агентов. Зачем принято решение, какие критерии приёмки, что должно тестироваться. Полезно и человеку, который придёт в проект через год. И ещё момент: чем строже процесс, тем меньше роль конкретной модели внутри. Так что зависимость от вендора скорее падает.
Гарантий качества от вендора, кстати, ждать ещё долго. Ровно поэтому процесс вокруг инструмента и нужен.
Про CI - спасибо, реально был красный, уже починил, сейчас зелёный.
Теперь про математику. План это не 2 килознака текста, который я печатаю руками. Моя реальная работа на план ближе к “сформулировать цель и проверить что агент понял правильно”. На это уходит куда меньше времени, чем заняло бы написать соответствующий код руками.
Да и сама скорость набора у агента несравнима с человеческой. Плюс колоссальная нагрузка при ручном кодинге - держать в голове всю систему сразу: типы, инварианты, граничные случаи, связи между модулями. Агент снимает и это. План формулирует “что”, а детальное “как” во всех частностях на порядок объёмнее, вот его и пишет агент.
Да, обязательно читаю результат. Недавно вышла Claude 4.8 — пока самое лучшее впечатление, справляется бодро. На 4.7 код почти всегда идёт без правок. На 4.6 бывают огрехи: не всегда правильно планирует выполнение, иногда пишет неоптимально. 4.5 для кода вообще не рекомендую — слишком часто ошибается. Без хотя бы беглой вычитки закрывать план рискованно: даже хорошая модель может сделать что-то формально работающее, но неудобное в дальнейшей работе.
Руками не переписываю. Если нахожу недочёты, прошу агента исправить. Это работает: на двух-трёх итерациях обычно получается то, что нужно. Заодно правки попадают в один стиль со всем остальным кодом, без скачков.
Про мусорные комментарии справедливо. У меня в шапке многих файлов есть мета-комментарии «Plan NNN: добавлено X», они нужны мне для трассировки между планом и кодом, но визуально засоряют. Имеет смысл переносить такие маркеры в commit-сообщения вместо самого кода.
Можно. Через явные правила в AGENTS.md: например, «каждый файл начинается с // Overview на 5-10 строк». ИИ это держит, если правило сформулировано однозначно. У меня применяется частично, не везде довёл до системы.
Кстати про размер файлов — как-то спрашивал у самого агента, какой размер ему комфортный. Ответил, что до 30 тысяч строк нормально, дальше желательно делить. Это тоже стоит зафиксировать в AGENTS.md правилом.
Около 20 тысяч рублей в месяц на Claude Code. В статье есть кусок про расходы и сравнение с инженерным временем.
Спасибо за подробные вопросы и за честный фидбек по коду, именно это и нужно слышать на ранней стадии.
Спасибо, что прогнали. Дрейф между правилами и кодом — реальная вещь, у меня для этого есть аудит-цикл (про него в статье есть кусок), но и он не покрывает 100%. На больших объёмах правил всегда есть отстающие места, особенно когда сами правила итерационно меняются.
Если не сложно, поделитесь конкретными местами, которые ваш агент пометил как нарушения границ или правил? Если это общая точка — добавлю в шаблон аудита, если частная — починю и зафиксирую. Свежий взгляд со стороны почти всегда ценнее моего собственного прогона.
Спасибо, плюс взаимно! Ощущение очень знакомое — то самое «могущество», когда один человек проворачивает объём команды. Но именно этот восторг был для меня главным риском на первых неделях: пока всё летит, легко не заметить как агенты тихо накапливают долги в коде. У меня это вскрылось через несколько недель в виде серии багов, которые в моменте казались мелочью.
Если будете дальше масштабировать, рекомендую заранее ввести аудит-цикл — даже простой: второй раз пройтись по результату с другой моделью или хотя бы с другим промптом. Снимает ровно тот класс проблем, который «могущество» помогает накопить незаметно.
На самом деле модель я выставляю вручную, обычно Opus. Sonnet включаю редко, под конкретные мелкие задачи. Авто-переключение моделей у меня не замечал, видимо зависит от настроек — у меня основной режим вручную с Opus.
Явных инструкций «использовать только Sonnet ради экономии» у меня нет, специально проверил свой AGENTS.md и другие конфиги.
Статья при этом не про экономию. Цифра по Claude Code (20 тысяч/мес) там для контекста, главное про методологию и где агенты ломаются.
Сейчас запуск ручной. Под каждый план — отдельный 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), дальше итерациями.
Это будет ещё и хорошим тестом самосогласованности: писать компилятор на самом языке заставляет столкнуться со всеми его неудобствами и пробелами на собственной шкуре.
Спасибо! Хороший вопрос, точно тема для отдельной статьи. Если кратко: начинаю с шаблона плана. Агенту говорю, что хочу сделать. Агент генерит черновик плана. Дальше итерационно обсуждаю с ним черновик, прошу добавить критерии приёмки, тесты, эскалацию. Руками сам почти не правлю, всё через диалог с агентом. Когда план готов — даю агенту примерно такой промпт на выполнение:
выполни все пункты плана NNN без упрощений (как для прода) и без остановок по всем пунктам, не забудь обновить спеку, D, Q и документацию по выполненной работе, сделай позитивные и негативные тесты, проверь результат по критериям приёмки, коммить после каждой большой задачи, если задач несколько — разбей на несколько коммитов по типам работ, работай по плану изолированно, запиши в план статус по завершении
Без такого промпта агент часто пытается упростить задачу или остановиться раньше времени.
Запишу себе в заметки, поделюсь подробнее в одной из следующих статей серии.
Использую сервис-прокладку, нашел в инете. Общение и выбор тарифа на Claude Code через Telegram (и не только Claude Code у них есть). В целом таких сервисов на рынке немало, kenomimi уже описал в ветке. Курс выше биржевого, конечно, но работает. Там, где платил я, могу дать ссылку в личке.
Справедливо. Прямой метрики по разделению «Claude vs процесс» у меня нет — контрольной группы «то же самое без планов и аудита» я не делал. Сужу косвенно: ранние попытки без структуры расползались за две-три недели, с дисциплиной темп держится второй месяц. Про «давно известные» сбои — согласен, ничего радикально нового. Ценность скорее в том, что они переносятся на агентов почти один-в-один, только в более острой форме: confirmation bias сильнее, edge cases пропускаются чаще. Лечится тоже плюс-минус знакомыми методами.
Очень точное наблюдение, причём с конкретным примером - спасибо, такое ценнее всего.
Да, вы поймали реальную вещь. spec/decisions это журнал решений с обоснованиями, он писался для агента: почему выбрали так, какие альтернативы отвергли и почему. Отсюда вся эта манера через отрицание - «никаких ~T, никаких borrow». Агенту это помогает не предлагать заново уже отвергнутое, а человек читает и тонет в отсылках.
Справедливости ради, тематические руководства для человека в проекте есть: docs/ много материалов по фичам - каналы, контракты, cli, очистка ресурсов и так далее, например: https://github.com/nv-lang/nova/blob/main/docs/nova-cli.ru.md. Но вы смотрели на spec/decisions, а она правда перетягивает внимание на себя и выглядит как основная документация. Чего реально не хватает - единой обзорной точки входа «архитектура целиком, с чего начать», которая связывает разрозненные руководства в цельную картину. Плюс часть из них наверняка подустарела. Так что ваш «поймёт как применять, но не как разрабатывать» - в точку. В планах поправить после выпуска.
Спасибо за разбор и за пожелания, удачи тоже!
Соглашусь, целюсь в 2к как потолок, 4к в плане это скорее верхняя терпимая граница для самых связных кусков, которые резать дальше уже искусственно. По хорошему да, большинство модулей хочется в районе тысячи.
Про пунктик Клода на 2000 строк интересно, не сталкивался явно, но косвенно сходится: на больших файлах агент заметно чаще промахивается мимо нужного места. На 4.8 стало терпимее, но порог никуда не делся, просто отодвинулся.
Принято, видимо я неправильно прочитал тезис. Тогда мы согласны больше чем я думал: тесты защищают гипотезу агента, и работают. У меня агент тоже сам пишет и чинит тесты, я больше слежу за тем что именно проверяется, руками не пишу.
Расхождение тогда только в акценте. У меня регресс-барьер жёсткий: красный тест блокирует закрытие плана автоматически, агент не может проскочить. Видимо у вас агент сам решает, чинить код или тест под новое поведение - чуть больше доверия агенту на этом шаге.
Про мультиагенты интересно, что вы их в полностью автоматическом режиме гоняли. У меня всё-таки человек в петле на ключевых решениях. Было бы любопытно почитать отдельно, если соберётесь написать.
Кстати, ваш аудит как раз в тему. Сам вижу что несколько 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) держат как раз то, что интеграционные и визуальные не ловят - тихие поломки в уже работавших местах. Агент закрыл план, регрессия красная - план не закрыт. Без этого барьера агенты накапливают незаметные регрессии очень быстро. Возможно зависит от типа проекта: у компилятора цена тихой поломки высокая, визуально её не увидишь.
Многоагентность - да, на старте у меня тоже эхо-камера получалась, дорого и без толку. Но когда ревьюеры с разным фокусом и контекстом, выхлоп оправдывает.
У меня тариф Claude Code Max 20x, фиксированная подписка, выходит примерно 20К рублей в месяц с учётом курса. Сумма не зависит от того, сколько токенов агенты нагенерили за день - хоть весь день гоняй в пределах лимитов плана, цена та же.
Оценка в 10К/день получается, если считать по API-ценам за токены при нагрузке 24/7. Подписочные тарифы как раз для плотного использования и сделаны: per-token по полной ставке за такой объём действительно вышел бы кратно дороже, поэтому и беру подписку.
Спасибо за разбор по пунктам, видно что сами через это прошли.
По Сбою 1: согласен, новая сессия не панацея, наслоение галлюцинаций тоже ловил. У меня чуть помогает то, что критик не видит историю предыдущей “переписки” - ему даётся только артефакт (код плюс план), без диалога, который привёл к ошибке. Когда нет цепочки рассуждений, за которую можно зацепиться, меньше шансов унаследовать ту же галлюцинацию. Но полностью не лечит, тут согласен.
По Сбою 2: Specification Drift - точное название, заберу. У меня похоже устроено, только без Jira: спека и план лежат в git как markdown, решения с обоснованием в отдельном журнале. Контроль соответствия делает агент-критик, сверяет результат с критериями приёмки из плана. Внешний трекер тикетов, наверное, дисциплинирует сильнее, но мне пока хватает текстовых артефактов в репозитории.
Спасибо, рецепт хороший, у меня попроще сделано. В AGENTS.md есть таблица ключевых файлов и жёсткое правило “перед изменением семантики языка сначала читай spec/decisions”. Но именно условной маршрутизации “если задача про комментарии - читай docs/rules/comments” у меня нет, только общий свод. Ваш подход с раздельными правилами под тип задачи выглядит чище, заберу к себе.
Тут соглашусь частично. Зависимость от скорости агентов есть: пропадут агенты - темп упадёт в разы, это честно. Но проект от этого не превращается в нечто, что без агентов не живёт.
Код на выходе обычный Rust, человекочитаемый, я его ревьюю и понимаю. Если завтра агентов не станет, проект можно вести руками - медленно, но он не рассыпется. Это не сгенерированная каша, которую без автора-агента не поддержать.
Спеки и планы по сути обычная документация, не что-то специально для агентов. Зачем принято решение, какие критерии приёмки, что должно тестироваться. Полезно и человеку, который придёт в проект через год. И ещё момент: чем строже процесс, тем меньше роль конкретной модели внутри. Так что зависимость от вендора скорее падает.
Гарантий качества от вендора, кстати, ждать ещё долго. Ровно поэтому процесс вокруг инструмента и нужен.
Про CI - спасибо, реально был красный, уже починил, сейчас зелёный.
Теперь про математику. План это не 2 килознака текста, который я печатаю руками. Моя реальная работа на план ближе к “сформулировать цель и проверить что агент понял правильно”. На это уходит куда меньше времени, чем заняло бы написать соответствующий код руками.
Да и сама скорость набора у агента несравнима с человеческой. Плюс колоссальная нагрузка при ручном кодинге - держать в голове всю систему сразу: типы, инварианты, граничные случаи, связи между модулями. Агент снимает и это. План формулирует “что”, а детальное “как” во всех частностях на порядок объёмнее, вот его и пишет агент.
Да, обязательно читаю результат. Недавно вышла Claude 4.8 — пока самое лучшее впечатление, справляется бодро. На 4.7 код почти всегда идёт без правок. На 4.6 бывают огрехи: не всегда правильно планирует выполнение, иногда пишет неоптимально. 4.5 для кода вообще не рекомендую — слишком часто ошибается. Без хотя бы беглой вычитки закрывать план рискованно: даже хорошая модель может сделать что-то формально работающее, но неудобное в дальнейшей работе.
Руками не переписываю. Если нахожу недочёты, прошу агента исправить. Это работает: на двух-трёх итерациях обычно получается то, что нужно. Заодно правки попадают в один стиль со всем остальным кодом, без скачков.
Про мусорные комментарии справедливо. У меня в шапке многих файлов есть мета-комментарии «Plan NNN: добавлено X», они нужны мне для трассировки между планом и кодом, но визуально засоряют. Имеет смысл переносить такие маркеры в commit-сообщения вместо самого кода.
Можно. Через явные правила в AGENTS.md: например, «каждый файл начинается с // Overview на 5-10 строк». ИИ это держит, если правило сформулировано однозначно. У меня применяется частично, не везде довёл до системы.
Кстати про размер файлов — как-то спрашивал у самого агента, какой размер ему комфортный. Ответил, что до 30 тысяч строк нормально, дальше желательно делить. Это тоже стоит зафиксировать в AGENTS.md правилом.
Около 20 тысяч рублей в месяц на Claude Code. В статье есть кусок про расходы и сравнение с инженерным временем.
Спасибо за подробные вопросы и за честный фидбек по коду, именно это и нужно слышать на ранней стадии.
Понял, спасибо. Будет интересно посмотреть вашу статью — про ревью и правила тема живая. Скиньте ссылку когда выложите, приду почитать.
Спасибо, что прогнали. Дрейф между правилами и кодом — реальная вещь, у меня для этого есть аудит-цикл (про него в статье есть кусок), но и он не покрывает 100%. На больших объёмах правил всегда есть отстающие места, особенно когда сами правила итерационно меняются.
Если не сложно, поделитесь конкретными местами, которые ваш агент пометил как нарушения границ или правил? Если это общая точка — добавлю в шаблон аудита, если частная — починю и зафиксирую. Свежий взгляд со стороны почти всегда ценнее моего собственного прогона.
Спасибо, плюс взаимно! Ощущение очень знакомое — то самое «могущество», когда один человек проворачивает объём команды. Но именно этот восторг был для меня главным риском на первых неделях: пока всё летит, легко не заметить как агенты тихо накапливают долги в коде. У меня это вскрылось через несколько недель в виде серии багов, которые в моменте казались мелочью.
Если будете дальше масштабировать, рекомендую заранее ввести аудит-цикл — даже простой: второй раз пройтись по результату с другой моделью или хотя бы с другим промптом. Снимает ровно тот класс проблем, который «могущество» помогает накопить незаметно.
На самом деле модель я выставляю вручную, обычно Opus. Sonnet включаю редко, под конкретные мелкие задачи. Авто-переключение моделей у меня не замечал, видимо зависит от настроек — у меня основной режим вручную с Opus.
Явных инструкций «использовать только Sonnet ради экономии» у меня нет, специально проверил свой AGENTS.md и другие конфиги.
Статья при этом не про экономию. Цифра по Claude Code (20 тысяч/мес) там для контекста, главное про методологию и где агенты ломаются.
Сейчас запуск ручной. Под каждый план — отдельный 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), дальше итерациями.
Это будет ещё и хорошим тестом самосогласованности: писать компилятор на самом языке заставляет столкнуться со всеми его неудобствами и пробелами на собственной шкуре.
Спасибо! Хороший вопрос, точно тема для отдельной статьи. Если кратко: начинаю с шаблона плана. Агенту говорю, что хочу сделать. Агент генерит черновик плана. Дальше итерационно обсуждаю с ним черновик, прошу добавить критерии приёмки, тесты, эскалацию. Руками сам почти не правлю, всё через диалог с агентом. Когда план готов — даю агенту примерно такой промпт на выполнение:
Без такого промпта агент часто пытается упростить задачу или остановиться раньше времени.
Запишу себе в заметки, поделюсь подробнее в одной из следующих статей серии.
Использую сервис-прокладку, нашел в инете. Общение и выбор тарифа на Claude Code через Telegram (и не только Claude Code у них есть). В целом таких сервисов на рынке немало, kenomimi уже описал в ветке. Курс выше биржевого, конечно, но работает. Там, где платил я, могу дать ссылку в личке.
Справедливо. Прямой метрики по разделению «Claude vs процесс» у меня нет — контрольной группы «то же самое без планов и аудита» я не делал. Сужу косвенно: ранние попытки без структуры расползались за две-три недели, с дисциплиной темп держится второй месяц. Про «давно известные» сбои — согласен, ничего радикально нового. Ценность скорее в том, что они переносятся на агентов почти один-в-один, только в более острой форме: confirmation bias сильнее, edge cases пропускаются чаще. Лечится тоже плюс-минус знакомыми методами.