- Series voir-pages
- page 12 / 26
- department 2 of 8
- stages implemented 0
AI development is not "the model writes code". It is a six-stage pipeline where an independent gate outranks speed, and a rollback is not an accident.
The development department in VOIR AI turns a task into working code along a recorded route: specification, code generation, tests, independent acceptance, deploy, monitoring. The key word is "recorded": every stage leaves an artifact you can inspect, not a retelling. The acceptance gate is run by a role that did not write the work — otherwise review degenerates into self-reporting. And when tests fail, the task goes back instead of riding to production "on trust". Below is the honest picture: what the department should do per the target architecture, what already works inside our own tooling (this very site is built that way), and how the department plugs into the AI CEO cycle.
VOIR AI product · zero stages implemented Marisova ecosystem · agents write code, the harness checks
Demonstration · development pipeline
One task, six stages, two outcomes
A pipeline where every task always reaches deploy looks perfect — and lies. The real design includes a second outcome: tests or the gate find a defect, and the task returns to the code stage with the problem described — production untouched. Switch scenarios to see both routes. The demonstration replays a pre-recorded script and is not connected to a live AI service; the stages are described in text in the "Six stages" section.
Structural numbers of this page: 6 pipeline stages, 2 demo scenarios, 8 departments in the architecture, 0 stages implemented in the product.
Pipeline · task → code → tests → gate → deploy → monitoring
Demonstration · pre-recorded scenarioSix stages Target architecture
Every stage leaves an artifact you can verify
"AI writes code" is not a process — it is an event. A process starts where each step has an input, an output and a recorded artifact: a spec, a commit, a harness report, a gate verdict, a deploy log, a monitoring report. Artifacts are not bureaucracy: independent acceptance checks claims against them, and the owner can see exactly where a task stalled. All six stages below are the product's target architecture; we know how they work from our own practice of building this site.
-
SPEC
Task specification
Target architectureThe task from the AI CEO is turned into a specification: which files are touched, what the acceptance criteria are, which boundaries must not be crossed. Without this stage, "make it nice" becomes a lottery: executor and requester diverge on the very wording of the result. The artifact is a written spec against which one can later say unambiguously whether the task is done.
Artifact: specification · input: AI CEO task · output: acceptance criteria
-
CODE
Code generation
Target architecture works in the ecosystemThe model writes code strictly against the spec: structure, styles, logic, edits to existing files — additively, deleting nothing without an explicit task. Every change is recorded as a commit with a human-readable message, so the diff can be read without running the code. Generating "one big file with no history" is forbidden in the architecture: an unverifiable change is not work, it is risk.
Artifact: commit + diff · input: spec · output: candidate for tests
-
TEST
Tests and checks
Target architecture works in the ecosystemAn automated harness checks everything a machine can check: no links lead nowhere, anchors exist, ru/en language pairs are in place, the SEO minimum is met, and screenshots at three widths show no overflowing text. A separate principle is the negative control: the check is fed a deliberately broken variant to prove it can actually turn red. A green report without a negative control is worth nothing.
Artifact: harness report + screenshots · input: commit · output: candidate for the gate
-
GATE
Independent acceptance
Target architecture works in the ecosystemThe keystone of the pipeline: a role that did not write the work verifies claims against actual state — disk, git history and live URLs, not the executor's report. The verdict is binary: VERIFIED, or back to CODE with the defect described. The executor never reviews itself — on principle: self-review always finds a way to stay green. This gate is what separates a pipeline from a pipeline imitation.
Artifact: acceptance verdict · input: harness report · output: deploy clearance or rollback
-
DEPLOY
Deployment
Target architecture works in the ecosystemPublishing happens only after the gate and only additively: back up the target directory, roll out new files, leave neighbouring pages alone, do not touch the server configuration. After the rollout, verification is mandatory: new URLs answer 200 and old ones keep answering 200. A deploy that is not followed by checking live addresses counts as incomplete — even if "the files were copied".
Artifact: deploy log + curl codes · input: VERIFIED verdict · output: live URL
-
WATCH
Monitoring after deploy
Target architecture works in the ecosystemThe work does not end at publishing: scheduled probes watch that live pages respond and that content does not degrade. Monitoring "when someone notices" is not monitoring — it is hope. The stage ends with a report to the owner: what was done, what the gate rejected, what broke afterwards, and which lessons flow into the next specification. Here the loop closes into the next run of the cycle.
Artifact: report to the owner · input: live URL · output: next-run loop
The acceptance gate · how it reads the work
The gate looks at the diff, not at the executor's report
The executor's report is a claim. The gate works with evidence: what actually changed on disk, what git shows, what live addresses answer. Below is exactly the diff a gate would like to see instead of beautiful promises: on the left, struck through, how tasks get closed without acceptance; on the right, how it looks in our practice.
The independence rule
Acceptance is performed by a role that did not write the work and has no stake in its green light. The same agent that wrote the code finds exactly as many problems as it is willing to admit.
The evidence rule
The gate accepts only what is verifiable: disk state, git history, HTTP codes of live addresses, screenshots. A retelling of "it all works" is not evidence and does not clear anything for deploy.
The rollback rule
Failing the gate is a normal outcome, not an accident: the task returns to CODE with the defect described, production untouched. A pipeline that never rejects anything either checks nothing or is lying.
The negative-control rule
Periodically the check is fed a deliberately broken variant. If the gate passes that too, the check does not work, and its green reports should be read as blank.
Deploy & monitoring Target architecture
Publishing is the middle of the work, not the end
In the architecture, deploy is an operation with guarantees, not file copying: first a backup of everything we touch, then an additive rollout — only new and changed files, no deletions on the server — then verification. Not only the new addresses are checked: neighbouring pages must keep answering, otherwise "shipped a feature" really means "broke somebody else's work". The deploy never touches the server configuration at all — that is a separate zone of human responsibility.
Backup before rollout
The target directory is copied before changes so every deploy is reversible. The rule is simple: no backup — no deploy. "The change is small" is not an exception.
Additivity
The rollout only adds and updates its own files. Live pages, other people's directories and the server configuration are not touched: someone else's work on a shared server is not ours to change.
Live-URL verification
After the rollout — HTTP codes: new pages answer 200, key neighbouring pages answer 200. "The file was copied" and "the page works" are two different facts.
Scheduled probes
Monitoring is run by a scheduler, not by human attention: regular checks of live pages, a log of triggers, escalation to the owner on degradation. Details live in the AI Operations department.
Statuses
Two status columns: the blueprint and our own workshop
The development department is a special case: we perform its stages daily with our own tooling while building this site. That is why the table is split in two. The left column is what is implemented in the VOIR AI product (right now, not a single pipeline stage). The right column is what already works inside the Marisova ecosystem. The right column must not be read as a promise to a client: our internal tools are not sold and not provided — they only prove the architecture is not invented but tried on ourselves.
| Function | In the VOIR AI product | In the Marisova ecosystem (internal) |
|---|---|---|
| Task specification (SPEC) | not implemented Target architecture: task → written acceptance criteria |
works Every development task for this site arrives as a file with requirements, boundaries and closing criteria. Internal tool, not a product |
| Code generation (CODE) | not implemented Target architecture: generation against the spec with a journal |
works An AI agent writes this site's code in a development session; every change is a commit with a message in git. All published ai.voir.su pages were made this way |
| Automated checks (TEST) | not implemented Target architecture: a single product harness |
works A local harness checks links, anchors, language pairs and the SEO minimum; Playwright takes screenshots at 1280/768/375; negative controls are practiced |
| Independent acceptance (GATE) | not implemented Target architecture: verdict of a role that did not do the work |
works The acceptance practice exists: claims are checked against disk, git and live URLs by a separate review, not by the executor's report. Not a product |
| Deployment (DEPLOY) | not implemented Target architecture: publishing as part of the product |
works This site's deploy script: docroot backup, additive rsync, then HTTP-code checks of new and neighbouring pages. The nginx config is never touched |
| Monitoring (WATCH) | not implemented Target architecture: probes, thresholds, recorded reaction |
works A scheduler runs probes of live pages on a schedule; for this site, live URLs are re-checked after every publish. Our own tooling |
| The interactive pipeline demo on this page | Demonstration A recorded scenario in a browser script |
not a live service Not connected to an AI service; executes and collects nothing — both scenarios are written in advance |
| Pipeline as a client service | not implemented Target architecture: a client runs their own development pipeline |
does not exist No clients, product not launched; internal ecosystem tools are not handed over to a client |
Link to the AI CEO
The development department is the executor inside the AI CEO cycle
The development pipeline does not live on its own: it is embedded in the AI CEO cycle — task setting, analysis and allocation, execution, independent acceptance, report. Development is the execution step: it receives a specification from the CEO loop and returns the gate verdict and the run report. Below are the five steps of the cycle and the department's role in each.
-
step 1
Task setting
The owner formulates a task to the AI CEO; the CEO turns it into an assignment to the department with boundaries and criteria.
Development receives: a draft spec (SPEC) -
step 2
Analysis & allocation
The CEO loop decides which task is development work and assigns it here — not to marketing or HR.
Development receives: a prioritised assignment -
step 3 · the department works here
Execution
Our pipeline: SPEC → CODE → TEST. Every stage leaves an artifact; failing tests return the task to CODE, not upstairs.
Development returns: commit, diff, harness report -
step 4
Independent acceptance
The acceptance role verifies claims against disk, git and live URLs. Our GATE is the technical part of that acceptance; the verdict goes back to the CEO loop.
Development returns: VERIFIED / REJECTED verdict -
step 5
Report to the owner
The CEO loop condenses the run into a report; development's lessons (what was rejected, what broke) flow into the next specification.
Development receives: tasks of the next run
Touchpoints with other departments: AI Operations provides playbooks and the monitor bus for WATCH; AI Research supplies data for specifications; the AI CEO sets and allocates tasks. How roles are built inside — see the AI Agents page.
Boundaries
What this page does NOT claim
Honesty is a requirement of the project's owner, not a marketing move. We fix the boundaries explicitly so they cannot be read two ways.
- The product does not exist. None of the six pipeline stages is implemented in the VOIR AI code. Everything above is target architecture: the blueprint we are building from.
- No clients, no deployments. There are no case studies on this page because there are no cases. We do not invent companies, metrics or testimonials.
- The demo is pre-recorded. The pipeline above replays a prepared scenario in the browser and is not connected to a live AI service: it executes nothing, deploys nothing, collects nothing.
- Internal tools ≠ product. The right column of the status table describes our own Marisova-ecosystem tooling. It is not sold, not handed to a client, and does not automatically become a product capability.
- No dead buttons. Every interactive element on this page is a demo-scenario toggle, an anchor, or a link to a real page. There are no data-collection forms here.
Questions & answers
Frequent questions about the development department
Is the VOIR AI development department already running?
As a VOIR AI product — no. All six pipeline stages on this page describe the target architecture: none of them is implemented in the product's code. The demonstration replays a pre-recorded scenario and is not connected to a live AI service. Separately, the Marisova ecosystem exists, where agent code generation, a QA harness, independent acceptance and deploy scripts are used by us to build this very site. They are not a VOIR AI product and are not provided to clients.
Who writes the code — the model or a human?
In our own practice, an AI agent generates the code in a development session, while the human owner sets the task, the boundaries and accepts the result. That is exactly why the pipeline has a separate independent acceptance gate: the executor never reviews its own work — claims are verified against disk, git history and live URLs.
What happens when tests fail?
The task never reaches deploy: the gate returns it to the code station with a description of the defect, and production stays untouched. This scenario is shown in the demo as the second switchable option — "gate rollback". Shipping a defect and apologising afterwards is not part of the architecture.
Is post-deploy monitoring a live service?
In the VOIR AI product — no, that is target architecture. Inside the Marisova ecosystem we run a scheduler with scheduled probes and an E2E audit of the live site; for this website the post-publish check is HTTP codes of neighbouring pages plus screenshots at three widths. These are our internal tools; they are not handed to clients.
Can I buy this development department today?
No. The VOIR AI product is in development and has no clients. This page describes the architecture we are building towards, and honestly separates what is designed, what already works as our internal tooling, and what does not exist in any form. The tiers on the pricing page are a launch plan, not an active offer.
How is development different from AI Operations?
Operations runs the company's repeating processes (playbook → plan → execution → control → report), while development turns a task into new working code (spec → code → tests → gate → deploy → monitoring). In the target architecture these are different pipelines with different artifacts; they share the principle of independent control. Details on the AI Operations page.
Watch the build — honestly
The VOIR AI product is in development and has no clients. We are not collecting "waitlist" sign-ups through this page: write to us directly and we will tell you what stage the pipeline is at right now. See the overall system architecture on the AI Operating System page, the departments on the home page, and launch plans on the pricing page.