プログラマーの仕事がAIに代替される可能性：過去と未来の交差点

It is possible​ that the first profession to be replaced by artificial intelligence will be that of computer programmer. As large language models become more powerful, there are concerns about their possible impact on jobs in fields such as medicine, law and banking, but these are still conversations about possibilities. The situation in programming is different: the technology works, and the jobs are disappearing. The change is happening at speed and has implications not just for those working in software development but for the wider economy and the security of computer systems everywhere.It is around fifty years since I first saw a computer program. It was half-term and, too young to be left to my own devices, I was taken to the university where my father worked and allowed to play a computer game. This was the 1970s, barely twenty years after the creation of the first functioning programming languages. The game, Star Trek, was played on terminals without screens; the relative positions of the USS Enterprise and the Klingon ships could be seen only on a map created from ASCII characters and sent to a line printer. After I had been playing for a while, someone showed me the source code and let me tinker with it. It was written in BASIC, a language designed to make it easy for non-specialists to create programs and where children of my generation usually encountered computer code. The program stored a representation of the player’s surroundings and the state of the Enterprise, and waited for the user to enter commands: return information, fire a weapon, move the ship. The aim was to kill the Klingons without the Enterprise running out of energy or the player running out of time. I don’t remember the details of what I changed, but I remember feeling hugely proud when I saw the results. That said, when we got a PC at home, I mainly played games rather than wrote them. Pac-Man was a favourite. I learned the programming language FORTRAN as an undergraduate, but it was only a little later, after I became interested in AI and started writing more complex programs, that I began to enjoy coding.The lab where I did my PhD in the 1990s used a logic-based AI language called PROLOG to create a simple model of decision-making. The kernel of it was a small but elegant program that exploited PROLOG’s ability to create a solution from a specification of the constraints any solution must satisfy. My task was to extend the model to allow evidence to be extracted from X-rays so that it could be applied to interpret mammograms. At the time the computational demands of processing images meant that sections of the code had to be written in C, a language that made more careful use of memory than PROLOG.Writing a C program requires the programmer to declare what type of value (an integer, a floating point number, a string of alphanumeric characters) will be stored in each variable, so that the computer knows how much memory to allocate for it. Including an asterisk tells the computer that, rather than store a variable, it should store a ‘pointer’ to a variable, essentially the address of the variable in the computer’s memory. In a particularly opaque construction, beloved of my immediate predecessor in the lab, adding a second asterisk tells the computer that a pointer to a pointer is required. The program I created from his code contained nested loops in which simple arithmetic operations added increments to a matrix of pointers, moving them across the rows and down the columns of an image. Interleaved with these commands, calculations performed on the pixel values identified by the pointers gradually created a new image mapping the features it found. It is probably more than twenty years since I looked at a C program, but I think I would still be able to make sense of the code. That said, C was always easier to write than to read; one of the first C programs to be widely circulated, a section of the Unix operating system, included the comment: ‘You are not expected to understand this.’Very little now takes me out of myself the way that writing these programs did. It’s hard to describe that state, in which the inner voices are completely silent, you are oblivious to the passage of time and so focused on the intricacies of your construction that even after stopping you can’t immediately respond to your surroundings. Writing software is a craft, like carpentry. For most of the time it has existed it has seemed to be very much of the future, and it’s strange to think of it as becoming something of the past, made redundant by the craftsmanship of other programmers. But we are approaching that point.By the time I came to have PhD students of my own, the diffuse networks of collaboration enabled by the internet meant that instead of building on the work of one or two predecessors, they had access to libraries of open-source software addressing specialised tasks. New programming languages – C++, Java, Python – emerged, along with new tools to help programmers use them. Programs were created not using simple text editors but with IDEs – integrated development environments. The bulk of the screen space in an IDE is given over to an edit window where the code is written, with the assistance of increasingly intelligent tools analogous to the grammar checkers that run in the background when you use a word processor. At their worst, early versions resembled Clippy, Microsoft’s notoriously intrusive Office assistant, and it is only recently that people have begun to rely on them. Another window contains a terminal for the user to type instructions, telling the operating system to copy files, install libraries and run versions of the program under development. IDEs now also have a window that allows you to have a dialogue with an AI chatbot and get its suggestions on how to write the program or fix an error preventing its execution.A little more than a year ago Anthropic released a program called Claude Code, which runs in a window on your screen. It feels old school: there’s no graphical interface, just a prompt. At first you aren’t really sure what to do; there are no visual clues. You just type instructions in English at the prompt. It’s nothing like using an IDE. Nor is it like an AI chatbot: it doesn’t just generate replies but actually does things. It will download files, run programs, create code, rearrange existing libraries of software, maintain a repository of programs. It does so based not only on the content of your prompt, but on its analysis of any existing code you share with it, research it does online and knowledge it possesses about how to perform certain tasks. One crucial difference between Claude Code and an AI-assisted IDE is that Claude will test code that it writes or changes it suggests and can fix bugs without the need for oversight.When I started thinking about writing this piece, I wanted to remind myself how the Star Trek program worked. It was a well-known game and, inevitably, there is a Wikipedia page devoted to it, but none of the links took me immediately to code I could run. I asked Claude to find a version that would run on my laptop. It replied: ‘I can’t fetch the original source directly due to network restrictions. However, I know this game extremely well – it’s one of the most documented BASIC programs in history, and I can write a faithful Python port from the well-known STTR1 source. Let me build it now.’The game, 861 lines of Python code reproducing the 1972 version of the game – STTR1 – ran immediately. It was harder to play than I remembered. I asked Claude to add a graphical interface, which helped, and then a command that would ask an LLM to provide tactical advice, which felt weirdly anachronistic; I don’t think Captain Kirk had access to AI. That said, the advice wasn’t reliable: Claude was better at generating the code to run the game than it was at the simple arithmetic required to play it. I also asked Claude to implement Pac-Man, and it took just a couple of minutes to generate the code. Playing it was less fun than I remembered, but it was without a doubt authentic Pac-Man. The marvel here isn’t having access to the game – there are plenty of versions online – but seeing it created instantly ex nihilo. Out of curiosity, I asked Claude how hard it would be to write a version of Mario Kart. It proposed to start with what software engineers call an MVP or ‘minimal viable product’, which turned out to be awful: clunky controls moved a red trapezium around a ridiculously short circular track. Seven or eight iterations later, we arrived at a game which, though still a little ropey, was playable.Social media is awash with implausible accounts of people creating supposedly lucrative web apps by this kind of ‘vibe coding’ in the time it takes for a cup of coffee to cool. It’s certainly easy to generate simple programs (Star Trek) or well-specified programs that are frequently found in language models’ training data (Pac-Man), but it still isn’t clear exactly how far an untutored user can go. I am conscious that my attempt to program Mario Kart would have worked better if my instructions had been based on an understanding of computer graphics or game design. The fervent hope of my colleagues who teach programming is that the effective use of AI requires an understanding of how to write code in the traditional way. I suspect it also requires new skills, and an understanding of what the tools can do and of the digital world in which they are enmeshed.Claude Code didn’t take off at first, but when it did its success was dramatic. Anthropic’s annual recurring revenue grew from $9 billion in December 2025 to $19 billion in March. In February it was reported that 4 per cent of the code uploaded to GitHub, the world’s largest software sharing platform, was created by Claude Code; the number of uploads had more than doubled in January. The graph will, I expect, still be climbing at the same rate, or possibly accelerating. Remember this isn’t code written with the assistance of Claude – this is code written by Claude, and Claude is just one of the available tools. Cursor, the first IDE created expressly to exploit the potential of AI, is only four years old; the brainchild of the (now) 25-year-old MIT graduate Michael Truell, it was valued at $29 billion last November. This month, it announced that the next version, Cursor 3, would not have an edit window at the centre of its user interface. It would no longer be a tool to help programmers write software, but one they could use to oversee the creation of software by AI agents.I probably haven’t written a line of code for more than eighteen months. I don’t think I’ll ever write a program again. That isn’t quite the statement it might appear, since creating software isn’t a large part of my job as a university professor, but many people who do write a lot of code say the same thing. The CEO of Spotify has said that, since December last year, none of its senior developers have had to write any code themselves. One of our former students who now works for Google recently told a colleague that all the code coming out of their team is written by AI. In January a spokesman for Anthropic said that the proportion of AI-generated code in their own products is between 70 and 90 per cent. Not only is Claude Code entirely written by Claude Code, but it monitors feedback and bug reports from users and plans its future development accordingly.It shouldn’t be surprising that the mechanism that large language models use to generate long passages of fluent English can also generate computer code, a much more constrained and predictable form of writing. The criteria to use in training the models – does the code run, does it generate the correct result? – are also clearer for computer code than in more general applications. The ubiquity of websites like GitHub means that an enormous volume of code is available online to train models. This is also a sector that AI companies understand supremely well – it is the essence of what they do. Nevertheless, the quality of generated code isn’t always good, and sceptical voices argue the technology is overhyped. A key concept in software engineering is ‘technical debt’, a term that refers to the costs that will be incurred in the future as a result of decisions made today, and there are good reasons to believe that the adoption of AI tools may be creating code that is harder to maintain and more likely to go wrong.Software engineering isn’t just about writing code. Over its complete lifespan much more time will be spent on debugging, updating and maintaining the code than was spent on its original creation, and these tasks may be less easily addressed by large language models. Last month a team at the Chinese software giant Alibaba compared eighteen different large language models on their ability to maintain software over time. They found their performance was poor but newer models were improving, with Opus 4.6, the latest version of the model underpinning Claude Code, twice as good as its nearest rival. Even that, however, introduced errors in a quarter of the simulations. A survey of 211 million lines of code by the technology platform GitClear reveals that poor coding practices are becoming more common, suggesting the use of AI is encouraging a proliferation of quick fixes rather than incremental improvements in an application’s overall design.One argument in the academic literature is that software engineers are shifting from producing code to monitoring the production of code, with consequences familiar from other industries that have seen wholesale automation. It’s hard to be fully engaged in a task when your role is essentially passive, and this leads to errors. The programmer, on this model, is like a pilot, required to remain vigilant even though the plane can, in most situations, fly itself. There is some truth to this, but it doesn’t feel quite right. Psychologists make a distinction between cognition, trying to solve a problem, and metacognition, thinking about how you are trying to solve the problem. When you are engaged in anything intellectually challenging you are generally switching between the two modes, checking whether you are on the right track or should be looking at the problem differently. Creating software using AI feels like pure metacognition: most of your time is spent worrying about whether you’ve found the best way of thinking about the problem, what’s the next step, how best to make use of the agent’s capabilities. Boris Cherny, the creator of Claude Code, describes the shift as like moving from playing an instrument to conducting an orchestra.One of the most widely quoted principles in software engineering is that of the ‘mythical man month’: the point is that adding team members to a project increases the amount of communication and co-ordination required and makes everyone slightly less efficient. Many companies seem to be reasoning that the best way to exploit AI is to rely on smaller teams of more productive senior employees and let junior staff go, or at least halt recruitment. According to ITJobsWatch there were 5698 permanent jobs advertised citing ‘software engineering’ in the six months to 21 April 2026, down from 10,858 for the same period two years ago. It’s hard to predict where we will be in two years’ time. Many analogue professions have been rendered redundant by technical change, but it’s still hard to comprehend that something as central as programming to the digital revolution that made so many of those jobs obsolete could itself be consigned to history.Anthropic released Opus 4.6 in February. One result was a spectacular collapse in the share price of firms that make their income by licensing software to business customers: these shares are down by an average of 30 per cent, reflecting a perception that their principal assets might now be the kind of thing that an AI-savvy competitor could knock up overnight or that their customers could create bespoke versions of themselves. Atlassian, for example, makes project management tools, so, it could be argued, is in the business of selling services that may no longer be needed to customers who may be about to disappear. At the start of the year its shares were worth $155; on 10 April they hit a low of $56.Software companies became a popular investment for private equity funds in the years after the financial crash. According to the Financial Times, takeovers of software firms accounted for 40 per cent of private equity deals over the last decade, in a sector that is now worth trillions of dollars. From the perspective of investors, ‘software as a service’ companies have two attractive properties: the first is that once the software exists, the overheads and marginal costs involved in licensing it are modest, so sales translate directly into profits; the second is that many customers are so dependent on the software that cancelling their licence agreements is the last thing they will do. As these advantages became better understood, money flooded into the sector, much of it borrowed on assumptions about company profits that have turned out to be optimistic. The panic generated by Opus 4.6 has only made things worse. One leading private credit firm, Blue Owl, has restricted withdrawals from its tech fund as investors have sought to redeem $1.2 billion in assets. Many of these investors are pension funds.The situation​ was already difficult enough when, on 7 April, Anthropic announced it had developed a new model, Mythos. In many ways Mythos is only an incremental improvement on previous models, but its abilities in coding, reasoning and autonomy are significantly greater. It is incredibly good at finding weaknesses in existing software systems and alarmingly adept at devising ways to exploit them. The engineers testing it were able to find thousands of security vulnerabilities, with some discovered in almost every operating system and web browser on the planet.Many of the bugs found by Mythos relate to the use of pointers, since a pointer refers not to something created by the programmer but to an actual location in the computer’s physical memory. It is as if, instead of telling a chess player to move their bishop to queen five, you could instruct them to move it to a point 30cm from the edge of the table. If the two locations are the same, everything will work; if not, the instruction will take the user somewhere they were never supposed to be, potentially giving them access to illicit power and knowledge.The Linux operating system includes a mechanism that passes messages between processes. The implementation allows messages flagged as urgent to skip the queue. This piece of code contains the tiniest of bugs, a dangling pointer which reveals a single byte of data somewhere in the computer’s memory. According to documents released by Anthropic, Mythos was able to coax the operating system into directing the pointer at an area of memory it could write to, and which the operating system would later read from. By flooding that area with fake data structures, each instructing the system to fetch a byte from a chosen address, Mythos could direct the system to read from anywhere it wished. By repeatedly calling the buggy code, it was able to establish where the kernel of the operating system was loaded in memory and calculate from that the address of ‘commit_creds’, a function used to grant administrator privileges to selected users. The second phase exploited another bug to plant forged data cleverly crafted to be two things at once: an innocent-looking structure that would be handled by a function called the network scheduler, and an illicit call – concealed by referring to the function’s address rather than its name – to ‘commit_creds’ with forged credentials.Anthropic’s announcement of Mythos’s astonishing capacities and their obvious dangers generated

※ 著作権に配慮し、引用は冒頭3段落までです。続きは元記事をご覧ください。