跳到正文
Pragmatic Engineer· Gergely Orosz·· 3 小时前AI 评分74

Gergely Orosz 梳理 2026 年科技行业现状:AI 如何改变软件工程

The state of the tech industry in 2026

AI 导读

Pragmatic Engineer 作者在 LDX3 大会发表主题演讲,总结 2026 年科技行业受 AI 影响的快照。

正文

I recently delivered the keynote at the LDX3 engineering leadership conference in New York, attended by 2,000+ engineering leaders, CTOs, Director+ and Staff+ engineering folks, in which I attempted to create a snapshot of where the tech industry is at this exact point.

In the middle of my keynote at LDX3

It came after I had the chance to visit the AI labs OpenAI and Anthropic, meet innovative startups like Ramp, Uber and others, get new, unpublished data from GitHub, Factory AI and Linear. The focus of the talk is trend inside of AI labs, VC-funded startups and Big Tech. Thanks to the kind access to these teams!

Before the conference, I spent weeks identifying and recording trends that didn’t exist a year ago – or were much more nascent back then – and also things that are currently broken, and others that remain unchanged. Today, we cover:

  1. Speed of change. In the tech industry, change has never been this large-scale, this fast. Industry legend Martin Fowler confirms.

  2. What’s changed: practically nobody writes code by hand anymore, working with 5-10 agents more common, the fading of the IDE, and 13 more changes from the last year.

  3. What’s broken: assumptions about code output broke, code reviews became theatrical, quality and reliability is down, and more.

  4. What’s still the same: teams are still important, as is planning; non-engineers are still not shipping code, and more.

  5. What comes next? Cloud coding agents and harnesses, engineers to stop reading the code, companies building a new type of AI infra, and more are already starting, and should accelerate.

You can watch the full talk, which is 29 minutes long:

Watch the full talk

The bottom of this article could be cut off in some email clients. Read the full article uninterrupted, online.

Read the full article online

1. Speed of change

People in tech are more than used to change; seeing the internet go from zero to everywhere, the arrival of mobile communications and smartphones exploding in popularity, cloud computing rising from a niche concern, and the development of programming languages like Go and Rust, and frameworks like React (web) and Jetpack Compose (Android).

Despite this, the scale and pace of the impact AI is having at present is still without precedent. That’s how industry veteran Martin Fowler described it at The Pragmatic Summit:

“Nothing has hit with the magnitude of AI. This is a whole size difference from anything that we’ve faced before.

On a smaller scale, we were very much involved in the growth of object-oriented languages. [object-oriented languages] scared a lot of people, but it didn’t scare us so much because we were part of it.

The internet had a huge impact upon us all. And, of course, we were spreading the challenge of agile software development. [Agile] had a very big impact on a lot of organizations because you could tell by how hard they resisted it.

But [for all those other changes] we kept talking about how important they were and how valuable they were and trying to persuade people of the importance of them. It may sound surprising, but even for the internet, there were people who wouldn’t think that was important!

For AI there’s no argument about how important it is. You cannot put blinkers on to deny the importance of this thing.”

Martin Fowler (left) at The Pragmatic Summit. See the full video

My own take is similar; we are without doubt at the beginning of a massive technological transformation, and after it, software will be built differently from how we’ve been doing for decades, although some parts of development will remain the same. At the very least, the tooling and best practices will look different, and things are changing faster than ever.

2. What’s changed?

#1 Nobody writes code by hand anymore

As the calendar enters Q4 of this year, we see this has solidified into a mega trend since the end of 2025 year when models greatly improved at coding. Related to this, in the very first article of this year we asked the question: when AI writes almost all code, what happens to software engineering?

From ‘When AI writes almost all code, what happens to software engineering?’

Today, there are plenty of signs that most engineers have stopped writing code by hand, and it was also a sign of the times recently when the Ruby on Rails creator sparked a “death of coding by hand” debate. Personally, I’m excited by the new opportunity that AI creates, and it’s exciting to experience this revolution firsthand. As mentioned in that deepdive, I’m certain that my way of coding will change drastically in 2026, and there’ll be plenty of knock-on effects.

For more on this topic, check out this recent edition of The Pulse.

#2 Working with several parallel agents is increasingly common

I like talking to engineers at AI labs because their working practices are often a few months ahead of the rest of the industry. Claude Code creator, Boris Cherny, revealed the new way he gets things done on the podcast:

“I have 5 terminal tabs. Each one of them has a checkout of their repository. I’ll round robin and start Claude Code in each one. I also run 5-10 Claudes on Claude Web, in parallel with my local Claudes.”

A few months after these comments, on last week’s pod with Cockroach Labs cofounder, Peter Mattis, – who’s an extremely productive developer who wrote circa 100K lines of code/year, pre-AI – said he’s doing something similar:

“Oftentimes, I’m doing things in parallel. I find my cognitive overhead is about 5-10 agent sessions concurrently. But sometimes those sessions will have many subagents doing things.”

I also asked a former coworker at Uber, who’s also an extremely productive software engineer, how he works these days. Dima Zaytsev (now a software engineer at Linear), told me:

“⁠It used to be a simple world: one mouse, one keyboard, one screen. You physically can’t work on more than one thing at once. Now, you no longer have that limitation.

I end up having 5-10 (literally) worktrees locally that I rotate between. Prompt one agent, and while it is working, move on to another to test output or review code.”

Nearly all of the most productive software engineers I’ve met – who were hand-writing code a year ago – no longer write the code by hand and also run several parallel agents. What a change!

#3 Rapid rise of agent-generated PRs

Fresh data that GitHub shared with me:

Agent-authored PRs: ninefold increase in eight months’ time. Source: GitHub

I’ve given GitHub grief for its ongoing reliability issues, but seeing how rapidly agent-generated PRs are growing makes me a lot more empathetic for the load which the platform is dealing with.

Food for thought: there were more agent-authored PRs in August 2026 on GitHub than human-authored ones! It’s reasonable to speculate that the number of agent-generated PRs will be permanently exceeding human-generated ones on the platform, going forward.

To give a sense of the number of AI-generated PRs: as of today (October 2025), there is likely to be 3x as many fully AI-generated PRs, per month (probably 75M+), than human generated ones at the end of 2023 (25M in December 2023). And the pace of AI-generated PRs does not seem to be slowing down, at least not now.

#4 Agent-generated issues also rising rapidly

Agents are not just generating PRs, they’re also opening tickets. Some more exclusive data, this time from my friends at Linear, which added first-class MCP support for agentic creation of issues:

More agent-created issues than human-created ones since July. Source: Linear

#5 Agent skills usage is mainstream

Both engineers and non-engineers use agent skills, and lots of companies are building their own agent skills repositories for all staff to create, share, and evaluate. An interesting data point on skills usage trending heavily up comes from autonomous software factory vendor Factory AI, which shared with me:

83% of Factory AI users use skills, up 2.5x from February. Source: Factory AI

#6 The fading IDE

I have great respect for software engineer Steve Yegge, who’s good at identifying emerging trends and learning about them. In a podcast episode, he said the IDE is effectively over:

Gergely: “Speaking about the job as developers, you’ve said something that can be triggering for a lot of people. You’ve said, on the AI Engineer Summit, that if you’re still using an IDE now, you’re a bad engineer.”

Steve: “Yeah, well, you got to be a little provocative. Let me put it this way. Okay, I’m not going to say you’re a bad engineer because I know some very, very good engineers, better than I am, who are still at level one or two in my chart [of AI usage]? But I feel profoundly sorry for them.

I feel pity for them like I’ve never felt in my life. For these grown people who are good engineers or used to be. And they’re like, ‘yeah, you know, I use Cursor and I ask it questions sometimes. And I’m really impressed with the answers. And then I review its code really carefully.’

And then I check it in and I’m like: ‘dude, you’re going to get fired. And you’re one of the best engineers I know!!’ “

Steve described his levels of AI usage like this:

  1. No AI usage

  2. AI agent in the IDE, with strict permissions

  3. AI agent in the IDE, with “YOLO” mode (permissions off)

  4. AI agent in the IDE, no longer looking at the code, but interacting with the agent

  5. CLI-first: abandoned the IDE

  6. Running several agents in parallel

  7. Running 10+ agents

  8. Built a custom agent orchestrator to run 30+ (or 100+) agents

Steve believes that “AI-pilled” engineers will abandon the IDE, and I’m seeing data from the market which backs that prediction:

  • Antigravity 1.0 was the last IDE released, based on a VS Code fork. It was released in November 2025. After that, no major IDE that is a VS Code Fork has launched. In May 2026, when Antigravity 2.0 launched, the product moved away from the IDE concept.

  • Codex launched as a non-IDE in Feb 2026, and they’re glad they did so, despite being torn about moving away from the IDE concept, at the end of 2025.

  • Cursor moved away from the IDE. In April 2026, Cursor relaunched and got rid of the IDE interface. It now looks pretty similar to the Codex and Claude desktop apps. When I talked to their team over the summer, they told me they maintain the “legacy” VS Code fork version for existing enterprises, but the future is agentic for them.

  • JetBrains seems in a hurry to pivot from IDEs. JetBrains has built some of the most beloved IDEs for developers, but the company is now also pivoting to JetBrains Air, and agentic development environments.

How every coding tool looks these days – gone is the IDE? Source: Cursor
JetBrains also joining the trend with JetBrains Air

Industry legend Kent Beck told me something interesting when we discussed why IDEs are slowly vanishing:

“It’s not that we don’t need more perspective and context for our human-based decisions; it’s that the context has changed.”

I wonder if what is really happening is the IDE evolving into something different to work better with coding agents. Steve Yegge also talked about how the IDE needs to evolve into a conversation and monitoring interface, but not an editor, given that we no longer write the code.

I’d also add that IDEs need to evolve into a validation and verification interface: how do we know that the agents’ output works as expected, how can we verify what tests it passes, how it looks, and whether you can try out whatever the agent builds. Tools like this are surely coming and will be widely adopted.

#7 Everyone is building their own harness/agent platform

In August, I posed a question on social media about whether it’s possible to be a serious tech business without having built an AI harness:

A provocative question

I asked it because most mid-sized-and-above companies have built their own agent harnesses, at this point! A few examples:

  • Ramp building Inspect – a case study we covered in depth

  • Stripe (Minions), Uber (Minion), Block (Goose), Shopify (River)

  • Google (Agent Smith), Meta (Devmate), Amazon (Kiro + Crew), Dropbox (Nova), Spotify (Honk)

  • DoorDash (Flux), Grab (LLM-Kit), WorkOS (Horizon), Hubspot (Crucible)

  • Monzo (Agent Chip), Sierra (Pinecone), Harvey (Spectre), Browserbase (bb)

  • … and many, many more!

#8 Dev work often starts in Slack

LDX3 keynote: much dev work starts in Slack for startups

What I’ve learned by visiting startups is that more and more development kicks off inside Slack. At OpenAI, it’s “@Codex, implement this”; within Anthropic, it’s “@Claude build this”, while inside Linear, it’s “@Linear work on this”. More startups have their own Slack integration of their coding agent – often a custom one.

Coding agents work really well when deeply integrated into a company’s stack, when the Slack agent kicks off a coding agent that runs in the cloud.

#9 Agentic software factories being built everywhere

We have covered in-depth how OpenAI is building an agentic software factory, and a lot of feedback from readers about that article has been an “we are too!” type response. Many readers say that their company is building a similar “agentic software factory.”

From the deepdive Inside OpenAI’s agentic software factory

The “agentic software factory” adds AI functionality to a bunch of existing systems such as the CI/CD system; for instance, in being able to interact with CI/CD via Slack, or creating brand new systems with agents in them like agentic code review tools, OpenAI’s agentic deploy system, or the Perf Factory.

#10 Migrations no longer take years

We’re seeing many migrations that would have taken years to complete, now taking mere weeks or months:

  • Anthropic: migrating the package manager Bun from Zig to Rust in 11 days (versus an estimated 1.5 engineering years)

  • OpenAI: the API layer is being migrated from Python to Rust. The migration is taking around 5 months, versus several years that it would have taken, without AI

  • Airbnb: migrating 3,500 end-to-end test files from Enzyme to React Testing Library: took 6 weeks (instead of years)

  • Asana: migrating 4,000 end-to-end test files from Enzyme to React Testing Library: 2 weeks, instead of an estimated spread out over five years

  • Uber: migrating 600,000 JUnit 4 tests across 15 million lines of code (!!) to JUnit 5: took 4 months (instead of estimated several years)

#11 AI costs a major engineering concern

In May, we covered the trend of companies wanting to cut back on AI spend within engineering departments, and last month, I reported on how tech companies are moving to open AI models to save 50% or more in token costs. Uber is a good example, where, despite token usage trending upwards, costs have stayed flat since May thanks to them running open models and doing smart model routing:

Uber’s per-token costs are down 50%+. Source: The Pulse

Three weeks after my article, Bloomberg confirmed the exact same trend. As I covered in my original deepdive, lower-cost models and smart routing account for the majority of cost savings at most companies. If you’re only doing two things, consider those techniques.

Most efficient way to cut back on token costs. Image source: Databricks

#12 Projects get done with only one or two engineers

Katelyn Lesse, Head of Engineering for Claude Platform, told me how her team works inside Anthropic. From our deepdive:

“On an individual project, you often cannot have more than two people working on it. This is because each engineer is already running several agents. And so as an engineer, you’re already fighting against your agents, which are stepping on each other’s toes on implementation. And in this setup, you just cannot have that many humans, who also come with all their agents!”

These days, I see the same thing happening at companies both small and large.

Other changes

3. What’s broken?

Assumptions about code quantity and frequency

It’s been a commonly held belief that code quantity grows roughly linearly. But with agents, both the lines of code and number of commits are growing exponentially, as shown in data from GitHub:

Source: GitHub’s load increase speeds up

(Human) code reviews are dead

A software engineer at a mid-sized startup told me something that’s pretty much an open secret across the industry, including at places with code reviews in place.

“Everyone is playing the theater of doing reviews, but with the volume of changes that get thrown your way, I observed that people just find a path of least resistance: give up on reviews and just stamp everything with LGTM.

We are gradually phasing out this process ourselves with some shortcuts that you are allowed to take, and that has been a major productivity boost.”

At the LDX3 conference, there was a strong reaction among the audience when they heard the bolded sentence out above. Today at most companies, there is indeed a “theater of code reviews”. The fact is that no engineer can keep up with 5-10 times more code to review, so most don’t thoroughly review the code.

Agent-only code reviews trending up

Fresh data from Linear shows that PRs which are reviewed solely by AI agents are a rising trend, and I expect it’ll continue:

AI-only PR reviews are up. Source: Linear

Quality and reliability down

We see this in many of the digital products we use. As Mario Zechner, the creator of Pi, said on the podcast:

“Everything is broken. It sure feels like software has become a brittle mess, with 98% uptime becoming the norm instead of the exception, including for big services. And user interfaces have the weirdest bugs that you’d think a QA team would catch. I give you that that’s been the case for longer than agents exist. But we seem to be accelerating.”

We covered the phenomenon of quality being worse with more AI usage in March, in ‘Are AI agents actually slowing us down?’

Infra capacity shortage

It’s common knowledge that there’s a GPU shortage and memory shortage in the market. In addition, there’s also the growing trend of CPU shortages. As I covered last month:

“Apparently, it’s now nearly impossible to get CPUs on spot instances without long-running connections with cloud providers. Also, reserving specific CPUs now needs to be done months in advance, and cloud providers will even turn down certain reservations because they don’t have enough CPUs or the right type of CPUs.”

If you’re at a company with a non-trivial amount of CPU usage, securing capacity is something worth doing now, as I wrote recently:

“The best time to secure more CPU capacity is most certainly right now. I’m hearing rumors that certain cloud regions no longer accept new tenants because all CPU capacity is leased, or negotiations elsewhere are difficult. I’m also hearing that customers are already paying today to reserve capacity that will only come online in data centers from December. This seems predatory by providers, but demand is so high that this is how they likely prioritize new capacity allocation – while earning much higher profits than usual.

If your company has dynamic workloads, and you’ve used spot instances in the past, now could be a good time to allocate fixed capacity – even if it’s more expensive. If you expect meaningful growth, doing so now might mean having options at some cloud providers or in some regions.”

A hit on personal focus and productivity

Software engineer Dima Zaytsev (currently at Linear, formerly my colleague at Uber) told me something that felt very relatable on AI and productivity:

“There’s lots of context switching: there’s always another agent that waits on your response.

Also, it’s just more work. When AI was ramping up, I felt more productive than my peers: I did in an hour what others needed a day for. Now, the expectation has become that everyone works on parallel things. And so, I end up feeling I have more work compared to pre-AI.”

Engineering leaders taking career breaks

An interesting, unexpected trend that has emerged is CTOs, Heads of Engineering, and VPs of Engineering resigning from their jobs, often with nothing specific lined up. From a current CTO who asked to remain anonymous:

“This change [with AI] makes builders want to build. We want to build again, so we can build more, and build faster with better tools, so we can increase the “talent density” of the team by doing more with fewer great people, and so on.

It’s an amazing time to build things. And it’s only getting better. And people just want to be close to it. They want to build and see how far they can go with these new tools.

I have a bunch of friends in my social circle who are the “CTO drop outs” you speak of. More still who are moving from management to IC roles in large companies. And their stories are largely what I describe above. They simply see this as a truly exciting time to build.

In the end, building is why they got into this field in the first place.”

We cover this in the deepdive ‘Headed for the exit: the great engineering leader career break’.

4. What’s still the same?

In the LDX3 keynote, I also covered areas that are mostly unchanged from before AI:

Teams are still important. As Katelyn Lesse, Head of Engineering for Claude Platform told me in July:

“One thing I’ve heard from some people is “we have two humans and a bunch of agents.” I reply that this isn’t where we’re at. I still have teams whose job it is to own a piece of software, iterate on it, own oncall, and so on. While each of these humans are supercharged by AI, the size and shape of the team is still similar. We still have two-pizza teams.”

Katelyn works at one of the most “AI-pilled” companies globally, so if teams are still as important there as they were before AI, then it’s not a stretch to say that the team structure is still relevant at companies across the industry.

Planning still happens – at least for complex work. Complex projects still have a lengthy planning phase. Also from Katelyn, on the planning phase of Claude Managed Agents:

“Our planning process looked more like a typical pre-AI planning process. You know how every team has the project, where everyone comes up with some version of the same idea and people keep floating and circling it around until you finally do it? Managed Agents was this for our team. When we started the project, we had documents dating back up to two years about ideas and suggestions.”

Tests and validation are still very important. From Jarred Sumner, creator of Bun, who’s currently at Anthropic:

“The AI writes pretty much all the code, but we have the AI write pretty much all the tests as well. Before AI, for production-ready software, we spent about the same time writing tests as we did on writing code. This is still the case with AI. You need to have a way to trust your code, and tests are probably the best way to.”

At each company I talked to in advance of the LDX3 keynote, I observed that a lot of focus is going into validating the output of AI agents. This makes sense: code review no longer works like it did before, we have more code, and we need to make sure that it won’t break production!

Non-engineers are still not shipping prod code. In the last few weeks, there’s been stuff on social media about AI enabling product managers/designers/non-technical people to ship production code. So, I asked the AI labs, startups, and other companies.

I can report that I did not find any single company where PMs/designers/non-technical people ship to production!

What I did learn about are cases where these folks create bugfixes – often unknowingly! – or new features with their agents that end up with devs to review. There’s also a massive amount of prototyping. But it’s still engineers who are responsible for deciding what can and what cannot be released to production.

We’re rediscovering old patterns that work great with AI. This came up in our podcast with Matt Pocock. Matt noticed that agents try to build software layer by layer, which causes bugs between the layers. Reading The Pragmatic Programmer, he discovered the concept of the “tracer bullet.” When he instructed the agent to use “tracer bullets” to build an app (aka implement a “golden path”), the agent started to produce better code.

As mentioned in the podcast, Matt is now reading classic software engineering books to find other “leading words” that guide agents efficiently.

In general, I’m noticing that “old” best practices are helpful when building better software when working with AI. This includes writing unit tests, building a “golden path” first (aka a “tracer bullet”), architecting an application upfront, and even using design patterns. The amusing thing is that we’re talking about decades-old best practices here.

5. What comes next?

It’s possible to look ahead at where the tech industry is headed by identifying trends that are underway, and which look certain to conitnue:

Cloud coding agents + harnesses will dominate. Most devs at companies will run AI agents in the cloud, instead of locally. Ramp offers a blueprint for this in our deepdive about their cloud agent, called Inspect. It seems that inside innovative tech companies, the “build your own cloud agent harness” principle is trending.

I also expect vendors like Anthropic, OpenAI, SpaceX, and others to start pushing their cloud coding agent offerings, and for more startups to build their own cloud harnesses.

As engineers, we’ll stop reading the code. It’s too early to tell when this will happen; this year, next year, or further in the future, but it’s likely that few of us will read the code that AI agents produce properly, going forward.

As a rule, I pay a lot of attention to Honeycomb cofounder and CTO, Charity Majors, due to her being a “default sceptic” about new technology, as well as a standout engineer and someone who speaks her mind. On our podcast in August, she asked:

“What would it take for you to be comfortable shipping code without you reading it and understanding it? Because that is engineering.”

Charity made the point that Ops and QA have already had decades to figure out how to ship code to production that they didn’t write and don’t understand – all while making sure it works! It seems unavoidable that most software engineers will also join this group. This is ironic, since software engineering, for the longest time, was about engineers writing and understanding the code!

Companies will build brand new types of internal infra. We’ll see a “reinvention” of these systems to work well with agents:

  • CI/CD, with agentic evals part of the pipelines

  • Agentic software factories, and figuring out what is and isn’t practical

  • Agents becoming part of deployments, observability, incident management

  • Agentic observability will surely become its own problem space and specialization: how can we make sure the customer-facing agents deployed work as expected, and how to ensure that systems which agents build and modify actually work as expected?

A “golden age” of refactoring/migrations/full-on rewrites. Migrations and rewrites that had been delayed for years because they’d take similar amounts of time to complete, should take no longer than weeks. That means there’s little excuse to delay any longer!

Engineers understand more about how capable AI agents are with rewrites/refactors/migrations today, and we’ll also clean up tech debt much faster, while having no reason to have a system in a state that we’re unhappy with!

AI “fluency” and “positivity” matter in recruitment at startups. A trend I have not written much about – but which is already happening – is startups selecting engineers for jobs who demonstrate a positive attitude about AI. As the Director of Engineering at a Series D startup told me:

“AI positivity was something we started to screen for in our hiring process. We want people to join who want to help us push the limits with what we can build with AI.”

The reality is that AI coding agents are already everywhere, and agentic systems look set to proliferate very soon. This will bring great demand for software engineers who are willing and able to build next-generation systems, and it’ll be a baseline criterion to be excited about the problem space.

This is not too dissimilar to the way that startups hire engineers who buy into the idea of growing fast, or when companies favor engineers who pick up the tech stack already in use, instead of insisting upon the one that they personally use.

Engineers with deep domain knowledge will become more in demand. In New York, I had a conversation with Titus Winters, lead author of Software Engineering at Google. He told me this observation:

“What you need to succeed anywhere is intelligence, wisdom, and charisma. Intelligence means: how to do it. Wisdom means: what to do. Charisma means: convince others to do it.

When intelligence becomes commonplace, wisdom and charisma become much more important.”

In the context of software engineering, “wisdom” is most easily earned by becoming a domain expert. So, if you work at a fintech company, learn about the finance industry and its customers in order to become a more valuable, in-demand engineer! That also applies if you’re at an agriculture tech company, or work in any other domain.

Finally: remind yourself why you got into the tech industry. At the end of my podcast with Peter Mattis, the cofounder and CTO of Cockroach Labs, we talked about how it feels pretty exhausting right now to keep up with the pace of change. He said:

“Remind yourself why you got into this in the first place. I got into software engineering because I like building stuff. Now I can build faster, and without some of the compromises that I had before!”

来源:Pragmatic Engineer · newsletter.pragmaticengineer.com