AWS CEO’s Two-Year Coding Prediction Fell Short—Developers Still Own the Work
AWS CEO Matt Garman has revisited his June 2024 prediction that most developers might stop coding within roughly two years. In a June 2026 Platformer interview, he judged Amazon to be close and moving in the predicted direction, but acknowledged that the company had not reached that state exactly.
The crucial distinction is between developers writing less code manually and software development no longer requiring people. TheStreet’s August 2024 account records both the approximate two-year estimate and the original emphasis on understanding customer needs and deciding what product to build.
What the original prediction covered
The leaked remarks did not describe a plan to eliminate software-engineering positions. They treated direct code authorship as one part of a broader job and proposed that AI could absorb enough implementation work to make coding a smaller share of developers’ time.
The uncertainty built into the prediction matters. The two-year period was presented as an estimate, not a deadline, while the outcome was framed as a possibility rather than a commitment or staffing decision. Turning “most developers are not coding” into “human developers will disappear” therefore changes both the scope and certainty of the claim.
Even the narrower forecast had substantial consequences. When agents can generate implementations, tests and routine corrections, the same project may require fewer hours of manual programming. That can alter team composition, junior assignments and hiring criteria without making architecture, product judgment or operational responsibility disappear.
The two-year result: movement without completion
At Amazon, manual authorship and troubleshooting of individual lines of Java had become much less common by the end of the forecast window. Some categories of code were still produced mainly by people, however, and the company remained far from a system that could recreate a large cloud service from a short instruction.
This boundary explains why reduced coding is not equivalent to autonomous software development. Mature services contain architectural constraints, dependencies, security requirements and operational history that an agent must be given or helped to recover. Engineers still need to understand how the system fits together so they can direct the work, recognize when an agent is stuck and reject an unsuitable result.
AI-native teams were also finding that automation shifts effort rather than removing every bottleneck. Less time could go into code production while more time went into product definition and supervising deployments, where the surrounding toolchain had not advanced as quickly. The development lifecycle was being compressed unevenly, with implementation moving faster than every process around it.
AWS’s own model preserves human authority
The company’s formal methodology makes the human role more explicit than the original leaked remarks did. AWS’s May 2026 AI-DLC description places agents across planning, code generation, testing and infrastructure configuration while requiring people to verify and approve work before execution proceeds.
Under that model, developers establish requirements and context, review generated code, validate security and resilience tests, refine defects and maintain traceability between business intent and production changes. Humans retain oversight, decision-making authority and accountability, especially where reliability, regulation or financial risk makes unexplained output unacceptable.
The job shifts from continuous code production toward continuous technical judgment. Reading unfamiliar output, identifying architectural conflicts, designing meaningful tests and spotting missing requirements become more valuable when agents can produce code faster than a team can safely evaluate it. A developer who cannot assess generated work is not equipped to approve it merely because the initial implementation arrived quickly.
Why this remains a workforce issue
Human approval does not guarantee that employment will remain unchanged. Higher output per engineer could allow an organization to build more products, deliver existing work sooner or operate with a smaller team. The result depends on customer demand, budgets and management choices; faster software production alone does not establish which outcome will dominate.
Entry-level work may face a particularly difficult redesign. Routine implementation, test creation and bug triage have traditionally helped less-experienced engineers learn a codebase and develop operational judgment. If agents absorb much of that work, employers need another path for junior staff to acquire the system knowledge required to review increasingly large volumes of generated output.
The same shift changes what employers can reasonably measure. Lines of code and time spent typing become weaker indicators when an agent performs much of the production. Requirement quality, review accuracy, failure detection, architectural decisions and production outcomes offer a closer view of the human contribution, although each remains dependent on the project and operating environment.
What the prediction ultimately got right
The two-year forecast did not end with human developers becoming obsolete. Its stronger insight was that software development and manual coding were beginning to separate: agents could perform more implementation while people concentrated on product intent, architecture, validation and operations.
That change is significant but narrower than the original headline suggested. Developers may spend fewer hours authoring syntax and more hours directing agents, resolving ambiguity and accepting responsibility for deployed systems. The work is changing quickly; the available evidence does not show that human engineering judgment has become optional.
Also read:
Subscribe to our newsletter
Get the latest Web3, AI, and crypto news delivered straight to your inbox.