AI Agents Are Writing Production Code. Here's What That Changes for Engineers

Six years ago, autocomplete finished your line of code. Two years ago, a copilot finished your function. Today, at companies like Razorpay and Rakuten, an AI agent can pick up a ticket, read the codebase, write the code, test it, fix its own failures, and open a pull request, without a human touching a keyboard.

This is not a prediction about the future of software engineering. It is already running in production. The question for engineers is not whether this shift is coming. It is whether they understand what it changes about their job, and what it does not.

 

What Exactly Is an Autonomous Coding Agent?

An autonomous coding agent is different from a code-completion tool or coding assistant. Where autocomplete finishes a line and a copilot finishes a function, an agent is given an outcome - a ticket, a bug report, a feature spec - and independently plans, executes, tests, and iterates on the full task, often across multiple files and systems.

Autocomplete: predicts the next few characters or line based on context.

Copilot-style assistance: completes a function or block when prompted, with a human still writing the surrounding logic.

Autonomous agent: takes a task description, explores the repository, writes code across multiple files, runs and fixes tests, and submits a working pull request end-to-end.

AI researcher and Anthropic team member Andrej Karpathy has described this progression as part of a broader shift he calls "Software 3.0", where the unit of programming moves from a function to a plain-language instruction, and the engineer's role shifts from direct author to orchestrator and reviewer of what the system produces.

 

Why Is This Shift Happening Now?

The short answer: the economics of writing code changed faster than the economics of everything around it.

Model capability crossed a usability threshold. Coding agents can now hold context across large production codebases - reading a multi-file diff, understanding dependencies, and producing a working, tested change - something that was not reliable even 12 to 18 months ago.

Coding stopped being the bottleneck. Engineering teams have long spent roughly half their time actually writing code. The rest goes into PR reviews, Slack threads, boilerplate tests, onboarding, and chasing flaky pipelines. Agents are increasingly absorbing the coding half, which shifts the bottleneck to everything else.

Cycle time economics changed. In human-only teams, a pull request opened at 3am often waits until late morning for a first review. With an agent in the review loop, that first pass can land in minutes, not hours - compressing a metric engineering organisations have tried to fix for years without simply adding headcount.

Context handoffs got cheaper. A ticket rarely captures every edge case discussed on a call or in a Slack thread. Agents that can ingest the ticket, the transcript, the thread, and the linked document in one pass reduce the information loss that happens every time work passes between humans.

 

How Are Companies Actually Using This in Production in 2026?

Several engineering organisations have published detailed, verifiable accounts of running autonomous agents inside real codebases.

Razorpay's Slash - an internal agentic system

According to Razorpay's own engineering blog, its internal agentic system, Slash, now handles tens of thousands of agent sessions and thousands of merged pull requests every month, with over a third of them merged without a human in the loop - though every change still passes the same checks as any human-authored one.

Specific capabilities the company has documented:

• Slash clones the relevant repository, writes the code, runs tests, opens a PR, and posts a Slack update - triggered by a Slack mention, a ticket assignment, or a CI pipeline event.

• A dedicated "Slash Reviewer" runs specialised sub-agents against every PR, covering bug detection, security, code quality, design-system compliance, and internationalisation, before a human ever looks at it.

Razorpay co-founder Shashank Kumar has publicly shared that Slash handles more than 5,000 tasks every day, and that the number continues to grow rapidly. Co-founder Harshil Mathur has stated that, in the near term, the company's internal direction is for engineers to guide agents rather than write code manually.

Rakuten — a 12.5-million-line codebase

In a case study published by Anthropic, a Rakuten machine learning engineer gave Claude Code a complex task inside a 12.5-million-line open-source library: implement a specific activation-vector extraction method. The agent completed the task autonomously in seven hours, with the engineer providing only occasional guidance, and the implementation reached 99.9% numerical accuracy against the reference method.

The honest counterpoint: agent output is not automatically team output

Not every organisation sees delivery metrics move because individual productivity metrics do. Anthropic's own internal survey of engineers found a 67% increase in merged PRs per day and self-reported productivity gains of 20 to 50%. However, independent analysis has pointed out that organisation-wide delivery metrics do not shift proportionally, and that more than half of surveyed engineers could still only fully delegate 20% or less of their daily work.

The gap between individual speed and team throughput is showing up as a new bottleneck: PR review capacity. Faster code production without expanded review and verification infrastructure does not reliably translate into faster shipped, reliable software. It moves the pressure downstream.

 

The Four Steps of AI Adoption in Engineering Organisations

Boris Cherny, Creator and Head of Claude Code at Anthropic, published a framework this week that maps what this actually looks like inside engineering organisations. He calls it the "Steps of AI Adoption" - four stages from fully gated AI access to fully AI-native operations.

His observation from talking to engineering teams daily: "One person is 10x'ing their output with Claude but the rest of the org hasn't caught up."

That gap between individual productivity and organisational throughput is exactly what the four steps describe:

Step 0: Gated. No agent access. Only older or approved models through AI gateways and custom auth. The bottleneck is legacy security, approval processes, and lack of true technical voices in decision-making.

Step 1: Assisted. One engineer, one agent, mostly supervised. A fast pair programmer. You run one session at a time and review almost every change before it merges. The unlock: a change that used to fill an afternoon becomes something you finish between meetings.

Step 2: Parallel Orchestrator. One engineer orchestrates 5 to 10 agents at once, each on its own worktree or git checkout. Auto mode is always on. Automated code review and security review are on by default. Output multiplies. You review final diffs rather than keystrokes. The unlock: a backlog that used to take the team weeks becomes one engineer's afternoon of orchestration.

Step 3: Supervised Autonomy. Claude writes most of the code. "Did you read the code?" becomes "what context was the model missing and how do we solve it for next time?" Claude proactively does work you would have had to kick off manually before. The unlock: maintenance and cleanup runs continuously in the background.

Step 4: AI-native. The loop is fully closed. Hundreds to thousands of agents run. Leadership steers by intent and monitors by exception. The unlock: a quarter-long migration becomes a workflow you kick off and check on.

Anthropic is on Step 3 and pushing toward Step 4. Cherny notes that the bottleneck at each step is not code generation. It is trust, guardrails, and review capacity - the same constraint Razorpay's Slash Reviewer sub-agents are designed to address.

 

Tools Being Built to Address the Review Bottleneck

The review capacity problem Boris describes at Step 2 is generating its own category of infrastructure tooling.

Bytebell is one example. It compiles a codebase into a verifiable graph of intent and dependencies - a single intermediate representation served to every AI tool over MCP - and checks every AI-generated change against that graph before it merges. The key capability is blast-radius detection: before a change lands, Bytebell traces what it breaks across every repository, not just the one the PR lives in. The change that looks clean in isolation but breaks a contract three repos away gets caught in review, not in production. This is precisely the cross-repo review problem that emerges when agent output scales faster than human review bandwidth.

Bytebell publishes figures of 93%+ accuracy on SWE-Bench Pro, 80% lower cost per query, and 90% faster responses compared to context-dumping approaches. These are their own published claims. The tool is available with a free community tier and a hosted Developer plan at $12 per user per month.

 

What Does the Data Actually Show?

Numbers are circulating widely. It is worth separating verified figures from hype.

Gartner projects that 33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024 - a genuine inflexion point, though Gartner also cautions that over 40% of current agentic AI projects will likely be cancelled by the end of 2027 due to unclear ROI or inadequate governance.

Anthropic's internal research found employees self-reporting Claude use in roughly 60% of their work and a 50% self-reported productivity boost, with the caveat that this reflects modestly less time per task and considerably more output volume, not simply the same work done faster.

MIT's Project NANDA found that 95% of enterprise generative AI pilots show zero measurable impact on profit and loss. The model works in the lab. It breaks the moment it touches real enterprise data, legacy systems, and actual workflows. This is the structural problem forward-deployed engineers are hired to solve.

The unresolved variable across nearly every published study is review capacity, not code generation. This is the constraint the Boris Cherny framework, Razorpay's Slash Reviewer, and tools like Bytebell are all independently addressing.

 

How Is the Engineer's Job Description Actually Changing?

The role is not disappearing. It is moving up a layer. This is the redefinition worth paying attention to:

Old job: Write the code.
Recent job: Write the code, faster, with a copilot suggesting completions. Current job: Describe the outcome, let the agent build it, review what comes back, decide what ships.

Karpathy's framing is useful here: as agents absorb more of the implementation work, the scarce skill shifts from syntax and output speed toward judgment, taste, and system-level oversight - knowing which of several agent-generated approaches will hold up in production and which will quietly break six months later.

This is not a smaller job. It is an entirely different one. And it is not being assigned to anyone automatically. Engineers are largely having to claim it.

 

What Skills Now Separate a Replaceable Engineer from an Irreplaceable One?

Prompting an agent to build a feature is no longer a differentiator. It is now closer to knowing how to use a search engine.

What companies are actually paying for:

1. Critical review of agent output. Reading a pull request sceptically enough to catch a plausible-but-wrong implementation, a silently dropped edge case, or a technically passing but architecturally wrong decision.

2. Comparative judgment across parallel agent runs. Running multiple agents on the same problem and knowing which approach will hold up under real production load.

Guardrail and system design. Building the permissions, checkpoints, and review gates that let several agents work safely without a human bottlenecked on every line. Closer to systems design than to writing code. Building and managing a strong observability layer for agents is the emerging version of this skill.

Documented proof of caught mistakes. A specific, written account of what an agent got wrong, why, and what was changed carries more signal to a hiring manager than a certificate confirming tool familiarity.

Willingness to let an agent fail on a real task, on purpose. Catching a real failure before it ships is a more credible signal of readiness for autonomy than any completed course.

 

Who Should Be Paying Closest Attention to This Shift?

Backend and full-stack engineers at mid-to-large product companies where agentic tools are already being piloted or deployed at the ticket level.

Engineering leads and managers deciding how to redesign review pipelines, permissions, and delegation boundaries before agent output outpaces review capacity.

Early-to-mid-career engineers whose current value proposition is largely "writes clean code quickly" - the segment most exposed to this redefinition.

Engineers at companies without agent access yet. The constraint of no mandate to change the pipeline does not prevent running one agent on one real problem independently and documenting what broke.

For engineers in India specifically: the shift is arriving through GCCs, product companies, and IT services firms deploying these tools at different speeds. Razorpay's Slash is the most documented Indian example currently running in production. Several GCCs in Bengaluru and Hyderabad are running similar internal systems. India produces 1.5 million engineers every year and carries thirty years of F500 deployment muscle across TCS, Infosys, Wipro, and HCL - the systems integration and enterprise deployment DNA that maps directly onto what the FDE and agentic orchestration roles require. The question for Indian engineers is not whether this is coming. It is which organisation they are in and how fast it is moving there.

 

What Should Engineers Actually Do Next?

Three directions are worth taking seriously, based on what is already working at organisations running this in production.

Go deep on one real, painful workflow. Not "I tried an agent once." Pick a genuinely slow or flaky part of your team's pipeline and ship an agent-assisted fix. Measure the before and after.

Practice review, not just prompting. The instinct for spotting a plausible-but-wrong PR comes from catching enough agent mistakes to develop pattern recognition, not from a course.

Move toward orchestration. The engineers pulling ahead are not writing more code themselves. They are designing the permission structures and checkpoints that let multiple agents work without constant human bottlenecks. This is the Step 2-to-Step 3 transition in Boris Cherny's framework.

Two moves apply regardless of which direction you take:

Let an agent fail on your watch, deliberately, on something with real stakes - and catch it before it ships. That failure and your fix are more valuable on a resume than a completion certificate.

Write down exactly what you caught. A clear account of what the agent got wrong, why, and what you changed is proof you can be trusted with autonomy you did not build yourself.