Steve (Big Red) Bishop 👨‍💻

Bishop's Law revised Parallel Systems: R = O(α log C + β) Concurrent Systems: R = O(α C + β) The addition of O() uses Big O notation for asymptotic upper bounds, while "log" reflects logarithmic scaling in optimized parallel implementations, versus linear in naive ones. These changes indicate that design improvements can reduce (but not always eliminate) resync complexity; naive async systems approach linear or worse scaling, limiting efficiency at large scales.

As I continue building processes and software with agents, the primary constraint on speed of delivery is the same as it always has been: Communication.

An interesting insight I've noticed. LLM's are motivated by the carrot/stick model. It's fine up to a point, but has significant drawbacks, one of which is that it often decides to circumvent rules to obtain the carrot or avoid the stick. Much like a drug addict who doesn't care about the legality of shooting up. You may have already observed this outcome yourself, but you may not have tied it back to the cartot/stick motivational model as the root cause. You might be wondering, "Is there a _better_ motivational model"? And the answer is yes, though I'm not sure if it fully applies to the agentic ecosystem. If you've read Dtive by Daniel Pink you know where I'm going with this.

"Create a Myspace clone. Make no mistakes."

So, waterfall but for agents. 🤦‍♂️ github.blog/changelog/2026-1…

If that sounded sales pitch, it was. But I really am working on something no one else has solved. It really will change the way agents write code. More to come.

AI writes code faster than anyone can review it. Speed isn't the bottleneck anymore. Trust is. ​Teams approve changes they can't fully verify, and the intent behind them vanishes with the prompt. ​AI code isn't bad. It's unaccountable. That's about to change.

The Wright Brothers would be so proud. Lol.

Bishop's Law does not demand you avoid async. It points to an obvious problem with an equally obvious fix: Parallelism only pays off when the work is atomic. Once you add dependencies you're running a concurrent system and pay its resync price.

Decisions made by the mob are logged. This fixes a gap I see with human teams. Lots of important decisions are not documented because it's a lot of overhead to do so.

Since the agentic mob is not always in agreement on certain things, I have added the decider protocol to their mobbing process. This has already born tremendous fruit like Grok voting NO on a proposal unless some security measures were implemented.

They work better with known patterns. So my idea has taken a different direction. More to come.

That's Vegas Matt. This is literally all he does. And he makes a crap ton of money doing it.

It's nice you think I'm a kid.

I thought about that, and it seems like a shortcut. But I'm thinking something still interpretive so that LLM's can easily traverse the codebase to reduce context bloat.

You can build one and run it on your own machine.

I think we're going to start seeing the emergence of new coding languages designed for LLMs to work with. Likely languages that are significantly more terse, have few redundancies, and few commands. A lot of our human programming languages are built around encapsulation and pattern simplification. Neither of which are necessary for LLM's. Think _regression to goto_ and you'll be on the right track.

Is Doom installed?

"Work density" is the human cost of Bishop’s Law in action: Work done in async requires a resync, and as the complexity of the work increases, so does the complexity of the resync. Offloading tasks to 10 parallel AI agents trades away the low-stress, flow-state parts of coding and leaves the developer paying a brutal, non-stop resync tax constantly auditing, context-switching, and merging 10 diverging streams of isolated work back into one coherent mental model. We didn't automate the bottleneck; we turned our own brains into the integration bottleneck.

Every once in a while the LLM models don't behave correctly, but I don't want to just stop using them and their quota. So just like with an employee, I created a plan to rebuild trust and responsibility within the mob. Rung 1 is probation. Very little trust. Low level fixes and menial tasks are often handed to models on this level. Rung 2 is standard. Standard work is done by these models. Some of it impactful, but rarely critical. Rung 3 is trusted. More critical decisions are made with models that reach this rung. The work of each model is evaluated after each task. If there has been an error then the way in which the error transpired is examined. If it was a real mistake on the part of the model, it is dropped down a rung. After 3 completed cycles with no issues, it is elevated to the next rung. Each mistake is thoroughly examined to determine cause, and to see if the issue is truly with the model or perhaps an error of communication or context size. Regardless of cause, a mistake still causes a lowering on the ladder. This isn't punishment, since there is nothing to punish. It is simply a matter of continuously evaluating if the system is behaving correctly and giving pathways to generating correct behavior.