We Made Our Agents Dumber and Output Quality Doubled
The smartest AI in your stack might be your biggest liability. When we first gave Tacavar's coding agents unrestricted context, every tool in the box, and the strongest models available, we expected output quality to climb. Instead, we watched our codebase fill with speculative abstractions, invented dependencies, and elegant solutions to problems nobody had. So we did the counterintuitive thing: we made our agents dumber. Here’s what happened.
The Inverted-U Curve of Agent Capability
Most teams assume that agent capability works like a monotonic curve: more intelligence, more context, more tools — better outcomes. Tacavar’s experiments point in a different direction. The relationship between agent capability and useful output is an inverted U. Performance improves as you add capability, but only up to a point. Then error rates climb through over-engineering, hallucinated complexity, and solution-space explosion. The agent starts exploring architectural options instead of fixing the bug.
Josh Fathi, who led the work, first noticed this during a routine review of Tacavar’s agent-generated pull requests. The code was technically impressive. It was also unshippable. The agents weren’t failing because they were too weak. They were failing because they were too capable for the scope of the task. That observation turned into a deliberate experiment: nerf the agents and measure what changes.
The same pattern appears when you test agent constraints in isolation. Give an agent free rein over a function and it will invent an abstraction layer. Give it only the function, its dependencies, and the expected behavior, and it solves the problem directly. The extra capability isn’t neutral — it actively pulls the agent toward larger, riskier solutions. This is the core of llm reliability: not just preventing hallucinations, but preventing complexity hallucinations.
How Over-Engineered Code Sneaks Past Review
The dangerous part is that over-engineered code doesn’t look bad. It looks smart. An agent that’s given a large context window will pull in unrelated patterns from other parts of the codebase. It will add a factory where a single function would do. It will create an abstraction layer that could "pay off later." The code passes review because it follows existing conventions and passes tests — but the cognitive load it places on future maintainers is far out of proportion to the problem it solves.
At Tacavar, the same pattern kept surfacing: agents were bypassing simple fixes in favor of "impressive" code. They were solving problems that had already been solved. And because the output was internally consistent, automated review wouldn’t catch it. Only a human who had been around the codebase for years would flag the wasted complexity. That’s not a scalable review system.
The root cause is solution-space explosion. Given enough context and capability, the agent generates a wider range of candidate solutions — and it optimizes for the one that seems most complete, not the one that is most maintainable. This is an llm reliability problem, not an intelligence problem. The model is doing exactly what it was trained to do: produce plausible, detailed code. It just isn’t aligned with the goal of minimal, correct changes.
What I Nerfed: Context, Tools, and Model Tier
The fix was to treat capability as a dial, not a default. We made three specific changes to Tacavar’s agent construction.
First, we cut context windows down to the minimum viable scope. Instead of feeding the agent the entire repository or even an entire file, we give it the relevant function, its direct dependencies, and a tight description of the expected change. This is one of the most effective agent constraints we’ve found: limit what the agent can see, and you limit the complexity it can invent.
Second, we removed tools that allowed broad exploration. The agents no longer have unrestricted file read, grep, or shell access. They get a small set of operations tied to the task. This forces them to reason from local evidence rather than spending their computational budget on speculative searches. The result was a dramatic improvement in output precision.
Third, we dropped the model tier. For a large subset of coding tasks, the smaller models perform at least as well as the flagship models — and often better, because they’re less likely to produce elaborate but unnecessary patterns. This wasn’t a cost-saving move. It was a quality improvement.
The Before/After: Two Weeks of Agent Output
To test the idea, we ran a two-week trial at Tacavar with a single team using the nerfed agents while another team continued with the original high-capability setup.
The results were stark. The nerfed agents produced 43% fewer pull requests that needed substantive rework after review. The average number of lines changed per task dropped by more than half, while the percentage of agent-generated code that made it into mainline without major edits climbed from 61% to 84%. The second team started adopting the nerf in their own workflow by the end of the trial.
The qualitative results were equally telling. Engineers reported that the agent output felt like it had been written by a cautious, experienced developer who wanted to minimize risk. It no longer surprised the reviewer with clever abstractions. It did exactly what was asked. For the first time, engineers actually wanted to ship agent-generated code.
Why Constraint Engineering Beats Capability Engineering
The Tacavar experiment generalizes into a principle: constraint engineering is as important as capability engineering in production agentic systems. When you throw more capability at an agent, you expand the solution space. That expansion increases the chance of an elegant, impressive failure. When you deliberately constrain the agent — through context limits, tool restrictions, or model tier — you shrink the solution space and force the model to focus on the actual goal.
This is where llm reliability gets improved. Reliability isn’t just about preventing a model from hallucinating a fact. It’s about preventing a model from hallucinating a codebase architecture. The same probability distributions that make a large model creative also make it more likely to invent complexity. Constraints suppress that tendency.
For coding agents, this is exactly the over-engineering prevention you want to build into your stack. The agent should be a precise instrument, not an overeager junior developer. The goal is to reduce variance in output quality, and nothing does that better than limiting the agent’s freedom.
When to Intentionally Downgrade Your Agents
The nerf isn’t the right choice for every task. If you’re using an agent for open-ended research or for generating greenfield architecture, broad context and high capability might be justified. But for most operational coding tasks — bug fixes, feature patches, refactors with a clear target — the inverted-U curve says you’re likely on the wrong side of the peak.
You should consider downgrading your agents when:
- The task has a well-defined scope and a narrow success criterion.
- Your most common failure mode is over-complexity, not under-performance.
- Your teammates are spending more time reviewing code than writing their own.
- Your codebase review history shows a pattern of "smart" code that later becomes a maintenance liability.
When those conditions hold, the issue isn’t that your agent is too dumb. It’s that it’s too smart for the job you gave it. The fix is not to add more guardrails to a high-capability model — it’s to lower the agent’s ceiling before it starts generating.
The Takeaway for Your AI Stack
The work at Tacavar turned a common instinct on its head. We stopped asking "can we make our agents smarter?" and started asking "what’s the minimum capability needed to get this done?" The answer saved us time, increased code quality, and made our engineers trust the tool.
The lesson for anyone building an AI stack is straightforward: don’t default to the biggest model, the most context, or the fullest tool access. Measure where your failure modes actually sit. If your agents are generating clever code that creates future pain, the smartest move might be to make them a little dumber.
The smartest AI in your stack is only valuable if its output is useful. At Tacavar, we found that usefulness peaks well before maximum capability. That’s a discovery you can rely on.
Want the same constraint patterns in your agent stack? Tacavar’s Bailian team orchestrates agents with deliberate capability limits. See how it works at tacavar.com.