How GATE was built

GATE started as a list of things that kept repeating in the teams I have led since AI became part of daily work: decisions that got lost, reviews that depended on who was reviewing, security problems that showed up late, and a question nobody could answer, which standard had been applied to a change.

The first version

The first version ordered the work into a cycle of thirteen stages, from someone raising a need to the system running in production and the organisation learning something from it. Each stage has what it takes in, what it delivers and who approves it. Between stages there are control points where the chain stops until a person decides.

Two decisions were never touched. The first was separating some roles: whoever builds does not review their own change, whoever proposes a design does not approve it, and whoever builds does not validate the business outcome. The second was leaving the rule catalog empty on purpose. A rule set copied from a guide describes whoever copied it, and nobody feels it is theirs. The rules had to come from real work.

Putting it into practice

The real test was implementing it in a real organisation, with real products, people and urgencies. Things showed up there that the paper did not show.

The most important was that the framework described an SDLC that already existed and said nothing about who builds it. It needed a role, the orchestrator, and a formulation phase with an exit written in advance, because while it is being built one person proposes and approves. It also became clear that approving every write one by one does not survive the real pace, and that authorising a scope for the session works better, with a short list of actions that always ask. The rules that matter cannot live only in the assistant's instructions: over long sessions they fade, and the environment and the platform have to enforce them.

Product, which often does not work in repositories, needed its own way in. And the use cases product validates turned out to be the best bridge between defining a requirement and the automated tests that protect it later.

All of that went back into the framework. And with it came the distinction that orders it today: GATE is the foundation, and each company builds its own SDLC on it, with the AI assistant it chooses.

Testing it on a company that does not exist

One question remained. Could another company, without help from whoever wrote GATE, build its SDLC with only what is published? To answer it, an AI agent with no prior context invented a health software company, with its team, its products and its simulated tools, and built its SDLC following the guide alone.

The result was a complete SDLC, which was then used across the whole cycle. Defining a requirement separated the solution the request brought from the underlying problem. Pre-review caught personal data being written to a log. The automated tests caught a regression. And diagnosing an incident, filtered by environment, avoided a false conclusion.

The test also found problems in GATE, which is exactly what it was looking for: gaps in the permission guards, a validator that let rules without an origin through, and platform assumptions a small team does not always meet. Each one is being fixed, and the test will run again.

A framework that learns too

GATE learns at three levels. The team learns from every review and incident. The product learns when what shipped is measured against the original problem. And the framework learns from every company that implements it, because each one records where it departs from GATE, and what turns out to be a lesson comes back as a proposal, with no company data.

That is why GATE is not finished, and does not mean to be. It improves with every use, like the teams that use it.

The next article explains how to implement it in your company.

Back to the blog