Showing posts with label team. Show all posts
Showing posts with label team. Show all posts

Why the CTO chair keeps emptying

Mike's Notes

This is the first part of an article by Gergely Orosz, available to read for free. The rest is for paid subscribers. The article was introduced in a recent issue of The Code.

I found this important for understanding what is happening in workplace culture at large SaaS/AI firms. Things to avoid at Ajabbi. For future reference.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > The Code
  • Home > Ajabbi Research > Library > Subscriptions > The Pragmatic Engineer
  • Home > Handbook > 

Last Updated

07/09/2026

Why the CTO chair keeps emptying

By: .
The Code: 24/08/2026

.

An exodus across Silicon Valley. Something is spooking the people who run engineering. Across startups and Big Tech, CTOs, VPEs, and heads of engineering are quitting high-status roles with nothing lined up. Veteran engineer Gergely Orosz says he's never seen this many top-tier leaders walk. In his latest deep dive, he spoke to nearly 20 on career breaks. Six in ten were already on their way out.

A range of reasons. From rapid AI adoption (or the lack of it) to long hours and burnout. Then there’s what Orosz calls “founder mode.” In smaller companies, founders are micromanaging engineering, turning VP and CTO roles into low-ROI gigs. Some leaders left to build their own startups; others were pushed out.

Across the board, these were the most consistent reasons:

  • The job got worse. Picture a founder celebrating a massive AI-generated PR while the CTO stares at the technical debt underneath. Flag the mess, and you become the office killjoy.
  • Equity looks like smoke. Leaders are trading salary for equity that feels like a gamble. Many CTOs now realize their options might never pay out due to VC payouts.
  • AI-native or bust. The best roles now want leaders who’ve actually led an AI transformation. If their current job can’t offer that, some are stepping back into IC roles rather than letting their skills go stale.
  • Teams are shrinking. Agents now handle work that once required entire teams, meaning fewer engineers and fewer layers of management.

It doesn’t stop at the top. When leaders walk, the ripple effect hits the entire team. If you're taking a leadership role, interview the company too: do founders want engineering to change, or just get cheaper? And if your job isn't giving you hands-on AI experience, get it elsewhere.

P.S. Our engineering team put together over 10 practical guides to help you kick-start your journey toward becoming an AI-native engineer. Pass this along to your colleagues today.

Headed for the Exit: the Great Engineering Leader Career Break

By: Gergely Orosz.
The Pragmatic Engineer: 19/08/2026

Big Tech and startups from the inside. Especially relevant for software engineers / AI engineers, useful for anyone working in tech.

...

Trend: more CTOs, VPEs, and Heads of Engineering are walking away from their high-status, in-demand positions. There are many reasons, mostly related to AI, and to "founder mode"

...

In my ~20 years in this industry, I’ve not seen as many capable engineering leaders opting out or taking prolonged breaks as now, with some high-ranking engineering leaders – CTOs, VPs of Engineering, heads of engineering, etc. – quitting their high-status roles and departing, if not into the sunset, then at least with nothing lined up.

To find out what might be behind this spate of sign-outs, I talked with almost 20 engineering leaders currently on a career break – or seriously considering one – and they let me into their personal reasons for deciding to jam the brakes on their careers. Thanks to everyone who shared their input!

Today, we cover:

Ten of the most common reasons for quitting, sometimes without the next gig lined up:

  1. The job got (much) worse
  2. The startup is “losing” and becoming worthless
  3. Not being AI-native enough for other skills to be relevant
  4. Their predecessor saw the “writing on the wall”
  5. Long hours – rarely decisive
  6. Smaller teams mean less need for leaders
  7. Fractional CTO work preferred over fulltime positions
  8. AI startups pay ICs more than non-AI startups pay executives
  9. Quitting to launch their own business
  10. Burnout
  • “Founder mode” looks here to stay, so how to deal with it? And has it made the CTO and VPE roles become “low ROI”?
  • ‘Work at companies that truly want to drive change’. A personal account from someone who took the VP of Engineering role at Gitpod (later, Ona, now acquired by OpenAI) and enjoyed a rewarding experience. Matt Boyle says he interviewed the employer beforehand on whether their business truly leans into the changes brought by AI.

“Just me?”

I was recently messaged by a head of engineering in San Francisco, who said:

“I’m talking to four startups in San Francisco about the head of engineering roles. Pretty normal.

But one interesting pattern is how founding CTOs/heads of engineering are stepping away to take a full career break. We’re talking about two of these four startups. And these are good startups!

Have you seen this trend? I have a small number of data points here, so you might have a broader view.”

I asked around privately, and it turns out a majority of the CTO-level folks I spoke to are considering the very same thing, or are actually in the process of leaving the office for a long spell away; 6/10 engineering leaders said they’re on the way out.

1. The job got (much) worse

Unrealistic expectations, including about AI, by founders and CEOs are the leading cause of jobs turning bad for CTOs and VPEs right now in 2026:

  • CTO expected to magically transform the company to be “AI-native”
  • CTO must make significant engineering cost cuts of up to 20-50%, including morale-sapping job cuts
  • “Do more with less” equals shipping more with fewer people (e.g., no backfills)
  • CTO faces pressure on business results as AI coding bills rack up
  • Founder slop: they want wonky AI prototypes shipped as full-blown products within weeks

Hands-on founders with “AI psychosis” make the job predictably harder, according to one CTO who just signed out of his job:

“Managing ‘AI psychosis’ with founders and executive peers has become very difficult. For example, what do you do when a founder ships a 60,000-line pull request into the product, gleaming with joy at how much more productive they’ve become with AI? They won’t see all the issues with that PR, and how do you bring up that they’ve created a massive amount of tech debt? Especially without looking like a ‘Debbie Downer’.”

Founder slop issues begin when top leaders get excited about AI’s capability, then get hands-on and start issuing PRs, and shipping code to production. It can cause issues across the board:

  • Accountability. Who’s oncall when founder-shipped code breaks? In the “you build it, you own it” culture of startups, it’s confusing when a founder gets hands-on while not owning their work.
  • Quality out the door: if a founder’s half-baked features are accepted, it sends the wider message that quality does not matter. Some people may adopt this attitude to their own work.
  • A founder can overrule whatever was previously agreed with the CTO or VPE about what to build next. Vibes the founder has or feels are reason enough.

Another way that leadership roles have diminished is that craft and quality are less important, says a VP of engineering who’s in the process of signing out of their job:

“Shipping software became all about speed. Finding differentiation with your product in the market is brutal, and speed / go-to-market becomes the biggest differentiator. Craft, quality, and care going into the product are taking a backseat.”

Things also go bad when companies don’t ‘get’ AI+engineering, except as a way to cut jobs. CTOs I talked to mentioned the likes of Ramp, Stripe, and Notion as places that understand how to integrate AI into the engineering culture with a growth mindset without forsaking quality. Elsewhere, bad vibes dominate at places where going all-in on AI leads to the cynical conclusion that product management, design, and engineering leadership are irrelevant.

2. The startup is “losing” and becoming worthless

Director+ roles have a few differences from individual-contributor engineering ones:

  • Larger equity stake in the business. Base salary at these levels is often similar to a staff engineer’s, but usually with more generous equity grants – especially at the VP of Engineering and CTO levels. A good financial outcome depends on the company becoming more valuable, and – in the case of private companies – having a good exit by being acquired or selling shares.
  • Understanding of the business and competition is a baseline. At Director+ level, a big part of the job is making strategic decisions that grow the business and help the company get ahead. It’s a nice-to-have for an engineer to possess business acumen, but director-and-above folks use it much more than most individual contributors (ICs). Great engineering leaders are good at understanding business performance and outlook.

A company that adopts AI rapidly usually falls into one of three buckets:

  • “AI-native”, building & selling AI products. The large AI labs and a select few “AI-native” startups are thriving, but many AI startups with VC funding struggle. Engineering leaders know this, and that their equity – usually issued as options – could end up worthless.
  • Software startups threatened by AI-native businesses. Good businesses in the pre-AI world can be threatened by AI today, like SaaS startups selling seat-based products in areas where agents are taking over the functionality. They have to pivot their businesses or seek an exit. Bending Spoons buying Airtable for less than the company raised is an example of a business threatened by AI and choosing to sell, instead of pivoting the whole business.
  • Unaffected by AI. Usually stable businesses which do more than software, such as with a real-world side to the operation like manufacturing or distribution.

The majority of software startups fall into one of the first two buckets of being AI-native or under threat. Senior leaders at such companies are in a good position to evaluate whether their company is a “winner” worth staying with.

Leaving due to equity becoming worthless

A CTO who quit their startup told me:

“My company would have needed a massive exit for me to realize any upside. I had an equity grant that was 2% of the common shares. However, this equity was behind an already steep preference stack for investors, post Series A.”

This CTO had a very generous equity grant at 2% of shares, so what made him leave it behind? They laid out how it will be difficult to get any benefit from them because the shares are most likely rendered worthless by rules about the order in which different investors get their share of the pie:

  • Assume that this company raised a $10M seed round at a $50M valuation, then a $100M Series A at a $500M valuation. So, a total of $110M was raised across two rounds.
  • Investors typically have a 1x preference. 1x preference would mean that upon any sale, they get the first $110M of the sale.
  • But in this company, the Series A investors negotiated a 2x preference: so upon a sale, $210M goes to investors first ($10M to the Seed, and $200M to the Series A investors).
  • The company now needs to sell for at least $210M for common shareholders (like the CTO) to make any money!
  • If the CTO does not believe a $200M+ exit could happen, then their equity is worthless. A $200M+ exit is typically an acquisition, because a stock market flotation rarely happens at below a $10B+ valuation, these days.

If a VC-funded company does not have the revenue or customers to grow at a fast tick (circa 20-50% per year), then it’s often a struggle to raise the next round of funding, and the business’s actual value usually shrinks to 3-5x of annual revenue. So, if a startup is making $10M per year after raising $110M in funding, and growing 30% year-on-year, then the company is likely worth around $30-50M. Perhaps the right buyer would pay $100M, but if growth slows, the value is likely to drop.

An experienced CTO who takes a step back and assesses things can realize when there’s a high chance of their equity turning into smoke, removing a reason to not sign out of the job. It’s what happened to the CTO above, and when they couldn’t turn the business around, they quit.

Business stops growing

When a VC-funded startup’s business stops growing, the prognosis can be dire in the sense that it’s unlikely to be worth as much as in the previous funding round. This is true even when the startup becomes profitable: this might mean it could theoretically go on forever; but with slow or no growth, it won’t win in another VC funding round.

Here’s a VP of Engineering who saw their startup stop growing, partly due to wrong bets by the CEO:

“My founder/CEO was nontechnical, and was both moving too slow and too fast with AI.

Too slow, as in they did not take the time to understand what our customers wanted. We built a TON of AI stuff, it totally confused them, they churned, growth stalled, word-of-mouth growth was gone. Heck, I don’t think our customers ever wanted or needed anything with AI!

Too fast, as in they deprioritized core systems’ reliability in favor of shipping AI work to prod which did not have any commercial potential. So, our core offering started to have more outages and we lost customers because of this as well.”

I’d add that deprioritizing reliability in favor of building features may be sensible in the early days. The problem seemed to be that this company had not found product-market fit, and the new AI features didn’t resonate with customers. Basically, the CEO lacked customer understanding, business intuition, or both.

So, good on the VPE for getting out when they saw the direction of travel. If the CEO won’t accept input from the VPE – who would’ve at least prioritized reliable operation – then there isn’t much left to stick around for!

3. Not being AI-native enough for other skills to be relevant

The top-paying engineering leadership positions have one thing in common: experience of leading AI-native organisations is expected, and leaders are sought who have turned their current company AI-native, or work at such a place.

It’s new to see people signing out of large companies for feeling like they’re lagging behind in adopting new AI workflows. An ex-engineering director at a large bank told me they quit their job to accelerate their career:

“I was not getting the opportunity to ‘close the loop’ on hypotheses enough. [...] To stay relevant in the industry, I feel like I need to pull out into the “fast lane.”

Like many others, I see the future of software development is with AI. If you don’t get hands-on with your team, working with AI tools day-in, day-out, you’re falling behind.

My plan is to get on the cutting edge of things through a mix of academia and consulting AI companies. I am not saying the plan is perfect, but I need more time to do things differently than I had in my job.”

Consider this: if you stay in your job for two more years, do you expect to find career opportunities at cutting-edge companies in the future? If the answer is “no”, then there’s a risk in just staying put. Joining an uncertain startup or taking a career break to develop AI expertise is also risky, but the outcomes may be more controllable than letting your skillset become outdated, relatively quickly.

But it might actually be necessary to quit in order to get AI experience: you might be able to get this by transferring to an IC role. As Charity Majors, co-founder and CTO of Honeycomb, said in last week’s episode of The Pragmatic Engineer podcast:

“You’ve got to get AI on your resume. You just have to. If you don’t, this is a huge career risk. If you’re working somewhere where you’re not getting these skills, I would do whatever I could to change that [including taking an IC role within the company].”

There are companies where moving from Director+ to individual contributor is possible, even if these companies are the minority. If you happen to work at a place like this, consider if you can and will take advantage of this opportunity.

Most companies say they want to be AI-native, but never do

Claire Vo – founder of ChatPRD and host of ‘How I AI’ podcast, and the former Chief Product & Technology Officer at LaunchDarkly – says most companies will never become “AI native” simply because most VP of Engineering or CTO folks don’t have what it takes to pull off such a transformation. In her words:

“The VPE role used to be primarily about deploying the dark arts to defend engineers from the roadmap, and now everyone thinks that’s BS and leaders are under tremendous pressure to inflect velocity or GTFO (get the f*** out).

Engineers are unhappy (don’t make me tokenmaxx, bro!), product and design sending slop PRs, and everyone good has left for a lab.

Most of these companies’ EPD (Engineering, Product, Design) orgs will never go AI-native, not even close. Most VPEs aren’t good enough at change management to pull it off.”

It looks like there’s a deadlock:

  • The current engineering org is frustrated by how AI is making engineering culture worse, morale is down, and people are frustrated and confused
  • To resolve this, drastic changes are needed to how everyone (engineers, product, designers) works
  • To pull it off, a VP of Engineering or CTO is needed who’s capable of this; someone excellent at change management, who’s ideally done it before.
  • But most VPEs and CTOs are not experts at large-scale change management, nor have done it before.

According to this, many VPEs and CTOs are doomed to fail at making the change they want, and it’s hard to know if that’s because organizations didn’t support them properly or resisted change.

4. Their predecessor saw the “writing on the wall”

There’s (usually) a honeymoon period in a new job, when we believe in the business we’ve joined and in its direction. But when this phase passes, a fraction or all of the problems described above may emerge, and there’s a decent chance that some of them are why your predecessor signed out:

  1. Has AI helped make the role worse?
  2. Is the equity on course to be worthless?
  3. Is getting AI-native experience actually possible, or is the organization resisting change?

I’ve talked with a CTO who replaced their predecessor and founding CTO. A few years into the job, the predecessor CTO realized their equity in the business was worth almost nothing due to stalled growth, all while they were also being out-competed by AI-native rivals. So, the new CTO also resigned after a short, six-month tenure.

5. Long hours – rarely decisive

Two engineering leaders – a CTO and a VP of Engineering – mentioned “insane working hours” as a factor that contributed to them finally quitting. But there were other things as well:

  • The business struggling for growth
  • Their equity grant’s value shrinking to nothing before their eyes
  • CEO/founder ignoring or overriding efforts to help the business succeed

My sense is that at a thriving business during chaotic times like these, it’s unlikely that long hours alone would spur people to leave, if their contribution to current success counts and is valued. When things are going well, it’s possible to delegate more and take time to recharge batteries. But when things are going badly, it feels like every waking hour needs to be spent on working to turn things around.

6. Smaller teams mean less need for leaders

Several engineering leaders are stepping back into IC roles for more stability because engineering teams are smaller now.

Karthik Hariharan, engineering leader at DoorDash, notes:

“Expectations have been shifting a lot in these roles, and a lot of folks qualified for them have consciously been stepping back into IC roles or joining bigger companies for stability and better compensation.

Engineering teams are also smaller now. A VPE isn’t needed until the team is large enough to require it. A technical founder can run the team for a lot longer these days.”

Some reasons why engineering teams have shrunk:

“Fullstack engineer” is mainstream, and was even before AI. Fullstack engineering was becoming relevant a few years ago in terms of a single engineer working on both the front and backends, instead of having a frontend engineer building the UI, and a backend engineer working on backend services. Fullstack frameworks like Next.js or Ruby on Rails made all this pretty easy before AI. Today with AI coding agents, you can rely on them to write decent code on platforms you’re unfamiliar with. There’s now little to no reason why a project would need multiple devs with different specializations.

It’s normal for one, or a maximum of two fullstack engineers, to be working on any given project at Anthropic as well. Head of Claude Platform, Katelyn Lesse, shared how it works at Anthropic:

“On an individual project, you often cannot have more than two people working on it.

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

Frontend-only and native mobile teams are also getting smaller or disappearing. Even at companies where iOS and Android are a big part of the business, more places are building using cross-platform technologies where one engineer can do the work that used to need several. For example, social media app Bluesky had a single engineer build its web, iOS, and Android apps for launch by using React Native and Expo. Bluesky later hired more people to work on the web and apps, but they all work across these three platforms. It’s not the same as hiring separate web engineers, iOS engineers, and Android engineers.

We cover this in more detail in the deep dives Cross-platform mobile development and Is there a drop in native iOS and Android hiring at startups? We also observed a steep drop in frontend engineers and native mobile engineers in our latest state of the tech jobs market report:

Demand for frontend engineers and native iOS+Android engineers keeps dropping with the trend of smaller engineering teams. Source: The tech jobs market in 2026

Tech companies have been flattening their org structures for three years now. We first covered the trend for fewer middle managers back in 2023, when Meta drastically reduced manager positions. The trend has not stopped, and many – if not most – companies have increased the number of reports each engineering manager has, while reducing the number of layers in their organization.

7. Fractional CTO work preferred over fulltime positions

The rest of the article is available to paid subscribers.

By , No comments:
Tags , , ,

Microservices Platforms: When Team Topologies Meets Microservices Patterns

Mike's Notes

Great presentation by Chris Richardson, who is very experienced.

"Chris Richardson explains how microservices platforms reduce team cognitive load, sharing six key platform patterns to streamline delivery and accelerate software development flow⁠." - InfoQ

The link has a video recording of the talk. Excellent as usual. 

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > InfoQ Weekly Digest
  • Home > Handbook > 

Last Updated

08/08/2026

Microservices Platforms: When Team Topologies Meets Microservices Patterns

By: Chris Richardson
InfoQ: 04/08/2026

Chris Richardson is a software architect and serial entrepreneur. He is a Java Champion, a JavaOne rock star and the author of POJOs in Action, which describes how to build enterprise Java applications with frameworks such as Spring and Hibernate. Chris was also the founder of the original CloudFoundry.com, an early Java PaaS for Amazon EC2.

Transcript

Chris Richardson: Welcome to my talk on microservices platforms. Really, what the talk's about is a simple idea, taking the concept of team topologies, platforms, and platform groups, which is another term for platform teams, and using those to accelerate the delivery of applications that use the microservice architecture. Basically, it's all about reducing the cognitive load of the service teams, enabling them to deliver better software faster. I've been building software for a million years now, at least that's what it feels like. It did mean that I was actually around when patterns became popular within the software community back in 1994, 1995. I was really good, and that shaped my thinking ever since.

My brain is full of 30 years of patterns now, as well as 30 years of Java. I've just done various things. I've worked on Lisp systems, created the original Cloud Foundry. Then I also, for the past 10-plus years, been pretty much focused on the microservice architecture, just helping organizations around the world improve how they deliver software. I'm excited, so my book, "Microservices Patterns," came out like 7 years ago now, which is still quite current, remarkably. I'm in the middle of working on a second edition of the book, so one day it will come out. I just think about microservices most of the time.

Microservices Platform: Why?

In this talk, I'm actually going to walk through six different patterns that I've identified that will help with the delivery of microservices. I'm sure there's actually many more. I want to start off just by talking about why platforms, why do they matter? What are the benefits in the context of developing microservices? I want to take a step back and talk about what software development is all about, and I like to think that at the heart of software development is a feedback loop. We in IT, we develop software, and then we put it into production, put it into the hands of the users, and we get feedback from that. It's really critical for businesses today to have short feedback loops so that they can thrive in today's volatile, crazy world, which is unpredictable from one moment to the next. Ages ago, I used to talk about brick-and-mortar businesses being disrupted by digital technology.

Since then, we've had pandemics, we've had wars, we haven't had tariffs, now we do, now we don't. It's just completely volatile. Businesses quickly need to be nimble. There's a lot of research that shows, and this is one of the findings from the keynote, that the better you are at delivering software, as defined by continuous stream of small changes, the more successful the business is likely to be. Fast flow is really important. To actually achieve fast flow, you need a combination of three things. You actually need a process, or specifically DevOps, which I'm actually not going to talk about today. That's how an organization should work. You need a properly structured organization, specifically one that follows the ideas of team topologies, which is actually a collection of patterns for structuring an organization for fast flow. Then you need an architecture that enables both of those things, which, at scale, is often the microservice architecture. I'm really focusing on the organization and the architecture piece of this in today's talk.

What is this team topologies thing? That is a collection of organizational patterns and principles for fast flow. It's basically, how do you structure your organization to deliver software rapidly, frequently, and reliably, using DevOps, actually? There are several different concepts involved. The first one is there's four different team types. Most of the work is done by what is known as a stream-aligned team. That is a team that is responsible for the end-to-end flow of work that is taking requirements and turning it into code running in production. These teams are generally small, five to nine people. Those are the teams that are doing the vast majority of the work. Then they're supported by three other team types. There's enabling teams that act as consulting teams that help teams acquire new skills. There's complicated subsystem teams that focus on domains that actually involve deep skills like math, for example.

I'm not talking about them so much in this talk. Then, lastly, there are what used to be called platform teams, and then they got renamed into platform groupings. I reject that, and I just call them platform groups in the second edition of "Team Topologies." Which is what I'm really going to talk about today. You've got these. I'll talk about what platform groups do. Then there are these three different interaction styles. Most of the interactions are via X as a Service, one team consuming the output of another in a self-service fashion. Occasionally, teams need to collaborate to discover new capabilities. Then, of course, enabling teams, which are acting as consultants, facilitate with the team that is learning. I'm going to talk about these interaction types quite a bit. Then there's a set of principles, and the most important principle is about managing a team's cognitive load.

The human brain can only deal with so much complexity. Collectively, a team, a set of brains can only deal with so much cognitive load as well. They only have a certain cognitive capacity, and you do not want to exceed that. Because if you cognitively overload a team, like just in order to get the work done, there's just so much mental effort, then that actually reduces team performance, and it ultimately impacts their mental health in terms of stress, and burnout, and so on. As Nicole mentioned in the keynote, a key part of having a great developer experience is minimizing the cognitive load of a team. As you're going to see, that is one of the key goals of having a platform or a collection of platforms. That's team topologies and cognitive load.

Then in terms of what is my definition of the microservice architecture. It's an architectural style that structures an application as a set of components or deployable units, which also go by the name of services. Then those services have two essential characteristics. They are independently deployable, meaning a service can be built, tested, and deployed in isolation from other services. They are loosely coupled, or specifically loosely design-time coupled, which means that a change to one service rarely requires other services to change in lockstep. Notice in this definition, I'm not talking about claiming that services should be small or numerous. That might be implied by the name, but that's not an important characteristic. The reason I'm talking about microservices here is because they actually enable fast flow. The way they do that is that they enable the teams that are developing in them, the stream-aligned teams, to be independent.

That comes from those two properties. Because the services are loosely design-time coupled, a team can change their service without having to coordinate that change with other teams. Then because the services are independently deployable, a team can deploy their service without any kind of collaboration with those other teams, at least the vast majority of the time, which means that teams are able to work separately most of the time, which is essential for fast flow. The challenge that you have is that the microservice architecture is quite complex. If you go look at the microservices patterns language, most of the patterns there are solutions to problems that you encounter when implementing microservices. There's a lot of different patterns that you have to implement. If you look at each pattern, it's a combination of three things. Application logic, which is what the team should be focusing on. There tends to be a lot of plumbing, so supporting infrastructure code, connecting to databases and message brokers, and logging and so on.

Then there's infrastructure services as well. Teams should be focused on application logic, and for them, having to deal with plumbing or infrastructure services would be an excessive burden. In some cases, it requires deep expertise, so it would impose a significant cognitive load. If each team was dealing with this, it would be duplicated effort. You'd end up with multiple bespoke implementations, which would be a maintenance nightmare. Then, on top of that, there are these cross-cutting application-wide concerns that don't really belong to any one team. Not only that, it's not just patterns. If you go look at the source code for a service, it's not just the application code. There's build logic, a definition of the service's dependencies, and task definitions that compile and test and package that service. There's also some deployment logic. There's also the definition of the service's deployment pipeline. Then there's probably Infrastructure as Code, like Kubernetes YAML, for example, that's there to deploy the service.

You don't want the team reinventing the wheel for all of that, because that would be an excessive burden. There's even more. Not only do you have the services, but then there's all these infrastructure services, including the infrastructure that runs the deployment pipeline, services that are global, like your message broker, for example, and then the deployment infrastructure. It would be a burden for all of the teams to actually have to take on that work themselves. That's the big motivation for platforms and platform groups. From a team topologies' perspective, a platform is an artifact that reduces the cognitive load of a stream-aligned team. It could be just a wiki page, but usually it's a tool or a library or some kind of self-service, SaaS-like solution providing a capability. It's developed by a platform group, and it's consumed as a service by the stream-aligned teams. That's the big idea here.

If you look at what a platform group is, it's actually a composite team type. It most certainly would have a stream-aligned team that develops the platform, but there might also be an enabling team that provides a consulting function that helps the stream-aligned teams be more successful with that platform. Then in terms of collaboration, this is primarily X as a Service. It's all about self-service platforms, but then the teams will collaborate to evolve the platform. Then, as I mentioned, the enabling team that's part of the platform will also consult with the service teams. The primary benefit is that it reduces the cognitive load of the teams, enabling them to work on their specific business functionality and actually deliver value. Then the platform is a single standardized implementation of some important capability. It's done right just once. Then the platform group itself can focus on developing skills in that area. Unlike the stream-aligned team, which is focused on delivering business functionality, the platform team can dive deep into whatever their particular more technical problem domain is. That's the big idea with these platforms.

The Service Foundation Platform

As I mentioned, I identified six different platforms, and there's most likely more, but I thought this was a good start. I'm going to talk about each one very briefly in turn. The first one I want to talk about is the service foundation platform that simplifies the creation and maintenance of services. As I mentioned a little while ago, if you look at a service, there's a lot of plumbing, there's build logic, there's Infrastructure as Code for deploying the service. There's a lot of stuff, and actually setting up a new service from scratch would be quite a burden on the teams, and maintaining all of that would be quite a burden as well. The solution is to have a service foundation platform that simplifies that part of service development. The service foundation platform is comprised of two parts. There's the service template, which, as the name suggests, is a template that can just be cloned to create a running service.

Then there's a service chassis that is a framework that the template is built upon. The idea of a service template, super simple. It's a complete running service that a team can just copy and drop in their business logic, and they've got this testable, deployable, observable service up and running relatively quickly. Big reduction in cognitive load there. The problem you have is that a template, and this is same as true with code generation as well, it is basically glorified copy and paste. Then what's more is the template is changing. When it's time to make an update to the plumbing for the services, you now have multiple copies of the code and it's likely to be slightly different because each service was cloned from a slightly different version of the template. There's potentially a massive maintenance task in updating all of these services. That's where the service chassis comes in.

The idea is you extract out most of the functionality that is in the template into this chassis, which is this framework. Then that framework is just referenced by the template. Hopefully, the template is really small, so the amount of copy and paste is significantly reduced. When it's time to make a change to the plumbing, you just update the framework, release a new version of it, update the service template to use that version, and then update each service to use the new version of the chassis. Fingers crossed, you've just rolled that change out and it's just a one-line version update. Of course, there are scenarios where it's a bit more complicated than that. A lot of the time, the upgrades are quite straightforward. If you have more complex upgrades that require code changes to each service, which includes updating stuff that is in the service template, one option is for the teams to do it themselves.

A much better option is for there to be some kind of update or migration script or some tool that you can apply to each service's repository to create a pull request. That might be a deterministic tool like OpenRewrite, which provides large-scale refactoring of your codebase. Or maybe, and this is my obligatory mention of GenAI, because that's the only thing that's real today, you might be able to use GenAI to actually do this update. You could actually give it the diffs of the service template, and maybe it would figure out how to apply those diffs to each and every service and create a pull request for it. Who knows, because every time you use GenAI, it's a roll of the dice as to whether you'll get something usable out of it. That's the service template, or to be more precise, the service foundation.

The Security Platform

The next platform I want to talk about is the security platform. Who here, first off, understands security and likes it. Because to me, it's like a prime example of my brain does not have the cognitive capacity to maintain knowledge of how OAuth authorization flows actually work. I learn it for a while, and then a month later, it's paged out. I don't know if that's because it's complex or because I'm getting old and my mental capacity is diminished. Security is really important, yet at the same time, it's really complicated. There's a lot of different areas to that, and I just want to talk about three areas that can impact developers. One part of security that's obviously important is authentication, verifying the user is who they claim to be, logging them in, in other words. There's a whole complex mechanism involving OAuth and OIDC and IAM services, and so on, that result in services being handed a token.

Then they have to do authorization based on that token, which might be hard-coded Java authorization rules, or perhaps they delegate to an authorization service like also cloud. There's also access control lists for things like Kafka topics and stuff. This is not what developers should be spending their time thinking about, because this stuff is hard, or at least for me, it's hard. Then, on top of that, there's also transport level security. You want to secure the communication between services as well, and that involves technologies like certifical authorities that are handing out certificates and so on. That's also quite complicated. The obvious solution is to have a security platform that takes care of that. This platform consists of two parts. There's a bunch of infrastructure services that provide the security mechanisms that I just described, like an IAM service, certificate management, which might actually be a service mesh, for example.

Maybe there's the authorization service as well. You've got that infrastructure. Then there are elements that provide security that are incorporated into the service chassis so that services are actually secure by default. You build them on top of the chassis. Then, let's just say automatically every REST endpoint will require a JWT. It knows how to get the JWT signing certificate from the IAM service. The idea is that this insulates the developer from the complexities of security, and the only security aspects they need to think about are writing the authorization rules that determine which operations can be invoked by whom. That's about it. That's the security side of things.

Infrastructure Services Platform

The next platform I want to talk about is the infrastructure services platform. Services are not these standalone things. They need a bunch of infrastructure services in order to run. Most obviously, the services need database servers, which need to be provisioned and managed. Typically, even if you're running on Kubernetes, you'll probably use AWS RDS or Aurora for the service databases. Then there's application-wide infrastructure like Apache Kafka. Maybe you use AWS MSK. On the one hand, it sounds simple, but on the other hand, setting up cloud resources on AWS and other public clouds is incredibly complicated and requires deep expertise, starting with getting an access key and taking it from there. It's like really complicated. You don't want teams dealing with this, because they should be focusing on their business logic. It makes sense to have a platform to do this. Once again, the platform consists of two parts.

One part provides the shared services like Apache Kafka and other pieces of infrastructure. Then there's what I call an infrastructure orchestrator. What that does, it enables the service team to say, my service needs a Postgres database with this capacity. Then the orchestrator is responsible for taking that service specification and creating the appropriate cloud resources, which are then managed. The teams can just go, I need this. They can express their intent and the orchestrator takes care of it. There are a few different solutions out there. One that I've used in the past in the Kubernetes world is Crossplane, which if you can get past the word soup of the documentation, it's actually really interesting. It basically extends the Kubernetes API. Let's say the platform team create a new resource type like service database. That's a CRD in Kubernetes terminology. Then they define how that maps to cloud resources.

Then, a service team can just write the manifest, the YAML that says, I need a service database and it needs to be this big and so on. Crossplane provisions and manages it for you. It's really cool because the service is defined at the Kubernetes level and now its infrastructure is defined at the Kubernetes level. Perhaps it's all packaged up into a Helm chart, so you install the Helm chart. You automatically get cloud resources in that environment. I think the technology is still maturing, but it's actually really interesting. Daniel Hertz company has one, Kratix, even better than Crossplane. Really interesting stuff, but it's deep technology.

The Observability Platform

Yet another platform I want to talk about is the observability platform. As you can imagine, a team that develops a service needs to understand how that service is behaving in production, and then they also need to understand what the users are doing, and how they're actually using that service. In the microservice architecture pattern language, there's actually six observability patterns. The gray ovals are the patterns. This includes the standard stuff like log aggregation, application metrics, and distributed tracing. It's like an observable service has to implement these patterns. As you can imagine, each of these observability patterns is some instrumentation which is comprised of application logic, plumbing, plus some dependencies, and that's emitting telemetry. Then there's infrastructure services like Prometheus, or something for storing logs and so on, that's gathering the telemetry, storing it, analyzing it, and presenting it to the teams. Yet again, on the one hand, the teams probably have to write some application-specific instrumentation, but everything else would be too much of a burden.

Setting things up, yet again, requires specific knowledge or in-depth expertise. Having an observability platform provide the infrastructure services like Prometheus, or ELK, or CloudWatch, or Datadog, so it could be a SaaS, or it could be on-prem, doesn't really matter, but it's stuff that needs to be provided, managed, and so on. Then, in the service template and chassis, there's elements that ensure that out of the box, the service is observable by default. You just build on top of the service chassis. You have an observable service. The team just needs to write the appropriate logging code, and collect the appropriate business-oriented metrics, and all of the low-level details are just insulated from them. Recurring theme. The team either ignores the low-level stuff completely, or focuses on the valuable parts, and everything else is provided via the chassis and these pre-managed infrastructure services.

The Build Platform

I now want to talk about the remaining two platforms, which are actually quite connected in a way, two sides of the same coin, the build platform, which is responsible for the deployment pipeline, and then the deployment platform that's responsible for the production environment. They're actually connected, because what comes out of the build platform actually has to be compatible with what the deployment platform is expected. Let's look at the build platform. Every service has a deployment pipeline that's going to compile the service, run the tests, package it up, perhaps as a deployable unit, like it could actually build a container, and a Helm chart, test that, and then either push it into the production environment or publish it to a registry where the production environment can pull it. Every service has one of these. It needs to be set up. It needs to be administered. That can be a significant burden for the team.

Then, also, the infrastructure that the deployment pipeline runs on also needs to be set up and administered as well. If we're using GitHub Actions, you've got to have a GitHub Actions workflow file for each service. Then the organization that contains the service's repository needs to be configured with GitHub Actions runners that actually execute the deployment pipeline, and also budgets need to be set and all of that administrative stuff. Not something you really want the teams to be doing, especially when you have a lot of services that are more or less built the same way, it's like, why reinvent the wheel? Good use case for having a build platform which provides the pipeline infrastructure, properly configured GitHub organizations. Then in the service template, there's actually a templated definition of the deployment pipeline, whether that's a GitHub Actions file or a CircleCI config.yml. Then, hopefully, the actual pipeline specification is built using these reusable package components like GitHub Custom Actions or CircleCI Orbs, to actually minimize the amount of copy and paste that's involved.

At least those two have a way of providing reusable deployment pipeline logic, and GitLab has something similar as well. Then the build platform can also provide some repository/registries for storing build artifacts, shared libraries, as well as publishing deployable units to a container registry for your container images and Helm charts. Because what comes out of the deployment pipeline obviously has to be stored somewhere. With this build platform, hopefully, most teams don't have to be concerned with all of this. It just happens for them. Maybe they need to tweak the deployment pipeline if they have specialized use cases, but hopefully not so much. I feel like this is pretty standard.

The Deployment Platform

Then that leads to the last part, which is the deployment platform. To actually run an application, you obviously need to have a production environment, and you might actually have some other environments, staging, dev, QA, though unclear exactly how many you really should have. Those are a centralized place where your service is run, and they actually have to provide a rich set of capabilities. They need to have a deployer mechanism that takes an updated service and rolls it out somehow. It's hard to talk about this in the abstract, but later on, I'll mention things like GitOps tooling like Flux CD or Argo. They also need to deploy your services in a fault-tolerant way. The big idea is like, here's my service, I need to run n instances of this. The infrastructure tries its hardest to make sure that's true. That could be an AWS autoscaling group, or it could be Kubernetes deployment, depending on what mechanism you're using.

Then there's also a networking capability as well. Requests that come in get routed and load balanced across your service instances. As you probably know, or maybe you're blissfully unaware, it's really complicated to set all of that up. Then the other part of this, every service needs some Infrastructure as Code configuration to define how it's deployed. It's either Kubernetes YAML, or maybe it's some Terraform Infrastructure as Code or something worse. There's a lot of stuff. It's really funny. I mostly live in the Spring world. When I step outside the Spring world and I go to the frontend, I'm horrified. I have been for many years. Then, over the past few years, I've been doing more of this DevOps-y stuff, and I'm equally as horrified. It is so complicated. I guess it's evolving. As a Spring developer, I don't want to have to deal with this. Actually, I find it cool and interesting, but there's another part of me that just wants to run away screaming.

You need a deployment platform to shield the developers from the complexity of the infrastructure. That will provide the various environments. Hopefully, in your service template, it'll provide IaC code for deploying the service, some kind of template. Then hopefully that is composed out of some reusable Infrastructure as Code components. Though the modularization technologies there leave a lot to be desired, specifically in the Kubernetes YAML world. Here's one example that I've worked with, which is where there's a GitOps tooling, here I've shown Flux, but there's also Argo CD. The state of the cluster is defined by one or more Git repositories. When those change, Flux will actually apply those changes to the cluster. It can also monitor the container registry. When a new Helm chart is published, it will edit the manifest and then deploy that new version. It's a pretty slick setup, but it is quite complicated. That's the deployment platform, and ideally it shields the developers from a lot of the complexity.

Microservices Platforms: How?

That's the six platforms. I just want to wrap up with a few comments about this platform development thing. While I was putting this talk together, I saw this article by The New Stack, which just pointed out that the success rate for platform engineering is not that great. Mostly fails. Based on what I've seen looking at organizations, is it's not surprising. I think one issue that's going on is for a lot of organizations, platforms are a way of ignoring the hard problems of people and solving actual customer problems. They do that by diving into what I call the infinity pool of technology. Because you can just get lost in the Kubernetes world and feel like you're doing useful things like creating custom Kubernetes operators. If you're not actually solving real problems, you're not going to succeed. A few thoughts. I've observed this antipattern forever. You really have to focus on the services, get those deployed in production, and worry about the technology later.

Specifically, what that means in terms of platforms, build some services, put them in production. Figure out what problems the teams are struggling with, then build the platforms, migrate the services to those platforms, and just iterate around that. Rather than go do a lot of platform development up front. Then team topologies has this great concept of a thinnest viable platform, or you could say it's like a minimum viable platform, where you build just enough platform to enable the teams to be successful. No more, no less. Maybe that involves Kubernetes operators, but maybe it doesn't. Then, teams need to adopt a customer-focused mindset, where customers in this case are the teams that are developing the services. The platform teams exist to help those teams, not actually dictate to them. They need to learn what their problems are, and provide platforms that help. Then they also need to actually help those teams use the platforms through facilitation. Build just enough platform to help, and do it in a customer-focused way.

Summary

In summary, microservices do require platforms to avoid the teams having to reinvent a lot of complex wheels. I identified six different platforms. There's probably more. Then I think it's really important to take a software engineering approach to these platforms, which are actually easier said than done with some aspects, and develop reusable components, rather than just copy-pasting everywhere, which creates a maintenance nightmare. Obviously, if you're a developer, you go, that's no big deal. Programming languages have libraries, frameworks, build tools like Maven, Gradle have plugins, even CI/CD platforms like GitHub Actions and CircleCI have reusable components. Then it gets a bit iffy when you're in the Kubernetes YAML world. There's Helm library charts, which are just weird. They work, but they're weird. Then there is a language called q, but that seems slightly weird to me as an application developer. I think there's work to be done in that area. You want to have these modular, reusable components everywhere. When you do have copy-paste, you then need tooling to actually automatically roll out updates to all of your services, generate pull requests for each one. Then, lastly, if you're building microservices, focus on the services, not on the technology. Build just minimal platforms that help.

By , No comments:
Tags , ,

Is Particle Physics Dead, Dying, or Just Hard?

Mike's Notes

This Quanta Magazine article about the current state of Particle Physics got me thinking.

  • Particle physicists are very good at statistical physics and maths
  • They have to be very bright and well-trained
  • They like hard problems to solve
  • There are unemployed particle physicists
  • Ajabbi Research will need people in the future. Hmmm

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Quanta Magazine
  • Home > Handbook > 

Last Updated

20/03/2026

Is Particle Physics Dead, Dying, or Just Hard?

By: Natalie Wolchover
Quanta Magazine: 26/01/2026

Natalie Wolchover is a columnist for Quanta Magazine, where she covered the physical sciences for more than a decade. Her writing has been featured in The Best American Science and Nature Writing, The Best American Magazine Writing, and The Best Writing on Mathematics, and has won several awards, including the 2022 Pulitzer Prize for Explanatory Reporting, the 2016 Evert Clark/Seth Payne Award, and the American Institute of Physics’ 2017 Science Communication Award. She was lead editor for the National Magazine Award–winning special issue, "The Unraveling of Space-Time." Her first book, The Question to Which the Universe Is the Answer, is scheduled for publication in 2027.

Columnist Natalie Wolchover checks in with particle physicists more than a decade after the field entered a profound crisis.

In July 2012, physicists at the Large Hadron Collider (LHC) in Europe triumphantly announced the discovery of the Higgs boson, the long-sought linchpin of the subatomic world. Interacting with Higgs bosons imbues other elementary particles with mass, making them slow down enough to assemble into atoms, which then clump together to make everything else.

A couple of months later, I took a job as the first staff reporter at the nascent science magazine that would become Quanta. Turns out I was starting on the physics beat just as the drama was picking up.

The drama wasn’t about the Higgs particle; by the time it materialized at the LHC there was already little doubt about its existence. The Higgs was the last piece of the Standard Model of particle physics, the 1970s-era set of equations governing the 25 known elementary particles and their interactions.

More striking was what did not emerge from the data.

Physicists had spent billions of euros building the 27-kilometer supercollider not only to confirm the Standard Model but also to supersede it by uncovering components of a more complete theory of nature. The Standard Model doesn’t include particles that could comprise dark matter, for instance. It doesn’t explain why matter dominates over antimatter in the universe, or why the Big Bang happened in the first place. Then there’s the inexplicably enormous disparity between the Higgs boson’s mass (which sets the physical scale of atoms) and the far higher mass-energy scale associated with quantum gravity, known as the Planck scale. The chasm between physical scales — atoms are vastly larger than the Planck scale — seems unstable and unnatural. In 1981, the great theorist Edward Witten thought of a solution(opens a new tab) for this “hierarchy problem”: Balance would be restored by the existence of additional elementary particles only slightly heavier than the Higgs boson. The LHC’s collisions should have been energetic enough to conjure them.

But when protons raced both ways around the tunnel and crashed head-on, spraying debris into surrounding detectors, only the 25 particles of the Standard Model were observed. Nothing else showed up.

In philosophy, “qualia” refers to the subjective qualities of our experience: what it’s like for Alice to see blue or for Bob to feel delighted. Qualia are “the ways things seem to us,” as the late philosopher Daniel Dennett put it. In these essays, our columnists follow their curiosity, and explore important but not necessarily answerable scientific questions.

The absence of any “new physics” — particles or forces beyond the known ones — fomented a crisis. “Of course, it is disappointing,” the particle physicist Mikhail Shifman told me that fall of 2012. “We’re not gods. We’re not prophets. In the absence of some guidance from experimental data, how do you guess something about nature?”

Once the standard reasoning about the hierarchy problem had been shown to be wrong, there was no telling where new physics might be found. It could easily lie beyond the reach of experiments. The particle physicist Adam Falkowski predicted to me at the time that, without a way to search for heavier particles, the field would undergo a slow decay: “The number of jobs in particle physics will steadily decrease, and particle physicists will die out naturally.”

The crisis and its fallout made for years of interesting reporting, but sure enough, the frequency of news stories related to particle physics diminished. I fell out of touch with sources. More than 13 years on, in this first column for Qualia, a new series of essays in Quanta Magazine, I’m taking stock. Is particle physics dying, as Falkowski predicted? Can new physics still be found? What’s the future for particle physicists? Will artificial intelligence help? How much hope is left in the search for answers to the many remaining mysteries of the universe?

Some particle physicists act as if there’s no crisis at all. The LHC is still running and will for at least another decade, and its operators are finding new sources of enthusiasm.

In the last couple of years, data handling at the collider has improved with the use of AI. Pattern recognizers can sort through the outgoing debris of proton collisions and classify collision events more accurately than human-made algorithms can. This helps the physicists to more accurately measure the “scattering amplitude,” essentially the probability that different particle interactions will occur. For instance, AI systems can determine more precisely how many top quarks arise in the aftermath of collisions versus the number of bottom quarks. Any statistical deviations from the predictions of the Standard Model could signify the involvement of unknown elementary particles.


A proton-proton collision documented by the Compact Muon Solenoid at CERN in 2012 shows evidence of the decay of the Higgs boson.

CMS Collaboration; Mc Cauley, Thomas

Novel particles as hefty as Higgs bosons would not be so subtle; they would have shown up already as pronounced bumps on data plots. But as Matt Strassler, a particle physicist affiliated with Harvard University, explained to me, the traces of lighter novel particles could still lie in so-called hidden valleys in the data. “There’s a huge amount of unexplored territory there,” he said. There might exist, for instance, an unstable type of dark matter particle that leaves its mark by occasionally arising and immediately decaying into an excessive number of muon-antimuon pairs. Detecting such an excess would point indirectly to the unstable particle’s existence. “For people who thought all the new physics is at high energies — they’re very disappointed right now,” Strassler said. “I don’t share that view. There are many opportunities for nature to provide clues at low energies.”

So far, though, no such indirect evidence of new physics has been detected. The more accurate the statistics have become at the LHC, the better they match the Standard Model. Michelangelo Mangano, a particle physicist at CERN, the laboratory that houses the LHC, said the collider today is like a tool for exploring the Standard Model’s predictions, and he considers this exploration worthwhile because not all consequences of the equations are easy to calculate. The search for new physics beyond the Standard Model is ongoing, Mangano said, but “the fact that it’s not giving positive results does not mean we are stuck, dead, or wasting our time.”

These questions are so fundamental that of course it’s worth nailing down every amplitude and checking every hidden valley, since we have the tool for the job. But for hunters of new physics, does the game end there?

The community wants to go bigger. CERN physicists want to build a Future Circular Collider, tripling the circumference of the LHC with a 91-kilometer tunnel beneath the Franco-Swiss border, to both probe higher energies and look for subtler signals. This FCC would initially collide electrons, which, unlike protons, are themselves elementary particles, with no substructure. Their clean collisions would allow more precise measurements of scattering amplitudes, making the FCC ultrasensitive to indirect signs of new physics. By the end of the century, the mega-collider would be upgraded to collide protons, as the LHC does now. Proton collisions are messier, but at the FCC they would achieve unprecedented energies — about seven times higher than the LHC can currently muster — so they have a chance, however slim, of revealing heavy particles beyond the LHC’s reach. (In theory, particle masses could range up to a million billion times greater than what the LHC energy scale can produce directly, so there’s no reason to expect them around the next bend.)

We’re not gods. We’re not prophets. In the absence of some guidance from experimental data, how do you guess something about nature? - Mikhail Shifman

As of now, the FCC’s fate is unknown; formal approval and funding commitments by member countries won’t come before 2028.

Meanwhile, U.S. particle physicists are aiming to complement the European strategy by constructing a brand-new type of machine: a muon collider. Muons are elementary like electrons, but they’re 200 times heavier, so their collisions would be both clean and energetic (albeit not reaching the collision energies of the LHC). Both the selling point and the challenge of this newfangled type of machine is that it will require major technical innovations (with all the spin-off potential that can bring), because muons are highly unstable. They must be accelerated and collided mere microseconds after they’re created.

Demonstrating the technology and then constructing the collider would take roughly 30 years, and that’s with federal funding. “We have to figure out how to do it in between 10 and 20 billion [dollars],” said Maria Spiropulu, a physics professor at the California Institute of Technology and co-chair of the committee behind a national report endorsing a muon collider program(opens a new tab) that came out in June 2025. Over the coming years, the Department of Energy will weigh whether to fund the proposal rather than competing science projects. What hurts its case is the lack of a “discovery guarantee,” which the LHC had with the Higgs boson.


Scientists and technicians inspected and upgraded systems at the Large Hadron Collider during the Long Shutdown 2, which began in 2018.

Maximilien Brice/CERN

Then again, as the mathematical physicist Peter Woit mused on his blog(opens a new tab), “Perhaps in our new world order where everything is controlled by trillionaire tech bros, the financing won’t be a problem.”

Deliberations about a Chinese supercollider have come to naught, I’m told. Instead, China has decided to pursue a “super-tau-charm facility”: a lower-energy particle scattering experiment that would cost mere hundreds of millions of dollars instead of tens of billions. The facility will produce a lot of tau particles and charm quarks, partly to study whether taus ever shape-shift into muons or electrons. This kind of switching isn’t predicted by the Standard Model, but it does happen in some theoretical extensions of it.

Okay, we might as well check. We’re desperate for new physics, and the price is good. But by definition it’s very difficult to know which shots in the dark are worth taking.

Adam Falkowski, who sounded the death knell for particle physics back in 2012, used to be known for the sharp commentary he supplied on his blog Résonaances(opens a new tab). But the Paris-based particle physicist hasn’t posted anything since 2022. He said that’s partly because he’s been tied up with fatherhood and partly because there hasn’t been much to say.

When we caught up on a video call, Falkowski told me, “I am very skeptical about future colliders. For me it’s very difficult to get excited about it.” He sees momentum behind CERN’s FCC campaign, but personally he worries about the huge costs and timescales, and the fact that “there are absolutely no hints that something is there within the reach of the next collider.”

For his part, Falkowski has turned to the theoretical study of scattering amplitudes, a growing research area focused on the geometric patterns underlying particle interaction statistics, patterns that could point toward a truer perspective on the quantum world. The field seeks to reformulate the equations of particle physics in a different mathematical language in hopes that this language might extend to quantum gravity. “There is a very vibrant program in trying to understand the structure of the physical theories,” Falkowski said. “The hope is that with the help of machine learning, that there can be very fast progress in the coming years. I think that’s where the best things have happened.”

But amplitudeology, as this field is known, is abstract — it’s no atom-smashing experiment. Falkowski said he does think experimental particle physics is dying. He has watched talented postdocs switch to other research areas or take data science jobs. “I’m not sure they are getting the best of the best as they used to,” he said, “because the prospects of returns are so distant. If you want to change the world now, you will do AI; you will do something different from particle physics.”


The ALICE (A Large Ion Collider Experiment) detector at the Large Hadron Collider was designed to study quark-gluon plasma.

CERN, Julien Marius Ordan/Science Source

This brain drain appears to be real. I spoke to Jared Kaplan, co-founder of Anthropic, the company behind the chatbot Claude. He was a physicist the last time we spoke. As a grad student at Harvard in the 2000s, he worked with the renowned theorist Nima Arkani-Hamed to open up the new directions in amplitude research that are being actively pursued today. But Kaplan left the field in 2019. “I started working on AI because it seemed plausible to me that … AI was going to make progress faster than almost any field in science historically,” he said. AI would be “the most important thing to happen while we’re alive, maybe one of the most important things to happen in the history of science. And so it seemed obvious that I should work on it.”

As for the future of particle physics, AI makes worrying about it now rather pointless, in Kaplan’s view. “I think that it’s kind of irrelevant what we plan on a 10-year timescale, because if we’re building a collider in 10 years, AI will be building the collider; humans won’t be building it. I would give like a 50% chance that in two or three years, theoretical physicists will mostly be replaced with AI. Brilliant people like Nima Arkani-Hamed or Ed Witten, AI will be generating papers that are as good as their papers pretty autonomously. … So planning beyond this couple-year timescale isn’t really something I think about very much.”

Cari Cesarotti, a postdoctoral fellow in the theory group at CERN, is skeptical about that future. She notices chatbots’ mistakes, and how they’ve become too much of a crutch for physics students. “AI is making people worse at physics,” she said. “What we need is humans to read textbooks and sit down and think of new solutions to the hierarchy problem.”

Cesarotti was a high school junior when the Higgs boson was discovered. She grew up near Fermilab, the U.S. national lab in Illinois that houses the Tevatron, which was the world’s highest-energy particle collider before the LHC. (The top quark was discovered there in 1995.) This proximity taught her that a particle physicist was a thing you could be. Later, it turned out to be her thing. “What are the fundamental building blocks of the universe — those were the questions that I was most interested in knowing the answer to,” she told me. “But what people said was, ‘Particle physics is dead. Don’t do this.’”

It may have been a fair warning; Cesarotti has yet to land a permanent job as a rising particle physicist. The subfield has continued to shrink, she and others said, as faculty hiring committees and grad students go in other directions. “Definitely all this rhetoric that there was nothing to be found and you should give up on it — people listened,” she said. “And of course that means there are fewer people. It becomes a self-fulfilling prophecy. If you’re pushing all these talented people out of trying to solve these problems into a field that it’s easier to make an impact on, then you’re setting yourself up for failure.”

Cesarotti echoed a sentiment I’d heard from others, which sounds correct to me as well: “Particle physics isn’t dead; it’s just hard.” It’s hard to know what to think about or look for. But the most devoted particle physicists are thinking and looking all the same.

“It was easy for 125 years,” Strassler said. “One thing led to the next. That lucky century has, for now, at least in the medium term, come to an end. That could change tomorrow, or next century, or who knows.”

A hint of a new lightweight particle could, in theory, show up at the LHC, or in some other experiment. Strassler is particularly excited about the study of radioactive thorium-229 decay, which could reveal variations in the fundamental constants. I’m slightly partial to experiments looking for “axions,” dark matter candidates that are so lightweight that they can act a little like light itself.

On the theory side, an obvious solution to the hierarchy problem could drop naturally out of the geometry behind scattering amplitudes. Or, if Kaplan is right, AI systems might someday suggest powerful new ideas for how the 25 particles of the Standard Model fit into a more comprehensive pattern — a possibility I didn’t foresee back when the crisis began.

Clearly, further progress toward the truth remains possible in particle physics. But there’s no discovery guarantee. I’ve had more than 13 years to think about it, and it remains a disturbing prospect: All the empirical clues we can glean about nature’s fundamental laws and building blocks might already be in hand. The universe may plan on keeping the rest of its secrets.

By , No comments:
Tags , ,
Subscribe to: Posts (Atom)