Does clean code matter when AI writes the code?

The code no longer needs to be maintained by a human. So what’s the point of clean code?

MARCO FUCCI DI NAPOLI
Co-founder rowads.studio

I came across this in a LinkedIn post by Marco Fucci di Napoli, founder of Rowads Studio — a five-person team that dropped code reviews entirely after adopting what they call extreme Claude Coding. Their north star metric: request to live time, the time between asking for a feature and seeing it in production. If it’s not live, there’s no value.

Two ideas in particular caught my attention.

• First: if code no longer needs to be maintained by a human, does clean code even matter?
• Second: request to live time isn’t a new concept — it’s the old principle that unshipped code has no value, updated to match the pace of AI agents.

The framing was compelling enough that I shared it with the team on Slack. The reaction was immediate: within an hour, three colleagues had jumped into the thread to push back, add nuance, and expand the question. What followed was a conversation interesting enough to outgrow its channel — and end up here.

The case for it: less friction, more product in production

The argument seemed solid. If AI writes the code, the bottleneck shifts away from implementation and lands squarely on product decision-making. In that context, a code review that takes two days to unblock has a real cost: request to live time spikes, and value arrives late.

Kevin Martínez added a nuance I agree with: the effort should shift toward what we never had time to do before, not toward shipping more features indefinitely. For years, things like load testing, accessibility (a11y), security audits, and Core Web Vitals sat in the backlog with the excuse of “we don’t have the bandwidth.” With tools like Claude generating implementations in minutes, that excuse disappears.

Kevin summed it up with a set of questions every engineering team should be able to answer today:

• Do you have load tests on your critical APIs?
• Has accessibility been audited on the front end?
• Is there real observability in production — not just logs?
• Have you reviewed your Core Web Vitals from last quarter?

If the answer to any of these is “no, we never had time,” AI just removed that excuse. The question is no longer “can we do it?” but “do we know enough to ask for it properly and validate it?” That shift changes where an engineering team’s time should be invested. The value of the work doesn’t disappear — it moves.

What I’m not convinced by — and I think Fucci di Napoli’s post implicitly acknowledges this — is the idea that more features equals a better product. Agents can write code faster, but the quality of product decisions is still a human responsibility.

Clean code with AI agents: design pattern or unnecessary token burn?

At that point the conversation took a more technical — and uncomfortable — turn for those of us who have spent years treating hexagonal architecture as a quality standard.

Kevin put the hypothesis plainly: a codebase organised into twenty layers of abstraction costs the AI more than a simple, direct implementation. When an agent has to jump across interfaces, repositories, use cases, adapters, and DTOs just to understand what a feature does, token consumption multiplies. And with it, latency and cost.

To test it, Kevin had a concrete experiment in mind: the same change, applied to a typical hexagonal architecture versus a KISS (Keep It Simple, Stupid) or YAGNI (You Aren’t Gonna Need It) implementation. His prediction: token consumption would be at least 100% higher in the clean code approach.

What does remain relevant — perhaps more than ever — is readability for the agent. It’s not the same as readability for humans, but it’s not the opposite either. Code that clearly describes its intent is easier for AI to modify than code full of implicit abstractions.

If something is complicated for us, it’ll be complicated for the agent too.

KEVIN MARTÍNEZ
Software architect at Orbitant

Carlos Jiménez raised the other side: “Can you sleep at night knowing the AI has implemented an if-else hell?” It’s a fair question. Today, many of us still need to understand and audit what the agent produces. But Carlos went further: it’s possible that in the future, AI systems will invent their own abstraction language — and at that point, neither clean code nor best practices will mean what they mean to us today. Time will tell.

And there’s a risk Kevin named that’s worth keeping in mind: saying yes to everything because “Claude can do it in five minutes” leads straight to a Frankenstein product. Features piling up without coherence, without a reason behind them, without anyone asking whether users actually needed that. Shipping speed doesn’t replace product clarity. If you’re already using AI to write better tickets and define features with more precision, you’re already one step ahead.

Back to the monolith? Architecture, context, and AI agents

Probably the most counterintuitive part of the whole conversation — and the one that’s made me think the most: microservices might actually work against you when the developer is an AI agent.

Kevin said it without softening it: “We might even go back to monoliths, because with microservices everything is fragmented and it costs the AI more to build a complete picture of the system.” Carlos, who doesn’t concede easily in technical debates, backed him immediately: with so many microservices, giving an AI the full context of a platform is genuinely hard.

The practical implication is that monorepos — and, to some extent, modular monoliths — make it easier for an agent to operate with more context in fewer steps. This isn’t nostalgia for ten-year-old architecture. The architecture we optimised for distributed human teams may not be optimal for teams working with AI agents. Kevin accepted it with eloquent resignation: as much as it pains him, the monorepo finally makes sense.

What becomes indispensable in distributed systems with AI in the development loop is contract testing. If services are going to be modified by agents semi-autonomously, contracts between them are the only reliable safety net. Without them, an AI-generated refactor can break integrations without anyone noticing until it hits production. In distributed architectures, contract testing stops being a best practice and becomes a hard requirement.

An emerging workflow that Kevin is exploring is TWD (Test-While-Developing): instead of writing tests after development, they’re used as a communication mechanism with the agent during the process itself. The data, when comparing testing tools, is striking:

1. TWD-relay: ~200–400 tokens per execution (~30 lines, pass/fail + error only)
2. Cypress: ~2,000–5,000 tokens (logs, screenshots, stack traces)
3. Playwright: ~1,500–4,000 tokens (HTML report, traces, verbose logs)

The agent executes and validates in real time, with token consumption 5 to 10 times lower than traditional alternatives. An architectural decision no one would have prioritised before becomes, with AI in the loop, a factor with a direct impact on cost and latency.

And there’s one more lesson in all of this, which Kevin summed up with the kind of clarity he has for obvious things nobody says out loud: what’s hard for humans is also hard for AI. Complexity doesn’t disappear. It shifts.

The happy path isn’t enough

There’s one final piece of this debate that David Rueda brought into the conversation — and it deserves its own space, because it’s the piece most easily buried under the wave of technological enthusiasm.

On paper, you can implement any feature perfectly with AI. The problem, as David pointed out, is that we work with real users — and real users are unpredictable. They don’t follow the happy path. They click a button forty times because they’re frustrated. They enter data in unexpected formats. They use the tool in ways no one anticipated when writing the prompt. For the happy path, AI is great. Everything else is still human territory.

It’s a question worth not glossing over. Edge cases are still the engineering team’s responsibility — not because AI can’t detect them, but because identifying them requires a mental model of the user that still doesn’t delegate well to an agent. Knowing what can go wrong is domain knowledge, and that knowledge still lives in people.

What about users who click a button 40 times because they’re frustrated or don’t know how to use the tool?

DAVID RUEDA
Software engineer at Orbitant

This has a concrete implication: the time we save on implementation should be reinvested in defining edge cases before asking the agent to handle them, not after. An agent that receives a clear prompt with explicit error cases produces far more robust code than one that you simply tell to “implement this feature.” The quality of the output still depends on the quality of the human input.

There’s also a product dimension that speed can obscure: features that ship fast also accumulate fast. Without a product review process — not just a code review — a team can reach production with ten features in two weeks and discover that half of them don’t solve the user’s actual problem. Observability and real behaviour analytics become valuable here in a way that previously seemed optional.

None of this invalidates the speed AI brings. It means that speed has to be aimed well. And aiming well still requires engineering judgement.

Coming back to the opening question: why does clean code matter if AI is writing it? The answer is more nuanced than it first appears. Practices change in form, not in purpose. What used to help another human understand and modify your code now needs to help an agent operate in it efficiently. The goal is the same. The audience isn’t quite.

What does seem to genuinely change is where the value of engineering work sits — though in truth, that value never lived in writing code. It lived in solving a business problem with a clear product vision backed by a concrete definition of ROI. What changes now is that engineers no longer have any excuse not to understand the business they’re trying to solve for.