Агентная разработка ПО для 1С

Кратко

1c-lite — работающий R&D-фреймворк для разработки 1С по спецификациям. Он объединяет анализ, независимое ревью спецификации, model routing, параллельную реализацию, проверку и приёмку человеком.

Цель — не максимальный объём сгенерированного кода, а более предсказуемая, проверяемая и экономически измеримая разработка с AI в реальных проектах 1С.

Моя роль

Я проектирую и разрабатываю фреймворк, правила проекта и процесс, который связывает спецификацию, внешнее ревью, реализацию, проверку и приёмку. Подход к маршрутизации и оценке моделей также развивается на данных реальных задач.

Что работает

• работа по спецификации с явными сведениями о конкретном проекте 1С;
• независимая критика спецификации в отдельном окружении модели;
• model routing по классу, сложности и роли задачи;
• изолированная или параллельная реализация при безопасных границах;
• тестирование и проверка после реализации;
• приёмка человеком и журналирование данных задачи и модели.

Тестирование — уже работающая часть фреймворка, которая сейчас усиливается наиболее активно: повышаются повторяемость автоматических проверок и покрытие регрессий.

Результат

AI участвует во всём цикле разработки 1С, а не только генерирует код. Рабочий процесс разделяет архитектуру, реализацию, ревью, проверку и приёмку, сохраняя ответственность за поставленное изменение за человеком.

Фреймворк остаётся активным R&D: основной цикл уже работает, а тестирование, оценка маршрутизации и интеграция с окружениями продолжают развиваться.

Архитектура

Модели и инструменты могут меняться; устойчивой частью остаются границы процесса.

Зачем нужен отдельный процесс

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

Поэтому цепочки «задача → кодирующий агент → код» недостаточно для корпоративной разработки. Анализ, проверка проекта, реализация и приёмка — разные зоны ответственности, даже если в каждой участвует AI.

Спецификация и независимое ревью

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

Основной оркестратор создаёт спецификацию. Отдельное окружение агента — сейчас OpenCode с подходящей внешней моделью, например DeepSeek, — критикует лишнюю сложность, выдуманные требования, пробелы и расширение объёма работ. Рецензент не меняет проект молча: за итоговую редакцию отвечает основной оркестратор.

Model routing и сведения о проекте

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

Каждый проект 1С хранит устойчивые сведения в файлах проекта и переиспользуемых skills: версию конфигурации и платформы, ограничения разработки, используемые базы и инструменты, команды проверки, правила Git и критерии приёмки. Это не позволяет важным знаниям оставаться только в истории диалога.

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

Параллельная разработка

Независимые задачи могут выполняться в отдельных рабочих окружениях и тестовых базах. Параллельность включается только при безопасных зависимостях и границах записи; сама по себе она не является целью.

                       ┌─ Задача A → Агент A → Тестовая база A
Принятая спецификация ─┼─ Задача B → Агент B → Тестовая база B
                       └─ Задача C → Агент C → Тестовая база C
                                      ↓
                          ревью → проверка → приёмка

Тестирование и проверка

Проверка следует за реализацией и может объединять статические и структурные проверки, тесты конкретного проекта, проверку запуска и ревью. Глубина зависит от проекта и риска.

Сейчас усиливаются:

• автоматизированное покрытие и повторяемый запуск тестов;
• связь между агентами реализации и этапами проверки;
• проверки запуска конкретного проекта и поиск регрессий;
• более ясные подтверждения для приёмки изменений, созданных агентом.

«Агент закончил писать код» — не критерий приёмки.

Приёмка человеком и оценка

Люди разрешают действительно неоднозначные требования, принимают важные компромиссы и утверждают итоговое поведение. Автономность агента во время выполнения не передаёт ему ответственность за поставленную систему.

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

Пример рабочего процесса

1. Оркестратор проверяет ясность бизнес-задачи и запрашивает недостающие факты, а не выдумывает их.
2. Спецификация фиксирует объём, нужные объекты 1С, ограничения, критерии приёмки и способ проверки.
3. Независимый рецензент ищет неподтверждённые предположения, пропущенные случаи и лишние решения.
4. Оркестратор уточняет спецификацию и отвечает за итоговый проект.
5. Работа делится по границам зависимостей и направляется подходящим моделям или агентам.
6. Независимые изменения могут выполняться параллельно при изолированных окружениях и областях записи.
7. Объединённый результат проходит проверки и тесты, соответствующие проекту.
8. Человек проверяет итоговое поведение и принимает либо отклоняет его.
9. Выбор модели, данные выполнения и результат приёмки фиксируются для оценки.

Данные для оценки

Журнал может содержать класс и сложность задачи, роль агента, выбранную модель, рецензента, длительность, расход токенов и результат приёмки. Для маршрутизации также могут фиксироваться запасная модель, причина выбора и условия эскалации.

Практическая цель — сравнивать модели по принятым результатам, видеть классы задач, которые чаще не проходят ревью, и понимать, когда более сильная модель оправдывает стоимость. Механизм журналирования уже работает; долгосрочный анализ и автоматическая оптимизация маршрутизации ещё развиваются.

Что усиливается

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

Фреймворк развивается из реальной инженерной практики, а не из попытки заранее спроектировать законченную платформу.

Инженерные правила

• качество спецификации ограничивает качество реализации;
• независимая критика полезнее самопроверки исходной модели;
• model routing должен опираться на принятые результаты;
• автономной реализации нужна соразмерная проверка;
• устойчивые знания о проекте должны находиться в файлах и skills;
• приёмка человеком остаётся последней границей поставки.