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.

I expect the casinos to call any sort of advantage the players get to be called cheating. What I don't expect is for judges to agree. What Phol did was absolutely not cheating. Social engineering yes, but not cheating.

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. 🤨

Interesting data, wrong conclusion. This eval shows that test-after tests which mirror the implementation don't improve a one-shot benchmark score. That is much narrower than "AI-written tests are empirically proven unhelpful." Start with the stats. 147 vs 145 of 222 is a 2-task difference. The 95% CI on that gap is roughly ±9 pts, and wider still because runs cluster by task. On the 44-task subset it's about ±20. "Not significant" means the eval can't detect effects that size. It doesn't mean they're zero. The benchmark also can't measure what tests are for. DeepSWE grades one patch against hidden tests and then discards the repo. Tests pay off on the next change: regressions, refactors, CI gates. An eval with no next commit scores that benefit at zero by design. The only stat-sig result is cost, and writing tests obviously costs tokens and time. You measured the expense side precisely and the benefit side not at all. Your own diagnosis is the real finding: the tests were "a repetition of the implementation." That's the textbook test-after anti-pattern, and humans who write tests that way get no value either. It's an indictment of how the tests were written, not of testing. The point that the same agent interpreted intent twice is half right. Tests can't fix a misread spec. They do catch the gap between what the agent meant and what it wrote: off-by-ones, missed branches, broken callers. How much they catch depends on test design, which the eval didn't vary. Disabling existing tests had no effect, which is plausible when the repo's suite doesn't cover the area each task touches and hidden grader tests define success. That tells you about benchmark task coverage, not whether a regression suite protects a living codebase. A better experiment would be test-first and outside-in, with acceptance criteria derived from the issue before any implementation exists. Score test quality with mutation testing. Then measure across a sequence of dependent tasks on one repo, where regressions can actually happen. You already flagged the most promising arm: humans specifying intent as executable examples. That's just BDD. The right takeaway isn't "stop writing tests." It's "stop writing tests that restate the code."

"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.

Talk about blaming the arrow not the brave.

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.