Agentic Software Development for 1C

Summary

1c-lite is a working R&D framework for specification-driven 1C development. It combines analysis, independent specification review, model routing, parallel implementation, verification and human acceptance.

The goal is not to maximize generated code. It is to make AI-assisted delivery more predictable, reviewable and economically measurable in real 1C projects.

My role

I design and develop the framework, its project conventions and the workflow connecting specification, external review, implementation, verification and acceptance. I also evolve the routing and evaluation approach from evidence produced by real tasks.

What works

• specification-driven work with project-specific 1C context;
• independent specification critique through a separate model environment;
• model routing by task class, complexity and role;
• isolated or parallel implementation where task boundaries allow it;
• testing and verification after implementation;
• human acceptance and model/task evaluation logging.

Testing is already a working part of the framework and is currently being strengthened most actively through more repeatable automation and regression coverage.

Outcome

AI can participate across the 1C delivery lifecycle rather than only generating code. The operational loop separates architecture, implementation, review, verification and acceptance, while keeping responsibility for the delivered change with a person.

The framework remains active R&D; the core loop is operational, while testing, routing evaluation and environment integration continue to evolve.

Architecture

Models and tools may change; the workflow boundaries are the durable part.

Why the workflow is necessary

Modern coding agents can write useful 1C code when a task is clear. Reliability is usually lost around generation: requirements are incomplete, a plausible specification grows unnecessary architecture, one model validates its own assumptions, verification is too shallow, or there is no record of which model was effective for the task.

A simple “task → coding agent → code” path therefore does not cover enterprise delivery. Analysis, design review, implementation and acceptance are different responsibilities, even when AI participates in each of them.

Specification and independent review

Coding agents are useful when a task is clear. The harder failures arise from incomplete requirements, speculative architecture, missing acceptance criteria and a model defending its own assumptions.

The primary orchestrator creates the specification. A separate agent environment—currently OpenCode with a suitable external reviewer such as DeepSeek—critiques unnecessary complexity, invented requirements, gaps and scope drift. The reviewer does not silently repair the design; the primary orchestrator remains responsible for the revision.

Model routing and project context

Stronger reasoning models are reserved for ambiguity, architecture and escalation. Clear implementation, review and verification tasks can use different specialized models. Routing is an engineering decision rather than one global default.

Each 1C project supplies durable context in project files and reusable skills: configuration and platform details, development constraints, relevant databases and tools, validation commands, Git workflow and acceptance requirements. This avoids depending on conversational memory.

Typical project instructions also identify modification boundaries, build or export commands and the evidence required for acceptance. They are reviewed with the code and remain available to later tasks.

Parallel development

Independent tasks can use separate work environments and test databases. Parallelism is enabled only when dependencies and write boundaries make it safe; it is not a goal by itself.

                         ┌─ Task A → Agent A → Test DB A
Approved specification ─┼─ Task B → Agent B → Test DB B
                         └─ Task C → Agent C → Test DB C
                                      ↓
                         review → verification → acceptance

Testing and verification

Verification follows implementation and can combine static or structural checks, project-specific tests, runtime smoke checks and review. The exact depth depends on the project and risk.

Current development strengthens:

• automated test coverage and repeatable execution;
• integration between implementation agents and verification steps;
• project-specific smoke tests and regression detection;
• clearer acceptance evidence for agent-produced changes.

“The agent finished coding” is not an acceptance criterion.

Human acceptance and evaluation

People resolve genuinely ambiguous requirements, accept important trade-offs and approve the final behavior. Agent autonomy during execution does not transfer responsibility for the delivered system.

The workflow records task class, model and reviewer choice, execution data and acceptance result. This supports later comparison of model quality and cost by task type without claiming that routing is already automatically optimized.

Representative workflow

1. The orchestrator checks whether the business request is clear and asks for missing facts instead of inventing them.
2. A specification records scope, relevant 1C objects, constraints, acceptance criteria and the verification strategy.
3. An independent reviewer critiques unsupported assumptions, missing cases and unnecessary design.
4. The orchestrator revises the specification and remains responsible for the final design.
5. Work is decomposed along dependency boundaries and routed to suitable models or agents.
6. Independent changes may run in parallel when their environments and write scopes are isolated.
7. The combined result passes through the checks and tests appropriate to the project.
8. A person reviews the final behavior and accepts or rejects it.
9. Model choice, execution data and the acceptance result are recorded for evaluation.

Evaluation data

The log can include the task class and complexity, agent role, selected model, reviewer, duration, token use and acceptance result. Routing metadata can also record a fallback, the reason for selection and escalation criteria.

The purpose is practical: compare models on accepted outcomes, understand which task classes fail review and decide when a stronger model is worth its cost. The logging mechanism exists today; longer-term analysis and automatic routing optimization are still evolving.

What is being strengthened

• more repeatable automated verification and regression coverage;
• enough accepted-task data to compare routing decisions;
• less manual coordination between specification, review, implementation and verification;
• easier adaptation to different client projects, databases and development environments.

The framework evolves from use in real engineering work rather than from an attempt to design a complete platform upfront.

Engineering principles

• specification quality constrains implementation quality;
• independent critique is more useful than one model checking its own assumptions;
• routing should be informed by accepted-task evidence;
• autonomous implementation requires proportionate verification;
• durable project knowledge belongs in project files and skills;
• human acceptance remains the final delivery boundary.