---
title: "About"
description: "Gabion began as a tool for reducing the review load on AI-written code and grew into a production pipeline with an architecture, modules, checks, and MCP."
canonical: "https://gabion.dev/about"
site_index: "https://gabion.dev/llms.txt"
---

> Index of this site: <https://gabion.dev/llms.txt>. Every page in one file: <https://gabion.dev/llms-full.txt>.

The history of the technology

# Gabion appeared when the speed of code generation exceeded the capacity to review it.

AI assistants let developers produce more code in less time. But code that looks professional is not necessarily built on a correct understanding of the architecture, the library, or the security boundary.

Gabion began as a tool for a CTO who needed to control this new class of risk. It then grew into a development environment for human and AI collaboration.

[How Gabion Works](https://gabion.dev/how-it-works)

[Gabion Technology](https://gabion.dev/technology)

## The AI started writing code faster. Review did not scale with it.

An ordinary error is visible: the code does not compile, a test fails, a feature does not work. Far more dangerous is a result that meets the explicit requirement and looks convincing, but violates an implicit assumption of the system.

For example, the AI can:

- apply a familiar pattern in an unsuitable lifecycle;
- use a library without understanding its non-obvious behavior;
- implement the ordinary scenario correctly, but miss an access boundary;
- duplicate a feature for which the project already has a mandatory component;
- connect parts of the system in a way that makes the next change harder;
- add a locally sensible solution that is incompatible with the rest of the architecture.

The tidier such code looks, the more time an experienced reviewer needs. It is necessary to check not only the line, but every assumption the model built the solution on.

When the AI is used occasionally, this work can still be done by hand. When it takes part in most changes, the team's capacity to generate code starts growing faster than the CTO's capacity to confirm that it is correct.

The new bottleneck is not the speed of writing code, but the capacity for meaningful review.

## Take the repeatable part of review off the CTO.

Gabion was not conceived as a way to replace the technical lead. Its first task was more practical: to move repeatable architectural decisions out of manual review and into the production pipeline.

### If a rule can be defined and checked in advance, the CTO should not have to, every time

- recall where it is documented;
- look for every place it might be circumvented;
- explain it to a new model;
- review yet another independent implementation;
- prove after an incident that the rule existed at all.

### Instead, Gabion has to

- provide the permitted path;
- make the wrong path visible or unavailable;
- return specific diagnostics;
- give the AI the means to correct the violation;
- show the human what happened;
- leave the CTO the decisions that genuinely require engineering judgment.

The architecture then stops being only the knowledge of the most experienced person in the room.

## The problem was not the absence of a model.

The market was already producing ever stronger assistants, editors with AI, and autonomous agents. A new model could improve reasoning and reduce the number of errors, but it did not change the fundamental design: it still had to reconstruct the rules of every project each time.

So Gabion did not become an LLM of its own or a wrapper around a single provider. It took a different place — between the intent of the human, the work of the model, and the codebase of the product.

Gabion answers not the question "Which model will write the best code?", but these:

- which decisions the model should be allowed to make at all;
- which components have to be ready in advance;
- which rules can be checked without another probabilistic judgment;
- what context the AI needs for a specific action;
- how to return an error in a form usable for the next attempt;
- how to preserve the architecture when the model changes.

Gabion does not make the model smarter. It makes the environment less dependent on how smart the model is in any single attempt.

## The production pipeline is designed for whoever works with it.

Most development tools were built for a human, and the AI later gained access to them through text, a terminal, or interface automation.

Gabion treats an AI assistant or agent as the primary consumer of the technical interface from the start. The human remains the owner of the goal and the decision, but does not have to translate every action of the model into the language of the tool by hand.

An environment for the AI has to provide:

- limited and well-described operations;
- machine-readable contracts;
- context relevant to the current task;
- stable rule identifiers;
- structured diagnostics;
- an explicit distinction between an error, a warning, and a human decision;
- a repeatable result from a tool call;
- the means to correct a change and check it again.

For this, Gabion uses its own MCP server. Information for the human is presented separately in the browser, so that the user sees the state of the process without reading the internal dialogue of the model.

[The Workflow of Human, AI, and Gabion](https://gabion.dev/how-it-works)

## Freedom of choice is useful until every choice becomes a new risk.

If the model chooses the language, the framework, the library, and the pattern for every feature on its own, the project gradually becomes a collection of locally sensible decisions with incompatible assumptions.

Gabion uses a coherent stack of Java, Spring, PostgreSQL, and TypeScript. These are mature technologies with a large body of high-quality code and stable practices represented in the training data of current models.

A stack agreed in advance makes it possible to:

- reuse modules;
- check architectural properties;
- manage compatible versions;
- give the AI more definite context;
- compare the quality of different models on the same tasks;
- hand over the result as a standard project;
- develop the production pipeline across client systems.

Gabion does not claim that this stack is the only correct one for any software product. It chooses determinacy where unlimited variability obstructs reliable collaboration between a human and an AI.

## Every relieved problem opened the next dependency.

Checking an individual pattern is not enough if the project can circumvent it another way. Setting a structure is not enough if the model does not know which tool performs the permitted operation. Providing a tool is not enough if the human cannot see what the agent did.

So connected parts began to appear around the original task:

1. a coherent technology stack;
2. an architectural structure for the project;
3. ready critical modules;
4. deterministic checks;
5. an interface for the AI through MCP;
6. diagnostics usable for a second attempt;
7. a browser interface for the human;
8. installation into different working environments;
9. licensing and access control;
10. an independent build of the resulting application.

That is how an internal tool for reducing the load on a CTO became a production pipeline inside which a complete system can be built and developed.

## Decisions the product does not change for the sake of convenient marketing

### An environment, not a model

Gabion works around a chosen LLM and does not migrate the architecture of the product when the provider changes.

### Check where checking is possible

A critical rule must not depend on another probabilistic answer if it can be expressed deterministically.

### Do not hide the human decision

Product logic, acceptable risk, and an ambiguous trade-off remain the responsibility of the human.

### Do not tie production to the development tool

The application has to build, deploy, and run without an active connection to Gabion.

### Do not promise identical models

A quantized model and a full one differ in quality. Gabion reduces the space for error and returns verifiable feedback, but it does not remove those differences.

### Do not open access ahead of responsibility

External distribution requires a license, updates, documentation, support, security, and clear removal — not only a working binary.

### Make the boundaries visible

The user has to understand what belongs to their application, what remains Pikiner technology, and what ends together with the license.

## Pikiner provides the migration service. Gabion makes it repeatable.

Gabion is developed by **Pikiner** as its own production technology.

Pikiner migrates the agreed behavior of a working product to a new technical foundation. Gabion sets the stack, the architectural boundaries, the modules, the tools, and the checks with which the new system is built and then developed.

### Why these are not two independent offerings

At present Pikiner and Gabion form one practical process:

1. the client demonstrates their working product to Pikiner;
2. Pikiner checks technical compatibility with the production pipeline;
3. the parties fix the behavior being migrated, the price, and the date;
4. Pikiner creates a separate client project;
5. Gabion is used during development and verification;
6. the client accepts the new system;
7. the team receives the project edition of Gabion for the first year;
8. the production application runs independently of Gabion.

The client buys a defined result of the migration, not hours of use of an internal tool.

### Why Gabion has its own site

The two sites answer different questions.

#### `pikiner.com` explains

- who a migration suits;
- what is migrated;
- how the scope is determined;
- how much a project costs;
- how acceptance works;
- who owns the code and the data;
- how to start a conversation.

#### `gabion.dev` explains

- how the production pipeline is designed;
- what role the Runtime and MCP play;
- what a module is;
- how the manifest and the contracts work;
- which properties are checked;
- how models are chosen;
- why production does not depend on Gabion;
- who the technology is available to now.

A separate site for the technology does not mean that Gabion is already sold as a standalone mass-market product.

### What the client receives

After the migration the client receives:

- a separate project directory;
- the source code of the application;
- the unique business logic;
- the data structure;
- the migrations;
- the tests;
- the configuration;
- the documentation;
- a deployment-ready result;
- access to the project edition of Gabion for the first year.

The exact contents of the project are determined by the SOW, and the Gabion features by the client license.

### What stays with Pikiner

Pikiner retains:

- the Gabion Runtime;
- the internal module storage;
- the internal module-management CLI;
- the production tools;
- the source anonymized module templates;
- the general development of the technology.

These elements are outside the client's project directory.

### The module boundary

If an agreed project requires a new shared module, Pikiner creates it as an anonymized reusable component.

The following are not migrated into a module:

- client data;
- secrets;
- the name of the product;
- unique business logic;
- confidential rules;
- the source code of the old system.

The source template outside the project remains Pikiner technology.

Everything in the delivered project directory belongs to the client on the terms of the contract.

### Why production stays independent

Gabion takes part in creating and changing the project, but not in serving a user request.

The production application must not:

- start the Runtime;
- contact the Gabion MCP;
- load modules from the Pikiner storage;
- check the Gabion token;
- contact Pikiner in order to execute business logic.

Before the handover the project has to pass a clean build without the Runtime, the token, and the internal storage.

### What happens after the first year

The client can:

- renew Gabion;
- continue development without it;
- bring in another team.

Not renewing ends access to the licensed Gabion features, but it does not take the project back and does not stop production.

### Two different meetings

The first free meeting is about the client's product:

The client demonstrates their product to the Pikiner team.

If the project is a preliminary fit, Pikiner can separately hold a Gabion Live Showcase:

The Pikiner team demonstrates Gabion to the client.

Deep technical questions that require further verification receive a written answer after the meeting.

### Why Pikiner does not open Gabion immediately

Pikiner has to answer not only for the capabilities of the Runtime, but for:

- installation;
- updates;
- licensing;
- documentation;
- data;
- tokens;
- removal;
- support;
- compatibility;
- termination of access;
- the independence of the client project.

Limited access now makes it possible to verify the whole process on real projects before promising a universal standalone product.

Pikiner answers for the result of the migration. Gabion enforces the production pipeline. The client keeps their project.

[About Pikiner](https://pikiner.com/company) [Product Migration](https://pikiner.com/migration) [Contract, IP, and Independence](https://pikiner.com/independence)

## A working Pikiner technology, ahead of a standalone public product.

Gabion exists, is in use, and is being developed inside the Pikiner production process.

What is in the future is not the technology itself, but its standalone mass distribution.

### What is available now

Clients of a Pikiner migration receive:

- a separate application project;
- the project edition of Gabion for the first year;
- access for work on the specific delivered product;
- the features listed in the client license;
- the updates provided;
- help with Gabion to the scope established.

The client project runs independently of any further access to Gabion.

### What is not available now

There is not yet:

- a public download of the Runtime;
- a standalone subscription;
- a free trial;
- a personal token for an arbitrary project;
- an open beta;
- a public module registry;
- a module marketplace;
- self-service creation of new projects by external users;
- an open module-management CLI;
- guaranteed plans for studios, companies, or developers.

### What is being considered for the future

Pikiner is exploring possible access models for:

- web studios;
- product companies;
- individual developers;
- technology partners;
- pilot programs.

These directions are not a public commitment to open access in a particular order or by a particular date.

### What has to be ready before access is widened

A standalone product requires more than a Runtime.

Before external access is opened, the following have to be prepared:

- a stable installation;
- updates;
- removal;
- documentation that works without the Pikiner team;
- a clear license;
- token management;
- restoration of access;
- a support model;
- environment compatibility;
- a data policy;
- telemetry controls;
- crash reporting;
- an incident process;
- termination conditions;
- verifiable independence of the client project.

### What limited access means

Limited access is not used to create artificial scarcity.

It means that Pikiner so far takes responsibility for Gabion only in a known scenario:

- the product was migrated into a supported pipeline;
- the architecture of the project is known;
- the license features are defined;
- the team receives documentation;
- the independence of the project is verified before the handover.

### The interest form

A visitor can describe a future scenario, but the form:

- does not create a trial;
- does not issue a token;
- does not create a project;
- does not book a Showcase;
- does not guarantee a beta;
- does not reserve a price;
- does not promise a launch date;
- does not create a queue with a guaranteed place.

[Current Availability](https://gabion.dev/availability)

### Gabion Live Showcase

A Live Showcase is not a way to obtain standalone access.

It is held separately for a suitable migration client, after seeing their working product.

A Showcase demonstrates the technology, but does not provide:

- the Runtime;
- a token;
- an account;
- the internal storage;
- a new client project;
- the right to standalone use.

### When the status changes

When a new access model launches, Pikiner has to update, at the same time:

- the Gabion home page;
- the availability page;
- the FAQ;
- the license terms;
- the Privacy Policy;
- the form;
- the technical documentation;
- the sitemap;
- the metadata;
- the email communication.

Until such an update, a visitor must not infer that access exists from the presence of registration or sign-in pages in the framework.

Gabion already exists as a technology. Public standalone access will appear only after a separate product decision.

[Current Availability of Gabion](https://gabion.dev/availability)

## Gabion develops around a verifiable boundary of responsibility.

The human defines the product and makes the release decision.

The AI does the technical work inside the permitted area.

Gabion provides the production pipeline, the contracts, and the checks.

Pikiner answers for the agreed result of the migration.

The client keeps their own project and the ability to continue working without Gabion.

### Study the workflow

[How Gabion Works](https://gabion.dev/how-it-works)

### Study the technology

[Runtime, Modules, Manifest, and Checks](https://gabion.dev/technology)

### Learn the terms for a Pikiner client

[Gabion for Pikiner Clients](https://gabion.dev/for-pikiner-clients)

### Tell us about a future interest in Gabion

The availability form does not create a trial, a token, a project, or a guaranteed place in a future program.

If you already have a working product, the first free meeting is where you demonstrate it to the Pikiner team. This is not a Gabion Live Showcase.

[Current Availability](https://gabion.dev/availability)

[Show Your Product to Pikiner](https://pikiner.com/contact?intent=product-demo)

Pikiner builds and delivers the product. Gabion helps enforce its technical boundaries. Production remains standalone.