Karpathy Called Programming “Unrecognizable”—Now Agents Open the Pull Requests

By August 2026, Andrej Karpathy’s February observation looks less like a prediction than a description of an increasingly concrete workflow: developers assign work in natural language, agents change repositories and open pull requests, and people review the result. The important qualification is that programming has not disappeared; human effort has shifted toward defining tasks, preparing environments, evaluating changes and deciding what can ship.

Karpathy made the argument on February 25, 2026, describing a sharp improvement in agents’ ability to persist through longer tasks and reporting that one built a video-analysis dashboard for him in about 30 minutes. The Decoder’s February 26 account also records his central caveat: agents still require direction, judgment, taste, oversight and iteration. Five months later, that distinction remains the most useful way to understand the change.

What actually became “unrecognizable”

The break with older coding assistants is not simply that a model can generate larger blocks of source code. An agent can inspect files, run commands, execute tests, observe failures, revise its approach and package its work for review. That loop turns a prompt from a request for text into the starting point of a bounded engineering task.

The developer’s interface consequently moves up a level. Instead of specifying every expression, the person specifies an outcome, supplies repository context and establishes the checks that will distinguish success from a plausible-looking failure. The code remains essential, but it increasingly becomes an intermediate artifact produced and inspected inside a larger process.

This is why “orchestration” is a more precise description than effortless automation. Someone must decide which tasks can run independently, what access each agent receives, which dependencies are trusted and how conflicting changes will be reconciled. Parallel execution creates leverage only when the work has clean boundaries; otherwise, it can produce several incompatible answers faster.

The workflow is now part of mainstream development infrastructure

The strongest update since Karpathy’s original statement is that delegated agent work is no longer confined to a private experiment or a terminal session. GitHub’s current agent documentation says users can assign an issue or prompt to an asynchronous coding agent, which changes the repository, creates a pull request and then requests human review. Agents can be launched from GitHub’s Agents tab, issues, pull requests, mobile interface or Visual Studio Code.

That product design makes the new division of labor visible. The unit handed to an agent is not “write this function” but a repository-level task with an expected deliverable. The handoff back to the human is likewise structured: a pull request, a set of changes and an opportunity to request another iteration.

GitHub also applies code scanning, secret scanning and dependency checks to agent-authored changes. Those controls do not prove that a change is correct, but their presence reveals where the practical bottleneck has moved. When generating another patch is cheap, review capacity, test coverage, security policy and confidence in the specification become more valuable.

Evidence supports adoption, not universal autonomy

Real-world pull requests provide stronger evidence than a single successful dashboard, but they also resist a simple “agents now work” verdict. A 2026 task-stratified study of 7,156 pull requests compared Codex, Copilot, Devin, Cursor and Claude Code. The researchers found that no agent led every task category and that the type of assignment was a major factor in acceptance rates.

Documentation changes were accepted more often than new features in that dataset, illustrating why a single global success rate can mislead. An agent receiving easier or more verifiable work may appear stronger than another handling ambiguous feature development. The authors also warn that repository characteristics and user expertise were not fully controlled, while acceptance itself is not a complete measure of code quality.

That evidence narrows Karpathy’s claim without dismissing it. Coding agents are demonstrably participating in genuine repository workflows, but performance depends on what they are asked to do and how the result is evaluated. “Works” is therefore not a permanent property of an agent; it is an outcome produced by the model, its tools, the task, the repository and the review process together.

The developer’s new work starts before the prompt

A useful agent-ready task has an observable finish line. It identifies the relevant part of the repository, states constraints, names behavior that must remain unchanged and provides commands that can verify the result. “Improve authentication” leaves both scope and success undefined; a bounded request to fix a reproducible session-expiry bug and pass specified tests gives an agent something it can iterate against.

Environment quality matters for the same reason. Reliable setup instructions, deterministic tests, readable logs and repository conventions supply feedback that an agent can act on without guessing. Weak infrastructure does not become harmless when the code is generated more quickly; it deprives both the agent and reviewer of evidence.

Review also changes when agents can produce several substantial patches at once. Reading every line remains possible for small changes, but larger workflows require reviewers to examine architectural fit, test validity, security boundaries and unintended behavior. The scarce skill becomes deciding which evidence is sufficient—not merely detecting whether the code compiles.

What Karpathy’s claim does and does not mean

Karpathy’s observation holds most strongly as a statement about the developer’s control surface. Assigning work, watching multiple executions and reviewing proposed changes is now a supported workflow rather than a speculative interface. For well-scoped, testable tasks, that can reduce the amount of direct code entry required from a human.

It does not establish that syntax knowledge, debugging ability or software design have become irrelevant. Those skills are what let a reviewer recognize a superficially successful patch, diagnose a flawed test or divide a vague project into safe delegations. Agents raise the level at which experienced judgment is applied; they do not supply an independent definition of correctness.

The durable shift, then, is from code production as the center of the job to evidence-driven delegation. Developers increasingly describe outcomes and manage execution, but they remain accountable for the system that emerges. The keyboard may be less central to some tasks; ownership of requirements, risks and final decisions is not.

Also read:

• The Strengths and Limitations of AI Coding Agents: Insights from Codex and Beyond
• Microsoft’s Autonomous Agents Now Have an IT Control Plane
• Grok 4.5: xAI Model for Coding, Agents and Knowledge Work