DEV Community: Sedai.io

Would You Ship a Codebase Rewritten Entirely by Agents?

Sedai.io — Wed, 15 Jul 2026 17:41:46 +0000

The team behind Bun ported 535,000 lines of Zig to Rust in 11 days, with one engineer, 64 Claude agents running in parallel, roughly $165,000 in API costs, and compiler errors treated as a distributed work queue.

The port is already running in Claude Code and Prisma's public beta. Zig's creator called it "unreviewed slop."

So we asked our engineering leaders: would you ship a codebase rewritten entirely by agents?

Shipping Codebases with Agents is the New Turing Test

Nikhil Gopinath Kurup (SVP of Engineering, ML)

Yes, I'd ship this one. And notice what the Bun team actually said: they gave the credit to the compiler, not the model. "Compiler errors as a work queue" is basically the whole story. They didn't trust the agents at all. They built a setup where every one of the ~1,300 lines a minute got checked mechanically, and the borrow checker doesn't care how good your prose is.

The way I think about it, this is really a Turing test. If you have a perfectly specified system, and a compiler is about as perfect as it gets, then the input is spec'd, the output can be verified from every angle, every claim in the spec has a test case, and there's already an implementation to diff against. Once you have all that, it stops mattering what's inside the box writing the code. Could be an army of interns, could be a few 100x engineers, could be 64 Claudes running for 11 days. If it swims like a duck and quacks like a duck, it's a duck. The author basically disappears into the verification.

You can see the edges of that in the fine print, though. 19 known regressions still made it into the final compiler and look at what they were: side effects inside a debug_assert that disappeared in release builds, bytemuck panicking where Zig used to silently truncate, comptime format-string behavior that got lost in translation.

"Ship an agent-written rewrite as far as you can verify it."
— Nikhil Gopinath Kurup, SVP of Engineering, ML

None of those are memory bugs. The duck test only checks for the stuff that's actually in your spec. The compiler caught its whole class and was blind to the rest. That's why they also re-ran the exact same TypeScript test suite and put two adversarial Claudes on it: one trying to ship and one trying to break. Even with all that, some behavior still slipped through.

We did a smaller version of this ourselves recently. We had SDKs for our APIs in a few languages, a customer wanted a new one, and that is an almost perfect agent task. Translate from an existing SDK, re-run the same 100%-coverage test suites the other languages already had. Spec, reference, full coverage, clean duck test. The agent handled it well.

But I wouldn't reach for this everywhere. That SDK job worked because the spec, the reference, and the tests all existed first, and engineers built them. Everything before that point, speccing the system, designing it, deciding what's even worth building, reviewing whether it's right, is still on the engineers here, and I'm not looking to change that.

Agents have made those people a lot faster. They're not going to replace them. Ship an agent-written rewrite as far as you can verify it. When you're writing the code and the thing that checks the code at the same time, that's still a person's job.

Shipping Faster With AI Is in Tension With Guaranteeing Quality

Ethan Andyshak (SVP of Product)

“The agents never had to be trusted, only checked.” This is the most important detail for me. Using agents to write code is efficient, but we're not at the point yet where we can safely ship all agent code without reviewing it.

This is a challenge because reviewing code can be time-consuming: you have to read and understand what the agent did in order to figure out if it makes sense. Even when there's no AI involved, this process requires a non-trivial percentage of the time it takes to write the code.

“If you try to fix AI problems with more AI, you might just be making a xerox of a xerox”
— Ethan Andyshak, SVP of Product

If companies try to accelerate by using agents to write large code bases quicker than they can be reviewed by humans, humans are still a bottleneck in the workflow, and you can't achieve the full acceleration that you might want.

As a result, we see new AI-driven tools coming out to take some of the burden of reviewing the code as well. At the end of the day, if you try to fix AI problems with more AI, you might just be making a xerox of a xerox — you're still losing some quality unavoidably.

In the future, we hope that the original agents writing code will have closer competence to senior developers, and that the peer review agents have the same critical eye as those senior developers' colleagues. Until then, while we're in this awkward growing pains phase, the pressure to ship code faster with AI remains in tension with the pressure to use human code review to guarantee quality.

Quality Still Takes Nuance and Iteration, Even Shipping With AI

Hari Chandrasekhar (SVP of Engineering, Core)

The single biggest advantage I take from the Bun story is the validated tests. That is probably the main reason they could ship an agentic migration with confidence. The procedure they outline is a good illustration of the nuance, iteration, and meticulous thought that actually goes into building a product at the quality bar people expect.

Expectations of AI systems and agents have skyrocketed, but it is still not magic. These systems think and act based on historical evidence and traces drawn from human experience and ideas. A genuinely new product or feature gets built on top of those ideas through repeated thought and improvement. Most successful products come from that additional process, and specialized products bring in niche concepts that make them stand out. The article shows how agentic systems can expedite the work, but the specialization and meticulous treatment were orchestrated by a human with the agent’s help.

“Expectations of AI systems and agents have skyrocketed, but it is still not magic.”
— Hari Chandrasekhar, SVP of Engineering, Core

Building on Ethan’s “checked, not trusted” point: can we ship code that is entirely agent-built? Yes, if there is enough process and enough guardrails to guarantee the level of validation a product’s quality bar requires. Vibe coding is getting popular, and we have also heard reports of people taking backward steps. In areas with simple, known, already proven steps, vibe coding works, and more people without a technical background will be able to use it.

But products with niche and fresh ideas need newer thinking and rigor. Agents will make that possible far faster, but it involves a dimension of human intelligence, experience, and thought that is not yet encoded or contextualized for current AI. Over time there will be an iterative process where the systems eventually learn it.

To summarize: can we ship code with agents? Yes, we are heading there. But there is a part of human intelligence, iteration, and thinking that is still required to orchestrate and set up the systems for high standards.

Why the Bun Rewrite Actually Worked

Suresh Mathew (CEO & Founder)

Would I ship a codebase rewritten entirely by agents? Yes, but with a big caveat.

It comes down to first principles here: The fundamental issue is you’re relying on a probabilistic engine. An LLM gives you the most likely output, not a correct one. So trust is off the table from the start, meaning verification must become everything.

"Take away that harness and I wouldn't ship it."
— Suresh Mathew, CEO & Founder

And verification is actually harder here than a human port. Humans reviewing code as they translate it is free QA. A million agent-written lines that nobody read? That checking has to be built explicitly.

Bun had years of tests and a compiler enforcing exactly what they cared about. That’s why it worked. Take away that harness and I wouldn’t ship it.

Want to know how AI agent optimization works? Read our guide.

How Much Isolation Do AI Agents Actually Need?

Sedai.io — Wed, 08 Jul 2026 16:41:34 +0000

By Suresh Mathew, Sedai CEO

When a tenant-isolation check failed in Asana's MCP server, roughly 1,000 companies using Asana's AI integration could access each other's project data for five weeks straight.

Failures like that are why AWS, Microsoft, Google, and Anthropic recently rebuilt their agent runtimes the same way: every session gets its own isolated environment, and the session, not the request, is what the platform schedules, secures, and bills for.

But none of them agree on how strong that isolation should be, because stronger isolation costs speed and money.

So I asked our engineering leaders: how much isolation do AI agents actually need to keep data safe?

Picking One Isolation Level Is the Wrong Question

Benjamin Thomas (Co-Founder & CTO)

I don't think you can pick one isolation level globally. Isolation strength should follow the trust level of what's running in the session. If an agent is executing arbitrary model-generated code with network access and credentials in scope, I want VM-level isolation, Firecracker-style, and I'll take the cold start.

That cost is also more manageable than the framing suggests, since you can start with the lighter VM at session initiation and escalate to heavier isolation only when the workload calls for it. Which really means the problem isn't the sandbox but the routing layer.

"Isolation strength should follow the trust level of what's running in the session."
— Benjamin Thomas, Co-Founder & CTO

Something has to look at each incoming session and decide its trust tier, placement, and lifecycle continuously rather than as a one-time config. That kind of workload-aware decisioning is where I'd expect the real gains to show up, both on cost and on blast radius.

The other wrinkle is that not all sessions are individual. Once you have shared sessions within a team, or long-running ones that outlive a single user's involvement, the question shifts from “What can escape the sandbox?” to “Who owns the session right now?”

The Asana case is exactly that: isolation held but the identity binding didn't. For shared and long-lived sessions, the session must be a security principal in its own right, not just a compute unit with a timeout. And the routing layer needs to carry that identity context along with everything else.

Your Sandbox Wont Save Your Work

Aby Jacob (VP of Engineering)

The sandbox is a security boundary, not a durability boundary, and many agentic workloads will fail if/when developers conflate the two.

While the session is increasingly becoming the preferred unit of compute, it seems durability and recovery are intentionally outside of its scope. A sandbox was never meant to remember, just execute.

For example, when a microVM crashes halfway through an agent task, everything inside it disappears including working files, runtime environment, partially completed routines and cached data. The session ID may still exist, but it now points to an empty container.

"The sandbox is a security boundary, not a durability boundary."
— Aby Jacob, VP of Engineering

The platform won't recover any of this, so we should design as if a crash is guaranteed: persist state outside the sandbox after every turn, make the environment reproducible from code or scripts, and make every tool call idempotent so a retry doesn't cause unintended side effects.

Resilient agents should externalise their state, treat the sandbox as ephemeral, and design every transaction to tolerate retries and partial failures.

An additional benefit of this architecture is portability. Once state lives outside the sandbox, the execution environment becomes a replaceable commodity that can be rented from any compatible provider, significantly reducing vendor lock-in.

Session Isolation Costs Less Than You Think

Shankar Jothi (VP of Engineering, ML)

The isolation overhead people worry about is mostly a cold-start cost rather than a steady-state one (at least for compute-bound serving paths). You pay it when a session is first provisioned, and it fades once the environment is warm and requests route back to it.

So the real variable isn't isolation itself, but how often you're establishing sessions — something lifecycle settings like idle timeouts directly influence.

"The isolation overhead people worry about is mostly a cold-start cost rather than a steady-state one."
— Shankar Jothi, VP of Engineering, ML

It's also worth being honest that this isn't measured as cleanly as it could be. Startup latency often gets folded into a single end-to-end number alongside inference time. The more useful practice is to decompose the path into the platform-managed portion and the application-defined portion, tracking those separately. That lets you reason about regressions instead of guessing at them.

More broadly, this still feels like an early and evolving space. The primitives are converging, but the operational maturity around cost, portability, and observability is still being worked out. That's where I expect most of the interesting engineering to happen over the next year.

Tokenomics Guide

Sedai.io — Thu, 02 Jul 2026 16:14:28 +0000

We wrote a Guide to AI token consumption in 2026, including up-to-date pricing comparisons for the latest models. Read here: https://sedai.io/blog/what-is-ai-tokenomics

The end of tokenmaxxing

Sedai.io — Fri, 26 Jun 2026 16:42:45 +0000

The "tokenmaxxing" era is officially over, according to Sedai CEO Suresh Mathew. The new era of tokenomics has begun.

Read Suresh's article: https://sedai.io/blog/tokenmaxxing-ending-era-tokenomics-has-begun

Tokenmaxxing is the idea that more AI token consumption = more productivity. Earlier this year, companies like Meta, Amazon, and Microsoft set internal targets for token usage.

But while AI spending skyrocketed, the results didn't follow.

Suresh proposes a new way to measure the value of AI, for this new era of tokenomics. It's a fantastic article for Eng, FinOps, and Finance leaders.

Is the era of cheap AI over?

Sedai.io — Thu, 28 May 2026 18:39:11 +0000

For years, we haven't paid the real cost for AI models. But that's about to change.

Our team explains how eng leaders can control the rising costs, in this article: https://sedai.io/blog/is-the-era-of-cheap-ai-over

"Who Touched Prod?"

Sedai.io — Thu, 07 May 2026 15:43:59 +0000

This is what it feels like to cause a prod issue

Podcast Livestream w/ Ilan Rabinovitch, SVP Product at Datadog

Sedai.io — Wed, 12 Oct 2022 18:32:43 +0000

We're incredibly excited to launch our new podcast tomorrow Thursday, October 13 with our first episode featuring a very ✨ special guest ✨, Ilan Rabinovitch, SVP of Product at Datadog.

Sedai would like to extend a personal invitation to the community on dev.to to join this special livestream of Episode 1 as we discuss The Future of APM and Cloud Operations. In this episode, we'll explore the different application performance challenges companies face today with the rise of microservice architectures, containers and serverless computing. We'll discuss the strengths and limits of the observability paradigm, and how autonomous systems and AIOps have emerged to streamline and scale operations for complex modern applications.