Request a demo

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 ready · tag v0.1.0-mvp · as of August 13, 2026

Why small 1C modifications cost disproportionately much

  1. 01

    The programmer queue

    A “stock by warehouses” report waits its week alongside big tasks.

  2. 02

    Specification costs more than code

    Half the time goes into finding out what is actually needed — and into rework after the first version.

  3. 03

    Entry threshold

    Small business has no 1C developer at all, and contractors do not take every small task.

  4. 04

    Generic AI does not help

    Chatbot code knows nothing about the specific configuration and is never compiler-checked — a human still finishes it.

  5. 05

    Configuration knowledge does not scale

    Every base is modified differently; without its structure, advice stays generic.

  6. 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

  1. 01

    Description

    The user states the task in their own words

  2. 02

    Clarification

    The system asks questions and fixes the requirements

  3. 03

    Generation

    Code is written in the 1C built-in language

  4. 04

    Compilation

    Built on the client’s real base

  5. 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), an external data processor (.epf) or a configuration extension.

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

Eight providers, including Russian and fully local ones.

Foreign cloud

Claude, OpenAI, DeepSeek, Kimi, Zhipu — 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.

  1. 01

    Selection and switching live at the router level: the provider changes in settings, without code edits.

  2. 02

    Automatic failover to a backup provider when the primary is unavailable.

  3. 03

    Request cost is tracked per provider — 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 fresh capability: a skill knows the contents of an entire configuration without storing it in the prompt — for the standard “Managing our firm” that is 4,278 objects.

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.

MechanismHow it works
PlansMonthly token quota, request-rate limit, number of custom skills, level-based skill access
Wallet & overdraftQuota exhausted — charges go to the balance if the plan allows it
One-off purchasesTemporary access to a single skill for a fixed amount
Guest modeTrial access with a hard limit and no overdraft
Cost trackingRates per provider and model — margin computed as fact
PaymentsA 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 ERP — start without exporting your own base

Risks and the near-term plan — what is honestly not closed at MVP

  • Validation on a live 1C — the main risk. Designer keys and parts of the format parsing were written from documentation, without access to a real installation. Marked in code; requires a pilot. Some guesses are already resolved by fact: configuration and extension export formats were parsed from real exports, and base-plus-extension merging is pinned by tests.
  • Internal review defects are closed. Ten confirmed findings on pipeline reliability under failures were selected from a multi-agent run — all resolved; a false assumption in the extension branch was rolled back instead of being masked.
  • Extension (.cfe) builds — an open item. Reports and data processors pass the pipeline end-to-end; for extensions, the export tree on the agent side remains to be built. A separate task before the pilot.
  • Code generation quality is not yet measured quantitatively. A set of real tasks and the first-pass build success rate are needed — that is the product’s main metric.
  • Next steps: close the extension branch → pilot on a real base → measure the success rate → plans and sales.

Summary

Market
Mass demand for small 1C modifications among companies without their own developer
Product
A ready file for the specific base, compiler-checked — not chatbot text
Protection
Data stays with the client; Russian and local models are possible
Stage
The MVP is fully built and working, from chat to artifact
Economics
Plans, quotas, overdraft and per-provider costs already in the system
Next step
A pilot on a real base and measuring the first-pass success rate

Discuss the pilot and metrics

Request a demo Home

Describe the task in words — the file is compiled on your own base Request a demo