Anyone who spends time in San Francisco is used to seeing cars with nobody behind the wheel. They stop at lights, wait for pedestrians to cross and steer around roadwork. From the sidewalk, it looks as if the car simply knows how to drive.
What makes this possible goes beyond the model that decides each maneuver. The car operates within a set of components that work together: a detailed map of the streets, sensors that cross-check one another, a defined operating area, rules that veto dangerous maneuvers and a remote team that takes over the hard cases. The model is one part of the system, and trust comes from the whole.
AI that writes code has the same problem
AI agents already draft requirements, propose architectures, write code and generate tests. Model capability improves with every release. Even so, an agent turned loose in a repository, with no business context and no limits, produces work that is hard to trust. It does not know which rules the company follows, which decisions have already been made or what it must not touch.
That is why the most useful question for technology leaders is what structure the model will work in: with what context, within what limits and with whom reviewing the result.
The harness, the structure around the AI
In the Tog Method, this structure is called the harness. It is the set of context, rules, agents, architecture patterns and checks that keeps AI working within the company’s standards. AI generates, the checks block anything that breaks the rules and a Tog Lab professional reviews before anything ships.
It all starts with context. AI models get more right when they are given the business context, so every project starts with a Domain Context: the single source of the rules, risks and decisions that guide each stage. In the car, that is the role of the detailed street map.
Piece by piece
The two structures map onto each other almost directly. Every component that makes the car safe has an equivalent in the development cycle.
| In the driverless car | In the Tog Method |
|---|---|
| Detailed map of every street | Domain Context |
| Redundant cameras, lidar and radar | Automated tests and TDD |
| Defined operating area | Scope and permissions |
| Rules that veto dangerous maneuvers | Guardrails that block destructive actions |
| Remote team for hard cases | Review of the plan and the pull request by a Tog Lab professional |
| Millions of miles in simulation | Evals and regression tests before the merge |
The car’s sensors cross-check one another: if the camera fails, the radar and lidar still see the road. In software, automated tests play that role. With TDD, the test is written before the code, and the agent finishes the task only when the test passes.
The defined operating area becomes scope and permissions. The agent gets access only to the part of the repository and the tools the task requires. The rules that veto dangerous maneuvers become guardrails: destructive actions, such as deleting data or touching production, are blocked by rule before they run.
The remote team that takes over hard cases corresponds to review by a Tog Lab professional, which happens at two points: on the plan, before the agent starts, and on the pull request, before the code goes in. And the miles driven in simulation become evals and regression tests, which verify behavior before the merge.
Nothing moves to the next stage until a person reads and approves the current stage’s document.
A person approves every stage
In AI-Accelerated, Tog Lab’s model for AI-accelerated development, work goes through seven stages: context, requirements, architecture, specification, prototype, code and tests, and infrastructure. Each one produces a document that someone reads and approves. Agents do the heavy lifting between one decision and the next. People from the client’s team and from Tog Lab decide what goes in and review all code before it reaches production.
AI autonomy has a defined limit for each type of task. As with the car, autonomy grows as the structure proves it can handle it. In a commercial proposal, we only promise what has already been validated with a client.
Where the analogy ends
Every analogy has its limits. The car decides in fractions of a second, in the middle of traffic, and a mistake has immediate physical consequences. In software, there is time between generating and shipping: code goes through tests, checks and review before the merge, and a change can be rolled back. That makes it possible to place the person at the decision points in the workflow, where their approval has the most effect.
There is another important difference. In the car, the structure belongs to the manufacturer. In AI-Accelerated, it can run inside the client’s cloud account, with the client’s model key and the AI model they choose. Switching models is a configuration change: context, rules, agents and checks stay the same, and the project does not need to be redone.
What this changes for buyers
For companies buying AI-assisted development, the structure around the model matters as much as the model. In practice, that means three things.
- You follow the project through each stage’s documents and approve before the next one starts.
- Repository, documentation and keys are in your company’s name from the first commit.
- You choose the AI model, and switching models does not mean redoing the project.
When evaluating a vendor, it is worth asking how they organize this structure: where the business context lives, what the checks block, who reviews and what gets recorded.