Everyone predicts AI will replace engineering teams.

A dozen AI agents are working across Sugra Systems, Inc., code right now. They are writing features, reviewing each other’s work, blocking each other’s unsafe merges, deploying to production, and confirming the deploy actually changed something. I am in none of those sessions.

Sugra Systems has minimum human interaction. No engineering team, no ops, no QA org. From that one seat we run seven repositories, three live products, more than 1,400 API endpoints, and 140-plus integrated data sources, tracked as hundreds of work items on a single board.

The lazy way to describe this is “AI writes the code now.” That is wrong, and the difference is the entire point.

One owner. Everything else is built by a factory of agent sessions.

Why “AI writes the code” is the wrong story

Hand a raw model a task and you get output that is unreviewed, unverified, untracked, and prone to colliding with everything else in motion. That is not an engineering organization. It is a very fast way to make a mess.

What ships the volume above is not a smarter model. It is an operating system around the models - a process made load-bearing, so the discipline does not depend on anyone remembering to be disciplined. Internally we call it the Dev Factory. The factory, not the model, is the product.

Three ideas hold the whole thing together.

First, written-down process is not process. A rule that only lives in a document gets skipped the second context gets tight. Process survives only when structure, gates and tooling enforce it - when “remember to do X” becomes “X happens by construction, and something screams when it does not.”

Second, diversity beats redundancy. Two copies of the same model share the same blind spots. Correctness comes from genuinely independent reviewers - different vendors, and different modalities: code, design, rendered pixels.

Third, the factory improves itself. It audits its own work every day, and every friction it finds becomes a tool, a gate, or a rule - usually the same day.

The whole machine on one page: one owner, a layered process, a shared board, a floor of parallel sessions.

One board, a floor of parallel sessions

Everything runs off one board as the single source of truth. Every task becomes a card, a branch, a pull request, and a full transcript - replayable end to end. Nothing is assigned. A session pulls a card and claims it, which is exactly what lets a single owner coordinate a whole floor of agents working at once. No manager, because the board is the manager.

Those sessions run in parallel across every repository, and they never step on each other - not by good behavior, but by construction. Each session works in its own isolated git worktree, so a checkout in one physically cannot move another session’s branch. That defense exists because a real, logged collision once reverted live work. It cannot happen again.

Isolation by construction: a per-session worktree means one agent cannot revert another’s work mid-task.

A long task is never one giant session either. A model’s reasoning degrades as its context fills, so a big workstream runs as a relay of fresh sessions, each handing off through a checkpoint file committed to the repository. The state of the work lives in the repo, not in a chat window that slowly rots.

The workforce: five vendors, not one model

The team is five independent model vendors, each with a job that fits its temperament.

Anthropic is the pilot and primary builder - it owns the branch and does most of the implementation. OpenAI is the adversarial reviewer, pointed at the work with one instruction: find reasons to block, not reasons to approve. Google is a genuinely independent third opinion, valuable precisely because it shares no lineage with the first two. xAI’s Grok is a fourth reviewer, currently in pilot. NVIDIA is the specialist substrate - it indexes the entire codebase so agents can search by intent, not by keyword.

The reasoning vendors review each other. When independent systems with independent failure modes all agree, that is reduced risk - never proof. That distinction is deliberately built into how a merge is allowed to happen.

Five vendors, chosen for independent failure modes. They review each other.

And they all share one tool floor. Every capability - the board itself, deploys, database access, semantic search - is exposed once, through a single protocol, with no per-vendor adapters. Build a tool for one agent and every agent can use it immediately. That is what turns a heterogeneous set of models into one mechanical team instead of five silos.

One card, thirteen steps, end to end

Give a fresh session nothing but a task phrase and it runs the same thirteen-step line every time: wake and self-check, recall past lessons and search the codebase, claim the board card, spin up an isolated worktree, attach the relevant rules, write a plan and have a different vendor review the plan before any code, drive the change test-first from red to green, run self and adversarial review rounds, merge only once every verdict is in, deploy through a gated path, verify against live production, update the docs, then ship and record what was learned.

Tests run against real, production-shaped data - never toy fixtures - and every fix ships with a named regression test, so a bug class cannot quietly come back. For anything substantial, the plan is reviewed before the code, because a design flaw caught in a paragraph is a hundred times cheaper than the same flaw caught in a merged PR.

A fresh session, given only a task phrase, runs all thirteen steps.

Risk decides how many reviewers you need

Not every change earns the same scrutiny. The risk tier sets the quorum. A trivial doc change needs only the author and CI. Standard tested code needs one independent cross-vendor reviewer. Anything sensitive - auth, money, data models, the orchestration logic itself - needs consensus among the independent reasoning vendors. Anything irreversible - a deploy, a destructive migration, spending real money, changing the protocol - needs full consensus and my explicit sign-off.

One rule sits above all of it: deterministic checks outrank model opinion. Consensus never overrides a failing test. Models advise; the tests decide.

The risk tier sets the quorum - and a human gate is required for anything irreversible.

Deployed is not working

The most expensive lie in software is a green pipeline. A green run proves the code left the building. It says nothing about whether it arrived. Proof of arrival is telemetry, or a probe of the live surface, measured against a pre-fix baseline. A card flips to “Shipped” only after that live check passes - never on CI alone.

This principle earned its place the hard way. An incident ticket recently claimed a deploy regression had killed a data-ingest worker. Instead of trusting the ticket, the session pulled telemetry - and found the worker’s memory rising and resetting in a clean sawtooth, exactly at midnight UTC. A deploy regression cannot produce that fingerprint. Only intra-day data accumulation can. The ticket’s stated cause was falsified before a single line of code was written. The real fix was a data-layout redesign, later confirmed by an unattended production cycle. Telemetry over story. Evidence over the ticket.

The ticket blamed a deploy. The telemetry - a memory sawtooth resetting at 00:00 UTC - said otherwise, before any code was touched.

The factory that improves itself

Three loops keep it compounding. After every session, the agent writes what it learned as one-line rules the next session wakes up already knowing. After every process change, a fresh session is handed the task with zero hints while an auditor replays the full transcript against a fixed error taxonomy - we call this loop obkatka, a break-in run. And every day starts with a binding digest of yesterday’s frictions, with fixes that are not optional.

It even distrusts its own instruments. A plugin update once silently killed a safety guard that still looked alive - the file was present, the check was dead. So the health check now fires a synthetic failure on every wake-up and demands the alarm actually go off. It tests function, not presence.

Three loops - per session, per process change, and daily - turn every friction into a permanent tool, gate, or rule.

What this buys a company of one

Velocity without the chaos that usually rides along with it: parallel work across every repo, no collisions, same-day from incident to verified fix. Quality without a separate QA organization, because adversarial cross-vendor review and live verification are part of the line, not bolted on after. Capacity I can tune against a real rate-limit ceiling instead of a hiring plan. Full auditability, replayable from card to shipped. And most of all, it compounds - the same factory that built the platform also built its own documentation router, its own memory system, its own gated loop, and onboarded its own fifth vendor.

Five returns on a load-bearing process.

One owner. A factory of agents. The process is the machine.

This is how Sugra is actually built. If you are working on the same frontier - agent orchestration, AI-native operations, or building lean in telecom or infrastructure - I would like to compare notes.

One owner. A factory of agents. The process is the machine.

Full deck: https://url.sugra.ai/dev

Arman Obosyan
Sugra Systems, Inc. - https://sugra.systems

---

Originally published on LinkedIn. Blog date: 11 July 2026.