The Road Ahead for AI Coding

Updated September 16, 2026.

The road ahead for AI coding starts with something that is already here: agents that can take a task, work in a development environment, and return changes for review. The question for a team adopting them is how much useful work it can delegate repeatedly, at an acceptable cost, with enough control to trust what ships.

The infrastructure is taking shape. Cursor's cloud agents run in isolated environments and can test an application, use a browser, and produce artifacts for review.^[1] GitHub Copilot's cloud agent can research a repository, implement a task in an ephemeral environment, run tests, and open a pull request.^[2] Claude Code spans terminal, IDE, web, and desktop workflows.^[3] Calling these products smarter autocomplete misses how much the workflow has changed.

I still think the platform opportunity is enormous. A developer getting a good result from an agent is one thing. An organization knowing which work to send, what the agent may access, how to evaluate the result, and who owns a failure is a much larger problem. Running an agent is one component of that system. Making delegated engineering dependable is the product.

The distinction matters because autonomy has several boundaries. Starting work, changing a branch, merging a pull request, and deploying to production are separate decisions. A team can automate the first two and keep explicit approval for the others. A dependency update with narrow scope and a reliable rollback deserves a different policy from a migration that changes customer data. Progress means giving agents more responsibility where the evidence supports it. A human approving the result is a useful part of the system.

Consider the workflow I care about: an error becomes a task, the agent investigates, attempts a fix, runs checks, and prepares a pull request. That can happen without an engineer noticing the alert and opening an editor first. The engineer then judges whether the fix addresses the actual problem. A passing test helps, but the reviewer also needs the reproduction, the reasoning behind the change, and any uncertainty the agent could not resolve. The time saved at the beginning is only valuable if it survives that review.

Reliable operation also needs a way to stop, retry, and recover. Put limits on spending and execution time. Give the agent the credentials and network access the task requires. Preserve enough of the environment and run history to investigate a failure. Define what happens when a test flakes, an integration goes down, or two agents edit the same code. These are requirements I would use to evaluate a platform, alongside the quality of the code it generates.

Measurement belongs in the same conversation. GitHub already exposes cloud-agent pull request metrics, including merged pull requests and median time to merge.^[2] Those are useful starting points. I would also track reviewer time, rework, regressions, abandoned attempts, and total cost per accepted outcome. Compare similar work against a baseline. Include model usage, execution infrastructure, and human effort. An agent that opens twice as many pull requests while doubling the review queue has not established its value.

DORA's 2025 research frames AI as an amplifier of an organization's existing strengths and weaknesses, with the underlying organizational system shaping the return.^[4] I read that as a reason to invest in clear requirements, useful tests, and fast feedback alongside better agents. A platform can make those practices easier to apply consistently. It cannot infer every business constraint that the team has never written down.

That is the bet behind the Tembo manifesto. I am Tembo's co-founder and CEO, so this is also the direction I am building toward. Today, Tembo provides isolated cloud environments for agents, connections to a team's repositories and tools, and a choice of agent harnesses.^[5] Its automations support event-driven and scheduled work, including the Sentry-alert-to-fix-PR workflow, with human review of the result.^[6] Those capabilities make the platform thesis concrete. Whether they save a particular team time and money still needs to be measured in that team's work.

The competitive bar is rising with those capabilities. The companies building editors, models, and code hosting already own substantial parts of the workflow. An independent platform has to earn its place. My middleware argument and multi-agent platform thesis depend on serving the customer's interests: preserving their context and policies, supporting meaningful agent choice, and evaluating outcomes on their own tasks. Portability takes work. Permissions, integrations, instructions, and evaluation need to survive a change of agent for that choice to be useful.

I want this to reach the company with a small engineering team and a backlog it cannot afford to tackle. That team should be able to delegate a well-defined fix or improvement and spend its judgment on the result. Getting there requires a product that makes the whole process manageable, including the failures. That is the road ahead I am betting on: more useful work getting done, with clear ownership of what ships.

— Ry