For investors and executives
AI Dev Assistant in detail
1C modifications from a task description — without a programmer in the queue. The user describes the task in words; the system clarifies requirements, writes code, compiles it on the client’s real base and delivers a ready file.
Status: MVP running on live orders · tag v0.1.0-mvp · as of August 28, 2026
Why small 1C modifications cost disproportionately much
- 01
The programmer queue
A “stock by warehouses” report waits its week alongside big tasks.
- 02
Specification costs more than code
Half the time goes into finding out what is actually needed — and into rework after the first version.
- 03
Entry threshold
Small business has no 1C developer at all, and contractors do not take every small task.
- 04
Generic AI does not help
Chatbot code knows nothing about the specific configuration and is never compiler-checked — a human still finishes it.
- 05
Configuration knowledge does not scale
Every base is modified differently; without its structure, advice stays generic.
- 06
Data cannot leave
Exporting the configuration and business logic to an external service is unacceptable for many.
Full cycle — from a Russian sentence to a file that opens in 1C
- 01
Description
The user states the task in their own words
- 02
Clarification
The system asks questions and fixes the requirements
- 03
Generation
Code is written in the 1C built-in language
- 04
Compilation
Built on the client’s real base
- 05
Result
A ready report, data processor or extension
A compile error is never shown to the user — it returns into the loop and the code is regenerated automatically.
The result is a file, not text: an external report (.erf) or an external data processor (.epf), including print forms registered in BSP. Configuration extension (.cfe) builds are not running yet — the only open delivery branch.
Three things a generic AI assistant does not have
Checked by the 1C compiler
The artifact is built by a real Designer against the client’s real configuration. Not “probably working” code.
Knows the specific configuration
The system works with the object set of this exact base — including modifications and installed extensions no standard configuration has.
The configuration never leaves the perimeter
Compilation runs on the client’s machine. Only the structure goes out — object and attribute names, without module texts.
Architecture: 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
Client perimeter (Windows)
- Launches the Designer: structure export, build, check
- they stay on your machine
- Only the configuration structure and the build result go out
- Installs as a regular Windows service, registered with a one-time token
The agent polls the service itself — no inbound ports to open. The backend never talks to 1C directly; the agent never talks to the AI.
Independent from any single AI vendor
Ten providers, including Russian and fully local ones.
Foreign cloud
Claude, OpenAI, DeepSeek, Kimi, Zhipu, Qwen — maximum code generation quality.
Russian
YandexGPT and GigaChat — when data must not leave the country’s perimeter.
Local
Ollama and LM Studio — the model runs on the client’s hardware, no internet needed at all.
- 01
The user chooses a mode, not a vendor — auto, cloud or local only: model names are not their concern.
- 02
Failover to a backup provider is enabled on all three pipeline steps — one vendor being down no longer fails the task.
- 03
Cost is recorded per answer: provider, model and price — unit economics visible per model.
Skills — what turns a chat into a tool
Disciplinary presets: role, rules, context budget, plan-level access.
Ready-made skills
A 1C consultant, a BSL code reviewer, a Vanessa Automation test-scenario generator.
Custom skills
Users create their own through a step-by-step wizard; the count depends on the plan.
Paid access
A skill can open on a higher plan or be bought as a one-off temporary access.
A skill knows the contents of an entire configuration without storing it in the prompt — for the standard “Managing our firm” that is 8,655 objects, including accounting and calculation registers.
Contents are loaded per question against a budget: the object list plus full attributes of the ones asked about. The consultation runs against the client’s real base, and request cost does not grow with configuration size.
Monetization is built in, not postponed
Everything listed works in the MVP.
| Mechanism | How it works |
|---|---|
| Plans | Monthly token quota, request-rate limit, number of custom skills, level-based skill access |
| Wallet & overdraft | Quota exhausted — charges go to the balance if the plan allows it |
| One-off purchases | Temporary access to a single skill for a fixed amount |
| Guest mode | Trial access with a hard limit and no overdraft |
| Cost tracking | Rates per provider and model — margin computed as fact |
| Payments | A payment gateway is connected; without keys a stub handles testing |
Not a slide prototype — a working system of four parts
Backend
Streaming chat, provider routing, skills, billing, task pipeline
Account
Tasks, artifacts, files, custom skills, balance and operation history
Admin panel
Users, plans, providers and rates, skills, billing oversight
The 1C agent
A Windows service: base and extension structure export, build, result delivery
Desktop tool
ConfigExplorer — browsing exports and building files manually
Standard library
Reference structures of “Managing our firm” 3.0, “Accounting” 3.0 and “Payroll & HR” 3.1 — start without exporting your own base
Validated on other people’s tasks, not our own examples
A corpus of verbatim task texts from two 1C freelance exchanges, and live pipeline runs.
- 01
The live run
Nine orders through the deployed service: requirement clarification passed on 8 out of 8 supported configurations.
- 02
The bottleneck is not code quality
Almost all failures were “provider unavailable”, not invalid code. Hence the backup provider on all pipeline steps.
- 03
Defects were closed the same day
That is how pre-compilation query validation and the refusal to deliver stub reports appeared.
Risks and the near-term plan — what is honestly not closed at MVP
- Extension (.cfe) builds — the main open item. Reports and data processors pass the pipeline end-to-end; extensions lack an export-tree builder. And this is the most demanded category: 15 of the 34 corpus tasks.
- The build success rate has only been measured on a sample: nine orders, three compilations out of seven on supported configurations. The sample is small; a regulated measurement runs on a frozen task set.
- Parts of the 1C work are not fully verified: export formats, composition schemas and spreadsheet layouts were parsed from real samples and pinned by tests; parsing the Designer log on a live build failure did not work.
- The support scope is deliberately narrowed: ERP is out of scope — a live ERP is almost never standard. The business model is not confirmed by numbers: acquisition cost, churn and unit economics are unmeasured.
- Next steps: extension branch → success-rate measurement on the frozen set → client pilot → plans and sales.