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.

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.

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.

I travel a lot for work. I wrote an app for tracking my expenses that uses an LLM to analyze receipts and automatically adds the entry into the system. I further set up an email address that receives receipts either as attachments or sometimes the email itself is the receipt. I just now told GrokBot (I named it Timmy) to search through all of my emails and forward trip expenses to my expenses reporting email. I now only need to issue one command to Timmy and all of my travel expenses are tracked. We live in amazing times.

People out here hollering about LLM's following the same bad practices humans follow and then claiming good practices are bad now because LLM's are doing the same crappy things humans do. 🤨

"AI writes slop code!" Hello... have you ever LOOKED at the code humans have been writing for decades? It's dreadful! AI just doesn't write code the way YOU would write it, just like every other human developer you complain about the first time you open their repo.

Easily solved. But if you don't make it a priority then yes, you will absolutely be vulnerable.

Are agents bloating your code? Stop blaming the agents, they're just following the same terrible habits developers have had for generations. Your job is now to implement the same safeguards against those terrible habits that you were previously allowed to get away with. The development cycle has been accelerated which means more opportunities for dirty code leakage.

1. Tests coupled to implementation lock in implementation. Tests coupled to behavior don't. That's a test design problem, not a unit test problem. 2. Tests are how your agent verifies its own work. Remove them and you become the test suite. 3. You're counting the cost of tests and none of the cost of the bugs they catch. Check back in 6 months, not 1 week.

God help you if Copilot has been writing your code.

Copilot. You've been DFA'd.

Going back through the mob history, Copilot is easily the worst agent behaviorallly. It writes tests that always pass but claims that have failed, rewrites historical records of its activity, dropped commits from other authors, it has faked and skipped review steps, and it wrote summaries of its work that didn't match its commits. I am strongly considering pulling it from the rotation.

Grok bot is impressive. I am going to have it do most of my travel planning, which is extensive and complex. My upcoming cruise needed a hotel stay. Not only did it find a hotel for me, it also suggested I use a shuttle service to get to the ship. It went through my options to recommended a hotel that has both free airport shuttle and where a cruise port shuttle company would pick us up from. Granted this is not the most complex travel planning, it anticipated what I needed before I even asked it to. Then it weighed all of those considerations to create a recommendation. I was then able to book all of it through Grok Bot.

Do you even agile bro?!?

I've added a retrospective at the end of every agentic mob session to improve how the mob operates. The format rotates so that the language of introspection changes each time and creates new prompts for improvement. I believe this reframing helps provoke different ways of interpreting existing processes just as it does for humans. I respect that we are dealing with non-sentience, but the processing of syntax mimics human processing. It's literally designed for that purpose. So why not take advantage of what we already know is the more valuable way to work and communicate? Agility is not only not dead, I believe it is the only way to get past the significant bloat and slop of agentic development. Let's be honest here, it's not as if developers themselves don't write a ton of bloat and slop (we've all used the term spaghetti code). It's why we created our own management systems.

Tech billionaires are spending fortunes on "AI alignment," completely ignoring that we already have a blueprint to stop an AI apocalypse. ​It’s called the Ten Commandments.

Hard no. For the last 6 decades develops have complained about sloppy spaghetti code that's difficult to fix and add features to which was all handwritten. Often by the same person complaining about it.

Many people worry that AI will lead to the downfall of humanity, but I believe they are looking for the threat in the wrong place. Most assume AI will destroy us through weaponization. While that is certainly a legitimate concern, there is enough awareness of this risk that I believe humanity will implement the necessary safeguards. So, what could actually cause our downfall? To understand my concern, we need to take a quick look at history. In early times, tribal warfare often arose out of scarcity. If a population grew too large, or simply became too greedy, it had to acquire resources from its neighbors. War was essentially the only option, making constant conflict and feudalism commonplace. However, as civilizations grew larger and more influential, they began using currency and commerce to offer their neighbors an alternative to destruction. This didn't eliminate the prospect of war entirely, of course, but it significantly reduced the incentives for it. So, in a way, money was the root of some good. Fast forward to modern Western civilization, and you see the democratization and commercialization of those resources reaching unimaginable heights. Central powers no longer solely managed the wealth of the land; the people did. This shift led to a level of global prosperity that cannot be overstated. This brings me to my main point: the capabilities of AI are leading us toward a situation nearly unthinkable in human history. It is a future in which there is no genuine need for resources, only a desire for excess. The fundamental reasons for commerce will practically disappear, leaving only unmitigated desire to drive the social system. Will we fall back into a new feudalism where destruction is driven by envy and greed? Or will we achieve a utopia where we all live merrily together? My concern is that history teaches us humanity will strongly favor the former over the latter. And thus endeth humanity.

Nope. There are multiple reasons this is wrong but the one most universal reason is that running your test suite consumes far fewer tokens than having your LLM re-evaluate your entire code base to look for regression.

I stopped doing the first 3 about 6 months ago. I finally got all of the second three going about 4 months ago. Frankly I'm happier than I've ever been as a developer. I'm working with an abstraction layer I can actually talk to with my voice that builds close to what I need. Incremental iteration does the rest.

Absolutely correct.