Engineers at Kilo Code Say They Now Write Code Just 1% of the Time. AI Agents Do the Rest.

Software engineers at Kilo Code are barely writing code anymore. Co-founder Emilie Schario said engineers there read or write code themselves only about 1% of the time, with AI agents handling the rest, according to remarks made at VB Transform 2026, an industry conference covered by VentureBeat.

"Unless something's really broken or debugging, 99% of the time engineers are not reading or writing code anymore," Schario said.

The claim is coming from the people selling the tools, not an independent auditor. Still, similar accounts came from other companies at the same event, suggesting this isn't just one founder's marketing pitch.

Symbotic: Humans Still Own the Product Calls

Jared Go, a distinguished engineer for AI and cloud at warehouse automation company Symbotic, described a system where AI does the heavy lifting on code quality but humans stay in charge of judgment calls agents can't make.

"These are my criteria," Go said, describing how he directs AI systems. "Let's look at it from the lens of security, elegance, clean, concise code, water tightness."

Go drew a distinction that matters: agents are good at building new systems from scratch, what engineers call "greenfield" work. They struggle more with "brownfield" work, meaning existing, tangled codebases with years of legacy decisions baked in.

"Greenfield is so easy for agents," Go said. "Brownfield we all know is where the actual challenge lies."

This is an important caveat missing from the more sweeping claims about AI replacing coding work. Building something new is a different problem than maintaining something old, and most real-world enterprise software is the latter.

Replit's Guardrails: Risk Scores, Not Blind Trust

Replit took a more cautious approach, according to Amol Jain, the company's head of product engineering. Every pull request submitted by an AI agent gets a risk score. Low-risk changes get self-merged by the agent that wrote them. Higher-risk changes go to a human reviewer who actually reads the code.

Jain described the philosophy as "human on the loop, not human in the loop." This means humans supervise the system rather than approve every single action inside it.

Replit's internal tooling runs what Jain called a "fleet of agents" operating in isolated cloud virtual machines, with access controls managed through token proxies for security. Engineers hand agents a task. The agents plan, build, and test the solution end to end.

Jain shared one specific example: a bug that human engineers couldn't reproduce or solve. An AI "manager" agent took over, spun up multiple sub-agents to diagnose the problem, then spun up more agents to build a fix. Six hours later, the system produced a pull request that resolved a bug that had stumped human engineers.

This is a single anecdote from a company with an obvious incentive to showcase its own AI-agent product in the best light. No independent verification of that bug fix's quality or long-term stability was presented.

The Multi-Model Push

Companies are also resisting single-vendor lock-in. Kilo Code's gateway supports more than 500 different AI models, according to Schario, who argued that the software layer running agentic engineering tasks should be decoupled from whichever underlying model powers it.

"Your software that you're using to do agentic engineering should be decoupled from the model that you're using to do it," Schario said.

If a company builds its entire engineering pipeline around one model from one vendor, it's exposed to price hikes, capability regressions, or an outage from a single point of failure. Multi-model support spreads that risk.

What's Unresolved

None of this answers the budget question raised in the same discussion: whether rising token bills for these AI agents represent real productivity gains or just a new category of IT spending that looks impressive on a slide but doesn't necessarily translate into better software, fewer bugs, or faster shipping over the long run.

There's also the accountability question. If an agent merges its own low-risk pull request and something breaks in production six weeks later, figuring out who's responsible and how to trace the decision back through however many sub-agents were involved is a genuinely unsolved problem. None of the three companies described a fully worked-out answer for that in these remarks.

Enterprises adopting these workflows are essentially running a live experiment on their own codebases. Whether that experiment produces safer, cheaper, faster software, or a mess that takes senior engineers years to untangle, is a question these companies haven't answered yet, and it may not be answerable for a while.