The Gabion Workflow
The human defines what the product has to do. The AI works with the code and the stack. Gabion provides the production pipeline and verifies that a change does not break its critical rules.
The architecture stops being a set of aspirations in documentation and becomes part of the development process itself.
A modern model can quickly produce clean code, explain it, and correct an obvious error. But an explicit requirement describes only part of the task.
Outside the request lie the implicit assumptions: the method of access control, the transaction boundaries, the permitted direction of a dependency, the data lifecycle, the specifics of a library, and the rules for integration with the rest of the system.
An experienced developer applies many of these rules automatically. The AI may not see them, may confidently select a similar but unsuitable pattern, and may produce a result that looks convincing in review.
The ordinary cycle leaves the model too many hidden decisions:
The problem is not that the AI writes code. The problem is how many critical decisions it has to guess.
| Participant | Responsible for | Should not do alone |
|---|---|---|
| Human | The goal, the business logic, the priority, the evaluation of the result | Remember every technical constraint of every library |
| AI | Analyzing the task, creating and changing code, correcting the discrepancies found | Reinvent the architecture and define the critical security rules |
| Gabion | The project context, the permitted tools, the architectural boundaries, the modules, and the checks | Decide what value a feature has to give the user |
Gabion does not determine what the user needs, and it does not turn a vague idea into correct business logic automatically. The human sets the goal, explains the exceptions, and accepts the result.
Gabion does not reduce the AI to inserting pre-written code from a template. The model analyzes the task and implements the change, but does so within a known technical boundary.
The architecture does not depend on whether the developer remembered to add it to a new prompt, or on whether the current model knows every decision taken a month ago.
The Gabion working cycle does not begin with an endless chat against an empty repository.
First a project is created on the coherent stack. The human and the AI then change it through the tools, modules, contracts, and checks provided. Once verified, the project is built by standard means and deployed independently of Gabion.
A new project is initiated by a command of the form
gabion init my-project. Gabion creates a separate
application directory.
The following appear in it:
Gabion Runtime and the internal module storage are located outside this directory.
The Runtime creates the project, but does not become part of the project.
The Starter is responsible for the initial shape of the application:
The Starter is not a module.
The Starter creates the foundation. Modules add vertical capabilities.
A Gabion module can include several layers at once:
The contents of a module are declared through
gabion.manifest.json.
The manifest tells Gabion:
A module must not know the internal structure of another module.
Permitted interaction goes through:
Gabion verifies the properties of this boundary available to it.
A direct import of an internal implementation, an arbitrary change to another module's files, or a hidden dependency has to be detected by the checks provided.
Once the project is created, the human describes:
Example:
"A project manager can see the financial indicators only of projects in their own organization. An organization administrator sees all of that organization's projects. Access between organizations is prohibited."
The AI does not necessarily receive the whole repository and all the project data.
Through the permitted MCP boundary it can receive:
The scope of access is determined by the project, the tool, and the decision of the human.
Secrets and production data must not enter the context automatically.
Before making a change the AI can:
The plan produced by the AI is not proof of architectural correctness. It helps the human understand the intended diff before it appears.
The AI creates or changes files inside the permitted directory.
For unique business logic, changes are made directly in the client project.
For a repeatable feature, an existing contract or module is used, if the production pipeline provides one.
The AI does not receive direct access to the internal Pikiner module storage.
If an existing shared component is not sufficient for the agreed result, Pikiner separately determines whether it should become a module.
A new module is created outside the client project as an anonymized reusable template.
The following are not transferred into it:
The internal Pikiner production CLI applies the module to the project and runs the necessary checks.
The project edition of Gabion for the client does not provide the module-management CLI or direct access to the internal storage.
After a change, the deterministic checks run.
They can verify:
A check evaluates a specific property of the project, not the persuasiveness of the explanation given by the AI.
If a rule is broken, the result has to explain:
The AI can use this diagnostic output to make a correction.
The human sees the same problem and does not have to reconstruct it from the internal dialogue of the model alone.
An architectural check does not replace a test of the user-facing result.
After a correction, the following run:
The specific set depends on the project.
A successful structure does not prove the correctness of an unknown business rule.
The human verifies:
Gabion does not take product, legal, or ethical decisions on behalf of the team.
After the technical and product verification, the project has to build without Gabion Runtime.
The standard cycle includes:
The Runtime, the internal storage, and the Gabion token are not part of this path.
A successful Gabion check does not publish a change to production automatically.
An authorized person or a client process decides separately:
After deployment the user interacts only with the application and its agreed external services.
Production must not access:
Gabion takes part in changing the project. The request from the user is executed by the application itself.
In a traditional project an architectural decision often exists in documentation, in a code example, or in the memory of a senior developer. A new participant may not know about it, and the AI may select a different approach that also compiles and looks reasonable.
In Gabion a repeatable rule is expressed, where possible, through one or more mechanisms:
Not every architectural decision can or should be turned into a prohibition. Gabion distinguishes verifiable boundaries from the areas where the engineering judgment of a human is required.
The AI and the human consume technical information differently. A model needs a structured result tied to a specific action and to a possible correction. A human needs a clear overview: what was happening, why the change was stopped, and whether a decision is required from them.
Gabion has to return:
The interface displays:
Information for the human is displayed in the browser — in an overlay or a separate window. The workflow is not tied to the interface of a single IDE.
If the rules of the system are held only in the context of the model, they have to be supplied again in every session and verified after every change of provider.
Gabion moves the durable part of the context into the production environment. The model gets access to the same tools and checks regardless of its brand, its size, or where it runs.
This makes it possible to choose a model on the basis of:
Gabion does not make a weak model equal to a strong one. Models differ in their ability to understand a task, build a plan, and correct errors. The environment reduces the number of decisions they have to guess, and detects certain violations before the result reaches the human.
Gabion does not:
The task Gabion sets itself is narrower and more practical: to take the repeatable technical decisions that can be standardized in advance away from the human and the AI, and to make the critical boundaries of the project verifiable.
The result of the work of Gabion is a separate project on the coherent stack, not a script executed inside a closed Pikiner platform.
The source code of the project is available to the client. This does not mean the project has to be published as open source: the client can keep the product closed.
Depending on the agreed contents, the project directory holds:
All contents of the delivered project directory belong to the client under the terms of the contract.
The following remain outside the client application directory:
These elements must not enter the production artifact of the application.
The project can be:
Independence does not mean that any future deployment method is automatically supported by Pikiner documentation. It means the absence of a mandatory technical dependency on Gabion.
The project being delivered has to pass a check in a separate environment:
This check has to be reproducible rather than dependent on the machine of a Pikiner developer.
If a Gabion module was used when the project was created, the files the application needs are in the project directory.
The application must not:
Pikiner keeps the original anonymized module template outside the project. The client keeps the contents of their own project.
Valid access may be needed for:
The exact contents are determined by the license.
Access is not needed for:
The team can:
Gabion has to remain a useful way to work with the project, not the only way to keep it working.
Independence from Gabion does not by itself guarantee:
After giving up Gabion the client is responsible for further changes, or transfers that responsibility to a team of their choosing.
The following have to be distinguished:
The first three properties do not require the last two.
The client receives the source code of their own application. Gabion Runtime remains closed. The production product runs without it.
The technology page explains in detail:
gabion.manifest.json;The first step happens on the Pikiner site.
At the first free meeting the client demonstrates their working product to the Pikiner team:
This does not require handing over the entire repository in advance or carrying out a paid technical audit.
Pikiner may separately offer the CTO or the technical team a free Gabion Live Showcase.
At the Showcase the Pikiner team demonstrates:
This is a second, separate meeting.
At the first meeting the client demonstrates their product to Pikiner. At the Gabion Live Showcase Pikiner demonstrates Gabion to the client.
The Showcase is not available as automatic open booking for any visitor.
A separate page explains:
Gabion is not yet distributed as a standalone mass-market product.
Short answers about the Runtime, the modules, the token, the license, and independence are collected in the FAQ.