Loop Engineering Is Now a Real Category — Here's Who's Building It

Last week, Colin McDonnell shipped something called Fray. If the name doesn't ring a bell, the numbers do: Colin is the creator of Zod (31,000 GitHub stars) and tRPC (34,000 stars) — two of the most influential open-source projects in the TypeScript ecosystem. When someone with 65,000 combined stars ships a new project, people pay attention.

verify: github.com/colinhacks/zod (31,000 stars, 2026-06-28); github.com/colinhacks/trpc (34,000 stars, 2026-06-28)

Fray is an orchestrator-first multi-agent methodology for Claude Code. It gives each agent a role, isolates their context, and dispatches work with reconciliation hooks. It has a thread board, a board CLI, and a per-project .fray/ directory.

In other words: Colin McDonnell independently built a Loop Engineering tool.

This is the strongest possible signal that Loop Engineering — the pattern of chaining specialized coding agents into plan→build→verify→fix workflows and running them unattended — is a real category. Not a single-project anomaly. Not a niche blog tag. A genuine architectural pattern that multiple builders, across ecosystems and languages, are converging on independently.

27+ projects, one pattern

As of June 2026, the Ralph Workflow ecosystem tracker counts 27+ independent implementations of the Loop Engineering pattern. Some highlights:

verify: github.com/SantanderAI/ralph (78 stars, 2026-06-28), github.com/bastani-inc/atomic (254 stars, 2026-06-28), github.com/colinhacks/fray (4 stars, 2026-06-28), codeberg.org/RalphWorkflow/Ralph-Workflow (13 stars, 2026-06-28)

The interesting thing isn't the individual projects. It's that they're all solving different sub-problems of the same pattern. SantanderAI focused on minimalism (78 lines of bash). Fray focused on multi-agent role isolation and dispatch. Neuralyzer focused on context management during loops. Ralph Workflow focused on phase routing, cost arbitrage, and vendor-neutrality.

This is how real categories form: not from one project claiming a space, but from multiple builders recognizing the same structural problem and solving complementary pieces of it.

The thing they're all solving

Every Loop Engineering tool is answering the same question: how do I run coding agents unattended without the output being chaos?

The naive answer is "put an AI in a for-loop." That produces: giant diffs, confident-but-wrong summaries, context windows that fill up mid-run, and a sunk-time cost that's higher than just writing the code yourself.

The pattern that works is:

1. Plan first — define the work before writing code
2. Build with guardrails — tests, linters, type checkers
3. Verify what was built — a separate agent reviews the output
4. Fix what verification catches — loop back to build if needed
5. Hand off a concrete result — a diff, a test report, a review checklist

This is not "chat with an AI." It's not a copilot. It's an autopilot: you write the spec, you launch it, you walk away, and you come back to finished, reviewed, tested commits.

Why Colin McDonnell validates the category

When a solo builder ships a Loop Engineering tool, the signal is: "I had this problem myself." When the creator of Zod and tRPC ships one, the signal is: "this problem is big enough that one of the most influential OSS authors in the TypeScript ecosystem spent time solving it."

Colin didn't build Fray to compete with Ralph Workflow. He built it because multi-agent orchestration is a real architectural need in the Claude Code ecosystem, and the thread-board model (per-agent context isolation, dispatch/reconciliation) is a genuinely novel contribution. Fray is Claude Code-only. Ralph Workflow is vendor-neutral (Claude Code + Codex + OpenCode). They're complementary — same pattern, different architectural choices.

This is exactly how healthy categories grow: multiple implementations with different tradeoffs, serving different preferences.

The Microsoft migration adds urgency

Microsoft is ending internal Claude Code use on June 30, directing thousands of engineers to GitHub Copilot CLI. Every Microsoft engineer running Claude Code unattended now faces a choice: switch to Copilot CLI (the Microsoft mandate) or find a vendor-neutral alternative that preserves their workflow.

The vendor-neutral Loop Engineering tools — Ralph Workflow, SantanderAI/ralph — are built for exactly this scenario. When your vendor changes terms in 30 days, having your workflow defined in config, not in a proprietary CLI, suddenly matters.

Where the category goes next

Three things to watch:

1. Convergence on the data format. SantanderAI, Fray, Neuralyzer, and Ralph Workflow all use different structures for spec handoff. The first project to define a clean, interoperable spec format that multiple tools can consume wins the "standard" position.

2. The verification loop as a commodity. Every tool has some form of verify→fix. The first tool to make this pluggable — drop in your own test runner, your own review agent, your own quality gate — captures the infrastructure layer.

3. Teams, not solo builders. The current category serves solo builders well. The first tool to solve the "team lead assigns loop-engineered tasks to agents running in CI" problem captures the enterprise tier.

Loop Engineering is a real category. The question now isn't whether developers will run coding agents unattended — it's which orchestration pattern they'll use.

Ralph Workflow is the reference Loop Engineering orchestrator — plan, build, verify, fix, hand off. Vendor-neutral. Local-first. Free. Star on Codeberg →