The research on developer-agent collaboration revealed something that feels obvious in retrospect but changes how I think about using these tools:

Incremental collaboration dramatically outperformed one-shot approaches: Developers who broke tasks into sequential sub-tasks and worked iteratively with the agent succeeded on 83% of issues, compared to only 38% success for those who provided the entire issue description at once and expected a complete solution.

This is less of a prompt engineering trick, and more common sense. When you don’t have enough details (or in LLM works, not enough context), then breaking down tasks into smaller achievable chunks with quick feedback points works the best. The parallel to distributed systems design is direct: you wouldn’t build a monolithic service that handles authentication, payments, and notifications all at once. You’d decompose it into focused services with clear boundaries, verify each one works independently, then compose them. Agent collaboration follows the same pattern; except instead of decomposing code, you’re decomposing cognitive work.

Active developer participation was essential for success: Participants who provided expert knowledge to the agent succeeded on 64% of issues versus 29% for those who only provided environmental context, and those who manually wrote some code alongside the agent succeeded on 79% of issues compared to 33% who relied entirely on the agent.

The successful pattern is rarely “AI does the work while I watch.” It’s more like pair programming with a partner who has inconsistent context. You write some code, the agent writes some code, you verify constantly. The moment you delegate end-to-end and walk away, success rates collapse. What clicked for me is how directly this maps to service reliability patterns: just as you wouldn’t trust a single microservice to handle an entire user journey without health checks and monitoring, you shouldn’t expect agents to complete complex tasks without incremental verification.

Developers preferred reviewing code over explanations: Participants reviewed code diffs after 67% of agent responses but only reviewed textual explanations after 31% of responses.

This tracks with how I work now. I skip the explanations entirely and go straight to the diff. Show me what changed, not the narrative around why it changed. The code is the source of truth-explanations are just another layer of output to verify. It’s similar to how you’d read service logs rather than relying on a dashboard’s interpretation of what might be wrong.

The failure modes mirror distributed systems challenges too. The research found agents made unsolicited changes beyond prompt scope in 38% of cases. Imagine a microservice that randomly modified adjacent services because it thought it was being helpful. You’d immediately add circuit breakers and strict API contracts. Same principle applies here: narrow scope, clear boundaries, constant verification. When a service (or agent) can’t be trusted to stay within its boundaries, you build infrastructure around that limitation rather than hoping it improves.

I’m still working through how much of this is current model limitations versus fundamental to how these tools work. We spent years learning that microservices need observability, circuit breakers, and clear contracts. The incremental collaboration pattern might be the equivalent for agents-permanent infrastructure rather than temporary scaffolding while models improve. If agents really do follow the same reliability patterns as distributed services, we should be applying the same operational discipline we’ve learned over the past decade.