Why AI engineering has a new vocabulary
AI tools have introduced a steady stream of new terms into software development, and it can be hard to tell which ones describe genuinely useful patterns and which are just rebranded versions of practices that already existed. Some of these words are still actively being defined. A recent episode of the GitHub Podcast covered several of the terms developers are encountering most often right now. Below is a quick guide to what they mean and why they matter.
Loop engineering and Ralph loops
Loop engineering is the practice of designing repeatable systems around agents, as opposed to manually prompting them one task at a time. Instead of asking an agent every morning to review new issues and propose fixes, you build a loop that runs on a schedule — fetching issues, passing them to an agent, validating output, and escalating anything that gets stuck. In essence, it is an AI-native cron job.
A Ralph loop is one specific implementation of that idea: you give an agent a detailed task, often drawn from a spec or product requirements document, and let it work until completion. This can be useful for breaking large tasks into repeated plan-act-check cycles, but it can also be inefficient, since each iteration consumes more tokens, context, and compute. Loop engineering attempts to make this pattern more structured by adding primitives such as skills, observability, validation, routing, and checkpoints — so you are not simply asking the agent to “try again” repeatedly.
Squads, fleets, and multi-agent workflows
If loops define a workflow, squads and fleets describe how multiple agents can participate in it. A squad is a group of agents with distinct roles, often mirroring a real-world team: one agent might plan, another vets the plan, another implements it, and another tests or reviews it. A fleet, by contrast, refers to parallel agents working on tasks simultaneously. You can have a squad operating within a fleet in parallel or in sequence.
The core idea is parallelization and specialization. Instead of relying on one agent to handle everything, different agents can be fine-tuned with specific skills to handle different parts of the development process more efficiently.
Harnesses and harness engineering
A harness is everything that surrounds a model to make it useful in your workflows — tools, permissions, memory, context, and orchestration. The analogy is to a horse harness: models can run wild, and the harness directs their effort safely as they complete tasks. GitHub Copilot is a good example of a software harness, connecting models to codebases, editors, pull requests, and terminals. Harness engineering is the work of designing and improving that surrounding system.
Hill climbing
Hill climbing describes the process of improving agents and harnesses over time through feedback. That might mean using evals to measure whether an agent produces the right output and adjusting the harness until results improve. If your agent is meant to review pull requests, hill climbing could involve checking whether it actually finds meaningful bugs, then adjusting tooling to make it better at that job.
Forward deployed engineers
A forward-deployed engineer is not a new role — it has existed for a while, but AI branding has given it fresh attention. These are customer-facing software engineers, often with an AI focus, who work closely with clients to implement or adapt technical solutions in their environments. That means helping teams integrate AI tools, workflows, and agents into existing systems.
Closed models, open weights, and open source models
The openness of a model has real implications for how you can use it. Closed models are accessed through an API or hosted product, meaning you can use them but cannot see the underlying weights, training data, or training process — this category includes many of the most prominent frontier models.
Open weight models make the weights available — the parameters that determine how much importance the model assigns to different inputs — so developers can download and run them locally or on their own infrastructure. However, the dataset and training method may not be fully disclosed.
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 is, the more you can run it, customize it, audit it, and trust it.
A moving target
This is just a sample of the terms circulating today. Some will stick, others will fade, and many will be replaced by more precise language as the industry matures. Rather than worrying about keeping up with buzzwords, it is worth focusing on the practices underneath them: whether workflows can repeat reliably, how you validate tasks, how humans should or should not intervene, and how much you can depend on a model. Best practices still matter, even in a new era of engineering.
