Coding agents can produce large amounts of code quickly, but verification remains much weaker than code generation.
2
Developers need readable code, focused context, strong tests, and clear repository documentation to work safely with agents.
3
Long-running agents need to report progress, ask for help without stopping completely, and make their reasoning visible.
Summary
This panel discusses where coding agents help and where they still create risk. Erik Schluntz says the terminal is a common interface for agents, while people still need an IDE or another way to review their work. Aparna Dhinakaran argues that debugging requires visibility into the agent's reasoning and the files it changed. Michele Catasta says the right abstraction depends on the user, with less technical users needing the agent to disappear behind a simpler product. The panel agrees that verification, testing, dependency management, and readable code are weaker than code generation. They recommend limiting the files an agent can touch, writing repository overviews, and building tests alongside generated code. Long-running agents could handle tasks such as database migrations or reliability work, but they need progress updates and a way to ask questions while continuing other work. The panel is candid that agents are still poor at maintaining code over time and supporting non-technical users.
The terminal is a common agent interface, but humans need review tools
Erik Schluntz says the command line is enough for the agent because every engineer has a terminal, regardless of which IDE they use. He still runs Claude Code in a terminal while keeping an IDE open to review the changes. Aparna Dhinakaran says the CLI is not enough for the human side of the work. Developers need to understand what the agent changed, why it changed those files, and what happened when the result failed. She describes the process as more than input and output because the agent's reasoning also affects whether people trust its work.
The right abstraction depends on who is using the product
Michele Catasta says developers can work directly with a CLI, while less technical users need a higher-level interface. His goal is to hide the agent and eventually remove the word "agent" from the product name. Users should be able to rely on what the software does without needing to know that an LLM is running behind it. Erik adds that verification may require different levels of access. A user can check a result through an interface when the output is obvious, but deeper checks require access to lower-level details such as the code.
The panel says agents can produce a code base very quickly, but they cannot yet verify their work at the same level. Erik connects better verification with ordinary software design: systems need separation of concerns and outputs that are understandable between modules. Aparna says teams are narrowing the files an agent may touch because changes can spread through large or legacy code bases. She also points to dependency problems, including circular dependencies, and recommends writing unit tests alongside generated code. Erik suggests that whether code remains in production after a long period could be a useful evaluation, since short-term speed can create later technical debt.
Vibe debugging needs different methods from human debugging
Erik says readable code matters when a human must debug it, even if the code is not maximally sophisticated for its programming language. He also wants evaluations for readability and application latency. Michele says "vibe debugging" does not work as well as vibe coding, although agents sometimes offer a strange new option: deleting the existing work and asking the agent to write it again. He expects new debugging tools because GDB and PDB were designed for people rather than agents. Aparna describes Cursor's ability to limit the agent's context to a specific file or part of a repository as useful for avoiding repeated changes that break something else.
Agents are safer at the leaves of a codebase than at its trunk
Erik separates the less connected leaf nodes of a codebase from the central trunk and branches. He says the leaves are safer places to use vibe coding because fewer components depend on them. Core logic requires much better understanding and quality. Michele says his product uses extensive rollback support because users can get into a cycle where fixing one problem breaks another. Instant previews and the ability to return to earlier points do not prevent the problem, but they give users a way to recover from it.
Repository context and tests help agents behave like new teammates
Aparna compares a coding agent with a new engineer or an on-call teammate. She suggests giving it an architectural overview of the repository, rather than only the context around the immediate file. Good tests define what the agent's code must pass. Michele agrees that documentation and tests remain basic requirements, while agents can help search a codebase, write tests, and create an architecture diagram for a person to review. The panel's advice is practical: give the agent the vocabulary and system context it needs, then make its changes pass tests before accepting them.
Long-running agents need updates and asynchronous help
Aparna is interested in agents that can work on reliability tasks or database migrations over a long period, but she does not yet trust them to run unattended and produce useful work. She wants status updates and visibility into the agent's reasoning. Erik compares this to an employee working on a week-long assignment. That person would share an approach, ask questions, and continue with other work while waiting for an answer. He says agents should eventually ask for help without becoming completely blocked, which would make long tasks more useful than a silent process that stops at its first question.
Maintaining code is still harder than generating it
Michele says agents are behind on verification and testing compared with code generation. They can create a large amount of low-quality code, but they are weaker at refactoring and at the work needed to maintain a codebase over time. Erik gives a small example: Claude Code planned a date and produced a useful markdown file after web searches, but it could not call a restaurant or order an Uber. Aparna adds that technical users currently have more tools for understanding and debugging agent behavior. The panel does not think coding agents are ready for non-technical users.
"At this point, we can write a ton of code very fast. You can build a code base in 10 minutes. But what we can't do extremely well yet is verification."Aparna Dhinakaran05:04
Who should watch
You are deciding whether a coding agent should work through a CLI, an IDE, or a higher-level product and want the panel's reasoning about each option.
Your team is using agents in a large or legacy repository and needs practical guidance on context limits, tests, rollback, and safe code locations.
You are evaluating long-running coding agents and want a candid account of why verification, progress reporting, and maintenance still limit autonomy.
