When AI writes almost all code, what happens to software engineering? No longer a hypothetical question, this is a mega-trend set to hit the tech industry GERGELY OROSZ JAN 06, 2026 ∙ PAID 289 21 27 This winter break was an opportunity for devs to step back from day-to-day work and play around with side projects – including using AI agents to juice up those half-baked or incomplete ideas. At least, that’s what I did with a few features I’d meant to build for months, but didn’t get around to during 2025: related to self-service group subscriptions for larger companies, and my custom-built admin panel for The Pragmatic Engineer. Unexpectedly, LLMs like Opus 4.5 and GPT 5.2 did amazing jobs on the mid-sized tasks I assigned them: I ended up pushing a few hundred lines of code to production simply by prompting the LLM, reviewing the output, making sure the tests passed (and new tests I prompted also passed!), then prompting it a bit more for some final tweaking. To add to the magical feeling, I then managed to build production software on my phone: I set up Claude Code for Web by connecting it to my GitHub, which let me instruct the Claude mobile app to make changes to my code and to add/run tests. Claude duly created PRs that triggered GitHub actions (which ran the tests Claude couldn’t) and I found myself reviewing and merging PRs with new functionality purely from my mobile device while travelling. Admittedly, it was low-risk work and all the business logic was covered by automated tests, but I hadn’t previously felt the thrill of “creating” code and pushing it to prod from my phone. This experience, also shared by many others, suggests to me that a step change is underway in software engineering tooling. In this article – the first of 2026 for this publication – we explore where we are, and what a monumental change like AI writing the lion’s share of code could mean for us developers. Today, we cover: Latest models create “a-ha” moments. It’s not just devs working at AI vendors who noticed much more capable models, but also independent software engineers. Why now? Model releases in November and December seem to have been the tipping point: Opus 4.5, GPT-5.2 and Gemini 3. The bad: declining value of expertise. Prototyping, being a language polyglot or a specialist in a stack are likely to be a lot less valuable, looking ahead. The good: software engineers more valuable than before. Tech lead traits in more demand, being more “product-minded” to be a baseline at startups, and being a solid software engineer and not just a “coder” will be more sought-after than before. The ugly: uncomfortable outcomes. More code generated will lead to more problems, weak software engineering practices start to hurt sooner, and perhaps a tougher work-life balance for devs. Product management vs software engineering: merge or separation? Product managers can now generate software easier – needing fewer engineers to realize their goals – but software engineers also need less product management. Both professions are set to overlap with another more than before. 1. Latest models create “a-ha” moments Over the past few weeks, some experienced software engineers have shared personal “a-ha” moments about how AI tooling has become good enough to use for generating most of the code they write. Jaana Dogan, principal engineer at Google, was very impressed by how far Claude Code has come: “I’m not joking and this isn’t funny. We have been trying to build distributed agent orchestrators at Google since last year. There are various options, not everyone is aligned, etc. I gave Claude Code a description of the problem, it generated what we built last year in an hour. It’s not perfect and I’m iterating on it, but this is where we are right now. If you are skeptical of coding agents, try it on a domain you are already an expert in. Build something complex from scratch where you can be the judge of the artifacts”. Thorsten Ball, software engineer at Amp reflected (emphasis mine): “For more than 15 years, I thought I loved writing code, loved typing out code by hand, and loved the “cadence of typing”, as Gary Bernhardt once called it; sitting in front of my editor with my fingers click-clacking on my keyboard. Now, I’m not so sure. 2025 was the year in which I deeply reconsidered my relationship to programming. In previous years, I had the occasional “should I become a Lisp guy?”, for sure; but not the question “do I even like typing out code?” What I learned over the course of the year is that typing out code by hand now frustrates me”. Malte Ubl, CTO at Vercel: “It’s been a crazy holiday period: I built 2 major open-source projects (one unreleased, and the other a full implementation of a bash environment in TypeScript for use by AI agents). I started writing a book I fixed a bunch of other things It’s a very different world now that we’re in Opus 4.5 world, and these would absolutely not have been possible without it. Opus + Claude Code now behaves like a senior software engineer whom you can just tell what to do, and it’ll do it. Supervision is still needed for difficult tasks, but it is extremely responsive to feedback and then gets it right. I don’t want to be too dramatic, but y’all have to throw away your priors. The cost of software production is trending towards zero”. Longtime readers may recall Malte from his reflections on 20 years in software engineering, including 11 at Google. One could claim that the voices above have an interest in this topic given they work at companies selling AI dev tools. But engineers with no pull towards any vendor also made similar observations: David Heinemeier Hansson (DHH), creator of Ruby on Rails, described how his stance on AI has flipped due to the improved models: “You can’t let the slop and cringe deny you the wonder of AI. This is the most exciting thing we’ve made computers do since we connected them to the internet. If you spent 2025 being pessimistic or skeptical about AI, why not start 2026 with optimism and curiosity? Just last summer, I spoke with Lex Fridman about not letting AI write any code directly, but it turns out part of this resistance was simply based on the models not being good enough at the time! I spent more time rewriting what it wrote, than if I’d done it from scratch. That has now flipped.” Adam Wathan, creator of Tailwind CSS, reflected: “Any time I have to type precise syntax by hand now [instead of using AI] feels like such a tedious chore. Surprisingly and thankfully, programming is still fun, probably more fun [with LLMs]. My biggest problem now is coming up with enough worthwhile ideas to fully leverage the productivity boost.” From “AI slop” to rocking the industry One widely circulated “a-ha” moment has been from Andrej Karpathy, a cofounder of OpenAI. Andrej has not been involved in OpenAI for years, and is known to be candid in his assessment and critique of AI tools. Last October, he summarized AI coding tools as overhyped on the Dwarkesh podcast (emphasis mine): “Overall, the models are not there. I feel like the industry is making too big of a jump and is trying to pretend like this is amazing, and it’s not. It’s slop. They’re not coming to terms with it, and maybe they’re trying to fundraise or something like that. I’m not sure what’s going on, but we’re at this intermediate stage. The models are amazing. They still need a lot of work. For now, autocomplete is my sweet spot. But sometimes, for some types of code, I will go to an LLM agent”. Two months on, that view had been thoroughly revised, with Karpathy writing on 26 December (emphasis mine:) “I’ve never felt this much behind as a programmer. The profession is being dramatically refactored as the bits contributed by the programmer are increasingly sparse. I have a sense that I could be 10X more powerful if I just properly string together what has become available over the last ~year, and a failure to claim the boost feels decidedly like a skill issue. There’s a new programmable layer of abstraction to master in addition to the usual layers involving agents, subagents, their prompts, contexts, memory, modes, permissions, tools, plugins, skills, hooks, MCP, LSP, slash commands, workflows, IDE integrations, and a need to build an all-encompassing mental model for strengths and pitfalls of fundamentally stochastic, fallible, unintelligible and changing entities suddenly intermingled with what used to be good old fashioned engineering. Clearly some powerful alien tool was handed around, except it comes with no manual and everyone has to figure out how to hold and operate it while the resulting magnitude 9 earthquake is rocking the profession. Roll up your sleeves to not fall behind”. The creator of Claude Code, Boris Cherny, responded, sharing that all of his committed contributions last month were AI-written: “The last month was my first as an engineer when I didn’t open an IDE at all. Opus 4.5 wrote around 200 PRs, every single line. Software engineering is radically changing, and the hardest part even for early adopters and practitioners like us is to continue to re-adjust our expectations. And this is *still* just the beginning”. We previously did a deepdive on how Claude Code was built with Boris and other founding members of the team. 2. Why now? Model releases in November and December seem like the tipping point where AI got really good at generating code: Gemini 3 by Google (17 November): Google’s best coding model to date Opus 4.5 by Anthropic (24 November): the best coding model from the company, which has become the default model for Claude Code GPT-5.2 by OpenAI (11 December): powering Codex, it’s similarly impressive as Claude Code with Opus I’ve used both Opus 4.5 and GPT-5.2 and they seem very competent at coding, which isn’t a niche opinion. Here’s Peter Steinberger, a software engineer with ~20 years’ experience and the creator of PSPDFkit, gave his impression of GPT-5.2: “The step from GPT 5/5.1 to 5.2 was massive. Now that GPT 5.2 is out, I have far fewer situations where I need [a custom-built CLI agent called ‘oracle’ to get the agent unstuck]. I do use [GPT 5] Pro myself sometimes for research, but the cases where I asked the model to “ask the oracle” went from multiple times per day to a few times per week. I’m not mad about this; building ‘oracle’ was super fun and I learned lots about browser automation, Windows, and finally took time to look into skills, having dismissed the idea for quite some time. What it does show is how much better 5.2 got at many real-life coding tasks: it one-shots almost anything I throw at it”. Simon Willison is an independent software engineering expert in LLMs whom I pay attention to, and he pointed out the same: “It genuinely feels to me like GPT-5.2 and Opus 4.5 in November represent an inflection point - one of those moments when the models get incrementally better in a way that tips over an invisible capability line. Suddenly, a whole bunch of much harder coding problems open up. It’s possible Gemini 3 Pro should be included in that group as well, but I’m not seeing quite the same level of astonished buzz from hardened software engineers around that model that I am for the other two”. The first-ever The Pragmatic Engineer Podcast episode was with Simon, fittingly entitled AI tools for software engineers, but without the hype – and Simon continues to live up to that sentiment. Wild prediction coming true? One forecast which many – including me – were sceptical about was made by Anthropic’s CEO, Dario Amodei, last March, when he said: “I think we will be there in three to six months, where AI is writing 90% of the code. And then, in 12 months, we may be in a world where AI is writing essentially all the code”. Yet it came to pass in December, when 100% of Cherny’s code contributed to Claude Code was AI-written. Playing devil’s advocate, one could point out that Claude Code is closed source, so the claim is hard to validate. And of course, the creator of something like Claude Code wants to showcase its high-performance capabilities. But I’ve talked with Boris and trust him; also, my own experience of using Claude Code tallies with his: I let Claude Code generate all the code I end up committing. When the code is not how I want it, I do more prompting to get the LLM to fix it. Like Boris, I’ve ceased writing code by hand because I don’t have to do it, and the models seem capable enough. I can still do it, but it’s simply faster to leave it to the model. Even for code that I know well enough and can navigate in my IDE, I’ve noticed that prompting the agent can get edits done just as quickly as I would do it, if not faster. Nonetheless, I do find myself going to the IDE as I like to know that I can do the work. For my own use case, the claim feels true enough that AI can generate 90% of the code I write, using TypeScript, Node/Express, React, and Postgres as technologies, in my case. I understand the same is increasingly true of languages like Go, Rust and other popular languages and frameworks which LLMs have plenty of training data for. Interestingly, LLMs seem to be pretty good at C as well, as observed by Redis creator, Salvatore Sanfilippo. The remainder of this article assumes AI coding tools WILL become good enough to generate ~90%+ of the code for many devs and teams, this year. The most likely candidates for this landmark look like being startups seeking product-market fits – for whom throwaway work is no big deal – and also greenfield development projects, where no existing codebase needs to be ingested or understood before building something new. Of course, there will also be plenty of occasions when it won’t make sense to totally rely on AI coding tools, either due to them not working well enough in some codebases or contexts, or when devs purposefully choose not to lean on them. It’s worth exploring the directions in which the software engineering profession could go in environments where almost all code is generated by AI via prompts, rather than being typed out by a developer. This would be a sea change that impacts the profession, but how? Let’s run the rule over the good, bad, and the ugly possibilities, starting with potential negatives. 3. The bad: declining value of expertise Some things that used to be valuable will be mostly delegated to the AI: Prototyping. Platforms like Lovable and Replit explicitly advertise themselves as ways for nontechnical folks to build software. In a recent ad, Replit teamed up with legendary NBA star Shaquille O’Neal, who vibe-coded an app for getting the top 5,000 pickup lines in online history, among others: Shaq vibe coding with no development experience. The apps were prototypes at best. Source: Replit Still, with AI tools, product folks, designers, and business people can build their own prototypes, and no longer need a dev to make an idea real. Alongside this, it’ll become a baseline expectation for each and every developer to be able to generate concept apps fast. Being a language polyglot will probably be less valuable. Engineers who are experts in multiple languages have traditionally been coveted because engineering teams often like to hire experts in their own stack. So, a team using Go would often prefer to hire senior engineers with Go knowledge, and the same with Rust, Typescript, etc. I’d qualify this with the fact that some forward-thinking teams ignore candidates’ expertise in their specific language and assume that competent engineers can pick up languages on the go. But with AI writing most of the code, the advantage of knowing several languages will become less important when any engineer can jump into any codebase and ask the AI to implement a feature – which it will probably take a decent stab at. Even better, you can ask AI to explain parts of the codebase and quickly pick up a language much faster than without AI tools. The end of language specializations and frontend/backend specializations? In the early 2000s, I recall most job adverts wanted candidates for a specific language: ASP.NET developer, Java developer, PHP developer, and so on. From the mid-2010s, more companies started to hire based on specialization in the stack: backend developer, frontend developer, native iOS/Android developer, cross-platform mobile developer. On the backend, it became accepted that a dev who knew a language like Go pretty well could pick up Typescript, Scala, Rust or other languages as necessary. Roles where for specific languages still matter were for native mobile, where the iOS and Android frameworks were different enough to require deep expertise in one or the other. But today with AI, a backend engineer can prompt decent frontend code, cross-platform code, or even attempt native mobile code. With this tool, I struggle to foresee startups hiring separate frontend and backend devs: they’ll just hire a specialist whom they trust will use AI to unblock themself across the stack. Implementing a well-defined ticket is something AI will increasingly do, like taking a JIRA or Linear ticket that’s well-defined – like a bug report or small feature request – and implementing it. Even today, the team at Cursor has an automation where all Linear tickets are automatically passed to Cursor, which one-shots an implementation. A dev can then choose to merge it or iterate on it. The more context is passed and the better the models are, the more likely the output will be mergeable. This will be a major shift, especially in hierarchical workplaces where project or product managers have long been writing detailed tickets for devs to implement with no questions asked! Refactoring will probably be ever more delegated to AI. It’s already pretty good at refactoring and the tools will probably only get better. Refactoring by hand will be much slower than spelling out what type of refactor you want the AI to do. Of course, in the pre-AI era, modern IDEs also offered powerful refactoring capabilities for speeding up tedious tasks like renaming functions or classes that did the renaming across the entire codebase, extracting functions. Of course, there will always be the risk that AI messes things up, especially with large refactorings. This is why having ways to validate code will surely be even more important this year. Paying careful attention to generated code – in some cases? Generating code from AI prompts can lead to verbose code, or duplication of existing code instead of using an abstraction. But there are times when this is perfectly acceptable, such as when building proof of concepts, or when topics like program efficiency are unimportant. Software engineer Peter Steinberger is building greenfield software, and said he’s stopped reading code generated by AI: “These days, I don’t read much code anymore. I watch the stream and sometimes look at key parts, but I gotta be honest, most code I don’t read. I do know where components are and how things are structured, and how the overall system is designed; that’s usually all that’s needed. The important decisions these days are language/ecosystem and dependencies. My go-to languages are TypeScript for web stuff, Go for CLIs and Swift if it needs to use macOS stuff, or has UI. Go wasn’t something I gave the slightest thought even a few months ago, but eventually I played around and found that agents are really great at writing it, and its simple type system makes linting fast”. Even so, reading code will remain important when extending existing mature software, or when security issues need to be avoided. In general, if shipped code doesn’t work and hurts the business, then you’ll want to both test and review it for correctness. 4. The good: software engineers more valuable than before It’s no trade secret that devs don’t spend all our time coding – at least not in most workplaces. Atlassian’s State of Developer Experience 2025 report, filled out by 3,500 respondents, found the average developer spends 16% of the working week on coding, and the rest on admin tasks. Thinking back to my time at the likes of Microsoft, Skyscanner, and Uber, that percentage feels right: I was helping others, doing code reviews, discussing design and bugs, attending planning, team, and general meetings, recruiting, getting in touch with others, and more. So, even if AI writes all the code in 2026, it would only free up a fraction of the average working week. But obviously, for AI to write the right type of code it first needs the correct prompts. Tech lead traits will almost certainly be more in-demand. When AI can implement any well-defined ticket, who will write the ticket that makes AI correctly create the code? To write the “perfect” ticket you need to outline both: User requirements for functional work: how the feature should work, what should happen in different edge cases Technical details for nonfunctional requirements like performance, accessibility, reliability-related work)? Someone nontechnical can write detailed tickets for user-facing work, but they are highly unlikely to be able to articulate nonfunctional requirements, which is where software engineering knowledge is increasingly critical. Also, hands-on engineers who can empathize with users and break down work into well-defined tasks will be more in-demand in this new world, I expect. As it happens, this is an ability already possessed by good tech leads. The only change is that even entry-level engineers will also have to master this if they want to progress faster in the coding part of the job. Getting good at testing and test infrastructure will become more important. For an agent to be more effective and less prone to hallucinations, it needs feedback loops that verify its work. Examples of these that are quick to run include: Compiling the code (does it compile?) Running static analysis (are defined rules followed?) Running automated tests (do all tests pass?) Speaking personally, I cannot imagine trusting AI-generated code without unit, integration, and perhaps end-to-end tests, too. For better or worse, I still see AI agents as not particularly impressive at writing good tests without targeted prompts. When I prompt building a feature, I also prompt the types of tests I want to see, and verify that they are written as expected. Tests then need to be set up to run as part of CI/CD. Of course, over time tests may slow down a larger codebase; in that case an engineer shall need to roll up their sleeves and look into speeding them up, or establishing whether there are redundant tests. This is a skillset that used to be expected of senior software engineers, but going forward, it may become a baseline for all software engineers who generate lots of code with AI. Being more “product-minded” could also be a baseline at more startups. As AI generates more code, it becomes increasingly important to specify what to build. Already, nimble startups are hiring “product engineers” who can create their own work, and be a blend of mini-product manager and software engineer. Examples of startups employing product engineers include WorkOS – where there is one PM to around 80 engineers, and everyone is a product engineer – and also Linear, which had no product managers during its first few years. Today, the company hires product engineers. Making good architecture decisions becomes even more important. With more code created faster, it’s crucial to specify the structure of the software. Are you building software as a monolith, or as standalone, testable services? What are the interfaces and boundaries, how do you make parts of the software testable, are there end-to-end tests, mocks, fakes? The list goes on. All these are decisions to instruct the AI to follow, rather than let it dream up whatever structure it can. Otherwise, you’ll risk being stuck with hard-to-maintain software – even with AI. Tracking and dealing with tech debt will have more focus. The more code there is, the more tech debt you will have, so there will be plenty to track and deal with. Inexperienced engineers will not notice everything, meaning that reliability challenges, performance degradation, and more bugs will creep in, as well as it becoming more challenging to modify the code without breaking things. Our guide to paying down tech debt applies even more when generating lots of code with AI! Being able to build for reliability, performance, scale, and security will be a highly-prized skill. When anyone can generate software that sort of works until it doesn’t, there will be more demand for engineers who produce quality work that always works as expected. You cannot prompt an AI to create secure, performant code: you need to know what you want, how to validate the nonfunctional requirements, architect the code, and prompt the AI accordingly. You might also need to throw away the AI and get down to writing code or configuration by hand in order to get the details right. Basically, it pays to know when to use your own expertise. Being a solid software engineer and not just a “coder”, is going to be more sought-after than before. Summarizing all the above, the engineering part of building software becomes a lot more important. We’ll be generating a lot more code, and for it to work well the engineering approach needs to be sound, and the feedback loops tight. Last year, vibe coding spread fast among nontechnical folks, many of whom soon discovered that it’s hard to build software that actually works, even though super–powered AI had generated their code for them. Six months ago, I made a meme about this: Writing code quickly isn’t the bottleneck in creating quality software 5. The ugly: uncomfortable outcomes More code & more resource usage = more problems? Engineers using AI will generate more pull requests and more code, and there’s already evidence. Below is Michael Novati’s GitHub activity in 2024 (with little AI usage) vs 2025 (with a lot more AI usage): Twice as many pull requests from using AI. Source: Michael Novati Michael was the most productive developer at Meta during his time there, and the company’s “Coding Machine” archetype was created after him. We did a podcast episode with Michael. He has not slackened the pace since: last year, he committed more than 1,500 new features and 800+ bugfixes at a pace of 400-600 commits per month (15-25 per day!), as part of the startup platform he works on, fulltime. He has shared a more detailed summary. Obviously, more code means more opportunities for bugs, security issues, and other problems. It could also mean more resource usage, due to devs and teams creating ever-more complex services, storing more data, using more compute, etc. Sloppier code. It can be predicted that the quality bar won’t rise in most teams which use AI to generate more code – at least, not initially. It’s impractical for engineers to review ever more and larger pull requests to the same standard as they did fewer, smaller ones. Early data shows code pushed to production is lower quality: the Cortex 2026 Benchmark Report surveyed 50+ engineering leaders, and found that change failure rates (the percentage of deployments that cause outages or rollbacks) has increased 30%. Weak software engineering practices start to hurt sooner. Teams that do not have a culture of automated testing, don’t follow coding guidelines, or have poor observability in-place will see more regressions shipped to production, and perhaps more outages as well. This is because the pace of shipping will speed up, and the bad stuff will hit production more often and also more rapidly. “Coders” who aren’t software engineers could be in less demand. If a developer doesn’t bring software engineering skills to the table, such as being able to break down complex projects, architect for testability and observability, and build for scale and reliability – it might be harder to find employment. When a nontechnical person can use AI to generate code, developers need skills that go beyond simply writing code because evidently the AI can already do that. Tougher work-life balance? I sense that 2026 will be when AI agents running in virtual sandboxes, remotely, become a big thing. This means that as a dev, it will be possible to prompt, validate, and deploy code from a web browser, or the phone – with no work laptop required. This change would be similar to when communications tools like Slack went mobile: devs can now be reached any time and do bugfixes from anywhere with an internet connection. This could become a problem, as former Datadog engineer, Donovan Dicks, noted: “I worry about how improving the mobile experience may erode more boundaries between employees’ personal lives and their professional responsibilities. Many people already struggle with the pressure to have Slack, Teams, etc, on their devices and to be accessible to their employers 24/7, all while receiving no additional compensation for work done off the clock. Enabling engineers to do even more, while AFK (away from keyboard) policies also expose them to the risk of more exploitation from employers. As a salaried employee in the US, I have never received additional compensation for late nights resolving incidents, the messages answered on commutes, or other tasks I’ve done outside of my normal working hours. Being AFK is one of few remaining defenses against even more professional responsibilities encroaching on my personal time, especially on holiday. If mobile coding workflows become viable and commonplace, this defense may disappear. The developments in tooling are exciting and while I enjoy experimenting with them for personal coding projects, I am more cautious about introducing them into my professional workflow. I’m curious to see how this will affect the industry”. Juniors pushed to become seniors fast? The new expectations on a software engineer who generates most of their code with AI seem to be: Break down the work well, into smaller pieces Work across the stack: from backend through frontend, and even mobile Be product-minded: talk with customers, fix bugs without needing to be asked, and bring product suggestions to the table Think about architecture decisions early, and make pragmatic choices in structuring the software Be good at verifying AI output Be hands-on with automated testing & observability Keep up with tech debt These used to be baselines for senior or staff-level engineers at top-tier companies, and now will become baseline expectations for entry-level engineers. However, pre-AI, entry-level engineers spent a few years writing a lot of code, and picking up these skills by working with more experienced devs, and learning from them. Will this change push new grads to “mature” faster: skip the “coding” part (that AI is good at) and jump straight to the engineering parts in software? And if so, is this necessarily bad? From my experience, new grads are very capable and eager learners, so I suspect many will thrive at taking on roles that used to be the preserve of devs with longer tenures. Computer science education increasingly required for new hires? If I were a hiring manager looking to hire a new grad, I would need someone with an understanding of “senior-level” concepts. They would need to come in with zero years of industry experience, and know about software architecture patterns, automated testing, and the concept and importance of tech debt. Oh, and they should probably have worked with AI tools on building projects as part of a team. All that seems like a tall order. But it turns out, some university programs already deliver this. In the span of 3-5 years, they teach both theory and practice and organize group projects. Meanwhile, leading places like Harvard offer LLM-related courses. Other universities will surely catch up soon. In a world where writing code is less valuable, but all the other parts of software engineering are more valuable, an academic education focused on software engineering and computer science could become a non-negotiable barrier for entry into the industry. Universities also double as “spam filters”: as AI applications clog up direct recruitment processes, partnering directly with local universities gives employers more certainty that candidates are authentic. A massive explosion in code and software for which someone must be accountable. As covered above, we will almost certainly see a lot more code generated, more software shipped, and much more maintenance to be done! This will all surely be a boon for infrastructure providers like cloud businesses, infrastructure tooling, and tooling that verifies software’s correctness. And for any and all production software, the buck needs to stop somewhere when things go wrong. I don’t expect this shall be a nontechnical person, but rather professional software engineers who understand the software generated by these AI tools and can maintain it, and who have the skills and knowledge to be accountable for code deployed to production based on their prompts. 6. Product management vs software engineering: merge or separation? I’ve seen several product managers get pretty excited about this change because AI generating code to spec could mean that product managers can build software without software engineers. But I actually think this is not what will happen: instead, software engineering and product management might overlap even more than before: Software engineers become a lot more product-minded and stay closer to customers. For example, they can fix bugs reported by customers rapidly without needing triaging or input from product managers Product managers become a lot more hands-on and build prototypes to show customers, perhaps without engineering input, and can occasionally also submit bugfixes for engineers to merge I’d also expect that engineering teams become smaller and more efficient in contrast to the more formal handoffs of the past, like product managers sharing a Product Requirements Document (PRD) for an engineering team to start building a new feature. Linear cofounder, Karri Saarinen, expressed this shift as the disappearance of “middle software work” aka the writing of the code – which used to take a long time: “Pure coding agent workflows can now produce working code from goals, context, and tasks. They operate more independently, requiring you to touch the code less and rely on the IDE less. The IDE becomes more of a code viewer than a writing tool. As these systems improve, this middle becomes thinner. Less time is spent manually translating intent into implementation. What actually needs to be built is still the important question. (...) [Software] design, in this sense, is not about artifacts or tools. It is about forming and shaping clarity of the intent through ideas, exploration, research, and discussion. It is about deciding what matters, what constraints apply, and what tradeoffs are acceptable. Good product work is seeking clarity [about] what would make this execution actually matter. In this era, directing and managing agent work becomes the craft. Writing code is less like constructing a solution and more like setting up the conditions for a good solution to emerge”. One thing seems certain, as software engineering evolves with more capable AI coding tools, so will product management, too. Takeaways It would be fair to push back on the claim at the top of this article that AI will write 90%+ of the code in many teams. Indeed, I’ve worked in large tech orgs where devs already wrote very little code in general, and where the complexity lay in navigating everything around it! In those environments, it’s unlikely that AI will help much or make a big impact. Even my own “a-ha moment” came when working on a simple codebase with good engineering practices (tests for everything), and a product that’s pretty low risk and easy to experiment with. Still, the latest AI tools have cleared my own quality bar of “code as good as I’d have written it”, and this is a big deal! It’s possible to foresee early-stage startups handing over the reins to AI to write all their code via prompts; at least until they get to product-market fit. This article has asked what happens when or if this approach spreads and makes it a waste of time and effort to type out code in an IDE, like it has become impractical to write code in a text editor with no autocomplete. The good news is that software engineering fundamentals should become more important, the more a team relies on AI to generate code. More code leads to more problems which need to be caught earlier, and dealt with systematically. This is what good software engineering is about, and always has been. I see it as a positive that AI will push folks to think about verification (you cannot truly trust the AI, after all), observability (verifying that the thing actually works in production), architecture (we’ll generate more code, faster, and it’ll need to be organized) and constraints (when shipping faster, you hit constraints faster around resource usage, performance, reliability, etc.) The bad news is that change will probably be rapid. It’s barely been a year since the idea of Claude Code was born in Boris Cherny’s head, and already similar tools like OpenCode, Codex, Factory, Amp, Cursor, and more capable agents are changing how software is written. Change has always been part of working in tech, but I cannot recall it being this fast, or happening across the whole industry at once! There’s also some grief. I’m coming to terms with the high probability that AI will write most of my code which I ship to prod, going forward. It already does it faster, and with similar results to if I’d typed it out. For languages/frameworks I’m less familiar with, it does a better job than me. It feels like something valuable is being taken away, and suddenly. It took a lot of effort to get good at coding and to learn how to write code that works, to read and understand complex code, and to debug and fix when code doesn’t work as it should. I still remember how daunting my first “real” programming class was at university (learning C), how lost I felt on my first job with a complex codebase, and how it took years of practice, learning from other devs, books, and blogs, to get better at the craft. Once you’re pretty good, you have something that’s valuable and easy to validate by writing code that works! Some of my best memories of building software are about coding. Being “locked in” and balancing several ideas while typing them out, of being in the zone, then compiling the code, running it and seeing that “YES”, it worked as expected! It’s been a love-hate relationship, to be fair, based on the amount of focus needed to write complex code. Then there’s all the conflicts that time estimates caused: time passes differently when you’re locked in and working on a hard problem. Now, all that looks like it will be history. I wonder if I’ll still get the same sense of satisfaction from the fact that writing complicated code is hard? Yes, AI is convenient, but there’s also a loss. Or perhaps with AI agents, being “in the zone” will shift to thinking about higher-level problems, while instructing more complex code to be written? Whatever the case, seismic change is also exciting because of all the new opportunities. I haven’t experienced a major shift which I knew was occurring while it unfolded. This time, I’m certain that my way of coding will change drastically in 2026, and there’ll be plenty of knock-on effects. Change can create improved career opportunities and open up new paths to success, as well as bringing lots of excitement and trepidation. I reckon there will be higher demand for software professionals in five years’ time than today, partly thanks to the explosion in the quantity of software that AI creates. With these new, more capable tools, we’re figuring out what world-class software engineering will mean in this future. What do you make of possible changes to come for our profession, with more capable AI tools? Leave a comment below.