It might be overwhelming to see all of the new vocabulary popping up in software development these days thanks to AI tools introducing them… all the time.
Some of this new vocab describes useful patterns that people are newly pursuing, others are just fancy names on top of things that already exist, and some are still actively being defined as we speak.
In our latest episode of the GitHub Podcast, Marlene Mhangami, GPS, and I talked through some of the AI terms developers are learning right now: loop engineering, Ralph loops, squads, harness engineering, hill climbing, forward deployed engineers, closed models, open weights, and open source models.
If you’re a reader instead of a listener, here’s a guide to what those terms mean, why they matter, and how to think about them.
Listen to the full episode below!
Loop engineering: Moving beyond one-shot prompts Loop engineering is the practice of designing repeatable systems around agents, instead of manually prompting them for one task at a time.
A simple example: instead of asking an agent every morning to review new issues, summarize them, and propose fixes, you create a loop that runs on a schedule.
That loop might fetch issues, pass them to an agent, validate the output, and escalate anything that gets stuck.
It’s a glorified AI-native cron job.
Ralph loops: The brute-force cousin of loop engineering A Ralph loop is one implementation of this “loop” concept: you give an agent a detailed task, often from a product requirements document or spec, and have it keep working until the job is done.
That can be useful, especially for breaking down large tasks into repeated plan-act-check cycles.
But, on the other hand, it can also be expensive and inefficient because every iteration uses more tokens, more context, and more compute.
Loop engineering aims to make this pattern more structured, so you’re not caught asking an agent to “try again” all the time.
A well-designed loop adds primitives like skills, observability, validation, routing, and checkpoints.
Squads, fleets, and multi-agent workflows If loops define a workflow, “squads” and “fleets” describe how multiple agents can participate in that workflow.
A squad is a group of agents with different roles.
They often reflect a real-world team.
One agent might plan, another agent might vet that plan, another agent might implement it, another might test it, and another might review it.
A fleet refers to parallel agents working on tasks at the same time.
You can have a squad working in a fleet in parallel, or in a sequence.
Operating this way lets different agents handle different parts of a process, and you can fine-tune and specialize each one with specific skills to be more efficient.
The core idea is parallelization and specialization.
Instead of one agent trying to do everything, different agents can handle different parts of a development process.
Harnesses: The system around the model Outside of what a model generates, a harness is everything surrounding it that makes it useful in your workflows.
That could be the tools, permissions, memory, context, orchestration (and so on) that guides how the model behaves.
If it helps you remember: harnesses are aptly named after the harnesses for horses.
Horses are like models that can run wild, and a harness helps direct the horse’s weight safely as it completes tasks.
Get it?
Anyway, a good example of a software harness is GitHub Copilot.
It connects models to codebases, editors, pull requests, terminals, and so on.
When you hear the term “harness engineering” tossed around, that’s the work of designing and improving that system that surrounds the models.
Hill climbing: Improving agents with feedback The term “hill climbing” is used to describe the process of improving agents and harnesses over time.
That could mean, for example, using evals to measure whether an agent is prod