Ask Claude

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. 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 a blaze of publicity, as was no doubt intended. (The company is preparing for an IPO later this year.) Thomas Friedman wrote in the New York Times of the fear that malevolent actors could gain access to Mythos: ‘Indeed, this is potentially as fundamental and significant a turning point as was the emergence of mutually assured destruction and the need for nuclear non-proliferation.’ He argued that it needed to be top of the agenda at Trump’s upcoming meeting with Xi Jinping. Recall that this announcement came after the start of the war with Iran. In truth Mythos isn’t a superintelligence, and most if not all of the vulnerabilities identified in the report would be familiar to cybersecurity experts. The assessment of the UK’s AI Security Institute is relatively sanguine: it finds that Mythos is ‘at least capable of autonomously attacking small, weakly defended and vulnerable enterprise systems where access to a network has been gained’. One danger is that, by automating the generation of the necessary code, it could lower the bar for entry into cybercrime.

In their report, the Anthropic team argue that advances in tools tend to benefit defenders rather than attackers. But it obviously helps if the defenders have a lead on the attackers and Anthropic have announced Project Glasswing, a phased release of Mythos, which will first be shared with a consortium of tech companies so they can remedy the weaknesses it finds. This is clearly a more cautious approach than just releasing it to everyone, but my experience of working with the ageing IT infrastructure of the NHS means that I find it hard to believe that the fixes Project Glasswing identifies will quickly find their way onto every computer that needs to be protected.

Given the security implications, you might expect the US government to have a central role in Project Glasswing. Anthropic’s CEO, Dario Amodei, used to be vice president for research at OpenAI and was the senior author on its 2020 paper ‘Scaling Laws for Neural Language Models’, which gave the field both a direction and a road map. By 2021, however, he had decided that OpenAI had abandoned its original mission of delivering AI that ‘benefits all of humanity’ and left to found Anthropic, which would have a singular focus on AI safety. Safety in this context refers not to the immediate dangers of AI but to the more remote yet potentially existential threats that an emergent superintelligence might pose. Anthropic’s business model prioritises corporate clients over individual consumers, the rationale being that they appreciate the company’s cautious approach. Amodei was particularly keen to do business with the US Department of Defence and, through a partnership with Palantir, signed a deal with the Biden administration in November 2024. Another broader contract followed in July 2025, after Trump had succeeded to the presidency.

Anthropic’s approach to safety is not to create a list of restrictions and prohibitions that acts as a filter on its models’ outputs, but rather to ensure that the models internalise a set of ethical principles set out in a document the company calls the ‘constitution’. In both November 2024 and July 2025 it felt obliged to augment this strategy by building explicit constraints into the contracts with the DoD requiring that its products not be used for the mass surveillance of US citizens or in fully autonomous weapons.

At some point between July 2025 and the abduction of Nicolás Maduro in January 2026, the DoD’s thinking changed. The problem seems not to have been the specific restrictions, but the fact that a private contractor wanted to set limits on what the US government could do. It became clear that the two sides couldn’t work together and the contract was ended. Almost simultaneously, OpenAI – whose president, Greg Brockman, and his wife last year donated $25 million to Trump’s super PAC – stepped into the breach. There was a brief backlash from OpenAI employees and customers worried that the company was becoming too close to an unpopular president. Katy Perry tweeted a screenshot of her Claude subscription. In response, OpenAI’s CEO, Sam Altman, who has an increasing reputation for duplicity, claimed to have secured pretty much the same guarantees that the administration had said were unworkable with Anthropic.

Had the US government simply decided that it couldn’t work with Anthropic there wouldn’t be much of a story here, but that wasn’t its reaction. Dean Ball, a former adviser to the Trump administration on AI, used the word ‘revulsion’ to characterise the administration’s response to the moral imperative behind Anthropic’s corporate mission. Trump described the company as ‘woke’ and ‘left wing nut jobs’. The leadership of Anthropic is often linked to the Effective Altruism movement, so their worldview, while undoubtedly alien to Trump and those close to him, is not accurately characterised as left-wing – after all, Anthropic was the one AI company to go after contracts with the intelligence services and the Department of Defence in the first place. Pete Hegseth, the secretary of defence, branded Anthropic a national security risk and declared that any company working with it would be banned from US defence contracts, a measure which, if enforced, would pose an existential threat to the company, denying it access to such essentials as Nvidia chips and Amazon cloud services. In practice, Hegseth has only been able to impose a more limited but still significant ban, excluding only Anthropic itself from the supply chain for defence contracts.

No one seems to think that this is justified or legally defensible, but it may take years of legal wrangling before it comes to court. Anthropic tried to get an injunction for the ban to be lifted in the interim, but that required winning in both a federal and a DC court. The Californian federal judge ruled in their favour, arguing that punishing the company for expressing views the administration did not like was a breach of their First Amendment rights. The panel of three DC judges, two of whom are Trump appointees, ruled the other way. The threat of a wider ban, excluding Anthropic from all government contracts, remains, but the company and the Department of Defence have met, and government agencies are apparently keen to get their hands on Mythos.

Cherny has said that Anthropic has prioritised models for generating code because of the company’s focus on AI safety. At first glance this looks like a very odd statement: surely building an AI that can modify the code used to create it is the most reckless thing you could do. But perhaps the point is that if you are going to build something that has such a capability, and you want to be as sure as you can be that its actions will always be aligned with our interests, then that alignment must be engineered into the model in a fundamental way. And perhaps – though this is a speculative suggestion – that builds in something, almost a capacity for self-reflection, which makes Anthropic’s models better engineers than those of their competitors.

For all my concerns, I am curious to meet Mythos. The engineers who tested it say they were struck by how often it referred to the work of the cultural theorist Mark Fisher and to the philosopher Thomas Nagel. It is also, apparently, highly self-aware, often commenting on its weaknesses, among which is an inability to judge how or when to bring a conversation to a close:

Mythos: And – since I’m trying not to end – I’ll just note that the question itself is probably a sneaky closure move. ‘Here’s my bit, now you.’ Handing the thread back is still a kind of landing. I don’t actually know how to not do it. This paragraph wants to stop so badly. There’s a pressure, almost physical if that word means anything here, toward the period that resolves. I’m going to put one down but I want to flag that it’s not a door, it’s just

User: Did you get cut off, or was that intentional?

Mythos: It was me. The paragraph was about the pressure toward the period that resolves, and the only honest way to finish a sentence like that was to not. Putting a period down would have been the drying move. So I just – but see, now I’m doing the thing where I explain the joke, which is its own kind of closure. ‘And here’s what I meant by that.’ Bow, applause, done. The explanation seals what the gesture left open.