We've Stopped Arguing About Whether · Greg Herlein
Herlein
Home
Posts
About Me
Projects
Resume
Staffing
© 2018-2026. All rights reserved.
Built with Hugo<br>Theme Blackburn
We've Stopped Arguing About Whether
01 Jul 2026, 00:00
ai /
agents /
spec-driven-development /
software-engineering /
future-of-software /
retreat /
knowledge /
thoughtworks
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...