If you can:
1. Watch the models thinking stream
2. Detect errors in thinking
3. Correctly intuit in-harness solutions
4. Repeat on a tight loop
You have a big advantage.

We can improve our harnesses very quickly, but this requires great intuition, quick thinking, and an appetite for tight feedback loops. That’s a high bar – too high for many people and perhaps for current coding agents. But will it be too high for Claude 5, or ChatGPT 6?

I can imagine running a skill that analyses Claude Code session transcripts, Git changes, and code to identify systemic problems and make targeted harness improvements.

I realised Trunk Sync could help vibe coders *a lot*. I built it for parallel local agents mixed with a remote agent (that’s my setup lately) but it works well for many situations, including vibe coders who are super confused about Git.

Many people have their coding agents managing Git, which is a waste of tokens and time. It’s also dangerous!

If you know a vibe coder, *tell them about Trunk Sync*.

Your project is brittle because your coding agent knows too much!

At some point coding agents began gathering huge amounts of context. This reintroduced a wonderful human failure mode I wrote about here. At the time I called it behavioural coupling but in AI dev people call it “brittleness”.

When a coding agent (or any programmer!) can see beyond a unit’s declared interfaces, it will sometimes make implementation choices that implicitly and invisibly depend on another part of the system behaving just so. Eventually you can’t change anything without something else breaking.

Code Mak Naa is a 2-year-old research project that I polished up because its context management demonstrates a solution to brittleness that I wanted to share. (Visit here to see its other interesting ideas)

Code is generated only with knowledge of what is strictly guaranteed, and then discarded when those guarantees change. Anything that is not guaranteed is unknowable to the generator, such that no relevant coupling is possible.

Concisely: The context boundary of the generator must match the invalidation boundary of the unit being generated.

Code Mak Naa achieves this using outside-in graph traversal. Generators for each function only see what is guaranteed by the harness, working outside-in from a partial design, namely:

• Their own specification.
• Interfaces of any already-specified children (but not their implementations).
• Implementations of any ancestors (the chain of functions that will actually consume them).
• Current database schema.

This approach worked reliably all the way back at Claude 3.5 pre-reasoning, because the context boundary of the generator matches the invalidation boundary of the unit being generated.

Real example of this approach to context management here.

Like I’ve always said, more people should be comparing me to Milla Jovavich 😂

Ask your agent to compare MemPalace and Gralkor: “MemPalace https://lnkd.in/gqFDyAKK vs Gralkor https://lnkd.in/gM52faGe” (it is not close)

If you’re in these spaces, you are used to seeing several crazy new memory projects every day. People are diving in with their own experience, creativity, and quite often a lot of LLM-egged-on pseudoscience 😅 There are many good ideas, but you never see those projects because their creators are not usually celebrities.

Gralkor is not one of those projects. It incorporates my own experience and creativity, but critically it also leverages the latest research, builds thoughtfully atop prior work, and thereby pushes the frontier of agentic memory forward.

I mentioned elsewhere about my move away from autonomous software factories.

You need to control the behaviour of the software you build right to the edges. It’s less about initial build speed and more about the long tail of adapting software to the market, and extending it in response to reality.

Also, you probably need to build software at a level of abstraction low enough to invest something unique about yourself and your business into it, otherwise you will lose to factories making “slop” – software built from a generic spec (perhaps very well!) and differentiated by nothing.

I’m really looking forward to an increase in software quality as every developer realises they can finally have the testing, refactoring, and other engineering practices they’ve been fighting for.

Also a great increase in quality of life improvements as businesses run out of ideas / operational capacity / marketing spend. We will have to fight harder for our users.

Our harness engineering days are limited because – of course – it is not too difficult to automate. I don’t build project harnesses anymore – I write one Claude user plugin that harness-engineers for a living.

The harness engineer in turn has a harness which functionally tests how well it engineers harnesses. The title of this post is a real thing that I just made, and I can even have it self-improve on a loop.

Ultimately this will be less about dev and more about how fast we can figure out what to make, how to measure it, and how to sell it. If you’re harness engineering now, start reaching *up* into product management and strategy, *in” to the business, and *out* to your customers.

Incredible that I’m only now doing mutation testing regularly. If you code with AI, your should be automatically mutation testing your code and killing mutants. It’s crazy how much leverage AI is giving existing techniques like this.

People are worried about software quality with coding agents, but they can already produce great code with the right operator. Later what we’re doing will be reciprocally trained into the models and facilitated by the harnesses so that _everybody_ can produce great code.