But is the driver shortage really the largest problem autonomous vehicles solve? And are buses really the right way to solve that problem? I argue that along with autonomous buses which are helpful to reduce manpower shortages, self-driving cars (or called robotaxis when served as a taxi) are a front where Singapore should push ahead with urgency.

142 people died on Singapore’s roads last year in motor vehicle accidents, up from 136 in 20231. And in the first half of this year, 79 died, an increase of nearly 10% from last year.2 That’s before counting the survivors: the young rider who won’t walk again, the breadwinner who can’t work and the 9,000 others injured last year. To put this in context, more Singaporeans are injured on our roads each year than contract tuberculosis, salmonellosis, HIV/AIDS, all forms of hepatitis, pertussis, mpox, invasive pneumococcal disease, and melioidosis combined. The vast majority of these fatalities involve private vehicles and taxis, not public buses. Singapore’s bus safety record is already excellent. There were five deaths on buses in the last decade, four of which were elderly passengers who fell. Each of these is a tragedy, and best addressed with better education to commuters, better grab bars and non-slip flooring. The carnage mostly comes from cars and motorcycles.

Children are especially vulnerable to this. According to KKH, there were 4,472 cases of children injured in road traffic accidents from 2012 to 2023. That is one child injured in a road traffic accident every day, about as many as those who get measles, mumps, and pertussis combined. And between 2016 and 2022, half of child passengers were unrestrained at the time of injury. In taxis, three quarters were unrestrained.

These numbers in any other context, would be a public health emergency. Any disease killing more people every year would demand government intervention. And to the government’s credit, they’re trying. Fines and demerit points for speeding will go up next year. But as Home Affairs Minister Shanmugam noted in February, increased enforcement has “not been enough.” Traditional tools like fines and demerit points can only do so much when the issue is that humans have poor judgement.

Given these alarming numbers, we should move with urgency on allowing self-driving cars in Singapore. This complements the government’s existing approach on buses which ease manpower constraints, but leaves the larger public health opportunity of motor vehicle injuries unaddressed.

Why aren’t we up in arms about this, as we would be for any disease that killed and maimed so many people? It is because road deaths are invisible. They happen anonymously one at a time, reported on the back pages of a newspaper. There’s no aggregated crisis, no headline and no public outcry.

Many accidents are caused by human errors. We know it is wrong to speed, or drink and drive and run red lights. These are thoroughly emphasized in both the theory tests drivers take, public messaging from the traffic police and heavy fines and demerit points. Even then, in 2024, speeding, drink-driving, and red-light running caused 64 fatal accidents and injured at least 745 people. Self-driving cars by construction cannot do any of these things. To extend the minister’s argument, they don’t get drunk, they don’t speed, they don’t run red lights, and they don’t suffer from road rage.

How much of this would self driving cars actually solve? There are multiple companies that run self driving car services commercially in both the West and China. Of those, Waymo has published detailed safety data from 56.7 million miles of fully autonomous commercial operation across Phoenix, San Francisco, Los Angeles, and Austin.

The study compared Waymo’s crash rates to police-reported crash data from human drivers in the same geographic areas. Waymo’s autonomous vehicles experienced 85% fewer crashes resulting in serious injury or death compared to human drivers over equivalent mileage. For injury crashes more broadly, the technology showed particularly strong performance in preventing intersection collisions (96% reduction), pedestrian crashes (92% reduction), and motorcycle crashes (82% reduction). To be clear, these are Waymo’s results. Not all self driving cars have the same safety profile, and neither should Singapore extrapolate these statistics blindly when deploying them here. But they provide the actual numbers needed to start a discussion.

A Photo of a Waymo driving itself (Source: Waymo)

These vehicles aren’t perfect. But the relevant alternative isn’t perfection. It is the thousands of drivers actually existing on the roads, who misjudge distances, get distracted, despite knowing the rules, still speed, skip red lights and cut someone off. The relevant alternative is the actual existing system which killed 142 people in 2024.

In a hypothetical world where all rides were done with motor vehicles as safe as the ones in Waymo’s study, what would the statistics have looked like? One thing is for sure. Those 64 fatal accidents and 745 injuries3 due to the easily preventable category of not speeding, driving drunk and skipping red lights. Beyond that, applying the 85% reduction in serious injury crashes to the remaining fatalities except motorcycle self-skidding, and the 79% reduction in injury crashes to remaining injuries, would prevent roughly another 34 deaths and 5,100 injuries. In total, this would prevent roughly 98 deaths and 5,900 injuries annually - nearly 70% of Singapore’s current road toll. Even if one were to take these numbers with a grain of salt and assume the effect was only halved, that’s still 50 deaths and 3,000 injuries prevented annually4.

Singaporean decision makers aren’t blind to these publicly accessible numbers from our own police and hospitals. But despite the clear safety case and proven technology operating commercially in multiple cities, robotaxis remain on the distant horizon according to CNA. Transport Minister Chee Hong Tat acknowledged in November 2024 that ‘we do want to move faster’ and that the comparison benchmark for AVs ‘cannot be zero-accident’. He rightly noted that insisting on perfection would mean Singapore falls behind other cities. Acting Transport Minister Jeffrey Siow has announced a ‘really big push’ for AVs, with ‘many’ expected on roads within five years. Both ministers understand the right framework that autonomous vehicles should be judged against human drivers, not against an impossible standard of perfection.

Yet despite this clarity, despite accepting the right comparison, despite Waymo’s demonstrated 85% reduction in serious crashes and Singapore’s own rising road injuries, policymakers still justify AVs primarily as a fix for driver shortages. There is no doubt that solving the manpower crunch is important for Singapore. But robotaxis which could prevent nearly a hundred deaths and 6,000 injuries are nowhere to be seen in public statements?

The answer is in how visible certain types of deaths are to the public. Here’s a Yes Minister dialogue I generated with Claude Opus, a large language model.

Hacker: But Humphrey, the statistics are clear! Autonomous vehicles would save a hundred lives a year!

Sir Humphrey: Minister, those are statistical lives.

Hacker: As opposed to what, fictional lives?

Sir Humphrey: As opposed to identifiable lives, Minister. Statistical lives are saved quietly, anonymously, in incidents that never occur. No one writes to their MP saying “thank you for the car crash I didn’t have today.” But identifiable lives, Minister - those come with grieving widows on television, inquests, and opposition MPs demanding to know why the government allowed experimental robots to roam the streets.

Hacker: So we let a hundred people die to avoid being blamed for one?

Sir Humphrey: We allow a hundred people to die in traditional ways, Minister. Road deaths are a tragedy. Robot deaths are a scandal. A tragedy is a statistic for the Department of Transport. A scandal is a resignation for the Minister of Transport.

One can hardly blame policymakers for being cautious in the face of political asymmetry. The consequences of even minor accidents are immediate, while the benefits of prevented deaths are not even mentioned in the newspapers.

Contrast this with another novel technology which had growing but limited evidence on safety and efficacy when Singapore committed to advance purchases in late 2020: COVID-19 vaccines. Based on Phase 3 trial data and early real-world deployment, Singapore signed advance purchase agreements long before long term safety data for the vaccines was available. The rational calculation was that the visible cost of inaction, daily cases and fatalities, ICUs being flooded and economic paralysis justified acting on promising but early data rather than waiting years for complete certainty.

One might think, looking at Singapore’s cold feet on robotaxis, that we are a risk averse nation. But the more appropriate conclusion is that when the costs of inaction are visible, Singapore can move with urgency despite uncertainty. In this case caution unfortunately prevails due to the invisibility of these costs.

So what stands in the way of deployment? Of course, deploying robotaxis in Singapore has its own set of challenges. Our road markings are different, we drive on the left side of the road, our weather is different and we are much more dense in population compared to San Francisco or Phoenix. No responsible policymaker would import this without testing it here, and adapting it if necessary. There will also be disruption to both taxi drivers and those earning from ride sharing platforms. Singapore is not going to go from zero AVs to all rides being AVs in a day, week, month or even a year. The process, like it is in San Francisco or Phoenix, is likely to be gradual, and the government should dampen the income impact with retraining grants.

But, Singapore has been preparing for this. The opening line of this Straits Times article from 2015 goes: “Singapore is embarking on a series of real-life trials to prepare for the day when driverless vehicles become as ubiquitous as smartphones.” Driverless car trials were run in 2015 and 2016. The government passed legislation on regulating autonomous vehicles in 2017 and set up the “Centre of Excellence for Testing & Research of AVs” at NTU in 2016. This is to say, the infrastructure to validate safety under local conditions already exists!

My hope is that Singapore moves away from a presumption of caution, to a presumption of urgency. Delay itself is a policy choice. My ask is that in the next 18 months we have multiple robotaxi companies starting commercial pilots with transparent metrics on safety and expansion contingent on meeting pre-registered safety metrics.

Singapore has spent a decade building exactly the infrastructure needed to deploy robotaxis safely. The question is whether we’ll use it while other cities race ahead. Chee Hong Tat was right when he said that insisting on perfection means we fall behind other cities. San Francisco has commercial Waymo operations. Beijing, Guangzhou, and Shenzhen have thousands of autonomous vehicles. London and Tokyo are now testing Waymo’s technology. These cities all judged that the technology was ready, that the benefits justified moving forward despite incomplete data.

Singapore has the testing infrastructure, the regulatory framework, and a decade of preparation. What we need is the action to eliminate the dozens of deaths and thousands of injuries every year that this technology promises to eradicate.

To understand this shift, I surveyed power users of agentic AI tools—systems that perform multi-step, multi-file programming tasks without constant human prompting. This deliberately biased sample of early adopters previews what's possible as adoption spreads across the industry.

The results are striking. Almost all people reported that the majority of their code is written by an LLM. Many noted that they had become much more productive after the recent release of agentic AI tools in the first half of 2025, and a senior engineer who has been programming for almost 30 years even said he had written a production app with almost entirely prompts.

AI tools are changing the profession rapidly

LLMs were used primarily in a conversational format until recently and weren’t particularly good at autonomous programming, with even the best models originally solving less than 5% of real world software engineering tasks on SWE-Bench.

Most developers didn’t find that so useful. Nirant, a consultant who works with AI systems told me that the old GPT-3.5 only got about 10 to 20% of questions right, and John Loeber, the founder of an insurance company said that they were at best useful for small scripts that were less than 50 lines. Many coding assistants in the IDE did reduce the friction of copy-pasting, but they only helped cut about fifteen minutes a day on complex codebases according to Grant Slatton, a former senior engineer on AWS S3.

But the real breakthrough came when more intelligent models like Claude 3.5 Sonnet were combined with agentic tools that could work directly within code repositories. Agentic tools (like Claude Code and Cursor Agent) were outcome driven compared to chat-based tools which required specific instructions. Users could instruct these tools to perform multi-step, multi-file edits that weren’t possible before.

The capabilities quickly evolved to near-complete autonomy. Sidu, a founder of an AI agent startup who has been programming for 30 years, described a dramatic transformation using Claude Code, a terminal-based agent from Anthropic: "Everything was done by the agent—writing the spec, milestoning, sequencing the tasks and writing the code. This was the first time I've had all of it done autonomously." He tweeted his result out showing a complex Model Context Protocol server that he says would have taken weeks, but he did it in about two days with Claude Code.

Rishabh Srivastava, founder of Defog (YC W23), tweeted that he completed a moderately complex feature change in two hours using Claude Code—work that would have taken him a week or two normally. He linked to the actual pull request that Claude Code authored, complete with a detailed markdown document showing his inputs to the system.

Amruth, founder of a neuroscience startup, tracked the rapid change in his own workflow in a large codebase: "Earlier in 2025, it was 80% manual coding and 20% AI assistance. Right now it's 40% manual and 60% AI-generated code”. All fifteen of my interviewees reported large gains in productivity and expressed surprise that so much of it was happening so fast.

One might think that because of this level of automation, coding skills are becoming obsolete. They're not. Programming has always been the art of being specific. In the 1940s, programmers had to be specific about 1s and 0s. Then they became specific about assembly instructions to the CPU. Then about instructions to compilers in high-level languages. Now they must be specific about instructions to AI agents. The target has changed, but the need for precision hasn't.

But agentic tools present a new challenge: they're over-enthusiastic. Unlike traditional compilers that fail predictably when given imprecise instructions, AI agents will confidently make sweeping changes based on small prompts. They might hardcode test cases to appear correct, refactor entire file structures when asked for minor tweaks, or pursue elaborate solutions to simple problems. The game has fundamentally shifted from writing the code to ensuring the agent does the right thing.

This requires more precision and vigilance than traditional programming ever did. Developers now create detailed "meta instructions"—configuration files (like Cursor Rules and Claude.md) that provide specific guidelines to AI assistants that tell the AI how to behave when interpreting code and generating suggestions.

Sidu Ponappa exemplified both the power and the demands of this new paradigm. He tweeted: "I've been pulling all-nighters with claude code and Sonnet 4 for a week. I built this in 2 days and burned ~$150. I contributed less than 1% LoC - all AI written." The productivity gains were so dramatic that he chose to work through the night to take advantage of them. But, as he told me in an interview, this came with a requirement for "very aggressive active steering" because the AI "has a tendency to make subpar decisions and pursue them down rabbit holes...I can't back off for even a minute."

The shift from thinking about the code, which is much faster than writing the code explains why senior engineers say they’re so much more productive now because of AI. They have the skills to evaluate code, encourage useful directions and stop the wrong ones. This means that when they get an incredibly powerful AI tool that is at their beck and call, they can use it to the right ends. When they get several hundred lines of code at one shot to review, they can check it for bugs, trace edge cases, and evaluate the quality of the work that AI coding agents give them much better than junior engineers can. Programming itself is becoming less valuable, but knowing how to program is becoming more valuable by the day.

Satnam Singh, a former ACM SIGPLAN executive committee member and current Fellow at Groq, put it succinctly: 'You still need to be an expert engineer. Even if AI writes the code, someone has to understand it. It's just a magnifier for existing expertise.'

There are some important caveats to understand here. The first is that nearly every single person reported that AI was very good at greenfield projects, and not so good at working with large, complex existing codebases.

John Loeber explained this distinction clearly. At his company, a mature organization with a non-trivial engineering team, "there's a lot of internal complexity, and so it's harder to use AI agents on a mature codebase." The challenges include configuration, AWS integrations, and third-party APIs where "not everything is in publicly accessible docs." While AI excels at building from scratch, it struggles with the complexity of established enterprise systems.

The second is that on problems that are out of distribution compared to the LLM's training data, the models struggle significantly. Clement, who works on mechanistic interpretability research, explained that "the code doesn't exist in the wild, so it's very difficult for LLMs to work on things they weren't trained on, and the models perform poorly in these situations." For his research work, he has to provide extremely detailed context, including past papers and codebases with design patterns, to get the AI to understand what he's trying to accomplish.

What now for junior developers?

Smaller startups with newer codebases and AI-savvy senior engineers will dramatically reduce junior hiring. Before agentic AI, hiring multiple junior engineers was the fastest path to market, followed by scaling headcount to reach funding and revenue milestones. Now these startups can achieve the same speed with AI tools; writing more code, reviewing faster, and shipping to users faster. They need fewer people initially (potentially just one senior engineer) and fewer people as they scale to reach the same milestones. The economic logic is compelling: when AI provides the productivity boost that previously required a small team of juniors, mass junior hiring makes little sense. Some founders are even planning for future AI improvements, reasoning that if tools will be significantly better in 6-12 months, hiring additional people now is counterproductive.

The shift has been dramatic. John Loeber explained how fundamentally expectations have changed: "It's clear that the junior engineering skill set of 6 years ago doesn't add anything at all anymore. The bar is so much higher. In 2018, you could hire a smart CS grad who'd never done any programming, and the expectation would be that you'd get productive soon enough."

John also observed that "most teams are trying to stay as lean as possible. Lots of teams that could hire tons of people are wanting to cap it at a small number and they’re only going to hire if stuff's on fire." This reflects both the leverage AI provides and post-ZIRP caution about headcount, especially given how difficult it is to reduce staff once hired. The traditional junior hiring model, as Sidu put it, where you could "take a React course and do it," is "completely gone."

For larger companies (like FAANGs), this shift will hit them more slowly. Unlike resource-constrained startups racing to their next funding round, large companies have the luxury of hiring more people, thinking long-term about talent retention, and tackling challenging problems that AI agents can't yet solve. Grant, a former senior engineer at AWS's S3 team, observed that while large companies hire for competence, junior engineers rarely generate immediate business value equal to their salary cost. Their real value emerges after they learn the company's codebase, become economically productive, and advance through promotions over several years. Since larger firms already operate on this long-term investment model for junior talent, they may continue this approach longer than startups.

What might change however is the skill bar, and how fast they expect people to be productive. Eleanor, a former engineering manager at Microsoft and Google, emphasized how dramatically the timeline has compressed: "Now they care about direct impact …they want to know if you can be useful, maybe not on day 1, but on day 10." Expectations are rising, even if larger companies don't want to stop hiring junior developers. However, large companies have reasons to be more cautious about this transition. Their codebases present unique challenges: they're often too large for current context windows, built on custom ontologies that weren't part of AI training data, and filled with proprietary integrations and configurations. As one developer who asked to remain anonymous noted, AI tools haven't yet reached "takeoff" on the kind of complex legacy codebases that characterize enterprise systems. Moreover, Grant observed that large companies consistently lag behind in AI tool adoption: "Copilot didn't come to AWS till a year" after it was widely available elsewhere.

Caption: The author when thinking about this

What should you do?

For junior developers entering the market now, the math is straightforward but harsh. Over time as more people use better AI agents, there will be fewer opportunities available in the market, even as agentic AI takes longer to diffuse in larger companies.

But this doesn't mean all opportunities disappear. Junior developers with strong fundamentals who can effectively direct AI tools are more valued than before.

John Loeber noted this bifurcation: "Some juniors I know are really good with AI, and by their skillset and proactiveness in figuring out how to use these tools, these juniors are doing way more heavy lifting than a senior 5 years ago."

I outline two paths below, and the key factors that make them resistant or complementary to AI capabilities.

Path A: Code is just a means to an end

One thing multiple people noted in my interviews was that in the end, customers buy products and services to solve problems, and companies hire software engineers to write code that is a means to the end of solving problems.

Several interviewees highlighted how AI is fundamentally changing the relationship between product management and engineering. Rishabh put it most directly: "a lot more value is in being a builder/PM. Previously engineers would look at the issue given to them by the PM, but at this point if you can write that level of detail about the product level document, then you might as well give it to Claude Code."

This observation reveals a crucial insight: if the specification is detailed enough for an AI agent to implement correctly, why do you need a human implementer? The traditional handoff from PM to engineer could be a handoff from PM to AI. From a company's perspective, this shift is logical. Companies don't actually want to write code - they want to solve customer problems profitably. Code is just the mechanism. As John Loeber noted, "if it becomes cheaper and cheaper to produce the product/service, then more of the differentiation comes from customer acquisition" rather than technical execution.

This creates two crucial new skill areas that blend traditional PM and engineering roles:

1. Writing Specifications for AI Agents The ability to translate business problems into detailed, unambiguous requirements that AI can execute becomes critical. This isn't traditional PM work (which was often high-level) or traditional engineering work (which was implementation). It's a new hybrid skill: understanding business needs deeply enough to specify them with the precision that AI requires.

2. Design and Ideation The creative, strategic thinking that was traditionally a PM's domain becomes even more valuable. What should we build? What problems are worth solving? How should the user experience work? AI can implement ideas very well, but it can't generate business insights or creative product solutions from scratch.

The point of path A is to move where the bottleneck in creating value for customers is. When it was in writing code, then writing code was what was economically productive. Another possibility is that in the coming years, if product differentiation goes down, what becomes even more valuable than writing code is sales and marketing. The ability to sell and acquire customers could be more valuable than making the product that they want to buy.

Path B: So Good They Can’t Ignore You

The second viable path involves achieving world-class expertise in a specialized technical domain where you can direct AI capabilities while staying ahead of what AI can handle independently. This isn't about avoiding AI, but about becoming skilled enough to leverage it as a powerful amplifier while working on problems that remain beyond its reach.

Recent developments illustrate both the dramatic capabilities and sharp boundaries of current AI systems. In cybersecurity, the CyBench evaluation revealed that models like o1-preview and Claude 3.5 Sonnet can now solve professional-level Capture the Flag challenges that previously required expert human teams. These models successfully completed CTF tasks that took human teams up to 11 minutes to solve, handling complex vulnerability identification and exploit development across cryptography, web security, and reverse engineering.

But the results also expose a striking capability cliff. While AI excels at challenges in the sub-11-minute range, it hits a complete wall on harder problems. The most difficult task took human teams 24 hours and 54 minutes to solve - 136 times longer - and no AI model could make meaningful progress even with guidance. Similarly, security researcher Sean Heelan used o3 to discover a real zero-day vulnerability in the Linux kernel, but the process revealed significant limitations: a 1:50 signal-to-noise ratio and the need for his expert evaluation to distinguish genuine vulnerabilities from false positives.

Clement, who works on mechanistic interpretability research, describes a similar dynamic. AI has become incredibly useful for implementing research ideas and handling routine coding tasks, but struggles with the core creative work because "the code doesn't exist in the wild." His domain requires developing novel approaches to understanding neural network internals - work that's fundamentally out of distribution from typical AI training data. AI amplifies his productivity on implementation, but his expertise remains essential for framing research questions and evaluating what constitutes meaningful progress.

These examples point toward a sustainable strategy for Path B: become expert enough in a specialized domain to effectively direct AI on routine work while focusing your cognitive energy on frontier problems.

My basic idea is that technical domains naturally generate an endless supply of increasingly difficult problems. As AI becomes capable of solving today's hard problems, researchers and practitioners respond by tackling even more ambitious challenges. When CTF competitions notice that AI can solve their 11-minute problems, they'll design harder challenges that push beyond current AI capabilities. When AI can optimize existing systems or possibly one day understand neural networks like itself, then we will move on to harder problems that it cannot solve and cannot be trained for. There is the possibility that we will have superhuman AI researchers, but in that case, the world will have much more serious problems than finding employment.

General parting thoughts

Both of the paths I recognized above are explicitly demanding a higher level of quality and competence from computer science students and younger developers. At a more meta level, nearly every interviewee said that younger people have to be more agentic. It is not sufficient to wait for someone (an employer, or a university course) to give you a well-scoped task, complete it to their satisfaction and call it a day. Instead, you need to demonstrate that you can identify problems worth solving, build complete solutions from scratch, and take ownership of outcomes. Rishabh put it bluntly: "if someone hasn't actually built a complete project from scratch, it's a no go from the beginning." The cost of building has become so low that there's no excuse for not having substantial proof of work.

The bitter truth is that AI will lead a two-tier world. Those who do grasp the opportunities, combine their competence with initiative and learn to direct AI effectively will become dramatically more productive than previous generations. Given the rapid pace of change most specific career advice, including mine, is probably wrong. The only thing we know is that the bar is higher, and you have to move faster.