Software Engineering Isn't Solved. It Moved Upstream.
Software engineering in 2026 feels like a solved problem. Top models paired with a good harness now clear 70 to 90 percent on SWE-bench Verified, up from roughly 4 percent in 2023. TELUS reports saving over 500,000 developer hours with agentic coding systems, and OpenAI runs a million-line production codebase with no manually written code.
Then loops arrived, and the feeling got stronger. Why prompt an agent turn by turn when you can define a goal and let a system iterate until the work is done?
There's a catch buried in that word "done". It lands hardest on the people who thought AI made planning optional. More on that in a moment.
The loop's short history
Mid 2025: Ralph. Geoffrey Huntley popularized the crudest possible version of the idea, a bash one-liner that pipes the same prompt into a coding agent forever:
while :; do cat PROMPT.md | claude-code; done
Each iteration starts with fresh context. Memory persists in git history, a progress file and a requirements document. The loop runs until every item in the PRD is complete. People used it to ship entire repos overnight, and Huntley used it to build a complete programming language over three months of mostly autonomous operation.
September 2025: loops become a design discipline. Simon Willison argued that coding agents are systems that can exercise the code they write, correct their own errors and run experiments, and that designing the agentic loop is a critical new skill. The loop stopped being a hack and started being something you architect.
June 2026: loops go mainstream. This past weekend, Peter Steinberger, the creator of OpenClaw, posted that you shouldn't be prompting coding agents anymore, you should be "designing loops that prompt your agents". Boris Cherny, who leads Claude Code at Anthropic, says he no longer prompts Claude directly: "My job is to write loops". Addy Osmani gave the discipline a name the same weekend. Loop engineering.
The tooling caught up at the same time. What was a pile of bash you maintained alone a year ago now ships as product features in both Claude Code and the Codex app. A five-line hack became a flagship capability in under twelve months.
If you read my harness engineering piece, this is the next floor of the same building. Osmani positions loop engineering one level above the harness: the same environment, but running on a timer, spawning helpers and feeding itself.
What a loop actually is
Strip away the branding and a loop is a small system with five pieces plus a memory.
Automations are the heartbeat. A scheduled run that does discovery and triage on its own: scan yesterday's CI failures, read the open issues, decide what's worth doing. In the Codex app this is the Automations tab. In Claude Code it's scheduled tasks, hooks or GitHub Actions.
Worktrees keep parallel agents from colliding. Each agent gets its own checkout on its own branch, the same way two engineers avoid committing to the same lines. Both tools now build this in.
Skills codify project knowledge so the agent stops guessing. Conventions, build steps, the "we don't do it this way because of that one incident" knowledge that otherwise lives in someone's head. Written once, read every run.
Connectors plug the loop into your real tools. Issue trackers, databases, Slack. The difference between an agent that says "here's the fix" and a loop that opens the PR, links the ticket and pings the channel when CI goes green.
Sub-agents split the maker from the checker. The model that wrote the code is too generous grading its own homework, so a second agent with different instructions verifies the work. Anyone who has run a maker-checker control in financial services will recognize the pattern immediately.
The sixth piece is memory: a markdown file or a board that lives outside any single conversation and tracks what's done and what's next. The model forgets everything between runs. As Osmani put it, "the agent forgets, the repo doesnt".
The primitive that ties it together is the goal command. Both Claude Code and Codex now have a /goal mode: the agent keeps working until a condition you wrote is actually true. You give it something like "all tests in test/auth pass and lint is clean" and walk away. In Claude Code, a separate model checks the stop condition after every turn, so the agent that wrote the code isn't the one deciding it's finished.
Read that primitive again, because it contains the entire catch.
The catch
A loop terminates against a condition. The condition has to be verifiable, written down, and decided before the loop starts. There is a name for that artifact. It's a specification.
This is the part the vibe coding era promised we could skip. Describe what you want loosely, let the model fill in the gaps, ship the prototype. That worked for demos because a human was in the loop, eyeballing every result and course-correcting in real time. Remove the human and the eyeballing has to be replaced by something the machine can check.
Even Ralph, the dumbest loop ever built, depended on this. The bash one-liner gets the attention, but the load-bearing component was always the PRD sitting next to it. The loop runs until all PRD items are complete. No PRD, no termination condition, no loop. Just an agent burning tokens in a circle.
So here's what a loop actually is, underneath the tooling: continuous verification against requirements. Every cycle asks the same question. Have all the requirements been met, in a way I can check? That question has been the backbone of serious software delivery for decades. Acceptance criteria, definition of done, UAT sign-off. The loop didn't eliminate that discipline. It automated the enforcement of it.
The vibe coder's loop either runs forever or stops on a lie. "Done" against a vague goal means the verifier model squints at ambiguous intent and makes a judgment call, which is the same failure mode as the original vibe-coded prototype, now running unattended at 3 a.m.
What this looks like in a pension fund
Take a plan amendment that changes early retirement reduction factors. A loop could absolutely implement it: automation picks up the ticket, a sub-agent drafts the changes in an isolated worktree, a verifier sub-agent runs the calculation test suite, the loop opens the PR when everything passes.
But every part of that depends on specification work that happened first. The amended formula has to be written down precisely. The edge cases have to be enumerated: grandfathered members, bridge benefits, partial vesting, members who terminated before the amendment date. Each one needs a test that encodes the expected benefit amount.
The loop's stop condition is "all benefit calculation tests pass against the amended formula". Writing that sentence took ten seconds. Making it checkable took an analyst, an actuary and an engineer agreeing on what correct means for every member cohort. That agreement is the engineering. The loop just refuses to let you skip it.
What the loop won't do for you
Osmani is openly skeptical of his own framing, and his caveats are worth taking seriously.
Verification is still on you. A loop running unattended is also a loop making mistakes unattended, and even with a verifier sub-agent, "done" is a claim and not a proof. Token costs can also spiral. Sub-agents each do their own model and tool work, and usage patterns vary wildly depending on how token-rich your budget is.
Comprehension debt grows faster, not slower. The quicker the loop ships code you didn't write, the wider the gap between what exists in production and what your team actually understands. A smooth loop accelerates that gap unless someone reads what it builds.
And the sharpest observation in his piece: two people can run the same loop and get opposite results. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all. The loop can't tell the difference. The replies to Steinberger's post split hard between converts and skeptics, and I think both camps are reacting to the same truth from different directions. The loop amplifies whatever judgment you bring to it.
The work moved upstream
So, is software engineering solved? The implementation layer is closer to solved than most of us expected to see this decade. But the question contains a category error. Writing code was never the whole discipline. It was the part that happened to be visible.
The progression of the last eighteen months tells the story. Vibe coding removed the typing. Spec-driven development brought back the requirements. Harness engineering built the environment that keeps agents reliable. Loops put the whole thing on a schedule. At every step, the durable skills moved upstream: away from syntax, toward specification, verification and judgment.
Which means the engineers who thrive in the loop era are the ones who can answer one question with precision: how will we know this is done? If your team can produce verifiable definitions of done, loops are the biggest force multiplier yet. If it can't, no amount of tooling will save you, because the loop will faithfully automate your ambiguity.
Start there. Not with the bash one-liner, not with the Automations tab. With the spec. The loop is just the machine that holds you to it.
Join the discussion on LinkedIn.