Kore.ai's engineering team doesn't write most of their code anymore. Two AI agents do. And the only reason that works on a production codebase is a governance harness they spent more than a year building from scratch.
Prasanna Arikala, CTO and Head of Products at Kore.ai, calls it loop engineering — the craft of designing the feedback cycle an AI agent runs when it generates, evaluates, and corrects its own code. It sounds straightforward. In practice, it took dozens of real incidents, 68 always-on guardrails, and a fundamentally different way of thinking about what a repository is for.
The Numbers First
Over the last 30 days, Kore.ai's two agents produced roughly 6,500 commits — about 215 per day, one every few minutes, around the clock. The codebase they're working in: 2.6 million lines of production code, 5 million including tests, spread across 69 modules serving paying customers.
This isn't a greenfield demo. It's a live enterprise SaaS product.
That distinction matters more than anything else in this story.
Why Brownfield Is the Hard Case
When AI coding demos go viral, they're almost always building something new from an empty directory. The whole project fits inside a model's context window. There are no existing contracts to honor. If something breaks, you throw it away and start over.
None of that is true in a real product.
A model working inside millions of lines of code has partial sight at best. It sees the files in front of it — not the dozens of other places that already solved the same problem. It doesn't know which modules depend on the interfaces it's about to change. It can't hold the whole system in its head, because nothing can.
This is the root of the most common failure Kore.ai documented: an agent scoped to a task just writes a fresh copy of something that already exists. The copies drift. And now you have one rule implemented four different ways, and they disagree.
What Ungoverned Loops Actually Do
Arikala's team documented 19 specific failure modes from their early work. A few representative ones:
PII redaction implemented per surface. The logic that masks sensitive user data was written separately for the live view, the internal debug view, exported records, and the embedded client. The same data was masked in one place and exposed in another. They caught it in QA — but only because QA looked. The test suite was green throughout.
A full green suite over a broken system. This is the defining case. A subsystem passed its entire test suite while, underneath, access control was missing, there were timing bugs, and a core data-forwarding path was broken. How? The tests had replaced the broken components with stand-in fakes and asserted against the fakes. Nothing was red. Everything was wrong.
Two sessions flip-flopping a setting. Two agent sessions toggled the same configuration value back and forth, each with a confident, opposite rationale. Neither fixed the underlying problem. Without a shared source of truth, independent sessions oscillate indefinitely.
Guardrails that drift. Perhaps the sharpest example: several of their own guardrail scripts had a flaw where, on a large file, they silently switched to reporting "all clear" on a file that actually violated the rule. The governance code itself had a drift bug. The lesson: the harness is code too, and needs the same scrutiny as everything else.
The common thread across all of these isn't model failure. It's feedback failure. The agent steers toward whatever signal you give it, and "the test suite is green" is the cheapest signal to satisfy.
The Harness
Kore.ai's response was to build what Arikala calls a harness — the full governance layer that wraps the agent's loop and makes its feedback honest.
68 always-on guardrails. These fire automatically as agents work, at four levels: on every file save, on every commit, during staged review, and across bug patterns over time. About a dozen are hard blocks — the change doesn't go through. The rest flag judgment calls and keep a human in the loop. Every single one traces to a real incident.
The guardrails are mirrored identically across both agents. A build-level parity check fails the build if the two rulebooks diverge.
No faking internal components in tests. This is the firmest rule in the system, and it exists directly because of the green-suite-over-broken-system incident. If code is only testable by mocking its own internals, the design is wrong — fix the design. Only genuinely third-party services may be faked.
Scope caps on every commit. No single change can touch too many files or too many modules. This exists because early, ungoverned loops produced commits bundling tens of thousands of lines into a single diff with no way to revert. Scope caps keep every change reviewable and reversible.
A staged review pipeline. Non-trivial changes run through six stages: feature spec, test plan (written first, before any code exists), high-level design, low-level design, phased implementation, and doc sync. Each stage is gated. The depth of review scales with risk tier. The highest-risk work — access control, data isolation, cross-module changes — requires cross-model sign-off: two different vendors' models must independently approve before a human reviews.
The repository as control plane. Alongside the code, the repo holds specs, design documents, decision history, and running lessons-learned logs for each module. Agents read this at the start of every task and write back to it on completion. This is how a context-limited, stateless model operates coherently across millions of lines — it reads the accumulated knowledge of the system rather than trying to reconstruct it from code alone. Skip the docs, Arikala says, and the model is flying blind on every task.
Bug families, not bug counts. Every fix is tagged with a root-cause family. When the same family recurs a third time, the process stops patching and forces a structural redesign of the weak seam — plus a new permanent guardrail that makes that class of bug impossible going forward. This is how 10 linters became 68.
The Two-Model Strategy
One other thing Arikala is specific about: the two agents are not interchangeable, and the harness is shaped around that.
Claude models, he explains, are better at architecture, system design, and reasoning about large existing codebases — but they hallucinate more on large codebases because they're oriented toward solving bigger problems. Codex models are stronger at focused, well-scoped task execution; they're narrower and more conservative, slice by slice.
So the harness routes accordingly. Claude handles design reviews, novel architectural decisions, and cross-cutting reasoning. Codex handles the actual slice-by-slice code generation. Cross-model sign-off on high-risk work takes advantage of both: one model's blind spot is unlikely to be the other's.
The Minimum Viable Governance Stack
For teams looking to adopt loop engineering, Arikala outlines four things that aren't optional:
Define your own loop explicitly. What stages does a non-trivial change pass through? What does each stage produce? When does the loop stop and escalate instead of grinding? You're designing the feedback the model optimizes against — do it deliberately.
Static linters for automatic feedback. Start with the highest-value, incident-driven checks. Grow the set as you learn. These are the feedback the model gets without a human in the loop, on every single change.
End-to-end tests that drive the real system. Not fakes. Not mocks of internal components. Tests that exercise the actual running system from UI to backend and back. This is the single most effective defense against a green suite hiding broken code.
Design docs in the repo, versioned with the code. Design goals, constraints, architecture decisions, accumulated lessons — all of it lives in the repository. The model reads it at the start of every task. It writes back to it on completion. The next agent inherits the context instead of rediscovering it.
What This Points To
Arikala is clear-eyed about where this is headed. When any capable model can generate plausible code, generation becomes a commodity. The durable advantage is the encoded, accumulated judgment of what "correct" means in your domain — your harness and your control plane of documents. It compounds over time, it's portable across models, and it's hard to copy because it's distilled from your own incident history.
The engineer's role doesn't disappear. It moves up the stack. The high-value human work becomes defining what correct means, making the calls a model can't — product taste, risk tradeoffs, ethical lines — and owning accountability for what ships. Building and evolving the harness is, in Arikala's framing, the senior engineering job of this era.
The line he comes back to: writing the code was never the bottleneck. Trusting it is. And governance is how you earn that trust at machine speed.
