Writing on software, systems, and hard-won lessons.
Writing on developer experience, systems thinking, and the mistakes behind both - covering AI workflows, continuous improvement, and the mental models that drive better decisions.
Writing on developer experience, systems thinking, and the mistakes behind both - covering AI workflows, continuous improvement, and the mental models that drive better decisions.
With chatbots and coding agents we've all experienced those moments that make us stop trusting the first answer. From cheerleading to making stuff up to drifting off course. That's why sometimes we need to bring in a second AI (or more) and start using AI as an investigation partner instead of solution provider.
Politeness bias: I was showing a colleague how to use a chatbot help with a MySQL query. The AI acted like they just graduated top of the class. Cheerleading doesn't build trust.
Hallucinations: I asked an AI to add a test to a file. Once finished, that file went from 500 lines to 100 lines. I asked why it deleted everything, it said it didn't because the file didn't exist. Only after I showed it the git history, it admitted it should have checked first.
Drift: While vibe-coding a chess analysis tool, every new chat meant re-explaining the project from scratch. The AI kept "improving" my idea into something I didn't want.
Most of the time a single agent approach is the way. But those failures taught me when to bring in a second AI. Then, if still not convinced or both AIs disagreed, I would introduce a 3rd to the council of AI to argue it out.
Yes, Signal-Based Adaptive Orchestration is nothing more than a fancy name for "get a second opinion when something feels off." It's my way of trying to explain when to bring in the council of AIs to resolve disagreements or doubts.
I was trying to think of term about how/when I should use more than one AI, and was eating a Super tasty BAO at the time.
So yes, SBAO itself is common sense. But mastering the signals to know when and tactics for what to do is the more useful part.
Once a signal fires, these are the tactics I use to get more clarity.
Triangulation On my personal project I asked one coding agent to scan if a dependabot alert was a false positive. It said yes, it was a false positive. Since it was a security vulnerability, I brought in a second coding agent to check. It said no, it was a real vulnerability. That's when I introduced a 3rd coding agent to argue both sides. The 3rd agent agreed with the 2nd agent that it was a real vulnerability and explained why the first agent was wrong.
Context sanitisation I asked one coding agent to investigate a bug and the solution looked correct but seemed too simple. So in a fresh chat, I asked the same coding agent the same question without any context. It found a different answer that also looked correct but seemed too simple. Then I asked them to compare answers, and they said a combination of both answers was the best solution. They were still wrong, but it was a useful investigation tool rather than solution provider.
Adversarial cross-examination I was planning an seo scanning tool that has multiple personalities and I used multiple AIs to brainstorm ideas. Using the prompt, "rank these in a comparison table and rate out of 100 and why" then had each AI critique the others' ideas. The good ideas floated to the top and I was the final judge to pick which ones to implement, 1st, 2nd, 5th.
The automated version looks like event-driven orchestration with human-in-the-loop. Multiple AI agents doing their thing, but then the human senses something isn't right and intervenes.
Semantic chaos is a failure mode unique to AI systems: the system doesn't crash, it confidently does the wrong thing for plausible reasons.
Sometimes more than a single-agent approach is required. The Doer-Verifier loop has one agent do the work and another check it, like one coder and one code reviewer. Event-driven orchestration has multiple agents waiting for a trigger to spring into action.
Single-agent (well-prompted) One model does the whole job with good context and tools. Fast, cheap, simplest to debug. Fails via hallucinations, drift, no internal QA. Best for most low/medium-stakes tasks.
Doer-Verifier loop One agent does, another checks against criteria, iterate. Best ROI, catches hallucinations early. Needs good checklists, can thrash without limits. Best for coding, writing, analysis QA.
Event-driven orchestration Components react to events, decoupled producers/consumers. Scalable, parallel, resilient. Events don't guarantee correctness, can amplify semantic errors. Best for production pipelines, async workflows.
Signal-Based Adaptive Orchestration Event-driven plus semantic signals plus human checkpoints. Stops semantic chaos compounding, routes judgment. Requires defining signals and review gates, not "set and forget." Best for high-stakes or costly agent workflows.
This framework is nothing fancy, but it comes down to this: when something feels off, don't argue with the AI, get another one to argue for you. Or even better, discuss with another person - basically SBAO with humans?
What is claude insights: The /insights command in Claude Code generates an HTML report analysing your usage patterns across all your Claude Code sessions. It's designed to help us understand how we in...
A friend of mine recently attended an open forum panel about how engineering orgs can better support their engineers. The themes that came up were not surprising:
At work someone asked how to rank higher. I said wrong question, first check if you're sabotaging yourself. The most common problem is people make it harder for Google to find and/or understand what t...