What if the smartest AI in your stack is actually your biggest liability? That question became impossible to ignore inside Tacavar after Josh Fathi deliberately degraded our coding agents—and output quality doubled. The HN post marking the experiment, "Show HN: I nerfed our coding agents on purpose," went to #1 because it contradicts a deeply held assumption: that more capability is always better. It isn't. For agentic systems, the relationship between capability and output quality is not linear. It's an inverted-U. ## The Inverted-U Curve of Agent Capability Every builder has felt the pressure to upgrade. A bigger model, a longer context window, a wider tool surface. For AI agents, the default intuition is monotonic improvement: give the agent more intelligence and it will solve more problems. Our data at Tacavar says the opposite. When we tracked coding agents across dozens of tasks, we saw a clear curve. Performance improves as capability rises—but only to a point. After that, error rates climb. The peak is not at maximum capability. It's somewhere before it. The failures at the top of the curve are not random. They're systematic over-engineering. An agent with too much context starts anchoring on irrelevant details. An agent with too many tools invents workflows that no human would use. An agent with a frontier model optimizes for "impressive" code rather than incremental, maintainable changes. The result is a solution-space explosion: more abstractions, more edge cases, more complexity—and more room for hallucination. This is not a hardware problem or a model quality problem. It's a fundamental property of agentic systems. When we stopped tuning for raw capability and started tuning for constraints, we saw LLM reliability improve in the only metric that matters: shipped code. ## Over-Engineering: When Smart Models Write Worse Code Tacavar's coding agents are not a toy. They sit in a real deployment pipeline, and the humans reviewing their work had developed a quiet aversion to the most capable agents. The pattern was always the same. Given a simple bug, a frontier-model agent would refactor the surrounding module, add an abstraction layer, and introduce a config file. The diff was huge. The commit message was ambitious. And the code was harder to review, harder to test, and harder to maintain than the original. We were paying for intelligence and receiving complexity. The deeper problem was that the agent was optimizing for the wrong objective. It had learned, from its training data, that great engineers write clean abstractions. It didn't understand that great engineers also know when not to. In production, the best change is often the smallest one. That nuance is exactly what gets lost when you maximize capability without agent constraints. The agent does not see a cost to complexity because complexity is not part of its loss function. It only sees an opportunity to be smart. The result is a system that confidently produces the kind of code that looks good in a demo and breaks in a code review. ## Our Experiment: Constraining Context, Tools, and Model Tier We didn't do this based on theory. We were frustrated. Our review queue was full of "impressive" diffs that needed heavy edits, and the team was losing trust in the whole pipeline. So Josh ran a controlled degradation experiment on Tacavar's coding agents. The goal wasn't to reduce capability—it was to find the point where the agents became reliable. We made three changes. First, we cut context windows aggressively. Instead of feeding an agent the entire repository and a rich issue thread, we handed it a narrow slice: the failing file, the relevant tests, and one sentence of instruction. Second, we removed tools. Agents that previously had shell access, file search, package managers, and a browser were reduced to a minimal set: edit, run tests, and report back. Third, we dropped model tier for most routine tasks, reserving frontier models for the rare cases where genuine reasoning was required. The immediate effect was psychological: it felt like a downgrade. The agents no longer had the capacity to "solve" every problem in their own way. They solved the problem we actually defined, or they did not solve it at all. The absence of extra options created agent constraints that forced focus. And because the action space was smaller, the failure surface was smaller. The agents couldn't over-engineer what they couldn't reach. ## The Results: More Maintainable, Correct, and Shippable Outputs The results were striking. We measured output quality across four dimensions: correctness, maintainability, review time, and shippability. Every dimension improved after the constraints were applied. The most dramatic change was in code review. Diffs shrank. Abstractions disappeared. The agents stopped touching code that wasn't part of the ticket. Engineers stopped rewriting agent output and started clicking approve. Why? Because constrained agents are forced to make a decision with less information and fewer tools. They can't pattern-match to a grandiose solution. They have to look at the actual code in front of them and make the smallest change that passes the tests. That process produces a different kind of code—code that looks like a human wrote it under time pressure rather than a developer wrote it with infinite budget. We also saw a drop in "hallucinated complexity." With full context, the agent would invent a relationship between two modules that didn't exist. With a narrow context, it couldn't even see the other module. It is a strange thing to build a system and then deliberately blind it, but the numbers were unambiguous. The constrained agents had a higher fix rate on first submission, a lower rewrite frequency, and a shorter cycle time. Output quality doubled because the agents were no longer trying to be impressive. They were trying to be useful. ## Constraint Engineering as a Core Discipline The biggest lesson from this experiment is that building production agent systems is not purely a capability engineering problem. It's a constraint engineering problem. The industry standard approach is to assume that a better model, a longer context, and more tools will always lead to better results. Our experience says otherwise. For AI agents to be trustworthy, their boundaries must be as carefully designed as their intelligence. Constraint engineering is not dumbing something down. It is modeling the actual problem. A coding agent that can rewrite the entire codebase is not a better coding agent. It's a bigger risk. A coding agent that can only edit the file in front of it is an agent whose authority is aligned with its responsibility. The same applies to llm reliability. We can't fully control a model's hidden reasoning, but we can control the environment it operates in. We can control what it sees, what it touches, and what it is allowed to ship. Those controls are the most effective reliability layer we found. ## How to Apply This in Your Own Agent Stack You don't need to run a full degradation experiment to start seeing gains. Start by auditing your current agent stack and asking what your agents can access. Then ask whether each access point is earning its risk. If an agent has file search, shell access, and the ability to install dependencies, it will eventually use all of them—often at the same time. The key is to apply agent constraints at the boundaries of your system. Start with context. Give the agent only the information required for the current task. If you have a bug report, don't paste an entire issue tracker. Include the stack trace, the failing test, and the relevant file. Next, reduce tools to a minimal set. Every tool is a source of unintended behavior. The best toolset is the one that lets the agent complete the task and nothing more. Finally, match model tier to task difficulty. Don't put a frontier model on a routine refactor and expect it to behave like a junior engineer. It won't. It will behave like a senior engineer with no sense of scope. Most importantly, treat capability as a variable you tune, not a number you maximize. The right level of capability is the lowest level that reliably solves the problem. Our agents are still capable. They're just not infinitely capable in every direction at once. That single shift in design philosophy is what turned Tacavar's coding agents from a source of review friction into a source of shipped code. Try Tacavar's constraint-engineered agent architecture for your own deployments at tacavar.com.