How to implement GATE in your company
A guide to building a company's SDLC with GATE, written while I am still implementing it.
Product
I want patients to be able to reschedule their appointment from the app.
Before writing the ticket, I separate the request from the problem.
Problem: patients call to change an appointment and the phone line gets swamped.
Solution the request comes with: rescheduling from the app. There are others, such as a link in the reminder.
Data: specialty and appointment date. That is health data, so it is classified as sensitive.
Precedent: the catalog has a rule about health data in notifications.
It is not clear whether patients can reschedule with a different professional. Here are both options for you to decide.
Next: acceptance criteria and use cases for you to validate.
Development
Review my change before I open the merge request.
I reviewed the whole branch against the base and against the ticket's criteria.
Blocking: the rescheduling service writes the patient's specialty to the log. That is health data and a catalog rule forbids it.
The migration is missing its changelog entry.
The ticket's three use cases are automated and passing.
I do not flag what was already there before your change.
The merge request draft and the verification script are ready. I published nothing.
Support and SRE
A patient says they rescheduled and never got the confirmation.
I followed the booking by its number through the three services it went through.
The booking was updated correctly.
The notification service answered "ok", but the email provider rejected the message because the address bounces.
Scope: it is an isolated case. Since the last deploy there are no more rejections than before, so it is not an incident.
For support: confirm the patient's email and resend. Every claim comes with a link to its log line.
Leadership
What is blocked this week and who can unblock it?
Three things are waiting on someone.
Rescheduling from the app has been waiting four days for a review. The backend reviewer can unblock it.
The payment alerts are waiting for product to decide what to warn about.
The database migration is waiting for a maintenance window from infrastructure.
Pattern: two of the three blockers are reviews. They should be spread out better.
I read this today from the ticket board and the code platform. I wrote nothing.
Last chapter of the series. It is a guide, but I have not finished implementing it yet. I am still in the formulation phase, so several recommendations come from my own mistakes or from mistakes I managed to avoid.
Implementing GATE in a company means building its own SDLC. In practice, that is a repository with the team's method, its rule catalog, the context of each product, the skills and the way each person joins. The full guide is in the repository, and here I summarise the essentials for anyone deciding whether it is useful to them.
What you need
First, a person to lead the adoption, whom GATE calls the orchestrator. They need the authority to assign roles and the technical judgement to reject a proposal from the assistant even when it is very well written. They do not need to know every tool in advance, but they do need to answer questions about the company and make decisions. They also need patience, because at first they will have to persuade people more than they would like.
Second, an AI assistant that loads instructions in every session, uses skills and works on a repository. Claude Code, Gemini CLI, Kiro and Codex all work, and the orchestrator picks one. You also need a code platform, a ticketing tool and, for operations, a reliable source of what happens in production. If one is missing, whatever depends on it waits and is noted in the plan.
The steps
The skeleton of the SDLC is generated with one command:
python3 bin/bootstrap.py sdlc ../sdlc-mycompany --assistant claude-code --org mycompanyThen the assistant interviews the orchestrator. It asks a few questions at a time, each with a suggested answer, and builds in layers: first governance and the plan, and then the method, the catalog, the products, the instructions, the controls and the skills. It shows each layer before moving to the next and at the end runs a point-by-point check.
The orchestrator's decisions
Some decisions only the orchestrator can make: which assistant to use, who fills each role, which profiles each person has, which products the pilot starts with and what is left out. None of them stops the build, because each comes with a default option, and whatever is not known yet is marked as pending.
The most important one is when the formulation phase ends. While the SDLC is being built, the orchestrator proposes and approves everything. That is fine as long as, before starting, it is written down when it ends. For example, when these conditions are met:
- someone else installed the SDLC without help;
- product used it on a real requirement;
- a rule born from daily work entered the catalog.
From that day on, the orchestrator follows the same rules as the rest of the team. It is the day I look forward to most.
Start small
The first phase covers product and construction, so that requirements arrive well defined and whoever builds them works with the team's rules. Then come operations and security, and finally visibility for leadership. Each phase starts only when the previous one works with real people.
The most common mistakes
The first is a risk I know well: that formulation never ends. The orchestrator keeps approving everything and the SDLC ends up belonging to one person. Another is filling the catalog all at once with copied rules that nobody on the team feels are their own.
Two more are harder to notice. If the checkpoints never reject anything, in practice the assistant decides, because it writes convincingly. And if the important rules live only in the instructions, without an automatic check or a pipeline to enforce them, in long sessions the assistant stops following them.
Finally there is the temptation to keep building instead of using what already exists. I know it well, because building always seems more urgent than stopping to teach. But as long as only the orchestrator uses it, the SDLC is still a project under construction.
What to expect
In the first weeks there is less mechanical work done by hand, and the self-review catches mistakes before they reach another person. In the following months, the catalog fills with the team's own rules and the same discussions stop repeating. Over time, knowledge is written down and the team works on top of what it has already learned.
The full guide, with the interview, the repository structure and the final check, is on GATE on GitHub.
This journal goes on, because the process is not over. If you implement it, I would like to know how it went, and even more so if you have to do it alone.