Gabion by Pikiner

AI writes the code. Gabion enforces the architecture.

Gabion is a development environment for human and AI collaboration.

It defines a coherent production stack, provides ready-made critical components, and verifies decisions at the points where AI-generated code that looks convincing is most often incorrect.

Works with a range of LLMs, including local ones. It does not require a model of its own, a specific IDE, or the transfer of production data to an external AI provider.

• Architectural constraints rather than recommendations alone
• Java, Spring, PostgreSQL, and TypeScript
• An MCP interface for AI assistants and agents
• Linux, macOS, Windows, and WSL2

A language model can interpret a task, propose a solution, and write code. But it has to make product, architectural, and library decisions at the same time — including where it has neither the full context nor the right to be wrong.

Gabion removes part of that responsibility from the model. It defines the technology boundary in advance, gives the AI access to the permitted ways of solving a task, and verifies the critical properties of the result by deterministic means.

Gabion therefore does not compete with an LLM. It creates an environment in which the chosen model can work on a real product within defined boundaries.

The model can be replaced. The product's architectural rules have to remain.

This division does not remove the developer from the process. It allows the developer to concentrate on the logic and the consequences of a change, without simultaneously having to recall every detail of every library in the production stack.

More on the Division of Roles

Gabion does not keep the product inside a closed builder platform.

It creates a separate standard project, helps the human and the AI change it within verifiable boundaries, and then leaves the application with an ordinary build and an independent production.

1. 1. A separate project

   A command of the form gabion init my-project creates a separate application directory on the coherent stack:

   • Java;
   • Spring;
   • PostgreSQL;
   • TypeScript;
   • Thymeleaf;
   • CSS;
   • Flyway.

   This directory holds the source code, the business logic, the project data, the tests, and the application configuration.

   Gabion Runtime and the internal module storage are located outside the project.

2. 2. A verifiable change

   The human defines the required result.

   The AI works with the code and receives the context relevant to the task through MCP.

   Gabion provides:

   • architectural contracts;
   • permitted extension points;
   • vertical modules;
   • deterministic checks;
   • clear diagnostics.

   If a verifiable rule is broken, Gabion returns a specific error. An explanation from the AI does not replace the result of the check.

   A Gabion module can combine the backend, the frontend, the templates, the styles, the page, the configuration, and the migrations of a single capability. Its contents are declared through gabion.manifest.json.

3. 3. An independent result

   Once verified, the project is built by standard means.

   The production application must not access:

   • Gabion Runtime;
   • the Gabion MCP;
   • the internal module storage;
   • the license token;
   • Pikiner servers to execute business logic.

   The end of access to Gabion stops the use of the tool, but not the operation of the product.

Gabion takes part in creating the project. The user interacts with the application itself.

A coherent stack instead of an arbitrary set of choices

Gabion uses Java, Spring, PostgreSQL, and TypeScript — technologies with a large volume of documentation, tooling, and established engineering practice.

The stack, the compatible versions, and the critical architectural paths are determined by the production pipeline, rather than chosen again for every request to the AI.

Explore the Gabion Technology See the Full Workflow

Different tasks require a different balance of quality, speed, confidentiality, and price. For one change a powerful cloud model is reasonable, for another a cheaper or quantized one, and a sensitive project may require a local deployment.

Gabion is designed so that the architectural rules do not depend on the brand of the model. The model interacts with the environment through the interface it is given, and receives verifiable feedback on the result.

Models, Data, and Cost

Gabion installs into the user environment without requiring root or sudo access, and it does not require a specific IDE.

AI assistants and agents interact with Gabion through an MCP server. Information for the human is displayed in the browser — in an overlay or a separate window — so the user sees the state and the results of the work independently of the code editor.

Supported environments:

• Linux x64;
• Linux arm64;
• macOS;
• Windows natively;
• WSL2.

The IDE can change. The model can change. The project's production pipeline stays the same.

Environments, MCP, and the Design of the Technology

Gabion helps to create and change the project, but it does not become a mandatory part of the working product.

The source code of the application is located in a separate client directory. Gabion Runtime, the internal module storage, and the license token are located outside it.

What the client keeps

The delivered project holds:

• the source code;
• the business logic;
• the frontend and the backend;
• the data structure;
• the migrations;
• the tests;
• the configuration;
• the deployment files;
• the project documentation.

All contents of the delivered project directory belong to the client under the terms of the contract.

The original anonymized module templates and the closed Runtime remain Pikiner technology, outside the client's project.

What confirms the independence

The project has to pass a clean check:

• without Gabion Runtime installed;
• without a valid token;
• without a connection to the internal storage;
• with a standard build of the backend and the frontend;
• with the tests running;
• with a deployment artifact created;
• with the application running.

The production application must not verify a Gabion license or contact Pikiner in order to serve users.

What the token controls

The token governs access to Gabion features:

• the Runtime;
• the MCP tools;
• the interface;
• the diagnostics;
• the updates;
• other capabilities of the license.

The token does not govern:

• the client's backend;
• the frontend;
• the database;
• the user accounts;
• the standard build;
• the deployment;
• the client's access to code and data.

What happens without Gabion

If the team does not renew access:

• the application continues to run;
• the project stays with the client;
• the data stays under the client's control;
• the standard build remains possible;
• another team can continue development;
• only the licensed features of Gabion stop.

Gabion has to remain a useful choice for development, not a technical condition of the product's existence.

What Pikiner Clients Receive Frequently Asked Questions About Independence

Gabion exists and is in use as the Pikiner production technology.

It is not currently distributed as a publicly available standalone product that any visitor can download, buy, or apply to an arbitrary project.

Access for a Pikiner client

After the migration the client receives:

• an independent application project;
• the project edition of Gabion for the first year;
• access for work on the specific delivered project;
• the features listed in the client license;
• the updates the license provides for;
• Gabion support within the defined scope.

The project edition does not provide:

• the creation of an unlimited number of new projects;
• the internal Pikiner module storage;
• the internal module-management CLI;
• the source code of the Runtime;
• the right to distribute or resell Gabion;
• the features of future standalone editions.

A separate Gabion Live Showcase

If the project is a preliminary fit, Pikiner may separately offer the CTO or the technical team a free Gabion Live Showcase.

At the Showcase the Pikiner team demonstrates:

• the project structure;
• the Runtime;
• the interaction with the AI;
• a real error;
• the diagnostics;
• the correction;
• the repeated check;
• the independent build.

The Showcase:

• is not the first meeting;
• does not replace the introduction to the client's product;
• does not provide a trial;
• does not issue a token;
• does not create a new project for the visitor;
• is not available as open automatic booking.

First the client demonstrates its product to Pikiner. Then Pikiner may separately demonstrate Gabion to a suitable client.

Public materials

Without a license a visitor can study:

• the description of the technology;
• the workflow;
• models and data;
• the terms for Pikiner clients;
• the FAQ;
• the information on availability.

Public materials do not provide access to the Runtime or to the internal module storage.

Gabion is developed by Pikiner. It was originally created to help a CTO control the growing volume of AI-generated code and reduce the review load.

As it developed, it became a production pipeline that makes it possible to migrate working products to a production stack and to leave further development with the existing team.

The History and Principles of Gabion Go to the Pikiner Site

The working product is demonstrated to Pikiner. Gabion is demonstrated by Pikiner.