I've reviewed thousands of coding-agent changes. Early error handling often gives away that a feature was built in the wrong order.
The agent adds rescue blocks, fallback behaviour and logging before the software has revealed which errors can actually occur.
Agents tend to build horizontally, through the database, services, API, validation and UI, anticipating the finished system before they have a working slice to learn from. That fits how they are evaluated. SWE-bench measures whether a patch resolves a bounded issue and passes the tests, not whether another engineer can safely change the code six months later.
Real projects reveal information while you build them. I generally leave most error handling until the core path works. By then I know which errors occur, where they are raised and what the user should see. The handling I write protects against failures I have watched happen.
Matt Pocock has been making this case for agent workflows with tracer-bullet vertical slices, an idea engineers will recognise from The Pragmatic Programmer. Each slice cuts through enough of the system to leave something visible and verifiable before you take the next step. An agent working in slices meets real errors while the design can still respond to them.
The cost shows up in review. A reviewer facing speculative error handling has to work out which branches protect against something real, where the errors are raised, what gets logged and what the user will see. In a large PR, that work can bury the feature being reviewed. A speculative handler caught in the first slice is easy to delete. Repeated across every layer, it becomes the error architecture of the feature.
Speculative error handling is a useful review smell. If a PR contains failure paths that nobody has observed or verified, the work has probably gone too far without feedback.
The agent adds rescue blocks, fallback behaviour and logging before the software has revealed which errors can actually occur.
Agents tend to build horizontally, through the database, services, API, validation and UI, anticipating the finished system before they have a working slice to learn from. That fits how they are evaluated. SWE-bench measures whether a patch resolves a bounded issue and passes the tests, not whether another engineer can safely change the code six months later.
Real projects reveal information while you build them. I generally leave most error handling until the core path works. By then I know which errors occur, where they are raised and what the user should see. The handling I write protects against failures I have watched happen.
Matt Pocock has been making this case for agent workflows with tracer-bullet vertical slices, an idea engineers will recognise from The Pragmatic Programmer. Each slice cuts through enough of the system to leave something visible and verifiable before you take the next step. An agent working in slices meets real errors while the design can still respond to them.
The cost shows up in review. A reviewer facing speculative error handling has to work out which branches protect against something real, where the errors are raised, what gets logged and what the user will see. In a large PR, that work can bury the feature being reviewed. A speculative handler caught in the first slice is easy to delete. Repeated across every layer, it becomes the error architecture of the feature.
Speculative error handling is a useful review smell. If a PR contains failure paths that nobody has observed or verified, the work has probably gone too far without feedback.