Every few months, we rename what software engineers do with AI. In two years we’ve gone from context engineering to harness engineering to loop engineering. The buzzwords come and go, but they track a real question: what is the human actually for?
In the harness engineering era, we built better tools to help agents do the work. Good tools and harnesses were guardrails that kept the model from getting lost. Even so, agents often went down wrong paths and spun endlessly. Back then, human taste and intuition helped steer confused agents toward more promising strategies.
Then, starting with Mythos/Fable and accelerating with Astra and Opus 5.5, it began to feel like agents could deliver any verifiable coding outcome with little to no hand-holding. The vibe shift was palpable.
With seemingly infinite magical solution machines now at your disposal (limited only by money and good sense), it can feel overwhelming to think about your remaining role in the system. As of late 2026, what should we entrust to agents, and what role should human judgment and taste continue to play? The answer comes down to verification.
Levels of verifiability
Verifiability is a core idea in model training and reinforcement learning: what you can verify is what AI automates first. It’s just as useful when we put those models to work, agentmaxxing our way through complex tasks.
When directing coding agents, ask of every feature: who can ultimately sign off that it’s correct? The code, the builder (you), the users, or long-term market forces? The answer to that question should shape how you treat agents and their outputs.
I think of this in terms of four verification loops.
The greatest pitfall of working with agents is confusing one loop for another and setting up the wrong kind of verification.
For example, closed-loop problems are best handled with better tests, not more code review, because we know that agents excel at problems trainable via RL. Conversely, when an agent proposes a solution to what is really an external- or long-loop problem, be skeptical of where its ideas come from. (Most likely Reddit.)
Trusting the closed loop
Trying to insert human taste and judgment into what is fundamentally a closed-loop problem is not a good use of time.
In 1993, Intel released the first Pentium processor, the start of a legendary line of CPUs that would dominate the global computing market for the next decade. A year later, a math professor discovered that it got certain divisions wrong. That was probably the last time in human history that an end user had good reason to check that a CPU did the math correctly. Today, we would consider that verification effort a waste of time, at least for humans. (I’m sure Intel still runs some suite of unit tests to avoid repeating that embarrassment.)
The equivalent bar for coding agents is rising fast. Just two years ago, we were hesitant to have Copilot remap a button in a web app without a human clicking on it twice. Today, Opus 5.5 can build you a CRM from scratch and every button will do what it says, because the agent has already run live browser tests and clicked every one itself.
When putting machine intelligence to work, adding duplicate verification to the critical path slows you down. These checks are never free, and even the smallest unit test has a time and compute cost. If we trust the model to verify that buttons work, we should let it own that work, just as we trust CPUs to divide. Your job is still to ship code proven to work, but the agent can now do more of the proving.
An employer of agents must develop a strong intuition for where a task sits on the spectrum of verifiability, and that intuition needs updating as models improve.
Optimizing the human loop
Once closed-loop work is covered by good automated tests, the next bottleneck is the human loop, the familiar review queue of anyone running agents in parallel.
Before agents, we front-loaded the human loop with design docs and whiteboarding, because implementation was expensive and a wrong technical bet could cost weeks.
In the post-agent world, the calculus flips. Human attention is better spent at evaluation: have agents build as many reasonable alternatives as the inference budget allows, then review what comes back. To keep that from flooding the queue, each result should arrive as high-level as possible, with as much verification as possible done up front, not quietly deferred. The review queue should hold findings instead of code.
We already see this in UI/UX design, where designers use agents to build multiple alternative designs in the live app to prototype and test ideas. I think this pattern is relevant to all layers of software.
The caveat: as long as inference and infrastructure are finite and pricey, some upfront estimation still pays for itself by avoiding big time sinks. The shift is relative.
Accelerating the open loops
One of the slowest parts of building products is getting user feedback that matters. This is particularly true when the product is built for a user demographic that the builders do not belong to.
For this, the biggest contribution of better coding agents is faster data analysis. Two other approaches feel worthwhile to explore: quickly shipping bespoke experiment variants in response to user feedback, and simulating user behavior in a closed loop.
Long-loop problems often elude even the best human judgment, but agents help here too. Because agents parallelize, we can run more concurrent long-term bets than ever before and monitor them consistently over time.
Problems become verifiable
Don’t confuse a task that is intrinsically unverifiable with one that was merely too expensive or tedious for humans to verify, or too cumbersome for agents to verify today.
For example, we might think of a choice between microservices and a monolith as a “human intuition” problem that is not verifiable in a closed loop. The difference seems like something you can only feel over years of tech debt and deployment pain.
But with enough agents, it’s possible (or soon will be) to simulate how a codebase evolves under each approach and measure which metrics actually differ. Benchmarks like SWE-CI already have agents replay months of real commit history to measure how well code holds up as it changes.
Applying this lens to every problem is a skill worth building. Not every problem will or should cross the line, but more problems do than ever before. Whereas in the past we often adopted off-the-shelf frameworks and products to benefit from the learned experiences of prior users, now we can study and experiment with them at scale to extract only the bits that are relevant to our specific situation.
Something to keep in mind here is that verifiable problems can sometimes slip back into unverified by accident. For example, if your codebase relies on Docker to run some integration screenshot tests, but Docker was accidentally uninstalled in the environment, the agent may decide to skip that step when crafting its proposals. Allowing such failures to compound silently will create a mess that is painful to clean up later.
Conclusion
The core idea is to keep verification front of mind and always know the answer to one question: who closes the loop?
As tools get better and models improve, the key to remaining competitive as a team is to get good at pushing problems across that line. What would it take to turn any given problem into something an agent can verify on its own? Sometimes the answer is a better test suite. Sometimes it’s a whole new way of running experiments.
Context engineering, harness engineering, loop engineering: each name moves the human one step further from doing the work and one step closer to defining what done looks like, in a form agents can verify. Whatever we call it next, the job is the same. Figure out who closes the loop, and if the answer is no one yet, find a way to make it the machine.