Case Study: GRiDD Technologies

Executive summary

GRiDD Technologies builds GNet, a B2B connectivity platform that links travel, entertainment, service, and fleet businesses with more than 5,200 ground transportation companies worldwide through a unified API. In June 2026 we adopted Atomic, a verifiable coding agent runtime, for day-to-day engineering work.

Our life before Atomic. Single-agent sessions in standard coding agents (Claude and Codex) wrote code fast, but the evaluation burden — is this right, complete, safe to ship? — stayed on us, and multi-repo tickets kept falling through.

Our life after Atomic. We used Atomic to build jira-ship, a workflow that takes a Jira ticket to merged, documented PRs. Research, planning, implementation, and verification are enforced by the runtime, not left to a model's discretion — and one $4.85 run caught a change that would have silently deactivated locations for paying customers.

The delta. Verification moved off our plates and into the runs. The tickets that used to stall became the ones we ship in an evening. Atomic replaced other coding agents in almost all work, with other agents only being reserved for small fixes or local UI polish.

We dive deeper into these topics below.

The numbers, up front

Our life before Atomic

Before June 2026, our AI coding looked like most teams': long single-agent sessions in coding agents. They wrote code fast but failed in ways that were hard to see until later — missed requirements, missed paths through the codebase, work left half done.

The bottleneck was never generation. It was evaluation: knowing whether a change was right, complete, and safe to ship. That burden fell entirely on us. We ran the builds, typechecks, and tests, clicked through the app, pasted errors back into the session, and repeated until it held.

What we wanted was a loop that takes a Jira ticket to production including security, accessibility, and comprehensive testing. Standard coding agents kept falling short of that on multi-repo tickets. We had chained agents into pipelines before, and any team can as orchestration was never the problem. What we could not build ourselves was the layer underneath that proves completion.

Our life after Atomic

jira-ship: the workflow we built with Atomic

The first thing we did with Atomic was use Atomic to build our own workflow. Atomic exposes its own documentation and workflow APIs to the agent: we described the loop we wanted in natural language, Atomic wrote the workflow definition in TypeScript, and we refined it after each failure. Each revision took minutes, instead of weeks of harness engineering for stage orchestration, context isolation, and retries. The result is jira-ship, a versioned definition that lives in our repo and turns a Jira ticket into merged, documented PRs with verification builtin:

fetch ticket (Jira via MCP)

  → scope-kb ∥ scope-code        (two isolated research agents: our knowledge base, our codebase)

  → reconcile-scope

  → plan (structured questions → our approval)

  → implement (per-repo git worktrees, fresh contexts)

  → verify / fix (build, types, tests, browser — up to 3 cycles)

  → code PR(s) + knowledge-base PR (created automatically, with critical findings written back to the knowledge base)

Two agents research every ticket in parallel, isolated so their outputs cannot bias each other. One reads only our knowledge base, the other only the code. Each returns the repos the ticket touches, with evidence. The codebase alone is too big to search exhaustively. The knowledge base adds the grounding context.

What makes this different from dynamic workflows or /goal? Those decompose tasks into stages and subagents too, but the decomposition is generated by the model per run. Whether a planning pass happens, how deep it goes, and what it must produce is the model's call each time. In Atomic, the workflow is a versioned definition: planning is a required stage with its own context and research budget, and the runtime verifies that every stage returns its declared outputs against a schema before the next stage starts. A stage cannot report success without producing its evidence. The plan we approve becomes the run's contract.

The incident jira-ship prevented

Our subscription tiers cap how many locations a business can register. A one-line ticket came in from an email: lower the caps to 1 for Basic, 2 for Professional, 6 for Premium. The change was three constants in a model file, which is the kind of change any coding agent makes in minutes.

We ran it through jira-ship. The planning stage traced where those constants flow and came back with this:

"Key behavioral consequence: the worker auto-deactivates CMS locations above the cap, so existing Premium accounts holding 7–10 locations will have the excess deactivated after the 10→6 reduction."

A background job enforces these constants. Merged as written, the change would have silently deactivated locations for every Premium customer above the new cap. We had no automated tests covering subscription caps, so CI would not have caught it. We closed both enforcement PRs unmerged and instead shipped a two-line pricing FAQ fix plus a knowledge-base update documenting the real caps. Total cost: $4.85 and about twenty minutes.

This is the versioned definition paying off. Planning was not optional that day because it is never optional. The runtime requires the stage and its evidence on every run.

Verification

Verification runs inside our workflow. The stage derives its checks from the ticket before seeing the implementation's claims. It runs the project's real build, typecheck, lint, and test commands — and exercises the app in a browser where that applies — as tracked, checkpointed tool calls. Real command output, not model self-report, drives up to three fix cycles, and code decides from the structured verifier output whether a run ships, loops into repair, or stops for a human. From jira-ship's verify stage:

for (const [i, argv] of checks.entries()) {
  await ctx.tool(`check-${i + 1}`, { argv }, async () => runCommand(argv, cwd));
}

How stage schemas, durable tool calls, and repair loops work is covered in the Atomic workflow docs.

Across our twelve runs, sessions recorded roughly 375 verification commands (123 on the biggest feature alone). What remained for us was reviewing the evidence and deciding to ship. For auth, billing, and critical changes we still read the code. What to build, how to build it, and whether it ships stays with the engineer, by design.

The delta

The one unmerged PR is one of the two we closed during the incident run above. Both were closed deliberately after the planning stage showed the change was out of scope. That close is the prevented incident.

The clearest single example is the largest ticket: a 48-file, +3,663-line document-request feature that researched, planned, approved, built, verified, and merged in one evening. The run spawned 53 research subagents and read over a thousand files so the implementation stage worked in a small, clean context. Before Atomic, we could not produce a change this size that quickly and trust it.

A new division of labor. Atomic now handles the large cross-repo, multi-requirement tickets. Basic coding agents are kept for small, bounded fixes at times. We plan on exploring integrating open models into our development workflows, particularly to address the security considerations now that we have this affordance via Atomic.

Trust: from babysitting to autopilot

By mid-July, Atomic had replaced standard coding agents entirely. Atomic is now the default path for every ticket with real scope. We use other coding agents only for small, well-bounded fixes and local UI polish. Our rule of thumb:

Reach for the runtime when a change has cross-repo scope, hidden coupling, higher production blast radius, or docs that must stay current.

The hardest part of adoption was behavioral. Like most engineers, we did not trust agents to run unsupervised for hours or overnight. Three things in Atomic's runtime changed that:

1. Judgment moved upstream. The plan gate captures our intent in writing before any code exists.
2. The runtime verifies completion. Each stage's outputs are checked, catching the skipped steps and unverified success claims we used to catch by babysitting.
3. The workflow comes to us. Approval requests, problems with evidence, and finished results with the verification record attached.

When we want to look, we can attach to any running stage, watch, steer, or resume it. The trust came from being able to check anytime and finding the work checked out.

There is a learning curve, and it pays off. Early on, we had one run burn $174 and 26 hours and merge a no-op PR. Learning how verification works and how to use the runtime properly saved us that time many times over in the following weeks. The same property that let Atomic build jira-ship kept paying off here: we could describe a workflow problem in plain language and have it revise its own definition. The runtime improves itself in the same tool that runs it.

Owning our intelligence

Over these weeks Atomic's runtime has orchestrated Opus 4.8, then Fable 5, and each model upgrade made the same workflows better. Models are replaceable; the workflows, the knowledge base, and the accumulated judgment are the asset and they belong to our team. They are files in our repos, they work across providers, and we avoid vendor lock-in. That is exactly what an organization should own, and Atomic lets us own it.

Try it on your own codebase. Every mechanism described here is visible on your first real ticket.