[Vgoose]

Nice! I actually ran across this paper+benchmark recently, too. It's the first I've found that start to aim at some of the non-functional and longitudinal requirements that I think have always been an important part of writing production code.

It's especially relevant now that models are good enough to solve ~most point-in-time problems.

Some relevant but disconnected thoughts:

- deterministic scores are so nice

- what "maintainable" is is probably some high dimensional space described by these signals; it'd probably require some human labeling to figure out where this space is

- another signal I've been thinking about and I'm seeing increasingly get brought up is the state space of a system; I'm seeing formal methods pop up a lot recently

[NitpickLawyer]

> another signal I've been thinking about and I'm seeing increasingly get brought up is the state space of a system

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.

[nicoty]

I've been thinking a lot about this recently. In my case: how do I get an agent to see the important parts of the current plan and get it to stick to it without deviating, especially as loops get into longer and longer cycles and compactions erase prior context?

I think the problem with just encoding a whole plan in a single markdown file is that it gets polluted really quickly (agents can stop adhering to instructions to keep it clean and conform to a specific structure), which makes it harder for agents to see which parts of the plan they should focus on. As such, I've reached a similar conclusion about giving the agent access to CLI tools to help them deal with this. To try to mitigate this, I've been getting Claude to develop for me a CLI tool that:

1. Scaffolds reusable, structured plan templates and a reusable workflow that structures how to tackle the plan, step by step.

2. Validates that the plan files still conform to the correct, parseable structure.

3. Parses and evaluates the plan files, to determine what the current state is and what the next valid transitions and states are according to the workflow, like a state machine, and outputs instructions and reminders for agents as to what they should do at each step of the workflow.

So far, I've been dogfooding the tool and it seems promising: I can leave Claude running for longer and it doesn't drift as much. However I haven't ran any benchmarks yet and I'm still not entirely happy with the state of the codebase ( https://github.com/nothingnesses/agent-scaffold ), so take this with a grain of salt.

That said, I'm also bullish on using agents with formal methods and proofs. Type checkers and compile-time checking in general are great because they surface errors early and with great specificity. So if you can encode your specifications with, e.g. dependent types, you can use the type-checker as a way to steer the agent when it goes wrong and gets off-track.

[LiveTheDream]

You should take a look at OpenSpec[0]. It implements your points 1-3.

[0] https://openspec.dev/

[Vgoose]

Ive have a definition of state space that is calculated by just the types of the system. It’s a rough approximation of the true state space but it’s convenient (and more reflective of what we actually mean by system state IMO) and types are inherently accessible to the model. I recently put down some thoughts around working with types to improve communication w/ AI that kind of sets this framing up: https://www.alecvo.org/blog/types-with-ai/. The actual definition is still WIP.

[dhorthy]

> - what "maintainable" is is probably some high dimensional space described by these signals; it'd probably require some human labeling to figure out where this space is

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

[jefffoster]

I’ve been thinking about this too.

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.

[Vgoose]

Thanks for sharing, I've never heard of variety before and that was an interesting read. It makes me think of a broader term I've been using to describe the run time state of the system: Entropy. I've given up on measuring that for now and I'm settling for a compile time proxy through measuring the _semantic_ cardinality of types as this seems a bit more approachable for a POC.

One drawback I ran into was that the variety/entropy of scalars tends to dominate everything else. I'm clamping them to 1 for now but that's also not great as it punishes more descriptive systems.

[rstuart4133]

> what "maintainable" is is probably some high dimensional space described by these signals; it'd probably require some human labeling to figure out where this space is

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.

[Vgoose]

I think there's a simple explanation for why the models aren't good at "maintainable" code: they're not explicitly trained on it in post-training. It being hard to quantify what maintainable is and there not being a popular benchmark for maintainability are probably some reasons why.