Somebody in your organisation is likely banging on about Ralph Wiggum loops, Gas Town, MEOW, YOLO mode, or LangGraph. You nodded along and made a note to look it up later. You never did. Somewhere around the third made-up noun, you begin to wonder if this is finally the wave that’s moving too fast for you to catch.
I thought it might be useful to breakdown some of the new language that surrounds AI. You’ll be (un)surprised to learn that behind the buzz are some pretty basic concepts. The technology is moving quickly, but the terminology is moving faster.
Models
It seems we can’t get through the week about hearing about the latest “frontier model” that’s going to make us all irrelevant, or how some internal-only “highly persistent” model is simply too dangerous for us mear peasants to use ... well, at least for a few weeks whilst the media whips us all up into a fomo frenzy.
Models come in a variety of shapes and sizes, but they broadly differ in the scale of their compute, the quality of the training data they’ve been fed, and what tuning has taken place to shape their output. It’s difficult to fathom the scale of their training. Meta’s Llama 3 was trained on over fifteen trillion tokens for 54 days using 16,384 Nvidia H100 GPUs. A “token” by the way is just a chunk of a word by the way. It would take 20,000 years to achieve the same using a high end gaming PC, and you’d burn enough electricity to power 9,000 UK homes for a year.
We do give models too much credit though. You hand it some text, it does a truly obscene amount of arithmetic, and hands you back the text that most plausibly comes next. It can’t remember your last conversation; it doesn’t know how to access the Internet, or have any mechanism to connect to other tools or data sources that might make it useful.
Harnesses
The harness is a more interesting space and where you can expect more differentiation between vendors. A harness is the environment the model operates within. It feeds the model its inputs, instructs it what to do, how to behave, gives it tools to interact with the world, and various other deeply unglamorous plumbing.
Two organisations can run the identical model and get wildly different results based on their choice and configuration of the harness. AI vendors are wise to this too; they know models are becoming increasingly commoditised, so their products tie together a user application, harness, and model. The vendors can see models commoditising, so Anthropic won’t sell you Claude Code pointed at GPT, and OpenAI won’t sell you Codex pointed at Gemini. Model, harness and application arrive as a product.
The harness is also the source of all the noise. Everyone on Twitter wants to let you know how they’ve (had AI) build them some elaborate system that eliminates AI hallucinations and runs every aspect of their lives “while they sleep”. Cool story, bro.
Importantly, everything the AI Twitter lot is shouted at you this year describes some aspect of the harness. You’re going to be disappointed how simple many of these concepts are, and how they echo the DevSecOps principles we’ve known and loved for so many years.
(Inner) Loops
Even seasoned developers take a few turns to get their software doing what they want. You write some code, but it throws a some dependency error before we even get to try it. You manage to fix that, and now your software does something! Unfortunately, it doesn’t quite do what you wanted. You pour back through the code, find some gaps in your logic, try again, find more, rinse repeat. You go through this process a few times until you finally achieve what you set out to do.
Congratulations, you now understand “loops”, or be more specific, “the inner loop”.
AI Agents struggle too. They make mistakes, they get distracted, or sometimes just plain forget what they were doing. Systems like <LIST> simply tell the agent to keep trying until whatever task they were set is “done”. The tricky part is defining what “done” looks like for any given task.
The Outer Loop
In most software development teams, you’ll find a Continuous Integration (CI) system like GitLab at the centre of what they do. Developers submit their code and the CI system performs various automated tests to decide if that code is ready to be put into production. Complexity varies, but there might be unit tests (does this bit work?), integration tests (does it work with other bits?), lint tests (does the coding style match our preferences?), and likely various styles of security tests (could a hacker abuse this?). In large companies it’s also common for any new code to be reviewed by another human as an extra precaution.
The CI systems churns in the background, helping whole teams of developers test their code. It ensures that all the parts of a software solution work together. When it detects a problem, the developer will go back to their code, make some changes (inner loop), then submit a new version. That in a nutshell, is the “outer loop”.
Determinism
In the AI world, there’s some debate how much testing belongs in the “inner loop” (usually on the developers machine) versus what belongs in our CI system (outer loop). Letting your AI system run its own tests is generally faster, but can we trust it? After all, we put all these tests together because we know even the best AI models (or human developers) make mistakes.
The solution is rather obvious; do a mix of both. Give AI as many tools as practical for it to determine if what it’s created meets our definition of “done”, but then pass that to a deterministic CI system to do the final checks.
The IT world is a fascinating place though. We’ll often create unimaginably complex and intricate systems to solve what, on face value, are simple problems. The problem is that we often get tunnel vision when given a new technology to play with. We forget we’ve got other tools, or we lose track of the real-world problem we were trying to accomplish.
Early in career, I spent weeks trying to devise automated zero-time database failover/failback. Failover was simple, but I couldn’t find a way to failback without taking the database down. A very frustrated business colleague asked “can you not just shove half the customers on server and the rest on another?” You see, whilst I was fiddling with the tech, the business had the very real risk that a server outage would bring the company to its knees. My non-technical business partner instinctively knew that potentially losing half our customers was better than all of them. I think engineers could all do with that reality check now and again.
Graphs
As teams devised more ways of defining “done”, the time taken for the CI system to check code increased. Developers became restless. The solution was pretty simple; configure the CI system so that it’s able to do some of those checks in parallel, rather than a strict queue. We probably want to make sure the code works by itself before we go through the trouble of spinning up a whole test environment to try it with other components, but there’s no reason why we couldn’t be doing a first pass of security testing whilst we’re doing that.
If you were to draw this out, you would see a straight line with various branches where the CI systems spins off work in a parallel. That my friend, is what maths folks would technically call a Graph, albiet it a very boring one.
The Clarity of Common Sense
It’s easy to feel lost in the sea of hype on LinkedIn and Twitter. Don’t be distracted by all the new terms people are inventing. Be wary of those with big promises, but don’t share meaningful results. Ralph is a bash loop. A graph is your pipeline. The outer loop is CI. Guardrails are policy, evals are tests, and human-in-the-loop is a change approval with better marketing.
Developers were king, but in a world where AI can write code faster and cheaper, the value equation has changed. Quality is the new bottleneck. What “done” looks like? That judgement doesn’t come from the training data; it comes from the people who’ve been wrong in production and had to explain it afterwards.