Agentic coding has sped up shipping exponentially, but with this added speed comes the added pressure to hit shorter deadlines, and that can mean not fully understanding what’s in your code base.
As one engineer described in r/ExperiencedDevs this week, the agentic code that gets spit out is often too complex, with the models defending that complexity even when engineers push back.
Regardless of whether agentic code can pass unit and end-to-end tests, engineers are still hesitant about shipping code they may not fully understand.
So I asked our engineering leaders: How do we deal with the complexity coding agents hand us?
The Cardinal Sin Is Vibe-Coding Whole Features in One Prompt
Nikhil Gopinath Kurup (SVP of Engineering, ML)
Working under the corporate mandate that "nobody is allowed to stop using AI" feels a lot like applying the Serenity Prayer to software engineering. You have to accept the tool policy you cannot change, find the courage to adapt your workflow to survive it, and develop the wisdom to know the difference.
A new generation of engineering judgment has to emerge here. Sometimes, it is okay to let the model "vibe code" a low-risk piece of logic. Other times, you have to scrutinize every single line. The key here is not whether you use the AI, but rather knowing when to trust it and when to put your foot down.
The cardinal sin right now is trying to vibe-code whole features in one monolithic prompt. That is how you end up with incomprehensible, over-built codebases and massive PRs nobody can actually review. Instead, the strategy has to be ruthless decomposition before you touch the coding model. Break the work down into bite-sized pieces, applying the classic Unix philosophy of making each part do one thing and do it well.
"Working under the corporate mandate that 'nobody is allowed to stop using AI' feels a lot like applying the Serenity Prayer to software engineering."
Use AI models for planning if you should. If you iterate at a high level first and structure small, well-defined tickets, you shift the hard thinking to the design phase. By the time you hand a small ticket to the AI, it can generate, unit-test, and fulfill that isolated requirement without leaving you trying to reverse-engineer a giant black box after the fact.
Context dictates how much freedom you give the model, too. For bug fixes, I lean on AI primarily to research and brainstorm potential root causes rather than blindly applying patches. For internal tools or non-prod tickets, where velocity trumps architectural purity, I am totally fine letting the system generate a more complex implementation, provided it actually works the way we need it to.
But even there, wisdom is key: review the approach before it gets built, not after the mess is already checked in. Working within rigid AI constraints doesn't mean abandoning standards, it just means changing how we enforce them.
Three Ways to Review AI Code When You Can't Read It All
Hari Chandrasekhar (SVP of Engineering, Core)
When we talk about managing the complexity agents are currently handing engineers, I think the example of hand reviewing a 3,000-line PR is a realistic version of the problem. Nobody actually reviews that much code, and pretending otherwise is how bad code gets passed instead of rejected.
Generation now runs at machine speed, but the guardrail is still a human reading code. So what can we do about that?
- Scope the agent so the diff stays reviewable.
Most giant PRs are a scoping failure during design and development, not a review failure downstream. A broad task handed to the agent produces a broad diff. Constraining it to a service boundary or a single behavioral change is the cheapest lever available, and it takes discipline in the prompt.
- Use AI as the first pass reviewer with the reviewer context made explicit.
This is the part people skip. The reviewing agent needs the context a good human reviewer carries in their head and never writes down:
- Architecture invariants,
- Conversations between engineers
- The failure modes we’ve already been burned by
- What safe means for a component that mutates live customer workloads
Given that, AI is a genuinely useful adversarial reader. Given nothing, it tells you the code looks fine.
- Keep the human on blast radius, not on line count.
It isn’t practical to read everything generated at machine speed. Focus on the areas where being wrong is expensive. A regression in a customer’s production environment isn’t recoverable with a fast follow-up.
A general take on the thread: the model is closer to a fast, confident senior engineer than to an oracle. It produces work at that level and it’s wrong at that level too, at machine speed. The failure here goes beyond complexity and highlights that there’s often no mechanism to overrule an agent when it pushes back.
"Unbound agent usage that’s producing this complex code is part of the reason why teams are spending so much more time on debugging. Ironically, those agents are the best triage instrument a team has."
The same asymmetry shows up in bug hunting too, as one Redditor called out spending 60% of dev time on bugs. Unbound agent usage that’s producing this complex code is part of the reason why teams are spending so much more time on debugging. Ironically, those agents are the best triage instrument a team has.
Ideally, you should bound where agents write unsupervised and widen where they analyze, not to pull back across the board.
Stop Debating the Models and Control the Context
Aby Jacob (VP of Engineering)
What changed for me was realizing I shouldn't argue with the models when they give me overcomplicated code. When an LLM pushes back against cutting down and simplifying, it isn't defending a position it actually holds, it's defending whatever’s in its own context. So I quit debating the code with it and started changing what I hand it.
I don't ask for a refactor anymore; instead I ask for a rewrite against the contract. "Simplify this" is a reduction task and LLMs are bad at reduction. But if I say “Here's the interface and the three callers, write it fresh and don't read the old version,” that's generation, and generation is what LLMs are actually good at.
I end up with a short implementation instead of an argument about a long one.
I also budget the LLM’s output before it starts. This means no new files, no new abstractions, no new dependencies, and a rough ceiling on lines. If I leave that out, I get a strategy pattern plus a config layer for something that has exactly one config.
“The idea is to stop spending effort cleaning up code because someday the models will manage that themselves. But we don’t know when that day will be, and until then, going back over generated code and cutting it down is just part of the job.”
We need to not over-engineer at the get go as well. When I want stuff removed, I make the agent name the caller. Asking "Is this necessary?" gets a “Yes” every time, but asking it to reason out why something is necessary tells you why something was engineered in a certain way.
And if you cross question against the ROI of having each layer, abstraction, or interface the agent added, more often than not, the LLM will agree what a dumb idea it was to write the code it already spit out.
On the question of whether clean code, DRY, and KISS don’t matter anymore: I just can't get there, and I think the resolution really is we won’t know for a while. The idea is to stop spending effort cleaning up code because someday the models will manage that themselves. But we don’t know when that day will be, and until that day comes, going back over generated code and cutting it down is just part of the job. Maintainability is the obvious reason for this; since a human is still the one on call at 3am, the code should be human-readable.
The one issue I don't see talked about much is token cost. A bloated codebase is a line item now and it's growing into a nastier beast with every next PR , more context on every read, and more tokens burned just getting the model oriented before it does anything useful. It's a quality problem too, since performance falls off in long, noisy context, so whatever mess you let through today makes tomorrow's agent worse at cleaning it up.
When you’re paying for token usage across every line of code, how do you manage the escalating costs? Sedai shows you what each call costs and routes it to the most efficient model. See how.