Ping. Ping. Ping. I would spend all day tab hopping between a dozen Claude and ChatGPT sessions. It felt like babysitting a group of needy kids. Jumping into one tab, trying to remember what I was working on, struggling to context switch, and then having to provide new input to each model. Tabs would keep pinging up requiring my attention and it felt like an increasingly difficult game of whackamole.

For the first few weeks of this, I felt a strange mix of awe and burnout. Awe at the volume of work I was achieving. Burnout at the sheer pace and mental taxation. It came down to how much information my brain was being forced to process. Usually the execution of a task (be it coding or otherwise) allowed enough time to mentally process the question of “What next?”. Not so anymore. The blocker was now my ability to keep up with the models!

For the first six months of building with AI, we were firmly in the “token maxing” era. Like I used to say to my team: “every single task you are about to do, ask yourself: can AI do this for me?” Of course, for some tasks there will be no real net gain; it’s faster/easier/better to just do it yourself. Or so it may seem. But the mere act of considering opens your eyes to the possibilities. And seeing more of the world unlocks more options, more skill and more leverage.

But eventually the problem flipped. The challenge was no longer getting the models to do enough. It was keeping up with them.

From coder to manager

Over the past year, I’ve had to get skilled at building software with AI agents. I didn’t originally train as a software engineer, and at first, I thought this would be a hindrance, but the more I build the more I realise that ‘systems engineering’ is the right lens here too. Everything is systems.

I’m lucky, really - coding is probably the highest level of ‘permissionless leverage’ (borrowing a concept from Naval), and until recently I used to wish I had studied software instead of engineering, but now I know I made the right choice. My systems experience gives me the ability to consider different lenses, different layers of abstraction. I think this is really the skill of a systems thinker - to be able to transcend levels of detail and only get into the weeds when required.

People say code has become commoditised. And I agree to some extent - boilerplate code has. But not architecture, taste, or product.

I liken building with AI to people management. You are still held responsible for the output of your team. And just like your confidence in their ability, independence, and output is built over time, such is the case with your AI team.

Your job is fundamentally this: give your AI team direction, and enough rope to manoeuvre, err and self-correct, and learn, but not enough that they can actually hang themselves and cause major disruption to the project. And we already have an excellent framework for delivering this kind of feedback: management! So praise, castigate, encourage, dissuade. Regular feedback (often accompanied by “remember this”, or “and update CLAUDE.md” to ensure persistence) is key.

Training your team is just as important with AI as it is with people. Going back to the classical “intern with a PhD” analogy - you wouldn’t expect your intern to understand your way of working on day one. Or, for that matter, why you are trying to achieve what you are.

The why is super important. Give someone a specific instruction and they will probably be able to execute it, but the moment they hit an unexpected snag, they will have to come back for more instructions. Tell someone why, and they have a mandate. A higher-level reason from which they can deduce the what, and adapt to changing circumstances.

Now of course there are limits here, and it’s important to control the level of autonomy (not giving them too much rope!).

Autonomy requires a feedback loop

After about GPT-5.4, I found the models were good enough to write code by themselves that I didn’t necessarily need to review (clearly this depends on the maturity of the codebase being worked on - I was building a POC here).

And to enable this, I had already worked out that they needed a concrete feedback loop to be able to validate their output. This can be tests (unit, contract, E2E), or even browser automation with frameworks like Playwright, which the agent can use to control a browser and actually click through the different UI elements (pretty astonishing the first time you see it).

This was not merely trusting the model more. It was giving it a way to work out for itself when it was wrong, and to self-correct. So, I was trusting the system itself.

I’m a big believer in learning compounding from different domains. Systems engineering had already taught me that autonomy and validation go hand in hand. If you want something to operate independently, you need to give it an environment in which it can observe the consequences of its actions and catch its own failures.

The attention problem

But despite this invaluable feedback path, I still found myself getting really mentally worn out.

To this end I’ve been working on ways to remove myself as a blocker.

One good way I’ve found is by using proposals. These are similar to the kinds of plans that used to be necessary in order to get good model results for long-running tasks. The difference is that proposals are HTML documents, which means they can be much more graphical and intelligible, and can be as dynamic / interactive as needed.

Proposals serve a dual purpose: both as an agreed set of objectives and plan for the models (which they can track implementation against), but also crucially as a human-focussed idea aimed at clarifying human understanding.

I created a skill which knows how I prefer these proposals constructed and formatted (executive summary in a few sentences at the top, section 1 is the idea, section 2 is the evidence, section 3 is the implementation plan and section 4 is the actual progress ledger). I like to work on a proposal as a co-author with the model until I’m happy with it, then set it to a status of ‘accepted’ (from draft). It can then be queued for implementation.

This idea was inspired by Jeff Bezos’s description of Amazon’s six-page memo culture: before discussion begins, meeting participants spend the start of the meeting reading the memo in silence. The LLM’s job is to make the proposal easily digestible so that people don’t waste valuable brainpower on deciphering.

The benefit of working this way is asynchronicity.

Because my proposal skill is constructed to split the work into phases and tasks within phases, the effort of orchestration and planning is handed over to the model. Phase 0 always involves a front-loaded examination of the codebase to prove the viability of the proposal and surface any questions at the start. The AI is instructed that it should resolve any ambiguity at the start, and that it’s not allowed to ask questions (unless critical) at later stages.

This way, I can spend five minutes answering the front-loaded questions (always with a multiple-choice tool), and the agent can then go about implementing the rest independently. This could mean 2-3 hours of uninterrupted work, allowing me to focus on other things.

The aim is to consolidate the points where my human judgment is needed, rather than allowing them to arrive unpredictably throughout execution.

Delegating supervision itself

What makes this even more powerful is my ‘orchestrate’ plugin. I built this to hand over a few processes to the AI that were causing me unnecessary overhead.

Firstly, the choice of model. My skill defines the capability needed for each role, then maps an appropriate model to it. As at the time of writing, I’m finding best results with Sonnet Max thinking for research/low-level implementation, Opus High for orchestration, and Fable Medium for adversarial review - more on that in a second.

The second thing is dynamic team structure. This is the ‘agent graphs’ hype that people have been talking about lately, and it is incredibly powerful. Imagine being able to spin up the ideal team for any task at hand. For a particular task, you might want a project manager, two junior software engineers, one senior, one lead, and one quality analyst. That is the kind of organisation you can represent and execute as a dynamically constructed agent graph.

My ‘orchestrate’ skill spins up a team structure where the junior engineer (a cheap model) does the groundwork and first draft. Then the orchestrator (a medium model) checks the work and can discuss with them and change their direction or provide feedback as necessary. Finally, once a solution is ready to be implemented, it gets ‘signed off’ by the lead engineer (an expensive model), who does an adversarial review: purposefully attacking the solution with the aim of trying to expose flaws in it, just like an adversary.

This also creates a tiered escalation path. The first agent should try to resolve problems itself; if it can’t, or if validation or review fails, the issue moves up to a stronger model. Only genuinely consequential ambiguity should make it all the way back to me. Human attention sits at the top of the escalation tree, not in every loop.

The clever thing about this is that the orchestrator can decide how many of each role is required, what they should work on in parallel, and how many review loops to facilitate before acceptance.

You have now taken yourself out of the low-level work, and used the power of different models, with different prompts, to reduce the chance that one model’s blind spots pass straight through the system unchecked.

So why not just make the lead engineer write all the code? For the same reason Google isn’t just made up of staff engineers. Cost!

One even more powerful trick is to use a completely different model provider for the adversarial review. These days I use Codex Sol, because the models can talk to each other by invoking the CLI tool. Using a different model family and provider can further reduce exposure to correlated failure modes (although they will inevitably share some training data and failure modes).

At this point I had delegated not just the implementation, but increasingly the supervision of the implementation too. Now I had unlocked hours of uninterrupted running, including overnight, with my team of Claudes working autonomously while I slept.

The organisation matters more than the individual model

There is also a clear lesson on vendor lock-in.

Because these models evolve at such an unprecedented pace, it’s critical to keep trying and testing new models, model families, effort levels and prompts. By having the team structure and cross-vendor adversarial review described above, you harden your position and reduce exposure to the fragility that comes when a model’s quality suddenly degrades.

The important thing becomes the role the system needs, rather than the specific model currently filling it. Thus, the model becomes an interchangeable component, while the organisation and the harness around it become the durable assets.

The progression for me has therefore been less about getting better at prompting, and more about repeatedly asking how I can remove myself from the next loop.

First, the models could write the code. Then feedback loops allowed them to validate it. Proposals allowed ambiguity and human judgment to be front-loaded. Orchestration allowed the models to start supervising and reviewing one another.

The constraint has changed. When AI cognition and execution become abundant, the scarce resource becomes human attention.

That means the core question is no longer simply how much work I can get AI to do. It’s how much useful work the whole system can produce, for each unit of attention I have to give it.

OBDII-MCP on Github

Recently, I replaced my car’s battery on a hunch. It felt like the car was struggling to turn over on cold starts, but there was no clear sign because there were no fault codes. I consulted AI and it came to the same conclusion. But this made me think: why am I in the diagnostic loop here, providing indirect, second-hand evidence to the AI? Why can’t the model just talk directly to the car, read the actual voltage data and perform any required tests?

Unfortunately, I didn’t have the tech for that. So I decided to build it.

I decided to build an MCP server that would bridge the gap between the model and the hardware. I started with a cheap Bluetooth OBDII dongle (OBDII is the automotive standard which defines diagnostic services and modes), which provided the bottom of the stack. This would allow serial Bluetooth communication between my laptop and the vehicle, and would implement the low-level CAN framing and request/response for me out of the box. This in turn meant that I wouldn’t need to implement a driver; the ELM327 Bluetooth dongle is the driver, providing the interface with a known and documented command set. I did, however, notice at this stage that these chips have a somewhat limited bandwidth - which would limit how many parameters (and at what frequency) I would be able to stream at the same time, and would shape the architecture.

On top of the ELM327 transport layer, I built out a PID (parameter IDs, such as motor RPM, or battery voltage) querying layer, used by OBDII. I then built a service layer on top of this that would expose tools to the MCP server. “python-OBD” would have handled most of the bottom half, but I’d already written my own by the time I properly looked at it, and since mine worked and I understood it end to end, I kept it. (It’s also GPL, and I wanted this MIT-licensed).

So the architecture stack looked like this:

While building the MCP tools I came to the realisation that there would be no need to implement diagnostic taste or logic here. I watched the model chain PID reads and reason about them without any hardcoded logic from me. Instead of building something like “check_charging_system()”, I designed purposefully thin primitives such as read a PID, list supported PIDs, read DTCs, open a stream. I had answered my own question: the intelligence no longer belongs in the application, but belongs in the model. I just needed a safe toolset for the model, which I provided by building exclusively read-only commands into the PID layer.

In order to make the MCP server testable (without relying on having the hardware in the loop), I built a light Streamlit application which enabled streaming selected PIDs, and built a way to record the stream to a JSON file, then to replay from the stream. I used the streaming feature to visualise the battery voltage, and then applied an electrical load (winding down all four windows at once). I proved the end-to-end integration by seeing the battery voltage dip in the graph at the same time:

I also recorded a session driving around the block, to prove the ability to record and replay the diagnostic session - an invaluable feature for diagnosing actual dynamic driving data.

At this point the project had crossed an important threshold: the AI was no longer just helping me reason about the car from photos and descriptions. It had a structured, read-only, interface into the vehicle itself.

So now I had something that worked well for my specific car, and for the default list of PIDs that I had pulled from online. But to make this project useful for other car models and manufacturers, I thought it would be useful to implement a discovery functionality. Effectively I wanted the LLM to ask the car “which PIDs do you support?”. This would pair nicely with the general MCP design philosophy - allowing auto-discovery rather than hardcoding capability. OBDII already supports this with so called “Mode 01 PID discovery”. So I built support for this for both the MCP client and the Streamlit dashboard, enabling users to connect to the car, ask what PIDs are supported, and then select what they wanted to see from the dynamic list generated in the dashboard (or indeed the LLM could do this itself over MCP).

Clearly there are limitations to this approach - I won’t claim that this tool is the answer to all car troubleshooting: far from it. While working on this project I also had to replace the car’s rear windscreen wiper motor, and when doing so I needed to take physical voltage readings at different points in the wiring loom and feed these into the model. The car doesn’t expose this over OBD. Equally, performing a simple voltage under load test (especially without knowing the load current) doesn’t give you a complete battery health test. But had I had this tool I could certainly have made a much more informed decision, especially by doing a few variations of load tests (combined with AI’s ability to pull datasheets and infer specific load currents).

Reflecting on this build made it clear to me that the reasoning boundary has shifted, and will continue to do so. As AI models get more capable, what real value is there in hardcoding “diagnostic intelligence” into the application? The new approach should be to provide the model with the right tools and harnessing, and then to get out of its way.

I thought back to how early waves of frontier model releases killed early AI companies, which relied on products that were fundamentally little more than an AI wrapper. How should today’s applications be built to prevent them becoming obsolete in six months? One approach appears to be to build with the rate of change in mind, and to fully expect that most of the reasoning should be done in the LLM layer. Thus, if reasoning is no longer the competitive moat, then perhaps it is data, domain expertise, harnessing and tooling.

OBDII-MCP on Github

The corner problem. “What if we moved the gusset by 5mm towards the vertical member?” By this point I was struggling to keep up with visualising the complex 3D geometry in my head, and it took me a good 30 seconds to remember what a gusset was again… and suddenly the conversation had moved on and someone else was offering technical observations about why that particular solution wouldn’t work, receiving nods of understanding from the room. The issue was that I was only a few months into real engineering, and despite being the work package manager for the battery pack we were discussing, I wasn’t fluent enough in the technical concepts to contribute much of substance. I kept my mouth shut.

Over the past five years of my career, I’ve often been in rooms where I’ve been outmatched. It’s become clear to me that fluency - the ability to use the jargon - and deep understanding are not the same thing. Every time I thought I had a rock-solid mental model and could speak the jargon, some new concept would present itself that everyone else was seemingly already familiar with, and which meant little to me. This, as I have come to appreciate, is what it costs to have responsibility beyond your experience, alongside genuine experts. It’s how I’ve spent the last five years at Sunswap - the cleantech start-up I joined as one of the first employees - and it’s how I’ve developed the ability to learn and compress fast.

Being outmatched isn’t an overstatement. I’ve worked alongside engineers with decades more experience than me, and it’s a specific, daily, uncomfortable cognitive experience. A feeling of not being able to keep up, processing slower than everyone else, and often slight embarrassment at stalling the progress of discussion. And yet, as I’ve progressed in my career, I’ve come to a crucial realisation: this is exactly the room I want to be in - the one in which I’m outmatched.

That doesn’t necessarily mean being outmatched on every front. I’m a jack of all trades, master of some - but in the domain at hand, I’m outmatched. My thesis is simple: there is no greater motivational driver for learning than imposter syndrome. It’s a quality I see in all those I respect most: only those who are blind to their true ability have the complete confidence to never self-assess.

My solution: learn fast. Learning the language of the domain came first. In school, I would roll my eyes at having to rote learn terminology. There were more interesting things to be getting on with, but perhaps I wasn’t fully appreciating the power of compression (forgivable, in fairness, for a 14-year-old). Now that I work in AI there’s an obvious parallel: context window optimisation. Just like LLMs - which can only process a fixed number of tokens at once, with quality degrading as the context grows - people can only process so much information in one chunk. Being able to use precise and domain-specific language is effectively a context compression hack: the information conveyed is succinct and specific enough that the meaning carries through with very low cognitive load. Naming a concept allows you to refer back to it with ease, without convoluted explanations. I remember always being struck by one particular colleague who would focus hard on picking the right words, so much so that he actually spoke quite slowly. At the time I thought this was over the top, but I later came to realise that this is evidence of an incredibly valuable and rare skill: the art of concept compression in real time, and the ability to distil meaning into its purest form.

Another instrument is a mental model. Take the example of a “sacrificial element” - a purposefully weak link in a chain that allows you to control which section will fail first. We used this in the battery pack design with our fusing architecture. We knew the sacrificial fuse would fail first in an electrical fault, so we deliberately located it outside the main pack area, allowing the pack to stay serviceable without invasive repairs. By labelling the concept in two words, everyone conjures up the appropriate mental model, which means it occupies the minimal amount of “context tokens” possible and enables faster discussion. Or (to appropriately compress the idea): compression.

But labels only work if there’s something real underneath them. Mental models have to be discovered first, then labelled - not the other way round. They have to be earned, like achievements in a video game. A few years ago, having discovered Charlie Munger (who popularised the concept of mental models) and Farnam Street (an online community dedicated to the subject), I attempted to create a giant poster of the most common mental models, hung it on my staircase, and tried to memorise it - an effort that quickly proved unsuccessful. Mental models are like a one-way function: you can easily calculate the output from the input, but not vice versa. It’s the same reason why book summaries don’t work long term. Your brain is effective at compressing concepts, but only once the underlying understanding is there. Without the work, the label has nothing underneath to attach itself to. However, I’ve found mental models to compound and pop up across domains, which is what makes them so powerful.

Beyond language and models, there’s first-principles thinking. A truly deep understanding of the domain space. Things like: what really is voltage? Every engineer will claim to understand voltage. Few can explain what physically causes it: an imbalance of charge at the particle level. My cheat code for first-principles thinking has been YouTube. Channels like 3Blue1Brown, AlphaPhoenix and Ben Eater have been invaluable in refining my models over the years. The videos worth watching I watch three or four times. Now I share them with my team. First-principles thinking is compression at the foundation: knowing what a concept physically is, so everything above it can be rebuilt. After all, if you can’t explain it at a whiteboard, do you really understand it?

The good news I’ve found is that compression compounds. I first noticed this two years in. By year three, after a concerted effort to deepen my electrical knowledge, it took me by surprise how fast new domains were becoming accessible. Not only are concepts transferable across domains, but more deeply, the framework for operating in ambiguity and getting up to speed quickly becomes a powerful weapon. Over the past couple of years I’ve found the same with AI. Ultimately, everything is systems. The skill of moving fluidly between levels of model complexity transfers everywhere. Now I use AI the same way, as a tutor for whatever domain I’m currently outmatched in. The compression habit just found a new instrument.

So being outmatched is the formation I’d recommend, if you can tolerate the discomfort. Studying compression won’t make you a compressor. Being in a room where you are outmatched will. This is the signal I look for now - if I’m not outmatched, I’m not at the limit, and there’s no room to grow. Every new expert colleague who joins Sunswap is an opportunity to be outmatched, and to learn from the best. Compression compounds.