I Nerfed Our AI Coding Agents on Purpose. Output Quality Doubled.
Tacavar nerfed its coding agents on purpose — and output quality doubled. The case for constraint engineering over raw model capability.
We made our coding agents dumber on purpose. Output quality doubled.
If that sentence reads like a typo, you're running the same playbook most teams run — bigger model, longer context, more tools. We ran it too at Tacavar. Then we watched our most capable coding agents produce the worst code in our stack: over-abstracted, unreadable, technically functional and functionally unmaintainable. So we did the counter-intuitive thing. We deliberately degraded them — smaller context windows, fewer tools, cheaper model tiers — and the code got dramatically better. The writeup hit #1 on Hacker News because it inverts an assumption the entire industry is building on.
The Failure Mode: When Your Smartest Agent Writes Your Worst Code
The pattern showed up in review queues before it showed up in dashboards. Our flagship coding agent — largest context window, full tool access, top-tier model — was supposed to be our best performer. Instead, it kept doing three things.
First, it added unnecessary abstractions. A 20-line fix would arrive wrapped in a strategy pattern. Second, it bypassed simple fixes in favor of impressive ones. Given a bug in a helper function, it would refactor three callers and introduce a new utility module nobody asked for. Third, it hallucinated complexity — inventing edge cases, defensive checks, and config surfaces for scenarios that didn't exist in our codebase.
The root cause wasn't stochastic bad luck. It was capability without boundaries. An agent with enough reasoning power and enough tools will always find a "smarter" solution than the one the task requires, and nothing in its objective punishes it for that. Reviewers kept rejecting its PRs, which meant the most expensive model in our stack had the lowest effective throughput. Our smartest agent was our biggest liability.
Agent Performance Follows an Inverted-U Curve
The industry default assumes capability monotonically improves outcomes: more parameters, more context, more tools, better results. Our data said otherwise. Plotted against task outcomes, agent capability traces an inverted-U curve.
At low capability, agents fail outright — they can't hold the codebase context, they call tools incorrectly, they produce broken code. Performance climbs as capability rises. But past a threshold, it falls again, for three distinct reasons:
- Over-engineering. Excess capability gets spent on the solution, not the problem. The agent optimizes for elegance instead of correctness and maintainability.
- Hallucinated complexity. Smarter models generate richer hypothesis spaces, including edge cases that don't exist. More capability means more plausible-sounding inventions.
- Solution-space explosion. Every additional context token and tool widens the set of valid-seeming paths. The agent explores more, commits less, and drifts further from the minimal fix.
The peak of that curve is the operating point you want: enough capability to solve the task, not enough to improvise beyond it. Everything below the peak is a capability problem. Everything above is an over-engineering problem — and almost nobody is managing for it.
Three Constraints That Doubled Output Quality
We didn't redesign the agents. We constrained them, one lever at a time, measuring merged-PR acceptance rate, review churn, and post-merge defect rate. Three constraints did most of the work.
1. We shrank context windows. Counter to every instinct, we cut the context our coding agents could pull. Without the entire repo in view, agents stopped proposing sweeping cross-cutting changes and started making localized fixes consistent with the file in front of them. Review churn dropped sharply — smaller diffs, fewer surprises, faster approvals.
2. We reduced tool access. A coding agent with a shell, a package manager, and web search will use them. Ours kept pulling in new dependencies to solve problems our existing utilities already handled. Restricting each agent to the minimum toolset for its task class removed the escape hatches. Forced to work inside the codebase, they reused what was there.
3. We forced simpler model tiers for routine work. This was the least popular change internally: routing boilerplate fixes, test updates, and small refactors to mid-tier models instead of the flagship. The result was the punchline. The dumber models couldn't over-engineer — they lacked the capacity. Their fixes were plainer, more direct, and reviewers approved them at nearly double the rate. Hence: we nerfed our agents, and output quality doubled.
None of these are model choices. They're boundary choices — coding agent constraints that shape behavior before the first token is generated.
Constraint Engineering as a First-Class Discipline
Most teams treat agent design as capability engineering: pick the model, tune the prompt, wire up tools. What's missing is an equal discipline on the other side — constraint engineering for ai agents, the deliberate design of what an agent cannot do.
This matters because llm reliability in production doesn't come from raw capability. It comes from bounded behavior. A production agent is reliable when its failure modes are narrow, predictable, and cheap to catch — and constraints are how you narrow them. Capability engineering raises the ceiling. Constraint engineering cuts the tail.
In practice we treat constraints like any other engineered surface at Tacavar: versioned, tested, owned. Every agent in our stack has an explicit capability budget — context size, tool allowlist, model tier, diff-size limits — matched to its task class. When an agent underperforms, we ask two questions, not one. Is it missing capability? Or is it drowning in it? The second question is the one the industry isn't asking, and it's the one that fixed our worst performers.
When NOT to Nerf an Agent
This is not an argument for dumb models everywhere. The inverted-U curve has a rising portion, and constraints on the wrong side of the peak will hurt you.
Keep full capability when the task is genuinely open-ended: greenfield architecture exploration, novel problem domains, one-off investigations where the deliverable is insight rather than merged code. Keep it when the problem requires deep multi-step reasoning that smaller tiers demonstrably can't complete — you'll trade over-engineering for outright failure, which is worse. And keep it during evaluation, because you need headroom models to calibrate where the peak actually sits for your task distribution.
The discipline isn't "make agents dumber." It's "match capability to the task, then bind it." Nerfing is the correction you apply when you've overshot — and most teams building agentic systems today have overshot.
The Generalizable Pattern: Bound the Solution Space, Not the Model
Strip away the specifics and the lesson generalizes to any agent system, coding or otherwise: agent over-engineering is a solution-space problem, and you fix it by bounding the solution space, not by swapping the model.
A model with a bounded solution space can only produce outputs that fit — small diffs, existing dependencies, minimal abstractions. The same model without bounds can produce anything, including the wreckage. This is why "just use a better model" never fixed our problem: the smarter model made the wreckage more sophisticated.
The pattern holds across domains. A research agent with a fixed document set stops inventing citations. An ops agent with an allowlisted command set stops improvising in production. Bound the space, and capability becomes an asset instead of a liability.
That's the architecture we've built at Tacavar: not one super-agent, but 32 constrained agents, each with a capability budget matched to its job, coordinated through an orchestration layer that treats constraints as first-class design objects.
Want agents that ship maintainable code instead of clever wreckage? Tacavar designs constraint-first agent architectures. See how our 32-agent orchestration stack works at tacavar.com/agents.