Вышла новая версия SimpleGen 0.6.1

Вышла новая версия 0.6.1 инструмента SimpleGen — вашего AI-помощника для автоматизации разработки решений на базе SimpleOne. В этом релизе мы закрыли важные дефекты деплоя и синхронизации, добавили отдельную команду для отправки изменений на стенд, упростили инициализацию и работу с правилами, а также подняли качество генерации и ревью кода.

Что нового

  • Исправлена некорректная инициализация полей типа list — дефект, о котором вы сообщали в обсуждении версии 0.5.1, устранён. Значения list-полей больше не «слетают» при инициализации.

  • Больше не теряются данные при деплое и синхронизации — исправлен дефект, из-за которого при выгрузке терялись данные записей, связанных со списочным представлением и представлением формы. Теперь всё доезжает до стенда в полном объёме.

  • Корректный порядок экспорта записей на стенд — доработали последовательность выгрузки: зависимые записи деплоятся в правильном порядке, ручных «доливок» больше не требуется.

  • Новая команда /simplegen.product_patch — отправляет изменения на стенд одной командой, без лишних шагов.

  • Убрали команду update_rules — её задачу полностью закрывает init с флагом --skip-export. Меньше команд — меньше путаницы.

  • Автоматическая инициализация репозитория — при первой инициализации SimpleGen сам создаёт репозиторий и делает первый коммит. Начать работу можно сразу.

  • Одна директория для правил — сократили перечень директорий: разные IDE теперь читают правила из одного и того же места.

  • Выше качество генерации и ревью кода — переработали промпты и проверки, решения получаются точнее, а замечания на само-ревью — предметнее.

  • Рефакторинг под качество и скорость — провели внутренний рефакторинг, который положительно влияет и на результат генерации, и на время отработки запросов.

Как обновиться

  1. Обновите пакет:
npm update -g @simplegen/simplegen
  1. Запустите инициализацию в чате:
/simplegen.init "Название продукта"
  1. Установите зависимости:
npm install

Готово — вы на версии 0.6.1. Репозиторий и первый коммит при первой инициализации создадутся автоматически.

Схема разработки с SimpleGen

Чтобы было проще сориентироваться, где какая команда применяется, мы собрали полный цикл разработки в одну схему — от описания в бэклоге до влития MR. Она разбита на пять блоков: спецификация, разработка, демо и приёмка, ревью и тестирование с релизом.

Схему в формате SVG прикладываем к посту — её удобно открыть в браузере и приблизить нужный блок.

Коротко по блокам:

  • Спецификацияspec_create, затем ревью через spec_check и цикл правок до чистого результата.

  • Разработкаcontext_set, spec_plan, далее по фазам: code_generateproduct_patch → проверка фазы. После всех фаз — само-ревью через code_review, сборка SOP через product_build и выгрузка через product_sync.

  • Демо и приёмкаdemo_plan, demo_data_prepare, demo_run, после чего инженер проходит приёмку.

  • Ревью — ревьюер работает самостоятельно, с ИИ или через code_review; инженер отрабатывает каждый комментарий и актуализирует DSL, SOP и спецификацию.

  • Тестирование и релиз — тестирование QA, исправление дефектов, влитие MR. Если деплой прошёл неудачно, помогает product_rollback.

Что планируем дальше

  • Генерация тестов и поставка инструментов под них

  • Генерация виджетов по Lo-fi макетам

  • Супер-режим — агент, который ведёт весь цикл разработки самостоятельно

  • Повышение качества генерируемых скриптов

  • Продолжаем работать по обратной связи и устранять дефекты

Ещё не пробовали SimpleGen? Самое время начать — установите пакет и выполните init, чтобы оценить возможности.


Мы активно развиваем продукт и хотим делать это вместе с вами. Делитесь впечатлениями, идеями и замечаниями в комментариях — каждый отзыв помогает нам сделать SimpleGen лучше.


Схема:

2 Likes

Коллеги, есть вопросы. Проект я инициализировал, саму генерацию спеки запустил. У меня opencode были проблемы с скилами .claude - так есть model: inherit - это ломает запуск субагента opencode. Но ладно, убрал. Далее скил create_spec принимает нормер задачи. Куда что класть я не поял, агент долго шарился по диску, пока не создал пустую папку с задачей. Далее, спека генерится синглшот вайбкодингом - у агента нет промта на интервью. В результате create_spec накидал очень странных идей. То есть он придумал роль user, а я писал ТЗ на портальную клиентскую заявку. Далее он ни словом не обмовлвился о модели запроса и накидал кучу FR на то, что уже и так реализовано моими коллекциями и скриптами, он это вообще не понял и не увидел. И главное, что нет цикла рефлексии - в спеке есть какие-то блоки уточнить, есть откровенные выдумки и тд. То есть откровенно не хватает какой-то симпловой версии скилла /grill-me-with-docs от Мэта - причем и до написании спеки и для ее доработки. Как ее дорабатывать тоже непонятно. Где мне написать, что нужна модель запроса, что нужно использовать коллекции, что не надо роли user? Сам агент не поймет, про что я ему говорю, нужен какой-то скилл, который агента снабдит всем контекстов о чем я с ним говорю, как все устроено и тд. То есть пока у меня получилось только потратить время, но не получить что-то полезное. Это нормально для начала, я думаю, но надо дорабатывать флоу в части правки замечаний по поводу спеки, планов, кода.

В общем, у меня получилось пообщаться по дорабоке спеки просто пригнав в чат сами промпты спек субагентов. Почти под 100% забил контекст, но что-то агент понимал по сути общения. Попробую написать план скилами

Продолжаю работу. План скилы не вызвали вопросов, а вот кодер и код ревьювер расстроили - сразу набивают 200к+ контекста, уходят на циклы компактифизации, читают кучу всего тупо черезGlob **/some/* , агент если и работает, то или во зоне “тупости” или на потеряном через сжатие контексте. Отпишу чуть позже, чем это кончится, но уже понятно, что работа кодера и код ревьювера субоптимальна.

Александр, добрый день!

Спасибо вам большое за такую развёрнутую обратную связь! Честно — вы единственный, кто прошёл весь флоу целиком на реальной задаче и описал каждый этап, такого разбора у нас ещё не было.

По ограничению на ответы в теме 0.6.1 — это не с нашей стороны, мы такого не ставили, и по первичной проверке тема открыта. Передал админам, чтобы посмотрели и сняли, если что-то найдётся. Извините за неудобство.

Теперь по самим замечаниям.

Про model: inherit — баг зафиксировали, рассмотрим и исправим в ближайшем релизе. Спасибо, что сами докопались до причины — opencode мы до вас толком не гоняли.

Про тестирование — согласен, сейчас этапа нет. Направление уже в проработке, о результатах напишу отдельно.

Про знания о платформе — тут хочу понять, что именно имеется в виду, потому что контура два:

  • если речь о том, что находится на стенде, — это экспортируемый DSL;
  • если речь о том, как создавать ту или иную запись и какие нюансы есть при работе с ней, — это лежит в правилах и командах, с которыми можно ознакомиться в вашем репозитории.

Если вопрос был про третье — почему агент не увидел ваши коллекции и накидал FR на уже реализованное, — скажите, разберём отдельно.

Про автоматическое применение сопки и деплой — тут важный момент. У агента есть правило: перед тем как отправлять изменения на стенд, он должен собрать сводку по тому, что пойдёт в деплой, и после этого отдельно спросить, отправлять ли. То есть то, что вы хотели увидеть — дифф до применения — в сценарии в принципе есть. Если агент этот шаг пропустил, то скорее всего это галлюцинация, но перепроверим обязательно, и если такого пункта в правилах всё-таки нет, то добавим. Полностью согласен, что так и безопаснее, и удобнее.

Две просьбы по этому пункту: правило лежит у вас локально, можете глянуть сами и убедиться, что оно на месте. И если сохранилась та сессия, где деплой улетел без вопроса, прислать её лог было бы очень полезно — без неё мы можем только гадать, правило не сработало или его проигнорировала модель.

Остальное — по интервью перед спекой, циклу рефлексии, доработке спеки, контексту кодера и ревьювера — разобрали целиком и забрали в бэклог. Ваши же идеи про дробление документации и про research-субагента, который приносит кодеру только нужные куски, совпадают с тем, куда мы смотрим. О каждом изменении будем уведомлять вас отдельно.

И скажите, пожалуйста, какими моделями вы пользуетесь в работе с инструментом? Это поможет отделить проблемы флоу от ограничений модели: часть симптомов из вашего описания похожа на нехватку контекста, часть — на наши собственные пробелы.

И есть несколько рекомендаций, они относятся в целом ко всем:

  • Пользоваться крупными сильными моделями — Claude, ChatGPT и Codex и т.п. Чтобы объяснить агенту, по каким правилам работать через прослойку платформы, уходит достаточно много токенов. Если модель слабая или не хватает контекста, она будет часто галлюцинировать и игнорировать требования. Судя по вашему описанию, история с тем, что агент не понимал, где создавать директорию под задачу, как раз из этой серии. У нас были аналогичные проблемы, пока не переехали на подписку Claude ( не реклама, нам никто не заплатил) но по опыту - 20долларовой подписки хватает на тривиальные задачи).
  • Чаще запускать новую сессию — по сессии на каждую фазу. Сгенерировали спецификацию — новая сессия, сгенерировали таск-план — новая сессия и т.д. Артефакты лежат на диске, так что наработки не теряются, а вот циклов компактификации становится заметно меньше.
  • Не стесняться переспрашивать в том же чате — «почему ты реализовал так, а не иначе», «перепиши реализацию, используя такой-то скрипт», «объясни, почему ты написал такой ответ». Человек всё ещё незаменимое звено разработки, он может и должен вмешиваться на каждом шаге, особенно на моделях поменьше — инструмент сам по себе объёмный.
  • Экспериментировать с правилами — они лежат у вас локально, можно ознакомиться с ними более детально и править — как руками, так и через общение с агентом. Если что-то даст рост качества — присылайте в таком же формате фидбэка, мы обязательно провалидируем и в случае успеха погрузим в коробку.

Ещё раз большое спасибо за обратную связь и за то, что довели дело до собранной сопки! Будем принимать всё во внимание и делать инструмент лучше.

Добрый день, Али. Пользуемся Qwen3.6-27B в инхаусе. Она умненькая, контекст 260К токенов из коробки, мы с ней делаем сложные многокомпонентные системы только в путь. Но даже если я ей YARNом до мегабайта развину контекст, то это никак не поможет. Даже для антропиков последнего уровня зона тупости начинается с 120К токенов. Дальше внимание модели рассеивается и она начинает ходить кругами, деать ерунду и тд.

Новую сессию на каждую фазу, я действительно пускаю. Проблема на build фазе. Оно билдит, обламывается, билдит еще раз, потом приходит к мысли, что не сможет сбилдить и надо делать синк, я делаю синк, оно билдит еще раз и еще раз, наконец добилдивает и у меня в результате 13 пакетов с одинаковым названием, во всех кроме послених двух записи удалены. Можно как-то билдить сопку, но не толкать ее на стенд? Я сам залью, проверю, что конфликтов нет, посмотрю, какие сущности вливаются и решу надо оно мне или я на доработку пойду.

Есть еще огрехи именно в промтах.

Я попросил в модели запроса использать коллекцию. Оно вставило коллекцию в Model Form Element, но не в список связанных коллекций. В результате ее ни удалить, ни заменить нельзя. Посмотел в плане реализации - только про Model Form Element написано.

Еще оно делало чойс поля в itsm_reqest при написании модели запроса. Конечно, ничего не заработало, sys_choice просто повисли в воздухе.

Еще оно сначало нагенерило мне названий как я просил, а потом где-то словило промт, что кирилистические названия нельзя и переколбасила все на английский. Да, в подписях полей подумало, что нельзя, хотя в ТЗ себе и написало, что можно. На на build почему-то решило все перевести.

В общем, будем использовать на оформлении спеки, а имплементить пока руками. Правила не будем трогать, мы не специалисты, уж лучше вы нам сделайте хорошие скилы, а мы протестируем. Надеемся на развитие проекта!

Немного о том почему инструмент ест столь много токенов:

Ваша модель, как и любая другая, видела миллионы реализаций многокомпонентных систем — React, Django, Spring, что угодно. Всё это лежит в предобучении: публичные репозитории, StackOverflow, документация, разборы архитектуры. Про SimpleOne в предобучении нет ничего. Ни одного публичного репозитория, ни одного разобранного кейса, ни строчки нашей документации. Модель не знает ни модели запроса, ни коллекций, ни того, как у нас связаны sys_choice и таблицы, ни ограничений на именование. Всё это приходится объяснять в контексте с нуля и на каждом шаге. Отсюда и объём: мы платим токенами за то, что для React модель получает бесплатно.

И согласен что у моделей есть порог тупости, мы работаем над оптимизацией правил, команд и механизмом сокращения токенов.

Про огрехи в промптах - примем во внимание.

1 Like