How to implement GATE in your company

Implementing GATE in a company means building its own SDLC: a repository with its method, its rule catalog, the context of its products, its skills and the way each person gets in. The full guide is in the repository. Here is the essential part, for anyone deciding whether it fits.

What you need

First, a person to lead the adoption, the orchestrator. They need the authority to assign roles and enough technical judgement to reject a well-written proposal from the assistant. They do not need to know every tool in advance, but they do need to answer questions about the company and decide.

Second, an AI assistant that loads instructions every session, uses skills and can work in a repository. Claude Code, Gemini CLI, Kiro and Codex qualify; the orchestrator chooses. You also need a code platform, a ticket tracker and, for operations, a source of truth about production. If one is missing, the part that depends on it waits, and the plan says so.

The steps

One command writes the skeleton of the SDLC:

python3 bin/bootstrap.py sdlc ../sdlc-mycompany --assistant claude-code --org mycompany

Then the assistant interviews the orchestrator a few questions at a time, with a default for each, and builds in layers: governance and plan, method, catalog, products, instructions, guards and skills. Each layer is shown before moving on, and at the end a verification runs point by point.

The orchestrator's decisions

Some decisions only the orchestrator can take: which assistant, who holds each role, which profiles each person gets, which products the pilot starts with and what stays out. None of them blocks the build, because each comes with a sensible default. Whatever is unknown is marked as pending and the build carries on.

The most important decision is the exit from the formulation phase. While the SDLC is being built, the orchestrator proposes and approves everything. That is fine, as long as it is written down before starting when it ends. For example, once these three things have happened:

• someone else installed the SDLC alone;
• product used it on a real requirement;
• a rule drawn from day-to-day work entered the catalog.

From that day on, the orchestrator follows the same rules as everyone else.

Start small

The first phase is product and building: requirements that arrive well defined, built by people who work with the team's rules. Operations and security come later, and visibility for leadership at the end. Each phase opens when the previous one works with real people.

Mistakes worth avoiding

The first is a formulation phase with no exit: the orchestrator approves everything forever and the SDLC ends up belonging to a single person.

The second is filling the catalog in one sitting with copied rules nobody recognises as theirs.

The third is control points that never reject anything, because then it is the assistant's fluency doing the deciding.

And the fourth is leaving the rules that matter only in the instructions, with nothing in the environment, a guard or the pipeline, to enforce them.

It also pays to resist building more before using what already exists. An SDLC that nobody but the orchestrator uses is still a project under construction.

What to expect

In the first weeks you notice the mechanical work that stops being done by hand, and the mistakes pre-review catches before they reach anyone else. Over the following months the catalog starts holding the team's own rules, and the same debates stop repeating. Over time, knowledge is written down and the team grows on what it already learned.

The full guide, with the interview, the repository structure and the final verification, is on GATE on GitHub. If you implement it, I would like to know how it went.

Back to the blog