Vibe coding in 1C: an agent, a configuration dump and checking the result

Vibe coding in 1C runs into a simple problem: an agent works with files, while the configuration lives in an information base. Once you build a bridge between them, a terminal agent such as Claude Code takes over the routine: standard data processors, queries, reports, module refactoring. Below is a four-step scheme, rules for the agent and an honest list of places where it is better not to let it in.

The whole scheme

1. The configuration is dumped to files (XML and .bsl modules) and put in git.
2. The agent runs in the terminal in the dump directory and edits modules.
3. The agent gets metadata and reference information from the files or through an MCP server.
4. The result is loaded back into a test base and checked in the Configurator. Only after that does it go to the production base.

The main rule: the production base is never available to the agent. You work in a copy or in a developer's base.

Step 1. Dump to files

There are three ways:

• The Configurator. The configuration menu has a dump to files item ("Dump configuration to files"; the exact location depends on the platform version).
• Batch mode. The Configurator has command-line parameters for dumping to and loading from files, for example DumpConfigToFiles and LoadConfigFromFiles. Check the exact syntax and keys against the documentation of your platform version; we do not give them here so as not to mislead you.
• EDT. If you already work in 1C:Enterprise Development Tools, the project is stored as files anyway and no preparation step is needed.

Put the dump under git and make the first commit before any agent edits. That is your insurance: every change shows in git diff and rolls back with one command.

Step 2. The agent in the terminal

Claude Code needs three variables (details in the docs↗):

export ANTHROPIC_BASE_URL=https://api.zukko.pro
export ANTHROPIC_AUTH_TOKEN=fetch_your_key
export ANTHROPIC_MODEL=claude-sonnet-5-5

Note that the address has no /v1 and the variable is exactly ANTHROPIC_AUTH_TOKEN. Then you run claude in the dump directory.

For complex refactoring you can switch to claude-opus-5-5; for routine work claude-sonnet-5-5 is enough. That is a decision about price and task: test it on your own code.

Step 3. Rules for the agent in CLAUDE.md

The agent does not know your configuration or conventions. Put a CLAUDE.md file in the root of the dump and describe them. An example (fill in your own points):

## Project rules (1C)
- Code language: the built-in 1C language (BSL). State the compilation directives &AtServer, &AtClient explicitly.
- Do not change standard modules and objects under vendor support unless directly told to.
- Write queries as query text with parameters, no string concatenation.
- No queries inside loops; collect the data with a single query first.
- Procedure names: in Russian, with our solution's prefix.
- After edits, list the changed files and what to check in the Configurator.
- Do not invent platform methods. If you are not sure a method exists, say so.

The last point is especially important: a model can confidently invent a platform method or property. More on such files in the post on CLAUDE.md↗.

Step 4. MCP for metadata

An MCP server is a program that gives the agent extra tools. For 1C there are two options:

• Ready community servers. They exist, but their quality and security vary. Before connecting one, read its code and permissions: the server must not write to the production base or send data out.
• Your own small server. It reads your dump and answers questions like "what attributes does this catalog have", "where is this register used", "which procedures call this function". XML parsing and text search are enough for that.

Connecting MCP in Claude Code is described in the post on MCP servers↗. Start without MCP: often the dump itself is enough, since the agent can search files anyway.

What to check after the agent

A working cycle for one task:

1. Ask the agent to change one module, not "the whole report".
2. Look at git diff. Read every line like someone else's pull request.
3. Load the changes into a test base.
4. In the Configurator run the syntax check and the configuration check. Copy errors back to the agent.
5. Run the scenario by hand: posting a document, building a report, edge-case data.
6. For static analysis you can add a third-party BSL linter (for example the open-source BSL Language Server); read its documentation before use.

Where the agent helps and where it is risky

Helpful:

• standard procedures and functions, query texts, handling arrays and value tables;
• refactoring: extracting repeated code, renaming, bringing code to a standard;
• comments and procedure descriptions;
• drafts of data processors and reports that you will refine anyway.

Risky:

• document posting, calculations, accumulation registers and anything that affects accounting: a mistake costs money;
• updating standard configurations under support;
• access rights and the role model;
• any operation on the production base.

Do not send real customer and employee data in requests to the model: the code goes to the model provider, and base data must not end up there.

What a session costs

An assumption for a small change: 30 calls in an agent session on claude-sonnet-5-5 (0.4 / 2, cache read 0.05, write 0.5), Anthropic format. Fresh input 150,000 tokens, cache read 600,000, cache write 100,000, output 30,000.

150,000 × 0.4 / 1,000,000 = $0.06 600,000 × 0.05 / 1,000,000 = $0.03 100,000 × 0.5 / 1,000,000 = $0.05 30,000 × 2 / 1,000,000 = $0.06 Total $0.20.

This is an order of magnitude; the real price is shown on the "Usage" page of the dashboard. Prices as of 18 October 2026, current ones: GET https://api.zukko.pro/v1/models. Create a key in the dashboard↗. If you need not agents but integrating 1C with a neural network over HTTP, see the post on integrating 1C with a neural network↗.

FAQ

Can I write 1C code without dumping to files?

You can copy modules into a chat by hand, but the agent loses the project context. A dump to files gives it search across the whole configuration.

Does the model know the built-in 1C language?

To varying degrees, and it may invent platform methods. That is why the rules tell it not to invent methods, and the result goes through the Configurator's syntax check.

Do I need MCP?

Not at first. Start with files and CLAUDE.md. Add MCP when the agent regularly misses on metadata.

Is it safe to give the agent access to the base?

No, never to the production one. Work with the dump and a test base, and apply changes to production only after a manual check.