The bottleneck was never typing speed
Four assistants now do roughly the same job well. Cursor indexes a codebase and edits across files, Copilot sits in every editor with an agent mode, Claude Code runs agentic edits from the terminal, and Windsurf plans multi-step tasks through its Cascade flow. All four support or approximate the same context plumbing. Choosing among them is a preference question now, not a strategy question.
What has not been solved is everything upstream of the edit. The hard part remains assembling context from tickets, design docs, logs, incidents, ownership records, and Slack threads — work that still falls on the engineer. When a tool lacks that context, the saved typing time returns as downstream fixes and integration debt.
Three measurable gaps make the point better than any argument. In a METR randomized controlled trial of experienced open-source developers, tasks took 19% longer with AI tools, even though participants expected to be 24% faster. In the 2025 Stack Overflow survey, more developers actively distrust AI accuracy than trust it — 46% against 33% — and 66% name "almost right, but not quite" code as their leading frustration. Veracode's 2025 report puts close to 45% of AI-generated code as introducing at least one OWASP Top 10 vulnerability.
None of those are code-generation failures. They are failures of what the model could see, what the engineer could verify, and what the system allowed to ship. A better model in the IDE does not touch any of the three.
The practical consequence is a shift in where an engineer's leverage sits. Coding assistants function as personal productivity tools; they are effective inside a single repo but typically have limited awareness of tickets, incidents, or design rationale, no unified view across services, and governance that varies by vendor. The interesting engineering is now in the layer that supplies context, bounds actions, and records what happened.
What the orchestration layer actually looks like
The research has converged on a shape. A recent practical guide to production-grade agentic workflows sets out nine best practices, and the striking thing is how unglamorous they are: tool-first design over MCP, pure-function invocation, single-tool and single-responsibility agents, externalized prompt management, clean separation between workflow logic and MCP servers, containerized deployment, and adherence to KISS. This is ordinary software discipline applied to a nondeterministic component.
The authors are explicit that prototypes are easy and production is not. Scaling agent scripts into governed, observable systems introduces decomposition questions, the choice between tool calls and MCP actions, deterministic orchestration, and the avoidance of implicit behaviors that produce drift. Without that discipline, workflows grow into opaque, unbounded pipelines that are hard to debug or govern.
Translated into architecture, this reads as a new layer in the stack: UI, then API, then workflows, then agents, then data and tools. Agents do not replace workflows; they orchestrate them, with a planner decomposing tasks, an executor calling tools, a memory layer carrying context, and a self-correction loop evaluating output against the goal.
The reliability advice that comes with it is the operative part — strict tool boundaries, deterministic paths for critical work, sandboxed execution, logging of every agent action, and human-in-the-loop checkpoints for sensitive tasks. Treat agents as powerful but unpredictable microservices, and the engineering rigor you already know applies.
A caveat on the evidence
The 19% slowdown deserves less certainty than it gets. METR's follow-up study with a larger cohort, begun in August 2025, produced mixed results complicated by selection bias; what survived both studies was the perception gap, not the slowdown itself. And the prescriptive half rests on a guide demonstrated through a single case study — a multimodal news-analysis pipeline — which is a proof of coherence, not of scale.
Most developers are not there yet
A GitHub community thread from February 2026 is a useful reality check. Asked what their must-have AI tools are, twenty-eight commenters answered almost entirely with assistant selection and review habits: Copilot for scaffolding, Claude for debugging, ChatGPT for learning, Tabnine where privacy matters. Orchestration frameworks appear, but as a single line — chain tools together with LangChain or LangGraph — buried among the picks.
What the thread is actually rich in is review discipline. Treat AI-generated code like a junior developer's draft: always review, test, and secure. Do not paste sensitive code into public tools. Use AI for speed, not final decisions. That is a governance layer implemented in human habit rather than in software, and for most teams it is the only one currently running.
Which is the honest state of things. The context layer is a direction, not a default, and the tooling vendors know it — evaluation criteria for team-scale AI tools now foreground workflow fit across IDE, PR, and CI/CD, security guardrails for AI-generated code, data privacy controls, and clear scope, policy, and approval boundaries so agent actions stay controlled and auditable. Those are the same questions the thread answers informally, written down.