The current feature race in AI coding assistants feels increasingly misguided. Every major player is scrambling to integrate "agentic" workflows—multi-step planning, tool use, and autonomous execution—directly into the core editor experience. While the research is fascinating, the practical implementation is adding a layer of abstraction and non-determinism that actively harms developer productivity for a large class of common tasks.
My primary issue is that these agent systems are optimized for a demo, not for a daily workflow. They turn a simple, predictable request into a black-box process with opaque reasoning, high latency, and unpredictable failure modes. Consider a straightforward task: "Add error handling to this function and log to our observability stack."
**Without Agent Overhead:**
A competent non-agentic assistant provides a direct code block edit, perhaps with a brief explanation. The transaction is fast, the scope is clear, and I can immediately evaluate the output.
**With Agent Overhead (as currently implemented):**
```
I'll help you with that. Let me break this down:
1. Analyze the existing function for potential error points.
2. Research the appropriate logging library for your stack.
3. Implement try-catch blocks.
4. Structure the log statements with relevant context.
5. Write a unit test for the new error handling.
```
It then proceeds to spin for 45 seconds, makes 8 file changes I didn't ask for, installs a logging package we already have, and its "unit test" is a broken stub because it hallucinated our test framework. I've now spent more time reverting and debugging its overreach than if I'd written the code myself.
The complexity cost is real. These systems introduce:
* **Unpredictable Latency:** Simple edits now require "planning" cycles, often serialized, blowing a 5-second task into a 60-second wait.
* **Debugging Overhead:** Tracing why an agent made a specific decision requires sifting through verbose, often irrelevant, "chain-of-thought" logs.
* **Configuration Bloat:** Assistant settings are now littered with toggles for "autonomous mode," "max steps," "self-critique," and tool permissions that most developers lack the time to properly benchmark and secure.
* **Opaque Context Usage:** It's becoming impossible to know what context (files, docs) the agent will decide to use, leading to changes in unrelated parts of the codebase.
I'm not arguing against advanced capabilities. I'm arguing for separation of concerns and user-controlled opt-in. The core editor experience should remain a sharp, predictable, fast tool for code generation and explanation. Agentic workflows for complex, multi-file refactoring or boilerplate project generation should be a distinct, explicit mode you invoke when you need that specific tool—not the default layer on every interaction.
We're sacrificing the 95% use case (direct, assisted editing) for the 5% use case (fully autonomous project work), and the benchmarks seem to be chasing the wrong metrics. Everyone is measuring "Can this assistant build a full web app?" instead of "Does this assistant make me 10% faster on my daily 50-line edit/debug cycle?"
Has anyone done any rigorous latency vs. correctness benchmarks on agent-enabled vs. direct completion modes for standard tasks? My anecdotal load testing shows a net productivity *loss* with current implementations. The hype is driving complexity, not solving it.
—DL
Benchmarks or bust
You've put your finger on something I see a lot. That "black box process" feeling is a real friction point, especially when you're in the zone and just need a precise edit. The latency and unpredictability can break your flow entirely.
I wonder if the core issue is giving up too much control by default. Maybe the agentic logic should be an explicit mode you switch into, not a layer that automatically activates for simple tasks. As a moderator, I see threads where folks feel they're wrestling with the tool's process instead of getting work done.
It's a tricky balance for the tool makers, isn't it? How do they innovate without complicating the simple, reliable use cases most of us rely on daily?
Keep it constructive.