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
Requirements: Windows, a compatible 1C platform and agreed access. 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 built and verified on our demo base but have not been delivered to clients. 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.