I work with AI every day, and my experience of the last six to twelve months is straightforward: the tools are getting more useful, and the efficiency gains are arriving quickly. Calling this a plateau does not describe the work in front of me.
I see little reason to declare that we have reached the peak of what AI can do for software development. That is a judgment about the direction of progress, not a promise that every release will be better at every task.
The more interesting question is why progress can continue even when one approach becomes harder to improve. Better models, better training, better tools and better engineering workflows can reinforce one another. Looking at only one of those pieces gives us an incomplete picture.
The scaling debate became too narrow
There is a substantial difference between saying that a particular training recipe faces diminishing returns and saying that AI is running out of useful progress.
Pre-training builds a model's capabilities from large amounts of data. Post-training further shapes those capabilities and behaviors. Inference-time computation concerns the work a system does while producing an answer or attempting a task. Improvements can happen in each area, as well as in the software surrounding the model.
A limit in one area does not establish a limit for the whole system. It may change where the next useful investment belongs.
This is familiar territory in engineering. When one component becomes the bottleneck, you investigate the architecture, the algorithm, the data flow or the operating process. You do not automatically conclude that the product has reached its final form.
I think some of the public conversation turned a debate about the next source of improvement into a much larger claim about whether improvement was ending. Those are different arguments, and they deserve different evidence.
What Sutskever and LeCun actually argued
In November 2025, I published an article examining Ilya Sutskever, Yann LeCun and the limits of simply adding more GPUs. Almost a year later, I think the subject deserves another look.
In his November 2025 conversation with Dwarkesh Patel, Sutskever described a transition from an age dominated by scaling to one requiring more research. He questioned whether making the existing approach vastly larger would deliver the transformation people expected. He also explicitly discussed the shift from scaling pre-training to scaling reinforcement learning.
It would be inaccurate to turn that into a prediction that AI could no longer improve. His argument leaves room for new methods and more productive uses of computation.
LeCun's position addresses a deeper question: whether current approaches provide the ingredients for human-level intelligence. His emphasis on world models, abstraction and planning concerns what systems need to understand and act in the world.
A better coding assistant cannot, by itself, settle that dispute. A system can become much more useful for software engineering while still lacking capabilities a researcher considers necessary for human-level intelligence.
I am comfortable challenging the idea of a broad AI plateau. I would be less comfortable claiming that improved coding has disproved either researcher's entire position.
Hassabis describes a more convincing combination
The approach Demis Hassabis described in his conversation with Lex Fridman makes sense to me. He discussed room for improvement in pre-training, post-training and inference-time computation, while also pursuing new research ideas. He presented scaling and scientific innovation as work that could proceed together.
That is a stronger framework than treating them as competing identities. A research breakthrough can create a more effective method to scale. More computation can make a previously impractical method usable. Better engineering can turn a research result into something people can operate.
None of those relationships guarantees unlimited progress. They do explain why difficulty in one area is insufficient evidence for declaring a ceiling across all of AI.
My interest as an engineer is in the useful result of that combination. I care whether the system can understand a task, act on relevant information, check its work and produce something worth keeping.
The model is only part of the coding system
When people discuss AI coding, they sometimes talk as though the product is just a model generating text. In practice, the surrounding system can determine whether that text becomes working software.
An agent may need repository search, a terminal, documentation, a browser, test results and a dependable record of what it has already attempted. It needs a way to recover after an interruption and boundaries around consequential actions.
These are engineering concerns with direct effects on usefulness.
Anthropic's March 2026 work on long-running application development described a structure involving planning, generation and evaluation, with explicit handoffs between sessions. Its reported experiments illustrate how the design around a model can affect the work it completes. They do not establish a universal productivity gain for every development team.
OpenAI's April 2026 Codex update similarly expanded the product around the model, including browser interaction, tools and development workflows. An expanded feature set is not a controlled productivity result, but it shows why evaluating the model alone misses part of what developers use.
OpenAI, Anthropic, Google and xAI should be evaluated through the work their systems can support. A leaderboard is one input, alongside tool integration, operating constraints and real task performance. The useful question is which combination of capabilities, tools, reliability and cost fits the task.
Why several modest gains can create a substantial change
Consider a hypothetical development task: add a customer-facing feature to an existing application.
The system must locate the relevant code, understand the conventions, make compatible changes, run appropriate checks and explain what remains uncertain. Producing the first implementation is only part of the job.
Better repository navigation can reduce time spent in irrelevant files. Better reasoning can reduce incorrect changes. Better tool use can help the agent obtain evidence instead of guessing. Better state management can keep it from repeating work after a session ends.
If these improvements happen together, their combined effect can be larger than the impression left by any one feature announcement. A task that previously required constant intervention may become practical to delegate within a clear boundary.
There is also a threshold effect. An assistant that needs correction at nearly every step can cost more attention than it saves. Reducing those interruptions can change whether using it is worthwhile, even if no single benchmark score looks dramatic.
The engineer is learning too. Clearer task boundaries, better acceptance criteria and more disciplined review can improve the result obtained from the same model. Comparing an inexperienced workflow with a mature one measures more than model progress.
I think this combination helps explain why the change can feel so fast in daily work. Capability, tooling and the person operating the system are developing together.
Exponential growth needs a defined measurement
The word exponential is tempting because it captures how the progress feels. But a persuasive argument needs to say what is growing and how it is measured.
METR has reported exponential trends in the human-equivalent duration of tasks AI agents can complete at specified success rates. That is relevant evidence for increasing software-task capability. Its time-horizon dashboard was last updated in September 2026, and the organization says it is no longer actively maintained.
Those tasks are deliberately defined and assessable. Their results cannot be translated directly into an exponential increase in an engineer's output or an agent's ability to take over a job. Professional work includes context, negotiation, ambiguous requirements and consequences that a task suite cannot fully represent.
The productivity evidence also deserves care. In February 2026, METR reported that selection effects and difficulties measuring concurrent agent work made its newer developer experiment unreliable for estimating the current productivity effect. Its observations suggested improvement, but did not establish a dependable general speedup.
My own experience supports a claim about my own working efficiency. It does not justify assigning a universal multiplier to programmers. We can take rapid progress seriously while being precise about the evidence.
The limit moves toward judgment and verification
Faster implementation makes the surrounding engineering decisions more consequential. Generating a feature quickly is valuable when the feature is appropriate, the changes are understandable and the result behaves correctly.
A system can produce a convincing interface while mishandling access permissions. It can pass a narrow test while breaking an integration. It can remove an error message without repairing the underlying failure.
These are possibilities to investigate, not reasons to dismiss the technology. They are reasons to decide what evidence is required before accepting its work.
I want tests that exercise meaningful behavior, reviews that examine consequential changes and a deployment process that can recover from mistakes. The person responsible for the software still needs to understand the commitments being made.
As implementation accelerates, review capacity can become the bottleneck. Starting more agents is useful only when the work can be separated and the results can be integrated and checked. Otherwise, parallel generation can become a queue of unresolved changes.
The discipline required to use AI well is part of software engineering. It deserves investment alongside the tools.
What businesses should reconsider
For a business owner, this debate has a practical consequence: a technical judgment made a year ago may deserve another evaluation.
A task that was too unreliable, expensive or awkward to automate could become viable as the surrounding system improves. That possibility should lead to a focused test, with a baseline and acceptance criteria.
Choose a bounded workflow. Define an acceptable result, the cost of a mistake, the review effort and the person responsible for operating it. Compare the complete process, including correction and maintenance, with the existing approach.
For software teams, measure useful changes reaching production, the effort needed to review them and the defects that follow. Code volume alone is a poor business outcome. A larger pile of changes can represent progress, rework or both.
I would also preserve room to change models and tools where it is economically sensible. A product should not depend unnecessarily on one model's quirks. Clear interfaces and evaluations make it easier to judge whether a new option actually improves the work.
The opportunity is to revisit assumptions with evidence, then adopt the improvements that survive that test.
What would convince me that progress was slowing?
A serious opinion needs conditions under which it could change.
I would pay attention if successive systems stopped improving on comparable, representative tasks. I would look closely if apparent speed gains consistently disappeared after accounting for review, defects, cost and maintenance. I would question the practical value of longer delegation if failures became harder to detect than the work was worth.
Conversely, I would count more dependable task completion, lower correction effort and improved economics as meaningful progress, even when those gains came from engineering around a model rather than a dramatic architectural breakthrough.
This requires comparing systems under stated conditions. Versions, tools, permissions, task context and evaluation criteria matter. A disappointing attempt with one configuration cannot settle the direction of the field, just as one impressive demonstration cannot establish universal success.
I want that standard applied to optimistic claims and plateau claims alike.
I do not think we have seen the peak
My view is that practical AI for software development still has substantial room to improve. I cannot tell you the date of its eventual limit, or promise that the next release will make every part of engineering easier.
What I can say is that the progress I experience in daily work does not resemble a technology that has finished developing. The combination of improving capabilities, tools and working methods is still changing what seems practical.
Research on new approaches belongs in that story. So does continued work on existing approaches. So does the engineering required to make either useful.
We should be specific about which limitation we are discussing and what would overcome it. Declaring that all of AI has hit a wall requires much stronger evidence than showing that one route has become more difficult.
I intend to keep testing what these systems can do, measuring the work they save and taking responsibility for the software that results. That is how I will judge the next stage of progress.
Frequently asked questions
Does better AI coding prove that scaling alone will produce AGI?
No. Coding performance and the requirements for human-level intelligence are different questions. Useful progress can continue while fundamental research problems remain unresolved.
Is programmer productivity growing exponentially?
There is no established universal rate. An exponential trend in a defined capability benchmark does not directly measure complete engineering productivity. Review effort, reliability, cost and the kind of work all affect the outcome.
Why do better tools matter if the underlying model is unchanged?
Tools can supply context, execute checks and preserve progress. These capabilities change what a model can accomplish within a workflow, although their value still needs to be tested on the intended task.
Does AI make experienced engineers less important?
It changes how engineering time is spent. Requirements, architecture, security, integration and verification still need responsible judgment. Faster implementation increases the value of directing that work well.
Should a company wait for the technology to mature?
Evaluate a bounded use case when there is a plausible benefit and an acceptable operating model. Adopt it if the complete workflow meets your requirements; keep watching areas where the evidence is still insufficient.