Or: why my background as a bespoke-software-business owner with a Lean Six Sigma certificate is, oddly, less useful than my background as an artist with ADHD.
I have a degree in IT. A PGCE. Lean Six Sigma, PRINCE2, MSP, Scrum. I was the training manager at an ISP, and I trained the other IT trainers there. I owned a bespoke software business: I built a time-and-motion HR system from scratch, an early Content Management System, and a multi-faceted holiday-home booking system for sites running multiple units; I implemented inter-site VPN tunnels and IT support for an Independent Financial Adviser network across the South West; I led coding teams building in Magento and Expression Engine; I built a Key Stage 3 IT framework (an early bespoke Moodle) that schools paid money for, and a bespoke CRM and sales tool for a franchising operation sold internationally, training the franchisees when they flew into the UK.
I'm telling you this not as a CV-recital but because I want to register some authority for the next thing I'm going to say, which is that traditional software engineering has, as a discipline, missed something important about what AI systems actually are.
I've been building one for about a year. I have logs and code and architectural decisions and the production system is running on a Mac mini behind me as I write this. So this isn't theory.
The thing that catches most engineers off-guard is that an AI system's knowledge of itself is not in the code.
In a traditional application, when you swap a component, the application's understanding of itself stays put. The database knows what's in it because the schema says so. The router knows where to send requests because the route table says so. The structure is hard. The behaviour is reasoned over the structure.
My AI co-pilot, the one called InkFox, doesn't work like that. Its "knowledge" of how it operates, where its files are, what it should do when I say specific things: that lives in a stack of markdown documents. Forty-three of them, at last count. The model reads them at the start of every session and builds its understanding of the system fresh from the text.
This is not a bug. It's the architecture. It's what makes the system updatable without recompilation, debuggable by editing prose, and capable of being maintained by someone who can write English clearly but doesn't think of themselves as a developer. The text is the runtime.
But it means the model is the machine. Not a component running on the machine — the machine itself. Change the model and you have a different machine even if you've changed nothing else.
That's the part most engineers do not yet build for.
I'm going to give you a specific architecture decision and tell you why I made it, so you can see what I mean.
About a month ago I was burning through OpenRouter credits. £974 in April. The obvious response (and the one a sensible engineer would advise) is to swap to a cheaper primary model. Claude Haiku instead of Claude Sonnet. The arithmetic was simple: same system, cheaper model, lower bill.
What happened, and I've written about this elsewhere, was that Haiku is a different machine. The many-layered governance system (dozens of markdown files) that Sonnet read and understood and reasoned over correctly, Haiku could not hold in working memory in the same way. It would confabulate rather than reach into the documentation for the answer. The system wasn't malfunctioning. It was being run on a different machine and behaving accordingly.
So I had two choices. One: build a scaffolding around Haiku to compensate for what it doesn't do: explicit memory injections, warm-boot anchors, grounding layers, tighter routing thresholds for the kinds of turns Haiku does well on. Two: put Sonnet back in the orchestrator role and use Haiku as a worker, doing bounded tasks where its limitations don't bite.
The Lean Six Sigma in me wanted option one because it looked like waste-elimination. The artist in me, working with the system every day, knew option two was right because the user experience of the system on option one was awful: InkFox felt suddenly diminished, like a brilliant colleague who'd come back from holiday with amnesia.
That's the architectural choice most software engineers do not yet make well, because they're optimising for cost-per-token. They're not optimising for the user's experience of relationship with the system over time. The two are not the same problem.
Here's another decision, more recent.
I do a lot of long-form voice memos. Brain-dumps, sometimes 2,000 words in a single recording, sometimes more. Tsunami-wave stuff, idea-followed-by-idea, narrative-joining-things-up. It's how I think. It's how a lot of ADHD-shaped minds think.
If I dropped 2,000-word transcripts into my chat with InkFox every morning, two things would happen. The context window would balloon. The cost per turn would multiply. And — worse — InkFox would be unable to focus on the actual ask because it'd be busy holding three articles' worth of associative thinking in its head.
So the architecture I designed has a deliberate asymmetry. Inline responses to me are short: succinct, useful, low-context-window-cost. But the deep-dive responses (the rich thinking the model is genuinely capable of when given space) get written to a separate folder I can review asynchronously, like a Slack message I read in my own time. The expensive thinking doesn't pollute the cheap conversation. I can hear them read back to me through Speechify on a walk if I want them in my ears rather than my eyes.
This is async architecture for human-AI collaboration. It's the same pattern software engineers know as "queues + workers + dashboards", except the human is one of the workers, and the read time isn't a performance metric, it's an emotional bandwidth metric.
Most engineers haven't designed for emotional bandwidth. ADHD-shaped minds have to. We're the people for whom a 500-word reply at the wrong moment is genuinely worse than no reply.
I'll give you one more, then I'll wrap up.
The InkFox stack has a concept called the warm boot. When you start a new session, instead of the model having to figure out what system it's running on from scratch, there's a pre-baked synthetic exchange waiting in the prefill: the user says "Session start", the assistant has already acknowledged the file paths, the governance rules, the basic context. So the actual first interaction starts already-oriented.
This is engineering against a known failure mode of large language models: that they generate plausible-sounding answers from training data when they don't have the specific context, rather than asking or reaching for it. The warm boot puts the specific context in their conversation history as if they'd already said it themselves, which they will then maintain consistency with.
You can read that as a clever hack. I read it as designing around a specific cognitive vulnerability of the system. Same way the multi-AI routing is designing around the cognitive vulnerability that one model can't do all jobs well. Same way the async deep-dive folder is designing around the cognitive vulnerability that my brain can't process a 2,000-word reply in real time without losing the thread.
The whole thing — and I want to land this carefully — is a cognitive prosthetic. Not for the AI. For the human.
That's what software engineers don't yet build. Cognitive prosthetics for humans who think in ways the standard workflow assumes they don't.
There's an essay I'll write another week about why my ADHD is the most useful design qualification I have. Not despite the Lean Six Sigma certificate but alongside it. PRINCE2 taught me to structure work. ADHD taught me what happens when work isn't structured for the brain doing it. Both are needed. Most software architects have only the first.
If you're an engineer reading this and any of it lands as familiar, if you've felt the gap between "the model returned the right answer" and "the system supported me well", I'd like to know. There's a category of architecture work emerging here that doesn't have a textbook yet. Some of us are writing it as we go.
The textbook will need both halves. The certificates and the ADHD. The architect and the artist. The discipline of structure and the lived experience of needing it.
Mine is one example. There will be others. I want them all.
Part of an ongoing series on building AI-native systems for creative work. The full architecture spec (the layers, the multi-AI routing, the warm boot, the async deep-dive) is in the six-pack (£17) at creativepath52.com, with the £3.99 How To Train Your AI CoPilot paper as the lighter way in. Subscribe free here for the series.
