We've Stopped Arguing About Whether

I just spent a few days at a retreat on the future of software development. Small rooms. Unconference format. Some of the sharpest people in our industry - the kind of names that show up on the spines of the books on your shelf. I’m not going to tell you who was there or who said what. We ran the whole thing under Chatham House Rule: use what you learn, attribute none of it. This is my initial take-away.

The event was the Future of Software Development Retreat Europe, hosted by Thoughtworks (and Martin Fowler) at the Kempinski Palace in Engelberg, Switzerland. Small-format, highly participatory, sold out. That much is public - so I can tell you the where. The Chatham House Rule covers the who-said-what, and that part stays in the room.

Everything below is only my opinion and my interpretation of what I heard and who I happened to talk to. A different attendee sitting three chairs over might write a different post. I’m not reporting consensus. I’m telling you what stuck in my brain. We’ll see how my take compares when the retreat report is issued by Thoughtworks.

Here’s the first thing that hit me, and it hit me hard.

Reading the reports of the February event, when a lot of these same folks last got together, the conversation was about what agentic development might look like. Aspirational. More about what was coming.

This time? Everybody in the room was doing it. Shipping it. Not slides - production. The whole debate about whether this changes software engineering is over. People have stopped arguing about whether a while ago. They’re arguing about how, and the how is getting real.


The center of gravity is moving. Many are still standing where it used to be.

The Center of Gravity Moved

If I had to compress the whole retreat into one sentence: the work is moving from writing code to specifying, verifying, and curating knowledge.

The code isn’t the point anymore. The spec is the point, and the agent executes against it. And the new quality bar isn’t “is it elegant” or even “is it code” - it’s “is it verifiable enough.” If you can verify the thing does what it’s supposed to, the form of the artifact stops mattering. Code or not code. Who cares. Does it pass?

Now - big caveat, and this is where I have to be honest with you. That framing is not settled. There was real, unresolved debate in the room about whether code is now ephemeral - a disposable byproduct the agent regenerates from the spec whenever it wants - or whether the code is still the thing that matters. A surprising number of very smart people argued the opposite of my one-sentence summary: that the code is the better spec. Their point: code is the only artifact that’s unambiguous, executable, and - this is the big one - deterministic. A prose spec is fuzzy and an agent will interpret it a little differently every time you run it. The code runs the same way every single time. So why would you treat the precise, deterministic thing as throwaway and the fuzzy thing as sacred? That’s a hard argument to wave off, and it ties directly into a theme I come back to below: everything that has to be deterministic still needs Engineering. There’s no consensus here. None. I lean toward spec-as-center, but I heard the code-is-truth camp loud and clear, and they’re not wrong to push. Reasonable, brilliant people are genuinely split, and I don’t think this gets resolved soon.

Either way it lands us squarely on the hard problem nobody has fully solved: how do you know the software is doing what it’s supposed to do? Testing, but bigger than testing. That’s the frontier now, not autocomplete.

The proof point that’s been rattling around my head is public knowledge, so I’ll say it plainly: 6 engineers rebuilt the Amazon Bedrock engine in 76 days - work that had originally been scoped at roughly 40 engineers for a full year. That’s AWS’s own number, using their agentic AI-DLC method and Kiro. Do the math: something like 40 person-years of work compressed into a couple dozen person-months. That’s not a productivity bump. That’s a different physics. (AWS wrote it up if you want the details.)

The game is radically changed, and there are many who don’t even know it - or won’t believe it. My take? I still think that if the Engineering framework is right, the code becomes ephemeral. And the “Engineering” moves from the code into the framework. More on that in following posts.

Knowledge Is the Bottleneck. Not Code.

The scarce thing was never code. It’s knowledge - the tacit stuff every team carries around in its head and never writes down. Why we did it this way. What we tried that didn’t work. The landmine in that module that Dave-who-left knew about and nobody else does.

Agents are starving for exactly that context, and we’ve spent decades not writing it down. In fact, the senior Engineers in the org have outsized value because they have that stuff in their heads.

The fix that kept coming up: have the agents generate the learnings themselves - summarize each session, aggregate it, feed it back into the next one. “Docs are now MCP and have the agents rebuild that.” Documentation stops being a PDF nobody reads and becomes a live thing your agents query. And the single most valuable thing to capture isn’t what the code does - the code already says that - it’s why the decision was made. The why is the gold.

Which means the real challenge is sharing it at scale. Everybody wants an “enterprise knowledge layer.” Nobody’s quite built the good one yet. (I’ve been chewing on this one for a while, so I felt very seen.)

The Junior Pipeline Is In Trouble

If the agent takes the implementer role - and it is - then we are no longer growing bug fixers. That entry-level rung where you learned the craft by grinding through tickets? Agents are eating it. So where do the seniors of 2035 come from?


We're pulling up the ladder we all climbed. Then wondering where the climbers went.

The scarce, valuable, brutally-hard-to-teach skills are now judgment, taste, and troubleshooting. And I have no idea how you teach those to someone without letting them do the grunt work first. The room floated apprentice models, pairing, rotation. Nobody had the clean answer. I don’t either. But if you lead a team, this is your problem now, not HR’s.

The Stuff That Doesn’t Change

Two things grounded me in the middle of all the future-shock.

First: everything that has to be deterministic still needs Engineering. Capital E. Same input, same output, every single time, no variance. Agents are wonderfully, terrifyingly non-deterministic. So the discipline of building things that don’t surprise you. We absolutely still need the ability to change (agile) and the resilience to change (all the devops “ilities”) - those aren’t going away. If anything they matter more when a probabilistic thing is writing your code. (My submarine reactor did not do “usually.” Neither should your payment system.)

Second, and this is the one I keep turning over: knowledge retrieval for agents is a wide-open frontier. How do you weight sources? Push or pull? Graphs turn out to be roughly as accurate as vector search but faster and cheaper in tokens - a graph as index and agent memory. And the question I loved most from the whole retreat:

What is PageRank for agents?

Whoever figures that out cleanly is going to matter a great deal. It’s the same knowledge-sharing problem from two sections up, wearing a different hat.

The Session I Missed Scared Me the Most

This is an unconference. You propose topics, they get slotted, and inevitably two things you care about land in the same slot. I proposed a session, it ran opposite the one on security, and I can’t be in two rooms at once. So I picked mine and missed the security one. Too bad, I’d have liked to be there.

Because people came out of that room rattled. Not junior folks looking for something to worry about - some of the most senior, most seen-it-all people at the whole retreat, the kind who don’t spook easily. They walked out saying, more or less, that they were terrified. And when those people use that word, you pay attention.

I wasn’t in the room, so I won’t pretend to relay the specifics. But I don’t need the transcript to connect the dots. Think about everything above: agents writing the code, code as a disposable artifact regenerated on demand, a probabilistic thing making a thousand decisions a second that no human reads line by line. Now put an adversary in front of that. The attack surface isn’t your code anymore - it’s your spec, your prompts, the agent skills, your knowledge layer, your agents’ tool access, the supply chain feeding all of it. We are wiring autonomous, non-deterministic systems straight into production, and the security models we lean on were built for a world where a human wrote and reviewed every line.

So yeah. Count me terrified too.

The answer isn’t to panic, it’s to do the work. The game of running your own pen tests, red-teaming your own systems, attacking your own stuff before someone else does - that game just got a whole lot more real. If agents can build at this speed, agents can break at this speed, and you had better be the one pointing them at your own defenses first. This stops being a specialist’s job you outsource periodically and becomes something you bake into the loop, continuously. I don’t think most of us are anywhere near ready for that.


The people who don't spook easily walked out of that room spooked. So did I, secondhand.

The Gap Is Widening. Maybe Forever.

I’ll close on the observation that sobered the room.

Adoption compounds. Organizations that are ahead use agents to accumulate knowledge, skills, and velocity - which lets them pull ahead faster. It’s a flywheel. And the genuine fear in the room wasn’t “some companies will lag.” It was that the slowest laggards might fall so far behind that they never catch up. The gap stops being a lag you can close with effort and becomes structural. A moat you’re on the wrong side of.

And here’s what turned that from a theory into a cold feeling in my gut: this isn’t a projection. One of the people in the room described an organization of thousands of engineers already doing spec-driven development at scale. Not a pilot. Not a lighthouse team of ten enthusiasts. Thousands. Already. While a lot of the industry is still debating whether any of this is real, somebody has already rolled it out across an org bigger than most companies. That’s the flywheel, spun up, in production, today. The lead isn’t coming - for some, it’s already here, and it’s already big.

There’s a money version of this too: the firms that operationalize genuinely agentic development early get a valuation premium - but it decays as everybody catches up, and eventually the sign flips. It stops being a bonus to have it and becomes a penalty not to. Same story the software people were telling, just told by the finance people.

So What Do I Do Monday?

Look - I walked out of that room energized and a little rattled, which is exactly how you should feel when the ground moves.

Here’s my honest takeaway. Stop obsessing over the code. Start obsessing over three things: the spec (that’s where your taste lives now), verification (how do you know it’s right), and knowledge (write down the why, and make your agents help you do it). And if you manage people, go figure out how you’re going to grow the next generation, because the old ladder just lost its bottom rungs.

The whether is settled. It’s all how now.

And the how is up to us.

What are you seeing out there? Drop me a note on LinkedIn - I’m genuinely trying to figure this out alongside everyone else.


A sincere thank you to Thoughtworks for hosting this. Pulling this particular group of people into one room and running it this well is not easy, and the timing could not be more critical - this is exactly the conversation our industry needs to be having right now. Thank you for making the space for it. It mattered.

 Share!