Skip to content

Coding Agent Acceleration Curve

Summary

Andrew Ng's May 2026 framework maps the differential speed at which coding agents accelerate different types of software work: frontend development > backend > infrastructure > research. This acceleration gradient has direct implications for team architecture and management expectations.

Details

The Framework

Ng's acceleration ranking, from most to least accelerated:

  1. Frontend development — Dramatically sped up. Coding agents are fluent in TypeScript, JavaScript, React, and Angular. They can examine their own output by operating a web browser and iterate. Weak at visual design but fast at implementation when design is provided or irrelevant.

  2. Backend development — Moderately accelerated. Harder because it requires steering models through corner cases that lead to subtle bugs or security flaws. Backend bugs can cascade into non-intuitive downstream effects (e.g., corrupted databases returning incorrect results). Skilled developers still produce far better backends than agents. Database migrations remain a risk.

  3. Infrastructure — Minimally accelerated. LLMs have limited knowledge of infrastructure tradeoffs. Ng says he "rarely trust[s] them for critical infra decisions." Building good infrastructure requires testing and experimentation — coding agents can help but the bottleneck remains. Finding infrastructure bugs (e.g., network misconfigurations) requires deep expertise.

  4. Research — Still very limited. Research involves hypothesis formulation, experiment design, interpretation, and iteration — work that extends far beyond coding. Ng uses agents to orchestrate experiments on behalf of single researchers but notes "today's agents help with research only marginally."

Management Implications

Ng's practical take: "I now ask front-end teams to implement products dramatically faster than a year ago, but my expectations for research teams have not shifted nearly as much."

This maps onto existing wiki frameworks: - concepts/lights-out-codebase — The acceleration curve explains why lights-out codebases are viable for frontend (high-throughput → forces the question) but not yet for research - concepts/compiler-analysis — The infrastructure difficulty Ng describes is the very apparatus gap that Venturini identifies - concepts/agentic-engineering — The curve defines which team functions should be redesigned for agentic workflows and which should maintain traditional engineering cadence - concepts/harness-engineering — Teams should reallocate resources according to the acceleration gradient, not uniformly

Open Questions

  • Does the acceleration curve change as models improve, or does the relative ordering remain stable?
  • Are there work types outside the four-tier model (design, QA, project management, DevOps as distinct from infrastructure)?
  • Does the acceleration gap create organizational friction — teams asked to move faster than the infrastructure (testing, monitoring, code review) can support?

Sources