Engineering with AI

There is hardly a software team left that does not use AI assistants. Developers use them to write code, leaders to prepare documents, product people to sort out requirements. The speed they gain is real and shows from the first day. What you almost never see is a method behind it. Each person works with their own prompt, in their own window, and what is learned in one conversation is lost when it closes.

For a while that is enough. Then the same problems start showing up everywhere. Quality depends on who used the assistant that day and how well they asked. Decisions fade, and the same debate returns a few weeks later in another change. Security arrives late, once the code is written. And if someone asks which standard was applied to a change, or who approved it, nobody can answer.

The risk of stopping at vibe coding

There is a way of using AI that has become popular, and I understand it perfectly, because it is a lot of fun: ask the assistant to build something, see that it works and move on. For a weekend prototype it is fine. For a product that handles people's data, money, or processes a business depends on, it is a gamble.

The tool does its job. The risk is that an assistant writes a correct solution and a wrong one with the same fluency, and if nobody reviews with judgement, the wrong one reaches production with the same confidence as the good one. A team that only generates code, without understanding what it generates, piles up debt at a speed that used to be impossible. It produces more, and it also makes mistakes faster.

What separates an engineering team from a group of people asking a machine for things is judgement: knowing what to build, recognising when something is wrong, and answering for what gets shipped. That cannot be delegated.

What GATE proposes

GATE was born from that concern. It is an open framework that orders AI-assisted work into a cycle of stages, each with what it takes in, what it delivers and who approves it. The rule underneath is simple: the AI prepares, people decide. The assistant reads the code and the data, drafts, correlates and checks against the source. The person accepts or rejects, chooses when something has to give, authorises any write into a shared system and answers for the outcome.

The piece I care about most is learning. Every decision taken in a code review and every root cause of an incident becomes a team rule, written down with its origin, and that rule applies before the next change. Over time the team stops arguing the same thing twice and mistakes stop repeating, because each one leaves something learned.

Bringing it into a company

GATE is the foundation, but each company has to build its own house on it. Its products, its tools, the way it is organised and its rules are its own, and no generic framework knows them.

That is why implementation starts with one person: the orchestrator, who leads the adoption and chooses the assistant the company will work with, whether Claude, Gemini, Kiro or another. GATE requires none of them in particular. With that decided, the assistant interviews the orchestrator about the organisation, its roles, its tools and what it wants first, and with those answers builds the company's SDLC layer by layer, showing each one before moving on. At the end it runs a real verification, point by point.

I recommend starting small. Product and building first, so that a requirement arrives well defined and whoever builds it works with the team's rules. Operations and security next. Each phase opens when the previous one works with real people, and while the building lasts, the orchestrator writes down when that phase ends, so the system does not depend forever on one person.

What a company gains

The first benefit is the most visible: productivity. The mechanical work that eats a good part of the day, such as writing tickets, rebuilding context, reviewing line by line or reconstructing an incident's timeline, is done by the AI. The team spends its time deciding, and a small group can cover what used to take several roles.

The second benefit takes a little longer to show, and is worth more: continuous improvement. Quality improves because every review leaves rules. Security improves because risks are reviewed before code is written, not after. Operations improve because incidents are diagnosed from data and each root cause becomes a rule that prevents the next one. None of these improvements depends on someone remembering to do them, because the cycle itself triggers them.

Some benefits appear in no report and still change a company. Knowledge stops living in the heads of two or three people and gets written down, so someone new gets up to speed faster and someone leaving stops being an emergency. Decisions are recorded with their reasons, so a year from now someone will understand why something was built a certain way. And for any change you can answer what was asked, which standard was applied and who approved it, something clients, auditors and regulation will demand more and more.

Governance and responsibility

Governing AI-assisted work means knowing in advance where the machine stops and where a person decides, and letting everything else move fast. GATE defines those points and deliberately separates some roles: whoever builds a change does not review it, whoever proposes a design does not approve it, and whoever builds does not validate the business outcome. In small teams with strong assistance it is easy to converge quickly on the wrong answer, and those separations are the protection against it.

Responsibility is not delegated either. An assistant can prepare a flawless deployment, but the decision to go to production is taken by a person, and that person answers for it. An organisation that tries to make the tool carry the responsibility finds out at its first audit or its first serious incident.

Experience plus assistance

This is, for me, the most interesting part. AI amplifies what it finds. In the hands of someone without judgement, it amplifies confusion. In the hands of someone experienced, who knows what to ask, what to discard and what must not fail, it multiplies their reach in a way that was unthinkable a few years ago.

When that experience is combined with a method that keeps what was learned, the effect compounds. Each month the team works on top of what it learned in the months before, with more rules, fewer repeated mistakes and less time lost rebuilding context. That compounding growth is what can become exponential, and it comes from what the company builds around the AI model, because anyone can subscribe to the model.

Where this is heading

Assistants will keep improving, and fast. They will sustain longer tasks, make fewer mistakes and be able to act with more autonomy. That is why the method matters more every day: the more the machine can do, the more a bad decision costs.

I believe the line between what the AI does and what a person decides will keep moving, and it is right that it should, as long as it moves with evidence and by someone's decision, not by omission. Models become a commodity within months, so the advantage will lie elsewhere. Companies with their knowledge in order, clear processes and a culture where the AI prepares and people decide will do better than those that only have the best model.

GATE is public and free to use. I wrote it so any company can build its own path, with the assistant it chooses. If you try it with your team, I would very much like to know where it got stuck and what you learned.

This is the first article in a series. The next ones cover how GATE was built and how to implement it in your company.

Back to the blog