Making use of artificial intelligence tools in software development is no longer limited to writing a single prompt and waiting for an answer. Developers increasingly talk about recurring execution loops, multiple agents, and systems that surround and direct the model—concepts that GitHub Blog attempts to organize in a guide published by Cassidy Williams on September 2, 2026, based on a discussion on the GitHub Podcast featuring Marlene Mhangami and GPS.
Some of these terms describe new practical patterns, while others give modern names to ideas that already exist; still others are continuing to take shape. Therefore, the guide does not present these words as final standards, but as a way to understand the ongoing discussion among software development teams.
From a Single Prompt to Loop Engineering
Loop engineering means designing repeatable systems around agents instead of manually asking an agent to perform a single task each time. The example presented is creating a scheduled process that retrieves new project issues, passes them to an agent to summarize them and suggest fixes, then verifies the output and escalates unresolved cases to another workflow.
In this sense, the loop resembles an AI-configured cron job, but it requires more than scheduling. The guide points to specific skills, behavior monitoring, output verification, task routing, and stopping points where intervention or review can take place.
Ralph loops are a simpler and more direct application of the loop concept: the agent is given a detailed description of a task, often based on requirements or a specification, and continues working until it considers the task complete. This approach may help divide work into recurring cycles of planning, execution, and inspection, but it can be costly and inefficient if each cycle consumes more tokens, context, and computing capacity.
The Difference Between Squads, Fleets, and Harnesses
Squads and fleets describe how work is distributed among multiple agents. A squad is a group of agents with different roles: one plans, another reviews the plan, a third implements it, a fourth tests it, and a fifth reviews the result. A fleet refers to agents working in parallel on tasks at the same time. A complete squad can run within a parallel fleet, or its roles can be organized sequentially.
The practical idea here is specialization and parallelism rather than assigning everything to a single agent. However, having multiple agents does not automatically guarantee higher quality; the article itself links the benefit to the team’s ability to distribute and control roles and verify outputs.
A harness refers to everything surrounding the model that makes it usable within a workflow: tools, permissions, memory, context, and coordination between tasks. The guide presents GitHub Copilot as an example of a system that connects models with codebases, editors, pull requests, and the terminal. Harness engineering is the design and improvement of this system surrounding the model.
Optimization Through Feedback
The term hill climbing describes gradually improving agents and harnesses based on feedback. A team may begin by measuring an agent’s performance through evaluation tests, then adjust the tools, context, or routing mechanism when the results are not accurate enough.
In pull request reviews, for example, measurement is not limited to the agent’s ability to produce a comment; it also includes whether it finds meaningful errors and provides useful recommendations. The practical takeaway is that introducing an agent into a workflow is not the endpoint; it begins an ongoing cycle of measurement and adjustment.
Role and Model Terminology
The field engineer describes a role that existed before the AI wave, such as a software engineer who works directly with customers, a sales engineer, or a solutions engineer. In the context of AI, this role helps teams adapt tools, workflows, and agents and integrate them into their existing systems.
Closed models are made available through an application programming interface or a hosted product, without making the weights, training data, or training method available to the user. Open-weight models allow users to download the weights and run them locally or on their own infrastructure, but this does not necessarily mean that the data and training method are available. In open-source models, the level of availability goes further to include the model, code, data, and training process for inspection, reuse, and modification.
Why Does This Guide Matter?
The real change is not merely the emergence of a new vocabulary, but the shift in the discussion from “What can the model generate?” to “How do we build a repeatable, measurable system around it?” This matters to development teams considering running agents within their processes, because choosing a term does not replace defining permissions, verification mechanisms, points of human intervention, and the cost of repetition.
Nevertheless, the source acknowledges that the terminology is not stable; some terms may become established, while others may disappear or be replaced by more precise expressions. Therefore, the most important questions remain practical: Can the workflow be repeated reliably? How are the results reviewed? When does a human intervene? And how much reliance on the model is acceptable? According to the article, these questions are more important than keeping up with every popular term.