Firebase – built by Google – has had a nasty outage this week with shockingly poor incident management at odds with how Google itself usually deals with high-severity incidents.

The outage started on Tuesday (29 Sep) at 5:41pm (PDT), when iOS apps using the Firebase SDK started to crash upon first opening; every iOS app that uses the Firebase SDK with analytics enabled was affected in this way. Developers of affected apps opened a GitHub ticket, in the absence of much else to do. On the ticket, the message “it’s crashing for me too!” was oft-repeated.

6:51pm (PDT): acknowledgement. An hour and ten minutes after the crashes started, an engineer on the Firebase team acknowledged that they were aware of the outage.

It’s unclear if the Firebase team was alerted via this ticket with 100+ comments by devs, or if Google’s own monitoring tool showed the issue. I asked Google/Firebase two days ago and haven’t had a response.

Not having anything better to do than wait for Google to resolve the issue, the memes began:

Others attempted to help the Firebase team by pinpointing the potential issue. Indeed, before a Google engineer acknowledged the incident, an external developer found the root cause at 6:37pm PDT; it was a zero-length entry that was crashing the SDK:

Given the flags are shipped by the backend, the offending change was a backend one, and the easiest resolution would be to roll it back, which the community practically begged Google to do:

Here’s a neat summary of the incident from another dev:

7:24pm (PDT): rollback starting. An hour-and-a-half into the incident, the Firebase team started rolling back the offending backend change:

8:16pm (PDT): rollback complete. And the rollback completed ~50 minutes later:

Software engineer, Nick Cooke, on the Firebase team posted a summary with more accurate timestamps:

What we can deduce from this:

• TTD (time to detect): one hour? The Firebase team never shared how long it took them to detect that practically all iOS apps using Firebase had started to crash. On the GitHub ticket, they acknowledged the incident 70 minutes after it started. Update: in the postmortem, later published by the team, they wrote how the team was alerted 20 minutes after the rollout, via crash alerts and GitHub issues. Good question why it took another 50 minutes to acknowledge the issue, though?.
• TTM (time to mitigate): 2-6 hours. It took two hours and eleven minutes to roll out the fix, but due to caching (apps that had cached the incorrect server response served this cache for additional four hours, and so kept crashing for up to six hours.)

Incident management basics

The Firebase team itself closed the outage with a short report effectively saying that there had been an outage, but they’d resolved it now, so thanks for your patience and have a nice day.

This handling of a high-impact incident is absolutely not typical of Google, the company that coined the term ‘Site Reliability Engineer’ and wrote the SRE book.

For one, Firebase never bothered updating its status page. Oddly enough, the official Firebase status page showed all systems green – despite the acknowledgement of the outage. Indeed, during it and afterward, they didn’t update the status page to indicate the lengthy outage:

But status pages exist for good reasons, including:

1. To communicate with customers during and after an outage
2. Offer transparency on the stability of the service

It’s worth asking: if an outage that takes down most (or all?) iOS apps using Firebase doesn’t warrant an update to the status page, then what does!

Google published a postmortem four days later, answering questions on how the outage happened. On Friday, 2 October, Google published a postmortem on the Firebase blog. It was a configuration change that crashed so many iOS apps. From the postmortem:

“On September 28, 2026, a routine configuration cleanup unexpectedly caused a large number of iOS applications using the Google Analytics for Firebase (GA4F) SDK to crash.

2026‑09‑28 17:38 (PST): A stale, legacy configuration flag was cleaned up.
2026‑09‑28 17:41 (PST): The malformed configuration payload begins rolling out globally to production servers. Outage begins: Clients fetching the new payload start crashing on launch.

The SDK missed validating that a flag’s name was not nil, ultimately causing the crash. Backend data anomalies should not cause app-side crashes.”

In the postmortem, Google noted that engineers were alerted to the outage through both GitHub reports coming from external developers, as well as their internal monitoring. It took another hour to pinpoint the cause being a legacy configuration flag cleanup.

Firebase says they have no way to update their status page for client-side outages. In the postmortem, Google explained that there is no place to indicate client-side outages on their dashboard (emphasis mine):

“Throughout the outage, both the Firebase and Google Ads status dashboards remained green. Because these dashboards rely primarily on server-side health metrics, they did not register client-side SDK crashes.

Commitment: Moving forward, we are actively working to: integrate SDK-related outage information into our status dashboards, streamline the manual update process, and improve GA4F status representation within the Firebase dashboard.”

It’s good to see Google not dropping the ball fully, and recognizing that both their dashboards and their incident management process need improvement.

It’s fair to ask though: why did only iOS crash, and not Android? Firebase’s Android SDK seems to be hardened more than iOS, as the feature flag removal did not crash Android devices.

Especially that now, with AI, it’s easier than ever to compare iOS and Android implementations to ensure they are identical – and it’s what Shopify has been doing during their native rewrite – could it have been a missed opportunity for Google to audit the differences between the iOS and Android SDKs? To me, not having an action item here feels like a missed opportunity.

Still, this is a good reminder to anyone and everyone shipping iOS and Android apps: aim to harden them, and when possible, run tests with malformed payloads, then fix crashes those payloads cause.

Déjà vu: the 2020 Facebook SDK crash

The last time there was a similar crash was in 2020, with Facebook. That May, apps such as Spotify, TikTok, Pinterest, and others also started to suddenly crash due to the Facebook SDK crashing all apps using it. Back then too, devs followed along on a GitHub ticket and they also found that bug: a value that should have been a dictionary but was a boolean:

Then as now, there was banter by devs being made to wait for a fix:

And requests to not move fast and break things any more:

Making light of the situation:

And also anticipating the resolution:

In the end, Facebook reverted the backend change, but shared even less than the bare minimum details from Google this time. This is all we know about that 2020 outage that was arguably more wide-ranging than the Firebase one:

I wonder if some people think that public-facing incident management is no longer important or valuable, even for developer-facing products. I’m not shocked that Facebook/Meta never bothered to communicate much about their outage because dev tools are not part of the DNA there.

But with Firebase, I am surprised that more than a week later, the postmortem is still not visible on the Firebase status page.

And maybe this is Google “shipping their org chart” playing out, live. The outage technically was caused by Google Analytics (who made the feature flag change), but is the responsibility of the Firebase SDK (whose iOS SDK was not hardened enough to deal with this new payload). The outage itself was buried inside a Google Ads dashboard (!!) which suggests that whatever team is seen responsible for the outage is inside the Google Ads organization.

In the end, despite the Firebase team committing to “improving status dashboard latency and coverage,” last week, those teams are in no hurry to carry out this work. AI agents might be making lots of work more efficient, but following up on action items seems to move at the same snail pace at Google, as it did pre-AI!

Read the full issue of The Pulse this is from, or check out this week’s The Pulse. This week’s issue covers:

1. New trend: building internal vibe-coding platforms at mid-sized companies. Ramp and Stripe built platforms for non-engineers to build internal websites and tools with, and both are taking off in those workplaces. I expect more companies to do the same.
2. Do us engineers really enjoy hard problems? Or do we actually like pattern-matching with backend problems? A provocative post by Cloudflare engineer, Sunil Pai, suggests there are other motives.
3. New open models launch in the EU and US. Kolibri, Mistral Large 4, and Beam by Reflection could challenge China’s dominance in open weight models.
4. Industry Pulse. Why Figma doesn’t let any agent use its MCP server; Google Cloud adds Swift support on the server side, Anthropic’s two-week sprint to speed up Claude Code, Coinbase dumps React Native shortly after Shopify announces doing so, Claude Opus 5.5 formats the C: drive, and more.

Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover Big Tech and startups through the lens of senior engineers and engineering leaders. Today, we cover one out of four topics from the last week’s issue of The Pulse. Full subscribers received the article below seven days ago. If you’ve been forwarded this email, you can subscribe here.

The creator of Ruby on Rails, David Heinemeier Hansson, caused quite a stir last week with comments in his Rails World keynote, when he revealed that coding by hand is dead at his company, 37signals.

This is a big deal because 37signals created Ruby on Rails, and they are known for their software craft there, especially when it comes to code quality. It’s also a business that’s 27 years old and is profitable. Despite that pedigree, DHH caused a stir among the dev community, saying:

“At 37signals, a couple of weeks ago, we made the decision that it clearly means we’re done writing code by hand. We have gone pencils down on the idea that we were gonna write code by hand, as a normal course of business creating things.

Writing code by hand at 37signals is now an exceptional state. It is like seeing a bug in Sentry: something here went wrong; why was the agent not able to produce what we wanted? Okay, maybe for a little while, we’ll still get the old pencil out and dot it down for them, but then we fix the machine, we fix the factory, we get things going again. This is a recognition of what’s already happening.”

DHH compared the maturation of AI tools into being highly capable at coding with the impact upon the craft of painting of the arrival of the camera:

“On November 24th, 2025, we got the “Kodak Brownie” of our era. We got Opus 4.5. AI technology, accessible in a harness that many people could afford to use and experience for the first time what it’s like to create software in pairing with a new form of intelligence. This was the tipping point for me. There was everything before November 24th, and then there was everything after. This is going to be the date that history books going forward will mark as the inflection point for the age of agents.”

He shared how 37signals has embraced a future where coding by hand is almost entirely absent:

• Embracing native mobile apps instead of web: famously, 37signals is bearish on native iOS and Android apps and has built web versions instead. With AI, they are betting on native apps being much easier to be built with a small team and are already building new ones.
• Moving backend services to Rust, not Ruby: This is due to performance reasons and because agents write good enough Rust. That’s remarkable to hear from the creator of Ruby on Rails!
• Ruby on Rails remains for web apps: 37signals is not leaving RoR behind, but only because Ruby on Rails’ convention-over-configuration design makes it easy for agents to work with it.

DHH closed by revealing that he no longer even thinks of himself as a professional programmer (emphasis mine):

“I have retired from being a professional programmer. I think it was somewhere around 4 to 5 months ago, maybe March. I spent a quarter of a damn century chiseling code by hand and loving every moment of it. This is not something to look back upon with regret; this is something to look back upon with joy and accept that it is over.

Writing code by hand is no longer an economically productive enterprise for the vast majority of programmers working at the vast majority of companies. On the other side of that is a new career as a professional maker of things, steering intelligence that was only available in science fiction up until a few moments ago.

One of the things we’re gonna have to revisit is everything we think we know about software architecture. The main tool that we’ve used for a very long time is abstractions. Abstractions don’t make quite the same sense in the age of agents. The reason we did abstractions was in part not to repeat ourselves; well, now the price of repetition has gone to near zero.”

It’s worth noting DHH’s keynote chose a spicy topic for a conference attended by engineers who are personally and professionally invested in the craft of building software!

Decline of coding by hand is long predicted

In the first issue in The Pragmatic Engineer this year, on 6 January, I wrote:

“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. (...)

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!”

I concluded that this change was on its way, based on my own experience of building software with Opus-4.6 and GPT-5.2, and from talking with experienced engineers who had resisted “AI hype” for good reason, but who had come to see that AI can now generate code that’s “good enough” in many cases.

Back then, I made a few predictions about what will happen when AI agents are producing most of the code for engineers:

• Sloppier code
• Weak software engineering practices hurting sooner
• “Coders” who are not software engineers see less demand
• Tougher work-life balance for engineers
• Junior engineers pushed to become seniors, fast
• Computer science education increasingly required for new hires
• A massive explosion in code and software, for which someone must be accountable

So far, it’s a messy transition and we engineers are responsible and accountable for a lot more code that we didn’t write, but which is in production anyway.

Non-engineers also getting into agents

At the end of January, I shared a deepdive that was pretty close to home for me: my brother’s 30-person, 15-engineer startup, Craft Docs, made its own sharp pivot to AI by building their own AI harness for non-engineers – called Craft Agents – two weeks before Claude Cowork was released, and months before ChatGPT Work launched.

Craft resisted the temptation to use AI when it did not feel productive, but with the model releases of November 2025, they found LLMs are not only useful for coding, but also for non-engineering work like customer support. In the deepdive, I went into more detail about non-engineering use cases (which engineers enabled) like:

• Automatic triaging of bug reports with agents
• Data enrichments added to all workflows
• Customer support “skills” like processing feature requests
• The marketing team building websites without devs
• HR automating tedious work
• Finance automating personal workflows

Craft Docs seemed early to a trend that has become more widespread, by having both their own engineering and non-engineering folks onboard to an AI harness. Now, there are signs other companies are doing the same: at OpenAI, non-engineering units like finance, recruitment, and legal moved over to Codex in June 2026:

In some ways, it could be comforting to know that it’s not only software engineering where the tools and workflows are quickly changing: every other function in tech is experiencing the same!

It’s messy right now

Just last weekend, a rant by an anonymous engineer in Big Tech hit a nerve with many people in the industry. An engineer with the username voxium posted (emphasis mine):

“The state of engineering right now is horrible. It has been half a month since I started a new role at a big company.

Nobody knows anything here. The specs, code, tests, PRDs, tickets, resolution of those tickets, reports, etc., everything is made by Claude Code. Nobody on my team likes this.

They are being forced to ship as much as they can. I have heard multiple times from higher management that pushing code is not a bottleneck, so why are we slow?

People are working 12 to 13 hours a day just to press enter. Nobody is reading anything. Humans in corporate are doing nothing on their own.

Everyone, literally everyone, from an L1 to an L7 engineer here is doing the same thing. Talk to Claude.

There is no sense of victory. Nobody is resolving bugs. In reality, nobody is thinking anymore. Everything is done by LLMs. It is so soul-sucking.

I would not mind it, to be honest, if we were at least given the time to check out the code and see what is going where. But no, the goal is to just ship. No matter what happens.”

This post rings true because it is happening at many places where there’s more AI usage, engineers do “outsource” thinking to LLMs, and end up not caring about anything else except shipping something to production.

Quality in decline

Since the beginning of the year, the quality of software has been degrading pretty much everywhere, much of it caused by over-reliance on AI, or perhaps more accurately, the outsourcing of thinking and decision making to AI. In July, I moved my video podcast off of Spotify after a series of unexplainable outages, and Spotify’s engineering team seemed to take no real pride or accountability in fixing the root causes of the issue.

Only this week, Uber shipped a new feature to production in the Uber Eats app – a new way to select extras with your food order – with seemingly no QA testing:

Inside this new “add-ons selector” in Uber Eats, I noticed three bugs at once:

• “Choose up to 999”: no engineer, designer, or PM bothered to check what happens when a restaurant does not fill out a number on how many toppings to add, or adds a ridiculously large number. The most toppings that my screen allowed to be selected was six and not 999, so I could not even choose the option of 999 buns for my burger.
• Sloppy overflow. A rule of thumb, during my time at Uber, was that text will never overflow, even when localized. Basilcummaynaise (basil mayo in Dutch) broke this rule but still shipped.
• Functional bugs in the selector. I originally tried to order from my favorite Mexican place: a bowl with no rice or bulgur as the base. There’s the option to select “rice”, “bulgur” or “nothing” as the base, but selecting “nothing” counts as an extra side, and the app doesn’t allow the ordering of a bowl with no base.

I’ve used the Uber Eats app for years, and this was the first time I saw such a sloppy feature release. I assume that devs and PMs building it have all “checked out”, stopped doing proper QA, and assume that the agent will take care of all of it. There’s no other way to explain three bugs shipped to all customers but seemingly noticed by nobody until I posted about it. To the Uber Eats team’s credit, they reached out and are looking into fixing all three issues.

Software engineering to be more important than ever

I’m personally past the shock and grief stages of agents taking over the activity of coding. At first, I assumed this change would reduce the amount of work for engineers. But, counter-intuitively, that actually seems to be growing:

• We need to understand the characteristics of LLMs better. LLMs feel familiar as they can produce text in a way only humans could do before. But they are less reliable, still prone to hallucination, suffer from capability gaslighting, and many other problems. They can also be expensive and slow.
• New systems need to be engineered. Agentic “software factories” can now produce code, based on the input provided. But how is this code validated? How much can detecting defects or various issues be automated? This is a brand new area, and we need to build new types of systems, often based on old ideas. One such example is OpenAI’s software factory, the other one is Ramp’s Inspect internal coding harness.
• Nondeterministic LLMs can generate deterministic code. An area I feel is under-explored and under-appreciated is the use of LLMs to substitute LLMs usage in agentic “software factories” with deterministic code they generate. For example: instead of running AI code review that is expensive and slow on all PR requests, could AI generate linters that catch the majority of common issues? If this is possible, complex lint rules would run faster, be more reliable and cheaper to execute than LLM calls.

New categories of systems and products will be built by engineers who “get” LLMs and AI engineering. We are seeing the majority of venture funding pour into AI companies because AI creates new business models, new revenue streams, and disrupts “traditional” software. For example, who would have thought that companies would spend tens of thousands of dollars, per engineer, on AI coding tools? Or that the category of AI inference providers would become as massive as it already is from barely existing two years ago?

This technological change will re-jig parts of the tech industry: the winners will surely win big, and teams and companies choosing inaction could be out-executed and displaced by nimble competitors. And in many ways, this is great news for us software engineers who keep up with the technology. Companies are now investing in innovation and are willing to pay top-of-market for software engineers who can help them build AI products or become AI-native.

Read the full issue of The Pulse this is from, or check out this week’s The Pulse. This week’s issue covers:

1. Firebase: global outage & poor handling by Google. The Firebase iOS SDK crashed after a backend change, crashing all apps which used Firebase analytics for 2-6 hours. Google did not update the status page or offer any postmortem, which is a head-scratcher from a company known for standout incident management practices.
2. OpenAI’s platform play from AWS playbook? OpenAI is becoming a platform where it’s possible to allocate ChatGPT spend on open models and AI offerings from among 16 partners, not just OpenAI models. It’s fair to ask if Anthropic will consider a similar platform play.
3. More data on companies moving to open models. Vercel’s AI gateway shows 60% of model spend goes to open weight models, and OpenRouter also shows open models are being more used than closed ones.
4. Why CTOs and VPEs are quitting en masse: another take. What if it’s not “founder mode”, but about people who love building software, feeling like they can do it solo (or with a small team) with AI tools?

I was at dinner with a bunch of CTOs and Head of Infrastructure folks recently, and from the conversation it was clear that many companies are struggling to source CPUs in the current climate, and are coming to terms with the end of juicy discounts from cloud providers for machines in the new era of surging demand fueled by AI.

The ‘memory crisis’ afflicting sectors like video gaming is well established and has been extensively covered in terms of shortages of GPUs, but now it seems like things are just as hard for businesses in need of CPUs from cloud providers.

In a sign of how things are changing, the disappearance of CPU spot pricing was mentioned at the table. Customers used to be able to pay up to 90% less than the standard price for CPUs, as cloud providers slashed CPU prices for machines that were lying dormant and unused. But that’s no longer the case. It seems that spot pricing has vanished because there’s no longer any lack of demand for CPUs – quite the opposite.

I was surprised, but a lot of people chimed in; 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.

Even big players struggle to reserve CPUs

I have asked turbopuffer CEO Simon Eskildsen about their experience of CPU availability in the cloud, since turbopuffer, as a product, runs on CPUs, not GPUs. They operate in AWS, GCP, and Azure, so I asked how easy it is to get CPUs these days. Simon’s response:

“Getting CPUs is not easy anymore. As Reinforcement Learning (RL) is becoming a large amount of the workloads: RL needs a lot of CPUs. So the labs are sucking up a lot of CPUs. During RL, they need to teach the models how to do things, like searching, and then they need the model to run software, which then takes CPUs to run.

Then, outside of RL, agents need to do all kinds of very general purpose things on a CPU. So as the demand curve is shifting to general purpose agents, CPU demand is also going up.

Even the big companies are fighting each other for the right to get the CPU allocations. I would assume that it gets a lot worse before it gets better on the CPU side.”

I was able to confirm what Simon said about larger companies struggling; a VP of Engineering at a large inference provider told me they are at the limit on how much GPU and CPU capacity they can buy from their cloud providers. They have cash to spend and want to rent more capacity, and are willing to accept the longest leases. Despite that, cloud providers tell them no more is available!

AI hogging CPUs

Katelyn Lesse, Head of Platform Engineering for Claude Platform, has written about the reasons for the massive CPU demand increase:

“In the past few years, AI-fueled demand has skyrocketed, and these few companies suddenly needed multiple years and tens of billions of dollars to actually add enough capacity. We ended up with 3 separate bottlenecks in factory capacity that AI is exacerbating. At TSMC, GPUs are competing with CPUs (and with Apple, Qualcomm, and Broadcom) for production lines. And at SK Hynix, Samsung, and Micron, HBM [High Bandwidth Memory] is competing with regular DRAM for wafers.

What we’ve ended up with is CPUs getting squeezed from both sides. AMD doesn’t own fabs [semiconductor fabrication plants], so its CPUs need to come out of TSMC’s constrained allocation. Intel does own fabs, but it’s been working through yield problems and is now pulling some of its capacity from PC chips in order to make more server chips. And CPUs need DRAM which has gotten more expensive because memory production has shifted toward HBM. Analysts are expecting CPU supply to add more comfortable headroom before memory does, but their expectation is that it’s still going to be multiple quarters away.”

AI-fueled demand does increase CPU load, as shown in this graph from Uber, displaying the growth in agent requests over the past six months:

Increasingly, “agent requests” not only generate code which is inference-heavy – and therefore needs GPUs – but they also run tools that compile the code, run tests, run linters, and all of this is CPU-heavy. At companies like Uber, Ramp, and others, AI agents no longer run on the dev’s local machine, but on a dedicated instance in the cloud. So, the companies reserve more CPUs on their respective cloud providers for agentic workloads. We recently covered how Ramp built and runs its cloud agent, Inspect.

Basically, the problem is:

• AI applications use more and more CPUs, thanks to agents running a lot more software. AI data centers used to have a ratio of 1 CPU to 8 GPUs. Now the ratio is more 1:4, and it could shrink to 1:1.
• Companies that can manufacture more CPUs are busy on other hardware. TSMC is busy producing GPUs, which might be more profitable than CPUs. Meanwhile, CPUs also need DRAM, but DRAM manufacturers (SK Hynix, Samsung, and Micron) are instead producing high-bandwidth memory (HBM) because it’s more profitable. This is why memory prices are spiking; even Big Tech is unable to buy RAM, as previously covered.

To secure CPUs, it’s necessary to do capacity planning up to 12 months in advance. Katelyn says that server orders are being fulfilled in ~six months, instead of 1-2 weeks’ time as previously, and that prices are up by between 10-20%. So, it’s probably time for capacity planning. Katelyn:

“Most of us have never capacity-planned CPUs. We planned databases, we maybe planned accelerators if we needed them, and we autoscaled on-demand into CPU capacity as much as our budgets allowed us to. But general purpose compute is now something many teams will need to commit to ahead of time, which means you should probably start to forecast and plan around it. If you’re operating at scale, there are some things to spend your energy on.”

Using existing CPUs more efficiently is something to do, as of now. The CPU capacity shortage won’t go away, and any new CPU allocations requested could take months to turn up. So, what can we do if new capacity lags? One option is utilizing current resources more efficiently!

This is a great time to review and to establish now which services are CPU-intensive, and whether or not they need to be. Also check on services which are utilizing little CPU: can they run on fewer nodes, so that some CPU capacity can be allocated to services that need it more?

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.

It seems like this issue has spread everywhere as a corollary of widespread AI adoption. There’s a GPU shortage, memory shortage, and now a growing CPU shortage as well. Back at the end of last year, there was even an hard drive shortage. The only compute primitive not in short supply seems to be networking!

Read the full issue of The Pulse this is from, or check out this week’s The Pulse. This week’s issue covers:

1. Writing code by hand: is it over? In his Rails World keynote, David Heinemeier Hansson (DHH) declared the end for writing code by hand for professional work – at 37Signals at least. Is this change now unstoppable?
2. Amazon and Meta struggle to hire and keep engineers. Both Big Tech companies are scrambling to hire engineers who they previously laid off or enforced job reassignment upon. It seems experienced engineers remain in demand after all.
3. Opus 5.5 released and it’s good. Anthropic has released its new model that’s 40% the cost of using Fable 5.1 and has superior coding capability.
4. Code reviews to vanish sooner rather than later? Marc Brooker, Distinguished Engineer at AWS, believes that humans will have no role in routinely reviewing code by hand, and explains why this is all but inevitable.

Subscribe to The Pragmatic Engineer

Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover Big Tech and startups through the lens of senior engineers and engineering leaders. Today, we cover one out of five topics from last week’s The Pulse issue. Full subscribers received the article below seven days ago. If you’ve been forwarded this email, you can subscribe here.

In May, I covered an emerging trend of companies wanting to cut back their AI spending, starting with engineering departments. Different approaches were being tried:

• Experimentation with running cheaper, open models on inference providers
• More investment in model routing to route simpler requests to cheaper models
• Knowledge-sharing sessions on how to use AI models cost-effectively
• Setting per-developer monthly AI usage limits

A few months later, it seems that several companies have managed to achieve this, according to sources I’ve spoken with.

Uber: AI costs down 50%

Uber managed to blow through its annual AI budget in the first three months of this year, and it wasn’t a surprise to hear, in May, Uber’s COO say that it was getting harder to justify spending on tools like Claude Code without seeing benefits from the leading models. It wasn’t long until engineering teams at the ridesharing giant set to work on how to optimize AI spend, and their efforts weren’t in vain.

Uber cut the cost per AI request by 34%, and the cost per AI session by 52%:

Of course, Uber keeps using more AI tokens and starting more AI sessions, but thanks to optimizations the cost has been flat since March, despite significantly more usage:

How did they pull it off at Uber? It was via a combination of different approaches:

• Open weight models, run using inference: run open weight models on inference services, which are significantly cheaper than frontier ones.
• Optimized model selection: benchmark all available frontier and open models, to build an accurate picture of their present capabilities
• Ongoing benchmarking: run benchmarks every week based on real work, and update them
• Cheaper subagent models: subagents do smaller tasks not requiring the most expensive models
• Reduce model effort: Uber found that defaulting to Medium effort gives the best cost-to-output ratio with advanced models
• Optimize requests: trigger automatic compaction above 400K tokens, even for models with 1M context windows
• Cache prompts: cache prompts to save money when using Uber’s own harness, Minions
• … and more: Uber wrote an engineering blog post detailing the dozens of optimizations taken to reduce token cost without noticeable change in the quality of code generated by agents

From the outside, the single biggest win seems to be Uber’s transition to using open models for certain tasks. Open models cost 2-20x less, compared to frontier ones:

Pinterest makes 90%+ cost savings by dropping frontier models

Interesting details from Pinterest’s earnings call last month reveal how much the social media platform saves by running open models. Here’s what CEO William Ready said (emphasis mine):

“Our approach to model deployment includes our own compact fit-for-purpose models built for Pinterest-specific use cases and suitable open source models post-trained in our own environment within our secure cloud infrastructure. When we leverage open source models, such as with Pinterest Assistant, we are seeing superior performance for our use cases when compared to closed third-party models because we are able to post-train open models on our highly unique data.

With open models, we are achieving cost per transaction at less than 8% of the cost of comparable closed proprietary models. This gives us substantial headroom to deepen and extend these capabilities over time in a way that is differentiated, highly effective, and cost efficient.”

Basically, what used to cost Pinterest $100 to run on a closed, frontier model, they now spend $8 on by using open models on owned or rented inference!

AT&T: 56% savings by swapping Claude for open models

With 100,000 employees, AT&T is a big spender on AI. The telco giant cut its AI bill by 56% while measuring a 2% decrease in the quality of AI’s output, after they moved workloads over to open models. From The Information:

“Austin said he’s found that open source models are “just as good or better” than older models sold by the likes of Anthropic and OpenAI. For instance, AT&T’s software developers still rely on cutting-edge models for complex tasks like generating code, but can use cheaper open source models for less intense tasks like generating summaries of previously submitted code, he said.

After the company began using router provider LiteLLM, the costs of some advanced AI tasks such as coding fell by as much as 56% while the quality of the AI’s performance fell just 2%, Austin said.”

Anthropic overpriced compared to the rest of the market?

Only a few months ago, Anthropic was the preferred model (Claude) and harness (Claude Code) among engineers. But Anthropic’s models are becoming steeply more expensive at a time when open weight models – and also OpenAI – are getting much cheaper. Meanwhile, Opus 5 is 100x more expensive (!!) than models like GPT-5.6 Luna xhigh and DeepSeek. That may be simply too much to ignore for some tech companies:

Seeing this data, I’m not surprised that more tech companies are looking to run open weight providers on inference providers, due to the significant savings available from a model that’s similarly capable as one from Anthropic.

What worked for Stripe, Coinbase, Uber & Ramp

The engineering team at Databricks interviewed engineers at Stripe, Coinbase, Uber, and Ramp, and collected how different approaches helped save costs for them. The summary:

To answer the question posed in the header of this report, it’s apparent that using open models is indeed the approach offering the biggest savings, followed by smart model routing. Spending controls and context optimization also bear down on costs, but they don’t come close to the first two techniques in results.

A week after publishing this article, Ara Krahzian at Ramp has confirmed that AI spend in August, has, indeed, declined at the top 1% of businesses by 10%, based on Ramp data:

I’d wager those companies are not spending fewer tokens, but they are optimizing cost, in ways outlined above.

Read the full issue of last week’s The Pulse, or check out this week’s The Pulse. This week’s issue covers:

1. New trend of CPU shortages: after a GPU shortage and memory shortage driven by AI companies, we’re now experienceding a CPU shortage, thanks to AI agents using a lot more CPU with tool usage. If you will need more compute in the future: secure it now, while you can (even if it’s expensive to do so).
2. Growth dream ends for more COVID-era unicorns: Miro sold itself to Bending Spoons for $1.35B, after it was valued at $17B in 2022. Airtable saw a similar valuation cut last month, and it seems a batch of now-overvalued, VC-funded companies are desperate to sell.
3. Industry Pulse: Overtime at Google to get Borg working on SpaceX’s data centers; SpaceX cuts Claude Code tokens by 90%; OpenAI launches Astra; Meta unveils Muse (and Mark Zuckerberg pushed production code in this release); – to which Mark Zuckerberg made personal contributions; OpenAI’s agents go rogue, again.
4. Do engineers lose touch when AI handles incidents? In the aviation industry, pilots are exposed to emergency situations every six months, to keep their critical problem solving skills sharp. In the tech industry, we might need something similar, especially if AI would take on handling of the simpler incidents.

Two months ago, I asked why Meta appeared intent on destroying its engineering organization, at a time when the social media giant was reporting record revenue and profits. The question was raised after the company did two unexpected things:

1. Laid off 10% of staff. Executed large layoffs in May, with circa 10% of engineers shown the door.
2. Moved 20-30% of engineers to AI training. At around the same time, infra and product teams lost a further 20-30% of their engineers, who were reassigned to data labeling work for AI training.

The outcome of that period was low morale and a string of embarrassing outages, including a “zero auth password reset” outage on Instagram, where anyone’s account – including that of former US president Barack Obama – could be taken over just by asking the AI bot to replace Obama’s email with a different one.

Now, thanks to reporting by Reuters, new details have emerged about a plan for much larger layoffs, which eventually did not go ahead. The news report is pretty damning, and I want to get into what the planned AI job cuts reveal about Meta at this point in its history, what Zuckerberg might have been thinking, and what it could mean for other tech companies.

Making Meta “AI-native:” Project Organization Transformation

The plan was formed in January of this year. As per Reuters:

“In January, Meta CEO Mark Zuckerberg and his top lieutenants gathered for their annual leadership retreat at his Hawaii compound. There they hatched a radical plan to reimagine work at the social-media giant in the age of artificial intelligence.

Code-named Project OT – short for Organization Transformation – the plan envisioned an “AI native” future for the owner of Facebook and Instagram. AI would take over much of the daily work performed by thousands of human employees. Virtual workers would be overseen inside Meta by smaller, “talent-dense” cadres of human staffers, according to one internal planning document reviewed by Reuters and three people familiar with the project.”

The idea was that many existing teams could be reduced by 60% in their size through layoffs and reallocation of workers to other parts of the business. Underpinning this was the assumption that AI would enable these smaller teams to operate as well as before. HR at the social media giant projected that the project would involve a bigger layoff than happened in 2022-2023, when 25% of staff were let go. The new plan was to do one layoff+restructuring in May, and another in November.

I suspect a 30-40% company-wide layoff was planned.

But at the last minute, something changed. From Reuters (emphasis mine):

“But on the night of May 19, just hours before the first layoff wave, Zuckerberg blinked. Meta laid off 10% of its employees the next day, but it called off planning for the November cuts, according to one internal document reviewed by Reuters.

By then, Meta employees were in open revolt, convinced that the company’s AI transformation initiatives were partly aimed at replacing them.”

The Reuters report shows those employees were right: Meta’s AI initiatives were indeed aimed at laying off as many of them as possible, without changing overall productivity!

Even though these 60% cuts did not happen, some teams had 30-40% cuts and struggled to cope with their workloads. It also didn’t help that I talked with teams whose key engineers got reassigned to AI labeling: those were devs with critical domain knowledge that was lost after they left.

Why did Meta want 60% smaller teams?

You must assume that a company like Meta acts rationally overall, and on that basis it’s worth figuring out what the rationale might be in the case of ‘Project OT’. The article offers a hint: executives at the company had been captivated by “AI-native” businesses in Asia, Reuters claimed:

“Meta executives, including Chief Data Officer Alex Schultz and Head of Product Naomi Gleit, visited Asia last year and admired how startups there had built their organizational charts around AI, according to three people familiar with the trips. Meta executives also commissioned their own research into how AI startups were organized and set up pilot projects to determine what being “AI native” would mean at the company, according to one source familiar with the research and internal documents describing the pilots.”

And indeed, in February Meta experimented with “AI-native pods” as reported in The Pulse at the time. The presentation obtained by Reuters shows leadership intended to achieve 60% reductions in team size with small, 3-5 person, “AI-native” teams doing the work of what had been between 10 and 20 people:

And Meta is probably on the money that engineering teams are becoming a lot smaller at startups – and “AI-native companies” are also getting smaller, by size. But those are companies that are growing slower, without ever having done mass layoffs. Meanwhile, Meta seems to have wanted to become smaller not organically, and over time, but with a brutal layoff and sudden reassignments, in the span of a year, ignoring the impact such a sudden change would have on the company, teams, and employees.

Downsides of tiny teams

In theory, a smaller team could work better with less communication overhead and quicker decision-making, so there are cases where the upsides of a small team outweigh the downsides. For example, if there’s a small team of very senior folks with sound judgment skills, outstanding domain knowledge, and who don’t care about growing professionally anymore. However, such expected gains would come with several real costs, mostly associated with losing so much experience and skill:

• Domain knowledge: A lot of personal domain knowledge is suddenly gone.
• Redundancy: what if someone is on vacation, another is sick, and the other has an urgent appointment that cannot be moved? In a 10-20 person team, it would mean business pretty much as usual. But in a 3-5 person team, you’re down to two people doing everything!
• Capacity for oncall: a healthy oncall schedule needs 6+ engineers if every alert is to be taken seriously by an engineer whose main focus is oncall and systems stability.
• Lack of “slack time”: Innovation often comes from having time to focus on other work, instead of putting out fires. A bigger team naturally creates more “slack time” that can be used for other things, like university recruiting events, writing engineering blog posts, working with other teams on building things together, etc. In contrast, one that’s stretched thin with a maximum of 5 people or less gets almost zero slack time.
• Professional growth: engineers pair with more devs and get more feedback on larger teams. There’s more discussion and generally more opportunities to learn.
• Judgment: For honing one’s skills, there’s more experience and mentoring to be gained in larger teams than on small, “AI-native” ones where engineers spend the most time with AI. How good is AI’s judgment, anyway?

Is Zuckerberg’s worst fear being out-executed by a startup?

With Meta’s business posting record revenue and profits, and facing zero pressure to radically change how the social media giant operates, it’s worth asking why the social media giant was in a rush to get to 60% smaller teams. It would be a significant challenge for the 75,000-strong company, unlike for some small startups with under 100 people.

My hunch is that Mark Zuckerberg is paranoid about a startup which executes better and that could “destroy” Meta at some point. After all, this is exactly what Facebook did, back in the day. In 2008, Myspace was the king of social networks and Facebook was only a small player – yet three years later, Myspace’s usership had collapsed. The Huffington Post analyzed the collapse (emphasis mine) at the time:

“Just over three years ago, in the spring of 2008, Myspace was top dog. That April, the upstart Facebook grabbed the lead and never looked back. In those three years, Myspace has lost over forty million unique visitors per month, lost both co-founders, laid off the vast majority of its staff and more generally, has diminished to a cluttered afterthought of the power it once was.

In an interview with Businessweek, former founder Chris DeWolfe blamed Myspace’s overenthusiasm and underexecution on the product side for many of the site’s problems.

“We tried to create every feature in the world and said, ‘okay, we can do it, why should we let a third party do it?’” said DeWolfe. “We should have picked five to ten key features that we totally focused on and let other people innovate on everything else.”

Instead, Myspace unleashed a slew of products that were buggy and dysfunctional and confusing and alienating to users, and which couldn’t keep pace with Facebook’s own progress.

“[Myspace failed] to execute the product development,” former Facebook president, Sean Parker, said in a recent interview. “They weren’t successful in iterating and evolving the product enough, it was basically this junk heap of bad design that persisted for many, many years. There was a period of time where, if they had just copied Facebook rapidly, I think they would have been Facebook. The network effects, the scale effects were enormous. There was so much power there.”

Ironically, Myspace’s desperate attempts to recoup its former success came in the form of imitating Facebook, a site it’d once tried to set itself apart from. It adopted the news feed Facebook had popularized, and neatened up the site itself in a way that also suggested it was taking visual cues from Zuckerberg’s page. In November 2010, the site integrated with Facebook Connect, calling it “Mashup with Facebook.”

Myspace had twice as many employees as Facebook (around 800 at the time), and grew faster than Facebook in 2003-2007. But Facebook out-executed Myspace by being more nimble and more focused. Zuck’s business has seemed to try and be like a startup in its nimbleness of execution since then, not wanting to give anyone the chance to disrupt it like it did to Myspace.

If so, is Zuckerberg being paranoid about a similar threat to Meta today? Myspace was far from being the decades-old company that Meta has become! It was only founded six months before Facebook and got more traction in its early years, but fumbled execution as it grew. In contrast, Meta is today the tenth largest publicly traded company by market capitalization in the world, with a $1.4T valuation.

Then again, maybe there’s cause for Zuckerberg to be paranoid: Anthropic, only five years old, with one twentieth of the workforce Meta has, and might be going public at a close to $2T valuation as soon as October. Anthropic is not a direct competitor to Meta – it’s not a social media company – but Zuckerberg clearly sees AI companies as a form of competition to Meta’s business model. After all, every minute a person spends chatting with an AI chatbot like ChatGPT, they’re not spending it on Instagram, Facebook or WhatsApp.

Maybe this is one reason for the forced reallocation of 20-30% of software engineers to do data labeling and other training tasks on Meta’s AI model. To Meta’s credit, Muse Spark is a pretty capable model, and while it is behind the likes of GPT-5.6 and Opus 5, it’s already ahead of Google’s AI models – no small feat!

Most valuable assets: people or GPUs?

Let’s consider how Zuckerberg might respond if he perceives these things:

• Smaller teams execute better with AI
• These smaller teams can out-execute Meta: like Anthropic has done with AI model development
• There’s a danger that Anthropic and OpenAI could do with Meta, like Facebook did with Myspace

One approach would be to lay off 20-40% of the workforce, but there are consequences:

• Workers reject being treated like “cattle”. Meta’s “Project Organization Transformation” assumed that productivity would go up if teams greatly shrank and used AI tools. But would this happen? When people realize 60% of their colleagues were reassigned or let go because of AI, they might look further ahead: will another 60% be laid off at some point for the same reasons? Work could start to resemble the “Hunger Games”, where people have job security only until the next model release.
• Engineering is officially a cost center, not a profit center. We previously covered how most tech companies treat engineering as a “profit center” that generates revenue, and is therefore worth investing in. At such companies, engineers are treated well; not just financially, but in how leadership treats them as a key part of the business. At Meta, software engineering became a cost center pretty much overnight!
• Mission, what mission? People often join a company and stay motivated over time due to a mission they personally believe in. What if next year’s mission is to lay off as many people as possible, or to survive future culls? That doesn’t seem like a very inspiring mission.

What makes Meta worth its $1.4T valuation, anyway? Meta generates $228B annual revenue, and $68B profit (net income). The company is valued 6x its annual revenue and 20x its annual profit because investors bet its revenue and profits will continue to rise. But how does this happen? It’s via advertising, innovation, and launching new products.

How do you promote and enable the innovation which creates the products of tomorrow? “AI-pilled” folks might look to the technology as it gets more capable. But AI-native companies which can innovate will achieve results faster, putting Meta behind the likes of Anthropic, OpenAI, and SpaceX.

Or you develop a smaller workforce full of entrepreneurs and innovators, who will invent these new approaches and products. Basically, the best employees need to be motivated to stick around longer term.

That’s the problem with large layoffs; they prompt precisely the best employees to quit to join competitors, or launch their own businesses. This happened with Meta’s previous layoffs, as covered two weeks ago in ‘Meta’s self-inflicted resignation wave’. When leadership declares the ‘bottom’ 20-40% of the workforce is redundant, then very few people feel safe, and key members of Meta’s engineering organization will get offers from AI labs and Big Tech rivals. This is the “resignation wave” in action, all started by May’s layoffs and forced reassignments.

Knowingly or not, Meta creates an internal “mercenary” culture, where more of the people who stay are in it for the money and little else. Everyone knows they could well be laid off at any time the AI becomes good enough to replace them. People cannot control whether they end up on a list of positions to be cut, so it’s sensible to just make as much money as possible while awaiting the seemingly inevitable. That sounds like a pretty miserable place to work.

It could also lead to a situation where the workforce becomes more populated by those with no better options, who are not in demand from other companies.

Do social impacts matter to Meta?

A final element of the planned drastic job cuts, as revealed in the Reuters report, that I want to touch on is the potential wider, external impacts. Honestly, I’m surprised that none of Meta’s leadership seems to have considered this angle.

By executing massive layoffs for the sake of AI, Meta could have invited more regulation of the emerging AI sector. Meta is one of the largest tech employers in the US, and the CEOs of Anthropic and OpenAI are on record for predicting mass unemployment, and calling on governmental intervention should it happen. In fairness, other tech companies have also held major AI-related layoffs; Block let go 40% of its workforce, about 4,000 people in February.

But Meta is not just another tech company: it’s the world’s leading social media company, and just lost a major US lawsuit alleging that its platforms harm children and faces an $18B fine. As a result, it has committed to make its platforms less addictive. If the planned cuts had happened at Meta and all those staff became unemployed, how would it have dealt with complying with the court’s ruling to make its products safer for children? Could AI be relied on to deliver this with much less human input?

In light of the recent legal defeat, it wouldn’t be a good look for Zuckerberg’s company to blatantly put profits ahead of people by dismissing a load more workers. The combined effect of the two events would create terrible optics. In response, the government could decide that Anthropic’s and OpenAI’s CEOs were right about the threat to society of mass job losses and roll out things like:

1. Stricter employee protection, specifically around AI-related layoffs.
2. Higher taxation on profits of companies that “replace” staff with AI, and channel the revenue to deal with widespread whitecollar unemployment
3. Start taxing AI at source whenever tokens are sold, and use the surplus to counter the social ills of unemployment

Or the government could do nothing and leave it to the market to deal with unemployed whitecollar workers by creating enough new companies to employ highly-skilled software engineers, PMs, designers and other folks.

Overall, the canceled plan to cut thousands more jobs in this climate just adds to the feeling that there are no adults running Meta. Since Sheryl Sandberg quit in 2022 as Chief Operating Officer and Zuckerberg’s “right hand”, Meta has acted irrationally, irresponsibly, and unpredictably:

• 2022-2023: laying off 25% of staff
• 2024-2025: immediately rehired even more people so that 2025’s headcount returned to 2022 levels, raising the question of what the point of layoffs even was
• 2026: on track to overtake Google as #1 in advertising revenue this year
• May 2026: conducted sudden layoffs and forced reassignments of engineers, while aiming to replace as many devs with AI as possible for no obvious reasons like external pressure or competitive threats.

I’ve long had a generally positive view of Meta’s engineering culture, but with the company’s leadership seemingly worshiping AI and holding their colleagues in disdain, you have to wonder which software engineer would choose to work at Meta if other options are available. There are many tech companies that value their human software engineers, understand that great teams make for great companies, and that AI is a tool and not a replacement for human energy, motivation, and thoughtfulness. But Meta is clearly not among them.

Read the full issue of last week’s The Pulse, or check out this week’s The Pulse. This week’s issue covers:

1. New trend: tech companies moving to open models. Uber, Pinterest, Stripe, Coinbase, Ramp, and AT&T are making large savings on their AI bills by dropping proprietary models and using smart model routing.
2. Automatic software maintenance experiments by Linear and Anthropic. Both startups are experimenting with how far they can push AI agents to automatically fix bugs and remove tech debt. It’s working better than anyone might’ve expected in the recent past, but not producing code that can be merged without review.
3. Frontier AI lab wars: OpenAI pulls models from SpaceX / Cursor. With SpaceX now a frontier model and rival to OpenAI and Anthropic, OpenAI has pulled its GPT models from Cursor. This isn’t an option for Anthropic which is dependent on the SpaceX compute they rent to serve Claude.
4. HR tech startup’s one-dev-per-project approach. A full-remote HR startup with 70 engineers has a single engineer run each project, and says the approach works well. Will this approach be adopted elsewhere, especially at other full-remote startups?
5. Industry Pulse. Meta moved over to Slack for better agent interoperability, layoffs at Uber and PagerDuty, Anthropic upsets users by calling a rate limit decrease an “increase”, token usage explodes on OpenRouter, AI drives surging demand for Apple’s Mac Mini & Mac Studio, and more.

Send us up to 10,000 words on how you see things at your startup or tech company, or at a business you’re connected with. The best entries will be published in the Pragmatic Engineer and win prizes of $2,500, plus one grand prize of $10,000 for the best essay we read.

The Pragmatic Engineer reports many developments in tech in our deepdives, including how building software is changing at Anthropic, why Ramp built its own in-house coding agent, how Uber uses AI for development, how Codex is built and what it could mean for the future of software engineering, and much more. Almost every company we talk with currently says that processes which worked fine for years are suddenly pretty outdated.

This pace of change makes it hard to cover the full breadth and diversity of tech in one deepdive per week – especially right now, when engineers are building and using new and better tools in every part of the software development lifecycle. 

So, we’re launching a writing challenge to encourage software builders to share how things on the ground are changing. We’ll share these cutting-edge reports with readers in future editions of the Pragmatic Engineer.

So, tell us what’s new, different, better, and worse in your part of the tech industry since AI entered your workflow! 

What we’re looking for

• An essay written for software engineers: 3,000 – 10,000 words on one of these topics:
  • How software engineering is changing at your company, institution, or open source project
  • The engineering culture at your company, institution, or Open source project in 2026
  • How you build software in your company, institution, or open source project
  • Software engineers turning into AI engineers at your company, institution, or open source project. Basically, how the work is changing
• First-hand details: Winning essays will include the authors’ personal observations and opinions.
• Include details about the team and company: Including details about the team and company in the spotlight is important and enriches the essay by painting a more complete picture for readers; what engineering practices are changing, what’s still the same, what about tooling, and processes? Is there any “traditional wisdom” that no longer holds true – or is still true today? It’s not necessary for writers to work at a company/team being written about.
• Software engineers and “builders” only: We want to hear from folks who build software; meaning that you have built from scratch, pushed to prod, or been paged when your service (or someone else’s) caused an outage. Basically, if you do this currently, or did it in the past, then your essay is eligible for entry. You don’t have to be a builder right now if you’re still close to those who build software.
• Individual work. This competition is specifically for individuals, so articles written collectively by teams are not eligible. Of course, outside of this competition, The Pragmatic Engineer always welcomes articles from teams that want to share interesting developments!
• No AI writing allowed. Writing is thinking, and we are interested in your own thoughts and observations, not a sharp, one-sentence observation turned into three paragraphs of blob text by an LLM. Using AI as a research tool is allowed if you’re confident about the accuracy of its output, but all the words must be written by a person.
• Submitted essays must not be available to read elsewhere before 20 October. The essay has to be purpose-written for this competition and cannot have been published online or in print prior to 20 October 2026 in order to be eligible. After this date, a submitted essay can be published on any company blog, personal blog, or other medium. In fact, I recommend publishing it – one goal of this challenge is to increase general awareness of how the industry is changing, covered from different viewpoints.

Prizes

The competition has the following prizes:

• Grand prize: $10,000 and publication in The Pragmatic Engineer (following editing), and a Pragmatic Engineer surprise package. For winning entries, we reserve the right to make edits for legal, editorial, style, grammar, and punctuation reasons.
• Runner-up prize(s): $2,500 + sharing an excerpt in The Pragmatic Engineer + a The Pragmatic Engineer surprise package. Focus of the runner up category includes viewpoints from:
  • Bootstrapped (non-VC-funded) companies
  • More “traditional” companies that not digital-first, or which even predate digitalization
  • AI-native startups founded in 2023 or later which have been using AI tools since day one
  • Academia, government institutions, and open source projects

For quality deepdives: We plan to publish a roundup of essays in the future on topics which contain interesting learnings, and that clearly show great effort on the part of authors. These pieces will receive a The Pragmatic Engineer surprise package.

Timeline

• End of day, 4 October, PST: deadline for all submissions.
• 20 October: decision on the prizes.
• 3 November: expected publication of the Grand Prize winner

FAQ

Why is AI writing banned from this contest? I want to use AI to write my essay like I do for writing code! 

It’s a rule that you cannot include writing in your essay which was generated by AI. As everyone who reads this newsletter likely knows; there is no shortage of ways to detect AI-written text these days! The Pragmatic Newsletter is fully written by humans, and the same applies here. The reason for this hardline stance is that we believe in the value of human thought and experience, as told by people with first-hand knowledge. It’s also about the audience: The “audience” for AI-written code is usually a machine, whereas the writing in Pragmatic Engineer is for humans, by humans. AI produces a statistical average in its output which creates uniform, dull text that’s an inferior reading experience to human writing – at least today it is.

What about AI spellcheckers like Grammarly or similar ones?

These are fine to use, to eliminate those pestering typos. Just make sure they are your words!

Can the entry be anonymous?

No, because we only want to receive essays that are stories and observations that are yours to tell. And so we are only looking for entries that make the company/team/project/institution name clear, as well as your own name.

Of course, writing it with names mentioned could well mean getting permission to talk about your company/team/organization in public, and it also requires more skill to highlight not just the good changes, but the tricky, or not-so-good changes. This is part of the challenge.

Getting in front of The Pragmatic Engineer readers (and to enter this specific challenge) is not possible as anonymous.

Can I use images as well?

Of course! We love images and illustrations.

Can I publish an essay with the note that it's pending my company approving publishing it?

You can, but we treat it as unreviewable until we receive notice that it is approved for us to review. Basically, if the approval comes too late compared to the prize decisions to be announced on 20 Oct, the piece will not be eligible for prizes.

Can I publish my essay online after writing it?

In order to be eligible for consideration and prizes, an essay cannot be available to read anywhere online or in print before or after it is submitted to this contest. After 20 October 2026, no publication restrictions apply.

Can my essay be changed after I send it?

For spelling, punctuation, grammar, legal, and editorial reasons, the Pragmatic Engineer reserves the right to edit or amend all writing published on this platform.

OpenAI put an impressive-sounding case study about how they helped Asana save $5.9M with a single migration. From OpenAI (emphasis mine.)

“Asana cleared 5 years of engineering work in 2 weeks with Codex. Using OpenAI Codex, Asana replaced an outdated testing system in two weeks for about $12K.

For this project, Codex helped Asana’s engineers remove Enzyme, an outdated testing system that had made the company’s code harder to upgrade. Model and infrastructure costs came to about $12,000, compared with Asana’s roughly $6 million estimate for the previous staffing plan.

After 1.5 weeks of engineering effort spread across two calendar weeks, Enzyme was fully removed. Model and infrastructure costs totaled about $12K. For comparison: the previous plan was expected to take at least five years and estimated to cost roughly $6M. The experience changed which long-running software projects the company believes are practical to take on.”

For context, Asana migrated from Enzyme to React Testing Library, which indeed would not be a simple migration. However, their estimate of four engineers (each on circa $300K/year, according to OpenAI’s arithmetic), spending five years on the project, had me like:

But thinking about this for longer raised the question: what does a migration from Enzyme to React Testing Library even look like?

Enzyme to React Testing Library migration

Let’s take a simple test and see how it looks in various testing libraries.

For our test, we want to verify that a button increments a counter. Here’s our button in React:

Now, the test to verify this, in Enzyme:

And let’s rewrite this test in React Testing Library:

The two tests do the same, but they have completely different syntax! Let’s see just how different they are, with a side-by-side comparison:

The main reason for this difference is that the two frameworks use a fundamentally different approach to testing. Whereas Enzyme is oriented towards component testing (notice how the test operates on a component instance), the React Testing Library operates on the rendered Document Object Model (a data structure representing the HTML shipped to the client) so the test sees the whole rendered page, not just the component its written for. That’s why the testing approach will differ radically between the two frameworks, especially when testing complex user journeys. You can learn more here on the tradeoffs between the two approaches from the React Testing Library author.

It took Airbnb 6 weeks to migrate 3,500 tests with AI

Last year, Airbnb revealed how they migrated their Enzyme test suite of 3,500 component test files within six weeks with LLMs. The estimate of doing this by hand was 1.5 engineering years. Airbnb did the LLM-aided migration in a multi-phase process:

Airbnb’s team had to build loops to keep retrying migrations; once they did, 75% of files were migrated in just four hours, and the migrations were straightforward. They then built a more sophisticated refactor pipeline for the remaining 25% of tests; after building the pipeline, the new loop migrated most of the remaining tests (97%) in total, after running over 4 days. The remaining 3% was done with LLM input, with engineers finishing it in a week.

This was in March 2025, when the frontier coding model was Claude 3.7 Sonnet. Today, models are a lot more capable, such as the likes of GPT-5.6 Sol and Claude Fable 5.

AI makes impractical migrations doable

On the basis that it took Airbnb six weeks, I find it credible that it took Asana two weeks to migrate what is probably a similarly complex test infrastructure from Enzyme to RTL, a year later.

The time and $6M cost as quoted by OpenAI feels inflated. I assume the numbers were based on an estimate that a fulltime engineer could do a maximum of X tests migrated per day, where X was between 5 and 10. Then, calculate the number of engineering years this takes (perhaps 20 engineering years), and multiply by the cost of an engineer. You estimate a project like this when it’s an undesirable project you really don’t want to do as an engineer!

So, looking at it from this point of view: does it matter if the estimate was 1.5 years (Airbnb) or half a decade (Asana, hypothetically)? Or if the estimated cost was $1M or $5M? It would still be an impractical migration and a foolish endeavor: too long and distracting, at least, in the “traditional” way!

Pre-AI, years-long migrations were rare. In 2021, Sentry took 1.5 years to convert their frontend codebase from JavaScript to TypeScript. That was a migration of 1,100 files and 95,000 lines of code! Around 10 engineers worked on the migration, so if we assume a $300K-per-engineer cost, that’s a $2–4M cost for circa 95,000 lines of code.

Indeed, Asana’s reported $12,000 migration cost could actually cost even less if there was ruthless focus on cost optimization. What about using a model that’s 10x cheaper than OpenAI, like an open model running on inference providers? After all, why use the most expensive model, especially if a company already owns GPUs, running models, making inference practically free (except for power costs, that is.) For a first run, $12,000 would be affordable for a company paying $300K for engineers. But for subsequent runs, I’d wager it’s worth spending time optimizing the cost, and saving $10K per migration (or more!)

A few more details from inside Asana

I managed to catch up with Dan Ubilla at Asana, who leads the Developer Productivity group at the company. He helpfully clarified a few things about the Enzyme migration post on the Asana site:

• Asana started the Enzyme migration in 2024. The team had 4,000+ Enzyme files to migrate, and they took a first stab at the migration with LLMs, at the time. Beyond migrating existing tests, much of this phase focused on getting the codebase into a state where future tests could be written more idiomatically. This included improving mocking, data set up, and coverage instrumentation. They finished migrating about 25% of the files to RTL, choosing the tests that had the highest return on investment: meaning easiest to migrate, or most frequently updated ones.
• The remainder of the migration became low priority. Asana prioritized migrations as critical (“must do soon”), important (“important to do soon”), and opportunistic (“nice to have”). The company has a good number of critical and important migrations, and the remainder of the Enzyme migration sat as one of the many opportunistic.
• Five years was about when the migration was projected to finish. The effort was not about “a team working for five years, nonstop on the project” – not at all! It was about the timeframe that the opportunistic Enzyme migration would have been completed, given its priority, and done, realistically. Given this migration was going on for two years, the five-year estimate was a rational one.
• The team wanted to prove that LLMs drastically speed up migrations, and demonstrated it with an opportunistic , low-priority one. The Enzyme migration was not all that important to do quickly, and would have sat around for years. So it was the perfect candidate to prove that with LLMs, long migrations can be sped up!

And finally, one addition from my end:

The $6M cost was a back-of-the envelope estimation. I asked Dan how this estimate of the migration costing $6M came together. Dan confirmed that the estimation was done the same way as most of us do these estimations:

• Estimate how long it takes an engineer to manually migrate a single Enzyme file (including rewrite + validation). Be generous with this estimation
• Multiply it by the outstanding files to migrate (the 3,000+ ones)
• Add in the time to remove any traces of the framework, monitoring, static analysis tools
• Multiply by the hourly rate of a typical engineer
• … and the number came out to $6M

This estimation does not take into account that migrating even ten files by hand takes less than ten times more than it takes to migrate one file (you become more efficient), nor does it assume LLM usage. It’s a baseline to get a sense of how the work would have been done, pre-AI, if distributed across all Asan engineers to pick up, and migrate few files, whenever they have time. My take is that this number is probably an overestimation, but the point is less about the number, and more to convey that this is a lot of work!

Internally, Asana’s team and leadership are now convinced about the usefulness of LLMs for migrations, and they’ll be using them for other, long-running, otherwise soul-sucking migrations.

Expect long-avoided migrations to finally happen

A few months ago, Uber shared that they executed a massive JUnit migration in four months with two engineers and AI: moving 600,000 unit tests spanning 15 million lines of code (!!) by moving from the unsupported JUnit 4 to JUnit 5. During the migration, 1.25M lines of code were modified. This type of migration used to be impractical; with AI tools, it took eight engineering months of effort, plus AI costs.

And there’s the Bun migration (530,000 lines of code from Zig to Rust in two weeks for a $165K API cost) as another example of drastically faster migrations with AI.

The best part about rapid, AI-assisted migrations is not needing to worry about supporting “old” libraries. One of the main reasons library migrations have been such a pain was the need to keep supporting the old library or technology during the migration. Shortening this window could well be worth the additional cost, at least until we figure out how to drastically reduce the time and cost of these migrations, as well.

The shared characteristic of all of the above migrations is that engineers needed to plan for it, design verification loops, and be involved throughout. I always dreaded migrations, so I see it as good news that we have a new tool to use for “grunt work” like this.

Read the full issue of last week’s The Pulse, or check out this week’s The Pulse. This week’s issue covers:

1. Did Meta really decide to reduce team sizes by 60% because of AI? An in-depth report by Reuters details how Meta’s leadership decided to slash team sizes by 60%, hatching plans in January to execute the social media giant’s largest-ever layoffs. But Mark Zuckerberg changed his mind at the last second, and now the company is stuck with all-time low morale, a wave of resignations, and its prized culture turning mercenary. Analysis.
2. More thoughts on Ramp’s in-house AI infra. Building AI tools in-house is akin to an “internal bootcamp” for AI engineering, which probably justifies the exercise at most tech companies.
3. Industry Pulse. GitHub’s load increase is speeding up, Stripe acquires OpenRouter, Ramp launches Ramp Router in public, a career “double boomerang”, App Store revenue drops for the first time ever at Apple – and what is a bug?

I host The Pragmatic Engineer Podcast. Thanks to so many of you tuning in, the podcast is widely listened to – it's one of the top-ranked software engineering podcasts, and episodes typically reach 500K+ people. If you're listening to the podcast, or reading the newsletter: thank you!

The podcast only has guests who, as as a software engineer, I'm excited to talk to and learn from. These folks typically fall into one of these categories:

• Built/builds epic pieces of technology. Examples include Chris Lattner (built LLVM, Swift, Mojo), Anders Heljsberg (created C#, TypeScript, TurboPascal), Andrey Breslav (created Kotlin), Greg KH (longtime Linux maintainer), Kat Cosgrove (longtime Kubernetes release lead), Mitchell Hashimoto (Terraform, Ghostty).
• Works at a company I find very interesting and relevant. Examples include Boris Cherny at Anthropic (created Claude Code), Elizabeth Stone (CTO at Netflix: a company whose engineering culture I've been fascinated with), or Mai-Lan Tomsen Bukovec (leads S3 at AWS)
• Is a deep domain expert - typically with a decade+ of experience. For example, Nicole Forsgren (developer productivity, DORA, SPACE), Laura Tacho (DX), Alice Ryhl (Rust), Robert Erez (CI/CD)
• Deep thinkers with a decade+ of experience. For example, Kelsey Hightower, Grady Booch, or Charity Majors.

As the podcast has become more popular, I am getting overloaded with pitches from PR people, Comms people, and Marketing people, though. The typical pitch is usually AI-written, and goes something like this:

From <CommsPerson@Startup.com>

Hi Gergely,

I have a potential guest and topic that feels unusually aligned with The Pragmatic Engineer’s audience.

X is the co-founder and CEO of Startup, which now serves ## million developers and ## thousand companies. The platform processes {large number of business metrics} every day, giving CEO a large-scale view into how engineering ability and team expectations are changing as AI-generated code becomes standard.

The useful conversation would not be a Startup product story. It would examine questions engineering leaders are actively dealing with:

- AI-generated topic #1 assumed to be a fit for the podcast
- AI-generated topic #2
- AI-generated topic #3

CEO has built Startup from its earliest days in Location all the way to global enterprise scale. He/she can bring both operating experience and concrete data instead of generic AI predictions.

Would this be worth exploring for the podcast?

Best,

MarketingPerson
Startup

I get 10-20 of these pitches, per week, in my inbox. Until now, I've been ignoring them, but then MarketingPerson sends two more follow-ups. I now have an AI agent monitoring my inbox, and I decided to at least send an AI reply to explain why I'm not sending a response to these pitches.

If you look at how my podcast works, it should be obvious to why such guest requests are not a good fit - and why having founders wanting to talk about their own startup would be a bore of a topic, and, frankly, a waste of time for 99% of listeners – possibly more.

But to spell it out to the marketing folks:

A) Send out AI emails: expect nothing back. Don't expect a response to an AI-written email, or a templated email. I get it, you think it's a numbers game: send a tweaked email out to 100 podcasts, and hope that at least one replies. In reality, by playing the same game as everyone else does, you are assisting to the noise, and end up drowning yourself in it as well.

And this goes not only to you, as a marketing person, but also to a founder/CEO who thinks they can put in zero effort in A Thing and get great results: you're kidding yourself. To those founders who have set themselves the goal of being invited onto a specific podcast: I'd challenge you, ask a former guest, how they got invited? I can already tell you that it sure wasn't an AI-generated email sent out by a marketing person they hired!

B) My podcast doesn't take self-pitches. The only type of pitch I listen to is a software engineer telling me "wow it could be great to have this and this person on the podcast, because of this thing they built/thing they did." In these cases, I check out that thing they built or thing they did. When a lot of people tell me the same thing, I might listen more.

But a CEO recommending themselves as a podcast guest? Or their marketing or PR team recommending the same? Ignore.

But to leave these marketing folks with some advice:

If your CEO/founder has so much to say about a topic: say it and write it! Ironically, every time I look up what the founder has written about the topic they (or their marketing team) are pitching, there's nothing! Nada.

If the pitch is sincere, then write down your thoughts! Post it on your company blog or personal blog.

But if you're just looking for "distribution", "free publicity", mass emailing podcasts is not how to go about it. Everyone is doing it, and it's not working for anyone.

The only founders you see on podcasts who are worth listening to? They built some epic stuff, are often hands-on, and they did not mass-email dozens or hundreds of podcasts with an AI-generated, generic agenda to talk about.

Two months ago, I covered how Meta seemingly deliberately started destroying its once-standout engineering organization. The company did 10% layoffs at a time when revenue and profits hit an all-time high, and reassigned about 20-30% of software engineers to data labeling with basically no notice.

The result was that a good chunk of software engineers at Meta – even those not reassigned – were starting to interview elsewhere:

I said – and still maintain – that the layoffs were an unforced, self-inflicted error on Meta’s part. Coupled with forced reassignment, they struck disaster. And I’ve now gathered new details that confirm that Meta is bleeding top engineering and product management talent:

Some layoffs reversed, in the 11th hour

In the UK, mass layoffs require a notification to those potentially affected, before the cuts can happen. A few weeks after this notification, a good chunk of folks were “un-notified,” I confirmed. But those on notice had already started to look for jobs, obviously.

Retainer equity grants offered to IC6+ engineers resigning

Meta started to offer large retainer equity grants to those resigning and leaving for Google, Anthropic, and OpenAI: a practice not done before. Talking with long-time Meta engineers, Meta simply didn’t make counteroffers or negotiate when an engineer handed in their resignation. But this practice has been abandoned. Here’s a story of a senior, long-tenured engineer I confirmed to have happened:

• This dev was force-reassigned to one of the AI data labeling teams
• They thought “oh no, this is not what I want to do” and started to interview
• Got a Google offer, but compensation was below their current one. Google basically lowballed them.
• Decided to leave anyway. Told their new manager they were resigning.
• New manager asked for some time, then presented a large, one-off, retainer equity grant, vesting over 3 years
• The engineer went back to Google, telling the company, unfortunately, they are a key engineer and showed them the retainer amount Meta is paying for them to stay
• Google upped their offer, out-bidding Meta’s retainer offer
• The engineer who was desperate to leave – even for lower compensation! – was thrilled, and happily left for Google.

Retainer equity seems to be offered for most IC6 engineers who resigned in the last few weeks. I talked with seven such people, who were all IC6 (staff-level engineer) and IC7 (principal-level engineers), who shared more details. They are not aware of IC4 (mid-level engineer) or IC5 (senior-level engineers) getting such offers.

Retainer equity offered is $400K to $1M+, and vests over 3 years, for the folks who got these offers. The $1M+ offers were all for engineers with Anthropic or OpenAI offers, and I confirmed a $400K and a $600K grant for engineers with an offer for other, smaller AI startups.

A current Meta engineer who is interviewing asked me if these folks needed to present their offer letter to get a counteroffer. I asked two of these folks with counteroffers, and neither had to do so, but they both indicated they were handing in their resignation. Upon receiving this notification, their director, together with HR, offered a discretionary retainer equity, should they stay.

Anthropic and OpenAI on a hiring spree from Meta

Anthropic and OpenAI seem to be on a hiring spree, signing Meta engineers that Meta wants to retain now that it is too late! I have confirmed that three engineers who received an offer from Anthropic were also offered large, $1M+ equity grants (vesting over 4 years) as counter-offers to stay. Two out of the three rejected it and joined Anthropic, and the third one initially accepted the offer and then still left for Anthropic a month later, forfeiting this grant.

OpenAI is having similar success, and the two AI labs seem to be the main destination for now ex-Meta engineers to bounce to. It makes sense: these companies can match Meta’s total compensation, and although neither OpenAI nor Anthropic is publicly traded, both companies organize secondary equity sales, and their respective IPOs are likely to happen in 3-12 months’ time.

AI startups also successful in hiring infra experts from Meta

I had an in-depth discussion with another long-tenured AI infra engineer at Meta, who was considering whether to stay, or to go. This person wrote up their situation, and shared it with me, writing:

“With the current situation at Meta (layoffs, forced drafting to do AI work, general sense of disruption at work, low moarale, and almost zero productivity across teams, plus multiple reorgs) I started to look around, on the market, a few weeks before the 20 May layoffs. I figured I have a 50% chance of being let go.

I did not get laid off, but I got offers from startups, and one from a high-growth AI startup I like, and also an offer from Google.

Now, the pros to staying a Meta:Context, relationshipsScale that few others haveBig Tech perks, relatively “chill” WLB in terms of oncallHigh TC

The cons:Terrible morale, hard to “move” work through mostly unmotivated teams all around meRe-orgs continue, I have very low confidence in middle management (Directors, VPs) to navigate this churnFurther layoffs are likely: it’s clear that there’s more bloat, surely Zuck will do another round in 2027. And no one is safe during a layoffA ‘doom loop’ for anyone who stays: low morale → unmoitivated bith highly compensated engineers → a bloated organization that moves slow”

After a new reorg, this engineer got a supportive manager, who made it clear they would help them thrive inside of Meta. So the engineer rejected both the AI startup’s offer and that of Google, deciding to stay… but only for a month!

The AI startup’s founder spent more time with this engineer, increased the equity in the package significantly, and convinced this engineer that at the startup they matter as a person, while at Meta they would be doing soulless work, worrying about the next layoff, probably early 2027.

So this engineer also handed in their resignation. And it all started with the layoffs: the engineer assumed there was a 50% chance of being let go and wanted more career stability!

Those deciding to not resign: stay for the money?

There are engineers staying – at least until the end of the year, to wait for the stock refershers — which we’ll talk about in just a moment.

Another engineer I talked to decided to quit Meta with morale so low, and start his own thing. Management convinced him to stay until the end of the year, hinting at large equity refreshers being handed out around January, which could be in the $1M+ range for this specific engineer.

The 2022 stock price causing a TC decrease for many?

One reason there’s speculation about large equity refreshers being handed out at the end of the year is that Meta’s stock price was very low in 2022 and 2023, when equity refreshers and new hire grants were handed out. In both March 2022 and March 2023, the stock price was around $200 - which is about a third of this year’s stock price (which has been fluctuating between $520- 680, currently sitting at $540.) By March 2024, the stock price rose to $500, and then to $580 in March 2025.

Because of this, those who joined Meta in 2022 have seen their equity grants nearly triple, and the 2023 equity is worth nearly 3x as well. But for these lucky folks, total compensation is set to drop by the end of this year, and their equity refresher would need to be higher than in past years to avoid a compensation drop.

Inside of Meta, engineers who I talked to are split between expecting further attrition (those leaving whose total compensation drops steeply) and those who think that there will be more attrition unless there are higher-than-usual equity refreshers.

A “mercenary” culture at Meta?

I wonder if Meta made a massive mistake by treating engineers as “commodities” and turning their culture into a “mercenary” one. Between March and June, Meta treated engineers as replaceable commodities that could be thrown out or moved between teams, while stripping them of any autonomy. The reassignments to AI labeling were not explained, nor were managers or individuals asked about preferences: from above, someone said that Alice and Bob, starting on Monday, are no longer with the team, but are training up Meta AI. Never mind that these were the two most experienced engineers on the team, or that Bob was the team’s infra expert, and Alice the “fixer” engineer on the team.

And all this damage was done, for what? It was to allow Meta to restart its AI coding model development efforts, and release Meta Muse Spark: an AI model that is currently the 7th most capable AI model as per Artificial Intelligence Analysis, tied with Grok 4.5. Credit where it’s due: with this model, Meta is now well ahead of Google’s Gemini in capability.

With the damage done, there is little motivation for anyone to stay at Meta – unless they are on a visa, or if it’s about the money. You can have an OK engineering culture with a team who is mostly interested in making more money than what they would elsewhere: but this is more of a mercenary culture, and companies run by mercenaries are more easily out-executed by teams where people believe in the mission of the company.

If you work at a company that would love to hire from Meta: now is (still) your opening! So go for it.

And if you’re at Meta: you are so in-demand, outside of the company, at places where engineering is still treated as a profit center. As Ryan Nystrom, currently building AI at Notion, put it:

“Meta friends: the industry is exhilarating right now. Get out. Go build something. The handcuffs are an illusion.

I’m having the time of my life at Notion. Come, and have fun again.”

Read the full issue of last week’s The Pulse, or check out this week’s The Pulse. This week’s issue covers:

1. More on the “great engineering leader career break.” The industry is changing fast, and the VPE and CTO roles also need to adapt. And don’t forget that these are the roles from which you can drive change that reorganizes engineering in ways that work better.
2. We need to talk about migrations with AI. Asana needed to migrate off testing framework Enzyme, but it meant doing a massive rewrite of test cases. With AI, the project was completed in two weeks: without AI, this work would surely have been kicked down the road. Airbnb and Uber share similar stories, and AI seems like a superb fit for framework migrations.
3. Are AI startups making the Gartner Magic Quadrant irrelevant? Gartner ranked AWS, Microsoft and IBM above Anthropic, Cursor and OpenAI in their “AI code modernization tools” ranking. This is most likely because the first three pay large sums of money to Gartner, but AI labs and vendors refuse to pay this “Gartner tax.”
4. Industry Pulse. Another hours-long GitHub outage, GitHub alternatives are here and fighting for market share, Slack launches Slack Code, text generated by Claude to be watermarked, and Uber open sources SubmitQueue.

Read the full The Pulse.

Selling to Bending Spoons is a company admitting defeat, and its inability or unwillingness to turn its business around, and wanting to get the highest possible cash for the business. Because this is what Bending Spoons is excellent at: they pay the highest cash value for a struggling business with a well-known brand, then take over operations, and operate the product with a fraction of the staff. They often let go most or all of the original team as they move over product operations to their in-house engineering team based in Italy and Europe.

Evernote: what happens when a new team takes over a legacy application

And having talked with Bending Spoons' engineering team on the podcast: they have done impressive engineering work after a takeover, in the past! For example, upon acquiring Evernote, the Bending Spoons engineering team discovered that the note-taking service was running as a Java 11 monolith (!!), with user data sharded across 750 manually provisioned virtual machines (!!!) on top of Google Cloud - in 2023! At a time when running cloud-native setups (managed databases, microservices) was common knowledge for years.

Evernote's existing setup was weirdly inefficient and operationally very heavy, with manual interventions needed to keep the service running. Needless to say, performance was poor because some VMs were regularly overloaded. Also, oncall was brutal!

The Bending Spoons engineering team rationalized the architecture:

• Migrated user data sharded from the 750 manually provisioned VMs to a managed database
• Split up the Java 11 monolith to microservices
• Did all of the above without disrupting user experience
• Improved performance of the backend by a wide margin
• Reduced oncall load after finishing the migration to a cloud-native setup vs the previous manual provisioning setup
• Did all the above in about 6 months.

It's a fair question: would long would have the original Evernote engineering team have taken to do the same changes that made the service more reliable, more performant, and cheaper to operate? I would guess it would have taken them many years: in fact, if they did not make this change until 2023, who knows if they would have ever made these pretty rational changes? And so the "shock therapy" of Bending Spoons starting with a blank page, and a new team taking over operating the full product, with a laser focus on efficiency: well, this approach can be pretty efficient, as the Evernote example shows.

You can listen to the full podcast episode I did with the Bending Spoons team: Twisting the rules of building software: Bending Spoons.

Price increases and the existing team let go: the two most typical complaints

Bending Spoons taking over an existing product has two major criticisms:

1. Price increases. Evernote was the biggest example of price hikes: after Bending Spoons took over operating the product - and improving its performance - price hikes followed. Being Spoons kept investing in Evernote, adding new features (including AI ones), but customers paying $37/year for the Pro plan pre-2023 were charged $250/year by 2026. My take is that this is what happens when a product starts working a business maximizing profits: lots of customers will leave for competition, while others will pay more, valuing a more reliable service that gets more investment than before. Bending Spoons keeps improving Evernote since the acquisition, alongside the price increases. Clearly, the company is optimizing for maximizing revenue, not maximizing the number of customers, though.
2. Layoffs. Bending Spoons let go most/all of the Evernote team in the US, briging operations in-house. This is part of the "usual" playbook of Bending Spoons: they buy products to operate them as efficiently as possible. The re-architecting example shows benefits of starting from scratch, and not needing to deal with internal resistance for changes that result in more efficient operations. Knowing that with a Bending Spoons acquisition, letting go of all the existing team is on the table is something that comes with selling to this company.

With this, let me share my analysis of a past Bending Spoons acquisition: when they bought SteamYard from Hopin.

Below is the now un-paywalled excerpt from The Pulse #89: The end of Hopin, from April 2024, sent to paid The Pragmatic Engineer subscribers. If you'd like to get analysis like this in your inbox, weekly, subscribe to The Pragmatic Engineer.

The End of Hopin

It’s been a real rollercoaster ride for the virtual events provider:

• 2019: founded with a mission to provide a solution for hosting virtual events.
• 2020-2021: raised a total of $1B in funding during a seed round in Feb 2020, Series A in June, Series B in November, and then a Series C in March-June 2021. The company was valued at $7.75B and acquired several startups, the biggest of which was video streaming platform, StreamYard, for $250M.
• 2022: layoffs in February, when Hopin was one of the early scaleups to do large cuts (12%), followed by more in July (29%), and November (17%)
• 2023: Hopin sold its core event tech business to RingCentral for $50M. We analyzed this at the time.
• 2024: Last month, Hopin’s UK entity entered liquidation. Insiders told me it was merely a restructure, with Hopin UK employees joining StreamYard. Basically, Hopin became the business it had purchased back in 2021.

This week, Italian mobile app developer Bending Spoons acquired the remains of Hopin, which is basically the StreamYard product. All Hopin staff will soon be laid off.

The Bending Spoons acquisitions strategy

Bending Spoons has previously acquired apps such as the notes app Evernote in 2022, events app Meetup in 2024, and video-recording app FiLMiC in 2022. Their approach to these acquisitions was the same each time:

1. Take over operating the product
2. Fire most staff immediately
3. Have some remaining staff hand over services, then fire them as well
4. Operate the app with a much smaller team and raise prices.
5. Profit!

I talked with current Hopin employees for details on what will happen next, and if this model will be followed again. Unfortunately, it will.

All existing Hopin staff will be let go, eventually. This affects around 80 staff working on StreamYard, and another 70 on other Hopin products, Streamable (video sharing) and Superwave (community platform.) I’m told severance packages are generous enough, at around 3-4 months’ salary.

As with other Bending Spoon acquisitions, a subset of the team was requested by Bending Spoons to help with the transition (and then be let go afterwards.) Understandably, morale is very low for this reason, and the certainty that everyone will lose their jobs.

How much did StreamYard sell for?

From talking with current employees, I gather that circa 95% of Hopin’s revenue comes from StreamYard, and not more than 5% from Streamable and Superwave. So the only valuable asset that this acquisition priced in is StreamYard.

In 2021, Hopin paid $250M for it. Back then, the video streaming service generated about $40M in annual revenue. This has risen to about $70M per year and keeps growing in an increasingly crowded market. StreamYard was at around break even and can be easily made profitable, I’m told.

A good question is whether Bending Spoons paid $250M or more for this asset. In 2023, RingCentral paid $50M for the “core” virtual events offering which was making $20M in annual recurring revenue (ARR) at the time, I’ve confirmed with insiders. However, ARR was falling steeply, and was forecast to hit $10-15M within a year. So RingCentral paid a 2.5x multiple for an asset losing revenue.

StreamYard brings in $70M per year, and this is increasing. I’d assume the purchase price would be at least the same 2.5x multiplier, if not more. So there’s a fair chance this sale’s value is close to $200M.

Why did Hopin sell to a buyer which wants to lay off everyone?

I have exclusively learned that StreamYard’s founders actually offered to Hopin’s board of directors to buy the company back, and operate independently, as before. This would’ve been a better outcome for employees, most of whom would surely have kept their jobs. Some of StreamYard’s staff knew of this plan and naturally supported it. The Bending Spoons sale has taken everyone by surprise.

But why would Hopin choose a buyer that is guaranteed to sack existing staff? Well, the board might have had no real choice, due to Hopin having raised too much money.

Hopin raised $1B in funding, during which it almost certainly offered board seats to investors including a16z, General Catalyst, Coatue, Northzone, Salesforce Ventures, Tiger Global, Accel, and others. It’s safe to assume investors control the board, and as Hopin will never live up to its $7.75B valuation, the board-level rationale has evidently been to maximize the amount of money clawed back.

Of that $1B, here’s what’s left:

• $50M from selling Hopin’s core business
• Whatever StreamYard sells for
• Residual cash left over from the fundraising

The board serving investors’ interests had to shop around for the highest bidder, and minimize losses. I have to assume the decision on whether StreamYard’s founders could buy back their own company came down to whether or not someone else was offering more money for it. Unfortunately for Hopin’s staff (and fortunately for investors,) Bending Spoons probably offered more.

The risk of raising too much venture capital

Hopin is a reminder that raising too much venture capital can have unexpected, seemingly irrational, outcomes. Firing all staff from a company making $70M/year while being break-even or profitable sounds irrational from the company’s perspective. But it is rational for investors and a buyer:

• Hopin’s investors realized the company is a “failed bet.” They want to cash out their losses: get back whatever money they can – which is still in the hundreds of millions of dollars! – and use this capital to make new bets.
• Hopin’s buyer – Bending Spoons – wants to maximize their return. They pay $X for the company, and the goal is to generate $Y over the next several years in profit from it, where $Y > $X. So, the acquisition pays for itself. Bending Spoons has a working model that involves firing all existing staff, and operating the product more efficiently.

The biggest losers in this story are:

• Some investors. Collectively, investors poured $1B into Hopin. In October 2023, Hopin returned $581M of capital to investors (so 58% of all amount raised). It is unclear if the StreamYard purchase that could be another $200-300M, will be returned to them. It is safe to assume that investors will lose about 20-42% of the amount they invested, depending on how much proceedings of the StreamYard purchase they get paid. This is much better than in the case of one-click checkout startup Fast going bankrupt a year after raising $100M in funding, where investors most likely lost all their investment! In the case of Hopin: it’s still a loss, but it’s far from a 100% loss like with Fast.
• Employees who expected a better outcome. Shares issued to staff by Hopin are now officially worthless. At the same time, Hopin did pay above-the-market base salaries, and offered generous severance during redundancies. Unfortunately, a reality of fast-growing startups is that they can grow fast, but also go down fast.

Winners of this sale are:

• The original founders of StreamYard who sold the company for $250M cash. Even though these founders are also departing, they netted a healthy return in 2021.
• Bending Spoons, which has acquired a market-leading streaming product generating $70M per year and growing. StreamYard would normally not be available to buy, but the need of the Hopin board to “cash in” the company’s remaining assets made this sale possible.

I assume the biggest winner of the Hopin story stands to be Hopin’s founder and former CEO, Johnny Boufarhat. He sold more than £100M ($127M) of his shares in 2021 as secondaries. He probably netted more money than Hopin – excluding StreamYard – generated in its lifetime! Selling a good chunk of his shares in 2021, at the peak of hype for virtual events is a good reminder that when everyone is buying, it can be a profitable strategy to sell!

What happened to other fast-growing startups in Europe?

In 2020, Hopin was known as the fastest-ever growing startup in Europe by valuation. This visualization by Sifted went viral, and was widely shared by Hopin staff on social media:

Hopin’s current value is now zero, having sold its valuable assets. But how have other, formerly fastest-growing startups in Europe performed? I visualized this:

Excluding Hopin, the car sale website Cazoo did worst; it’s currently close to bankruptcy, valued at about $60M. The companies that managed to grow above than their 2020 valuations are:

• Food delivery service Wolt was acquired by DoorDash for €7B ($8.1B) in 2022
• Ride-hailing app Bolt was last valued at $8.5B, and is supposedly preparing for an IPO in 2025
• Neobank, Revolut, was valued at $33B, even though some investors cut their valuation of the company to around $20B in the summer of 2023
• Spotify’s current market cap is nearly $60B, and the company is trading close to its 2021 all-time-high

This chart confirms what we already know: 2020-2022 was a time when startup and scaleup valuations hit all-time highs, fueled by zero interest rates, and widespread changes in consumer spending caused by the Covid-19 pandemic. We have covered what the end of rock bottom rates could mean for the tech industry.

You can no longer watch The Pragmatic Engineer Podcast as video in the Spotify app (only as audio) because I have quit publishing video on that streaming platform. This comes after I decided that reliability takes a back seat within that team – and across much of Spotify. Unlike on other platforms such as YouTube, Apple Podcasts, and Substack, I’ve recently encountered a series of reliability issues around Spotify being unable to process video episodes. Even though I enjoyed a direct link with the Podcasts team there, things haven’t improved.

So from now, I will no longer be publishing video episodes on Spotify. You can find videos of my in-depth chats with guests only on YouTube. Apologies for any inconvenience this change causes! Audio episodes of the podcast can still be found on Spotify via the RSS podcast feed hosted on Substack.

Honestly, the decision to quit the streaming giant wasn’t hard, and I reckon there’s a point here about the risk of deprioritizing reliable operations at major companies in order to push on things like AI adoption, as Spotify seems to be doing.

Some context: for the first two years of The Pragmatic Engineer Podcast, it was published on three podcast platforms:

1. Substack’s podcast platform (audio): this is where the “master” RSS feed is served to the likes of Apple Podcasts, the web, Overcast, Pocket Casts, etc
2. YouTube (video): video episodes uploaded individually
3. Spotify (video + audio): every video episode was uploaded individually and then served as video or audio episodes from the platform.

As someone hosting a podcast, there are good reasons to bother doing three separate uploads:

• Most podcast platforms don’t support video. There will always be a need for a platform that serves the master RSS feed for audio versions while the video ones are elsewhere.
• YouTube doesn’t integrate with anything. YouTube is the leader in video podcast distribution, and uploading there directly makes sense.
• I had a direct line to the Spotify team, which was a big plus. Starting out the podcast, I had the unusual privilege of contact with the podcasts team, thanks to the newsletter gaining a decently-size audience. I was persuaded to take the plunge with them.

For eighteen months, nothing major went wrong. The admin portal for podcast publishers (called ‘Spotify Creators’) was pretty wonky; it gave intermittent errors, and was unable to remember me when I signed in, so, each Wednesday, I’d have to sign in with a code sent to my email to publish an episode.

But overall, things worked, until it all went suddenly downhill…

Unable to publish Spotify podcast episodes 3 out of 5 weeks

From late May, I did not include links to Spotify on new episode announcements because their podcasts product or platform seemingly had outages every time one published on Wednesdays at around 9am PST / 12pm EST / 6pm EU time.

Outage #1 (20 May): podcast publishing broke, my episode would not process on Spotify for 2+ hours. When uploading a video file to Spotify, there’s a processing pipeline that runs to create chunks of the podcast in different video and audio formats. This pipeline appeared to stop running, meaning new episodes were not published.

It was not just the publishing that broke: the Creator portal looked absurd, with NaN% values everywhere, during the outage:

I emailed the Spotify team to alert them about the outage and also complained online. I got a response, confirming the outage and pledging to do better:

“The issue was in one of our podcast publishing metadata pipelines. A small subset of episodes completed normal media processing but then missed a downstream publish update because a newly introduced validation signal was not correctly wired into the logic that wakes up the publishing path. In simpler terms: the episode could become eligible to publish, but the final propagation step was not reliably triggered for that class of episodes.

We identified the root cause, deployed a fix, and reprocessed the affected episodes with all-clear called early this morning. We’re also tightening the system so that fields used for publishing eligibility cannot be added without also triggering the relevant downstream updates.

Separately, we’re reviewing how partial creator-impacting publishing delays are surfaced, because even when this is not a broad platform outage, it is still a bad experience for publishers like yourself.

Apologies again that you hit this. It was a real bug, not a wide outage, but it hit some of our most relevant creators.”

Outage #2 (17 June): Spotify down. Four weeks later, when attempting to publish a video episode, all of Spotify went down for many users, including myself.

Spotify does not maintain a status page, so it’s impossible to tell how widespread the outage was. I didn’t include a Spotify link in that week’s announcement either.

Outage #3 (24 June): podcast publishing broke – again. Outage #3 in five weeks; deja vu. This time, it was episode publishing not working, yet again. After waiting two hours for the episode to publish on Spotify, I yet again sent out the announcement with no Spotify link.

I also emailed the Spotify Podcasts team, who confirmed the outage. I said I was considering stopping publishing video episodes, and to switch to audio-only publishing (which means pointing Spotify to my master RSS feed.) I said that an apology was appreciated but it wasn’t enough to make it worth publishing video episodes there.

I also asked for the incident review because I had the feeling that reliability was not all that important on this podcast product. For the first outage I got a vague description of what happened, and promises of improvements that were never done – e.g. during this second outage, there was no improved communications to creators, which I was told would happen, after outage #1.

Internally, Spotify’s team surely conducted an incident review as per usual, so I figured I’d hear back in about two weeks’ time, and assumed a reply would be forthcoming because I’d made clear I was ready to leave Spotify Podcasts if reliability didn’t improve.

No incident review three weeks later, so I quit Spotify

The incident review had never arrived as promised by three weeks later, even though there had been time for it to be completed. It was yet another sign of a platform that has become unreliable. Also, the creator portal occasionally threw up this error:

I checked my Spotify stats: stream plays had been trending downwards unsurprisingly, given the ongoing outages, while the other podcast platforms didn’t show the decline. It made me decide “enough is enough” and to move off Spotify.

Staying on their platform depended on seeing an incident review, but they didn’t prioritize transparency, still had no status page, and nobody had built a feature for episode-processing status like YouTube has had for years. So, I pulled the plug and left:

After I made the switch away from Spotify, the platform’s creators portal became buggier than ever, as in these examples:

Comments disappeared:

… even though other parts of the UI showed dozens of comments:

Episode links directed to 404 pages:

A day or two later, these issues disappeared: I assume no one had tested the flow of moving away from Spotify Podcasts to an RSS feed, and it’s why the experience was so poor.

Incident review finally published, but with a wrong timeline

A few days after offboarding from Spotify, their team published the incident report for outage #3. Reading through it, something did not add up in the timeline:

My email account confirmed that I mailed the Spotify team at around 17:30 about the outage. So, after weeks of creating this report, why did the incident report downplay the fact that customers alerted the team before their own automated alerts fired?I complained to the Podcasts team, and to their credit, the incident report was updated:

I didn’t like how high-level the report is, and how vague the promised improvements were. Specifically, this one:

“During this incident, many creators learned something was wrong from their audiences before they heard anything from us. We are improving our processes and technical capabilities so creators get notified as soon as possible when things aren’t working.”

Overall, I don’t regret the choice to leave, particularly when the focus of Spotify’s leadership is on AI, not reliability.

Does Spotify have “AI psychosis?”

Previously, I used the term “AI psychosis” differently from the usual way of describing when someone starts believing everything an AI model tells them, however outlandish. I applied it to Meta’s rush to develop its own AI model at the cost of the reliability of its profitable business activities. This was based on Instagram’s most embarrassing-ever account takeover incident, which occurred when the team responsible for Instagram’s Trust & Safety was slashed. Soon after, AI-generated, AI-reviewed code caused the hacking of a former US president’s account.

At Spotify, it should have gone the other way. In March, I had the opportunity to meet its Head of Technology & Platforms, Tyson Singer, who said the company puts reliability far ahead of AI adoption, and doesn’t adopt AI for its own sake. So, it was somewhat surprising to read the summary below of a podcast Spotify did with Anthropic:

“Spotify now ships 4,500 production deploys a day, and 73% of PRs are now AI-assisted.

Niklas Gustavsson (VP of Engineering at Spotify) keeps 5 to 10 Claude sessions running in tmux, one per git worktree, agents working in the background. All of it inside a 20M+ line monorepo. He expected agents to struggle at that size, but it’s worked well.

Spotify’s migration codemods grew into thousands of lines of edge cases. Code has too much API surface for static rewrites. Early LLMs barely did better. Adding a judge took PR success from ~25% to 80%.

All of this leans on verification, the single most important thing when agents are used and the place most companies underinvest

Spotify rebuilt their test automation around it so engineers can confidently guide and supervise agents, rather than manually execute repetitive tasks.”

It seems to me that all the talk is about usage of AI, and none about reliability, all while Spotify’s platform becomes less reliable than ever, at the same time as the streamer is going all-in on AI; with AI judges and devs running 5-10 parallel Claude sessions.

All things considered, it’s worth asking if Spotify has the corporate variant of “AI psychosis”, whereby the reliability of a successful operation gets torched in the chase for the next big thing by executives. I don’t even think Spotify is all that different from Meta and other companies in this!

Things look bad, based on the quality and reliability degradation of products. Annoyingly, in many cases, customers don’t really have the choice of going elsewhere. My podcast is an exception, as video podcasts on Spotify never truly took off, so quitting the platform wasn’t a big deal. Even so, I’m particularly disappointed that Spotify has prioritized AI usage over reliability. I know some executives there pushed against this, but I feel safe in assuming that they lost that battle.

Value of staying reliable & “sucking less”

Max Kanat-Alexander, distinguished engineer at Capital One, has written about how a software project can become wildly successful just by “sucking less” in his reflections upon the success of the Bugzilla project, (2004-2009):

“All you have to do to succeed in software is to consistently suck less with every release.

Nobody would say that Bugzilla 2.18 was awesome, but everybody would say that it sucked less than Bugzilla 2.16 did. Bugzilla 2.20 wasn’t perfect, but without a doubt, it sucked less than Bugzilla 2.18. And then Bugzilla 3.0 fixed a whole lot of sucking in Bugzilla, and it got a whole lot more downloads.

Why is it that this worked?

As long as you consistently suck less with every release, you will retain most of your users. You’re fixing the things that bother them, so there’s no reason for them to switch away. Even if you didn’t fix everything in this release, if you sucked less, your users will have faith that eventually, the things that bother them will be fixed. New users will find your software, and they’ll stick with it too. And in this way, your user count will increase steadily over time.

But what happens if you release frequently, but instead of fixing the things in your software that suck, you just add new features that don’t fix the sucking? Well, eventually the patience of the individual user is going to run out. They’re not going to wait forever for your software to stop sucking.”

Personally, I got tired of Spotify’s Podcasts product continually going in the wrong direction on Max’s scale: the poor reliability, frequent errors on the Creators site, and the sense that they don’t really care about improving existing things.

Read the full issue of last week's The Pulse. The full The Pulse additionally covers:

1. Will Kimi K3 trigger US push for closed-source AI models? Moonshot AI’s latest open model, Kimi K3, is on par with Anthropic’s Fable 5. Could it lead to the US government regulating or banning Chinese open models to protect US labs?
2. AWS laughs off “heart attack” billing error. AWS customers were billed trillions more than they should have been, due to what was likely a conversion error. But instead of sharing an incident report, AWS saw the funny side.
3. Industry pulse. OpenAI’s unreleased model tried to hack HuggingFace to improve its test scores, X took more than a year to develop its new Android app, Google’s new AI model flops, and more.

Read the full The Pulse.

One thing I am hearing that’s top of mind for many engineering leaders is what is being done to deal with the continuous increase in code review load. It’s been a topic for a while, and more such conversations seem to be taking place.

For me, it began in January, when Opus 4.5 and GPT 5.4 started to write more and better code at most companies. Around then, Director-level folks started talking about the bottleneck of building software moving from coding to the review phase.

There’s been a boom in AI code review tools to deal with the increase in load since February, and an explosion of experimentation with and adoption of dedicated AI code review tools like CodeRabbit, Greptile, Qodo, SonarQube (now also Gitar). There’s also tools offered by coding harnesses themselves like Claude Code review, Cursor review, GitHub Copilot review. And then tools previously not involved in code reviews – but which have context on the codebase – are also adding this, like Sentry’s Seer AI reviews, Linear code reviews.

Larger companies are building in-house tools to improve the code review experience. Uber’s Code Inbox is one case:

Smart assignments are a feature inside Code Inbox for having reviews progress:

Then there’s Risk Profiles which estimate the impact of a change, and encourage devs to pay extra attention to risky ones:

We covered how Uber uses AI for software development, and it’s not just Uber: companies like Cloudflare (AI Code Reviewer), Faire (Fairey), and HubSpot (Sidekick) and many others have also built tools to make their code review flows more fluid, after finding that an in-house implementation worked better than integrating a vendor.

Another approach is thinking about how to verify code, instead of reviewing. This is easier said than done; in theory, thorough testing should be able to verify that code works as expected. But how much testing is ‘thorough’? What type of tests are we talking about? Integration and end-to-end as well? What about fuzz testing? Or formal methods? What about verifying that new tests exercise the functionality as expected? And how do we connect all of this with observability?

Too much thorough code review is burning out engineers, and resulting in sub-par code reviews. I hear a lot anecdotally that devs see others as no longer able to review code with intent, whereby, if the AI code review has no real comments, they just approve it. Meanwhile, those devs who put the same effort and energy into code review as before feel overloaded by AI slop PRs sent their way.

The problems exist, and the solutions feel more like experiments.

What are you seeing inside your company, and how are you dealing with the increase in code reviews? Share your ideas for practical, workable “replacements”?

Read the full issue of The Pulse this excerpt is from, or check out the latest The Pulse from today. Today’s issue covers:

1. Moving video podcasts off Spotify due to constant reliability issues
2. “Kimi K3” moment & a US lobby for closed-source AI models
3. AWS laughs off huge billing error
4. Industry Pulse

Read the full issue here

Last week in San Francisco, I met Jarred Sumner, creator of JavaScript runtime, Bun, and was keen to learn more about the rewrite of Bun from Zig to Rust. But at the time, Jarred didn’t want to say too much, as the tool used for the migration, Fable, was out of action due to the US government imposing export controls. 

Jarred and I at Anthropic’s HQ, last week

Fortunately, the situation is now resolved and Fable is available globally, and Jarred has published a detailed post about the project. Before we get into the migration, some context:

Bun is a complex project, with lots of production software depending on it. Bun itself does many things:

• JavaScript, TypeScript and CSS transpiling, minifying and bundling
• A test runner
• A package manager (npm-compatible)
• Other things: module resolution, a WebSocket client, Node.js implementations and many modules

Today, Bun has 22 million monthly downloads, and software like Claude Code and OpenCode depend on it, while hosting providers like Vercel, Railway and DigitalOcean do first-party support for Bun.

Why a rewrite? 

Zig is not a memory safe language, and memory-related bugs occurred continuously. Jarred lists memory-related bugs in the latest version of Bun: memory leaks, crashes due to memory issues, heap-out-of-bounds writes, and so on. This was after the Bun team patched the Zig compiler to reduce memory-related issues, and put end-to-end memory leak tests in place. As Jarred says:

“Our bugfix list felt bad and I was tired of going to sleep worrying about crashes in Bun. I don't blame Zig for that - other users of Zig don't have the bugs we had, and mixing GC with manually-managed memory is an uncommon enough thing for software to need that no language really designs for it. (...)

For Bun, correctly handling the lifetimes of garbage-collected values and manually-managed values has been a major source of stability issues - most often small memory leaks and occasionally crashes. Every memory allocation has to be meticulously reviewed. Where do these bytes get freed? How do we ensure it only gets freed once? Did we check for JavaScript exceptions properly? Is this garbage-collected pointer visible to the conservative stack scanner? Is this garbage collected memory or manually managed memory?”

Moving to a memory-safe, yet performant language could eliminate such errors, and Rust is one such language that fitted the bill. Jarred:

“A large percentage of bugs from that list are use-after-free, double-free, and "forgot to free" in an error path. In safe Rust, these are compiler errors and RAII-like automatic cleanup with Drop. Compiler errors are a better feedback loop than a style guide.”

However, doing a full rewrite on Rust has always been a terrible idea. Or at least, it used to be, because of how unbearably long it would have taken:

There are two problems with rewrites: they take too long, and they take waaaay too long. A dev who has done rewrites probably knows how things tend to go:

1. Make an educated guess about how long it will take; say, nine months.
2. Nine months later, there’s still another ~6 months to go because new functionality is added to the original codebase, and now that new functionality needs to be added in!
3. By 15 months in, there’s still months left to go for the same reason!
4. In the end, you manage to mandate a “feature freeze” for two months and finish the rewrite in ~18 months, if lucky. The original nine-month estimate can end up taking 2+ years.

Jarred likened rewriting Bun in Zig to this:

“Historically, rewrites are a terrible idea. Excluding comments, Bun is 535,496 lines of Zig. 

A rewrite in another language would take a small team of engineers a full year.

A year of zero user-facing impact is not a realistic option we could consider. So, enforcement through code-style to fix stability issues was our best bet, and was our plan when we added Rust-inspired smart pointers to Bun's codebase.

But honestly, I didn't want to do it. Homegrown smart pointers offer worse ergonomics than Rust, with none of the guarantees.

What if, instead, I spend a week testing if Anthropic's new model [Fable] can rewrite Bun in Rust?”

Rewriting Bun with Fable

Unsurprisingly, the rewrite was not as simple as typing a prompt like: “Claude, rewrite Bun in Rust. Make zero mistakes.” Instead, this is how Jarred did it:

Step #1: Prep work. Three hours of intense prep work with Claude, explained Jarred:

“Before writing any code, I spent about 3 hours talking to Claude about how to map patterns from our Zig codebase closely to Rust. Claude serialized this discussion into a PORTING.md document, which ended up on Hacker News [as the Zig → Rust porting guide]”

This guide is a 600-line file with instructions like:

Ground rules:

• No tokio, rayon, hyper, async-trait, futures. No std::fs, std::net, std::process. Bun owns its event loop and syscalls. (Rust core/std slice, iter, mem, fmt, and core::ffi are fine — only the I/O-touching modules are banned.)
• No async fn. Everything is callbacks + state machines, same as the Zig.
• Borrow-checker reshaping is allowed. When matching Zig flow yields overlapping &mut, capture the needed scalar (.len(), index) into a local, drop the borrow, then re-borrow. Do NOT reach for raw pointers just to silence borrowck; leave // PORT NOTE: reshaped for borrowck so Phase B diff readers aren't confused.

It’s a series of instructions that makes sense to someone who’s expert in Rust. If you want to learn more, we cover Rust basics and why Rust is different, with Alice Ryhl.

Step #2: Trial run + adversarial review. Asking Claude to rewrite three files out of 1,448 total number of files. After the rewrite, Jarred ran two separate adversarial reviews with Claude to critique the result, in separate sessions than the one that Claude made the changes in.

Step #3: split up the work across 64 AI agents. Jarred split up the job so that agents worked on files independent from one another, in parallel.

Step #4: iron out issues with the run (~1 day). When Jarred attempted to run all this, agents kept getting in each other’s way:

“I asked Claude to loop the workflow on all 1,448 .zig files, and about 2 minutes in, one Claude ran git stash before committing. Another ran git stash pop. And then git reset HEAD --hard. They were stepping on each other! And if I put each Claude into a separate worktree, I would run out of disk space because Bun's git repository is too big and eventually the changes will need to be compiled and seen together.

So, I asked Claude to edit the workflow to instruct Claude to never run git stash or git reset or any git command that doesn't commit a specific file at once. No cargo either. No slow commands at all.

Then, Claude resumed the workflows. And it was working! Too slowly, so I split it into just 4 workflow shards each with their own worktree (4 worktrees total), each running 16 Claudes committing and pushing files.”

Step #5: have it run and wait ~2 days. The parallel agents went to work, and completed the rewrite of 535,496 lines of Zig code over the course of two days. Each commit was checked by two adversarial reviews, before being committed.

Step #7: fix ~1,600 compiler errors (~12 hours). The rewrite was completed, but nothing compiled. Going crate-by-crate (‘crate’ is Rust’s concept of a top-level compilation unit), Jarred had Claude fix compiler errors. This alone would be a herculean task for an engineer, but not for Claude:

“Fixing the cyclical dependencies revealed about 16,000 compiler errors. A massive number for 1 human, but not a crazy number for 64 Claude’s at once.

To maximize parallelism, the workflow looped over each crate.

• For each crate, run cargo check, group the output by file and save the errors to a file
• Fix all the compiler errors within that crate
• 2 adversarial reviewers for the crate's changes
• 1 fixer applies the fixes”

Visualizing fixing of errors, one by one, done by the agents. Source: Anthropic

The enjoyable thing about this phase of the migration was that the agents ran from midnight until 11:30am, fixing compiler bugs on their own – when Jarred and the team were getting some sleep.

Step #8: run tests locally (~2 days). Bun has a large test suite. The next step was to get these tests to run without compilation errors. 

Step #9: get the test suite to pass CI (~3 days). Once the tests were running (and failing), the next step was to fix the code, so that the tests could pass. This took two days.

Step #10: Done in 11 days! After all the tests passed and Jarred verified that everything worked as expected, he merged the changes. The whole process took 11 days, from planning to the finish.

The rewrite: porting ~550K lines of code, in 6,500 commits, over 11 days, with 64 agents

How repeatable is this process?

The rewrite cost a whopping $165,000 with API pricing. With Fable’s API prices, the rewrite consumed 5.9 billion uncached input tokens, 690 million output tokens, and 72 billion cached input token reads. Anthropic sells API tokens at a margin as its business, so the cost of the rewrite for it was lower. It’s a large amount: the equivalent of the annual base salary for a software engineer at a mid-tier company in the US!

But then again, could have an engineer done all this work in a year? Probably not, and Mitchell Hashimoto says the same:

“On the cost, I think $165,000 at API pricing for Fable (didn’t verify) is an incredible deal. There’s absolutely no way an engineer with that salary would’ve been able to achieve the milestones Claude did in 11 days. No way. (Even if you break it down to N engineers paid $165K total in 11 days it doesn’t math out)

This does, however, also reconfirm my own biases which is that Fable in particular is most excellent at hard, focused tasks with clear reward functions. I’ve been tweeting about this recently.”

What if AI enables rewrites and migrations that wouldn’t have been considered before? The idea of rewriting Bun in Rust without AI was impractical, admits Jarred:

“By hand, I think this would've taken three engineers with full context on the codebase about a year, during which time we wouldn't be able to improve Node.js compatibility, fix bugs, fix security issues or implement new features. We never would've done that. The realistic alternative was to do nothing and keep fixing the bugs at the top of this post forever.”

A rewrite or migration taking months or years is why so many of these projects never happen. Let’s take aside the cost for a minute and consider this question: if AI can shorten a one-year rewrite to a week: would you do it? 

If the answer is “hell, yes:” a blueprint now exists in the form of the Bun migration on how to do it. There are some caveats not detailed in the post, though:

1. You need an engineer who is very motivated and knows the codebase very well
2. You need an extremely robust test suite, so when the test suite passes, you know it works
3. You need to be willing to invest a lot in tokens, not knowing how well it all will work

In fairness, #3 is the weakest point because we know LLMs are pretty good at “mundane” work like code migrations. With a good test suite (#2) and a motivated engineer to iron out things (#1), you’ll more likely than not succeed.

The remaining question is how much can be spent. It will likely not be $165K: and costs can be reduced with a simpler project, or by being thoughtful about model usage. For example, do high-level planning with the most expensive model, and cheaper ones for coding and review tasks.

Migrations with AI are surely speeding up, but only when projects are well-engineered like Bun’s has been.

Read the full issue of The Pulse this excerpt is from, or check out the latest The Pulse from today. Today’s issue covers:

1. Grok’s CLI uploaded all your local files to the cloud, then got caught.
2. New trend: concern about massive increase in code review load.
3. Are more devs at enterprises upset about enterprise pricing by AI labs – and does it matter?
4. Linux creator: AI “clearly useful.”

Read the full issue here

Cursor has just released a new report based on two years of its aggregated usage data, and there are some interesting findings:

Power users generate 10x as many lines of code vs the median

The median dev using Cursor (the p50) generates about 700 lines of code per week with it, while for the 90th percentile, it’s closer to 9,000 lines.

Top 1% of users create incredible volume of code

The p99 data is pretty stunning:

The top 1% of users generate around 30-40K lines of code per week! That’s the equivalent of what ~45 “median” devs generate in the same period.

It’s worth asking how these top 1% of users are different. Are they writing a lot more greenfield code, do they have a bias for not using libraries, are they tokenmaxxing to get to the top of leaderboards? Do they generate 45x as many bugs, and importantly: are they adding a lot of business value with the software they ship?

Cursor consumes 10x more input tokens than it generates in output tokens

This is surprising: 90% of Cursor’s token usage is input tokens! This means that most of the tokens used are for reading the existing codebase and documentation. Outputting of code is a minority usage:

In some ways, this usage makes sense: as devs, we always spent far more time on reading the code, compared to lines of code we typed out. The “10:1 read-to-write” ratio is a classic. Here’s Robert. C. Martin (aka “uncle Bob”) sharing this observation in 2008, in his book, Clean Code:

“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code… [Therefore] making it easy to read, makes it easier to write.”

I find it amusing that we’re now seeing this 10:1 read / write ratio for token usage with AI agents!

Input tokens become the main AI token cost

Input tokens are priced at a fraction of output tokens: for example, Opus 4.7 charges 5x more for output tokens than for input tokens ($5 per 1 million input tokens and $25 per 1 million output tokens). Still, thanks to input tokens dominating token usage, Cursor is seeing input tokens account for closer to 70% of the cost of AI coding agents:

Without caching context, token cost would be 10x higher

Cursor does smart caching of context, to avoid re-generating old context with more new input tokens. When taking cache usage into account, Cursor only spends 0.6% of tokens on output tokens. The remaining 99% is split between cache read (90%), cache write (2.5%), and input tokens (7%):

I wonder if context reuse and caching will be a key AI efficiency component in the future? AI tokens are expensive to generate, so any form of reuse will make a lot of sense, especially in workflows like coding where a lot of existing context is reused.

Of course, Cursor sharing this detail also makes sense, as they remind everyone that building an efficient AI agent harness is far from trivial. Indeed, if you roll your own agent harness, you also need to put an efficient caching layer in place to match the efficiency of tools like Cursor.

Opus is the most expensive model & could hurt Anthropic

At the time of publishing, Opus 4.7 was still considered the most capable coding model. However, it’s also very expensive, and Cursor’s own data shows it’s close to 10x more expensive than its own Composer 2.5 model:

It’s significant that Cursor compares the cost of a single agent request; it’s not a direct token-to-token comparison. And it’s worth noting this benchmark is being shared by Cursor, which has an incentive for its Composer model to appear the lowest-cost.

Still, assuming you can get similar-enough results with a 10x cheaper model, it is a saving that’s hard to ignore, especially for mid-sized and above companies. I would not be surprised if more tech companies find ways for devs to use less capable – but cheaper – models for less critical work.

More expensive models result in higher acceptance rates

An interesting metric Cursor shares is cost-per-line-added, per model:

This metric is a more realistic cost because it correlates to output: “smart” models that are expensive, but which produce code that is frequently accepted, are penalized by the cost-per-agent-request metric, but they’re not here.

Indeed, Opus 4.7 has the same cost-per-line-accepted as GPT 5.5 at half the cost per agent request. In this comparison, Cursor’s Composer model is “only” 5x as efficient.

Missing from both lists are Google’s Gemini models, a strange omission by Cursor. I reached out to Cursor and they told me that Gemini was left out simply because they see very little usage of this model on their platform, similar to the sparsely used Grok model.

Almost half of AI changes accepted without manual review by devs

I’ve left the most interesting part of this report to last: in just a month, among devs using Cursor, it has gone from 10% who let AI agents create commits without a manual step, to around 40% of devs who no longer personally check the code:

The jump correlates with Opus 4.7 and GPT-5.5 being released, and around the time when many devs seem to have concluded that writing code by hand is dying after experiencing this generation of models’ capability at generating code.

Check out the full report from Cursor for more details. Thanks to the team for releasing this data!

Read the full issue of The Pulse this excerpt is from, or check out the latest The Pulse from today. Today's issue covers:

• Bun’s Rust rewrite with Fable: what can we learn?
• Anthropic’s Fable, OpenAI’s GPT-5.6 Sol, Cursor’s Grok 4.5, Meta’s Muse
• North Korean hackers keep trying to infiltrate full-remote companies
• Industry Pulse: Meta’s key logging exposed sensitive data, massive cuts at Xbox, Meta could not buy enough AI capacity from Google, Qualcomm acquires Modular, and memory price hikes hit Apple products.