When AI Writes Almost All the Code, What Happens to Software Engineering?当 AI 写了几乎所有代码，软件工程会怎样？

What happens to software engineering when AI writes almost all the code?

This is no longer a hypothetical question — it's a massive trend about to hit the tech industry

This year's winter break was a good time for developers to step away from their day jobs and tinker with side projects, including using AI agents to finish ideas that had been left half-done. That's at least what I did: there were a few features I'd wanted to build for months but never got around to in 2025 — one was a self-serve group subscription feature for large companies, and the other was a custom admin panel I built for The Pragmatic Engineer.

To my surprise, large language models like Opus 4.5 and GPT 5.2 performed remarkably well on the medium-sized tasks I gave them: I ended up shipping a few hundred lines of code to production, and the whole process was just prompting the LLM, reviewing its output, confirming the tests passed (including the new tests I had it write!), and then prompting it for a final round of polish.

Even more surreal, I actually wrote production-grade software from my phone: I connected Claude Code for Web (Anthropic's web-based coding tool that lets you direct AI programming from a phone) to my GitHub, so I could use the Claude mobile app to direct it to modify code, and add and run tests. Claude dutifully created PRs, which triggered GitHub Actions (running the tests Claude itself couldn't run), and I found myself reviewing and merging PRs with new features purely from my phone while traveling. To be honest, this was all low-risk work — all the business logic was covered by automated tests — but I had never before experienced the thrill of "creating" code and pushing it to production purely from a phone.

This experience isn't unique to me — a lot of people share the same feeling. In my view, software engineering tools are undergoing a step change. In this piece — also The Pragmatic Engineer's first article of 2026 — let's explore the current state of things, and what it means for us developers when AI starts writing the vast majority of code.

Today we'll cover:

The latest models bring an "a-ha moment." It's not just developers at AI companies who've noticed the huge leap in model capability — independent developers feel it too.

Why now? The models released in November and December seem to be the tipping point: Opus 4.5, GPT-5.2, and Gemini 3.

The bad news: the value of specialized expertise is declining. Looking ahead, prototyping, mastery of multiple programming languages, or deep specialization in a particular tech stack may all depreciate significantly.

The good news: software "engineers" are worth more than before. The qualities of a Tech Lead are in higher demand, startups will expect engineers to be product-minded, and being a solid software engineer rather than just a "code writer" will pay off more.

The harsh reality: unsettling consequences. Generating more code brings more problems, weak engineering practices will be exposed faster, and developers' work-life balance may become harder to maintain.

Product management vs. software engineering: convergence or divergence? Product managers can now more easily generate software — fewer engineers are needed to achieve a goal — but software engineers similarly need product managers less. The overlap between the two professions will be greater than ever.

1. The latest models bring an "a-ha moment"

Over the past few weeks, several senior software engineers have shared their firsthand experience that AI tools are now powerful enough to generate the bulk of their day-to-day code.

Jaana Dogan, a principal engineer at Google, was impressed by the progress of Claude Code:

"I'm not joking, this isn't funny at all. We've been trying to build a distributed agent orchestration system at Google since last year. Multiple approaches coexisted, and no one could agree on anything, etc. I described the problem to Claude Code, and within an hour it produced what took us until last year to build.

It's not perfect, and I'm still iterating, but this is the stage we're at now. If you're skeptical about coding agents, try using one in a domain you're good at. Build something complex from scratch, and be the judge yourself."

Thorsten Ball, a software engineer at Amp, reflected on his blog (bold in original):

"For fifteen years, I believed I loved writing code, loved typing it out character by character, loved what Gary Bernhardt calls the 'rhythm of typing' — sitting at the editor, fingers clattering on the keyboard.

Now, I'm not so sure anymore.

2025 was a year of deep reflection for me about my relationship with programming. I used to occasionally wonder, 'should I become a Lisp devotee?' But I never once wondered, 'do I even still enjoy typing code by hand?'

By the end of this year I've realized that typing code by hand now makes me feel irritated."

Malte Ubl, CTO of Vercel, said:

"This holiday was insane: I built two large open source projects (one not yet released, the other a complete bash environment implementation for AI agents, written in TypeScript).

I started writing a book

And fixed a bunch of other things too

With Opus 4.5, the world is completely different. None of this would have been possible without it. Now Opus plus Claude Code is like a senior software engineer — you tell it what to do, and it does it. Hard tasks still need supervision, but it's extremely responsive to feedback, basically getting it right with a single nudge.

I don't want to overstate this, but you all really need to let go of your old assumptions. The cost of producing software is approaching zero."

Longtime readers may remember Malte, who previously shared reflections on 20 years of a software engineering career, 11 of them at Google.

You might say all the people quoted above work at companies that sell AI development tools, of course they'd say this. But engineers with no vendor interest at all have made similar observations:

David Heinemeier Hansson (DHH), the creator of Ruby on Rails, described how his attitude toward AI did a complete 180:

"You can't dismiss how amazing AI itself is just because of the sloppy and embarrassing AI output out there. This is the most exciting thing since we networked computers together. If you were pessimistic or skeptical about AI throughout 2025, why not start 2026 with optimism and curiosity instead?

Just last summer, I said on Lex Fridman's show (a well-known tech podcast) that I wouldn't let AI write code directly, but in hindsight, that resistance was because the models simply weren't good enough yet! I spent more time rewriting AI's code than I would have spent writing it myself. Now it's completely reversed."

Adam Wathan, creator of Tailwind CSS, said:

"Now, every time I'm forced to type out precise syntax by hand instead of using AI, it feels like a chore. To my surprise and relief, programming is still fun — even more fun than before.

My biggest problem now is not being able to come up with enough worthwhile ideas to fully take advantage of this productivity boost."

From "AI slop" to shaking up the whole industry

One widely shared "a-ha moment" came from Andrej Karpathy, co-founder of OpenAI. Karpathy hasn't been involved with OpenAI's day-to-day operations for years and is known for his blunt assessments and criticism of AI tools. Last October, on the Dwarkesh podcast (a well-known tech podcast), he summarized his views on AI coding tools (bold in original):

"Overall, the models just aren't there yet. I think the industry is overreaching, trying to pretend everything is great, but it's not.

It's slop.

They don't want to face this, maybe they're busy fundraising or something. I don't know what's going on, but we're in this awkward in-between stage. The models are genuinely impressive, but they still need a lot of polishing.

For now, autocomplete works best for me. But there's some code I'll still use LLM agents to write."

Two months later, that view was completely revised. On December 26th, Karpathy wrote (bold in original):

"I have never felt more behind as a programmer than I do right now.

The profession is being massively "refactored" (yes, he used the programming term to describe the transformation of the profession itself), and the proportion of code programmers contribute by hand keeps shrinking.

I have a feeling that if I could string together all the tools that have emerged over the past year, my capability could increase tenfold. And not capturing this dividend is purely on me.

On top of the existing layers of abstraction, there's now a whole new programmable abstraction layer to master: agents, sub-agents, their prompts, context, memory, modes, permissions, tools, plugins, skills, hooks, MCP, LSP, slash commands, workflows, IDE integrations... You also need to build a complete mental model to grasp the strengths and pitfalls of these fundamentally stochastic, error-prone, opaque, ever-changing entities, which have suddenly become entangled with the traditional engineering that used to work just fine.

Clearly, a powerful alien tool has been handed out to everyone, just without a manual — and everyone has to figure out on their own, amid a magnitude-nine earthquake, how to hold it steady and operate it.

Roll up your sleeves and get to work — don't fall behind."

Boris Cherny, the creator of Claude Code, responded that all the code he committed last month was written by AI:

"Last month was the first time as an engineer that I never opened an IDE at all. Opus 4.5 wrote about 200 PRs, every single line of code. Software engineering is undergoing a fundamental shift, and even for early adopters and practitioners like us, the hardest part is constantly recalibrating our expectations. And this is still only the beginning."

The Pragmatic Engineer previously did an in-depth feature, talking to Boris and other founding team members about how Claude Code was built.

2. Why now?

The model releases in November and December seem to be the true tipping point for AI coding capability:

Gemini 3 (Google, released November 17): Google's strongest coding model to date

Opus 4.5 (Anthropic, released November 24): the company's strongest coding model, now the default model for Claude Code

GPT-5.2 (OpenAI, released December 11): powers Codex, performing on par with Claude Code running on Opus

I've used both Opus 4.5 and GPT-5.2, and both are extremely capable at coding — this isn't a fringe opinion either. Peter Steinberger, a software engineer with about 20 years of experience and founder of PSPDFKit (a well-known PDF processing framework), shared his impressions of GPT-5.2 on his blog:

"The jump from GPT 5/5.1 to 5.2 is huge. After GPT 5.2 came out, I need my own CLI tool 'oracle' (which helps unstick agents when they get stuck) much less often. I still occasionally use GPT 5 Pro for research, but the number of times I have the model 'ask oracle' went from several times a day to a few times a week.

I don't feel bad about it; building oracle itself was fun, and I learned a lot about browser automation and Windows, and finally spent time studying the skills feature, which I'd previously never taken seriously. What this shows is just how much 5.2 has improved on many real-world coding tasks: nearly everything I threw at it, it could one-shot."

Simon Willison, an independent software engineering expert in the LLM space whom I've followed for a long time, made the same observation:

"In my experience, GPT-5.2 and Opus 4.5, both released in November, really do represent a tipping point — where the incremental progress of models suddenly crossed an invisible capability threshold. All at once, a huge batch of harder coding problems became solvable.

Gemini 3 Pro might belong in this group too, but I haven't seen the same degree of astonishment about it from the seasoned engineers I follow."

The very first guest on The Pragmatic Engineer podcast was Simon, under a fitting title: AI tools for software engineers, without the hype — an attitude Simon has consistently practiced.

A crazy prediction came true?

One prediction that many people — myself included — dismissed at the time came from Anthropic CEO Dario Amodei. Last March, he said:

"I think within three to six months, AI will be writing 90% of the code. In another 12 months, we might be living in a world where AI writes almost all the code."

It turned out to come true in December, with 100% of the code Cherny committed to Claude Code being AI-generated. From a skeptical standpoint, you could point out that Claude Code isn't open source, so this claim is hard to verify. And of course, the creator of Claude Code would want to showcase its capabilities. But I've talked with Boris, and I trust him; and my own experience using Claude Code matches what he described: all the code I commit is now generated by having Claude Code write it.

When the code doesn't meet my expectations, I keep prompting the LLM to change it. Like Boris, I no longer write code by hand — not because I can't, but because it's no longer necessary; the model is capable enough. I can still write it by hand, but handing it to the model is clearly faster.

Even with code I know well and can navigate freely in my IDE, I find editing with an agent to be at least as fast as doing it manually, sometimes faster. That said, I still open the IDE from time to time, because I want to confirm to myself that I'm still capable of doing this work by hand.

For my own use case—TypeScript, Node/Express, React, and Postgres—the claim that "AI can generate 90% of the code" is largely true. From what I understand, Go, Rust, and other mainstream languages and frameworks with plenty of training data are increasingly similar. Interestingly, LLMs seem to be quite good at writing C code too, as Redis creator Salvatore Sanfilippo has observed.

The rest of this article proceeds on the assumption that AI coding tools will, this year, reach a level where they can generate roughly 90%+ of the code for many developers and teams. The likeliest early adopters are startups still searching for product-market fit—for whom throwaway work doesn't matter much anyway—and greenfield development, where you're building from scratch without needing to understand an existing codebase.

Of course, in many situations relying entirely on AI coding tools still isn't realistic, whether because it isn't yet good enough for certain codebases or contexts, or because developers deliberately choose not to rely on it.

But it's worth considering: in an environment where nearly all code is generated by AI via prompts rather than typed by developers by hand, where does the software engineering profession go? This will be a seismic shift, but what will it actually look like? Let's go through the good, the bad, and the ugly possibilities, starting with the potential downsides.

3. The bad news: expertise is losing value

Some capabilities once considered high-value will increasingly be handed off to AI:

Prototyping. Platforms like Lovable and Replit position themselves explicitly as tools that help non-technical people build software. In a recent ad, Replit brought in NBA legend Shaquille O'Neal to vibe-code an app called "The Greatest Pickup Lines of All Time":

O'Neal, with zero development experience, vibe-coding. The resulting app is a prototype at best. Source: Replit

That said, with AI tools, product managers, designers, and business people can now build their own prototypes without needing a developer to turn ideas into reality. At the same time, every developer will be expected to quickly produce proof-of-concept apps—this will become table stakes.

Being a programming-language polyglot may be worth less. In the past, engineers fluent in multiple languages were in high demand, because teams typically preferred to hire people with experience in their specific stack. Go teams tended to hire Go experts, Rust teams hired Rust experts, TypeScript teams hired TypeScript experts. To be fair, some more forward-thinking teams didn't care whether candidates already knew their specific language, trusting that good engineers can pick up a new language anytime.

But when AI writes the vast majority of the code, knowing several languages matters less, because any engineer can jump into any codebase and have AI implement a feature—and the AI will likely produce a reasonably solid implementation. Even better, you can have AI explain parts of the codebase to you, ramping up on a new language faster than would be possible without AI.

Is language specialization, and frontend/backend specialization, coming to an end? In the early 2000s, I recall most job ads asking for developers in a specific language: ASP.NET developers, Java developers, PHP developers, and so on. Starting in the mid-2010s, more and more companies began hiring by stack direction instead: backend development, frontend development, native iOS/Android development, cross-platform mobile development. In backend, it became widely accepted for a developer familiar with Go to move to TypeScript, Scala, or Rust. The roles that still cared about specific languages were mainly native mobile development, since iOS and Android frameworks differ enough to require deep mastery of one or the other.

But today, with AI, a backend engineer can prompt their way to decent frontend code, cross-platform code, and even attempt native mobile code. With this tool available, I find it hard to imagine startups still hiring separate frontend and backend developers: they'll just hire one solid expert and trust that person to use AI to solve problems across the whole stack.

Executing well-defined tickets will increasingly be done by AI. Take a clearly described JIRA or Linear ticket—whether a bug report or a small feature request—and have AI implement it. Today, the Cursor team already has an automated pipeline where every Linear ticket is automatically handed to Cursor, which implements it end to end. The developer's job is just to decide whether to merge or keep iterating. The more context provided and the stronger the model, the higher the chance the output can be merged as-is.

This will be a major shift, especially in more hierarchical workplaces, where project managers or product managers have long written detailed tickets for developers to execute.

Refactoring may increasingly be handed to AI. AI is already quite good at refactoring today, and the tooling will only keep improving. Manually refactoring will be far slower than telling AI what kind of refactor you want. Of course, even before AI, modern IDEs already offered powerful refactoring capabilities—renaming functions or classes across an entire codebase, extracting functions, and so on.

Of course, the risk of AI botching things remains, especially for large-scale refactors. So this year, the importance of code-verification methods will only grow.

Does generated code need careful review? It depends. AI-generated code can be verbose, or it might reinvent the wheel instead of reusing existing abstractions. But sometimes that's entirely acceptable—for example, when building a proof of concept, or when program performance doesn't matter much.

Software engineer Peter Steinberger, who's working on a greenfield project, says he barely looks at AI-generated code anymore:

"These days I barely read code anymore. I watch the code flow by, occasionally paying attention to the key parts, but honestly, I don't look at most of it. I know where the various components are, what the overall structure looks like, how the system is designed—usually that's enough.

The decisions that really matter now are language/ecosystem and dependency choices. The languages I use regularly are TypeScript (for web), Go (for CLI tools), and Swift (when I need macOS-specific features or a UI). A few months ago I had zero interest in Go, but then I tried it and found that agents write Go really well, and Go's simple type system makes type-checking run fast."

That said, reading code still matters a lot when extending mature existing software or when you need to guard against security issues. Broadly speaking, if shipped code breaks and affects the business, you'll definitely want both testing and code review.

4. The good news: software engineers are more valuable than before

Developers don't spend all their time writing code—at least not in most workplaces. Atlassian's 2025 State of Developer Experience report (surveying 3,500 people) found that developers spend only 16% of their week, on average, writing code, with the rest going to administrative matters. Looking back on my time at Microsoft, Skyscanner, and Uber, that ratio rings true: I was helping colleagues, doing code reviews, discussing designs and bugs, attending planning meetings, team meetings, all-hands, doing hiring, coordinating with various people, and so on.

So even if AI writes all the code in 2026, that only frees up a small slice of the work week. And obviously, to get AI to write the right code, you first need to give it the right prompt.

The traits of a strong tech lead will almost certainly be in even higher demand. When AI can implement any well-defined ticket, who writes the ticket that gets AI to generate correct code? Writing a "perfect" ticket requires clearly describing two things:

The user requirements of functional work: how the feature should behave, and what should happen in various edge cases

The technical detail of nonfunctional requirements: work related to performance, accessibility, and reliability

Non-technical people can write detailed user-facing tickets, but they're nearly incapable of clearly describing nonfunctional requirements—and this is exactly where software engineering knowledge is becoming ever more critical. Hands-on engineers who can think from the user's perspective and break work into well-defined tasks will be in even higher demand. This is precisely the skill good tech leads already possess. The only change is that even entry-level engineers, if they want to grow quickly in coding, will need to master this skill too.

Testing and test infrastructure skills will matter even more. For agents to be more effective and hallucinate less (that is, invent code or APIs that don't exist), they need feedback loops to verify their own work. Fast-running verification methods include:

Compiling the code (does it compile?)

Running static analysis (does it follow the defined rules?)

Running automated tests (do all tests pass?)

Personally, without unit tests, integration tests, or even end-to-end tests, I can't imagine trusting AI-generated code. Frankly, I currently feel that without targeted prompting, AI agents still aren't that great at writing good tests. When I prompt it to build a feature, I also prompt it with the kinds of tests I want to see, and confirm whether the tests were written as expected.

Tests also need to run as part of the CI/CD pipeline. Of course, as codebases grow, tests may run slower and slower; that's when engineers need to roll up their sleeves to optimize test speed, or figure out which tests are redundant. This skill used to be required only of senior software engineers, but going forward, it may become table stakes for every engineer who generates a large amount of code with AI.

At more startups, "having product sense" may also become a basic requirement. As AI generates more and more code, being clear about what to build becomes more important. Some nimble startups are already hiring "product engineers"—people who can identify what needs to be done themselves, combining the roles of a mini product manager and a software engineer.

Startups adopting the product-engineer model include WorkOS—where roughly 80 engineers are supported by just one product manager, and everyone is a product engineer—and Linear, which had no product manager at all in its early years. Today, the company also hires product engineers.

Making good architectural decisions matters more than ever. The faster and more code gets generated, the more important it becomes to have a clear structure for the software. Should you build a monolith, or independent, testable services? What are the interfaces and boundaries, how do you make each part testable, do you have end-to-end tests, mocks, fakes? The list goes on.

These are all decisions you need to explicitly instruct AI to follow, rather than letting it improvise freely. Otherwise, you'll end up stuck with unmaintainable software—and even AI won't be able to save you.

Tracking and managing tech debt will get more attention. The more code there is, the more tech debt there is, and the more there is to track and manage. Less experienced engineers won't notice every issue, and reliability challenges, performance regressions, and more bugs will quietly accumulate, making it harder and harder to change code without breaking something else. Our earlier guide to paying down tech debt is even more relevant in an age of AI-generated code at scale!

The ability to build reliable, high-performance, scalable, and secure systems will be an extremely valuable skill. When anyone can generate software that's "good enough but could break at any moment," engineers who can consistently produce stable, reliable, high-quality code will be in even higher demand.

You can't just get AI to write secure, high-performance code with a single prompt: you need to know what you want, how to verify nonfunctional requirements, and how to design the architecture, then prompt AI accordingly. Sometimes, you may even need to set AI aside and write the code or configuration yourself to get the details right. Ultimately, knowing when to apply your own expertise is itself a skill.

Being a solid software engineer, not just someone who "writes code," will be more sought-after than before. To sum up what's been said above: the "engineering" part of building software becomes more important. We'll generate more code, and to make that code run reliably, the engineering methodology has to be solid and the feedback loops tight.

Last year, vibe coding rapidly took off among non-technical crowds, and many quickly discovered: even with a super-powerful AI generating the code, building software that actually works well is genuinely hard. Half a year ago, I made a meme about this on LinkedIn:

Writing code quickly isn't the bottleneck to creating high-quality software

5. The ugly reality: unsettling consequences

More code and more resource consumption = more problems? There's already evidence that engineers using AI submit more PRs and produce more code. Here's a comparison of Michael Novati's GitHub activity in 2024 (barely using AI) versus 2025 (using AI heavily):

PR count doubled after using AI. Source: Michael Novati

When Michael worked at Meta, he was the most prolific developer there, and Meta's "Coding Machine" nickname was coined because of him. We did a podcast episode featuring Michael.

And he hasn't slowed down since: last year, at a pace of 400-600 commits per month (15-25 per day!), he contributed over 1,500 new features and more than 800 bug fixes to the startup platform he's building full-time. He shared a more detailed summary.

It's obvious that the more code there is, the more room there is for bugs, security vulnerabilities, and other issues to creep in. This could also lead to more resource consumption—developers and teams continually building more complex services, storing more data, consuming more compute, and so on.

Code quality is getting rougher. Predictably, most teams using AI to generate more code won't raise their quality bar accordingly — at least not at first. Engineers used to review a small number of small PRs; applying the same standard to an ever-growing volume of larger PRs simply isn't realistic.

Early data suggests the quality of code shipped to production is declining: the Cortex 2026 Benchmark Report surveyed over 50 engineering leaders and found that change failure rate (the share of deployments that cause an incident or rollback) rose by 30%.

Weak software engineering practices will surface problems faster. Teams that lack a culture of automated testing, don't follow coding standards, or have weak observability infrastructure will see more regressions pushed to production — and possibly more outages. The reason is simple: delivery is faster now, so the 'bad stuff' hits production more often and more quickly.

Demand may fall for developers who can only 'write code' without broader software engineering skills. If a developer can't offer software engineering skills — like breaking down complex projects, designing architecture for testability and observability, and building scalable, reliable systems — finding a job may get harder. When even a non-technical person can use AI to generate code, the skills developers need must go beyond 'writing code,' since AI has clearly already mastered that.

Will the boundary between work and life get harder to hold? I have a hunch that 2026 will be the year AI agents running in remote virtual sandboxes go mainstream. That means as a developer, you'll be able to give instructions, verify results, and deploy code from a browser or even your phone — no work computer required. This shift will feel like when Slack and other messaging tools arrived on mobile: developers can be reached anytime, anywhere, and can fix bugs from wherever there's a network connection.

This could become a problem. Former Datadog engineer Donovan Dicks points out:

"My worry is that a better mobile experience will further erode the boundary between employees' personal lives and professional responsibilities. A lot of people already feel pressure to install Slack, Teams, and similar apps on their phones and be reachable by their employer at any time — and there's no extra pay for anything done outside normal working hours. Letting engineers get more done while AFK just exposes them to more risk of being squeezed by employers.

As a salaried employee in the US, I've never been paid extra for handling a late-night incident, answering messages during my commute, or doing other work outside working hours. 'Away from the keyboard' is one of the few defenses I have left against more professional responsibility eating into my personal time, especially vacations. If mobile coding workflows become viable and the norm, that defense may disappear.

The advances in these tools are genuinely exciting, and I enjoy playing with them on personal projects, but I'd be much more cautious about bringing them into a professional workflow. I'm curious what kind of impact this will have on the industry as a whole."

Will junior engineers be forced to grow into senior engineers faster? In this new era where AI generates most of the code, the expectations placed on software engineers seem to be shifting to:

Being good at breaking work down into smaller tasks

Being able to work across the stack: from backend to frontend, even mobile

Being product-minded: proactively talking to customers, fixing bugs without being told, proactively suggesting product improvements

Thinking about architectural decisions early, making pragmatic choices in software structure

Being skilled at verifying AI output

Being able to personally handle automated testing and observability

Continuously managing tech debt

These used to be the baseline standards top companies held senior or staff-level engineers to, but they're now becoming baseline expectations for entry-level engineers. Yet before the AI era, entry-level engineers spent years writing lots of code and gradually picked up these skills by working alongside more senior colleagues.

Will this shift push new graduates to 'mature' faster — skipping the 'writing code' stage that AI already handles well, and jumping straight into the engineering part of software? If so, does that have to be a bad thing? In my experience, new graduates are capable and quick learners, and I believe many of them will do quite well taking on roles that used to be reserved for senior developers.

Will a computer science education become a hard requirement for breaking into the industry? If I were a hiring manager looking to hire a new graduate, I'd need someone who understands 'advanced' concepts. They'd need to grasp software architecture patterns, automated testing, and the concept and importance of tech debt — with zero years of industry experience. Oh, and they'd probably also need experience using AI tools on a team project. That's a pretty high bar.

But in fact, some university curricula already provide this. Over a 3-5 year program, they balance theory and practice and organize team projects. Meanwhile, top schools like Harvard are already offering courses on large language models. Other universities will surely follow quickly.

In a world where writing code is worth less but the other parts of software engineering are worth more, academic education centered on software engineering and computer science could become an unavoidable gateway into the industry. Universities also serve as a kind of 'spam filter': when AI-generated applications flood hiring pipelines, partnering directly with local universities gives employers more confidence that a candidate is a real person.

Someone will have to be accountable for the explosion of code and software. As mentioned earlier, we're almost certain to see more code generated, more software shipped, and more maintenance work needed! This is undoubtedly good news for infrastructure providers — cloud vendors, infrastructure tooling companies, and software correctness verification tools will all benefit.

And for any production software that's live, when something goes wrong, someone has to be accountable. I don't think that someone will be a non-technical person, but rather professional software engineers who understand the code AI tools generate, can maintain it, and have the ability and knowledge to take responsibility for code deployed to production based on their own prompts.

6. Product management vs. software engineering: merge or diverge?

I've seen several product managers get excited about this shift, thinking that since AI can generate code from a spec, maybe product managers won't need software engineers to build software. But I don't think that's how it'll play out — instead, the boundary between software engineering and product management may become even blurrier than before:

Software engineers become more product-minded and get closer to customers. For example, they can quickly fix bugs customers report without needing a product manager to triage or get involved

Product managers become more hands-on, building prototypes themselves to demo to customers — sometimes without engineers involved at all, and occasionally even submitting their own bug fixes for engineers to merge

I also expect engineering teams to become smaller and more efficient, moving away from the more formal handoff model of the past — like a product manager writing a PRD and tossing it over to the engineering team to implement a new feature.

Linear co-founder Karri Saarinen describes this shift as the disappearance of 'middle-layer software work' — the 'writing code' stage that used to eat up so much time:

"Pure coding agent workflows can now produce usable code directly from goals, context, and tasks. They run more independently, you need to touch the code less and less, and reliance on the IDE keeps shrinking. The IDE is turning from a writing tool into a code browser.

As these systems keep evolving, this middle layer keeps getting thinner. Less and less time is spent manually translating intent into implementation.

What to actually build remains the most important question. (...)

[Software] design, in this sense, isn't about artifacts or tools. It's about shaping and sharpening clarity of intent through creativity, exploration, research, and discussion. It's about deciding what matters, what constraints apply, and what tradeoffs are acceptable. Good product work is the pursuit of a kind of clarity — what will make this execution actually meaningful.

In this era, directing and managing the work of agents is itself becoming a craft.

Writing code feels less like constructing a solution and more like creating the emergent conditions for a good solution."

One thing seems certain: as more powerful AI coding tools drive the evolution of software engineering, product management will evolve right along with it.

Summary

If someone wants to push back on the claim I opened with — that AI will write over 90% of the code on many teams — that's entirely fair. I have in fact worked at large tech companies where developers didn't write that much code to begin with; the complexity all lived outside the code itself! In environments like that, AI is unlikely to make much of a difference or have much impact.

Even my own 'a-ha moment' happened on a relatively simple codebase — one with good engineering practices (everything had tests) and a product that wasn't high-stakes, making it easy to experiment freely.

But still, the latest AI tools really did hit the quality bar I care about — 'code as good as what I'd write myself' — and that matters a lot!

It's predictable that early-stage startups will hand the reins to AI, letting it write all the code via prompts — at least until they find product-market fit. This piece explores what happens as that pattern spreads and hand-typing code in an IDE becomes as time-consuming and laborious as writing code today in a text editor with no autocomplete — something nobody does anymore.

The good news: the more a team relies on AI to generate code, the more the fundamentals of software engineering matter. More code means more problems, and those problems need to be caught earlier and addressed systematically. That's exactly what good software engineering has always done — and now more than ever.

I think this is a good thing: AI will push people to seriously think about verification (after all, you can't fully trust AI), observability (confirming things actually work in production), architecture (we'll be generating more code, faster, and it needs to be organized sensibly), and constraints (as delivery speeds up, you'll hit ceilings on resource usage, performance, and reliability that much faster).

The bad news: change could come very fast. It's been just over a year since Claude Code went from an idea in Boris Cherny's head to what it is now, and similar tools — OpenCode, Codex, Factory, Amp, Cursor, and more powerful agents besides — are already changing how software gets written. Change has always been the norm in tech, but I don't recall it ever moving this fast, or sweeping across the entire industry all at once.

There's also a sense of loss. I'm slowly coming to accept the likely reality that, from now on, most of the code I push to production will be written by AI. It's already writing faster than I can, and the results are about as good as what I'd write by hand. For languages and frameworks I'm less familiar with, it's even better than I am.

It feels like something precious is being taken away, and quite suddenly. Writing code well takes an enormous amount of effort — learning to write code that actually runs, learning to read and understand complex code, learning to debug and fix code when it breaks. I still remember how intimidating my first 'real' programming class in college (learning C) felt, remember feeling lost facing a complex codebase in my first job, remember spending years honing this craft through practice, learning from other developers, reading books and blogs. Once you reach a fairly high level, you have a valuable and easily verifiable skill — code that runs is the proof!

Some of my fondest memories of building software are about writing code. Getting into flow, juggling several ideas in my head at once, typing them out at speed, then compiling and running the code and seeing — 'great' — everything working as expected!

Honestly, it's always been a love-hate relationship — the intense focus that writing complex code demands is itself something you both love and hate. And then there's the friction of time estimates: when you're deep in flow wrestling with a hard problem, time just moves differently.

Now, all of that looks set to become a thing of the past.

I can't help but wonder: will there still be that sense of accomplishment that comes from the difficulty of writing complex code? Yes, AI is convenient, but there's also something being lost.

Or maybe, once AI agents take over, 'getting into flow' will shift toward thinking about higher-level problems while directing AI to write the more complex code?

Either way, an earthquake-level shift also means exciting new opportunities. I've never before been so clearly aware, in the moment, that a major transformation was happening. This time, I'm convinced my own way of coding will change dramatically in 2026, and the ripple effects will be too numerous to count.

Change can create better career opportunities and open new paths to success, while also bringing plenty of excitement and anxiety along with it. My guess is that five years from now, demand for software professionals will be even higher than it is today, partly because of the explosion in the amount of software AI is creating. With these more powerful new tools, we're all figuring out — in this future — what world-class software engineering actually means.

What do you think about how more powerful AI tools might change our profession? Feel free to leave a comment below.