The Pulse is a series covering events, insights, and trends within Big Tech and startups. Notice an interesting event or trend? Hit reply and share it with me.
Today, we cover:
Meta follow-up. A follow-up on Tuesday’s deepdive into Meta’s ongoing demolition of its own engineering org. Non-engineering teams lost more than 10% of their staff, while Integrity teams were already stretched before the cuts and reallocation.
Big implications of the US banning Anthropic’s new model, Fable. The US government wants only US citizens to be able to use Fable. That could make China more influential as other countries and non-US companies look to capable open models – most of which come from China.
SpaceX, Cursor, Continue. Elon Musk became a trillionaire with SpaceX’s IPO, while SpaceX acquired Cursor, and Cursor acquired Continue. SpaceX looks like it wants to go head-on against Anthropic and OpenAI.
Industry Pulse. Gemini lead quits for OpenAI, Epic Games’ new open source version control system, Microsoft considers dropping OpenAI for DeepSeek, research confirms LLMs amplify existing expertise, and more.
1. Meta follow-up
Tuesday’s article about Meta destroying its engineering culture made quite the splash in terms of comments and debate online. From inside Meta, there was positive feedback on the accuracy of the deepdive into the situation, and there were also a few helpful clarifications and new information which I’m happy to publish here:
Listen and watch now on YouTube, Spotify, and Apple. See the episode transcript at the top of this page, and timestamps for the episode at the bottom.
Brought to You by
• Antithesis – if you're using agents to code, the problem isn't writing the code but making sure it didn't break anything. Antithesis goes beyond code review and runs your whole system in faster than real-time and identifies hard to find bugs before your users hit them in production. Antithesis enables teams like Jane Street, Fly.io, and the etcd community to use agents safely and ship better code, faster. Learn more
• WorkOS – make your app and agents Enterprise Ready, with SSO, SCIM, RBAC, and more. Get started.
• turbopuffer – a vector and full-text search engine built on object storage. It’s fast, cheap, and extremely scalable. The teams building the smartest AI products out there — Cursor, Notion, Cognition, Anthropic — they all run on turbopuffer.
In this episode
Robert Erez is a principal engineer at Octopus Deploy, and a longtime expert in CI/CD, deployment systems, and software delivery. Rob and I were also once colleagues on the Skype web team, working on large-scale deployments and release processes.
In this episode of ThePragmatic Engineer, I sit down with Rob to discuss how teams deploy software safely and efficiently at scale. We cover Kubernetes, GitOps, platform engineering, progressive delivery, feature flags, cloud development environments, and the growing role of AI in CI/CD workflows. We also get into the tradeoffs in different deployment approaches, why self-hosted software still matters for some organizations, and the recent evolution of software delivery practices.
Key observations on deployments and CI/CD from the conversation with Rob
Here are 10 interesting takeaways from our chat:
1. Roll forward, never backwards. When a system has state – which typically means it uses databases – then doing a rollback can leave the code talking to a schema that’s no longer in sync. Rob’s advice is to not treat a failure in v2 as a trip back to v1, but rather as a push to v3 with the fix in it.
2. GitOps isn’t actually about Git. None of the four pillars of GitOps – 1) declarative, 2) versioned and immutable, 3) pulled, not pushed, 4) continuously reconciled – require Git, although Git can work under these constraints. Yet, the term ‘GitOps’ has made the industry dogmatic about cramming everything into a repo – even things like secrets that absolutely shouldn’t be there!
3. Continuous deployment can be overkill; continuous delivery is more practical. Shipping every single change to prod (continuous deployment) is not as necessary as many people think, Rob says, and there’s often more value in continuous delivery, where changes flow through testing and the deployment process itself is validated. With continuous delivery, you can decide whether to push to production automatically, or click a button once a week.
4. Feature toggles are a better safety net than rollbacks. When something breaks in production, reaching for a toggle to switch a feature off enables you to “stop the bleeding” and then calmly diagnose an issue. Rolling back a feature flag is less nerve-jangling than scrambling to force a redeployment in the middle of the night!
5. One problem with feature flags is that they’re addictive. On the other hand, the ease with which feature flags are added can create a hygiene crisis if they’re continuously added, but not removed. Treat feature-toggle cleanups like a form of gardening and “weed” rolled-out toggles from the codebase.
6. A Git repo can be a bottleneck at scale. Rob mentions that some companies run thousands of independent Kubernetes clusters that pull state from a Git repository. But such clusters can get throttled by the repo, forcing them into workarounds. Pull-based GitOps doesn’t scale infinitely for free.
7. A sizable number of major institutions remain on-prem – and this won’t change. Banks, other financial bodies, and governments, demand full control over their hardware, upgrades, and downtime. That’s why Rob expects this segment won’t move to cloud-based SaaS.
8. Platform teams work at larger companies. These teams earn their keep in big organizations with multiple teams and projects because they offer ways of bringing sanity and focus.
9. There’s a trend of ephemeral environments replacing test/staging environments. Companies used to have a few testers fighting over a handful of static test environments, but today, it’s trivial to spin up a full environment, per-feature branch, pre-merge. This is an “ephemeral” environment for evaluating that things work, which is then torn down once something is merged. It helps speed up the feedback process.
10. AI shifts the CI/CD calculus from speed to risk. Today, shaving ten minutes off the CI build-time matters because a long-running build blocks human devs. But this time saving will be insignificant when an AI agent writes most of the code and “babysits” a slow pipeline without context switching. Then, the new priority will be to reduce the risk of an AI agent shipping a bug to production, so it will make much more sense to run extra, more thorough, tests – and also even slower ones.
The Pragmatic Engineer deepdives relevant for this episode
Hi – this is Gergely with a free issue of the Pragmatic Engineer Newsletter. In every issue, I cover challenges at Big Tech and startups through the lens of senior engineers and engineering leaders. Subscribe to get deepdives like this in your inbox, weekly:
For two decades, Meta had a unique, high-performance engineering org; right up until around April of this year. For the first 20 years of the company’s existence, it had a “move-fast-and-break-things” culture, and in the early 2020s this shifted to a “move-fast-with-stable-infra” one. Engineers I know at the company were empowered to do good work, focus on impact, and to balance business interests with solid engineering.
But in the past few weeks, all that has changed, as if the leadership has been following detailed blueprints on how to demolish a proven, successful engineering culture in the most ruthlessly efficient way possible.
For the past few weeks, I’ve been sharing how bad things are inside the social media company for engineers in one of Silicon Valley’s most prestigious workplaces. In this article, we walk through what’s happened, and ask what’s going through the minds of leadership who are reducing software engineering there from the profit center that it was between 2004 until very recently, to the disdained cost center that it has become in just a few weeks.
We cover:
Meta’s pre-AI engineering culture
Investing in AI and pressing engineers to always use it
Core engineering folks feel treated like trash
Most embarrassing-ever outage
Internal mess
Self-inflicted wounds
Is “AI psychosis” just a Meta issue?
1. Meta’s pre-AI engineering culture
I’d split Meta’s engineering culture into two eras: “move fast and break things”, and then “move fast with stable infra.”
“Move fast and break things”
In the 2010s, Facebook’s unconventional engineering culture had grown somewhat legendary in the tech industry, as the company went against conventional best practices and succeeded massively.
In 2012, when Facebook hit the billion-users landmark, the company produced a small physical book about its culture which was placed on employees’ desks. Presented with retro propaganda design, it was dubbed the “little red book”, co-opting the name of a famous volume of the thoughts of Chairman Mao, (1964).
At around 70 pages long, Facebook’s version codified its engineering culture: speed, fearlessness, taking ownership, and thinking outside of the box.
Back then, mantras in Facebook’s little red book were also in print across campus, and included:
Move Fast and Break Things
Done is Better Than Perfect
Fail Harder
What Would You Do If You Weren’t Afraid?
Every Day Feels Like a Week
The Wright Brothers Did Not Have Pilot Licenses
The Foolish Wait
Fortune Favors the Bold
There was genuine focus on building good products. Also from the book:
More from Facebook’s Little Red Book
“Move fast with stable infra” culture
In 2022, I did what is one of the longest deepdives we’ve published on the topic of Meta’s engineering culture. By then, things had evolved, and much of any former recklessness was gone, replaced by the principle of moving fast, but with stable infra. Here’s how I described Meta’s engineering culture then:
“The culture is incredibly engineering-centric: much more than most of Big Tech. This might come from Mark Zuckerberg being an engineer himself, or because much of the innovation in the early days of Facebook came from engineers.
Focus on individual impact. Impact has been the bread and butter of the focus at Facebook. This is very true since the early days, and the focus on generating impact remains.
One detail in common with most Big Tech firms is that both the engineering culture and general culture focus so much on individual impact. This results in some people focusing on short-term, measurable wins and assuming that teamwork and split wins between groups might be less rewarded.
The lack of rigid processes. Facebook seems to have the least amount of processes or standardization across all of Big Tech. Don’t even try to compare it to Amazon’s engineering culture and the countless formal processes there. But even compared to companies like Google, Microsoft or Uber, Facebook’s processes are much looser. Most of this comes from the engineering-centric nature of the company and engineers disliking processes.
Surprisingly little emphasis on testing, documentation or code comments. You’ll find shockingly little automated testing and documentation at Facebook, compared to the rest of Big Tech. Inline code comments are also very rare.
A founder-engineer driven company. Facebook is one of the few Big Tech firms whose founder is an engineer, and still is the CEO. Netflix is the other one where founder and co-CEO Reed Hastings was also a software engineer before starting the company. Amazon was the other example of this until recently, but it’s not the case at Google or Apple. There are good examples of smaller companies like Cloudflare, but they’re all younger than Facebook.
Bootcamp. A unique onboarding process, unlike what any other Big Tech firms offer. We cover this more in the Bootcamp & onboarding section.”
Engineers whom I knew inside the company are capable, motivated, and product-minded, and their work was appreciated. CEO, Mark Zuckerberg, was influential: he personally coded the first version of Facebook, had stayed close to engineering, and valued software engineers very much. Engineers there felt they were working inside a profit center.
2. Investing in AI and pressing engineers to always use it
Meta has been the only company among the big five of Apple, Microsoft, Amazon, Google, and itself not to own a hardware platform or operating system. Apple has the iPhone, iPad and Macs, Google has Android, ChromeOS and Pixel phones, Microsoft has Windows, and Amazon has the Kindle.
Stepping back, it looks as though the Mark Zuckerberg of today has resolved not to miss a platform opportunity, after the company failed to build its own mobile OS or mobile phone during the 2010s.
This is one reason for investing so much in virtual reality (VR) with Oculus, and in augmented reality with the Meta Glasses. Facebook changed its name to Meta in 2021, back when it looked like VR – and the metaverse – could be massive. Billions was spent on ensuring Meta would be the market leader in this space. But once again, VR didn’t go mainstream; since the end of the pandemic, popular interest in the segment has died down considerably.
When it became clear that AI would become a mega-trend in 2022, Zuckerberg didn’t miss it: he assembled the internal FAIR group (Fundamental AI Research team) as well as a GenAI product organization and released a series of open-weight AI models:
Llama 1: released in Feb 2023, three months after ChatGPT, built by FAIR
Llama 2: in June 2023, built by the GenAI product organization (as well as all subsequent Llama models)
Llama 3: in April 2024. This model was Meta’s most competitive LLM of all, and gained momentum in adoption across the industry
In June that year, Meta acquired a 49% stake in Scale AI to reboot its AI efforts for a whopping $14.8B, and brought in Scale AI’s CEO, Alexandr Wang to take over Meta’s AI strategy. The acquisition of Chinese startup Manus AI for $2B is currently in question after China blocked the deal from being completed.
Based on the investment made into Scale AI and Wang, it’s pretty clear that Meta – and Zuckerberg – is determined to build a state-of-the-art LLM that can be competitive with the latest versions of Claude and ChatGPT. But Meta has to start pretty much from scratch, and it’s up to Alexandr Wang to deliver.
Scale AI brings in a very specific kind of expertise to Meta, as one of the best in the industry in:
Training data and labeling: Scale started, and is still best known, as a provider of high-quality labeled datasets for machine learning and AI training, including code, text, image, video, etc.
RLHF and fine-tuning: A RLHF (reinforcement learning from human feedback) flow which Scale runs, where people give feedback for foundation models, as a “human in the loop” data engine that many leading AI labs use to create better LLMs.
Wang seems to have a very broad reign to do what he has been an expert in: creating training data, doing data labeling and RLHF. This is being pulled off with the labor of Meta’s engineering workforce, and by surveilling it.
Problem #1: Tracking keystrokes and mouse clicks, with no option to opt out. In late April, Meta told engineers they were being enrolled into a system that tracks every keystroke and click, to produce training data for Meta’s new AI. There’s no way to opt out.
Needless to say, this is invasive and raises privacy questions: If you log into your personal bank account, does the tool track you? What about when you’re writing a personal email, or responding to a personal call? Meta held no consultation and there are no workarounds; just a top-down decision being pushed through.
This month, Reuters reported that people’s concerns there are finally being heard:
“Meta is dialing back elements of its plan to collect employee mouse movements, keystrokes and other actions for use as AI training data, it said in an internal memo on Tuesday, following weeks of angry pushback from staffers.
New controls will allow employees to pause the data collection for up to 30 minutes at a time and request exemptions from the initiative, according to the memo, authored by Stephane Kasriel, a vice president in Meta’s AI model-building Superintelligence Labs unit.”
From talking with current Meta engineers, I understand the logging system has not been rolled out in the UK due to data protection regulation.
Problem #2: 30-50% of engineers on core teams have been forcefully reassigned to data labeling and RLHF, upsetting folks even more.Also starting in late April, product engineering teams received a mandate from above, whereby 30-50% of engineers were to leave the team and join the ADO org (Agent Data Optimisation).
“Forceful” reassignment is very relevant here because of Meta’s traditional engineering culture. Between its founding in 2004 and until last year, Meta gave engineers autonomy to choose where they work and what they work on. This was structural to how the company worked:
Engineers were not hired for a specific team (save for at the Staff+, levels, in some cases). They were hired to the company
During a 6-week bootcamp, new hires got familiar with Meta’s engineering culture and chose a team
Team matching meant talking with multiple teams who had headcount, doing small work with them, and finding a match
Internal transfers were easy, and often initiated by engineers
Team selection via bootcamp started to die down in around 2024, but any Meta engineer with at least two years’ tenure knows that previously they chose what to work on, and of course, could pick the most impactful thing to work on. And then, out of the blue, they’re assigned to a division where the impact is not clear, the work is menial, and doing it too long will surely hurt their career prospects.
“Data labeling” is more involved work, even though a bit repetitive. There are labeling tasks, where you create a website, then look at it and decide if it looks good or not, and give this feedback: this is the “typical” data labeling. But this is the less frequent type of work. But then there are more involved AI training tasks, which looks like this:
Come up with a task that the AI should do
Then write the tests that confirm the result
Package all of this up into a Docker container, using Harbor framework
Then read the code that the AI writes - often doing this based on feedback from several models, and give it feedback
This work is not easy to do — and you can see why you need good software engineers to do it! — but it gets repetitive really quickly. Most engineers who I talked to said that they found it hard to do this work motivated day-in, day-out. Then again, I did talk with an engineer inside the org who said that by varying the technologies they use, and challenging themselves, they found this work motivating and interesting! This engineer expects there to be more software engineering work coming up, after the phase of training passes. There’s a lesson here: when life gives you lemons, you can either complain about it, or you can make lemonade, like this dev has done so.
This training work is secretive across the AI industry, and vendors are offering $100+ per hour for devs to do this type of work. There are rumors across the industry that OpenAI and Anthropic spends more on these training environments (to make the models great at coding) than the model training run itself!
Infrastructure and security teams were hit especially hard by reassignments. I talked with several engineers in infra orgs, who had 30-50% of their teams drafted into the ADO org. And in some cases, it was the best engineers who left.
One engineer told me that the whole situation feels like the movie, The Hunger Games, when tributes are randomly selected and then removed from their environment, to something completely different. Except, at Meta, many more folks are being affected, with between three and five from a 10-person team going from building products used by hundreds of millions, to giving human feedback on AI-generated GitHub repos, over and over. So, a wider impact than in the Hunger Games, but with less drastic consequences.
Around 6,500 people are in the ADO org, more than at OpenAI and Anthropic. Roughly four to five thousand of these are software engineers. Meta has around 25,000 engineers, meaning that one in every 5-6 software engineers may now find themselves doing data labeling full time.
As you can imagine, people are actively open to new positions, and nobody is updating their job title on LinkedIn and elsewhere to “data labeling at Meta.”
I’ve spoken with people in this role and they don’t like doing it, and feel upset about the top-down decision making. The silver lining is that they still have a job, have retained their salary, and were not part of layoffs. They still have time to leave Meta for something that pays comparably and is not a data labeling job.
3. Core engineering folks feel treated like trash
Problem #3: a month-long waiting game, stoking fear across the company. On 20 April, Reuters reported that Meta planned to lay off 10% of staff in a month’s time, and Meta confirmed the news, meaning there was a period of four weeks when everyone knew that they could be unemployed very soon.
Forced reassignments to data labeling started to happen. As I covered at the time:
“Understandably, there are mixed feelings about this redeployment [to data labeling], with layoffs coming soon. On Wednesday, 20 May, Meta will announce layoffs. Perhaps those moved to do data labeling could actually be “safer” than colleagues on product teams. Of course, this is speculation, but it would be cruel if Meta cut devs reassigned to data labeling.”
Problem #4: Performance review is hyper-aggressive at Meta, so devs optimize all metrics. The internal performance review process, PSC (Performance Summary Cycle), is very stringent, compared to Google and Apple, I’ve learned. Managers inside Meta “fight” over the pay packets of their employees, which involves “knocking down” the packet of engineers on other teams, so their direct reports are ranked higher. It’s common to weaponize metrics in this process – be that business impact, the number of code reviews, number of lines of code written, pre-AI (see our Coding Machine archetype podcast on this.)
Quotas are handed down to managers for the splits of the workforce to be put in each ‘bucket’, and the internal politics gets heated as managers try to get their reports into higher buckets.
After a few years, engineers at Meta learn that the best way to not get a bad PSC rating is to have all metrics – impact, code committed, and other numbers – higher than their peers’ are. Learn more about the internal politics of performance calibrations.
Problem #5: tokens are measured as part of perf, so devs aggressively optimize for it. When layoffs were confirmed, engineers also learned that managers shall inspect token count during perf reviews. This raised worries that those with low token counts might be marked as underperformers and dismissed.
So, what is the natural reaction to this as an engineer at Meta? They started using AI tools for the sake of generating more tokens. This happened while Meta had an internal token leaderboard, encouraging tokenmaxxing. As I wrote on 16 April:
“As per The Information, Meta employees used a total of 60.2 trillion AI tokens (!!) in 30 days. If this was charged at Anthropic’s API prices, it would cost $900M. Of course, Meta is likely purchasing tokens at a discount, but that could still come in at $100M+ – in large part from senseless “tokenmaxxing”.”
The biggest problem: people stop caring about real work and focus on performative work. Let’s check the four ingredients that Meta’s leadership has decided to introduce to their workplace:
Tracking the keyboards and mouse clicks of all engineers, where legally possible
Reassign a good chunk of engineers to fulltime data labeling
Let staff know that 10% of them will be laid off
Have a culture where devs optimize for any and all metrics measured during PSC
Measure token usage as part of PSC
Shake this mix up well, and what do you get? Two things:
Everyone overuses AI to boost their personal stats. An engineering workforce that pretends to work with as much AI, and as little human input, as possible. It’s a strange incentive where an outage caused by a failure to review code properly is not grounds for dismissal, but writing code by hand – instead of having an AI agent write it – could cost you your job
Every longer-tenured engineer is seeking a new job, or at least considering it. Those who have been around at Meta longer term have seen enough. Let me describe this visually:
Why pretty much every engineer at Meta is looking for a way out, visualised
Fresh data seems to confirm that starting in May, a lot more engineers at Meta are looking for an “out.” Here’s how signups to leading Big Tech interview preparation service interviewing.io from Meta have changed over the last year and a half: we can see a massive jump in May vs the year before, as shared by founder and CEO Aliner Lerner with us:
Signups to interviewing.io’s interview prep service from Meta. Source: interviewing.io.
To its credit, Meta has given out generous retention equity packages to several engineers considered key on the remaining teams. These packages make it harder to get matching compensation elsewhere. Still, I talked to one engineer who got an equity top-up, and said that this approach helped him decide to leave as soon as possible because he feels bitter about the lack of autonomy and having no control over things.
4. Most embarrassing-ever outage
Meta’s core infra and security teams have suddenly found themselves severely understaffed. Most folks are pushing AI-generated code merged with AI-only reviews, without paying much attention to quality. After all, they’re dealing with the possibility of unemployment, while firefighting to operate a team without its best engineers whose headcount has been cut in half, all with the knowledge that AI usage could affect their own job security.
Two weeks ago, on 30 May, the most embarrassing outage in Meta’s history happened. Here’s software engineer Siddharth Sundharam’s summary (emphasis mine):
“Yesterday, a slew of Instagram accounts, including some high profile ones like the Obama White House account, seemingly got hacked.
Look, I’m no spring chicken. I’ve spent almost a decade and a half identifying vulnerabilities and exploits at unicorn scale, but this is hands down the most unserious, “almost too stupid to be true” of them all.
The Takeover Flow:
Step 01: Faking the Location & Initiating Support. All the attacker needs to kick this off is your account username. Then, they hop on a VPN or proxy close to your city so Instagram’s security algorithms don’t suspect a thing. (You can quite easily get this from your public profile or “About” section or a hundred other ways.) Once it looks like the request is coming from the correct region, they tell the Meta support AI that the account is hacked and ask it to send the verification codes to an arbitrary email address they control.
Step 02: That’s It. Really, that’s it.
The first proper zero auth password reset I’ve seen in production. There appears to be no additional check as to whether the email being given is actually something the user has used before. Once the AI sends the security code to the attacker’s email, the attacker passes it right back to complete the verification. The platform hands over a fresh password reset link, granting full ownership to the attacker.”
This is a security breach in which Meta left its extra-secure, reinforced front door unlocked, so that anyone could come in, and there was no alarm to notify anybody when it happened! It seemed Meta only noticed when users started reporting it on social media!
From talking with folks inside Meta, I’ve learned that AI was at the heart of this outage. AI-generated, AI-reviewed code, and security teams being gutted were together the cause of this beyond-embarrassing incident. I poked around, and here’s what I gathered:
Instagram’s Trust and Safety Team lost around 50% of its staff to data labeling and layoffs. Some of the most senior folks were drafted onto AI training tasks.
AI-generated changes that saw no human input, just another AI code review, were very common during the last two months, across the codebase. The change that caused this outage looked like one of these
Normally, the Trust and Safety team would be on top of monitoring and alerting of security breaches, but it is currently in full disarray due to rapid, internal disorganization.
Meta’s Chief Security Officer resigned the very next day. The outage was resolved on Monday, 1 June, and an investigation started as part of the SEV process. On Tuesday, Meta’s Chief Information and Security Officer (CISO), Guy Rosen, announced his departure.
Coincidence? I suspect not: the CISO might have stepped down if they warned against the Security org being gutted but were then ignored, and so no longer trusts leadership. I also imagine the CISO didn’t have the idea to move a good half of Instagram’s security team over to data labeling.
As a note, the previously worst outage was all Meta services going down for seven hours in 2021, due to a DNS / BGP configuration issue. It was a bad outage, but Meta handled the follow up well, in my opinion. After that 2021 outage, Meta shared a postmortem and apology. It has not done so for the latest Instagram account takeover outage.
5. Internal mess
Wired shares more details on just how bad the situation is inside Meta, right now:
“Someone interrupted a livestreamed, employee-only presentation at Meta earlier this week with an expletive-filled outburst about “being the company’s bitch,” according to a recording heard by WIRED. The individual then asked the people leading the call to write to a specific Meta AI executive and “tell him that he’s a piece of shit.”
The incident, which took place on a call open to thousands of employees, reflects growing frustration inside the company’s Applied AI team, which was formed in March to support the work of AI researchers at Meta Superintelligence Labs. Three current employees tell WIRED there is widespread dissatisfaction with how Meta assembled the unit of about 6,500 engineers and product managers and the drudgework they allege they have been assigned to improve AI models.
“It’s literally the gulag,” one of the employees claims. “You have zero purpose in life all of a sudden, you barely interact with anyone, you just have these tasks every week.”
There’s more: Meta’s Chief Product Officer, Chris Cox, reportedly admitted to staff that Meta’s upper leadership (the folks above him, meaning the C-level at Meta) created the mess. Also from Wired:
During a meeting this week open to all employees at Instagram, Meta chief product officer Chris Cox addressed the “difficult” and “brutal” environment created by the “insanity of this company” in the past few months, according to a recording heard by WIRED. Cox applauded Instagram employees for launching features and serving around 2 billion users amid what he compared to “running a marathon in the middle of a hailstorm and then, like, your teammate gets replaced and then we’re recording you.”
“It’s like what the fuck,” he said, drawing laughs, before repeating himself. “It is like what the fuck.”
6. Self-inflicted wounds
So, is there an ultimate source of the “insanity of this company”, as CPO Chris Cox put it? Engineers whom I talked to point the finger at two individuals: Mark Zuckerberg and Alexandr Wang. Zuckerberg has full control over the business, and has made the decisions to reallocate a good part of engineering folks to data labeling, to roll out tracking software, and to lay off 10% of staff when Meta achieved record revenue and profits. As the CEO, the buck clearly stops with him.
But it’s hard to unsee that – outside of layoffs – everything that Meta is doing is taken from the Scale AI playbook, and that surely comes from Wang:
Mandatory keystroke and mouse tracking to generate training data
Forced data labeling with 4,500+ engineers is to generate high-quality RLHF, surely for Meta’s under-construction coding LLM
Taking away the best engineers from the heart of the business is surely signed off by Mark Zuckerberg, believing that it is more important for Meta to train a coding AI than it is to operate its core business like Instagram, Facebook or Messenger reliably. Oh, did I mention that on Saturday (12 June) Facebook and Instagram had another SEV0, that is, a full-on outage?
Before all this happened, Meta was on track to overtake Google as the world’s #1 ads business by the end of the year. But for some reason, Mark Zuckerberg decided that building a coding LLM is more important.
Meta’s leadership is now trying to undo all the damage they have done. Wired reports that Meta CTO, Andrew Bosworth, admitted to staff that the AI reorg was atrocious and committed to better communication in the future.
To me, it looks obvious that Zuckerberg doesn’t care how engineers feel about the massive changes, and that Bosworth likely ignored the chaos, all while engineers know for a fact that the next AI model matters more than they do to the business. Bosworth also said that employees will have access to AI coaching tools. Very considerate, given the situation!
Based on all I’ve learned, Meta’s engineering culture is dead because leadership has made it clear that engineering at the company is a cost center.
Nice while it lasted
Needless to say, I hope my assessment is way off, but I’ve seen nothing yet from Mark Zuckerberg and Alexandr Wang – the two executives creating this current mess – to suggest it is. There may be a short time period where, if major changes like data labeling assignments and staff tracking are undone, then things at Meta could return to normal. The longer the current conditions persist, the more tenured engineers will surely leave.
7. Is “AI psychosis” just a Meta issue?
It’s tragic to see a technical founder at Meta so focused on AI that he neglects the engineers who built the heart of his company. But is Meta a one-off exception?
Mitchell Hashimoto (creator of Ghostty, founder of HashiCorp) says he is seeing similar behavior by other founders (emphasis mine:)
“I strongly believe there are entire companies right now under heavy “AI psychosis” and it’s impossible to have rational conversations about it with them. I can’t name any specific people because they include personal friends I deeply respect, but I worry about how this plays out.
I lived through the great MTBF vs MTTR (mean-time-between-failure vs. mean-time-to-recovery) reckoning of infrastructure during the transition to cloud and cloud automation. All those arguments are rearing their ugly heads again but now it’s... the whole software development industry (maybe the whole world, really).
It’s frightening, because ‘psychosis folks’ operate under an almost absolute “MTTR is all you need” mentality: “it’s fine to ship bugs because the agents will fix them so quickly and at a scale humans can’t do!” We learned in infrastructure that MTTR is great but you can’t yeet resilient systems entirely.
The main issue is I don’t even know how to bring this up to people I know personally, because bringing this topic up leads to immediate dismissals like “no no, it has full test coverage”, or “bug reports are going down” or something, which just don’t paint the whole picture.
We already learned this lesson once in infrastructure: you can automate yourself into a very resilient catastrophe machine. Systems can appear healthy by local metrics while globally becoming incomprehensible. Bug reports can go down while latent risk explodes. Test coverage can rise while semantic understanding falls. Changes happen so fast that nobody notices the underlying architecture decaying.
I worry.”
The takeover outage at Instagram was exactly like this: the engineering team dropped the quality bar for AI-generated and AI-reviewed code, probably expecting that they could recover quickly from failures. And they did indeed recover… after the damage was done, high-profile Instagram accounts were hacked, and the system was compromised, all very publicly.
Mitchell highlights the specific concern of founders over-estimating the capabilities of AI, and consequently casting aside sensible safeguards when shipping code to production.
Takeaways
Most of us probably have something to learn from the disastrous events at Meta caused by hyper-focus on AI to the exclusion of people who are the lifeblood of that company.In some good news, I’m hearing that in the UK, some of the 10% layoffs have suddenly been cancelled: at the end of the mandatory consultation period, several infra and security teams are learning that no engineers on their team will be let go, as originally expected.
Meta has a booming business, and is already a beneficiary of AI via increased ads revenue. Meanwhile, my Facebook feed is filled with fake, AI-generated videos, with hundreds of comments from bots and people who seemingly don’t realize it’s AI. It all seems like just more content for Meta to show ads next to.
And yet, despite business booming, Meta’s leadership has gone on a crusade to inflict the most damage possible on its engineering org. Apparently, they’re now learning that most of it was pointless.
If you’re in a leadership position and feeling the temptation to make drastic org changes for AI-related reasons, take a deep breath and see where it left Meta. Meanwhile, If you’re an engineer at a company whose leadership is over-indexing on AI, consider forwarding this article as additional context.
If you’re hiring standout engineers who are extremely hands-on with AI, then it’s never been easier to get talent from Meta, than right now. Every engineer I know at the company is an extremely early adopter of AI, and knows how to build products and AI infra. These folks have soured on the company and its leadership. Meta’s loss of talent will be the gain of other startups and the rest of Big Tech; it’s one benefit of AI that’s probably a bit unexpected – not least of all by Meta!
It seems like the old mantra of “move fast and break things” has now extended to Meta’s engineering org itself, with the company’s rush to over-invest in AI, so it will avoid missing the latest mega-trend in the tech industry.
The Pulse is a series covering events, insights, and trends within Big Tech and startups. Notice an interesting event or trend? Hit reply and share it with me.
Today, we cover:
Anthropic alienates customers with Fable’s data retention and nerf policies. Anthropic’s latest mode, Fable, stores customer prompts and data for 30+ days and performs worse if Anthropic thinks devs’ usage could potentially pose a commercial threat. The launch is an urgent reminder to have an off-ramp from Claude if you want to be able to vote with your feet.
New trend: smart model routing. Are there any ‘intelligent’ router solutions out there which select the right model for the right task? I looked into it, and there are a few options. More suggestions welcome!
Reliability fail: No automated zone failover for Coinbase’s global trading service. Back in 2016, Uber had a cross-region failover for its core business. Ten years later, Coinbase does not, so it’s little wonder the platform suffered an embarrassing 10-hour outage. The big mess is a head scratcher.
Industry pulse. Anthropic and OpenAI file for IPOs, open source project quits GitHub after maintainer banned without appeal, Opendoor “reshores” jobs from India to the US with AI-native engineers, and more.
Are LLMs eroding software engineering skills? A software engineer admits they feel increasingly useless due to how capable LLMs are, in an article that has resonated with lots of folks. My sense is that we give too much credit to LLMs, while underestimating our own capabilities and understanding.
1. Anthropic’s new model release is a reminder to have an off-ramp plan from Claude
What’s going on in today’s job market? We try to answer that big question in this second part of our deepdive into the tech employment market, following Part 1 on the tech jobs market in 2026, published two weeks ago.
First of all, a big thank you to partner teams for sharing exclusive details for this deepdive:
Interviewing.io: anonymous mock interviews with engineers from top companies. Thanks to founder and CEO, Aline Lerner.
Workforce.ai, built by Live Data Technologies, which monitors 1M+ job changes and 300M+ employment validations monthly, across companies, roles, levels, functions, industries, and locations. Special thanks to Alex Hamilton for his input.
SignalFire: a VC firm with a standout data analysis team. Ordinarily, their data is used to give their portfolio companies a major commercial advantage, but they made an exception to share some for this article. Special thanks to Asher Bantock.
TrueUp: a platform that scans every open job in Big Tech, top startups, and scaleups, typically paying in the top two tiers of the trimodal software engineering compensation model. Thanks, Amit Taylor.
Today, we cover:
Top AI labs are now more attractive than Big Tech. Anthropic is most in demand among job candidates for interview preparation services. Along with OpenAI, it’s almost certainly the place with the most competition for jobs in tech.
Harder for new grads & interns to get hired. Data shows that intern intakes have fallen, even as software engineering recruitment recovers. Large tech companies take on half as many interns as before, and candidates’ work and educational backgrounds matter more than ever.
Mobile and frontend demand drops, AI & FDE surges. Frontend engineer titles are disappearing fastest across the industry, followed by native iOS and Android ones.
AI engineering comp > software engineering comp. AI engineers are more in demand than software engineers, and get higher compensation offers, especially with equity. At the 80th percentile in the US, $300K+ base salaries are the norm now for senior engineers.
Management’s “great flattening” continues. There are fewer engineering managers for each engineer across the industry, and fewer VP of engineering and director of engineering posts at Big Tech.
Big Tech seniority & tenure keep rising. Since the end of zero interest rates in 2023, it’s as if there’s fewer ways to tempt Big Tech workers to switch jobs, so they remain in situ.
Interview preparation signups: what do they indicate? Companies doing mass layoffs tend to see the biggest surge in devs signing up to practice interviews. A list of the top 20 companies from where engineers are preparing to interview elsewhere.
Where engineers go after Big Tech. From Amazon, they go pretty much everywhere. From Google, Apple & Meta, it’s mostly to AI labs. Microsoft is where the most ex-workers become their own bosses by working for themselves next.
AI engineering job openings have increased 60% in the past year at top companies, while software engineering openings grew by 7% in the same places. We also found that Big Tech is significantly growing AI engineering headcount:
AI engineering headcount growth at Big Tech. We look into Microsoft’s spike in Part 1. Source: Workforce.ai
Anthropic: most in demand
New data suggests that the two biggest AI labs are attracting the most candidates to apply for their AI engineering roles, which is pretty predictable.
Interviewing.io is a job interview preparation service which offers coaching for clients who are getting ready for interviews at specific companies. Based on the number of mentions by clients, Anthropic is the one most candidates are preparing for with paid coaching, and it’s not even close:
Most popular employers in coaching prep. Source: interviewing.io
It’s also notable that OpenAI (16% of candidates) gets around the same share as Google (17%) and other large tech companies (17%). Combined, Anthropic and OpenAI account for 51% of all interviewing.io coaching requests. For context, interviewing.io only added coaching for frontier labs this year!
Weekly coaching demand for Anthropic vs OpenAI. Source: interviewing.io
There are a few potential causes of the surge of interest in Anthropic:
OpenAI replaces Anthropic as AI supplier for the US’s novel ‘Department of War’. In early March, the US Government controversially declared Anthropic a “supply chain risk”, and appointed OpenAI as its AI supplier, after Anthropic raised concerns about the future use of AI in mass surveillance and fully autonomous weapons. This raised suspicions that OpenAI agreed to cross ‘red lines’.
Anthropic’s market dominance continues. Claude Code is the most popular developer tool, as found by our AI tooling survey in February. It seems little has changed.
Anthropic’s value exceeds OpenAI’s. In March, Anthropic raised a $65B funding round at a $965B valuation, making it more valuable than OpenAI for the first time.
Anthropic files to go public first. Last week, Anthropic filed to go public, beating OpenAI which has done so a week later.
Anthropic also recruited the most in-demand AI researcher, Andrej Karpathy, in May. My sense is that between the two labs, Anthropic has more momentum for the time being, and has perhaps acquired a ‘halo effect’ with its seemingly principled stance. It’s not surprising that it’s attracting more candidates.
Where are AI labs hiring from?
We looked into the sources of recruits to the three most in-demand AI labs: Anthropic, OpenAI, and Google DeepMind. Here’s what we found:
Where top AI labs recruit from, and where folks go next. Source: workforce.ai
Where Anthropic hires from, in order of popularity:
Google (often Google DeepMind)
Meta
Stripe
Microsoft
Amazon (AWS)
Databricks
OpenAI:
Google
Meta
Apple
Stripe
Statsig (after OpenAI acquired Statsig)
Microsoft
Amazon (mostly AWS)
Databricks
Airbnb
NVIDIA
Google DeepMind:
Internal transfer
Meta
Microsoft
Amazon
Windsurf
Anthropic has the highest retention rate of all AI labs. Data from SignalFire found the 2-year retention rate (percentage of employees who stay 2 years) is:
OpenAI: 67%. This is consistent with the rest of Big Tech
Google DeepMind: 78%. Well above the rest of Big Tech
Anthropic: 80%. Standout, industry-wide!
Consistent with SignalFire’s 2025 finding, OpenAI 2-year retention was 67% (FAANG-level) versus Anthropic (80%), and DeepMind (78%).
2. Harder for graduates & interns to get hired
It’s well known that it’s getting harder to be hired as an early-career engineer, and new data underlines this.
Intern intakes down since 2022
Live Data Technologies looked at software engineer vs engineering intern hiring trends at 30-80 US-based tech companies, pinned to 2019 hiring numbers (100% being that year’s total number of hires). The spread is wide because Live Data Technologies selects the top few dozen companies that meet their criteria for a “large public tech company” in their database.
The findings:
Intern hiring is falling, but not software engineering recruitment. Source: Live Data Technologies
Zooming into intern hiring, here’s a visualization of it as a percentage of all appointments:
Tech companies are hiring fewer interns. Source: Live Data Technologies
Alex Hamilton, analyst at Live Data Technologies, says:
“We’ve seen overall software engineering hiring start to come back since the 2023 tough market. However, intern intake just kept falling alongside it, which isn’t what you’d normally expect.
Historically, intern programmes have tended to bounce back pretty quickly once companies start hiring again. That hasn’t happened this time, and 2024 and 2025 are the first years in the series where the two lines are moving in opposite directions.
Where you do see companies holding intern intake steady or growing it, it’s almost always a reflection of where they are as a business, be that earlier-stage or faster-growing companies, rather than any kind of broader market recovery”.
Graduate jobs trending down
Anecdotally, we hear new grads continue to have a hard time finding a position. Our new recruitment data on major US tech companies confirms it:
Share of new grad recruitment at 28 large US tech companies. Source: Live Data Technologies
“New grads” in this data are software engineers who graduated less than a year before getting a job as a software engineer. In 2025, just one in 10 engineering hires at larger companies were recent grads, down from nearly three in 10 in 2023.
Pedigree matters more for new grads
We looked closely at the places from where new graduate software engineers are joining US-based tech companies, and found the share of successful candidates from “elite” universities is growing:
Source: Live Data Technologies
By “elite” universities, we mean one of the top 20 US colleges for computer science, such as MIT, Stanford, Carnegie Mellon, UC Berkeley, Harvard, Caltech, Georgia Tech, and Cornell.
Obviously, the influence of these places’ reputations is not a new thing, it’s what makes them “elite” universities, after all. But with new grad hiring down across tech, even graduates from these universities can expect fewer opportunities than before.
Even so, the pedigree that comes from graduating from a well-known university, or doing an internship at a well-known company, becomes ever more significant as the job market tightens.
3. Mobile and frontend demand drops, AI & FDE surges
Here’s interesting data showing the shifting prevalence of job titles on sites like LinkedIn over time:
How engineering titles changed in the last four years. Source: SignalFire
Some takeaways:
AI engineering’s on fire. This is not surprising and is evident throughout our study.
Forward Deployed Engineers (FDE) are growing rapidly. We covered the sudden demand for FDEs in 2025, and this year we’re seeing the FDE role heat up again.
Modest increase in sales engineers: Sales engineers help close large, B2B-type, deals, and are typical at companies selling to enterprises. The rise in prevalence of this position suggests more companies are targeting enterprise-scale clients. Also, my sense is that FDEs can operate like sales engineers.
There are fewer native mobile engineers. In 2022, I observed a drop in demand for native iOS and Android engineers. Cross-platform frameworks being more capable today may contribute to fewer places investing in native applications, and a fall in demand for this discipline overall. Is the “golden age” of native mobile development over, with its standalone native iOS, native Android, and web teams for a single product?
Frontend-only engineers are disappearing. This is one of the most interesting trends in the data. I’ve observed full-stack engineers become the norm at many places, who can do both frontend and backend development. Especially with AI, there is no reason a proficient frontend engineer should not work on backend as well, so, I expect “pure” frontend engineers will be employed only in larger companies, where demand exists for things like building a design system. We cover more on this topic in the deepdive, Design systems for software engineers.
4. AI engineering comp > software engineering comp
One poorly-kept secret in tech is that although software engineering compensation is very good at Big Tech and top startups, it’s superior for AI engineering jobs at the same places – and even better at leading AI labs:
Scheduling update: this week, there will be a podcast episode on Wednesday and no The Pulse on Thursday.
I’m in Budapest, Hungary, this week, for Craft Conference, where I’ll be giving a keynote presentation alongside other speakers, including software engineering legend Kent Beck, who’s been on the podcast, Hillel Wayne, a formal methods expert and the author of ‘Logic for Programmers’, and Titus Winters, lead author of Software Engineering at Google.
The title of my keynote is “Slow down to speed up”, and I’ve been thinking about this topic a lot recently. Here are some things I’ve been seeing that I feel are relevant…
AI coding tools now used by pretty much all software engineers – that’s fast!
The Pulse is a series covering events, insights, and trends within Big Tech and startups. Notice an interesting event or trend? Hit reply and share it with me.
Today, we cover:
New trend? ROI questions for AI investments. I talked with engineering leaders at mid-sized and large companies, where spending on AI agents is being dampened via per-engineer mont…
Listen and watch now on YouTube, Spotify, and Apple. See the episode transcript at the top of this page, and timestamps for the episode at the bottom.
Brought to You by
• Antithesis – if you’re using agentic workflows, you need to be extremely clear about what you’re building and how your system should behave. Antithesis brings specification and verification together, making your agents faster, smarter, and safer. And when you’re using Antithesis, you’ll have greater clarity about your code as well. Learn more.
•WorkOS – The fastest AI-native teams have to slow down for the hard problems — WorkOS makes sure auth, for your app and your agents, is never one of them.
• turbopuffer – a search engine that companies like Cursor, Notion, and Linear use to index and retrieve every byte of context for their AI agents. It’s ridiculously scalable, built on object storage, with smart caching on NVMe SSDs so it’s very fast. It also offers many different search indexes and tools: check it out.
In this episode
OpenCode is one of the fastest-growing AI developer tools around, surging in just a few months from roughly 650,000 monthly active users to nearly 8 million, and almost 1M daily active users.
In this episode of The Pragmatic Engineer Podcast, we meet Dax Raad, co-founder of OpenCode, for a discussion about the gaps in developer tooling that led him to build OpenCode, the advantages of open source, and why taste and engineering judgment matter even more as AI becomes a core part of software development.
We also cover how OpenCode turned Anthropic’s blocking of integration with Claude Code into a massive growth lever by partnering with OpenAI and other model providers, why GPU demand is becoming a bottleneck everywhere, how come AI coding tools don’t automatically mean engineering teams move faster, and also why Dax is personally skeptical about predictions for the future of engineering and work, in general.
I found this conversation especially interesting because Dax displays a healthy skepticism toward the benefits of AI, even while building one of the most popular AI coding harnesses.
My observations from the conversation with Dax
Here are 14 of my most interesting takeaways from talking with Dax:
1. AI makes coding easier, but the hard parts of the job don’t vanish. Dax remarks that a lot of the job has become objectively easier with AI, but then follows up with a simple question: why does it feel like he is still having to think as hard as he ever did?
2. Thinking upfront beats building prototypes and seeing what sticks. This is especially true in the period before a product-market fit is found, Dax says. AI doesn’t help much in this early phase because the problem is figuring out what to build, not how fast you can build it, he says. Therefore, thinking hard about the right direction for development beats taking unfocused swings at different ideas.
3. Shipping 10x more features is a recipe for a Frankenstein-like product. It’s tempting to one-to-one prompt an agent for every user’s complaint or competitor’s feature. But the more features are jammed into a product, the worse it tends to become. Also, don’t forget that every shipped feature will need to be supported for as long as it’s part of the product!
4. No AI-native coding agent company is “winning” by being better with AI. Dax says that none of OpenCode’s competitors are crushing them, and that nobody is using AI so well that others cannot compete.
5. For OpenCode, product positioning beats speed of execution. A massive reason for OpenCode becoming the most popular open source AI coding harness is that they noticed no coding agent had successfully claimed the open source category. Dax was wondering why not, given that every market-leading dev tool across the industry is open source. So, he and the team focused on positioning and it paid off handsomely. He summarizes: “Get positioning right and the world just keeps handing you wins you didn’t expect.”
6. OpenCode’s “inverted” strategy: start with a good-enough product, then optimize. Dax admits their harness wasn’t ideal during OpenCode’s first five months, but it was still good enough. “Once we won enough market share, we went back and tried to make our harness good and smart.”
7. Most software engineers profit from AI as time gained, not increased output — unless you change incentives! Dax says the natural way for software engineers to “cash out” their AI tooling gains is with time savings, by doing the same work as before, but faster. Until compensation and motivation structures change, most teams should expect output to stay flat while engineers go home earlier. There’s nothing wrong with this, but AI vendors sell a different outcome to CFOs: increased output.
8. Motivated engineers who care about quality get buried by slop PRs from devs who don’t care. Dax has hired people from companies where they were one of the few who still cared about quality. In contrast, former colleagues just pumped out AI-generated code and focused on getting their tasks done, ignorant of the decreasing quality of code. Motivated devs feel they are drowning in garbage code and tech debt, and getting burnt out by trying to clean it up. Dax calls this an engineering leadership problem that most companies don’t notice.
9. AI code generation mutes the “guilt” of doing the wrong thing, but this builds up tech debt. Pre-AI, writing a hack felt bad, the second time it felt really bad, and by the third time you’d often just refactor in order to fix up the code. Now, the agent hides the hack, which skews devs’ judgment and results in less tech debt being cleaned up.
10. Dealing with tech debt is easier than ever, and teams should do more of it. Agents make refactoring across a codebase cheap: for example, ask an agent to implement a new pattern everywhere across the codebase. It’s very easy and cheap to clear up tech debt, today. So, do more of it!
11. AI has not really changed the thinking / doing ratio for Dax. “Pre-AI, I would spend 95% of my energy thinking about what to do and 5% on doing it. Now I spend 96% of my time thinking, and 4% on actually doing it. So, it’s like a 20% improvement [from 5% doing to 4% doing], but day to day, it feels as hard as ever.”
12. Confident predictions about AI are often forms of self-reassurance. A post went viral on X claiming that 24-29 year-old engineers will dominate in the future, which was written by – you can guess – someone in that exact age bracket. Dax says he sees this pattern a lot and frames such posts in terms of the author making themself feel better: “Someone like me has all the advantages. Someone unlike me has all the disadvantages”. Dax says he’s uninterested in predictions and just focuses on the next task, and the next day.
13. Old “enterprise” patterns are coming back in fashion for writing quality software, as agents are the new junior engineers. Dax says that things like domain-driven design and verbose design patterns went out of style over the past two decades because they’re tedious to type out. But they are actually very useful when there are junior devs on the team – or when there are agents that need strong guardrails. Dax is already using more such “old school” patterns.
14. The future-proof tech career: solid software engineering + deep industry expertise. Dax reckons engineers undervalue how easily they can become industry insiders compared to people who only focus on engineering, but never become an expert in one business area, as they go.
The Pragmatic Engineer deepdives relevant for this episode
Last year, I described the tech jobs market as “weird”, based on reports from both job seekers and hiring managers. In this deepdive, we dig into what – if anything – has changed in 2026.
A year ago, most engineers found it harder to get responses to job applications, while hiring managers found it harder to hire than before. We’ve now spent two months gathering fresh, never-before-shared data from a range of sources to find out if that paradoxical situation still exists or not.
We collected the data with software engineer Jessica Salmon – who’s joined the team as a tech industry analyst. A big thank you to partner teams who shared exclusive details for this deepdive:
TrueUp: a platform that scans every open job in Big Tech, top startups, and scaleups, typically paying in the top two tiers of the trimodal software engineering compensation model. Thanks, Amit Taylor.
Workforce.ai, built by Live Data Technologies, which monitors 1M+ job changes and 300M+ employment validations each month across companies, roles, levels, functions, industries, and locations. Special thanks to Alex Hamilton for his input.
Today, we cover:
Software engineering recruitment: trending up, mostly. More software engineering job postings in the UK and the US, and a decline in Germany and France. “Top” tech companies are hiring 20% more vs a year ago.
Big Tech and publicly-traded companies. Meta went on a monster hiring spree for the last two years until layoffs, last week. Microsoft and Amazon were flat, while Google and Apple consistently hired devs. Stripe, Shopify, and Atlassian all hired more than Big Tech.
Who’s hiring the most software engineers? Apple, Amazon, and IBM are the top 3 by number of positions listed, while Meta dropped off the top 20 with layoffs there. The fastest-growing companies seem to be in fintech, observability, and security.
AI engineering: explosive demand. Most tech companies seem to be prioritizing AI engineering recruitment over software engineers. Observability companies appear to be hiring fastest.
Who’s hiring the most AI engineers? Apple, Google, and TikTok have the most openings, and many larger tech companies have 50-100% more AI engineering job listings than a year ago.
Is AI engineering replacing software engineering hiring? The data doesn’t say, but are the basics of AI engineering becoming a baseline skill for software engineering job candidates?
TrueUp tracks open positions at top-paying companies, which are usually US-based. Among this group, recruitment of software engineers has been steadily increasing since March 2023:
“Top” startups keep hiring more devs. Source: TrueUp
US growth, but less in Canada and Europe
Let’s take a look at broader industry trends via software developer jobs listed on Indeed.com, the world’s largest job aggregator site. As a “jobs aggregator”, Indeed not only displays paid-for ads but also crawls many other career sites and lists the vacancies.
Looking at trends over the last five years, the number of software engineering jobs listed is still lower than in May 2021:
Dev job listings in the US, 2021-2026. Source: FRED / Indeed
Obviously, 2021 was the pandemic which created a commercial boom for the tech industry, so it’s not exactly an ideal comparison. Zooming into the last twelve months shows encouraging growth signs:
Dev job listings in the last five years vs the past year. Source: FRED / Indeed
Outside of the US, let’s check out software engineering vacancy trends, per Indeed:
Software engineering listings over the past 12 months by country. Source: FRED / Indeed
In this list, the US and the UK are the only two countries where vacancies are up; Canada is flat, while Germany and France have seen declines. To me, it suggests US-headquartered companies are hiring more devs, mostly in the US and some in the UK, whereas European-headquartered companies are more cautious about recruitment.
The software engineering industry still grows
Let’s ask how much the software engineer population has grown or shrunk in the last seven years. Here are some numbers from profiles, as tracked by Workforce.ai:
Net growth and shrinkage for software engineer profiles. Source: Workforce.ai
Let’s zoom into this chart:
Recruitment shifts over time. Source: Workforce.ai
There are a few interesting details:
Hiring mostly occurs between the months of March and June, andthere’s very little net growth in the second half of the year. This makes sense as tech companies set annual headcount budgets at the beginning of the year and commence hiring from then, with most hires evidently made in the following months. Hiring budgets are usually spent by mid-year.
The industry seemingly shrank in 2023. That year, it was only in Q2 that more software engineers were hired than left their jobs. It was the worst period for software engineers in two decades.
…and also in 2024 and 2025 during Q3. Mass layoffs mostly happened between August and October, the charts show.
2. Big Tech and publicly-traded companies
Big Tech: modest jobs growth – but not at Meta
Looking at the two years since May 2024, of the five largest tech companies, only Meta grew headcount aggressively:
Meta hired while Microsoft and Amazon stayed more static. Source: Workforce.ai
In that time, Meta increased its headcount by nearly 20%, so perhaps its recent 10% layoffs could be considered as not a total surprise. As for other tech giants, their software engineering headcount also changed in the last two years:
Apple: +10%
Google: +5%
Microsoft: -1.1%
Amazon: -1.3%
Visualizing this:
Mixedsoftware engineering headcount growth across Big Tech. Source: Workforce.ai
Apple and Google seem the most “stable” places when it comes to growing the software engineering function; Apple has not had mass layoffs for decades. In contrast, Meta is the most volatile place to work; hiring devs quickly and then letting them go. Elsewhere, Amazon and Microsoft are slowly employing more software folks.
Meta’s hire-then-fire rollercoaster
Meta warrants a closer look, where morale is reportedly as low as it’s ever been right now, due to layoffs of 10% of staff, while thousands of software engineers have been reassigned to manual data labeling from previous product development or infra work. From 2004 until 2022, Meta never did mass layoffs, but in the past three years there have been three sizeable redundancy rounds (at the end of 2022, early 2024, and last week), with the most rapid hiring growth of any tech giant sandwiched in between:
Meta laid folks off in bulk, then hired them fastest among Big Techs. Source: Workforce.ai
Before 2022, Meta ranked with Google as one of the most stable places to work in tech. Safe to say, the company is currently the riskiest place to be in job-security terms – even if Mark Zuckerberg has said there will be no more mass layoffs this year.
A couple of years ago, larger tech companies were hiring even more than most of Big Tech. Software engineering headcount grew in the past two years at Shopify (+36%), Stripe (+29%), Atlassian (+23%), Snap (+15%) and Spotify (+6%).
Source: Workforce.ai
But that’s changed recently. In the past year, headcount growth has slowed at Stripe (+15%), Atlassian (+11%), Shopify (+6%), Snap (+2%), and Spotify (+1%),
Source: Workforce.ai
This data does not capture Atlassian letting go of 10% of staff this month, and Snap laying off 16% in April.
Among this group, Stripe stands out as a place that keeps hiring at a higher pace than nearly all of Big Tech. Atlassian and Shopify have grown their software engineering headcount faster than Google, Microsoft, and Amazon did in the past two years.
3. Who’s hiring the most software engineers?
So, which companies are hiring the most? Let’s look at this via open positions and growth comparisons.
Companies with the most open roles
“Top” tech companies with the largest number of software engineering openings:
Businesses with the most software engineering vacancies. Source: TrueUp
Compared to last year:
Companies with the most open positions, 2025 vs 2026. Source: TrueUp
Observations:
The top three are unchanged: It’s still Apple, IBM, and Amazon
New entrants to the top 20: Accenture (consulting), Tesla, Cadence (hardware), Hewlett Packard Enterprise (HPE), and SpaceX.
Dropouts: Meta and Oracle. Last year, Oracle was #4 on the list with 1,396 open software engineering roles, but the company announced up to 30,000 layoffs in March. Also no longer leading in jobs available are Speechify, NTT Data, Meta, and DXC Technology.
Big Tech companies hiring more than last year: Apple and Google, which has +62% more engineering roles advertised than last year.
Big companies hiring less vs last year: Meta, Oracle, and TikTok all have much fewer openings listed. For Meta and Oracle, there’s little surprise given recent layoffs. TikTok was in US regulatory limbo until January, when a new TikTok USDS joint venture was established.
Hardware companies hiring more software talent: Micron, Qualcomm, and AMD all have considerably more software engineering openings than last year.
Where are the “top” software engineering jobs?
Most of these jobs are in the US, just as most companies leading in recruitment numbers are US-headquartered. Other leading locations for jobs are India, the UK, and Canada:
Numbers and locations of software engineering jobs listed by leading tech companies. Source: TrueUp
Fastest-growing: fintech and security
Then there are large companies where recruitment has been among the fastest anywhere in software engineering:
Companies which hired software engineers rapidly in the last two years
Software engineering headcount growth at some companies was significant over the past two years:
Ramp (fintech): +94%
Wiz (security): +84%
Datadog (observability): +68%
Rippling (fintech): +55%
Figma (design tooling): +41%
Netflix (streaming): +37%
Of this group, Datadog, Figma, and Netflix are publicly traded, and the largest by headcount:
Datadog: AI agents are driving demand for observability through the roof, and Datadog is the leader of the pack. There’s demand to expand their infra and offerings. AI companies are also customers: OpenAI famously – or infamously! – spent around $170M on Datadog in 2025.
Figma: the design tooling company went public in 2025 and is heavily investing in products related to AI, such as Figma AI.
Netflix: the streaming behemoth is transitioning from “just” being a video streamer to becoming a broader entertainment platform, doing live events, advertising, gaming, and more. We did a podcast with Netflix CTO, Elizabeth Stone, in 2025 about Netflix’s engineering culture.
4. AI engineering: explosive demand
AI engineering demand is only going in one direction: upwards, at a fierce tick. Last September, our previous State of the Tech Job Market report found that AI Engineering was the hottest segment in tech for job listings growth. Today, the trend seems to continue:
The Pulse is a series covering events, insights, and trends within Big Tech and startups. Notice an interesting event or trend? Hit reply and share it with me.
Today, we cover:
Antigravity 2.0 takes the ‘IDE’ out of its new IDE. Feedback about the redesigned IDE is overwhelmingly negative due to bugs, poor UX & model support, and eating through Gemini token quotas. Also: a clue that Antigravity’s own devs use other tools for their work?
Why is Google’s product ecosystem chaotic? The range of products on display at the Google I/O conference made a messy, incoherent impression. But Google’s “let a thousand flowers bloom” approach might be giving the search giant an underrated advantage in the AI race that no other Big Tech giant has.
Meta cuts 8,000 jobs. Morale is very low inside the social media giant as thousands lose their jobs, just as revenue and profits hit record levels. Meanwhile, those assigned to dull data labeling work are spared the axe.
Industry pulse. Anthropic pays $15B/year for SpaceX compute, SpaceX’s financials and IPO filing, more woes for GitHub, court dismisses Elon Musk’s “hypocritical” OpenAI lawsuit, and Spain may stop blocking its internet during La Liga football games.
How to get a job at a frontier lab in 2026. A Distinguished Engineer at Google recommends focusing on developing particular skills
1. Antigravity 2.0 takes the ‘IDE’ out of its new IDE
Listen and watch now on YouTube, Spotify, and Apple. See the episode transcript at the top of this page, and timestamps for the episode at the bottom.
Brought to You by
• Antithesis – if you write Rust code, check out Hegel-Rust: a free, open-source property-based testing library for Rust, built by the team behind Hypothesis. It’s now maintained by Antithesis. If you try Hegel and like it, your Hegel tests will run in Antithesis as written, as well.
• Sentry – application monitoring software built by developers, for developers. I’ve used Sentry for 10 years now, starting back at Uber. It shows you the full context on issues: stack traces, user actions, environment details, and more. A new, recent feature: Seer, their debugging agent — I like it! Check out Sentry.
• Craft Conference: meet myself, Kent Beck, Hillel Wayne and other standout speakers on 4 June, in Budapest, Hungary, at the conference dedicated to the art and science of software delivery craft. See details.
In this episode
Rust is one of the most admired programming languages around – and also one of the hardest to learn. What makes developers stick with it?
In this episode of The Pragmatic Engineer Podcast, I sit down with Alice Ryhl, a software engineer on Google’s Android Rust team, and a core maintainer of Tokio, which is the most widely-used async runtime in Rust.
We discuss what makes Rust different from other languages like TypeScript, Go, and C++, and why so many developers say that “once it compiles, it works.” We go deep into memory safety, ownership, borrowing, unsafe Rust, and Cargo.
We also cover how Rust is governed by RFCs, feature flags, its six-week release cycle, how engineers get paid to work on the language, and also look into how Rust’s use inside the Linux kernel is progressing.
My observations from the conversation with Alice
Here are 12 of my most interesting takeaways from talking with Alice:
1. Open source contributions can open career doors. Alice landed her Google job not by sending in an application, but by spending years answering questions on Rust forums, and contributing to documentation and code. She also became a maintainer of Tokio while a college student. One day, an email arrived in her inbox, asking: “do you want to work on the Android Rust team?”
2. Reliability is the backend pitch for choosing Rust over TypeScript. Alice is adamant that Rust is a backend language and not a TypeScript replacement on the frontend. Rust’s design for minimizing errors and maximizing reliability can make it a better choice than TypeScript on the backend.
3. Rust over C++ for development is a strong choice for avoiding a host of security vulnerabilities. In C++, a trivial off-by-one error in an array can become a massive security vulnerability. In contrast, Rust’s memory safety eliminates an entire class of such bugs, unless you are brave – or foolhardy – enough to use an “unsafe” keyword, that is!
4. Rust was designed to turn implicit failures into compile errors. Where other languages allow you to forget something, Rust makes an omission into a compilation error for things like null checks, uninitialized variables, or error propagation with the ‘?’ character. If you mess something up, it’s almost certain your program will not compile. If it does, at the very least you should see a lint warning. We previously covered how Andrey Breslav, creator of Kotlin, purposely made null safety an important part of Kotlin.
5. The hardest part of learning Rust is not syntax, but data structure design. Alice observes that newcomers reflexively build cyclic object graphs, like a Book object referencing Page objects that refer back to the Book. Such cyclic graphs are possible in Rust, but its ownership model makes this hard, meaning that Rust novices end up battling the compiler. Obvious solutions are to use structs and understand how ownership works in Rust.
6. Refactoring in Rust is safe and easy, thanks to the compiler. Alice: “I change a return type or struct field, then just fix the compiler errors until the compiler stops shouting. And then once I’ve done that, I’ve updated every place I need to update.” Rust’s focus on correctness makes refactoring it more straightforward than dynamically-typed languages and Java-style typed ones are to refactor.
7. Rust may be optimal for AI agents because of the compiler’s high-quality feedback loop. Alice’s refactoring trick of just doing what the compiler says also applies to agents: they can talk to the compiler, be told what to fix, and iterate. Combined with Rust blocking entire bug classes by design, this makes it one of the better languages for agent-generated code.
8. “Editions” allow Rust to make breaking changes without ‘breaking’ anyone’s code. Rust editions (2015, 2018, 2021, 2024) can be mixed freely across crates. A library on the 2021 edition works seamlessly with a binary on the 2024 edition. This is how Rust evolves syntax (like adding async/await as keywords) without forcing an ecosystem-wide migration.
9. Rust’s governance precludes a “benevolent dictator for life”. Unlike with Python and Linux, teams in Rust self-organize and delegate to each other. Tough questions are hashed out at in-person events like ‘Rust All Hands’. It’s a good illustration that open source projects can thrive across different structures.
10. Rust in the Linux kernel has graduated from “experimental.” At December 2025’s Linux Kernel Maintainer Summit, the kernel community agreed Rust is no longer experimental. Combined with US Department of Defense regulations pushing agencies away from non-memory-safe languages, this means we should see more Rust in the Linux kernel and everywhere else, too.
11. AI code review may matter more than AI code generation in safety-critical codebases. The kernel community is experimenting with AI bots that review mailing-list patches. Maintainers reportedly find them impressive, especially for kernel code; an area where quality and reliability has always been more important than quantity. It’s interesting that AI might be helpful as an extra quality gate.
12. Risk of AI-assisted Rust: false fluency. Since Rust’s compiler is so strict, code that compiles can be assumed to be correct. However, Alice describes AI agents adding Rust versions of C build flags with no purpose! She also cautions that junior engineers using AI to learn Rust run the risk of not understanding why the compiler accepts the code they produce.
The Pragmatic Engineer deepdives relevant for this episode
Earlier this year, we asked The Pragmatic Engineer subscribers about the AI tools you use, how you use them, and, crucially, what you think of them. We received more than 900 responses, and with this article we conclude our analysis of that data, covering:
Tradeoffs of AI tooling. Positive and negative sentiments, like how AI tools often mean less time spent on tedious, repetitive work, but that it often leads to unrealistic business expectations.
Adopting AI at scale is hard. Companies are struggling to achieve adoption that feels productive at the team and org levels. Our survey finds the benefits of AI heavily depend on the engineering culture that was in place before.
Impact on codebase quality. Codebase quality seems to be decreasing, but management at most places does not care. Meanwhile, maintenance duty is falling upon a shrinking number of engineers who still understand increasingly complex codebases.
Less experienced engineers and AI. For these folks, AI seems to be less helpful and they rack up higher AI token bills. Maybe they need more space to learn, mentorship, and support.
AI tooling ‘addiction’. Using AI agents “feels like a slot machine” encouraging “just one more prompt”-type behavior, while some folks think that the pricing of plans is built in a way to “lure” them to prompt more and more.
Changes since 2024. Fewer devs are negative about AI, but there’s not all that much more positivity. The models have become much higher quality, and better tooling improves trust.
Where are we headed? The concept of code ownership seems to be eroding, and collaboration within teams becomes less important.
Previously in this series, we covered:
AI tooling for software engineers in 2026: a detailed summary of survey responses, covering the most-used AI tools, trends, AI agent usage, company size and usage, and tools engineers love.
What can be said about the impact of AI tooling on engineers this year? Well, based on the responses that readers sent in to our survey, there are some common patterns:
Code and output tradeoffs
Productivity tradeoffs
Research published two weeks ago (5 May) by Microsoft claims AI expands the pool of people who can do high-value work. Our survey found similar, while MS’s findings are based on Microsoft 365 Copilot chat usage.
“AI used to do more high-value work” Source: Microsoft
Obviously, Microsoft has an interest in showing the benefits of its AI tools, but in this specific area, it’s telling that both studies agree AI does allow devs and non-devs to expand the type of work they do.
Software engineering tradeoffs
With AI tools, their ‘mileage may vary’ among individuals. For example, some respondents told us they can spend much more time in a “flow state” thanks to AI tools, as they don’t have to wait for input from peers, can keep unblocking themselves, and have fewer interruptions.
But others say the opposite: that because they can start so many more tasks in parallel with AI tools, they keep context switching which knocks them out of a flow state!
The positives and negatives of these tools seem dependent on the environment respondents work in, individuals’ personality traits, and where users are on the AI learning curve.
2. Adopting AI at scale is hard
One pattern in the responses is that adopting AI at company-scale remains challenging, including:
Costs: a growing concern covered in depth in Part 1
Usage: getting people to use AI tools continuously is not always straightforward
Onboarding and education: at larger companies, there needs to be support to help devs make the most of the tools
Reviewing AI-generated output: code review is a particular pain point
Integrating with internal systems: AI tools are more helpful when they are seamlessly integrated with internal systems, hence why many larger companies use in-house, deeply embedded coding agents
Adopting AI at company-level doesn’t lead to a magical fix for engineering problems, while the benefits of AI in an organizational sense seem to depend on what was in place before.
Case in point, AI seems to amplify pre-existing engineering culture. AI doesn’t change the underlying quality of an organization’s engineering culture. Teams with strong engineering practices get more positive benefits out of AI than those without. Teams that see benefits from AI tools already had:
Guardrails: testing and automation around the codebase and deployments
Documentation: they recorded their architectural decisions and engineering practices
A quality codebase: AI agents will replicate patterns already in a codebase
A few quotes on this from respondents to our survey:
“AI is an amplifier, not a fixer. Good software engineering practices get multiplied. So do the bad ones. Embedding this properly in teams is exciting and important”. – Staff+ engineer at a large company in Europe
“I feel like AI allows both faster prototyping and increased velocity on iterations to production software; it relies on existing best practices / project templates our team already have”. – Solutions Architect at a small company in the US
A workflow that makes one dev “10x” more productive may not work for another. This is another reason why rolling out AI tools doesn’t seem to magically make everyone more productive. A senior engineer working at a large company in Canada told us:
“It feels like AI workflows are very idiosyncratic in that some people derive (I hate this framing, but…) 10x more productivity benefit from them than other apparently equally clever, educated, and diligent developers. It feels like finding a workflow that clicks with your own habits and heuristics is more important than finding a global optimum for everyone”.
AI amplifies individuals differently, so the team impact is messy to figure out. A US-based principal engineer at a large company reflected on feeling disconnected from colleagues because of how they use AI differently:
“I use AI in what I think is probably a more sophisticated way than most of my colleagues, so there can be a disconnect between my work and theirs, which is not good news because I am “The Principal” on the team”.
“The tool that works for you” approach can lead to tooling chaos, even at a team level. While it’s empowering to allow devs to choose the AI tools they feel are the most helpful, over time it becomes chaotic when teams can choose their own tech stacks, and when at large companies there are dozens of different technologies. A staff+ engineer at a 200-person business in the Middle East wrote in their response:
“We’re still trying to figure out how to deal with tooling consistency on a team level. It’s one of our biggest struggles, but possibly more due to company structure than anything else. Everyone is using different tools with little coherence. It’s been rough.”
Some companies have briefly rolled back AI to deal with the negative effects first. From an engineering lead at a 10,000+ person company in Europe:
“Since the AI boom, the quality of technical writing and reasoning from senior engineers in my org has significantly deteriorated. There’s an overwhelming volume of low-quality work product that is generated entirely or in part by AI, which has made it very difficult to conduct meaningful review of RFCs or code. We’ve also seen costly production incidents caused by code written and/or approved by AI, and – while my employer initially bought heavily into the hype – we have now rolled back some of our AI tools to deal with the drop in quality.”
3. Impact on codebase quality
A concrete pattern in our survey data is that codebase quality is decreasing due to AI. The contributing factors are not surprising:
“AI slop”: more low-quality code generated, such as duplicated, verbose code, and poor abstractions
Too many code reviews, which means review quality slips
More bugs: due to faster code output and less strict reviews, more bugs sneak into codebases
One CTO at a European startup lists their negatives about increased AI usage:
“A lot of tiny bugs and low code quality if you are not careful, verify carefully, and have good structure and guardrails
AI agents generate too much and repetitive code, making systems harder to maintain
Developers lose understanding of the codebase and become numb to bad architecture and bad developer experience”
According to our survey, management often seems unfazed by decreasing quality, and instead focuses on the higher output. A principal DevOps engineer at a large European company said:
“In our company, we hand AI tools to inexperienced engineers who can’t distinguish good code from bad code and it’s falling on deaf ears in our leadership. They only seem to care about short to mid-term cost savings.”
The maintenance burden of AI-generated code is falling on the fewer engineers who understand and care. A staff engineer at a European company listed the problems that AI-generated code is causing:
“Drive by” contributions are up: many more occasional non-core-engineer contributors adding code but not sharing the maintenance burden
Contributing without adding guardrails: many engineers and most of engineering leadership are not using reasonable guardrails like tests
AI slop from folks who have nothing to do with the codebase: huge volume of slop incoming from people who don’t understand the codebase, but will commit and create PRs without fully understanding what they’re doing
Complexity is exploding: thanks to the above
The maintenance budget is falling upon fewer devs, while the task of refactoring bloated codebases and reducing complexity is left to those still sufficiently in touch with the codebase, thereby making the maintenance burden even worse.
But some leaders “get it.” A CEO at a 20-person company told us:
“While AI has made generating code ‘cheaper’, the monitoring and maintenance worry me; the things that have traditionally cost the most in software. We’re increasing the rate of shipping large amounts of code with less understanding and increasing the unpredictability, so how do we work the predictability back on top?”
There is industry pressure on companies to adopt AI tooling and impose its usage upon engineers, driven by a mix of factors:
Seeing actual benefits of AI and hearing that other teams and companies enjoy success with it
Fear of being left behind by competitors, or becoming less relevant
Anxiety about investor interest if a company is seen as not adopting the latest AI tools.
This often leads to:
Top-down mandates to use AI
Expectation of headcount reduction, with smaller teams doing the same amount or more
Management treating AI productivity gains as a baseline rather than a bonus.
One staff engineer at a 10,000-person US company explained it like this:
“AI is part of almost every work conversation. The entire company expects it to increase productivity and reduce the need to hire people. I keep trying to get better at using it and trying to make it more reliable so I can do more. I do worry about the quality of the work and atrophy of certain skills. It’s unclear to me if those skills even matter anymore.”
Pushing AI adoption blindly triggers red flags. Respondents shared what makes them worry about things going south in their workplaces:
Focus on tracking AI usage, but not the quality of the output. This will likely lead to product regressions and unhappy customers
Pushing for universal adoption. Some companies target 50%, 80%, or 100% AI usage for certain tasks, seemingly blind to how some targets can worsen the quality of output, or simply create wasteful usage. See the trend of tokenmaxxing.
A focus on velocity, but without recognition of quality work. Expecting more velocity and output seems to be the baseline, and there is no recognition for work truly well done.
The “move fast and break things” mantra famously championed by Facebook seems widespread across the industry with AI tools. A senior manager working at a large, European-headquartered company told us:
“I see a trend: move fast and break things, and end up breaking things too often. We have to learn to focus on testing and resiliency a lot more, as with AI-driven development we introduce more bugs than before. But the velocity gain is bigger for now”.
Output over quality is leading to the death of code review at some places. As a lead engineer working at a small company summarized:
“We’re at the death of code review. I used to do very deep code reviews where I’d take the time to understand the architecture and organization and provide feedback on maintainability and efficiency. I have no motivation in spending that time to review a giant PR where it’s clear that even the original author didn’t bother to do that”.
4. Less experienced engineers and AI
The first generation of software engineers who have never developed without the help of AI are now entering the industry. Here is a response from a young engineer working at a startup as an intern:
“I have never worked as a developer without AI. Writing this scares me a bit, actually, but it’s the truth!”
But this will be the new reality for those joining the industry. So, what needs to happen to help a new generation of “AI-native” grad engineers grow professionally?
AI is an amplifier which could amplify the lack of experience. A staff engineer in the US at a large company told us:
“Agentic AI is a fascinating mirror. It can code as well as the user who drives it. If that user is a junior engineer, now you have a faster junior engineer. If the user is a staff engineer, now you have a faster staff engineer.
What agentic AI doesn’t do is magically convert a junior engineer into a staff engineer, because the user driving it still needs enough experience to know what a good solution looks like”.
A junior engineer in Australia shares their experience of how frustrating working with AI tools is:
“I think AI agents are great for vibe coding or prototypes where the code quality and functionality doesn’t matter that much. I think it’s also useful for senior engineers who know what they’re doing.
For junior engineers like myself, these AI tools are stressful to use. I don’t have the experience or knowledge to tell AI exactly what to do or quickly confirm its output, so I spend a lot of time on just triple checking and redoing stuff. I’m overall frustrated, but I’m trying to embrace it as we’ve been asked to by the company”.
Less experienced engineers seem to use more AI tokens and rack up higher bills. Several respondents observed this: director-level folks noted that junior engineers are in the top-spender category in their orgs, and it is junior devs who spend tokens on unproductive use cases.
There should be more space for junior folks to grow because they use AI more, one staff engineer respondent said:
“Companies need to give some breathing room to Junior engineers and help them learn and acquire knowledge using AI tools as a booster and not as a replacement”.
Junior folks seem to be delegated fewer opportunities that could help them grow. This is because senior people can turn to AI for tasks, including those which they would have previously delegated to an intern or new grad. A few responses mention this:
“AI allows me to have work done that I would usually delegate to a junior or pay a SaaS for; e.g., writing drafts, summarizing the news. “ DevSecOps lead at a small company, Europe
“I’ve begun to automate any repetitive task that we previously relied on juniors and offshore contractors for.” - Engineering manager, at a large company, US
“I no longer have to delegate work by writing a very long document and briefing a junior engineer.” - Principal engineer, large company, Europe
Why not consider mentoring junior devs in your organization? It’s clear that less experienced engineers are having a rocky start to their careers, so delegating stuff to them instead of to AI could be of high value for newer generations of talent.
5. AI tooling ‘addiction’
It seems that the rapid feedback loops of AI-assisted development create addictive tendencies, and there’s a noteworthy presence of “addiction lingo” in some responses to our survey:
The Pulse is a series covering events, insights, and trends within Big Tech and startups. Notice an interesting event or trend? Hit reply and share it with me.
Today, we cover:
Forward deployed engineering heats up again. Massive demand for the role at Google, OpenAI, and Anthropic. The latest version of the FDE role looks like the consultant / solution a…
Listen and watch now on YouTube, Spotify, and Apple. See the episode transcript at the top of this page, and timestamps for the episode at the bottom.
Brought to You by
• Antithesis – verify your system’s correctness in the development loop. Build, extend and deploy mission-critical systems: without human review or traditional integration tests, all while avoiding embarrassing outages. Antithesis goes far beyond code review and runs your complete system, exhaustively analyzing its behavior, and exposes bugs as quickly as agents introduce them. Learn more.
• WorkOS – Anders has spent decades thinking in programming languages — WorkOS speaks the same language when it comes to enterprise infrastructure: SSO, SCIM, RBAC, and more, built right so you never have to. See how.
• turbopuffer – a ridiculously scalable, fast and cheap vector and full-text search engine. Cursor moved to turbopuffer after their existing vector database couldn’t keep up with the number of codebases they were adding. This move cut their semantic search costs by 95%, and they have so many good things to say about turbopuffer. Check it out.
In this episode
Anders Hejlsberg is a living legend and one of the most influential programming language designers of all time. He created Turbo Pascal, Delphi, C#, and also TypeScript. As well as that, he spent nearly a decade at the pioneering dev tools company, Borland, and is now in his 30th year of working at Microsoft, where he’s a Technical Fellow.
In this episode, we discuss what it takes to build programming languages that developers love to use, and trace his career from writing his first compiler to creating Turbo Pascal and Delphi, and helping to pioneer modern software development through C# and TypeScript.
Anders details how C# was designed by a small group of experienced language designers who met a few hours each week, and he explains why tooling was just as important as the language for TypeScript’s success, and what he has learned from building languages which stay relevant for decades.
We also look into how Anders uses AI today, which language features suit AI-assisted development, and what he thinks is changing in the craft of software engineering as developers move further away from writing code line by line.
It was special for me as well to talk with Anders: because my first-ever programming language was Turbo Pascal, and my first paying job was at a C# shop, back in the day. And I write most of my backend services using TypeScript, today.
My observations from the conversation with Anders
Here are 14 of my most interesting takeaways from talking with Anders:
1. The first computers had zero abstractions on top of the hardware. Anders started programming on an HP 2100 with 32K of memory and a paper tape boot loader. “Things were so simple. You could see all the way to the bottom. There was just no layering. It was right on top of the hardware,” he says. The past 50 years of computing have been a process of adding layers above the hardware.
2. Turbo Pascal won by being more than “just” a compiler. Anders also built an IDE to edit Turbo Pascal programs in, and a debugger to troubleshoot them with. In later languages which Anders designed, he always focused on the entire developer workflow, not just compilation.
3. “10x better for 1/10th of the price” is a proven winner. This is what Turbo Pascal did: it sold for $49.95 when competing compilers cost $500, and it was faster and more interactive than competitors’ products. Conveniently, the low price tag also killed off piracy
4. The first Turbo Pascal “debugger” was an elegant hack. The compiler printed the program counter address on a runtime error. Then you could re-run the compiler in a mode that stopped at that address, and the IDE would show which line was being syntactically processed at that point. There were no line maps or debuggers built for this debugging experience: Constraints force creativity!
5. C# might have not existed without a famous court case. Microsoft originally hired Anders to architect its Java tools (Visual J++), but the Sun versus Microsoft lawsuit (1997-2001) meant Microsoft could not build on top of Java, as the company that owned Java’s IP (Sun) sued MS for alleged unauthorized changes to the Java language. Microsoft realized it had to build a new language that combined VB’s productivity with C++’s power. This led to C# and .NET.
6. The original C# design team numbered only six. They held three meetings per week which lasted two hours each, during which they debated what to build. Anders believes that designing even large languages does not require a large team; it’s the right experience that matters most. In that group, this meant folks who had built languages before.
7. C# introduced the async/await pattern that many languages later ran with. Anders said this pattern spread to so many other languages because compilers can generate state machines that humans hate writing. Manual state machines require moving all stack states into objects and wrapping logic in a giant case statement. Devs generally loath doing this by hand, and async/await lets developers write sequential-looking code while the compiler does the painful rewrite behind the scenes.
8. TypeScript exists because Anders refused to build Script# for the Outlook.com team. Microsoft’s Outlook.com team asked Anders’ C# team to productize “Script#,” a language to cross-compile C# to JavaScript. Anders and the C# team pushed back, suggesting that a better approach was to fix JavaScript. Anders felt strongly that to be attractive to the best-of-breed developers in the JavaScript ecosystem, you want people to write JavaScript, and not another language like C#.
9. Open development on GitHub made TypeScript much better. TypeScript was open source from the beginning in 2012 on CodePlex, Microsoft’s open source platform. There was not much community activity there, and in 2014, the project moved to GitHub with its large, active community. “Open development” on GitHub is what Anders credits for making TypeScript as good as it has become.
10. The TypeScript compiler breaks many traditional practices. The compiler is built to support lazy evaluations, and deferred imports, and is functional by necessity. For example, with 500 files open, the compiler keeps abstract syntax trees (ASTs) cached for 499, and rebuilds just the one being edited. It only resolves the minimum types needed for the cursor’s current position.
11. Training data volume is what makes AI great at TypeScript and Python. Anders says the language best suited for AI is the one that AI has seen the most in its training set. How well AI agents work in a specific language largely depends on how much of that language exists on the internet. It has less to do with the design of a language.
12. But AI is limited for writing compilers – for now, at least. On Anders’ team, AI is limited in terms of seeing the “big picture”; for example, how types, symbols, binding, and parsing all relate. It’s because LLM training sets don’t contain much about compilers as yet.
13. Reviewing code could be the future of the craft. Anders predicts we’ll all be project managers in the future, managing armies of junior programmers, aka agents, which generate reams of code. Anders admits he is less interested in reviewing code, personally, but reckons code review could be made much more interesting; for example, AI generating commentary that guides reviewers through changes.
14. Designing a programming language is a 10-year play. As Anders puts it:
“Version one is great, but has all sorts of issues. You’ve got to do version two, but it’s not until version three that it really starts to be great. Then you’ve got to convince people to adopt it.”
The Pragmatic Engineer deepdives relevant for this episode
Before we start, some news: my tech compensation site focused on tech total compensation (TC) in Europe, TechPays has been acquired by Levels.fyi! TechPays was a project I’ve been building on the side with engineering manager Zsombor Erdődy-Nagy for a few years, and both of us are pleased that the site found a new and welcoming home. Read more.
Four decades ago, the writer of ‘The Mythical Man-Month’ (1975), drew on folklore about werewolves to publish a paper about the prospects of a so-called silver bullet for software development that would make professionals much more productive at their craft.
The Werewolf of Eschenbach, Germany, line engraving, 1685. This image appears in the “No Silver Bullets” chapter of Mythical Man-Month (1995)
Frederick P. Brooks published “No Silver Bullet – Essence and Accident in Software Engineering” in 1986, and as the title suggests, it is pessimistic about the existence of any silver bullets. The term refers to a super weapon capable of dropping otherwise near-unstoppable werewolves and other creepy supernatural beings in European folk tales.
Since its release, this paper might have become even better-known than Mythical Man-Month (MMM). In 1995, the second edition of that book included Brooks’ later essay as chapter 17, along with an additional chapter of reflections.
In this article, we look into whether the essay was correct in its disbelief in silver bullets, or whether any did indeed slay the beast of unproductivity for developers over the course of time. Also, how does AI agents generating so much code, as of today, challenge the entire premise – or not?
We cover:
“No silver bullets” – why has it held up? No single new technology or methodological breakthrough by itself introduced magnitudes-of-improvement to the areas that really matter in software engineering. Is that unusual?
Is SRE a silver bullet? Google’s Search team introduced the SRE discipline, and won orders-of-magnitude superior reliability to its competitors. But why only Google Search?
Was open source + GitHub a silent silver bullet? No development had a bigger impact on the wider tech industry than the open source wave since the 2010s. Has it been a silent silver bullet, an overlooked cause?
Could AI be a silver bullet? At first glance, AI generates 100x-or-more code output. But productivity, reliability, and simplicity improvements are a bit unimpressive – at least for now.
Brooks was a computer scientist who led IBM’s System/360 and OS/360 operating systems development, ‘The Mythical Man-Month’ was published in 1975. Last year, we did a deepdive into this engineering classic (Part 1, Part 2, Part 3, Part 4), delving into its predictions and legacy.
1. No silver bullets?
The paper delves into folklore for its motif, a ‘silver bullet,’ and uses it to pose the question of whether there would be any “silver bullets” on the horizon (in 1986) that could be similarly fatal to software engineering complexity. From the paper (emphasis mine:)
“Of all the monsters who fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest.
The familiar software project has something of this character (at least as seen by the non-technical manager), usually innocent and straightforward, but capable of becoming a monster of missed schedules, blown budgets, and flawed products. So, we hear desperate cries for a silver bullet, something to make software costs drop as rapidly as computer hardware costs do.
But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement in productivity, in reliability, in simplicity.
Skepticism is not pessimism, however. Although we see no startling breakthroughs, and indeed, believe such to be inconsistent with the nature of software, many encouraging innovations are under way. A disciplined, consistent effort to develop, propagate, and exploit them should indeed yield an order-of-magnitude improvement. There is no royal road, but there is a road.
The first step toward the management of disease was replacement of demon theories and humor theories by the germ theory. That very step, the beginning of hope, in itself dashed all hopes of magical solutions. It told workers that progress would be made stepwise, at great effort, and that a persistent, unremitting care would have to be paid to a discipline of cleanliness. So it is with software engineering today.”
In 1995, Brooks revisited his idea that silver bullets weren’t real in the software domain. From the Mythical Man-Month’s anniversary edition:
“No Silver Bullet” asserts and argues that no single software engineering development will produce an order-of-magnitude improvement in programming productivity within ten years (from the paper’s publication in 1986). We are now nine years into that decade, so it is timely to see how this prediction is holding up.
Whereas The Mythical Man-Month generated many citations but little argument, “No Silver Bullet” has occasioned rebuttal papers, letters to journal editors, and letters and essays that continue to this day.
Most of these attack the central argument that there is no magical solution, and my clear opinion that there cannot be one. Most agree with most of the arguments in “NSB,” but then go on to assert that there is indeed a silver bullet for the software beast, which the author has invented. As I reread the early responses today, I can’t help noticing that the nostrums pushed so vigorously in 1986 and 1987 have not had the dramatic effects claimed.”
Brooks re-concluded that there had been no technological breakthroughs of the type postulated in NSB.
But motivation can also have silver bullet-like effects and always has had, he foundvia more research into scientific evidence that motivation can boost productivity. In his own words:
“Since “NSB,” Bruce Blum has drawn my attention to the 1959 work of Herzberg, Mausner, and Sayderman.
They find that motivational factors can increase productivity. On the other hand, environmental and accidental factors, no matter how positive, cannot; but these factors can decrease productivity when negative. “NSB” argues that much software progress has been the removal of such negative factors: stunningly awkward machine languages, batch processing with long turnaround times, poor tools, and severe memory constraints.”
Today, it’s a long time since the mid-nineties; with the benefit of hindsight, were there any silver bullets flying between then and 2022, which fit the bill as slayers of unproductiveness? I suggest a few, below. If you can name other silver bullets since the launch of Windows 95, please do so in the comments!
Version control: (late 1990s.) CVS, Subversion, and later, Git. Version control allowed engineers to collaborate much more fluently, leading to more teamwork and – in some cases – less full-on solo labor.
IDEs: (early 2000s). Modern IDEs like Visual Studio, IntelliJS, and others make context-rich editing easy and fast. They also allow for faster, less error-prone refactoring and more efficient debugging.
CI/CD and automated testing: (mid-2000s). CI systems started to spread during the 2000s with the likes of CruiseControl (2000s) → Jenkins and SaaS CI solutions from the 2010s (e.g., Travis CI, CircleCI, GitLab CI, GitHub Actions).
Open source and package managers: (2010s). Open source has been around for decades, but GitHub’s rapid adoption made it easier to create and discover, coupled with package managers in the Node, Python, and other language ecosystems to build on top of open source solutions.
StackOverflow: (2010s). The popular programming Q&A site made it easier to get unstuck by finding solutions to common problems, with the capability to ask questions and get responses from the large user community within hours. By 2025, the site was pretty much dead.
Cloud: (early 2010s). AWS launched in 2006, then Azure and Google Cloud in 2008, and they went mainstream in the 2010s. Today, cloud is everywhere, and increasingly more infrastructure startups build on top of hyperscalers (the biggest public cloud platforms), such as Vercel / Netlify (platform-as-a-service), Supabase / Turbopuffer (databases) and others.
Platform teams & DevEx teams: (mid-2010s). Mid-sized and larger tech companies created dedicated platform teams to own infrastructure and internal platforms. In the 2020s, larger tech companies have created ‘Developer Experience’ teams to build better internal dev tools and workflows. We previously covered Uber’s program/platform split, and Uber’s developer experience evolution.
SRE: the Site Reliability Engineer (SRE) profession grew during the 2010s, much influenced by Google.
These technologies increased developer efficiency and productivity, but none by itself was a productivity accelerator in isolation.
Obviously, by 2022 the craft of building software had developed greatly since ‘No Silver Bullets’ came out; and was more efficient, faster, and more collaborative than ever. One highly anecdotal way to identify this is via the disappearance of cake from some tech workplaces. Back in the day, cake was distributed at work for major product milestones being hit: the shipping of a new product was often marked with awards and tasty baked treats – at least on teams building browsers, like the IE and Firefox teams.
But by the 2010s, shipping frequency had increased by so much and was an everyday, unremarkable occurrence at some places, according to Matt Brubeck, a former engineer on the Firefox team:
“Back when Firefox 2 was released (six years ago this week!), the Internet Explorer team started a friendly tradition of sending Mozilla a cake as congratulations. This continued for Firefox 3 and Firefox 4. After Firefox switched from major releases once or twice a year to incremental updates every six weeks, they sent us a cupcake for the next few updates instead. :)” Mozilla engineer, Matt Brubeck
Fruits of success: Cake for Mozilla Firefox team in 2006 after shipping Firefox 1
Today, Firefox ships a stable version about once a month, as does Chrome. In this context, marking each release with more cake could inadvertently cause some health issues on the team – too much cake, that is! From this September, Chrome will switch to shipping every two weeks.
Agile and Scrum is worth a mention; not as a technology, but a methodology: Scrum encourages teams to move in smaller cycles and deliver more frequently, via sprints that typically range from a week to a month. In the early 2000s, this methodology spread quickly and brought efficiency improvements to many tech companies. However, by the early 2020s, many startups and some of Big Tech had moved on, as covered in How Big Tech runs tech projects and the curious absence of Scrum:
“Scrum got in the way of shipping on a daily basis. The whole idea of Scrum revolves around Sprints, of committing to tasks at the beginning of the sprint, working on these during the sprint, and demoing what we did at the end.
The process felt unnatural and like it had been forced on a fast-moving web team. We soon moved to a more fluid way of working, taking the Kanban approach. We stopped caring about sprints, and dropped most rituals that come with Scrum. We just cared about knowing what we’re working on now, and what it was we’d get done next.”
Basically, Scrum worked and still does so for teams wanting to shorten shipping cadence from months to weeks. But for teams shipping daily, it often gets in the way.
One area that improved significantly has been the pace of shipping incremental software. In 1975, shipping software several times per day with elements like version control, CI/CD, feature flags and engineers being oncall, might have sounded far-fetched. Back then, software delivery was measured in months and years. In this way, we’ve perhaps made improvements overall in the regions of 10x to 100x over the years.
But that came via combinations of new tools like version control and CI/CD, new approaches & methodologies, and testing – and also from shifting constraints; for example, it’s now possible to revert backend changes rapidly, and code shipped in binaries can be controlled by feature flags in many cases.
Even so, improvements were mainly in iteration speed and not necessarily in the complexity of the software shipped. With all that progress, shipping complex and high-quality software still takes comparable time, often years, as 50 years ago. A prime example is the upcoming video game, Grand Theft Auto VI, probably by now the most highly-anticipated game ever, which is set to launch in November, after at least six years – and potentially 12 – of total development time:
Initial planning started in 2014 (12 years of development)
Development started in earnest in 2020 (circa six years of full-on development)
The studio, Rockstar, confirmed development was underway in February 2022 (at least 4.5 years of full development)
GTA VI: more ambitious but also slower
The video game development timeline is as long as it ever was, and even longer, as developers strive to meet players’ expectations on things like graphics, lighting, and physics. GTA 6 looks like being the most complex installment in the long-running series. So, perhaps there’s not been much change in software delivery timelines because when we have more capabilities to work with, the goals get more ambitious and the bar for “standout” software keeps rising.
2. Is SRE a silver bullet?
Brooks’s definition of a silver bullet:
“A single development, in either technology or management technique, which by itself promises even one order of magnitude improvement in productivity, in reliability, in simplicity.”
In simplicity and productivity terms, I struggle to name a single approach that delivered a 10x-or-more improvement by itself. But in the area of reliability, one company that has pioneered novel approaches since the 2000s is Google. Google.com is probably the single most reliable piece of internet software of all. In the last 15 years, Google Search has suffered a single outage, on 8 August 2022, which lasted around an hour. Otherwise, there have been no global outages (of course, there have been several for other Google services).
In 2003, Google created the ‘Site Reliability Engineering’ (SRE) role. SRE veteran, Dave O’Connor, shared with us:
“The fervent belief of Google’s founders was that speed and reliability mattered more than features. This belief was coupled with the understanding that we couldn’t achieve it traditionally, which made it an existential issue. The level of investment in building out all layers of the serving stack was a case of “because we can”, but also “because we have to, as nowhere else does what we need”.
There was never a question of whether traditional ‘ops’ would work at Google. We needed a specialized role, staffed by folks familiar with the problem space and engineering methods required to make it work.
In 2003, the SRE role was born. Ben Treynor Sloss had been tasked with building Google’s “production team” and in his own words, he built “what happens when you ask a software engineer to design an operations team.” This turned into the birth of the SRE function at Google. From the outset, SRE was staffed in varying measures by systems/operations experts and software engineers. A large part of the remit of the team was to build the tools and practices required to operate Google’s fleet.”
Over time, the rest of the industry caught on to SRE and DevOps. From our SRE deepdive:
“Eventually, other companies caught onto the scaling issues, especially the hyperscalers. Each had their own approach, but over time, the notion grew industry-wide that making things reliable was a real-life engineering discipline, not simply ‘ops’.
This step saw a number of terms coined to describe this engineering, including ‘DevOps’. At its core, this was the notion that the disciplines and practices of reliability engineering should be ingrained into the overall engineering organization. At places other than Google, this mostly took the form of combined developer/operations roles (i.e. “you build it, you run it”), which differed from Google’s implementation, but the practices were similar.
Around this time, Google started opening up about SRE, eventually publishing the first SRE book, and follow ups. Conferences such as USENIX SRECon, Devops Days, and other movements have solidified reliability engineering as a discipline that scales well beyond Google. Indeed, the company has become a consumer of many state-of-the-art developments.”
So, at Google Search, the SRE role could be described as a genuine silver bullet for the tech giant. The company’s obsession with reliability helped it build what is probably the most reliable public-facing service of all. On the assumption that SRE plays a significant role in the approach, I would feel comfortable with calling SRE a silver bullet for Google Search.
SRE, as a concept, is commonplace across Google, but the reliability of its other services is not so impressive. For example, Google Cloud has had many outages, and Gmail also goes down every now and then. I’m sure that without SRE, reliability would be worse, but in general, Google services’ availability these days is probably a magnitude higher than the availability of most online services in the 2000s.
Similarly, GitHub has an SRE role but the service is at zero nines of availability, partially explained by a 3.5x increase in load in two years. But in other ways, the zero nines is likely self-inflicted.
This makes me wonder if the existence of silver bullets depends greatly on teams and individual contexts. SRE seems like a good case to consider:
a “silver bullet” for Google Search
… but not for other Google services
… and definitely not for the broader industry
Could it be that when implemented in the right place, in the right way, and with the correct investment, then SRE – and an incredible focus on reliability – will yield a 10x-or-higher increase in reliability?
My hunch is that Google Search has such standout reliability not just because of SRE, but because Search might be the only organization in Google with reliability as a founding value, embedded in the team’s culture, with unmatched investments of time and money.
Google has published several books that explain their techniques and practices, but for other teams to get those results, they would need to invest similarly in reliability.
3. Was open source + GitHub a silent silver bullet?
Perhaps there’s a silver bullet which is easily missed: open source. In the first-ever Pragmatic Engineer Podcast episode, I asked software engineer Simon Willison what the biggest “productivity leaps” have been during his career. He named open source:
The Pulse is a series covering events, insights, and trends within Big Tech and startups. Notice an interesting event or trend? Hit reply and share it with me.
Today, we cover:
Did Anthropic turn hostile on devs because capacity was running low? Forthe past few weeks, Anthropic has continually upset devs with its “dumber” model, and by removing Claude Code access from some paid accounts. After securing lots of compute from SpaceX, could the reason have been to conceal capacity issues?
Amazon finally allows Claude Code and Codex usage. The online retail giant wanted to improve its own coding agent, Kiro, so banned other AI coding tools. But that ban is now lifted.
Meta forcefully assigns engineers to data labelling ahead of job cuts. In several teams, 20-40% of engineers are given menial, data labelling work. Could that actually boost people’s job security – for now?
New trend: small “AI-forward” teams. Meta and Amazon’s CEOs say teams of 5-10 devs do better work than teams of 50. There are important caveats: it’s unclear what they’ll do with the “excess,” and if it’s limited to “mechanical” work like rewrites.
Industry Pulse. Why Meta tracks employees’ computer activity, OpenAI starts to move off Datadog, Apple lets slip it uses Claude Code, GitHub → Xbox transfers at Microsoft, VS Code inserted “coathored by Copilot” even when Copilot did nothing, analysis of the Coinbase layoffs.
Before we start, last week I covered big pricing changes coming from GitHub, but it seems I underplayed how big they will be. Reader Julien has helpfully clarified the actual impact (thank you!)
The multipliers will be increased for Pro and Pro+ plans on annual renewal (roughly a ~3x increase on average)
With other plans (Pro, Pro+, Business, Enterprise) it’s more drastic; they will adopt API token-based pricing and drop request-based pricing.
This is indeed a massive change; GitHub has heavily subsidized its usage, relative to API billing, and this change will make pricing unpredictable as of 1 June – at least initially. As Julien put it:
“We are basically waiting to see how much we will be able to use our actual subscription with the new pricing 😇”
1. Did Anthropic turn hostile on devs because capacity was running low?
Connexion
