Let me start with a confession, because it sets up everything that follows.
This was the hardest thing I've written in years. Not because the facts were hard. The facts are easy — I've got twelve years of them. It was hard because to write it I had to do the one thing none of us actually wants to do: I had to take apart the thing that just works.
You know the thing. The instinct. The move you make without watching yourself make it. The reason a junior brings you an architecture and you can feel, in about four seconds, exactly where it's going to fall over — and you can't fully say why, you just know. That four-second thing is the whole career. It's also completely invisible to its owner. You do not get to see your own intuition. It runs below the waterline.
To write this, I had to haul it up into the light and look at it. And I'll be honest with you — that's a deeply uncomfortable thing to do, because there's a superstition we all carry that if you stare too hard at the thing that works, it stops working.
I did it anyway. And the tool I used to do it is the same tool this whole session is about. More on that at the end, because that's the part that actually hits.
First, the long way. Mine. Quickly, because it's not the point.
I wrote parsers for a living. Properly. For money. When "data engineering" wasn't a job title, it was just the unglamorous person who made the feed make sense. I wired together enterprise architectures from nothing, back when Enterprise Architecture was a sick, half-formed capability that most organisations couldn't spell, let alone staff. I learned to build the structure that holds knowledge before there was anything clever to put on top of it. That's not a flex. That's the foundation of everything I'm about to tell you, so hold onto it.
2014. IBM. Watson. First real contact with the idea that you could reason over structured knowledge instead of just searching it. The execution didn't survive contact with real data — almost nothing did back then — but the idea went in like a splinter and never came out: the value isn't the clever bit at the end, it's how you organise what you know before the clever bit runs.
Then the hype outran the substance and I went into a personal winter. Not the industry's. Mine. I stopped believing brochures for about four years.
2018 is the year that actually matters, and almost nobody knows this story. I had a frosty meeting with two very senior Norwegian ex-military security analysts. The kind of frosty that gets under your skin. I went away and, overnight — one night — designed a big-data-lake-based SOC built on a bring-your-own-ML approach. I called it Raz0r. Apache Accumulo underneath. TensorFlow on top. That night in 2018 is where my machine-learning life actually starts — not in a chat window seven years later, but in a sleepless rage-build after a meeting that annoyed me enough to prove a point. Everything I run now — the graph, the Brain, NinjaSignal — traces back to that night. The concept is that old. The tools just took seven years to deserve it.
Then GPT-2 and the parade after it. And I'll say it plainly: I hated it. Not the technology — the culture. The slop. The carousels. The confident wrongness posted three times a day with a rocket emoji by someone explaining my own field back to me. I endured GPT Pro and Codex because they were tools and I'm a professional, but they left me proofreading a stranger, which is worse than doing it yourself.
June 2025, I switched everything into Claude Code. And for the first time the tool was good enough to keep up with the architecture I already had. Not invent it. Execute it. Today there's a Claude resident on my own production boxes — not a tab I open, a thing that lives in the estate and works. That's the maturity curve. It took twelve years and one bad meeting in Norway.
Right. That's the long way. Here's the part you came for.
Here's the good news and it's better than you think: you do not have to repeat my twelve years. Most of those years were spent waiting for tools that now exist. The judgement took a decade. The path can be walked in months — if you walk it in the right order and you know where the walls are.
Most people fail this not because they're not clever. They fail because they do it in the wrong order. So here's the order, and the pain at each step.
Have one. Get it right, or at least have one.
The most common failure I see in talented architects is starting with the tool instead of the idea. "We're going to use AI" is not a concept. "We're going to do agentic" is not a concept. A concept is a sentence a tired person can repeat back to you. Mine was: "the SIEM is lying to me, so I'll build something that shows its working." One sentence, one grievance, one thing that's true.
The best concepts are grievances. Something in front of you is broken, or dishonest, or slower than it has any right to be, and you have the means to replace it. That's a concept. It has an enemy. It knows what done looks like.
Don't let the excitement of the tool become the concept. If you can't say what you're building in one irritated sentence, you don't have a concept — you have a vibe. Vibes don't survive contact with production.
Sit in the shape before you build it.
This is the step everyone skips, and it's the one that separates people who reach my level from people who generate impressive rubble. The moment you have a concept, the temptation is to open the editor, because the tool makes building feel free.
Resist it. What's the source of truth? What's deterministic and what's genuinely fuzzy? Where does the data come in dirty and where does it get resolved? I drew a multi-vector graph — the Brain — on a whiteboard. Five graphs, full cross-graph traversal, everything normalised into triplets at ingestion, resolved before anything intelligent is asked to happen. The communities the graph surfaces are the rocket fuel: by the time a model speaks, the structure has already done the thinking and the model just narrates what the architecture already knows.
And the cost angle nobody mentions: the architecture decision is the cost decision. I gate cheap, certain work to deterministic code — regex-first — and only spend the model on the genuinely fuzzy part. That one decision cut a pipeline's cost by an order of magnitude and made it more reliable, because I stopped paying a probabilistic system to do a clerk's arithmetic.
Coding straight away feels like progress and is usually the opposite. A model will help you build the wrong thing at extraordinary speed. Speed into the wrong architecture just arrives at the disaster sooner. The shape is the moat — and the model can't give you the shape. That's your job, and it's the job that lasts.
The doorway most architects won't walk through.
This is where most enterprise architects stall, and it's nothing to do with intelligence. It's a culture wall. We came up drawing diagrams and writing strategy. We did not come up living in a terminal. And the brutal truth is: until you get your hands into git and wire the model into your actual environment at the command line, you are a passenger. The leverage doesn't start until the tool is inside your environment — with your repo, your files, your context, your real problem in front of it.
Get comfortable at the command line. Get your work into git — branches, commits, messages — because that alone changes how you think; it forces your changes to be legible. Wire the model in at the CLI so it can see the repo and act on it. Give it a small, real, low-stakes job first. Watch it plan, act, and come back. Then a bigger one. Build trust the way you'd build it with a new hire.
Don't stay in the comfortable web window forever. The web chat is for thinking. The CLI is where work gets done. It will feel exposing — that's correct, and temporary. Everyone good at this walked through the git wall, including architects of twenty years who felt like impostors at the prompt for a fortnight. The fortnight passes. The capability stays.
Think in the window. Build in the terminal.
Two surfaces, two jobs. The UI — the chat — is where I think: ideation, argument, shaping the messy thing into the clear thing, interrogating a result. The CLI — Claude Code — is where I build: agentic loops, planning, executing against the repo, reading its own errors, coming back with a diff. I move between them constantly. Window, terminal, window. That rhythm is the actual skill, and it's invisible from the outside. People see twenty apps. They don't see the loop that made them.
And the destination: the model isn't something I open. It's resident — a Claude living on my own production boxes, part of the operating model. Not a tab, a tenant. When the model is resident, the terminal becomes the new SOC, the prompt becomes the new runbook, the artefact becomes the new evidence, and the code is the control.
The way I run all of it: missions, not roadmaps. Every piece of work is a mission with a statement, a time horizon, and — the part nobody does — kill criteria written down before I start, while I'm still honest enough to be objective. Parallel bets, one wins, failure is data. The roadmap tells you what you hope to build. The kill criteria tell you what you're brave enough to stop. And context is the scarce resource — not compute, not model quality — so a dense, curated memory gets read first, every time. Most "the AI got confused" stories are really "the human never told it what was true."
Don't confuse "resident and mature" with "automated and unattended." The model is in the estate. The judgement is still mine. The day you let the tenant make the load-bearing decisions is the day you've handed the building to someone who doesn't own it. The maturity is in the discipline, not the autonomy.
A ladder you can place yourself on:
- 0You talk about AI. You have opinions. You have used it twice.
- 1You use the web chat to think and to draft. Useful. Still a passenger.
- 2You're in git and at the CLI. You've felt the impostor fortnight. You shipped a small real thing with the model in the loop.
- 3You run the window/terminal loop fluently. You have a concept with an enemy and an architecture you can defend.
- 4The model is resident in your environment. You run missions with kill criteria. Context is curated, cost is gated. The terminal is your SOC.
- 5You've turned the instrument back on yourself. You can articulate how you think, teach it, and improve it. You are compounding.
Most of this room is a 1 with the experience to be a 4 inside a quarter. The only thing between those numbers is the git wall and the nerve to walk through it.
Cognition instrumentation
I don't think of these models the way the carousels do. Not a brain to replace mine, not an oracle, not a colleague, not any of the warm nonsense. I think of AI as cognition instrumentation.
Let me be precise, because the word is doing real work. An instrument doesn't think for you. An oscilloscope doesn't have opinions about your circuit. It makes the invisible visible so you can reason about it. That's what these models are to me — instrumentation for my own cognition. A way to take the thing that runs below my waterline, the four-second instinct, the move I make without watching, and pull it up into something I can see, test, argue with, and refine.
When I think out loud in the window, I'm not outsourcing the thought. I'm putting a probe on it. I'm watching my own reasoning render in real time, in a form clear enough to disagree with. The model reflects my thinking back with the fog removed, and in that reflection I catch the leap I didn't know I was making, the assumption I'd never said out loud, the step I compressed into instinct twenty years ago and never re-examined. That compressed step — the zero-moment, the thing your subconscious does before the conscious mind shows up — is exactly the thing that's impossible to teach, because its owner can't see it. The instrument lets you see it.
The instrument doesn't diminish you. It shows you to yourself. And the better you already are, the more there is to see.
That is what made this piece so hard. To write it, I had to instrument myself — point the probe at my own competence and ask what it is I actually do. And the model held it still long enough for me to look, which is unnerving, because you spend your whole career not looking at that, on the superstition that looking breaks it. It didn't break. It got sharper.
Which is also, finally, why I'm good — and how you get there faster. I'm good because I've got a decade of cognition worth instrumenting. You might have less, or more in a domain I'll never touch. Doesn't matter. The instrument amplifies whatever's holding it.
Put it on a deep, hard-won way of thinking and you get a platform. Put it on a vibe and a Canva subscription and you get a carousel. Same instrument. The difference is entirely you.— the whole session, in two lines
- Write your concept as one irritated sentence. If you can't, you don't have one yet. Sit with the grievance until it's a sentence.
- Before you write a line of code, draw the architecture and defend every box to a colleague who's allowed to be hostile.
- Put a real piece of work in git this week. Branch it. Commit it. Feel the legibility change how you think.
- Wire the model in at the CLI and give it one small, real job. Watch the loop.
- Next week, give it a bigger one, and start moving between the window and the terminal on purpose.
- Write down your kill criteria before your next build, while you can still be honest about it.
- Once a fortnight, point the instrument at yourself. Ask it to reflect your reasoning back, and have the nerve to read it.
I'll do something I don't normally do: hand you the actual file that governs how I work with the model. My CLAUDE.md — the document a fresh model reads before it writes a word for me. It encodes the voice, the rules, the "never invent a number" line, the comedy dial, the lot. It's real. It runs.
Drop it in the root of a repo or into a project, call it CLAUDE.md, and the model loads it on every turn. Import it, read it, then gut it and make it yours — because the whole point of this session is that the file only works if the judgement inside it is yours, not mine.