Developers are facing a vocabulary explosion as AI tools constantly introduce new terms to describe existing patterns. Some words describe useful workflows, others are just fancy names for old concepts, and some are still being defined. In a recent GitHub Podcast episode, Marlene Mhangami, GPS, and the host discussed specific jargon currently appearing in development: loop engineering, Ralph loops, squads, harness engineering, hill climbing, forward deployed engineers, closed models, open weights, and open source models. This guide explains what those terms mean, why they matter, and how to think about them.
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 is asking an agent every morning to review new issues, summarise them, and propose fixes. You create a loop that runs on a schedule instead. That loop might fetch issues, pass them to an agent, validate the output, and escalate anything that gets stuck. It is 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 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 are 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 specialise each one with specific skills to be more efficient.
The core idea is parallelisation and specialisation. 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.
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 is 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 producing the right kind of output, and then adjusting the harnesses until the results improve.
Or, another example, if your agent is supposed to review pull requests, hill climbing might be checking if it indeed finds meaningful bugs and produces useful recommendations, and adjusting tooling to improve that.
Forward deployed engineer: A familiar role with an AI focus
A forward-deployed engineer job has already existed, but AI branding makes it sound edgy and new. Now, it is a customer-facing software engineer, or sales engineer, or solutions engineer, often with an AI focus.
If you have not seen those job titles before, this person generally works closely with customers to implement or adapt technical solutions into their environments. With the AI focus, that means helping teams integrate AI tools, workflows, agents, and so on into their existing systems.
Closed models, open weights, and open source models
Not all models are shared in the same way.
Closed models are accessed through an API or hosted product. Developers can use the model, but they do not get access to the underlying weights, training data, or training process. The big, famous frontier models you hear about are often all closed models.
Open weight models make the model weights, which are like dials that decide how important certain inputs are, available. Developers can download and run these models, often locally or in their own infrastructure. But, to be clear, the dataset and training method may not be fully available.
Open source models go a step further, in that the model, code, data, and training process are all available for inspection, reuse, and modification.
The more open the model, the more you can run, customise, audit, and trust it.
The terms are ever-evolving
This is just a sampler of some of the terms we are hearing a lot today. Some will stick around, and others will fade into our memories, and others will be replaced by better language as the industry matures.
Do not worry about falling behind on buzzwords. They are just words, and more important are the practices under them. Ask yourself if workflows can repeat reliably, how you validate tasks, how humans should or should not interfere, how much you can rely on a model, and how you can improve that your system. It is a new era of engineering, and best practices still matter.
