The State of the Tech Industry in 2026: What Changed, What Didn't, and What Broke
The Pragmatic Engineer
Gergely Orosz writes The Pragmatic Engineer and hosts its podcast. In this LDX3 New York keynote, Orosz reported on recent visits to the headquarters of OpenAI, Anthropic, Cursor and Ramp, and on conversations with engineers at Uber, Linear and other startups. Orosz organized the talk into four parts: what has changed in how software gets built, what has stayed the same, what has broken, and what comes next. Orosz's overall position is that the past twelve months brought a wave of change unlike anything before. Some fundamentals still hold, and some things across the industry are visibly straining.
Almost nobody writes code by hand anymore
Orosz's first observation was that hand-written code has become rare. Engineers still edit code by hand, but most of it is now written with AI. Orosz placed the turning point in January. After the winter break, engineers found that models starting with Opus 4.5 and GPT-5.2, used inside agent harnesses, had become very good. According to Orosz, startups that track the metric report close to 100% AI-generated code, with engineers doing the prompting.
Running many agents in parallel
The second change is that engineers now work with several agents at once. In March, Boris Cherny at Anthropic described running five Claude Code sessions in terminal tabs on a local machine, plus another five to ten Claude sessions on the web. Orosz acknowledged that Anthropic will naturally be at the cutting edge and may sometimes use AI "for the sake of AI." So Orosz also cited engineers outside the labs.
Dima, a former Uber colleague of Orosz's who now works at Linear, said it used to be a simple world: one mouse, one keyboard, one screen, so you physically couldn't work on more than one thing. That limit is gone. Dima now runs five to ten worktrees and five to ten agents at the same time. Two days before the talk, Orosz spoke with Peter Mattis, co-founder of Cockroach Labs, who built Gmail's first backend storage and other storage systems at Google. Mattis described the same pattern, putting their cognitive overhead at five to ten concurrent agent sessions. Orosz's point is that experienced, "hardcore" engineers have widely adopted parallel agents.
IDEs are fading
Orosz, who said they love their IDE, found this one unexpected: heavyweight IDE usage is declining. People still use IDEs, just less. Orosz described Antigravity, released in November as a kind of Windsurf rebrand, as the last major VS Code fork.
The OpenAI team told Orosz in June that in January they had considered forking VS Code for the next version of Codex and were torn about it. For a while they thought building Codex without an IDE had been a mistake. They soon concluded that they had made the right call at the right time and that it was a win. Orosz also noted that JetBrains is pivoting to Air, which is more of an agentic harness and looks similar to Codex. Cursor, the biggest VS Code fork, pivoted in April to an agentic interface that also resembles Codex. Inside Cursor, the team told Orosz that the IDE is now a legacy product: they need it for enterprise customers, but it isn't growing and is shrinking.
Orosz shared a text from Kent Beck on the subject. Beck's point was that we still need perspective and context for human decisions, but that context has changed, which may be why the IDE is going away.
Everyone is building their own harness
Orosz half-jokingly tweeted: "If you haven't built your coding harness, are you even a serious tech company?" Orosz listed companies that have done so, including Ramp, Stripe, Uber, Block, Shopify, Google, Meta, Amazon, Dropbox, DoorDash, Grab, WorkOS, Monzo, HubSpot, Sierra and Harvey. These harnesses usually have internal code names. Orosz said building one is easy. A common motivation is to plug in internal data sources that companies may not want to connect to Codex or similar tools. Some of these harnesses are built on top of Codex, Claude Code or OpenCode.
Work starts in Slack, and the agentic software factory is real
Developer work increasingly begins in Slack. Inside OpenAI, people tag Codex and ask it to implement something, and Codex is connected to OpenAI's internal systems. Anthropic does the same with Claude and has launched that as a product. Startups are building their own Slack agents and bot integrations, and Linear has its own Linear bot.
Orosz admitted to once treating "agentic software factory" as a far-off buzzword. Orosz now considers it real and pointed to OpenAI as one of the best examples, the subject of a Pragmatic Engineer deep dive released the same day. In OpenAI's setup, agents act on input that typically comes from other agents and return to Codex to generate a pull request. A human often reviews the final pull request for critical changes with a large blast radius. OpenAI also runs what Orosz called a "perf factory": agents monitor production, raise PRs to improve it, and keep iterating. Orosz stressed that this is not fully automated and that full automation isn't OpenAI's goal, but called it a big change.
Migrations no longer take years
Orosz gave several examples of large migrations finishing far faster than before:
- Anthropic migrated Bun from Zig to Rust with a single engineer, the person who wrote most of Bun. Orosz suggested this would probably have taken years, or would never have happened, because a migration means maintaining two things at once.
- OpenAI, according to information Orosz presented as new, is migrating the API behind all its interfaces from Python to Rust. The team says it is about 90% done after roughly four to five months under production load, with nothing visible from outside, and expects to finish in a couple more months. Orosz joked that "90% done" is what everyone says.
- Airbnb dropped the Enzyme UI testing library for React Testing Library in six weeks and published a write-up on how they did it.
- Asana made the same switch in about two weeks. Orosz noted the nuance that Asana had spent years on groundwork beforehand. Orosz also stressed that these were essentially full rewrites of test suites, not simple library swaps.
- Uber moved from JUnit 4 to JUnit 5 across millions of lines of code in four months. Orosz said this would previously have taken years of slogging.
Data on agent-generated work
Orosz presented several datasets showing agent activity rising sharply. Fresh data from Linear shows that, for the first time, more tickets on its platform are created by agents or through MCP than by humans, after a steep rise in recent months. GitHub data shows agent-generated PRs "exploding." Agent-only PRs, meaning PRs with no human reviewer, numbered 7.7 million in January and rose nearly tenfold by August. Orosz said the trend matters more than the absolute number and also flagged a July–August spike in agent-only reviewed PRs. Data from Factory AI shows skills going mainstream: about 80-something percent of Factory's users now use skills, up from about 30-something percent in February.
Cost: a spring scare, then partial control
By May, Orosz said, companies were widely worried about AI costs. That was around the time news broke that Uber had blown through its annual AI budget, as Claude Code spread and AI got more expensive. By September, Orosz reported, many large companies had brought their cost curves under control. They cut per-token costs by about 50% and kept total costs flat by investing in open models, smarter routing and similar measures.
Specializations are disappearing and projects are shrinking
At OpenAI, ChatGPT's head of engineering told Orosz that they had expected engineering specializations to fade but were surprised by how fast it happened. Last year OpenAI was still hiring dedicated iOS and Android engineers. This year it isn't, because it believes that with Codex anyone can do that work at a good-enough level. Orosz sees the same pattern elsewhere in frontend and mobile, and also sees frontend engineers taking on more backend work.
Projects are also being done by one or two engineers. Katelyn, Anthropic's head of engineering for the Claude platform, told Orosz that an individual project often can't have more than one or two engineers. Each engineer already runs several agents that step on each other's toes, so there is room for at most one more engineer, who brings their own agents too. Orosz said one-person projects are becoming much more common at the startups Orosz talks to.
Orosz briefly listed a few more changes. Teams are getting smaller. Junior hiring keeps declining, not dramatically but steadily, which Orosz said shows up in Pragmatic Engineer data and elsewhere. And agent infrastructure has become its own discipline. Orosz counted about sixteen changes in total and emphasized that almost none of them were true twelve months earlier, with the possible exception of the junior hiring trend.
What hasn't changed: teams, planning, testing
Orosz was pleased to hear that the team remains the unit of work at Anthropic. Katelyn said some people talk about "two humans and a bunch of agents," but that isn't where Anthropic is. Teams still own a piece of software and its on-call rotation. Each person is supercharged by AI, but team size and shape are similar to before: still two-pizza teams. Orosz said the same holds at OpenAI and behind any successful agentic product. People go on vacation, generate energy together, inspire each other, hold a high bar and keep each other accountable. Orosz's view is that "two people and a bunch of agents" amounts to a one-off project, not a team.
Planning still matters for complex work. According to Katelyn, planning for Anthropic's more complex infrastructure products hasn't changed much from her earlier years at places like Stripe. Building the wrong thing is still a waste even when building is faster. Planning remains especially important for infrastructure complexity, aligning teams and communicating with customers.
Testing and validation remain essential. Jarred Sumner, who rewrote Bun at Anthropic, said AI writes nearly all the code and nearly all the tests. Before AI, his team spent about as much time writing tests as writing code for production-ready software, and that ratio hasn't changed. Sumner stressed that you need a way to trust your code and that tests are probably the best way to get it. Orosz added that there are other layers of validation, and that formal verification is becoming more popular.
Non-engineers are not shipping to production
Orosz kept hearing that non-engineers can now ship production code, so Orosz asked around for a week. Orosz's conclusion was that it isn't happening. Non-engineers build websites and flag bugs in Slack, and sometimes a Slack bot turns that into a pull request. But these people typically don't know what a pull request is, and they are not shipping production code; they are alerting engineers to bugs. Orosz said no company they spoke to, from Linear to Cursor to OpenAI, has non-engineers pushing production-ready code, and that they aren't sure this will ever happen.
Old patterns are being rediscovered
Matt Pocock, the educator behind the "grill me" skill, told Orosz that he encountered the term "tracer bullets" in The Pragmatic Programmer and then went looking in older books for "leading words" that improve agent output. In A Philosophy of Software Design he found the ideas of deep and shallow modules, and he found that using those terms with the AI produces better code. Orosz found this fascinating: the models were trained on these ideas, and the ideas apparently still help when guiding them.
What broke: code volume and code review
Assumptions about code volume no longer hold. Orosz noted that GitHub has had outages and, to its credit, publishes data on what's happening. Over three years, pull requests, commits and new repositories are up about 5x, and the increase has accelerated sharply in the last six months. Data GitHub gave Orosz shows the roughly 10x rise in agent-only PRs, and total pull requests doubling in just the last two months.
Orosz said code review is "done for." An engineer who asked not to be named told Orosz that everyone is playing "the theater of doing reviews." Faced with the volume of changes, people take the path of least resistance, and some just approve everything. That startup is gradually phasing out code reviews because they don't work. Orosz calls these "zombie code reviews" and argued that if your team still nominally does code review on every change, it probably isn't really reviewing. Ramp has started telling engineers it trusts them to skip code review for certain non-critical parts of the codebase, and Orosz expects more companies to do the same.
Quality and reliability are also breaking, according to Orosz. Orosz sees constant "paper cuts" in everyday products, naming Spotify and Substack as examples. Orosz attributes this to people, and agents, shipping more.
Infrastructure shortages, including CPUs
Orosz said everyone knows about the GPU shortage, but it mainly affects AI labs, inference companies and AI startups seeking GPUs. A memory shortage is raising memory prices, though most companies won't feel it much. What surprised Orosz was a CPU shortage hitting cloud customers with ordinary workloads, which The Pragmatic Engineer recently covered with examples including Turbopuffer and Anthropic. Ordering a CPU or server at a cloud provider used to mean one to two weeks of back-order time; Orosz reported it is now up to six months. Mid-size customers cannot reserve CPUs in certain regions, and some regions can't take any new orders at all. Some companies are already paying for capacity that won't arrive until December, because that is the only way to secure it. Orosz called the situation "manic."
Focus, productivity and the shifting baseline
Orosz also reported damage to focus and productivity. Dima at Linear, whom Orosz described as an excellent engineer even before AI, said there is constant context switching and always another agent waiting for a response. Dima also said there is simply more work. When AI was ramping up, Dima felt more productive than peers, finishing in an hour or two what took them a day. That pace is now the baseline expectation: everyone is expected to work in parallel. As a result, Dima feels they have more work than before AI. Orosz said many people feel this way and encouraged the audience to reflect on it.
Engineering leaders are walking out the door
Orosz interviewed about 20 to 25 engineering leaders who are taking or planning career breaks and summarized their reasons:
- The job got harder. Under "founder mode" expectations tied to AI, some founders push leaders to fire half the team, while others expect revenue to double when AI spend doubles. Orosz called these expectations unrealistic.
- Startups are losing. Leaders see their equity becoming worthless or their company heading toward bankruptcy, try to turn things around, fail, and check out.
- Companies aren't adopting AI fast enough. Leaders care about career stability. Orosz argued that if your company is still working the way it did in 2022, staying another two or three years puts you in a career hole, because your next employer will expect AI-era experience.
- Smaller teams need fewer leaders, and middle management is often cut alongside them.
- Fractional CTO work is surprisingly popular in hubs like New York, San Francisco and possibly Seattle. Leaders who quit voluntarily take fractional roles because returning full-time feels too messy right now, even though the companies hiring them want them full-time.
- AI startups pay much more in total compensation, sometimes even in cash. Orosz said Anthropic is recruiting the CTOs of major public companies to join as ICs or to lead small teams, and that higher pay there is an open secret.
- It's a good time to found a startup for hands-on leaders with the right background, who can likely raise VC funding.
- Burnout. Some leaders want to step back, let things settle, and return later.
What comes next
Orosz listed developments they were fairly certain are underway and will continue.
Cloud agents and harnesses. Anyone with engineering resources is building them. Orosz described Ramp's harness as one of the most advanced and said it works far better for Ramp than Codex or Claude Code. Ramp gave three reasons for building it: local machines are far more limited than the cloud; Ramp is frontend-heavy and can build better frontend tooling in the cloud; and it wanted remote developer environments anyway, so this killed two birds with one stone. Orosz said the only catch is that the CPU shortage may make capacity harder to secure. Dima, previously a strong advocate of local development, noted that the industry still lags on Devpods (something Uber had) and cloud development tooling. Dima has nonetheless changed their mind and now sees the cloud as the future, because work grinding away in the cloud doesn't hog their machine.
We will stop reading the code. Orosz attributed this view partly to Charity Majors, whom Orosz described as a big skeptic. On the podcast they discussed what it would take to be comfortable shipping code without reading and understanding it, noting that ops and QA have long worked this way. Orosz framed it as a question of when, not if.
New internal infrastructure. Evals will become part of CI/CD if they aren't already. Companies will keep iterating on agentic factories, and agents will take part in deployments, observability and incident management.
A refactoring wave. When refactoring, migrating and rewriting become cheap, Orosz asked, why not do them? Orosz added that this is also a low-risk way to practice agentic skills.
AI fluency and positivity as a hiring baseline. An engineering director at a startup told Orosz they now screen for AI positivity, because they want hires who will help push the limits of what can be built with AI. Orosz noted this applies both when hiring and when interviewing.
AI maturity as an organizational goal. Orosz cited Laura Tacho, who spoke at the Pragmatic Summit in February. Tacho says organizations that move faster start from a business outcome, work backward, and build agentic systems that reduce handoffs, increase learning and remove friction. In Tacho's framing, individual-level automations are the easy path. What leaders should be doing is the harder work of building team-level or company-level agentic systems, which Orosz said explains the surge in AI infrastructure. Orosz acknowledged this is high level but called it the right direction.
Demand for deep domain knowledge. Titus Winters, an author of Software Engineering at Google, told Orosz that success requires intelligence (knowing how to do something), wisdom (knowing what to do) and charisma (convincing others to do it). As AI makes "how" cheap and widespread, Winters argued, wisdom and charisma become much more important. Orosz added that this doesn't mean ignoring intelligence.
Orosz's advice to engineering leaders
Orosz's advice was to future-proof your career by being hands-on: build software and ship to production. As an example, Orosz cited Will Larson, chief product and technology officer at a company with a 50-person engineering organization, who has shipped more code to production in the past 15 months than in the previous five to ten years combined. Orosz urged leaders to:
- build AI infrastructure that helps their team and company;
- use AI to remove friction from their own work, their team's and their company's;
- avoid outsourcing their learning to AI, because peers who use it to improve will get ahead.
Orosz also said leaders should accept doing less people management for now. ICs don't expect as much of it, nobody yet knows what that career path looks like, and it isn't what founders and executives currently expect from leaders. Orosz expects the field to figure it out and return to it eventually.
Orosz closed with Peter Mattis. Mattis, after years as a hands-off engineering leader of a large organization, has returned to being hands-on. Mattis told Orosz you have to "get in there," use AI tools constantly and push yourself to learn, and said they have learned more in the past year than in the previous five combined, which Orosz found striking given Mattis's experience. Orosz asked the audience to remember why they got into tech. Mattis's answer was that they got into software engineering because they like building things, and now they can build faster and without some of the compromises they used to make. Mattis called it a little exhausting, but also very exciting.
Good morning. I'm Gergely, and thank you for the introduction. I now spend most of my time writing The Pragmatic Engineer, hosting the podcast, which is software engineering, big tech from the inside. And today I want to bring you into a journey, show you some stories, some information that might not be as readily available inside AI labs, big tech and startups.
In the last few months, I went inside the HQ of OpenAI, Anthropic, Cursor, Ramp. I also talked with folks at Uber extensively, at Linear, and other startups. Here's some of the photos where I went, especially Ramp with the office guy. And today I want to cover first what changed, then what did not change, things that have broken across the industry, and what comes next. Let's start with what's changed. And a lot of things have changed.
First thing, nobody writes code by hand anymore except for a few of you folks. But in general, it's just more and more rare to see. Of course, we still edit some code by hand, but it's crazy how much we are writing with AI. And this was kind of obvious to see in January. We all woke up in January after the winter break and we just saw that these models, starting from Opus 4.5 and GPT-5.2, were just really, really good with the harnesses. And from there on, people switched, and in most startups that are tracking these numbers, it's gone to close to 100% AI-generated code that, of course, engineers prompt.
Another thing that's changed: working with several agents. It's increasingly common. In March, I talked with Boris Cherny, who told me about how he has five terminal tabs, five Claude Codes on his local machine, plus five to 10 Claudes on the web. Now, this is Boris Cherny. This is Anthropic. Obviously, they will be cutting edge, and they will just honestly use AI, sometimes maybe even for the sake of AI.
But I talked with Dima Zaytsev, who was an engineer, an old colleague of mine at Uber. He now works at Linear, and he put it really nicely. He said it used to be a simple world: one mouse, one keyboard, one screen. You physically couldn't work on more things than one, but now we no longer have that limitation. So he's doing five to 10 worktrees. He's doing five to 10 agents at the same time.
And just the day before yesterday, I talked with Peter Mattis, co-founder and CEO of Cockroach Labs. He's the person who built Gmail's first backend storage and a bunch of really cool storage stuff inside of Google. And he told me the same thing. Oftentimes, he's doing things in parallel. "My cognitive overhead is five to 10 agent sessions concurrently," and he just often does that as well. So again, so many people, so many kind of hardcore engineers, if you will, have kind of moved to this mode of just parallel agents. It's pretty common.
IDEs are just fading away. This was really unexpected for me to see because I love my IDE, but the trend of this heavyweight IDE usage is trending down. People are using them, just not as much. Antigravity released in November, the Windsurf kind of rebrand, if you will, was the last major VS Code fork that was forked.
And I talked with the OpenAI team just in June. And they told me that in January they were considering forking VS Code for the next version of Codex, but they were kind of torn in between. Should we do it? Should we not? And for a little bit, they thought it was a mistake to build Codex without an IDE, but they quickly realized actually they did it at the right time, and it was a win.
JetBrains, one of the most beloved IDE brands, they're pivoting to Air, which is also more of an agentic harness, if you will. You can check it out. It looks similar to Codex. Cursor, the biggest VS Code fork, has pivoted in April to just an agentic interface. Again, looks very similar to Codex. So all of these tools, and when I talked with the Cursor team inside of Cursor, they told me specifically that the IDE is now just a legacy product. They need it for enterprise, but it's not growing and it's shrinking.
And I was talking with Kent Beck about this yesterday, and he texted me this. He said, "Hey, on the death of IDEs, it's not that we don't need more perspective and context for our human-based decisions. It's that context has changed." So maybe that's why it's going away.
Everyone and then some are building their own harness and agent platform. And by everyone, I'm talking the startups, the big tech, the mid-size companies. I put this kind of tweet half-jokingly, saying, "If you've not built your coding harness, are you even a serious tech company?" And here are companies that have built it: Ramp, Stripe, Uber, Block, Shopify, Google, Meta, Amazon, Dropbox, Shopify, DoorDash, Grab, WorkOS, Monzo, HubSpot, Sierra, Harvey, Bros, so many more. Usually they have cool internal names. By the way, it's really easy to do it as well. And they often do it so they can plug in their data sources that they might not want to plug into Codex or whatnot. And some of them are building on top of Codex, Claude Code, OpenCode and so on.
The developer work now often starts in Slack. So inside OpenAI, they just tag Codex: "Implement this." Codex is plugged into all the OpenAI systems. Anthropic, same thing with Claude, right? They launched it as a product as well. Startups increasingly build their own Slack agent and AI bot integrations. Linear does the same with their Linear bot and so on.
The agentic software factory. This used to be a buzzword that I used to be like, "Agentic software what? Like cars? Sure, one day." But no, it's actually happening, and one of the best examples is OpenAI's software factory, which a deep dive is going out in a few hours in The Pragmatic Engineer, so you'll be able to see. But in this diagram that describes how their agentic software factory works, those dashed lines, those dotted lines are where agents act on typically AI agent input, and they go back to Codex to generate a pull request. A human in the end often reviews a pull request for critical ones, for a large blast radius. But OpenAI has this really cool concept of a perf factory run by agents, which monitors production and raises PRs to improve production, and they just keep iterating on it. It's not fully automated, and they don't have the goal, but it's happening, and this is a big change.
Migrations no longer take years. If we're paying attention, it's not as surprising. But some examples: Anthropic migrated, famously, Zig to Rust with one engineer, who wrote most of Bun, by the way. So this was really fast, and it probably would have taken years, and it probably just wouldn't have been done just because when you migrate, you need to maintain another thing.
OpenAI, as I'll describe in a deep dive, this is new information that I got from them. They are migrating their API that hits all of their interfaces from Python to Rust. They are about 90% done, which is kind of what everyone says, by the way. But they're saying that it took about four to five months to get here under production load, nothing seen from the outside, and they're expecting to finish in a couple more months. And usually we know these things would have taken years. But this is a great example because I don't just want to show the kind of days, which is a little bit like fairy tale stories.
Airbnb moved up. They discontinued their Enzyme UI testing library and went to React Testing Library. They migrated in six weeks, and they did a really nice write-up about how they did it, AI-assisted. Asana did the same thing in about two weeks. There's some nuance there because they spent a few years before doing it. And again, these are practically full rewrites of test suites. It's not replacing a library. There are some interesting details there. Uber moved from JUnit 4 to 5 in four months, which was millions of lines of code. And again, it literally would have taken them just years slogging away beforehand. So these things are just cheaper and better and easier.
Agent-generated issues are on the rise. Fresh data from Linear shows that on their platform, the white line is human-created issues, tickets, and the blue line is agentic or MCP-created tickets. And for the first time, more agent-created tickets are happening on their platform than human-created ones. And you can see the sharp rise in the last few months.
We're also seeing agent-only reviewed pull requests are on the rise. So just in July and August, agent-only reviewed pull requests, where no human reviews it, are spiking, which is also a very interesting trend. This is data sourced from GitHub on how agent-generated PRs are just exploding. In January, there were 7.7 million. The number is less important than the trend: nearly 10x increase by August, agent-only. So this is the agentic software factory at work.
And skills usage is also going more mainstream. More people are doing it. This is data from Factory AI, where they're seeing about 80-something percent of their users use AI skills. So it's just again going kind of mainstream compared to February, when it was 30-something percent.
Cost is a big concern for a lot of you. You will know this. But back in May, there was already a widespread trend about companies worried about cost. This was around when it made the news that Uber blew through its annual budget for AI, and Claude Code was becoming more popular. AI was getting more expensive. Now by September, a lot of the large companies have managed to take control of their cost curve, and they're cutting back costs, per-token cost about 50%, keeping costs flat after investing in open models, smarter routing and so on.
Another interesting trend is the disappearance of engineering specializations. Inside OpenAI, I talked with Sulman Choudhry, ChatGPT's head of engineering, and he said that although specializations in engineering, he suspected they would go away, he's still surprised how quickly it has happened. Last year, they were still looking for iOS and Android specialized engineers. This year, they're not because with Codex, in their case, or LLMs, they feel that anyone can do the work at a good enough level, which is a very, very interesting one. And I'm seeing this a lot for frontend, mobile. Most engineers have been familiar with backend, but same thing, a frontend engineer can do more backend now.
Projects are increasingly being done by one or two engineers. So inside, I talked with Katelyn Lesse, head of engineering for Claude Platform, and she just put it out so simply. She said, "On an individual project, you cannot often have more than one or two engineers 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. So there's only maximum one other engineer you can take, who will also bring their agents, because now you're looking at a lot of individuals doing it. And one-person projects are becoming so much more common inside of startups who I'm talking with, by the way.
Some other changes: teams are getting smaller. We're seeing this everywhere. This kind of comes logically from the points before. There's less junior hiring happening across the industry. It's fallen, not dramatically, but it just keeps going slower. We're seeing data inside of The Pragmatic Engineer and elsewhere about intern hiring just keeping going lower and lower. And agent infra is finally its own discipline.
So this was a lot of changes. We went through 16 different things, and I was just throwing things at you. I was trying to keep it concise, but just so many different things are all changing. And these changes, I want to stress, these are the last 12 months. Before, none of these were really true, maybe except for the junior hiring one.
So what did not change? Because the industry is not like we're pulling a Meta, where we're trying to disrupt completely ourselves, but it is happening. Some things have not changed, though. Number one is teams have remained as the unit of work. Inside of Anthropic, I was pretty pleased to hear that teams are a big thing. And again, Katelyn told me this. She said, "One thing I've heard from some people is, 'Oh, we have two humans and a bunch of agents.'" And then she says, "This is not where we're at. I still have teams whose job is to own a piece of software, own on-call, and so on. And while each of these humans is supercharged by AI, the size and the shape is still similar." They still have two-pizza teams like before.
Same thing, by the way, with OpenAI. Same thing when you look at any successful agentic product. It's with a team, right? People go on vacation. They create energy with each other. They inspire each other. They hold a high bar. They keep each other accountable. This is not going anywhere. Don't let anyone tell you, "Two people and a bunch of agents." That's not going to be a team. That will be a one-off project, maybe.
Planning has remained for complex work. Inside of Anthropic, for example, Katelyn told me that for their more complex infrastructure-related products, planning hasn't changed much from, for example, years back when she worked at Stripe and so on. And building the wrong thing is still a waste, even when building is faster. Planning is especially important for infra complexity, aligning teams, communicating with customers. And again, this is not changing.
Tests and validation remain important. We know this, but this is, for example, Jarred Sumner on the Bun team, who rewrote Bun inside of Anthropic. He said that the AI writes pretty much all code, but we have the AI write pretty much all tests. Before AI, for production-ready software, we spent about the same time writing tests as we did on writing code, and this has not changed. The ratio has not changed. And he is stressing that you need to have a way to trust your code, and tests, he says, are probably the best way to do so. There are, of course, different layers of testing. Formal verification is also starting to become more popular, but we need to validate this code that we're producing.
And this is an interesting one. I keep hearing about how non-engineers are now able to ship production code, and I've been asking around the past week, everyone, if this is happening. And no, it's not. They're not shipping to prod. They are building websites. They are tagging in Slack, saying, "Oh, this is a bug. Can you look into it?" And sometimes that Slack bot might create a pull request. But those people typically don't even know what a pull request is, and they are not shipping production code. They are alerting the engineering team to bugs. But engineers, every company, every startup from Linear to Cursor to OpenAI's team, you don't have non-engineers push production-ready code in any shape or form. So this is still not happening, and I'm not sure if it will, by the way.
And then this is interesting. Old patterns are being rediscovered again. I talked with Matt Pocock, the creator of the grill-me skill and a well-known educator, and he told me that after he discovered the term tracer bullets from The Pragmatic Programmer book, he started to dive into different books. He was looking for keywords, for leading words where the agent does better work, and he started to read the old books. He came across A Philosophy of Software Design, where he got into deep modules and shallow modules, and he figured that when he says these words to the AI, it writes better code. Who would have thought? On one end, it was trained on it. On the other end, those methods, I guess, work even with guiding the AI. Fascinating.
So we went through what changed, what did not change. I'll talk about what broke. Code quantity and our assumptions about it have just gone out the wall. We see the GitHub outages, and they are publishing, to their credit, data on what's happening. This speed of how many pull requests are pushed.
Per month, the commits, the new repos in a three-year timeline, they're up about 5x, but just in the last six months, they're up by so much more. Data that GitHub gave me actually showed that they're seeing again that 10x increase in agentic-only pull requests, but in the last two months, pull requests have gone up 2x. That includes everything as well. It's just speeding up really quickly.
Code reviews are just done for. I talked with an engineer who asked not to put his name on here, but he said what a lot of people are saying. Everyone is playing the theater of doing reviews, but with the volume of changes that get thrown your way, he observed that people just find the path of least resistance. Some teammates just give up and say, "Looks good to me," on all of them. Inside this startup, they're gradually starting to phase out code reviews themselves because it just doesn't work. I just call these zombie code reviews. It's happening everywhere. If your team is still doing code reviews, you're probably not doing code reviews, unless you've cut out and you're not doing code reviews on 80% of them, or you're not mandating them.
Inside of Ramp, they have started to say, "Look, we're going to trust you to not do code reviews for certain non-critical parts of code." And I think more companies will do that.
Quality and reliability—you can see this in every software across—it's just breaking. Everything is broken. Some people complain about it, talk about it. You look to different sites. I see it all the time in just the sites I use, from Spotify to Substack, a lot of paper cuts. Clearly people are shipping more with agents, or agents are shipping more, and you can see it everywhere right now.
This is interesting: infra capacity. We know there's a GPU shortage across the industry, but unless you're an AI lab or an inference company, you're not going to worry too much about it. Or an AI startup that wants to get GPUs, then you will be worried. There's a memory shortage, which means memory is more expensive. But again, most of us will not see too much of that. What I was very surprised to hear is there's a CPU shortage as well for cloud companies that are running just normal workloads. It's starting to get harder and harder to secure your CPUs. I covered this in The Pragmatic Engineer just very recently with a bunch of examples, including from Turbopuffer and Anthropic.
Ordering a CPU or server used to take one to two weeks of back-ordering time. It's now up to six months inside of cloud providers. If you're a midsize customer, you cannot reserve CPUs in certain regions or in some regions. No more orders can be taken at all. And some companies are paying for CPU capacity that will not arrive until December. And they're paying for it because that's the only way they can get it. It's manic.
Another thing that broke is our focus and our productivity. I just took one quote from Dima, also at Linear, who I had a really good conversation with. Dima is an amazing engineer from before AI as well, and he told me there's just a lot of context switching. There's always another agent that awaits your response, and also it's just a lot more work. He was really honest. He said, "Look, when AI was ramping up, I felt more productive than my peers because I did in an hour or two what took them a day, and it was awesome. However, now this has become the baseline expectation that everyone does parallel things." And so he ends up feeling as having more work compared to pre-AI. It's worth reflecting if you're feeling like this, because a lot of people are feeling like this.
Finally, engineering leadership. There's something going on with engineering leadership. A lot of you are here, so I'm glad that you've not walked out the door, but a lot of people have walked out the door. I did a deep dive on this. I talked with about 20, 25 engineering leaders who are either taking a career break or will be taking a career break. And there's a lot of reasons for this, but the main ones, I'll just list briefly.
The job of an engineering leader just got a lot worse, a lot harder. Some of it because of founder mode expectations with AI. Some founders are pushing you to fire half the team. Others are pushing you to show revenue going 2x when AI spend goes 2x, and so on. It's unrealistic expectations. It's just harder to do a good job.
Many startups are losing, and leaders see that they're losing. Your equity is getting worthless, or the startup is on a path to bankruptcy. So you try to turn it around, you cannot, you check out. A lot of startups are not adopting AI workflows fast enough. And if you are in this room, you will know that career stability is also important. You're working at a company, and you might work here in two years or three years or four years' time, but there's a good chance you won't.
What you want to make sure is, if this doesn't work out or it's one of the reasons above, you can go and work at another place, carry on being an engineering leader. To do that, your current company should adopt AI practices. You should be changing how the world is changing. And when it's not, that's where I see a lot of engineering leaders quit. This is slow-moving organizations where you are stuck working in the same way as in 2022 for the next two or three years. You will go in a career kind of hole.
What about smaller teams? With smaller teams, you need fewer leaders. A lot of smaller teams come with middle management being cut as well. Sometimes there is just a lot less need for this.
Fractional CTO work is becoming surprisingly popular, especially in metro hubs like New York, San Francisco, maybe even Seattle. Some of these engineering leaders who quit voluntarily, they just don't want to go back right now because it's too messy. But they will do fractional CTO work. And all these fractional CTOs want to be hired full-time, but they don't want to go back full-time. It's a very interesting trend.
Also, elephant in the room: the AI startups will pay way more total compensation, sometimes even cash compensation, than non-AI startups pay. You see how Anthropic is getting the CTOs of every single major publicly traded company to join as an IC or someone with a small team. They're also paying more. That's also one of the open secrets. A lot of leaders like you realize you're hands-on. If you want to do a startup, now is a perfect time. You can probably also get VC funding if you have the background and you have the pedigree. And finally, some people are just burnt out, feeling it's a good time to take a break, see things settle, and then come back a bit later.
So, what comes next after all of this? Here are a couple of things that I'm pretty certain are happening and will happen. First one is just cloud agents and harnesses. Everyone with some engineering resources is doing it for many reasons. Ramp is doing one of the most advanced agentic harnesses right now that works really well for them, way better than Codex or Claude Code or any of them. I talked with them in detail on why they're doing it, and they do it for three reasons.
One, local machines are a lot more limited than the cloud. Two, they're huge on front end. They build better front-end tooling in the cloud than they have on local machines. And three, they wanted to have remote developer environments anyway, and this kills two birds with one stone. The only problem with this approach is when you have a CPU shortage, it might be a little bit trickier to secure, but again, it's a small detail. So many other companies are doing it, and so many will follow.
This is again Dima from Linear. I asked Dima, "Hey, Dima, what do you think about cloud versus local?" And he said he was such a big fan of local development, and the industry is still lagging behind on Devpods. That was something we did at Uber, and tooling for cloud development. However, he changed his mind about the future because he now sees cloud as the future, because whenever he kicks off stuff grinding in the cloud, it doesn't hog his machine. It's faster, easier, etc. This is definitely the future.
We will stop reading the code. This doesn't just come from me. It comes from Charity Majors, who is such a big skeptic, and I love her. On the podcast, we were talking about what it would take for you to be comfortable shipping code without reading and understanding it, because this is what ops have been doing. This is what QA have been doing. It's not an if, it's a when. It's coming.
We will be building out, and are building out, new types of internal infra. This means eval will be part of CI/CD if it's not already. We will have these agentic factories that we keep iterating on. Agents will be part of deployments, observability, incident management, and so on. And again, it's already happening and will just keep happening even more.
We will have a refactoring wave, migrations, rewriting. Look, when it's so easy or cheaper to refactor, why not do it? Plus, it's great exercise to use some of these agentic skills risk-free.
AI fluency and positivity will be a baseline for hiring and to be hired. I talked with an engineering director at a CZ startup who said that they have started to screen for AI positivity in their hiring process. He said, "We just don't want people to join. We want people to join who want to help us push the limits of what we can build with AI." As a leader, just know this is the case, and this is true when you're hiring, and also it's true when you are interviewing.
And getting to AI maturity is something that so many companies will be doing. Startups might think they're already there; larger companies are pushing for this. From Laura Tacho, who was at the Pragmatic Summit in February: she's saying that orgs who are moving faster and maturing do something different. They begin with a business outcome and work backwards from there, and they build an agentic system that reduces the handoffs, increases learning, and removes friction. All of this is a little bit high level, but it's the right direction.
And she's saying that the wrong way to do things, one of the easy ways to do it, is individual-level simple automations. But what's hard to do, what all us leaders should be doing, is team-level agentic systems or even company-level agentic systems. That's why you'll see all of that AI infra happening, because that's how you do it.
Finally, engineers with deep domain knowledge will be so much more in demand. Titus Winters, author of Software Engineering at Google, told me something so interesting yesterday. I love Titus. He said what you need to succeed anywhere: intelligence, wisdom, and charisma. You need intelligence, meaning you know how to do it. Wisdom means you know what to do, and charisma means you convince others to do it. Now, when intelligence becomes commonplace, or with AI the how to do it becomes just very cheap, widespread, wisdom and charisma become much more important. As leaders especially, remember this one. And I'm not saying don't focus on intelligence at all, but he has a point here.
So in this new world, how do you thrive as an engineering leader? My advice is future-proof your career. Get hands-on if you're not already, but most of you are. Stay hands-on building software, shipping to production. You will hear stories. Will Larson in the other room, he's chief product and technology officer at a 50-person engineering organization. He has shipped more code into production the past 15 months than in the past five or 10 years combined. And if he's doing it, you can do that as well.
Build out AI infra systems that help your team and your company succeed. And you'll also get hands-on with this. Use AI to remove friction from your own work, from your team's work, and from your company's work. And don't outsource your learning. Use AI to get better. Don't for—you're not going to get ahead, but your peers that do it will.
And finally, accept that you'll probably just do less people management for now. This is not really the time. ICs don't expect it as much. We don't even know what that career looks like. We will figure it out. We will get back to it, but also this is not your main expectation from above and from founders and so on.
Finally, just lean in, learn more before, and you'll be fine. With Peter Mattis, I had such an inspiring conversation. Again, this person built so much incredible software. He is a CTO of, I think, a 600-ish-person organization, hundred and something engineers, if I recall correctly. At some point, he went on to being a hands-off engineering leader, and now he's back to hands-on. And he told me, "You just got to get in there. You need to be using these AI tools all the time, and you need to push yourself to learn." He says, "I feel I've learned more in the past year than in the previous five years combined," which is weird because he's a wicked experienced software engineer. He's built some amazing software.
And finally, just ask yourself, why did I get into tech? When you started, why did you? Peter told me his reason. He said, "I got into software engineering because I like building stuff, and now I can build faster and without some of the compromises I had before. It's a little bit exhausting, but it's also very, very exciting." So with this, just keep on keeping on. Check out The Pragmatic Engineer, and I'll see you at the Antithesis booth. Thank you.
Article published · Updated