From AI-Assisted to AI-First Engineering: The Harness Your Team Actually Needs

Legacy TypeScript website content. Shared public website, blog, protocol, guide, and language-neutral docs ownership now lives in ~/src/graphrefly under D563. This page is retained here only as migration/reference material while the TS API generator still lives in website/.

From AI-Assisted to AI-First Engineering: The Harness Your Team Actually Needs

Arc 7, Post 45 — The Harness Infrastructure for AI-First Teams

---

CreoAI CTO Peter Pang gave a talk recently about what he called “AI-First” engineering. The key claim: you don’t get there by bolting AI onto your existing processes. You have to rebuild three things — your product process, your testing process, and your codebase’s state model — around AI from the ground up.

He’s right. And the reason most teams struggle with the rebuild is that they don’t have the right substrate to build on.

Specifically: they’re trying to run AI-First processes on infrastructure designed for AI-Assisted workflows. The tools don’t match the architecture. The debugging story doesn’t match the complexity. The state model doesn’t support what AI systems actually need to do.

Here’s how GraphReFly addresses each of Pang’s three rebuilds — and what v0.4 adds to make the substrate solid.

Rebuild 1: The product process — describe, review, run

The traditional product process is: write a specification, implement it, test it. The AI-assisted version is: write a specification, have AI help implement it, test it with AI help.

The AI-First version is different: describe what you need in natural language, have AI compose the topology that implements it, review the topology visually before it runs, then run it and iterate by talking — not by coding.

GraphReFly’s describe snapshot is designed for exactly this. It’s a declarative topology view that constrains review to structural operations: add this node with these deps, connect these sources, apply this operator. The constraint space is narrow, like SQL constraining database operations — which means the LLM gets it right more often, and when it gets it wrong, the error is structural and obvious, not subtle and hidden in code.

The review step happens at the describeToMermaid(graph.describe()) level (any of the describeTo* pure renderers from @graphrefly/ts/render works the same way): before a graph runs, the engineer reviews a simplified flow view. Not code. Not a wall of JSON. A node graph that shows what connects to what and in what order.

A ──► B ──► D ──► output
           ▲
C ─────────┘

If the topology is wrong, you say so. The LLM revises. The revision is structural — a node added or removed, an edge rewired — not a code change.

This is the product process rebuilt: humans review topology, AI executes it.

Rebuild 2: The testing process — harness-aware evaluation

Pang’s testing process rebuild is: AI tests AI-generated code. GraphReFly’s version is more specific: the harness evaluates itself.

The 7-stage reactive loop (INTAKE → TRIAGE → QUEUE → GATE → EXECUTE → VERIFY → REFLECT) is the harness. The VERIFY stage isn’t a separate test suite — it’s a reactive node that receives execution output and checks it against declared success criteria. The REFLECT stage analyzes patterns across multiple VERIFY results and updates the strategy state for the next cycle.

This is AI testing AI, but within a reactive graph that makes the testing loop’s own state observable:

harnessProfile() // → queue depths, retry counts, strategy scores, VERIFY pass rates

The diamond race bug we described earlier is a good example: the retry tracking failure was caught by harnessProfile() showing an escalating retry count that shouldn’t have been possible. Once visible, the root cause was diagnosable. Without the profile, the wrong value would have propagated silently until the loop exhausted itself.

The testing process is rebuilt when the test loop itself is a first-class observable system — not a test harness that runs separately from production code, but the same reactive graph, with the same describe() and trace() APIs, running in production.

Rebuild 3: The state model — reactive graph, not file system

This is the rebuild most teams skip — and the one that matters most.

Current AI agent architectures typically use one of two state models: file systems (read/write files to pass context between steps) or conversation threads (accumulate messages in a context window). Both are snapshot models: each step reads a frozen snapshot of state that may have been stale since it was written.

The consequence is what gets called the “context window problem” — agents spend tokens reconstructing current reality from stale state, making decisions based on outdated information, and producing inconsistent results when the stale state doesn’t reflect what other parts of the system have already done.

GraphReFly’s state model is fundamentally different: state pushes. When node A’s value changes, every node that depends on A is notified and recomputes — automatically, without any agent asking “what is A’s current value?” The graph always reflects current reality. Stale state isn’t possible because stale state can’t persist: any change propagates immediately to all dependents.

For multi-agent systems, this is the difference between agents that need to poll for updates and agents that receive updates. The reactive model eliminates the polling loop — not as an optimization, but as a structural property of how state works.

What v0.4 adds: the substrate for AI-First

The v0.4 work hardened the three layers that AI-First architectures depend on:

Correctness foundation (P2/P3): When AI generates the topology and that topology runs in production, the correctness invariants need to be unconditional. An AI-generated graph shouldn’t fail because of a wave-timing race or a stale cache read. The foundation redesign makes correctness structural, not dependent on knowing which composition patterns to avoid.

Observable state (unified describe): AI-generated systems are harder to debug when you can’t see their runtime state. The unified describe() snapshot — paired with the describeTo* pure renderers in @graphrefly/ts/render — plus trace() and resourceProfile() give AI models the same structured access to runtime state that human engineers have. When an AI agent debugging a running harness can call graph.describe() and get the same structured output a human engineer would use, the debugging process becomes collaborative — not “the engineer debugs what the AI produced” but “both use the same tools.”

Durable execution (attachStorage): AI-First workflows run for hours or days. They need to survive restarts, handle partial failures, and resume from checkpoints without losing state. attachStorage with cascading tiers and V0 version-counter shortcuts makes this operational without requiring custom storage infrastructure per deployment.

The management layer: topology design, not code review

Pang’s final point is the one engineering leaders respond to most: “my management time was greatly reduced.” The reason it was reduced is that the AI-First architecture changed what managers review.

In a traditional engineering workflow, a manager reviews code — which requires understanding implementation details, knowing which patterns are correct, catching subtle bugs. This is high-cognitive-load review.

In an AI-First workflow built on a harness like GraphReFly, the manager reviews topology. A node graph showing “these inputs flow through this processing chain to produce these outputs” is reviewable without knowing the implementation. The validator shows “VERIFY pass rate: 94% over last 1000 items.” The trace answers “why was this item flagged?” with a causal chain.

The manager’s role becomes: is the topology correct? Are the success criteria the right ones? The topology is the program. The harness is the execution and verification substrate. The AI is the implementer that fills in the node functions.

This is what AI-First engineering actually means: the humans design the architecture, the AI executes within it, and the infrastructure makes the execution observable, auditable, and resumable.

GraphReFly v0.4 is that infrastructure.