The pilot, step by step
You describe the task, answer clarifications, confirm the specification and accept the result. The specification is half the result, so it gets its own stage.
- Task
The task
You describe the task in your own words.
- Clarify
Clarification
The system asks questions: which period, which breakdowns, what to do with returns, whether group totals are needed.
- Approve
Approval
You see the final specification before any code generation begins.
- Build
The build
Code is written and built with 1C tooling on your base.
- Check
Your check
You review the result.
- Done
Done
You take the file.
If the build fails, the service retries the fix within the agreed limit. If the task is not completed — you see the status and the next step.
Not happy with the result? Say what is wrong — the task repeats with your remarks.
The specification
The system asks first, then acts
Clarifying questions
Questions are asked against your configuration — the system already knows which objects and attributes it has.
Specification check
Requirements are re-read in a separate pass: no contradictions, no gaps.
Approval with you
The final specification is shown to you before generation starts.
Result quality
Why the result works instead of “looking right”
The same tool a programmer uses
The code is built with 1C tooling on your base. Launch and business result are verified on a base copy against agreed examples.
The exact composition of your configuration
Names of catalogs, documents, registers and their attributes come from your base; installed extensions are counted together with it — borrowed objects and added attributes included.
Errors return into the loop
The code is rewritten based on the Designer's message — automatically, within the agreed iteration limit.
The query is validated before compilation
Ambiguous aliases and non-existent sources are rejected against your base composition upfront.
Verified by execution, not only by the build
A build does not execute the query: in the Oct 10 review, three of five “compiled” reports turned out to be wrong. So since Oct 11–14 the report is actually formed on a demo base before delivery, and the 1C error is condensed and sent back to the model for regeneration.
No stub reports are delivered
A report whose columns are filled with stubs instead of data looks ready but is not — it is refused.
Data security
What goes to the service and what does not — line by line
| What | Leaves your perimeter |
|---|---|
| Configuration structure: object and attribute names | Yeswithout it there is nothing to write code against |
| Module texts, your business logic | Nothey stay on your machine |
| Base data: stock, documents, contractors, amounts | Nothe service never connects to the base |
| The task description and clarification thread | Yesthis is the task itself |
| Generated code and the compiled file | Yesthey are the result of the work |
| Extension: build verification | Noruns on our demo base of the same standard configuration |
Reports and processors are compiled on your machine with your own Designer — the service has no access to the base. The task description and structure go to a cloud model (in production: Qwen and DeepSeek); if that is unacceptable, say so upfront — it is settled before the pilot.
For your IT team
Strict separation: the cloud thinks, the on-site agent executes
Service cloud
- Chat, requirement clarification, code generation
- Routing between AI providers
- Task state, billing, history
- Account and admin panel
Your perimeter (Windows machine)
- The agent — a Windows service on the machine running the 1C platform
- Launches the Designer: structure export, build, check
- Polls the service itself — no inbound ports to open
- The access key is stored using Windows protection mechanisms
Channel separation: the backend never talks to 1C directly, and the agent never talks to the AI. For extensions on a standard configuration no agent is needed on your side: verification runs on our demo base.
What we need from you
Connection follows an environment check
Preparation takes one working day. Requirements: Windows, a compatible 1C platform and agreed access — no separate server needed; any machine already running 1C will do. No changes to your configuration — everything works through external files.
What is connected and what actually runs today
If data must not go to external AI
In production today
Cloud Qwen and DeepSeek. The mode — auto / cloud / local only — exists in the service; you do not need to know model names.
Russian models
YandexGPT and GigaChat are connected to the service; not used in the main flow right now.
Local models
Ollama and LM Studio are connected. On our hardware generation came out at ~1 token/s, so we rejected local generation for now.
If your rules forbid cloud models entirely — that condition is settled before the pilot: on our hardware the local variant is not viable yet.
Worth knowing in advance
- Reports, processors and print forms are fully built and were proven in the team's internal tests; extensions and the AI-developer are in development.
- Complex tasks with non-standard logic still require a programmer — the system targets routine. A standard report, a selection, a simple processor — yes; reworking accounting methodology — no.
- Working with the Designer requires the base not to be exclusively locked at that moment.
- The first pilot runs on a test copy of the base — a condition, not a suggestion.
- Extensions (.cfe) are already delivered to customers on real requests; they are built and verified on our demo base, and the success rate is unmeasured. An extension with its own catalogs rebuilds some of the standard tables — it is installed like a configuration update, in a maintenance window. Whether an extension can be applied is verified for your platform, compatibility mode and security profile.
- The execution check does not cover processors yet; on the Trade 11 demo base it failed to start on Oct 14 — the cause is being investigated.
- Modifying an existing report is partial for now: the system sees its composition and fields but cannot yet rewrite a finished composition schema.
Questions
Frequently asked questions
What does AI Dev Assistant do?
A project that prepares external reports, data processors and print forms for 1C from a task described in words. At the current stage we propose discussing a pilot: check compatibility, agree requirements and evaluate the result on a base copy.
Does it replace a 1C programmer?
Describing the task requires no programming. Connecting the agent, configuring access and checking the effect on the books needs a responsible specialist. Complex changes to accounting logic are assessed separately.
Which data is transferred to the cloud?
By the stated architecture: the task spec, the clarification thread, selected metadata, the generated code and the work results. Base records and source modules are intended to stay local; the exact transfer set is agreed and verified before connection.
Does a successful build mean a correct report?
No. After the build, launch, permissions, filters, totals and control examples must be verified. Acceptance criteria are agreed before the pilot starts.
Can ERP or a modified base be connected?
ERP is outside the stated scope of the current pilot. A modified configuration and installed extensions first need a separate compatibility assessment.
How much does it cost?
No approved public pricing yet. After task assessment, the scope, cost, timeline, iteration limit and stop conditions are agreed. A trial chat is not the same as pipeline execution.
Let's discuss your task
Demo — environment check and setup — a pilot task on a test copy of your base — your decision.