Benchmarking Opus 5 on SlopCodeBench

It seems like we all tried to contain and organize a system that simply prefers to select its own organization.

Which makes me to think that these skill packs of workflows are really made to make it easier for humans rather than agents.

My typical workflow when AI assisted is what I call human gatekeeping... I'll plan out next steps with the agent, updating a TODO.md file with what needs to be done, then a fresh context to implement the next step(s), and review the code before committing to git. I may iterate/stash or even reset a few times before it's "good enough"... it is rarely close to what I would do myself, but often as good as what I've gotten from other developers IRL on projects.

This includes updating the documentation area(s) of a project as well as testing. I also tend to lean on ./run/* for scripts that will run/test various portions of the project... getting the agent to use these is sometimes harder than it should be, as I want it to specifically exercise a lot of things through the process... there are also times where it will try to change a valid test that's failing instead of fixing the code. That's the most irritating part. Some models are annoying, some feel like pure magic at times.

Labs do not train on benchmark data (allegedly). They can train on similar problems, but benchmarks have specific strings in them that labs are supposed to be aggressive in filtering out of their training corpora.

State space of a system AND the way to make it accessible / visible to a model. Many times a model can work magic if it can "see" the state of a system in a way that suits it. That's why sometimes having a cli added to the environment seems like such a big unlock. Because that cli usually takes a complex state and allows visibility into it, and possible manipulation in a structured way.

this is a nicely succinct way to put this - a multi-dimensional space where no single metric is really useful

state space of the system is interesting too. I would guess that for any production software with dependencies like databases/third parties that might be too hard to measure, but if you can silo off parts of your system into bounded state machines, it may be a value metric on some module behind a clean interface.

I think the kubernetes control loop model is a great instance of this, a handful of scoped components that own a control loop across a well-defined state machine, that can operate / recover in the face of most network partitions or downtime - the promise of CRDTs but rather more a pragmatic approach to it

There’s this notion of variety popularized by cybernetics folks a long time ago. Variety is like the state space of the system. Then there’s a law that says “only variety absorbs variety”.

So if a method has high variety then it must have an equally complex implementation to handle the variety.

When there is a mismatch it means that either the method has parameters that aren’t useful, or that the body of the method isn’t covering cases it should.

https://fffej.substack.com/p/only-variety-can-absorb-variety was my attempt to write it up more fully.

Maybe, but "maintainable" has a simple definition: minimising the effort to incrementally grow a software system as its size grows to infinity (while maintaining some defect ratio). Humans (called senior software engineers) figure this out over decades by working on a number of large software systems.

So far models haven't figured the same thing out. I can only guess why. All their learning comes from examining code on the internet. Somehow whatever the patterns are that make large software projects like the OSs maintainable by large groups of people working independently has escaped them. Maybe the bulk of code they look at is in the small so they miss it, maybe the patterns are just hard to discern in big systems.

My theory is there are anti-patterns which the larger projects somehow manage to keep to a minimum. It's hard to learn something that's not there. Instead, you learn these anti-patterns by doing them, and watching a system all fall apart over the course of years, and if you're good you manage to pin the blame on the right thing.

If you want to wrap it up neatly in a package, models have learnt how to program, but programming is not the same as design. Design requires very different skills to using a programming language. At a very high level, big systems are sets of interconnected modules. The things that matter are narrow APIs with minimal coupling, and where coupling is unavoidable making it explicit and easy to reason about. Concrete examples of the anti-patterns to be avoided are global variables, leaky abstractions and APIs that require complex sequences of interconnected calls.

Those things don't bite hard until you program in the large. The current crop of LLM's seem to be useless at all of them. If you've got a big context window and you are only writing 100s of kloc, a budget of kilowatts to understand the complexity, it doesn't matter. But humans don't have a budget like that, and so far everyone I've seen who reads large chunks of vibe coded software recoils in horror, gives up, and walks away.

Even with that budget, the models fail anyway once the size gets way beyond their context window - it's just that they fail much later than humans. Which I guess makes learning the lesson so much harder - perhaps near impossible as your "they need labeled examples" hints at. Oddly the solution would be to train with smaller context windows (a less powerful model in some ways), so the failures become apparent much earlier.

It looks like they have been going with your solution for now - giving engineers cheap tokens via flat-rate plans, and watching how they do things. I don't think that will work. Engineers who chew through the billions of tokens offered by these plans are vibe coding. The code they produce is so poor it can't cross the threshold from small to large. There is nothing to see there about programming in the large.

:( what a rant - it looks like an LLMs CoT as it thinks through things. Which is what I was doing, I guess.