The smartest AI in your stack might be your biggest liability. We made our coding agents dumber on purpose, and output quality doubled. Not in a demo. In production, on Tacavar's own codebase, after Josh Fathi and the Bailian team ran a two-week experiment that deliberately degraded agent capability. The post about it hit #1 on Hacker News, and the response was telling: every founder who had run agents in anger recognized the failure mode. More capability was not the bottleneck. It was the cause. ## The Inverted-U Curve of Agent Capability The default assumption in agentic AI is monotonic improvement: bigger model, larger context, more tools, better output. The data from Tacavar suggests otherwise. Agent performance follows an inverted-U curve. Up to a point, increasing capability improves correctness. Beyond that point, error rates climb. The agent doesn't fail by doing less; it fails by doing too much. Why? Because a coding agent with excessive capability treats every ticket as an opportunity to demonstrate intelligence. It introduces abstractions that obscure the original logic. It "future-proofs" against requirements that don't exist. It adds indirection because indirection is what advanced models are trained to produce. The result is code that passes tests, satisfies lint rules, and yet makes every human reviewer uncomfortable. That discomfort is the signal — the system has crossed the peak of the curve. ## How Over-Engineered Code Sneaks Past Review The dangerous part is that over-engineered code doesn't look wrong. It looks impressive. A PR from an over-capable agent will sometimes include a new service layer, a generic event bus, or a caching strategy that was never requested. The diff is large, but each individual hunk is defensible. A busy reviewer sees sophisticated patterns and assumes the agent understood something they didn't. This is not just an aesthetic problem. At Tacavar, we watched agents bypass a simple fix in favor of an architectural one. A race condition that could be solved by moving two lines became a distributed lock. A config typo became a new configuration schema. These agents were not being lazy; they were being too clever. The unnecessary abstractions compounded. Every layer added surface area for future bugs, and because the code looked experienced, it shipped. Over-engineering prevention is as much about limiting agent ambition as it is about reviewing intent. ## What I Nerfed: Context, Tools, and Model Tier The point isn't to make agents useless. It's to give them exactly enough capability to do the task and no more. The Bailian team pulled three levers: **Context window.** We stopped giving agents the whole repository. Instead of a 128k-token context dump, the agent got the relevant module, the immediate call sites, and a precise statement of the problem. Less context forced the agent to treat the local code as ground truth instead of spinning theories about distant parts of the system. It also reduced the chance that unrelated code would be "cleaned up" as part of the task. **Tool access.** We removed write access to most of the codebase. Agents could read broadly but only edit files explicitly listed in the task. No creating files. No moving files. No running arbitrary tests unless the task required it. The tool constraint is the strongest guardrail because it converts a preference (don't refactor) into a physical boundary (you cannot refactor). **Model tier.** We downgraded the underlying model for routine tasks. A smaller, faster model with less "creative" capability is more likely to write the boring, direct solution. We reserved the frontier model for architecture and open-ended exploration, which is where its cost actually pays off. The pattern is not "dumb agents are better." It's that agent constraints should be chosen intentionally, in the same way you choose a language or a framework. Capability is a resource, not a goal. ## The Before/After: Two Weeks of Agent Output The two-week experiment was simple. Week one: agents ran with the full toolbox — large context, broad tool access, frontier model. Week two: the nerfed config. Same backlog, same team, same definition of done. The result was unambiguous: output quality doubled. Specifically, the percentage of agent-generated PRs that merged without rework or meaningful review comments doubled. The absolute number of PRs per day didn't collapse; it shifted toward smaller, more focused changes. The qualitative difference was stark. Week-one agents produced elegant solutions that required four rounds of review. Week-two agents produced direct solutions that required one. Engineers stopped seeing agent PRs as work. They started seeing them as a first draft that was close to shippable. Week-one agents were adding "robustness" that read as risk. Week-two agents added tests that actually matched the change. Same team, same goal, completely different relationship to the output. This did not happen because models got worse at reasoning. It happened because the system was aligned with the actual objective: correct, maintainable code that humans want to ship. Capability beyond the task requirement is not a feature; it's a tax. ## Why Constraint Engineering Beats Capability Engineering The industry has spent years pushing in one direction. More parameters, more context, more reasoning effort. But llm reliability in production is not improved by uncompromising raw intelligence. It's improved by reducing the space in which a model can be confidently wrong. That's what constraint engineering does. It shapes the problem so the agent's default behavior is correct. At Tacavar, we now think of agent constraints as part of the product spec. Every autonomous system should have an explicit "capability budget," the same way it has an ops budget or a latency budget. The budget answers a question: what is the minimum set of capabilities required to complete this task successfully? Anything above that minimum is risk. This is also why we call the orchestrating team Bailian. They are not hunting for the most powerful model. They are matching model, context, and tools to the decision type. In some cases that's a frontier model with a single narrow tool. In others it's a small model with no tools at all. The agent constraints are the product. Over-engineering prevention starts upstream. A coding agent that cannot see the entire repo cannot rationalize an unrequested refactor. An agent that cannot create files cannot invent a microservice. A model that is not smart enough to be impressive will be smart enough to be useful. That trade-off is the whole game. ## When to Intentionally Downgrade Your Agents Not every agent should be nerfed. The decision depends on the cost of failure and the nature of the task. **Downgrade when the output is consumed by production systems.** If incorrect or over-engineered code will be run by customers, constrain heavily. This is the default for code that ships. **Downgrade when the task has a narrow contract.** A bug fix with a known reproducer needs context, a small model, and no write access outside the relevant files. The narrower the contract, the fewer tools the agent should have. **Keep capability for exploration.** Asking an agent to propose three architectures is a different job than asking it to implement one. Use the capable model for the former, then hand the selected design to the constrained agent for implementation. **Upgrade when the bottleneck is reasoning, not action.** If the agent fails because it lacks domain knowledge or planning ability, add capability. If it fails because it creates a mess, remove it. You can tell which one is happening by reading the diff. Bloated diffs are a capability problem. Wrong diffs are a reasoning problem. The operational sign that you should downgrade is not failure. It's confident over-delivery. An agent that consistently produces code that is more complex than the ticket requests is a liability, no matter how good it is at reasoning. ## The Takeaway for Your AI Stack The smartest model is not the best model. The best model is the one that solves the problem with the minimum viable intelligence. Tacavar's coding agents improved only after we deliberately removed context, tools, and raw model capability. The lesson is generalizable: llm reliability and over-engineering prevention are achieved through deliberate constraint, not through escalation. Stop asking which model is smart enough. Ask which agent configuration is dumb enough to be trustworthy. The answer will surprise you. 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.