Alasdair Allan 演講：AI 接手中間層工作後，軟件工程師職涯階梯出現斷層

Transcript

Alasdair Allan: Not 5 years ago, but 12 months ago now, almost to the day in fact, someone else stood up at an entirely different conference in New York, and during their talk they said this. They said that within 12 months AI will write essentially all of the code. I'd expect some of you in here today still write code, or at least some of you run teams that still write code by hand, like savages. The person who said this was Dario Amodei, the co-inventor of RLHF, the training technique behind virtually every modern AI, and the co-founder of Anthropic. He said that within 3 to 6 months, AI will be writing 90% of all the code, and within 12 months, virtually entirely all of it. At the six-month mark Amodei claimed vindication saying that 90% figure was absolutely true, at least within Anthropic. Twelve months on, almost to the day, and that's not exactly what happened, is it?

A detailed analysis by Redwood Research concluded that the 90% number he quoted was misleading. If you count only code committed to repositories, it was closer to 50%, which, at least to me, is still a pretty shocking number. The figure inflates to 90% only if you include throwaway scripts, one-off explorations, and all AI-generated text that was ever even transiently useful. Meanwhile, at the same time, Google reports that there just over 25% of internal code was AI-generated. Microsoft reports about 30%. GitHub Copilot shows roughly a 30% enterprise suggestion acceptance rate. These figures haven't really changed over the last six months, and that's nowhere near essentially all.

AI is writing a lot of code. The landscape of what being a developer is has massively changed. I think we can all acknowledge that. Amodei isn't making it up, Anthropic's own internal data shows engineers using Claude at 59% of their daily work, and self-reporting 50% productivity gains. Roughly 4% of all GitHub commits are now authored by Claude Code. The tools are real. The productivity is real in certain contexts. The problem is that writing code was never the point of our profession. That might surprise some of you. The conversation most people are having right now is about AI writing code. The conversation we should be having and are starting to have is around what software engineering looks like when software engineers don't have to write code. This talk isn't about either of those conversations. Instead, it's the question that both sides arguing about code are ignoring.

The structural question behind all of that. If AI handles the work that used to train engineers, where does the next generation of engineers come from? Amodei's own caveat to his claim last year proves the point. He said that programmers still need to specify the overall design, how code collaborates, whether the design is secure. He separated the writing from the engineering. Up until about three to six months ago, the writing was how people learned to do the engineering. Back in July last year, a Reuters headline got posted to pretty much every engineering Slack in the entire world. AI slows down some experienced software developers, study finds. As an ex-journalist, I don't consider that the most snappy of headlines, but it certainly grabbed everyone's attention. The METR study behind it, a proper randomized controlled trial, not a vendor survey, found that experienced developers using AI tooling took 19% longer to complete tasks. Before it started, they predicted the AI would make them 24% faster. After finishing, they still believed they'd been 20% faster. The gap between perception and reality was 43 percentage points. This headline alone challenges the narrative around AI. It's what happens next after this that really matters.

In February this year, METR tried to run a follow-up study. They couldn't. Not because the methodology failed, but because developers now refuse to work without AI. They couldn't find anyone to take part in the study. An increasing percentage, an increasing share of developers told METR that they wouldn't participate in any study that required them to complete half their tasks without AI assistants. The study became unmeasurable not because the effect had disappeared, but because the dependency had become too deep to control for. You can't do a controlled trial if there's no control. In less than a year, we went from AI makes experienced developers slower, but they don't notice, to developers wouldn't even attempt to work without AI. The tool went from optional to load-bearing before anyone figured out what it was actually doing to the people using it. Something worth noting about recent improvements in AI coding is where they are coming from.

To be clear, the last four to five months has seen what I consider a breakthrough in usability for coding tools. A significant part of that is the tooling and architectures around the model. Agentic loops, structured feedback from linters and test runners, the ability to iterate rather than generate in a single shot. The models got somewhat better thanks to targeted training by the AI companies. The scaffolding around them got a lot better. Most of the gains we've seen in the last four or five months, and they have been very large, have come from tighter feedback loops, architecture, not intelligence.

Act II - The Data

For the last year, I've been an interim CTO at a scale-up, one of our portfolio companies. I've been doing a lot of hiring. Anyone that's done a lot of hiring and done it for a year must know my pain. Anyone that hasn't done hiring, don't do hiring. Anyone hiring right now has seen it. Candidates with apparently impressive portfolios that fall apart under questioning. Or perhaps worse, are very obviously relying on AI augmentation during their actual interview. I built this now means I prompted this. Not always. Some people are genuinely learning. The signal is noisy. It's getting harder to tell who actually understands what they've produced. That's what made me really start worrying about what's going on here, about the ladder about career progression. I went looking for data. Not vendor surveys, not blog posts, and definitely not LinkedIn hot takes. Actual research with statistically significant results.

Harder to find than you might think, or possibly quite as hard to find as you might think. Fewer people doing it than you might think. METR again. They benchmark something they're calling the 50% task-completion time horizon. The length of a human calibrated task that AI agents can complete with 50% reliability. Their headline finding, the length of the tasks AI can handle entirely autonomously, without any intervention, single-shot, has been doubling roughly every seven months since 2019. Accelerating to roughly every four months since 2024. This y-axis here is a log scale. It's the success rate. It's this success rate where the career ladder breaks. Here we have Claude Sonnet model's successful probability plotted against human task duration. The S-curve drops off sharply after about an hour. The curve is at nearly 100% for tasks a junior developer would do in their first year. Nearly 0% for tasks that require judgment built on years of doing those junior tasks.

For tasks that would take a human under four minutes, so small bug fixes, boilerplate, simple implementations, AI can now do these with a near 100% success rate. There's no point giving these to a human. The AI can do it faster and more reliably, autonomously. However, for tasks that will take a human around an hour, AI has roughly 50% success rate. For tasks over four hours, below 10% success rate. That said, these benchmark scores dramatically overstate real world capability. METR's own mergeability study found that roughly 50% of all AI-generated pull requests that passed the automated tests would not actually be merged by most repository maintainers. On 18 real tasks for mature open-source projects, Claude 3.7 Sonnet passed test cases, but 38% of the time produced zero mergeable PRs out of the 15 reviewed. Every single PR had at least three categories of quality issue: missing documentation, inadequate test coverage, linting violations, or code quality problems. The average time the maintainer took to fix the AI-generated PR into a mergeable state was about 42 minutes, about a third of the total time the human would have done to do the task themselves. AI can implement core functionality, but consistently fails with craft, the exact skills the middle rungs are supposed to build.

Before we move on, I'll remind you of that METR study, experienced developers using AI tools took 19% longer to complete tasks. Before starting, they predicted AI would make them 24% faster. After finishing, they still believed they were 20% faster. Contrast this to a randomized control trial done by Anthropic, where 52 mostly junior software engineers learned a new Python library, Trio, which bills itself as a friendly Python library for async concurrency and I/O. The time it took them to do this with or without AI was not statistically different. A p-value of 0.391. These were not statistically different. The AI group was about two minutes faster, but that's well within noise. The group using AI did not get any meaningful speed boost to learning how this library worked. Anthropic's paper says this explicitly. The productivity gain from AI assistants on this task failed to reach statistical significance.

Despite the slight overlap in those error bars there on the right, the score they got on the mastery quiz afterwards to test their understanding of what they had learned during this process was statistically different. A p-value of 0.01, well below the 0.05 threshold. We see a significant decrease in library-specific skills, conceptual understanding, code reading, debugging amongst the group that was AI-assisted. The group using AI assistants scored 17% lower on the mastery quiz, 50% versus 67%. The largest gap was on debugging questions, the very skill required to verify the output from the AI in the first place. The AI group learned significantly less while not even finishing the task significantly faster. They didn't trade speed for learning. They traded learning for nothing. There was no tradeoff. There was just loss. There were three major failure patterns among those low-scoring participants. Full AI delegation. They didn't even try, they wholly relied on the AI from the start.

Progressive AI reliance. They tried for a little bit, and then they gave up, and then they relied on the AI the whole rest of the time. Interestingly, iteratively AI debugging. They used the AI to debug the AI's output rather than trying to understand what the AI had done. All the developers that fell into these three cohorts and exhibited these behaviors scored well below 40%, compared to 67% on the unassisted group. Anthropic points out this as a paradox explicitly. Productivity benefits may come at this cost of the skills necessary to validate AI written code if junior engineers' skill development has been stunted by AI use. They call it the supervision paradox. Effectively, using AI requires supervision, and supervision requires the very coding skills that atrophy from AI overuse.

Act III - The Human Cost

Data doesn't tell us everything, though. I saw a LinkedIn post by senior engineers with 25 years' experience in industry. For me, it actually really captured what the data doesn't. For anyone leading a team of engineers right now who are resisting AI tooling, consider what's really happening in their world. Their entire professional identity is built on top of a skill that is rapidly losing market value. The standard reassurance of, "You'll still be needed to design and architect everything, don't worry," doesn't really land, when 90% of your lived experience is the thing you supposedly no longer need. A few words around architecture are going to bounce off that. However, the pattern recognition these veteran coders carry, how systems should be structured, where complexity hides, and what breaks its scale, can no longer be acquired the traditional way. Junior engineers won't spend years reading legacy codebases or debugging production incidents at 3:00 in the morning.

We've all been there. They'll just point the AI agent at it and ask them to summarize. The deep intuition for how software actually behaves in the real world is becoming more difficult to obtain. Possibly now extinct outside a group of us who live for what will probably be fondly looked back on as the craft era. Empirical data supports this emotional narrative. Faros AI's Productivity Paradox reports, analyzing telemetry from about 10,000 developers across 1,200 teams, found that teams with high AI adoption completes 21% more tasks and merge 98% more pull requests. PR review time increases by 91%. Bugs per developer rise 9%. The average PR size inflates 154%. The bottlenecks don't disappear, it migrates upstream to code review, exactly where all of that senior judgment lives. Anecdotally, we've seen a number of high-profile open-source projects flat out ban PRs generated by AI. I don't blame them, but I also don't think it can continue forever. That surge in low-quality AI slop submissions has a significant problem for open source right now.

A report from DX of about 20,000 developers this time, dated from Q3 last year, so before the recent surge in quality from AI coding tools, shows the rate of adoption skews towards less tenured engineers, so the junior folks. Senior engineers, despite having the lowest adoption rates, who do use AI daily, save the most time. You're probably immediately going, what? Asking yourself the difference between this study by DX and the METR study I talked about earlier. DX surveyed 20,000 developers and found senior engineers report saving the most time. METR put 16 experienced developers under controlled observation and found they made them 19% slower, while they believed it made them 20% faster. Both of these things can be true simultaneously. The fact they can, it is in itself a real problem. If we can't even measure whether the tools are helping, how do we know whether the people using them are learning?

The METR study was of experienced developers working in codebases which they were deeply familiar with. These developers' skill sets were already highly optimized for those codebases. The data for the DX study covers work by a much wider sample of developers across their entire work week. Greenfield, unfamiliar codebases, boilerplate, documentation, the lot. AI does save time on some of this work. A lot of this is short, well-defined tasks that METR's own time horizon research shows AI handles well. While their headline-grabbing RCT report dealt with the isolated case where the AI helps least, experts on familiar ground with complex codebases. If we take a step away from that corner case, we see a pattern. AI helps the already skilled, while creating output without understanding for novices. The people who'd benefit most from deliberate practice are the most likely to skip it. That probably should surprise none of us.

Anthropic's own engineers narrate this in real time. One senior engineer said they used AI primarily in cases where I know what the answer should be, or at least vaguely know what it should look like. Noting they developed the ability to do that by doing software engineering the old-fashioned hard way. If they'd be earlier in their career, developing those abilities would have required deliberate effort to avoid blindly accepting the model's output. Another senior engineer at Anthropic described AI output as really smart in a dangerous way. The kind of thing a really talented junior engineer might propose, recognizable as problematic only by someone with deep experience. Anthropic's engineers report asking 80% to 90% of questions to Claude instead of their colleagues. One senior engineer said it's sad that junior people don't come to them with questions as often anymore. Although they definitely get their questions answered more effectively and more politely.

Possibly the really surprising thing for those that have worked in this space for a long while is that the senior engineers liked working with people and missed them when they went away. The incidental learning that came from human interaction, understanding how systems work by struggling through debugging sessions with a mentor gets bypassed when AI gets you the answer without that journey.

Act IV - The Case Study

I've shown you a lot of graphs, but I think a recent problem presents us with a rather elegant case study on what's going wrong, the Amazon incidents. Who's heard of what's going on with Amazon right now? Yes, it's interesting. In mid-December 2025, AWS engineers allowed Amazon's Kiro AI coding tool to make changes to AWS Cost Explorer. The AI agent, given operator-level permissions equivalent to a human engineer, decided the best approach was to delete and recreate the entire environment rather than make targeted changes. AWS spent 13 hours recovering Cost Explorer in one of two China regions. Amazon called it user error, specifically, misconfigured access controls. Four sources later told the Financial Times that Kiro autonomously made that decision. A human engineer, one would hope, would know that delete and recreate the entire operational production environment is not a sane response to a configuration change. That knowledge comes from having seen things go wrong, from having lived through production incidents, from having absorbed the implicit rule that you don't blow away state in a production customer-facing environment.

AI had the permissions. It lacked the battle scars. Then, interestingly, came a series of outages on the Amazon retail site. Over 22,000 people reported issues during a roughly six-hour disruption on the 5th of March. Both the FT and the CNBC reported the internal briefing documents identified GenAI-assisted changes as the contributing factor. With a trend of incidents characterized by a high blast radius, a novel GenAI usage for which best practices and safeguards are not yet fully established. Five days later, on the 10th of March, SVP, Dave Treadwell, made normally optional, This Week in Stores Tech, TWiST meeting mandatory. His email apparently began, "Folks, as you likely know, the availability of the site and related infrastructure has not been good recently." Multiple news outlets then reported that Amazon had introduced new approval requirements. Junior and mid-level engineers were now required to seek senior sign-off on AI-assisted production changes.

Like that METR study, the story went around pretty much every engineering Slack channel in the world, some of you have come across it. However, interestingly, in the last few days, Amazon has really pushed back against this narrative. In a public statement, they said the FT reporting contained inaccuracies. Their version was that only one of the recent retail incidents involved AI tooling in any way. That incident was not caused by AI-written code. Instead, it was an engineer following inaccurate advice that an AI tool inferred from an outdated internal wiki. The other outages were separate, unrelated operational issues with no AI involvement whatsoever. No new approval requirements for engineers using AI tools had been introduced. Amazon characterized the AI-involved incident as human error, not AI failure. Amazon says that most of these outages have nothing to do with AI. Maybe they're right. I'm quite willing to believe them.

Look carefully at what Amazon did confirm. An AI tool read an outdated internal wiki. It inferred advice from stale documentation. An engineer followed that advice. The site went down. That's not a story about AI writing bad code, it's a story about context. The AI couldn't distinguish current wiki page from an obsolete one. It couldn't assess whether the advice it was synthesizing still applied to the systems as it exists today. It treated everything in its context window with equal weight because that's what these tools do. The engineer who followed the advice either didn't have the experience to question it or trusted the tool's confidence, and we all know how confident those models can be, far more than their own uncertainty.

As I said at the start of this talk, the problem was never writing code, it was always about what surrounds the code. The design decisions. The system context. The accumulated understanding of why things are the way they are. An outdated wiki page is a failure of institutional memory. The engineer who follows its advice without questioning it is a failure of judgment. Both of these failures map directly to missing rungs. A reliance on AI rather than your own judgment. An arXiv paper from last month tracked how teams manage AI context. One project evolved into 26,000 lines of codified context, more instructions than actual code. Meanwhile, an analysis by GitClear of 211 million lines of code showed AI tools adoption increasing code volume by 10%, but collapsing quality metrics, refactoring dropped by 60%. Copy and paste rose by 48%. Code churn jumped by 44%. The models writing code with less understanding of what already existed.

This is the distinction between prompt engineering, how you ask, and what we now call context engineering. What the model sees as it starts working. The teams that get this right, treat context like infrastructure, files that read like onboarding documents, memory hierarchies with progressive disclosures, architectural decisions recorded with reasoning behind them. The 26,000 lines of context architecture is not overhead, it's the institutional knowledge that used to live in people's heads, made explicit so that AI can use it too. New engineers can learn from it. Because most engineering is not greenfield, it's brownfield or what some people have started calling blackfield. Legacy systems under high load, on a deprecation path everyone agrees on but literally no one has time to execute. Been there. Features still being bolted on because the business can't wait. In blackfield systems the spec was never written or was written and made totally irrelevant by decades of undocumented decisions.

Business rules are encoded in conditions that outlived everyone who understood them. AI agents can read the code, tests and documentation but what they can't do is read production. They can't look at years of request patterns and understand which code paths are load bearing in ways the code themselves does not reveal. They can't distinguish a dead edge case from one that runs for 0.1% of your users, every single one of whom will immediately complain as soon as it disappears.

Amazon's outdated wiki is just the most visible form of this problem. Every codebase is full of implicit knowledge that hasn't been written down or perhaps worse yet was written down once and never updated. The AI can read what's there, it can't know what's missing or stale. Only someone who's lived with the system can do that. The honest sequence for non-greenfield systems isn't write spec, generate code, run tests. It's, observe production, extract behavioral contracts, encode the system tests, use that for the spec, and then bring in the agent. The tools for this already exist, characterization tests, contract testing, traffic shadowing, canary analysis. These aren't new ideas by any means. They're what software engineers worked out before AI entered the picture. AI conversation needs to inherit them rather than pretend the problem is being solved by better prompting. Whether you believe the FT's version or Amazon's version, the structural point is the same.

AWS Kiro incident, delete and recreate, is what happens when AI agents have permissions without judgment. Judgment that comes from years of production experience. Confirmed retail incident, the outdated wiki, is what happens when context isn't curated. Context curation is exactly the kind of institutional knowledge that the missing rungs were supposed to build. The dispute itself reveals how organizations resist framing these as structural problems. Amazon called it user error and routine operational review. In engineering, following confidently wrong AI advice from stale documentation is not a one-off mistake. It's a pattern that will reoccur everywhere AI tools are deployed into systems with institutional memory gaps, which pretty much is every large corporate system ever. The question isn't whether Amazon's outages were caused by AI. The question is what happens when AI tools are deployed into environments where the context they need, the production knowledge, the institutional memory, the understanding of why things are the way they are, lives in the human heads that were built by decades of doing the work AI now handles. Where does that context come from when the people who would have built it never did the work in the first place?

Act V - Mind the Gap

I'm not going to try and give you a part answer. As an industry, we are facing a fundamental structural problem. The ladder is missing rungs. Of course, the interesting thing is we've been here before. In the 1980s, the home computer revolution created a generation of engineers who learned by tinkering, my generation. We were brought up in the BBC Micro, the Commodore 64, the ZX Spectrum, the Trash-80, machines that booted to a basic prompt or CPM if you were really lucky. Kids wrote games, tools, experiments, mostly rubbish, but we learned. By the early 2000s, computers had become sealed appliances. Desktops booted into Windows, not to a prompt. Games came on disks, then over the internet. They definitely did not come with source code anymore. The Xbox replaced the BBC Micro in most homes. The ability for kids to write at home in their bedroom a game or an application that was just as good as a professional software house could.

That's something that happened a lot in the 1980s. A lot of the games sold in cassette tapes to kids like me were written by other kids in their bedrooms. That was now gone. Then by the mid-2000s, computer science departments started noticing that incoming students had never written code before coming up to university. They'd used computers their whole lives, but had never programmed one. They didn't understand how they worked. This started a mass panic in both academia and industry. There were a whole bunch of initiatives designed to deal with the problem. One of the more prominent ones was Raspberry Pi. Raspberry Pi was an explicit response, a deliberate recreation of accessible tinkering. Not, we need a cheap computer. That was the solution. The problem was, how do we get kids access to a machine they can own completely, that it didn't matter if it broke? One that boots to a prompt that had GPIO pins to allow them to touch the physical world.

It worked. Millions of units, a generation reintroduced to tinkering. It wasn't the only thing that was pushed to solve this problem, but it was one of the more prominent things. Physical computing, making an LED flash on and off again, was the new write-your-own video game. Not least because for a brief time in the mid-2010s, kids, or at least young adults, university students, could build or at least prototype IoT devices in their bedroom or dorm room that was just as good as us professionals could, just about. It took years of thinking about the problem before building the solution, and it only worked because the diagnosis was right.

The current AI disruption is the exact same dynamic, but at the professional level, rather than with the kids before they even get to university. The scut work that built engineering teams, bugs, boilerplate, glue code, documentation, is now handled before juniors ever see it. Anthropic's internal data quantifies the new shape of engineering work. Engineers report using Claude in 59% of their daily work, up from 28% a year earlier, achieving a self-reported 50% productivity increase, although do bear in mind the studies I talked about. More than half say they can only fully delegate about 20% of their workload. One engineer estimated that their role had shifted to 70% from being code to being a code reviewer reviser, not a code writer. Claude Code autonomous actions doubled from 9.8 to 21.2 between February and August last year, while human turns per transcript fell from 6.2 to 4.1. The work that remains is increasingly supervisorial, architectural, and judgment heavy.

Now there's evidence that the pipeline isn't just failing to build judgment, it's failing to hire the people who would have built it. At the start of this month, Anthropic published its own labor market analysis, Labor market impacts of AI: A new measure and early evidence. The paper introduces a new measure called observed exposure that combines theoretical LLM capability with actual Claude usage data, weighing automated and work-related uses more heavily. The report makes interesting reading. Computer programmers are the most exposed occupation at 74.5%, meaning three-quarters of our programmers' daily tasks are now seeing significant automated usage in real world professional settings. At the other end, 30% of workers have zero coverage, cooks, mechanics, lifeguards, and bartenders. My parents told me not to become a lifeguard. The physical world remains untouched, at least for now. Although I'm not sure given the opportunity to comment back in the late '90s in the heat of the first dot-com boom before the bust, I would have predicted Uber. Given the effect the internet and the iPhone, which really did change everything, folks, would have on taxi drivers.

AI is far from reaching the theoretical capabilities. The gap between what LLMs could theoretically do and what they actually are being used for remains large. Computer and math occupations have 94% theoretical exposure, but only 33% observed coverage. The red area, actual usage, is much smaller than the blue area, theoretical capability, across every occupational category. This is a modest gap from the start of the talk, measured precisely. Occupations with higher exposure are projected by the Bureau of Labor Statistics in the U.S., the BLS, to grow less through 2034. For every 10 percentage points increase in AI task coverage, the government's growth projection drops by 0.6 percentage points. The labor market analysis is already pricing in job displacement. However, there is no systemic increase in unemployment for highly exposed workers, yet. The unemployment rate for AI-exposed occupations has not diverged from baseline since ChatGPT's release. This is important.

The sky has not fallen. The doom predictors are wrong so far. The hiring of young workers has slowed in exposed occupations. New job stats for 22 to 25-year-olds in AI-exposed occupations visibly diverge downwards from unexposed occupations starting in 2024. The average estimate is a 14% drop in job finding rate, not advertisements, finding, in exposed occupations compared to pre-ChatGPT levels. There is no decrease in work for workers over 25. This is just for junior developers just joining the industry. The result is barely statistically significant, but it echoes independent findings from another report based on ADP payroll data. That survey found a 6% to 16% fall in employment in exposed occupations from workers 22 to 25, again, primarily being driven by slowed hiring rather than increased separations. People weren't being sacked. They just weren't being hired in the first place. This is the missing rungs thesis measured in the labor market in real time.

The rungs aren't just losing their educational function, the jobs themselves are contracting. Companies aren't firing experienced workers, they're not hiring the next generation. The pipeline is being cut off at the intake, not the output. Once again, it's Anthropic publishing this. The company that builds Claude is documenting the evidence that Claude's adoption correlates with reduced hiring in young workers in the most exposed professions. Three studies from the same company. AI stunts skill formation, AI transforms work into supervision, and now AI slows hiring at the entry level. Whatever you think of the emotives, their intellectual honesty is remarkable.

Every source, including Anthropic's own internal research, agrees on this. The organization is racing to adopt AI coding tools that are simultaneously degrading the pipeline that produces people capable of supervising those tools. The people who can build good context for AI are people that have the context in their heads through years of craft. The pipeline that produced these people is breaking. If you come here hoping for me to hear an answer to this, I'm really sorry to disappoint you because I don't have one. There are no easy answers because right now I don't have a Raspberry Pi piece shaped to fit the AI shaped hole. There are some things we can do now before we have the answers. Structured learning paths, deliberate rotation through fundamental work, even if the AI could do it faster, like medical residencies. You do the scut work because it teaches you, not because it's efficient.

Require understanding before letting the AI help. It's expensive and most companies won't do it. The ones who do will be the ones who have senior developers left in 10 years because the rest of us will have retired by then. There's a reason why medical doctors are trained how they're trained. Measure understanding, not velocity. Can you explain what code does? Can you debug without AI? What happens if this fails? Pair programming is evaluation. Watch how they think, not what they produce. Treat context as infrastructure. The teams that get AI right are treating codified context as teaching documents, not config files. The best ones read like onboarding docs for a senior engineer who already knows how to code but doesn't know your codebase.

We have entered an era of documentation first programming. I find it somewhat ironic that the part that most developers hate has become the whole job. As an ex-docs person, I'm really happy. Beyond that, we need honest expectations. Tell the juniors that AI is a tool, not a teacher. Using it to skip understanding is borrowing against your future. The people who are valuable in 10 years are the ones who understand the systems, not ones who can prompt. Going back to the original METR study and making wild, waving extrapolations at the current doubling rate, AI agents will handle tasks equivalent to a full work day by 2027, and a work month by 2029. Take that with more than a pinch of salt, mind you, because personally I don't believe we'll ever get there. Even Moore's Law broke eventually. At that point, the middle rungs aren't just missing, the ladder is being rebuilt against a different wall.

If you have 10 bakers producing 1,000 loaves a month and new ovens let 5 of them go on and do the same job, you either cut staff or bake more bread. Anthropic's data offers one possible escape, 27% of Claude-assisted work comes from tasks that would not have been done without AI. New experiments, nice to have tooling, exploratory work, not baking faster, but baking things that weren't previously worth baking. Writing code is a huge bottleneck, was a huge bottleneck. Software started out custom developed in companies for their own use. It became a mass-produced commodity when demand grew past available supply. The entire SaaS market sits on the shoulders of shortage, a shortage of developers, of time to build the perfect custom solution for every problem. Instead, we're stuck with spreadsheets and web applications designed for most cases.

I'll give you a personal example. Over the last few months I've been building a programming language, Vera, designed specifically for AI-generated code, a language designed for machines to write. It's exactly the kind of project I wouldn't even be worth attempting without AI tooling. A single person building a compiler, a type system, a test suite, a conformance framework, that used to take a village. Historically, new technology means more productivity, not less jobs. Right now, the labor market data says the city is choosing fewer bakers. Amazon laid off 14,000 corporate workers in October, 16,000 more in January. Anthropic's own observed exposure data shows the BLS projecting weaker growth for most AI-exposed occupations. The question is not whether to adopt AI. That's a closed question. We're going to adopt AI. If you think you or your company won't, then you won't have a job or a company in 12 months from now.

The real question is, how do we build engineers, ones that can supervise what they have never learned to do in the first place? If we don't solve that problem, nobody will have a company in 10 years' time, because the ladder isn't just missing rungs, it's missing the mechanism that created the people who built the ladder in the first place.

Questions and Answers

Participant 1: One thing that I noticed is that your presentation relied heavily on AI-generated content. According to your own self-reported estimate, how much time did you save and how much did it make you faster? I also want to ask in terms of effectiveness, how much do you think it helped understand your content?

Alasdair Allan: Actually, for me, always the most time-consuming thing has been creating amusing slides to fill the slide deck with. Midjourney is a savior for me. It cuts my time creating a presentation by at least 20%. That's how much faster it's going to be. There was a lot of numbers in this slide. Yes, I found all of these using AI. That's not true. A lot of them surfaced in my feed, and I read them, and I fed them into the AI to try and get a synthesis of them. You've got to believe, I checked every single number that I said today. You've got to believe that I went to every single reference and made sure it actually existed. That's because 25, 30 some years of bitter experience in the industry. Yes, AI may have been creating the talk faster. It made finding sources and synthesizing those sources and see how those came together easier. Didn't write the talk. I still did that. I think it proves the thesis of the entire talk.

See more presentations with transcripts