Why AI Programming Is Evolving from Loops to Graphs

The article examines a rapid shift in AI programming discourse: within six weeks, the focus moved from designing loops that drive individual agents to organizing multiple loops into explicit task graphs. Peter Steinberger’s June 2026 tweet urged developers to stop prompting agents directly and instead design loops that prompt agents; by July he asked whether the industry had shifted to graphs. The author argues that Graph Engineering does not replace Loop Engineering but rather organizes multiple loops, verification gates, and roles into a runnable graph with typed dependencies and state transitions.

Four Layers of AI Engineering

The author positions four concepts in a hierarchy:

SDD – defines overall goals, boundaries, and acceptance criteria.

Harness – provides context, tools, permissions, and runtime environment.

Loop – drives a single node to converge based on feedback and evidence.

Graph – organizes multiple nodes’ dependencies, state, routing, and overall acceptance.

Loops sink from the outermost control structure into node-level or subgraph-level convergence mechanisms inside a graph.

Why a Single Loop Hits a Ceiling

Tasks like modifying an interface, fixing a bug, or adding tests can run in a single loop of execute–check–fix–reverify. As tasks grow, new problems appear:

Architecture, frontend, backend, and testing have dependency, parallelism, and merge relationships.

Design gaps, code errors, environment issues, and permission problems require different routing paths.

Local test passes do not guarantee cross-module contracts, permission boundaries, or full regression.

A failing branch should be locally retried; different roles need isolated contexts and permissions.

The core issue: if task dependencies, deliverables, verification relations, and failure routing remain hidden inside a main agent’s context, the system only has an implicit graph that is hard to inspect, recover, or govern.

Two Meanings of “Graph” in Current Discussion

Around Steinberger’s question, two interpretations emerge:

Task and execution graph – nodes are tasks, agents, tools, or human approvals; edges express dependencies and conditional routing. LangGraph and Microsoft AutoGen’s experimental GraphFlow already provide such orchestration.

Feedback and governance graph – Carlos E. Perez emphasizes a “network of loops” where optimization loops need counter-metrics, independent evaluation, auditing, and goal revision to avoid converging on wrong objectives.

The author argues both are needed: a work graph answers how the task gets done; an evidence graph answers why the result is accepted. Without independent evidence, a system may efficiently complete the wrong task; without work dependencies, multiple roles and check loops cannot stably collaborate.

Working Definition of Graph Engineering

Graph Engineering is the practice of explicitly modeling complex AI tasks as a runtime graph composed of tasks, execution roles, tools, verification gates, and human decisions, and controlling branching, parallelism, merging, rollback, local re-execution, and replanning through typed dependencies and state transitions.

A graph is abstracted as G = (V, E) where: V – nodes: agents, programs, tools, verifiers, human approvals, or subgraphs. E – edges: dependencies, artifact passing, conditional routing, failure handling, or compensation relations.

Each run instance records node versions, inputs/outputs, execution evidence, and budgets.

The graph need not be a DAG; review returns, test failures, or design additions create back-edges – loops are cycles within the graph. The real design challenge is the runtime contract of nodes and edges. Each node must answer four questions: what it depends on, what it produces, what proves it is done, and where to go on failure.

Example node contract (YAML-like):

node:
  id: backend-rate-limit
  owner: backend-role
  requires: [design-baseline]
  produces: [code-diff, test-evidence]
  done_when: [build-passed, required-tests-passed]
  on:
    design-gap: route-to-architecture
    implementation-error: retry-locally
    environment-error: blocked
    approval-required: waiting-human

Concrete Example: Adding Rate Limiting to a Login Endpoint

Requirement: same account and source IP limited to 5 login attempts per 60 seconds; 6th returns 429 with audit log, without changing existing auth results or other endpoints.

In a single agent loop, one agent could handle design understanding, code changes, tests, and fixes. In a real project, the task expands into a graph:

After design review passes, backend implementation and test case design run in parallel.

Integration verification starts only after both branches complete.

Backend node internally runs an “implement–build–test–fix” loop.

Security check failure routes only back to the affected implementation node.

Frontend node is added only if the design baseline explicitly requires handling 429 – not automatically because a frontend role exists.

Completion is not just “all nodes green.” The evidence graph must confirm rate-limit test cases and original login regression pass, audit logs are generated, and evidence binds to current code and design versions. This is the engineering value of Graph: it turns implicit dependencies, responsibilities, evidence, and exception paths into an executable, inspectable system structure.

Why the Focus Shifted in Six Weeks

No new computer science was invented; the engineering focus moved up rapidly:

Loops enabled agents to work continuously, making task decomposition, dependency management, and failure recovery the new bottlenecks.

Parallel agents increased speed but turned result coordination, state consistency, and error propagation into explicit problems.

Local convergence cannot prove global correctness; cross-node contracts, global invariants, and independent verification are needed.

Workflows, state machines, and dependency graphs already existed; they have become the center of agent engineering discussion.

Anthropic’s multi-agent research retrospective also notes async execution brings coordination, consistency, and error propagation challenges. As agent count grows, questions of who can start, wait for whom, share artifacts, affect whom on failure, and who ultimately accepts become critical. This six-week shift is a cognitive migration from “how to keep a single task running” to “how to organize multiple closed loops into a governable system.”

Six Capabilities Required for Production Graphs

Node contracts – explicit inputs, outputs, responsible roles, permissions, and done conditions.

Typed edges – dependency, artifact, conditional, failure, and compensation relations machine-judgable.

Graph state – which nodes are pending, running, done, waiting, blocked, or failed.

Scheduling and recovery – parallelism, merging, cancellation, local re-run, idempotency guarantees.

Evidence and verification gates – who checks, independence, objectivity, version binding.

Observability and budget – trace critical path, failure propagation, tokens, time, human intervention points.

The most overlooked is failure propagation after local success: when upstream design or interface versions change, completed downstream nodes may become invalid. The system must determine which artifacts to invalidate and which checks to re-run, rather than relying on stale “success” states. This makes Graph Engineering harder than traditional workflow orchestration: nodes can be non-deterministic agents, and the graph continuously receives new evidence.

Graph Is Not the Default Answer

Boundaries to clarify:

Graph ≠ multi-agent; a single agent can execute a task graph node by node.

Multi-agent ≠ Graph; a group chat without dependencies, state, deliverables, and exit conditions remains implicit collaboration.

Graph ≠ a specific framework; not a knowledge graph or code dependency graph.

Graph does not imply agents dynamically create and rewrite the entire graph from the start.

If a task involves one well-bounded module, linear sequence, and deterministic checks, a controlled loop suffices. Graphs are warranted when there are multiple interdependent deliverables, parallelism and merges, independent roles and permissions, human verification gates, or local recovery requirements. Even then, start with a small, static, observable graph; prove node contracts, evidence passing, and failure routing work stably before adding dynamic splitting and graph restructuring.

Graph Already Appears in the Author’s Workflow

The author currently uses separate threads for architecture, frontend, backend, and test roles. Architecture maintains design baseline; developers implement against it; testers independently verify design and code. When developers find design gaps, they cannot modify the baseline directly. Lacking automatic routing, the author manually collects design issues, has architecture update docs, then developers re-read the new baseline.

This manual coordination mixes two problem types:

Non-blocking design additions that can be batched.

Blocking issues that freeze interface, data structure, or business rule implementation and must be routed immediately to architecture.

Making this coordination explicit yields a typical graph path:

Design issues must record source node, design version, missing decision, blocked scope, affected artifacts, and optional suggestions.

Architecture returns new version and change scope so development nodes know what to resume.

The whole graph should not pause; unaffected nodes continue. Only nodes depending on missing design enter a recoverable waiting_design state, not a terminal blocked state.

On new baseline release, the system must judge which code, test, and review results are now invalid.

Today these collection, routing, state switching, and recovery steps are human-maintained; Graph Engineering aims to explicitize stable relationships and gradually hand them to system scheduling.

Summary

Steinberger’s rhetorical question did not formally declare Loop Engineering dead, but it accurately identified the next layer of problems in AI programming. The progression is: Prompt guides a single action. Harness provides execution conditions. Loop drives local convergence. Graph organizes global collaboration. SDD constrains final direction.

Moving from Loop to Graph is not discarding loops; it acknowledges that complex software development was never a single loop. Loops make one task continuously approach completion; Graph ensures multiple converging tasks do not lose the overall goal in collaboration.