These Aren't New Principles
I feel like every other day there is a new noun. Evals, backpressure, guardrails, agentic fitness functions.
But underneath each one is a fundamental principle teams have been applying for decades.
About 20 years ago, a manager I once worked for ensured he created an environment where it was safe to fail. He pushed the team to hold that standard too.
Automated tests were obviously a part of it. But a build turning red wasn't the important part: it was the philosophy and culture. It was the exact opposite of a blame culture. No one was punished for making a mistake. In fact, we treated an incident as a failure of our systems and processes, and ensured an individual was never the subject.
When something failed, it simply became data. This made it something the team could take responsibility for, iterate on, improve and ultimately prevent from happening again.
Extreme Programming already had a value for this: Courage. Kent Beck calls it "effective action in the face of fear", and the example he gives is "the courage to speak truths, pleasant or unpleasant".
Now I'm reading every week about a new discipline for building the same loops for agents.
None of this is new. A failing test providing feedback to a person is the same test that provides feedback to an agent. The mechanism is identical. What changed is who reads the output.
Architecture documents are an example I run into a lot. Documents always risked going stale. But today, an agent reads one, believes it, and now builds based on something that stopped being true two years ago.
How do we prevent agents from doing this? We stop letting prose be the authority. This means deriving the architecture from the code when you need it. Or, we build systems where violating a boundary fails the build. We make our system and processes refuse incorrect changes.
The codebase is the source of truth and tells us what's implemented. A failing architectural test is the source of truth providing feedback. This is what my manager was teaching us decades ago about building an engineering culture where it was safe to fail.
But I want to try and force myself to articulate the thing I'm finding frustrating: why now?
I know why. It's because these tactical things help agents. But why weren't organisations building these loops to help their people already? Why aren't agents inheriting these benefits?
I've worked in several high-performing teams where this was a non-negotiable default of engineering culture. But I've also worked with teams that refused to invest when it was for the people. And now suddenly, since it helps agents, it's time to invest.
It's great we're finally providing the benefits to the meat-bags. But, as a meat-bag, I find it a shame it's a second-hand side effect of tooling built for something else.
This is not an argument against evals, or guardrails. Actually, I think the opposite: you should already have them. Build them. They work. In doing so, you'll build a codebase that also shapes an agent's behaviour more than a prompt does.
I'm just tired of proven principles and practices being constantly reframed as something new.
They're the loops we already had, finally getting funded.