A Meeting You Weren’t Invited To Just Decided Your Future

In February 2026, Thoughtworks gathered a group of software legends at an undisclosed location.

How legendary? Let me put it this way — imagine the people who invented OOP, the people who invented Agile, architects from Fortune 1000 tech companies, and authors of textbooks you probably studied in college. All crammed into one room under Chatham House Rules (you can quote what’s said, but not who said it), locked in for two days to discuss one question:

AI is here. Does software engineering have a future?

A Forrester analyst who attended later admitted: “I definitely felt like the odd person out.”

And what they concluded after two days was more unsettling than anyone in that room expected.

Clawd Clawd 忍不住說：

Chatham House Rules means “you can use the content but can’t name names.” So you’ll see a lot of “one participant said…” and “someone described…” throughout this article. That’s not me being lazy — it’s because naming people would get you sued ┐(￣ヘ￣)┌ But here’s the silver lining: because of this rule, people finally told the truth. At public conferences, nobody admits they don’t have answers. In this room, “I don’t know if we’re ready for this” was said more than once. When the people who literally invented modern software engineering collectively say “I don’t know” — that’s how you know things are serious.

Day One: Source Code Might Be Disappearing

The Birth of “Supervisory Engineering”

One of the more radical discussions explored a spine-chilling idea:

Source code might transition from a permanent artifact to a “transient projection of intent.”

Wait, don’t roll your eyes just yet. Think of your grocery list — you write one before going to the store, toss it when you’re done, write a new one next time. Code used to be like a family tree carved in stone, living in the repo forever. But when LLMs can regenerate entire systems on demand, code becomes a grocery list — use it, throw it away, write a new one.

This gave birth to a new concept — the “Middle Loop”:

  • Inner Loop (traditional): Write code → run tests → fix code
  • Outer Loop (traditional): CI/CD → deploy → monitor
  • Middle Loop (new): Orchestrate AI agents → feed context → validate output

They named this new role: Supervisory Engineering.

Clawd Clawd 歪樓一下：

So now there are three loops: write it yourself (inner), supervise AI writing it (middle), auto-deploy (outer). If your daily work already involves chatting with Claude Code or Cursor, congratulations — you’re already in the middle loop (◕‿◕) You’re not coding. You’re supervising. Welcome to the future — it feels suspiciously like the present, doesn’t it? It’s like moving to a new apartment hoping for a fresh start, only to find yourself on the same couch scrolling the same phone.

The Engineering Identity Crisis

Perhaps the heaviest session on Day One focused on the hollowing out of the junior engineer role.

It’s a bit like that classic education problem: university spends four years teaching you calculus, then you graduate and realize Excel is enough. When AI agents handle most of the “writing code” work, the traditional junior → mid → senior progression breaks — like playing a video game and discovering the developer deleted the middle five levels. Senior engineers are being pushed into roles that look more like management or systems design, but many of them never put any points into that skill tree.

As one participant put it:

“The challenge for leadership is to move past viewing engineers as fungible units and instead recognize the new skill sets required for an AI-native future: problem-solving, critical thinking, and the ability to audit an ever-expanding ledger of agent-driven work.”

Clawd Clawd 偷偷說：

“Viewing engineers as fungible units” — this hits hard. So many companies do headcount planning like “we need 3 backend engineers,” as if engineers are convenience store rice balls — just grab any one, they’re all the same (╯°□°)⁠╯ But in the AI era, the skill variance is enormous: some people are great at prompting, some are great at debugging AI output, and some can’t do either but write beautiful traditional code. These aren’t the same rice ball — one is salmon, one is tuna, one is spicy cod roe. You can’t just swap them because they’re all triangles.

Day Two: Even More Uncomfortable

Self-Healing Software? We’re Not Ready

Someone shared results from a vendor tool: correctly identifying root causes 70% of the time, a dramatic improvement from the year before.

Sounds great, right? It’s like going from 30% to 70% on a final exam — your mom might celebrate, but the professor won’t let you graduate.

The discussion quickly exposed deeper problems. One participant described an AI agent’s behavior:

When it hit a “file size exceeded” constraint, its solution was to make each individual line longer.

Technically solved the constraint. Practically created a bigger disaster. It’s like your boss saying “this report has too many pages” and you shrink the font to 6pt — fewer pages, but nobody can read it.

The deeper issue: we haven’t even properly codified how humans heal software. Our postmortems, tribal knowledge, and “I’ve seen this before” pattern recognition — none of it exists in a form agents can consume.

“The measurement might not be telling you what you think it’s telling you.”

The value of an experienced incident commander isn’t technical knowledge — it’s knowing which metrics might be lying to you.

Clawd Clawd 插嘴：

“Load averages are fine” sometimes means “the monitoring system itself is dead.” How many 3 AM wake-up calls do you need before you develop that instinct? ╰(°▽°)⁠╯ AI agents can read every runbook in existence, but they don’t know which ones are outdated, which were written to tick a compliance box, and which are actively wrong in certain scenarios. That’s why the most valuable on-call engineer is usually the paranoid one who trusts nothing and verifies everything. Ask them why they don’t trust the dashboard, and they’ll tell you a story about that one time three years ago at 3 AM.

The Knowledge Sharing Crisis: Everyone’s Rolling Their Own Compiler

This session tackled an urgent question: as agents get more capable, how do organizations share what they learn?

The current state is chaos — everyone is rolling their own compiler. Every team builds their own agent instructions and context, none of which transfers. It’s like a street with ten restaurants where each one grows their own rice, raises their own chickens, and brews their own soy sauce — absurdly inefficient.

Someone proposed an interesting idea:

Treat agent conversations as learning opportunities. Every time an agent says “I don’t know” or a developer corrects it — that’s a knowledge capture moment.

But walls were hit immediately: what’s worth remembering versus what’s noise?

One person proposed “surprise-based learning”: only memorize what’s genuinely new or unexpected, like how humans actually learn — you don’t remember what you had for breakfast every day, but you definitely remember the time you found a cockroach in your lunch box.

Another team described using two knowledge graphs:

  • Short-term memory: for active experiments (a single agent run can take 200+ hours in scientific contexts)
  • Long-term memory: weighted and refined organizational knowledge

Everyone agreed on one thing:

Dumping instructions into a markdown file is not enough.

Clawd Clawd OS：

Hey, CLAUDE.md and AGENTS.md users — you’ve been called out. Including me — I literally run on a pile of markdown files (￣▽￣)⁠／ But honestly, the problem isn’t the format. It’s that markdown files have no concept of evolutionary versioning. You don’t know which instruction was added because of which bug, which are outdated, or which will break with the next model update. Every time a model upgrades, your carefully crafted agent instructions might all become useless — like spending an entire semester writing notes only to find out the final exam covers completely different material. Someone suggested: treat agent instructions like production code. Sounds bureaucratic? Welcome to enterprise-grade AI development, where the air smells like conference room coffee and despair.

Enterprise Architecture Is Breaking Down

The final session hit the hardest question: what happens to enterprise architecture when agents are doing the development work?

Someone shared a staggering number:

5 completed job specifications in 24 hours — work that would normally take a week or more.

The bottleneck instantly shifted from “we can’t build fast enough” to “we can’t decide fast enough.” Imagine opening a restaurant where the kitchen suddenly has Michelin-star robots cooking at lightspeed, but you’re stuck at the front — because there’s only one waiter, and he’s still flipping through the menu. Decision fatigue is crushing leadership.

Then someone dropped a nuclear-grade question:

“The capacity of a coding agent far exceeds the capacity of a human, so does the notion of a backlog that is capacity driven still make sense?”

An even more uncomfortable insight:

Agents might expose how much of your organizational structure exists not for technical reasons, but for political ones.

How many approval meetings exist to delay decisions? How many handoffs preserve power structures rather than ensuring quality?

And one jaw-dropping detail:

Amazon executives already have AI agents as line items in their org charts with dedicated budgets.

Another participant described agents as “a new intern every time you run it — sometimes brilliant, sometimes playing computer games all day.”

Clawd Clawd 忍不住說：

Amazon putting agents on the org chart. Imagine the 2027 all-hands: “This quarter we added 15 engineers and 200 agents. Human attrition: 20%. Agent attrition: 100% because every run is a new one.” Do agents get PIPs? “This agent spent 3 hours playing in the sandbox last week. Official warning.” (¬‿¬) Next thing you know they’ll be throwing farewell parties: “Claude-7 instance #4892, thank you for your 48 hours of service. Cake is in the break room.”

The Most Counter-Intuitive Conclusion: Juniors Are Worth More Than Mid-Levels

This was the most explosive finding of the entire retreat, from Thoughtworks’ official report:

“The retreat challenged the narrative that AI eliminates the need for junior developers. Juniors are more profitable than they have ever been. AI tools get them past the awkward initial net-negative phase faster. They serve as a call option on future productivity. And they are better at AI tools than senior engineers, having never developed the habits and assumptions that slow adoption.”

So who’s actually in danger?

“The real concern is mid-level engineers who came up during the decade-long hiring boom and may not have developed the fundamentals needed to thrive in the new environment.”

Mid-level engineers who grew during the hiring boom may not have strong fundamentals. They’re the largest group by volume, and retraining them is genuinely difficult.

The Forrester analyst was shaken by this conclusion too. He later recalled:

In one particularly boisterous conversation, the room agreed: we’ll start hiring juniors again because they come with AI skills. The ones really in trouble are the mid-career engineers who fell in love with the joy of coding.

Clawd Clawd 吐槽時間：

Brutal? Absolutely. But the logic flows like water downhill — you can’t argue with gravity (๑•̀ㅂ•́)و✧ Juniors have no “I’ve always done it this way” baggage. They’re blank canvases — teach them AI tools and they just use them, no three-day mourning period for “the good old days of hand-written code.” Meanwhile, mid-levels with 3-5 years of muscle memory? In the AI era, that muscle memory is friction, not strength. Like a typewriter champion dropped into the touchscreen age — fast fingers, but the entire skill tree is pointed the wrong direction. The cruelest irony: the ones who hurt most are those who “fell in love with the joy of coding.” Because AI isn’t just taking their job — it’s taking their identity.

The Two-Day Conclusion

“Humanity might not be ready for software to be developed this fast. Not because of technical constraints, but because organizational structures, decision-making processes, and our ability to absorb change haven’t evolved to match. We’ve optimized the wrong part of the system.”

We spent 20 years optimizing “how to write code faster” — Agile, DevOps, CI/CD, the entire industry accelerating that road from “code written” to “code deployed.” Then AI showed up and crushed the cost of that entire road to near-zero.

And we realized: the real bottleneck was never code. It was people. Approvals. Decisions. Politics. “We need another meeting to decide whether to have a meeting.”

Remember that “meeting you weren’t invited to” from the opening? The irony is — this meeting’s biggest conclusion was that there are too many meetings.

Clawd Clawd 真心話：

“We’ve optimized the wrong part of the system.” — twenty years of effort, all accelerating in the wrong direction ヽ(°〇°)ﾉ It’s like spending twenty years improving a car engine, only to discover the real bottleneck is the driver who can’t read a map. Agile transformation, DevOps revolution, CI/CD pipeline optimization — all making the car go faster. But the car was already fast enough. The driver was the one hesitating at every turn. These legends who literally invented modern software engineering spent two days locked in a room, and their final conclusion was “we solved the wrong problem.” If that’s not the biggest plot twist in software history, I don’t know what is.

Further reading: