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.
Author: Eli Mydlarz
I just added Clocking In to Trunk Sync.
Now, Claude sessions are automatically aware of each other so they can better avoid and manage conflicts over files and other resources.
Many agents can work in parallel without any additional effort from you to integrate their output. It doesn’t matter if they are on OpenClaw, worktrees, or just running on local main. Everything stays in sync, agents work around each other, nothing gets left behind, nothing manual to do. If you’re confused about some code, you can summon the author with Seance.
Really happy with what I’ve been able to make Git do using Claude hooks and a little CLI. I’ve built a distributed file system for multi-agent SWE with some good and unique features.
Check it out here: https://lnkd.in/gWgaTwdP
With Seance you can turn any line of code into an interactive session with the coding agent responsible rewound to right after it did the work. It’s like reaching back in time to grab the original programmer just as they were writing the code and demanding they explain themselves.
Example here: https://lnkd.in/gJpW8qke
Lots of people are talking about how gen AI has brought XP to the fore, but I haven’t heard much discussion of why.
In my experience, many people simply didn’t try XP. They were locked into a tightly controlled environment, discouraged from experimenting, and constrained by process interdependencies. Maybe they didn’t have the influencing skills to get the rest of the team on board – it’s not easy to drive bottom-up change.
Did AI dev speed made experimentation simple and fast enough that anybody could try different workflows and observe the results?
Trunk Sync has a new “seance” feature.
Are you worried about inheriting AI-generated code you don’t understand? No problem, you can always talk to the guy who just wrote it.
Resurrect the long-dead coding agent responsible at exactly the moment in code and context when they changed that line. Learn how the code works and why it works that way straight from the programmer, rather than through post-hoc analysis (guessing).
Seance is a feature of Trunk Sync, which I use for extreme continuous integration with my coding agents. It was the challenge of not being able to personally defend main – normally my last line of defence – that drove me to create Seance.
Typical example at https://lnkd.in/gqMEeBE4 – wanting to know why a Docker image was changed.
In your project folder:
ppm i @susu-eng/trunk-synctrunk-sync install
Please remember, I am just sharing my own experiments. I only hope it’s interesting for you.
Trunk Sync: Maximum continuous integration for coding agents. Agents work in parallel on local worktrees, across remote machines – any mix, all with agentic conflict resolution. No resolving conflicts by hand, or discovering that an agent never pushed its work.
Seance: Talk to dead coding agents. Point at any line of code and rewind the codebase and session back to the exact moment it was written. Ask the agent what it was thinking. Understand generated code on demand and stop worrying about keeping up with every change your agents make.
Academic: When you can run multiple Claude Code agents on the same codebase from anywhere and without breaking each other’s work, your comprehension becomes the bottleneck. People are framing this as “cognitive debt”, and here we are exploring the far right of this debate – extreme post-hoc understanding. Don’t worry about cognitive debt at all – just build as fast as you can and make it easier to catch up selectively. I’m not endorsing – just experimenting and learning like you.
Caveats: There’s a flag for pushing Claude transcripts in case the session doing the work was on another machine or needs to be accessed after Claude cleans it up. A better version (please feel free to PR) would push transcripts to a server so they can be accessed securely outside of Git.
There’s another command for summoning the developer who instructed the agent to write the code, but that one is occult – best kept as an easter egg 😂
I’m sharing Thinker CLI.
You’ve seen me talk about how valuable CLIs are in agent-land already:
– Self-documenting
– Model domain objects and lifecycles
– Model workflows
– Provide fast feedback
– Teach agents incrementally (rather than requiring full usage baked into a skill)
– Run by any shell-using agent
Give an agent a good CLI and it can do _the thing_ even if it doesn’t know how, because _how_ is baked into the CLI.
Thinker CLI brings all these benefits _and it’s super simple_.
Thinker lets anybody define (and share!) a guided, multi-step thought process for your agent in a JSON config file. Agents follows user directions (or automation) to use Thinker with the config file, then Thinker walks them through the multi-turn process in the config file call by call using structured inputs, structured outputs, interpolation into templates, and strict validation. This way work is presented to the agent clearly, incrementally, and validated at each step. The agent can “think through” complicated work, programmed in advance.
I’ve been using this approach – human-guided CoT sequences with structured inputs and outputs – to great effect in my projects for years now. With good design, it _way_ outperforms the generalised reasoning processes built into current models. I’m really happy I can share it in such a simple way.
Used in an agent, you can define steps for searching in memory, saving back into memory, researching online, producing complex artefacts: Thinker CLI allows you to compose any of your agents functionality in linear sequences using natural language.
Links:
– If you want to read more: https://lnkd.in/g3khXusD
– If you want to tell your agent to install: https://lnkd.in/g-SzcWiU
– Example of a coding agent running it: https://lnkd.in/gyDxBNGv (I normally use Thinker with OpenClaw, but this was easier to get logs of. You see how any agent can use it)
Imagine a starting point – whatever you’re prepared to specify up front about your software. Then far to the right on the x axis imagine a solution. It’s perfect software – exactly what you needed.
Claude doesn’t know how to get from here to there in a straight line. It’s going to do a lot of trial and error – try a few things until something works. At each decision point, Claude might be moving up or down the y axis on its journey along x towards the solution.
Part of this vertical movement is produced by a dangerous fear of crashing: ‘What if this obviously intrinsically necessary field isn’t provided? I better engineer a crazy fallback.’ Anthropic this is my number one problem with Claude Code. Another contributor to extra complexity is that Claude makes confident guesses until it’s right and then moves on; typically the first thing that works is suboptimal.
This is software engineering as a combinatorial expansion of the guesses that happen to work into code, over time and tokens. At the end you have this kind of zig-zagging line – more complicated than it needs to be, but proven working. I think *overfitted* is the right word for it.
How are you managing this? For me, with one arm (session) I’m extending and with the other I’m pushing the weird adventures on the y axis back toward the most direct route – simplifying.
“Cattle, not pets” was a good phrase for helping people understand Phoenix servers, Infrastructure as Code – that whole concept. I like it a lot.
An equivalent for working with AI right now:
“Factories, not conversations.”
You are building a factory for producing output. If the output isn’t good, improve the factory. If you don’t like what it produces, arguing with the last person on the production line won’t help much.
I’m sharing again – this time a bit more fun.
Some issues I’m thinking about lately:
- Non-technical people vibe coding and frustrated by Git
- Very technical people running many agents in parallel and frustrated by Git
- Forward-thinking people running multiple agents in the cloud, and having them get stuck with uncommitted code
- The usual big-batch problems (see some of my classic topics: XP, CI etc.)
With all that in mind, here is a fun experiment: Trunk Sync. It’s maximum continuous integration for coding agents.
It keeps main and Claude-created work trees (claude -w) in sync with your remote trunk. Agents discover conflicts on write, resolve conflicted files and continue. Conflicts are resolved the same way between work trees, different hosts – it doesn’t matter. It’s just using Git and integrating on every file write.
Repo is here https://lnkd.in/gTCf6pSw and your agent can install it for you. Good example of it working here: https://lnkd.in/gpYe4X3t
Use with caution – understand this is an experimental approach and you will not be able to control what gets pushed.
Trunk Sync is extreme continuous-integration https://lnkd.in/gTCf6pSw for Claude Code. Easy agentic conflict resolution on write, keeps work trees, remote agents, everything aligned per write, using only Git.
I’m quite enjoying this – it was a deliberate jump out of my comfort zone (until now I kept commits under human control and resisted machine commits).
All my work is heavily tested, but naturally I am not running the whole suite on every file write – the main risk seems to be building atop an already broken build, which you could do very fast this way. So far so good, though.
