Evidence reviewed through 27 August 2026.
For several years, AI in software development meant adding an assistant to an existing workflow: ask a question, paste an answer, accept an autocomplete. The developer still did most of the work, and the AI sat beside them.
That no longer fits my work, or the AI-intensive work now being documented by others. The model reads the repository, changes files, runs commands, opens pull requests, reviews other agents' changes and keeps working while the developer moves on.
The models I use write much better code than they did six months ago. The larger change is that the workflow is being redesigned around machine execution.
My normal workflow includes several agents, delegated subagents and unattended runs. In a typical month, the provider dashboards for those systems record billions of tokens across coding, research and operational work. I include that number only to locate my perspective. It measures exposure, not skill or value. My experience describes one intensive workflow. It should not be mistaken for the average baseline.
The workflow itself changed several times in a few months. OpenClaw and Hermes made persistent, tool-using agents feel practical. Codex then made parallel coding a normal part of my day. By August 2026, much of my attention had moved towards persistent goals and routines that can start another agent run without waiting for me to write the next prompt. This personal chronology says nothing about market share. It shows how quickly the unit of work is changing.
Why I will not call it vibe coding
The phrase "vibe coding" has become too vague to help this discussion.
Andrej Karpathy originally used it for a deliberately code-blind workflow. You give in to the result, "forget that the code even exists," run what the model produces and keep asking for changes. That can be fun and useful for disposable experiments.
The term now covers several incompatible ideas. Some people use it for any AI-written code. Others mean a disciplined process in which the developer may not read every generated line but still relies on specifications, tests and review. Critics use it as shorthand for careless work.
Once a term describes both code-blind prototyping and disciplined engineering, it describes very little. I will use AI-assisted development for the broad category and agentic development when models can act. The useful questions are whether the change was understood, verified and owned.
The rest of the terminology is still moving too, so these are the definitions I use in this series.
A coding agent is a model inside a runtime that can inspect a workspace, edit it, use tools, observe the result and try again. A chat response suggests code. An agent can run it.
A harness is the system around the model. It supplies context and tools, maintains state and feeds results back into the work. In Harness-Bench, 5,194 trajectories produced a 23.8-point gap between the strongest and weakest harnesses when averaged across the same eight models. Stronger models varied less, but the model and harness both mattered.
A loop can mean several different things. Anthropic now separates turn-based, goal-based, time-based and proactive loops. Every coding agent already has an inner loop: the model calls a tool, observes the result and decides what to do next. That is part of the harness. It is not the shift I mean here.
In this series, a loop is the layer above that. It starts another turn or another agent run without waiting for a person to supply the next prompt. It may keep one verifiable goal alive, as Codex /goal does, or repeatedly discover work such as failed builds, review comments and maintenance tasks. The initial instruction has not disappeared. The system now decides when to run again, what context to add, how to verify the result and whether to continue.
The Ralph Wiggum technique, published in July 2025, was an early external version. A small shell loop repeatedly launched fresh agent sessions while files and Git carried state. Current harnesses increasingly provide continuation, scheduling and evaluation themselves, while larger orchestrators apply the pattern across agents.
The more recent explanations are broader still. Boris Cherny separates goal mode, scheduled loops and multi-agent workflows. Peter Steinberger describes a pipeline from an intended outcome through coding, review and end-to-end testing. He says it could be called a loop, a graph or something else. The useful shift is the control system, not the label.
A finite goal loop needs durable state, independent evidence of completion and a budget. A monitoring routine may have no final end date, but each action still needs bounded authority and a way to escalate. Otherwise it is repeated guessing at greater cost. The August 2026 LoopsBench preprint evaluated 112 long-horizon tasks. Its strongest model-and-loop configuration resolved 25%. These mechanisms add a higher-level control surface over the harness. They have not solved planning, state retention or regression.
Old studies describe old workflows
In early 2025, METR ran a careful study of experienced open-source developers and found that AI-allowed tasks took 19% longer. The confidence interval ranged from 2% to 39% longer. That result was widely repeated, often without its date, task selection or tooling.
METR tried to repeat the experiment with newer agentic tools later in 2025. By February 2026, the researchers said the new data was no longer reliable. Some developers would not participate if half their tasks might have to be completed without AI. Between 30% and 50% said they withheld certain tasks for the same reason. Parallel agents also made individual task timing difficult. The returning-developer estimate had moved towards an 18% reduction in task time, but its confidence interval still included a slowdown. METR explained the problem directly.
The useful finding here is methodological. The usage pattern changed enough to break part of the experimental design, leaving the productivity question open.
The gap between lighter and intensive use matters too. A May 2026 METR survey of 349 technical workers found higher perceived gains among heavier and more experienced users, and among people using Claude Code or Codex. Only 87 were software engineers, and the convenience sample had a response rate of roughly 2%. It cannot tell us the true multiplier, but it shows variation that an average can hide.
The average respondent was not running a fleet of agents. An April 2026 Stack Overflow pulse survey of 1,100 developers and other professionals reported workplace agent use at 59%, compared with 31% in a separate 2025 survey. Among agent users, 69% had a single-agent setup and 68% preferred one. Across all respondents, 63% rarely or never allowed fully autonomous work.
The frontier has moved quickly. Average use has followed more slowly.
What it means to build around AI
OpenAI published one of the clearest examples in February 2026. A team that began with three engineers built an internal product in a repository of roughly one million lines across code, infrastructure, tooling and documentation. About 1,500 pull requests were merged. The team estimated that the work took one-tenth of the hand-coding time.
The important part was the environment built around the agents. The repository contained structured knowledge, executable plans, architectural rules, local observability, isolated worktrees and automated review.
This was an uncontrolled internal case study from the vendor of Codex, and OpenAI warned that the result depended heavily on that investment. The case study is worth reading in full.
Make the repository legible. Important context cannot remain in one person's head or disappear into chat history. Architecture, product rules, operational constraints and current plans need clear sources of truth that agents can find.
Make success executable. Tests, linters, security checks, type systems and policy checks turn expectations into feedback. A prose instruction can be misunderstood. A failing check gives the agent something concrete to repair.
Keep the system replaceable. Models and harnesses change quickly, and prompts tuned to one model decay with them. Tests, interfaces, documentation and controls can reduce the cost of changing models when something better arrives.
The cost of moving this fast
At the frontier, a practice can feel obsolete within a quarter. Attention expanded from prompt phrasing to context, then to harnesses and the loops that now prompt agents. These layers accumulate. OpenAI's GPT-5.5 guidance, for example, says teams can often use shorter prompts while defining tests and stopping conditions more clearly.
That pace is exciting and exhausting. Organisations should give teams time to experiment and a sensible cadence for adopting tools. I return to the effect on roles, learning and well-being in the third article.
The bottom line
For a growing group of AI-intensive teams, AI is becoming an execution layer rather than an optional assistant. The durable approach lets agents do more without making the organisation less able to understand or operate the result.
We used to integrate AI into the workflow. At the frontier, we are now building the workflow around it.