Operator, not consultant
Why the useful help with AI coding tools comes from someone who still ships, not someone who only advises.
There is a lot of advice about AI in engineering from people who have never shipped with these tools. A deck and a framework is not the same as having run agents in production, on real customer software, on a real deadline.
The work that moves a team is hands-on: in the codebase, on real tickets, alongside the engineers. Advice at a distance does not change how a team actually works. Pairing does.
The gap is not knowing, it is doing
A consultant can tell you that context matters, that you should write specs before you prompt, that you need a review gate. All true, all useless on their own, because the hard part was never knowing the principle. The hard part is the friction of a specific codebase on a specific Tuesday. The same advice splits in two depending on who is holding it:
| Advice at a distance | In the codebase with you |
|---|---|
| ”Write a spec before you prompt.” | We write one with your team on a real ticket, and watch where it breaks. |
| ”Add a review gate.” | We find the stage where work already queues, and fix that one first. |
| Principles that sound right in a slide. | Habits that survive your test suite, your flaky service, your sceptical engineer. |
You only meet that friction by being in it. The advice that survives contact with a real repository is different from the advice that sounds good in a slide. We have changed our own practice more from one afternoon pairing on someone’s actual code than from anything we have read.
What “operator” commits us to
It means we are in your codebase, on your tickets, with your engineers, doing the work and not narrating it. When we suggest a change to how you use an agent, we have already tried it on something real and watched it fail or hold. And it means we leave: the point of the engagement is a team that can hold the pace without us, not a dependency, and not a document that sits in a drive.
It also means we keep our hands off the things that are yours. You own the architecture. You own the hiring. You own every pull request. We are there to make your team better at this, not to take it over or to quietly become a permanent line item.
So if someone is selling you an AI transformation and they cannot show you code they have shipped with these tools, be careful. The useful help looks boring from the outside: someone who has done the work, sitting with your team, doing it again, then handing it back. No theatre. That is the whole job.