yeah, but not at scale; you can now spin up 20 bike shedding agents and flood anyone of your employees/coworkers.

It comes from C. Northcote Parkinson's work, where he calls it "The Law of Triviality". The idea is that people clog up decision-making by introducing a swarm of issues that have little relative impact or importance for the project at hand, leading to a massive misallocation of attention. His example is a $10 million construction project for a Nuclear Reactor where as much time is spent debating the materials to be used for a $3000 bike shed as on the actual reactor buildout. The law of triviality says "the time spent on any item of the agenda will be in inverse proportion to the sum [of money] involved."

Source: C. Northcote Parkinson, "Parkinson's Law and Other Studies in Administration" (1957)

LLM increase the range of things bikesheddable, so some folks will try to have a LLM design a nuclear reactor and manage the coffee budget in addition to the traditional bikeshed design complications. Whether this is an improvement or more engines of what passes for civilization catching on fire, well…

It's a low-effort drive-by comment, but I read it as tourists prompting about an issue they don't really know about.

People will recognize a glimmer of something they can attach to, prompt and get a few pages of junk about this narrow topic, and then contribute it in a way that further reduces the signal-noise ratio of the discussion or project.

Like, dude, we have the same tools. We can get the same slop from the tap at any time.

This is where the harness shines. It's why products like Cursor have been growing like crazy. If you drop an extremely intelligent person into a problem they've never seen before, the initial context and knowledge-sharing just to get them up to speed is immense. They'll make a lot of mistakes until they're ready to fix your problem. The harness can leapfrog most of that. There is a booming industry in harnesses with no saturation in sight. We're not even close to maximising the utility of current models, let alone the amazing improvements which are happening week to week.

An agent doesn’t know what “job” it’s being asked to do until you tell it.

Imagine you’re blind and deaf and have temporary retrograde amnesia. You “wake up” one moment with a memory of some words in your head like “what is the bug?” …but you don’t recall the context of that question, and nor can you look/listen around to observe the context.

So you don’t know whether you’re e.g. at the office, in front of your computer, in the middle of doing some pair-programming (where, yes, you’d in investigate the bug thoroughly with tools), vs. having a conversation with a colleague over lunch (where the expectation is for you to tap into your knowledge + intuitions to either guess or say you don’t know — not to pull out your laptop.

That’s what it’s like to be one of these LLMs being prompted by some agent harness. Unless the harness injects the proper context into its “recent memory”, it just doesn’t know.

If you ask Fable or 5.6 Sol to improve performance, it will generally know to build a benchmark and create a test corpus. I'm not sure where the contrary suggestion is coming from.

Additionally, if you are asking agents to write test, be very careful. They will write tautology tests.

They will mock things to no end. They will flat out REMOVE assertions (saying it's not needed). They can also write test to assert the wrong result.

You have to always review it, it's exhausting.

Will, it depends on the AI. Anthropic used to have a lecture-length system prompt for their models to explain this stuff—part of the secret sauce for Claude Code—and famously found that the 5 series models no longer need it.

As usual, if you use anything but the best model available I’m going to state that the better ones do better. If you do use the best model available, then I’ll just mention that Fable still has limits and still needs some guidance.

One thing it does not do is deliberately build tests which test nothing at all, or which restate the code under test. I mention this because certain other models absolutely would.

"Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth

Tests prove the things you thought of worked, and it often isn't hard to find the likely edge cases such that you have reasonable confidence everything works. You will be wrong from time to time, but not that often. You can prove code correct, but if the proof is wrong (common when a human is doing it), or the spec is wrong (most people have no clue how to write a comprehensive spec) it can still be wrong.

Haven't you ever written tests that assert that certain things happen or do not happen along the way? We use mocks all the time to, say, make sure that the code doesn't load the entire db in memory. Then it's there as a regression if somebody down the line wants to do that exact thing for some reason.

Manual testing.

I work on user facing applications, and since the models do not have good taste, testing the UX is essential.

If you spot a bug, usually the model will attempt to reproduce it in a new test case that does cover the actual issue.

1st line of defence, use something like ponytail to enforce brevity. Use property testing and behavioural testing on top of unit testing. Enforce readability standards so you will be able to understand the tests.

2nd line, code review.

Do the first pass with an agent, ask it to bounce back vacuous or tautological tests. Ask it to verify that the tests verify what they claim to. Then read them yourself.

3rd line, mutation testing. If the tests don't actually catch broken code, kill the mutants.

Read the tests.

Doing a pass where you just ask the AI to sanity-check the existing tests (against rules like “test against the spec, not the implementation” can also help.

Existing tests.

"tests" here could mean have a benchmark the agent can run to determinately evaluate quality.

I don't strictly mean junit unit tests.