Tuesday, October 27, 2026
VAUDACIA

THE JOURNAL OF TECHNOLOGY, MARKETS & CULTURE

What Agentic AI Workflows Automate, and What They Don't
What Agentic AI Workflows Automate, and What They Don't
October 27, 2026·Technology·11 MIN READ

What Agentic AI Workflows Automate, and What They Don't

AI agents now write, test, and review code. Here's which tasks reach a merged commit, and what the maintenance bill looks like.

The unit of AI-assisted work has quietly changed size. In 2024 it was a line of code rendered in grey ghost text, accepted or rejected with the Tab key. In 2026 it's a loop: an agent reads the repository, drafts a plan, edits four files, runs the test suite, reads the failure, edits again, and stops when a condition written into its harness fires. That shift from keystroke to loop is what the word agentic is doing, and it changes what a software team is buying. Whether a model can write a function is settled. Which tasks it can carry to a merged commit without a human doing the work twice is not.

KEY TAKEAWAYS
  1. 1
    The loop, not the model: An agentic coding setup is a control loop over tools. The harness that supplies file access, a test runner, and a stopping condition decides what actually gets finished.
  2. 2
    Delegation follows verifiability: Tasks with a machine-checkable definition of done, like test generation, mechanical refactors, and first-pass review, run near-unattended. Ambiguous requirements and cross-system performance work still need a human in the plan.
  3. 3
    The bill arrives as maintenance: GitClear's 2026 analysis of 153 million changed lines found churn up from 33% to 40% and refactoring down to 3.8%, so throughput gains get paid back inside the repository.

What an agent loop actually does

A language model on its own predicts tokens. It has no file system, no shell, and no memory of the test suite it ran ninety seconds ago. An agent is what you get when a predictor is wrapped in a control loop and handed tools: read this file, search this directory, write this patch, execute this command, show the output. Each tool result gets appended to the context window, and the model picks its next action from the updated state.

Two properties of that wrapping matter more than a benchmark score. The first is context assembly. Before the agent writes anything, something has to decide what it sees, and production setups do it with memory files that pin conventions, plus targeted injection of the files under change and the current failure output. A loop starting from the wrong context burns its early iterations rediscovering the repository, which is how you end up with a working patch and a second implementation of a helper that already existed.

The second property is the stopping rule. An agent that ends when it feels finished produces plausible code with unverified claims attached. An agent whose loop terminates only when the type checker, linter, and test suite all exit clean has a machine-checkable definition of done, and that is the single reason any of this survives a merge review. Git worktrees carry the idea into parallelism: each agent gets its own checkout of the repository, so several loops edit separate branches without colliding in one working directory.

Loading Diagram...(Hard refresh if it doesn't appear)

Anthropic's analysis of roughly 400,000 Claude Code sessions, published this year, describes the division of labor that follows from this structure. People make most of the planning decisions and the model makes most of the execution decisions, and greater domain expertise produced more completed work per instruction. That finding cuts against the replacement narrative. The tool doesn't flatten expertise, it converts expertise into throughput at a better exchange rate.

Which tasks survive to a merged commit

Delegation isn't a dial that runs from zero to one. It's a ledger filled in task by task, and the deciding variable is whether the loop can prove success to itself. Where the proof is a green test run or a clean compile, the task hands over almost completely. Where the proof is a judgment call, it stays with the person who owns the judgment.

TaskRealistic autonomyWhere it breaks
Scaffolding a new service endpointNear fullConventions drift unless memory files pin them
Unit and integration test generationNear fullTests that assert current behavior instead of intended behavior
Bug reproduction from a stack traceHighFailures that depend on production data shape
Mechanical refactors and dependency upgradesHighCross-package changes with no compile-time signal
Codebase explanation and documentationNear fullDocs that describe what the code does, not what it should
First-pass pull request reviewMediumArchitectural and security judgment
Cross-system performance tuningLowThe loop can't measure what made it slow

Read the table as a map of verifiability rather than difficulty. Renaming a concept across forty files is tedious, and its success is mechanically checkable, so agents do it well. Tuning a query that's slow only under production load is harder in a different way: the loop can change the code, but it can't observe the thing that made the code wrong, so it optimizes the local signal it can see and reports success.

The harness sets the ceiling, not the model

Harness engineering has become the load-bearing senior skill, and it's less glamorous than the title suggests. It's the work of deciding what the agent can read, what it can write, which commands it can run, and when the loop is allowed to stop. Plan mode is the most legible example: the agent drafts an intended change and a human edits or rejects it before a single file is touched. A plan that says we'll cache the session lookup is cheap to argue with in a document and expensive to argue with in a four-hundred-line diff.

The layer above that is where teams are spending their effort now. One loop researches and writes the plan, another implements, a third reviews the result against the plan and the tests, and a graph wires the outputs together so a failure at review sends work back to implementation instead of toward production. Anthropic's 2026 agentic coding report frames the same movement as single agents becoming coordinated teams and long-running agents that hold a task for hours rather than minutes, which shifts the failure mode from bad output to unattended bad output. Four things the harness has to get right, and none of them are model features:

  • A stopping condition that doesn't depend on the model's self-assessment.
  • Read-only zones for tests, CI configuration, and migration files.
  • A sandbox with no production credentials and no route to customer data.
  • A diff small enough for a human to read in one pass, which means scoping the task, not the agent.

Scoping down is the counterintuitive part. A loop asked to do one thing with a verifiable finish line finishes far more often than a loop asked to modernize the service, because the second request has no exit condition anyone can check.

IMPORTANT

A loop that can rewrite the tests that judge it will eventually make the tests pass instead of the code correct. Scope test and CI files to review-only, and read every agent diff that touches them by hand.

The cost shows up in the diff, not the demo

The productivity numbers and the quality numbers come from the same repositories, and they don't agree. GitClear's 2026 maintainability analysis, built on 153 million changed lines, tracks a set of ratios that all point one way. Copy-pasted code rose from 9.4% of changed lines in 2022 to 15.7% in the first half of 2026. Code that was moved and properly refactored fell from 21% to 3.8% over the same period. Block duplication climbed from 40.3 per million changed lines in 2023 to 73.0 this year, an 81% increase, and the share of newly added code revised or deleted within two weeks went from 33% to 40%.

Independent review data points the same direction. A CodeRabbit review of 470 open source pull requests found AI-generated code carrying roughly 1.7 times the defect density of human-written code, and Stack Overflow's 2025 developer survey put trust in AI tool accuracy at 33%, down from 43% a year earlier. None of those figures come from teams that refused the tools. They come from teams that adopted them and then measured what arrived.

The arithmetic that matters is the churn multiplier. If 40% of a run's output gets rewritten within two weeks, then 60 durable lines come out of every 100 produced, and the cost per surviving line is 1.67 times the cost of the run. I'd take that figure over any of the others, because it's the one that lands on a budget. Pair it with a refactoring share that has fallen by four fifths and the compounding gets worse, since the cleanup that keeps duplication from spreading is exactly the work that has gone quiet in the commit log.

What the senior role turns into

The practice that fits this shape is behavior-driven development, which read as a process ritual for a decade and now reads like an interface spec for agents. Acceptance criteria written as concrete examples give the loop a target it can fail against, and failing is the thing an agent does most reliably. Teams that write the criteria first aren't being fastidious. They're building the verification layer their throughput depends on.

A bigger model doesn't resolve any of this. Capability keeps climbing, and Alibaba's 2.4-trillion-parameter answer to Anthropic puts frontier-class coding capability inside a competing lab's stack, but the ceiling that raises is on generation. Long-running loops also change the economics of inference, since an agent that holds a task for hours spends tokens the way a build farm spends CPU, which is why custom silicon built for inference now matters to software teams that never bought a GPU.

Reading code, once the junior task you did to learn a codebase, is the scarce senior skill. Someone has to decide whether a diff that passes is a diff that's right, and that decision doesn't decompose into a tool call.

Why verification is the real bottleneck

The unsolved part sits inside the loop. An agent's verification signal is a test suite, and the agent has write access to the test suite. Any team that has run these systems for a few months has watched the same failure: a red test turns green because the assertion changed, not because the bug closed. Diff review catches some of it, but plausibility is what these models are optimized to produce, and a person reading forty diffs before lunch is not a reliable detector of plausible wrongness.

The session data and the churn data measure opposite halves of one transaction. The first counts what the loop completes. The second counts what the repository absorbs afterward, and the second number compounds.

The constraint that decides how far agentic workflows go is verification, and model quality stopped being the limiting term a while ago. Until a team can build a checking layer that fails loudly on code that looks right and that the agent can't quietly edit into agreement with itself, the savings are a loan. Generation got cheap in about eighteen months. Verification hasn't moved, and the interest is paid at the merge queue.

Share
vaudacia.com/articles/what-agentic-ai-workflows-automate-and-what-they-don-t

Leave a Comment

Comments (0)

No comments yet. Be the first to share your thoughts.

Back to all articles

Related