What do loop engineering, harnesses, and open weights actually mean for developers?

The podcast behind the glossary

Cassidy Williams published the guide on September 2, 2026. She is senior director for developer advocacy at GitHub. The post summarizes an episode of the GitHub Podcast. Marlene Mhangami, GPS, and Williams talked through the terms developers are learning right now. Some describe useful patterns people are newly pursuing. Others are fancy names on top of things that already exist. A few are still actively being defined as we speak.

The episode runs about five minutes. Williams wrote the guide for readers who prefer text over audio. She warns against buzzword anxiety. The practices underneath matter more than the labels.

Loops and the brute-force cousin

Loop engineering is the practice of designing repeatable systems around agents. Manual one-shot prompts become obsolete. 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 is a glorified AI-native cron job.

Ralph loops implement this concept differently. 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 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 and fleets divide the work

Squads and fleets describe how multiple agents participate when loops define a workflow. A squad is a group of agents with different roles. They reflect a real-world team. One agent might plan, another might vet that plan, another 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. 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 handle different parts of a development process.

Harnesses steer 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. The name comes from horse harnesses. Horses are like models that can run wild. A harness helps direct the horse's weight safely as it completes tasks. 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 and the familiar role

Hill climbing describes the process of improving agents and harnesses over time. That could mean using evals to measure whether an agent produces the right kind of output, then adjusting the harnesses until results improve. 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, then adjusting tooling to improve that.

Forward deployed engineer is not a new job. It has already existed. AI branding makes it sound edgy. Now it is a customer-facing software engineer, or sales engineer, or solutions engineer, often with an AI focus. 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.

Three levels of model openness

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 closed models.

Open weight models make the model weights available. Weights are like dials that decide how important certain inputs are. Developers can download and run these models locally or in their own infrastructure. But the dataset and training method may not be fully available.

With open source models, 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, customize, audit, and trust it.

The terms keep shifting

This is just a sampler of terms heard a lot today. Some will stick around. Others will fade into memory. Others will be replaced by better language as the industry matures. Williams suggests asking whether 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 system. It is a new era of engineering. Best practices still matter.