Claude AI Found Real Bugs in Microsoft CTO Kevin Scott’s 40-Year-Old Apple II Code

="">

Microsoft CTO Kevin Scott handed Anthropic’s Claude a mass of assembly code he wrote as a teenager in the 1980s. The AI didn’t just read it. It found actual bugs — in 6502 assembly language for the Apple II, a platform that hasn’t been commercially relevant in decades.

That’s the headline. But the implications run deeper than a fun nostalgia exercise.

What Actually Happened

Scott, who has led Microsoft’s technical strategy since 2017, described the experiment during a conversation at a recent event, as reported by Slashdot. He fed Claude source code from programs he’d written around 40 years ago as a kid learning to program on an Apple II. The code was written in 6502 assembly — a low-level language that requires manual memory management and direct hardware manipulation. Not Python. Not JavaScript. Assembly.

Claude didn’t just parse the syntax. It identified genuine bugs in the code, explained what they were, and described how they’d manifest during execution. For anyone who’s worked with 6502 assembly, this is a nontrivial feat. The instruction set is small but unforgiving. Context matters enormously. And documentation from that era is sparse by modern standards.

Scott used the demonstration to make a broader point about where AI capability is heading — particularly in understanding legacy systems and ancient codebases that still underpin parts of modern infrastructure.

A fair point. COBOL still runs a staggering percentage of global financial transactions. Fortran persists in scientific computing. The world is full of old code that few living programmers fully understand.

Why This Matters for Engineering Teams

The practical takeaway here isn’t that Claude can debug your Apple II hobby project. It’s that large language models are demonstrating genuine competence with obscure, low-level programming languages that have tiny representation in modern training data.

Think about what that means for enterprises sitting on millions of lines of legacy code. Banks. Government agencies. Defense contractors. Manufacturing firms running control systems written in languages that predate the internet. The talent pool for maintaining these systems shrinks every year as experienced engineers retire. And training new engineers on dead or dying languages is expensive and slow.

If AI models can reliably read, interpret, and find defects in code written in languages like 6502 assembly, COBOL, or Ada, that’s a meaningful capability for organizations drowning in technical debt. Not theoretical. Practical.

But — and this is a significant but — reliability is the key word. A demo where Claude correctly identifies bugs in one codebase doesn’t tell us much about its error rate across thousands of codebases. False positives in bug detection are almost as costly as missed bugs, because they waste engineer time and erode trust in the tool.

Anthropic has been positioning Claude as particularly strong in coding tasks. The company’s Claude 3.5 Sonnet model scored well on SWE-bench, a benchmark for real-world software engineering tasks, and the company has continued pushing coding performance in subsequent releases. Scott’s experiment, whether intentional or not, served as a public endorsement of those capabilities from a competitor’s CTO. That’s notable.

Microsoft, of course, has its own massive AI bet through its partnership with OpenAI and the integration of Copilot across its product lines. Scott praising Claude’s abilities is either a sign of genuine intellectual honesty or a subtle acknowledgment that the competitive field remains wide open. Probably both.

The Bigger Picture on AI and Legacy Code

Several companies are already building products around AI-powered legacy code analysis. Firms like Modernize and others are targeting COBOL-to-Java migration specifically. IBM has invested in its own Watsonx Code Assistant for Z, designed to help translate and modernize mainframe applications.

So Claude’s performance on 40-year-old assembly isn’t happening in isolation. It’s part of a broader race to make AI useful for the hardest, least glamorous parts of software engineering — maintaining and migrating the old stuff that nobody wants to touch but everybody depends on.

The risk? Overconfidence. AI models hallucinate. They generate plausible-sounding explanations for code behavior that may be subtly wrong. In high-level languages with strong type systems and extensive test coverage, that’s manageable. In low-level assembly with no tests and no documentation? The consequences of a confident but incorrect analysis could be severe.

Still, the direction is clear. AI models are getting better at understanding code across the full historical spectrum of programming languages. And the economic incentive to apply them to legacy systems is enormous — potentially hundreds of billions of dollars in deferred modernization costs across global enterprises.

Scott’s little experiment with his teenage Apple II code was charming. It was also a signal. The future of AI in software engineering isn’t just about writing new code faster. It’s about understanding the old code we’ve been afraid to touch.