AI Dev Jargon Decoded: Loops, Harnesses, Squads, and More

GitHub's podcast team, including Marlene Mhangami, recently walked through nine AI development terms that are appearing constantly in engineering conversations: loop engineering, Ralph loops, squads, fleets, harnesses, hill climbing, forward deployed engineers, closed models, open weights, and open source models. Some describe genuinely new patterns, some are old roles with fresh branding, and some are still being defined. Here is what each one actually means, and whether it is worth your attention.

What happened

GitHub’s podcast broke down nine terms that are spreading fast through AI-adjacent developer conversations. Rather than letting them pile up as buzzwords, the team gave working definitions for each. Below is the plain version.

Term	One-line definition
Loop engineering	Designing scheduled, repeatable systems around agents
Ralph loop	Agent works a task in repeated plan-act-check cycles until done
Squad	Group of agents with distinct roles (planner, reviewer, tester, etc.)
Fleet	Multiple agents running the same tasks in parallel
Harness	Tools, memory, permissions, and orchestration surrounding a model
Hill climbing	Using evals and feedback to improve agents and harnesses over time
Forward deployed engineer	Customer-facing engineer who helps teams integrate AI tools
Closed model	Accessed via API; weights and training data not shared
Open weights	Weights downloadable; dataset and training method may not be
Open source model	Model, code, data, and training process all available

Breaking down each term

Loop engineering and Ralph loops

Loop engineering is the practice of building scheduled, repeatable workflows around agents instead of prompting them manually each time. Think of it as an AI-native cron job. A loop might fetch open issues on a schedule, hand them to an agent, validate the output, and escalate anything stuck.

A Ralph loop is one specific version of this: give an agent a detailed spec and let it keep cycling through plan-act-check until the task is complete. That sounds efficient, but every iteration consumes more tokens, more context, and more compute. A well-structured loop avoids that waste by adding skills, validation, routing, and checkpoints so the agent is not just spinning.

Squads and fleets

Where a loop defines the workflow, a squad defines who does the work. One agent plans, another vets the plan, another implements, another tests, another reviews. A fleet is those agents running in parallel rather than in sequence. The point is specialization: each agent can be tuned for its specific job instead of one generalist agent attempting everything.

Harnesses and harness engineering

A harness is everything around the model that makes it useful: the tools it can call, the permissions it holds, the memory it can read, and the orchestration logic that controls it. GitHub Copilot is a good example. It connects underlying models to codebases, editors, pull requests, and terminals. Harness engineering is the work of designing and improving that surrounding system. The model itself is just one part of what ships.

If you are thinking about adding AI capabilities to your business workflows, you are almost certainly doing some version of harness engineering, whether you call it that or not.

Hill climbing

Hill climbing is the feedback loop for agents and harnesses. You measure whether an agent is producing the right output (using evals), then adjust the harness until results improve, then measure again. An example from the GitHub post: if an agent is supposed to review pull requests, hill climbing means checking whether it actually finds meaningful bugs and produces useful recommendations, then tweaking the tooling based on what you find.

Forward deployed engineers

This role predates AI entirely. A forward deployed engineer is a customer-facing software or solutions engineer who implements technical solutions inside a client’s environment. The AI version is the same job, now focused on helping teams integrate agents, workflows, and AI tools into existing systems. The title sounds new; the work is not.

Closed models, open weights, open source

These three are genuinely distinct and worth getting right:

• Closed models are accessed through an API or hosted product. You use the model, but the weights (the internal dials that determine how inputs are weighted) and training data stay private. Most large frontier models work this way.
• Open weight models make the weights downloadable so you can run the model locally or in your own infrastructure. The dataset and training method may still be private.
• Open source models go further: the model, code, data, and training process are all available for inspection, reuse, and modification.

The more open a model, the more you can customize, audit, and run it on your own terms. That distinction matters when you are deciding what to build on.

Why it matters

This vocabulary is spreading because the patterns it describes are spreading. Teams that were experimenting with one-off prompts six months ago are now building scheduled agent loops. Companies hiring “forward deployed engineers” are billing a familiar role as something new. And as the open vs. closed model debate grows, knowing the difference between open weights and open source affects real decisions about vendor lock-in, compliance, and cost.

For business owners evaluating AI tools or vendors, understanding this language helps you ask sharper questions. If someone pitches you a “multi-agent squad,” you now know to ask how the agents are validated and what the harness looks like. That is a better conversation than nodding along to the buzzwords.

If you want to track how this space keeps evolving, our AI news coverage covers the model releases and tooling shifts behind these terms as they happen.

Our take

Most of this vocabulary is useful shorthand for real patterns that developers are building right now. Loop engineering and harnesses describe things people were already doing without clean names for them. Giving them names makes it easier to discuss tradeoffs and share designs across teams.

The part to be skeptical about: Ralph loops and unstructured multi-agent workflows can burn a lot of compute without a clear improvement in output quality. Token cost is real, and “let the agent keep trying” is not a strategy. Hill climbing is the honest answer here, but it requires good evals, and most teams do not have those yet. Build the measurement before you build the loop.

The open vs. closed model distinction is the one that deserves the most attention right now. As more business-critical workflows run on AI, the question of who controls the weights and training data will matter for compliance, cost, and continuity. Worth thinking about before you are locked in.

What to do about it

1. Audit your current AI usage: are you one-shot prompting, or do you have a structured loop with validation and checkpoints?
2. Map your harness: list the tools, permissions, and memory your agents can access and check for gaps or over-provisioned access.
3. Check model openness before committing: ask vendors whether you have access to weights, and what happens to your data during inference.
4. Set up at least one eval before expanding agent usage, so you have a baseline for hill climbing.
5. Talk to your team about what a “forward deployed” AI integration would actually look like in your context, using workflow automation as a starting point for scoping the work.

Know the vocabulary, but measure the output before you scale anything.

Source: GitHub Blog