The Programmers’ Eulogy Is Early Again

Software developers are being told that artificial intelligence will make their profession obsolete, but the strongest evidence points to a different change: AI is reducing the value of unexamined code while increasing the value of judgement, design and verification. Venkat Subramaniam, a programmer and teacher with four decades in the field, says the technology will demand more skill from developers, not less.¹

The Question Arrived Before the Evidence

The question came to Subramaniam in an ordinary setting, from somebody outside the programming world: are you worried about losing your job now that artificial intelligence can write code?

It is the question of the moment, repeated in boardrooms, investment presentations and newspaper headlines. It also assumes its own answer. If software can be described in a prompt, and if a machine can turn that description into executable instructions, why should a company continue to employ the person who used to write the instructions?

Subramaniam’s response is more useful than the familiar assurances that technology will create “new opportunities”. He does not deny that generative AI is remarkable. He says that when he asks it to perform a task outside his experience, he can be astonished by the result. When he asks it to do something he knows well, the defects become obvious.

“With AI, we need more skill, not less skill,” he said in an interview with The Marco Show, produced by JetBrains. The sentence runs counter to the sales pitch without pretending the tool is weak. AI can produce code at a speed no human typist can match. It can draft tests, explain unfamiliar libraries, identify suspicious patterns and assemble a working prototype before a conventional development process has left the planning stage.

But software is not judged by whether a block of text looks plausible on a screen. It is judged by whether the system does what people need, protects information, survives unusual conditions, behaves predictably under pressure and can be maintained by somebody who did not write it. The code is only the visible part. The difficult work is deciding what the code must mean.

A market that prefers simple prophecies is obscuring that distinction. “AI will replace programmers” is easier to sell than “AI will rearrange the division of labour inside software teams”. The first sounds like a revolution. The second sounds like management, training and careful measurement. The first produces excitement. The second describes reality.

The history of software warns against treating a new abstraction as final. Tools have repeatedly removed manual work, and people have repeatedly mistaken that removal for the profession’s disappearance. The forecast fails because programming was never only typing syntax.

A Job Is More Than Code

The word “programmer” hides several different occupations. One person may spend the day writing application code. Another may design the structure of a banking system. A third may investigate why a service fails only under a particular combination of load, data and timing. A fourth may review a proposed change and reject it because it creates a security risk six months from now. All of them may be called developers.

Employers do not buy lines of code for their own sake. They buy software that performs a task reliably. That means somebody must discover the task, separate essential requirements from fashionable requests, identify the people affected by failure, and decide what trade-offs the organisation can tolerate. Someone must choose how data moves through the system, how permissions work, how errors are reported and how the service will be repaired after release.

The U.S. Bureau of Labor Statistics describes software development as a process that includes analysing users’ needs, designing the pieces of an application, planning how those pieces work together, documenting the system, maintaining it and testing it. The same occupational profile distinguishes developers from quality-assurance analysts and testers, whose work includes identifying defects, evaluating risk and reporting problems to developers and stakeholders.²

AI can participate in each of these activities, but participation is not ownership. A model can generate five possible architectures. It cannot bear responsibility for choosing the one that exposes customer records to the wrong service. It can produce a test suite. It cannot decide whether the tests cover the failure that would damage the company’s reputation. It can summarise a codebase. It cannot guarantee that its summary has not quietly omitted the one dependency that makes the system fragile.

This is why Subramaniam draws a line between producing code and evaluating it. He says AI resembles many human developers in one respect: it is less impressive at writing code than at finding problems in code. The machine can be a tireless critic, but criticism has value only when the recipient understands what matters.

A novice often sees successful execution as proof of correctness. An experienced developer asks different questions. What assumptions does this code make? What happens when the input is empty? What happens when two requests arrive at the same time? Does the error message reveal private information? Will the database remain consistent if the process stops halfway through? Is the solution needlessly complex? Can another developer understand it next year?

These are not decorative questions added after the “real” programming. They are the real programming. A system that compiles and passes a narrow demonstration may still be unusable. The more consequential the software, the less adequate a surface inspection becomes.

The result is an uncomfortable inversion. AI lowers the cost of making a first attempt. It does not lower the cost of knowing whether the attempt is good. In some cases it raises that cost by flooding the team with plausible alternatives that must be checked. The bottleneck moves from production to judgement.

COBOL Refused to Die Quietly

The industry has seen this argument before, though the tool names have changed. In the late 1950s, COBOL was promoted as a business language that ordinary organisations could use without depending on a small priesthood of machine specialists. Its English-like structure and portability were meant to make business data processing more accessible.

That ambition did not eliminate programmers. It changed what programmers could build and widened the range of organisations able to use computers for serious administrative work. COBOL became part of the infrastructure of banks, insurers, government departments and large companies. The language outlasted the predictions made about it because the systems built with it became too valuable to discard.

IBM’s account of COBOL records its formation through the Conference on Data Systems Languages in 1959, its first release in 1960 and its later standardisation. The company says COBOL remains present in critical financial and business applications, including systems handling high-volume transactions and large-precision decimal calculations.³

The lesson is not that every old technology is secretly superior. COBOL has limitations, and organisations have spent years trying to modernise or replace parts of their legacy estates. The lesson is that a tool can succeed at its stated purpose without producing the social result its advocates predicted. Making programming more accessible can create more demand for software, not less demand for people who understand it.

Grace Hopper, a central figure in the development of early compilers and programming languages, helped define COBOL as a readable, machine-independent language for business use. The Computer History Museum describes it as probably the most successful programming language for business applications in history.⁴

Each later wave followed a related pattern. Higher-level languages hid machine instructions. Integrated development environments hid the command line. Frameworks hid repetitive infrastructure. Low-code platforms hid more of the implementation. None of these changes made the underlying problems disappear. They shifted where a human had to intervene.

The industry’s recurring mistake is to measure the old job by its most visible manual activity. If developers once spent hours writing boilerplate, then a tool that removes boilerplate appears to remove developers. But a business that can produce one application more cheaply may decide it wants ten applications, better integration, more automation, stronger security and faster changes. It spends the savings on more ambition.

The economy has no fixed quantity of software it needs. Every industry now wants internal tools, customer portals, data pipelines, mobile services, security controls, automated reporting and systems that connect old infrastructure to new products. Some of those projects will be cancelled, some will be built badly and some will be replaced. The appetite keeps moving.

That is why “the end of programmers” has remained a durable headline. It confuses the end of one form of programming with the end of the need to make systems work. The former is a routine development. The latter is a much larger claim, and the record does not support it.

The Machine Can Be Impressive and Wrong

The case for AI coding tools is not imaginary. They are good at tasks with a clear local shape. They can translate a function from one language to another, draft repetitive code, generate a first version of documentation, suggest likely causes of a bug and produce small prototypes. They can help a developer understand a library that would otherwise require hours of searching.

They can also be wrong in hard-to-notice ways. A syntax error is merciful because the machine usually refuses to run the program. A semantic error is more dangerous because the program runs while doing the wrong thing. It might calculate a price incorrectly at the boundary of a discount, authorise the wrong user, mishandle a time zone or silently discard a record.

Generative models are trained to produce a likely continuation, not to assume legal, financial or operational responsibility for the result. Their confidence in a sentence is not evidence that the sentence is true. The same applies to code. A neat function can be built on a false assumption about a library version. A convincing explanation can cite a method that does not exist. A test can confirm the implementation’s preferred behaviour while ignoring the requirement it was supposed to satisfy.

Subramaniam’s prescription is not to ban the machine. It is to constrain it. Give the system a clear specification, define the boundaries, state the existing conventions, describe the performance and security requirements, and ask it to work within those conditions. The constraints are not a minor prompt-writing trick. They come from engineering thought.

An experienced developer also knows when a prompt is underspecified. “Build an online banking feature” is not a specification. Which accounts are involved? What are the authorisation rules? What happens when a transaction is interrupted? How are disputes handled? What is logged? Which regulations apply? What is the recovery plan? How are duplicate requests prevented?

A model can ask some of these questions if instructed. It cannot know which answer the organisation is entitled to choose. That requires conversation with users, lawyers, security specialists, operations teams and people who understand the existing system. Software is embedded in institutions. It inherits their obligations.

The most valuable use of AI may therefore be adversarial. Ask it to look for race conditions, missing validation, insecure defaults, unnecessary complexity or untested assumptions. Ask it to propose counterexamples rather than merely applaud the first design. Use it to produce a prototype that makes an idea concrete enough to reject.

Subramaniam describes doing exactly that. A feature proposal seemed unattractive, but arguing about it in the abstract was inefficient. AI let him build a prototype in minutes. Once the idea could be demonstrated, the reasons for rejecting it were easier to discuss. The machine did not make the design decision. It shortened the path to an informed decision.

That is a more mature account of AI assistance than the claim that a prompt has replaced an engineering team. It treats generated code as a disposable instrument: useful for learning, testing an idea and exposing problems, but not automatically entitled to enter production.

The Trust Gap Is the Point

Developers are adopting AI tools while remaining sceptical about their output. That combination is not evidence of irrational resistance. It is what one would expect from professionals who have to repair the consequences of plausible mistakes.

Stack Overflow’s 2025 Developer Survey, based on responses from more than 49,000 developers, reported that AI use continued to rise while trust in the accuracy of AI output fell. The survey said 80 per cent of developers were using AI tools in their workflows, but only 29 per cent trusted their accuracy. It also reported that 66 per cent were spending more time fixing AI-generated code that was “almost right”, and that 64 per cent did not see AI as a threat to their jobs.⁵

The numbers describe a practical relationship with the technology. Developers are not refusing to use a tool because it is imperfect; almost every software tool is imperfect. They are refusing to confuse convenience with reliability. The machine earns a place in the workflow by saving time after review, not by demanding trust in advance.

The previous year’s survey showed the same pattern in an earlier form. In 2024, 76 per cent of respondents said they were using or planning to use AI tools, while only 43 per cent trusted the accuracy of their output. Forty-five per cent judged the tools bad or very bad at complex tasks, and 70 per cent of professional developers said AI was not a threat to their jobs.⁶

The scepticism matters because software teams do not work on isolated puzzles for long. A developer who asks an AI system to write a small utility may receive a useful answer. A developer working inside a mature codebase must understand conventions that may not be written down, dependencies that behave differently in production and business rules that exist because an earlier failure was expensive.

Context is the scarce resource. The model can process a large amount of text, but supplying the right context remains a human responsibility. Too little context produces generic code. Too much irrelevant context buries the requirement. Incomplete context produces the most dangerous result: a solution that looks tailored while quietly missing the condition that matters.

The trust gap also exposes a weakness in the way companies measure productivity. If a developer accepts a generated function, the dashboard may record speed. If the developer spends two hours finding and correcting the function’s hidden problems, that work may appear as delay. A company that counts keystrokes will conclude that AI is transformative. A company that counts reliable outcomes may reach a more modest conclusion.

Human review is not a ceremonial signature at the end of an automated process. It is the control that makes the process defensible. When the output affects money, safety, privacy or public services, the reviewer needs enough understanding to challenge the machine. That requirement is precisely why technical skill becomes more important as generation becomes cheaper.

Productivity Is Not the Same as Speed

The most seductive claim about AI coding is also the easiest to measure badly: it makes developers faster. A tool can produce more code per hour without helping a team deliver better software. It can increase the number of pull requests while increasing the time spent reviewing them. It can accelerate the first draft and lengthen the repair work.

Research from GitHub has reported strong perceived benefits from AI coding tools. In a 2024 survey of 2,000 people on enterprise software teams in the United States, Brazil, Germany and India, more than 97 per cent said they had used AI coding tools at some point. Respondents said they redirected the time saved toward system design, collaboration, and learning, while many reported perceived gains in code quality and test generation.⁷

Those findings are relevant, but they come from a company that sells one of the leading AI coding products, and they measure what respondents reported. They should be read as evidence of adoption and perceived usefulness, not as a final verdict on productivity.

A more demanding test came from a randomised study by researchers at the Model Evaluation & Threat Research group. The study gave 16 experienced open-source developers 246 real tasks in mature repositories and randomly allowed or disallowed the use of early-2025 AI tools. The researchers reported that developers expected AI to reduce completion time, but that the AI-allowed tasks took longer in the study. They also noted that the participants were experienced contributors working in projects where quality standards and repository context mattered.⁸

That result does not prove that AI always slows software development. It does, however, show that broad productivity claims require care. A bounded coding exercise is not the same as a task inside a large, unfamiliar system. A line of code is not the same as a useful feature. A completed task is not the same as a maintainable change.

The difference between speed and productivity appears in ordinary engineering decisions. A developer may use AI to produce three designs in an afternoon. That is valuable if the designs clarify the choice. It is wasteful if the team now has three poorly understood systems to maintain. A developer may generate a large test suite. That is valuable if the tests express the intended behaviour. It is a liability if they merely reproduce the implementation’s assumptions.

AI may also change what teams attempt. When prototypes are cheap, organisations can investigate more ideas. Some will fail earlier, which is good. Others will survive because a demonstration creates political momentum, even though the underlying design is weak. Faster production can increase the volume of bad ideas as well as good ones.

The real question is not whether AI can produce code faster than a human. It plainly can in many cases. The proper question is whether the complete system—requirements, design, implementation, testing, security review, deployment, monitoring and maintenance—reaches a dependable result with less total effort.

That measurement is harder because it crosses departmental boundaries and extends beyond the launch date. It also captures the value of people who prevent a failure that never appears in a report. The industry likes visible output. Reliability is often invisible until it disappears.

The Apprentice Problem

The most serious challenge AI raises is not the immediate replacement of senior programmers. It is the possibility that organisations will weaken the route by which junior programmers become senior ones.

Subramaniam asks how a beginner develops expertise when a machine is always available to provide the quick answer. The question is not sentimental. Expertise is built through repeated contact with difficulty: tracing a failure, reading documentation that seems incomplete, forming a hypothesis, testing it, discovering that it was wrong and trying again.

That process can be frustrating, but it teaches the difference between a symptom and a cause. It shows why a fix that solves one test can break another. It creates a mental map of how the language, tools and operating environment fit together. A beginner who copies a correct answer may complete the immediate exercise while learning nothing about why the answer is correct.

Subramaniam compares overdependence on AI with overdependence on an integrated development environment. Modern development environments make programmers more productive, but he tells younger developers to learn how to run a program from the command line rather than allowing the interface to hide how the pieces connect. His point is not that old tools are morally superior. It is that convenience can conceal structure.

The same principle applies to AI. A junior developer should be allowed to use it, but not allowed to outsource understanding. The developer should attempt a solution, explain the problem, inspect the generated code line by line, test the edge cases and be able to reproduce the reasoning without the model. AI should function as a tutor, critic or pair of extra hands, not as an invisible author whose work cannot be defended.

Education faces the same choice. If students are assessed only on an answer, a chatbot can produce the answer. If they are assessed on the development of a solution, the evidence changes: design notes, failed attempts, test choices, explanations, revisions and oral defence. The point is not to preserve artificial hardship. It is to ensure that the learner acquires the capacity that will be needed when the generated answer fails.

There is also a management problem. Companies have spent years treating junior roles as expendable while expecting experienced staff to appear fully formed. If AI removes every entry-level task, the organisation may gain short-term output and lose its future talent pipeline. Senior engineers do not reproduce themselves through job titles. They are formed by doing real work under supervision.

This does not mean juniors should be protected from automation. It means their work must be redesigned. They can own small systems, write tests, investigate incidents, document decisions, compare model outputs and review changes with experienced colleagues. The learning objective must be made explicit. “The AI wrote it” is not a career path.

The people most likely to benefit from AI are those who have enough knowledge to interrogate it. That creates a risk of widening the gap between workers who already possess technical foundations and workers who were promised that foundations were no longer necessary. The tool can compress some differences in output. It can also magnify differences in judgement.

What Organisations Will Get Wrong

Executives are attracted to AI coding because it appears to convert a costly specialist activity into a general business capability. If anyone can describe a feature and receive an application, the company can imagine removing queues, shrinking teams and bypassing the slow negotiations that usually accompany software projects.

That vision confuses demo production with service operation. A demonstration can tolerate hard-coded data, weak permissions and a missing recovery path. A live system cannot. A company that lets employees build applications without common rules may create a private collection of unmaintainable systems, each with unknown dependencies and uncertain ownership.

Governance is therefore not an obstacle added by cautious people after innovation has begun. It is how an organisation knows what it has built. Teams need policies for confidential data, model access, code licensing, testing, security review, dependency management and accountability. They need to know which systems may use AI-generated code and which require additional approval.

The constraints that Subramaniam says improve AI output must exist at the organisational level as well as inside an individual prompt. A model needs a specification. A team needs an architecture. An architecture needs a reason. Without those layers, the machine will faithfully accelerate confusion.

There is a temptation to respond to a new tool by imposing a single company-wide instruction: use AI everywhere. That is not a strategy. AI may be excellent for drafting documentation and weak for changing a payment ledger. It may help analyse logs while creating unacceptable privacy risks if the logs contain customer data. The relevant question is not whether AI is fashionable. It is where the risk-adjusted benefit is real.

Companies must also stop treating review as an unproductive cost. If generated code enters a system faster than experts can understand it, the company has not created productivity. It has borrowed against future maintenance. The interest arrives as technical debt, security incidents, slower releases and a workforce that no longer knows why the system behaves as it does.

The Bureau of Labor Statistics projects that employment of software developers, quality-assurance analysts and testers in the United States will grow 15 per cent from 2024 to 2034, with about 129,200 openings a year across the combined occupation. The agency links demand to software for artificial intelligence, connected devices, robotics, automation and cybersecurity.⁹

Those projections do not guarantee work for every worker or every specialism. Entry-level hiring can weaken even while total demand remains strong. Some tasks will disappear. Some roles will be combined. Salaries and bargaining power may change. A profession can expand while particular people are displaced.

That is the honest version of the forecast. AI may reduce the number of people needed for a narrow category of routine programming. It may also increase the value of people who can connect software to a difficult organisation, a complex customer need or a high-consequence operating environment. The aggregate number does not remove the obligation to understand who bears the cost of transition.

The Economics of More Software

The replacement story assumes that demand for software is fixed. Once the machine makes each application cheaper, the company buys the same amount of software with fewer programmers. That would be plausible if software were a finished commodity, like a fixed quantity of office furniture.

It is not. Software changes the possibilities available to an organisation. A cheaper prototype makes it sensible to test ideas that would previously have been rejected. A better integration layer makes a new service possible. A stronger security tool permits a company to bring a process online. Lower project costs can expand the number of projects considered worthwhile.

This is why older abstractions did not simply empty the profession. They made more ambitious systems feasible. They also created new failure modes. A business that can automate a process must decide which exceptions deserve human attention. A company that connects more systems creates more points at which data can be lost or misinterpreted. Greater capability enlarges the field of responsibility.

AI coding tools will probably make some forms of software abundant. Small internal dashboards, simple web interfaces and routine data transformations may become inexpensive enough for non-specialists to commission. That is not the end of programming. It is a market shift for programming, with consequences for quality and ownership.

When barriers fall, more people enter the field. Some produce useful tools. Some produce brittle ones. The resulting demand is not only for authors but for maintainers, auditors, security specialists, infrastructure engineers and people who can rescue a system built by someone who did not understand its foundations.

The phrase “anyone can code now” should therefore be treated with the same suspicion as “anyone can build a house now because power tools exist”. A power tool expands what a skilled builder can do. It also lets an inexperienced person build a dangerous structure more quickly. The tool is not the building inspector.

There will be real layoffs. A company can use a productivity tool to reduce headcount even when the economy as a whole creates new technical work. Managers do not always reinvest savings in better systems; sometimes they keep the savings. Workers are right to worry about how the gains are distributed.

But layoffs are not evidence that the underlying profession has become unnecessary. They may show that employers are changing the mix of skills they will pay for. A worker who only offers routine implementation faces pressure. A worker who can frame a problem, assess a design, explain risk and keep a system operating remains attached to the part of the work that cannot be safely delegated.

The economic question is not whether AI will make code cheaper. It will. The question is whether the value of dependable software, clear decisions and accountable maintenance will fall at the same rate. There is little evidence that it will.

The New Definition of Programmer

The programmer of the next decade may write less code by hand. That is not a scandal. Much of the code developers write today is repetitive, and many developers would gladly spend less time typing instructions that a tool can produce accurately.

The change becomes dangerous only when the industry mistakes less typing for less thinking. A developer who directs an AI agent must still decide what the agent is allowed to change, what evidence is required before accepting the change and how the result will be monitored in production. The job becomes closer to directing a small, fast and unreliable team member. Speed does not remove the need for management.

That new role contains several forms of expertise. There is specification: stating the desired behaviour with enough precision to expose ambiguity. There is architecture: deciding how the parts should fit and what must remain stable. There is verification: proving that the result meets the requirement and does not create a new problem. There is operational knowledge: understanding what happens after deployment, when real users behave in ways nobody predicted.

There is also taste. Good engineers recognise unnecessary complexity. They know when a simple solution is adequate and when a simple-looking solution is merely hiding a difficult problem. They can compare two designs not only by whether they work today but by how much freedom they leave the team tomorrow.

Subramaniam says the part of software development he enjoys is problem-solving, design thinking, criticism and evolution, not the typing itself. AI can remove manual effort from the work he dislikes while leaving the work he values. That is not an argument for complacency. It argues for measuring the profession by its proper substance.

The historical record does not show a machine arriving, taking the whole job and leaving nothing behind. It shows tools absorbing routine tasks, followed by a larger field of activity around the systems those tools make possible. The people who adapt are not necessarily the fastest typists. They are the ones who understand consequences.

So will AI replace programmers? It will replace some programming tasks, weaken some career ladders and give employers a reason to demand more output from fewer people. It will expose workers whose only advantage was producing familiar syntax. It will also create more software, more integration and more systems that need to be understood.

The serious prediction is narrower and less theatrical. AI will make code generation ordinary and judgement scarce. It will reward programmers who can specify, constrain, test, critique and maintain. The programmer’s future will not be secured by refusing the machine. It will be secured by knowing when the machine is wrong.

1. Venkat Subramaniam interview, The Better You Are at Programming, the Worse AI Looks, The Marco Show, JetBrains. https://youtu.be/_590TxMwvWM ↩
2. U.S. Bureau of Labor Statistics, Software Developers, Quality Assurance Analysts, and Testers. https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm ↩
3. IBM, What Is COBOL? https://www.ibm.com/think/topics/cobol ↩
4. Computer History Museum, Grace Murray Hopper. https://computerhistory.org/profile/grace-murray-hopper ↩
5. Erin Yepis, Stack Overflow, Developers remain willing but reluctant to use AI: The 2025 Developer Survey results are here. https://stackoverflow.blog/2025/12/29/developers-remain-willing-but-reluctant-to-use-ai-the-2025-developer-survey-results-are-here ↩
6. Erin Yepis, Stack Overflow, Developers want more, more, more: the 2024 results from Stack Overflow’s Annual Developer Survey. https://stackoverflow.blog/2024/01/01/developers-want-more-more-more-the-2024-results-from-stack-overflow-s-annual-developer-survey ↩
7. Kyle Daigle and GitHub Staff, Survey: The AI wave continues to grow on software development teams. https://github.blog/news-insights/research/survey-ai-wave-grows ↩
8. Joel Becker, Nate Rush, Beth Barnes and David Rein, Model Evaluation & Threat Research, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. https://arxiv.org/html/2507.09089 ↩
9. U.S. Bureau of Labor Statistics, Software Developers, Quality Assurance Analysts, and Testers, employment projections and occupational outlook. https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm ↩