As part of my job as CTO Europe, Middle East and India for Thoughtworks I was lucky enough to attend the first Future of Software Engineering retreat at Deer Valley, Utah at the end of January, 2026. This last weekend I was also privileged enough to not only attend but host the sequel FOSE at Engelberg, Switzerland. Just like the first, we ran this as an Unconference. There were more people, but the ask was the same: bring your experience, your questions, your doubts, your belief, and a desire to think about what software engineering means in our new agentic era. I am writing this in an airport on the way home, after three incredibly intense days. These are my first rough thoughts. My mind is buzzing, I’ll have more to follow.
As a caveat for readers and fellow attendees. These are my first thoughts: this reflects the sessions I was in, and I’m barely 24 hours after the end and still traveling home as I write. My thinking will change.
Note: the event was conducted under the Chatham House Rule. I can’t reveal any sources or attendees (unless they also publicly reveal their attendance) but I can reveal what was discussed.
There has been a real shift in just five months
Overall, though it has only been five months, I noticed a real difference between the two retreats. Where Deer Valley had hesitancy and a belief that there was something here even if we weren’t yet sure what it was, Engelberg had confidence: the value is here. As I explained to a colleague today, this was not a conference for true believers: the evidence is in.
What does the evidence say? Well, that was less clear. Some patterns and practices are emerging (one attendee had catalogued dozens of agentic engineering pattern libraries) but they are emerging. There is more work to do to truly establish what is effective, and when.
In comparison to Engelberg, Deer Valley was very focused on the tools: what is possible, how do those tools impact people. Engelberg went broader. With more experience, people were wondering about how the success we’ve now seen plays out not just in teams, but between teams and across companies. How do we avoid one team creating a pricing engine while someone else creates a pricing service? Is it possible to build a context layer that spreads across an entire enterprise? Is that even a good idea? While these are technical groundings, the discussion returned again and again to the social side of the socio-technical system.
What kind of organisation is right for you?
This led to a fascinating discussion about real options for organisation design. The question: is your org an optimiser or a learner?
-
An Optimiser. Your engineering team uses harnesses and agents to be able to change any part of your enterprise. Inbound work arrives automatically in a queue: either from direct customer feedback (synthesized by agents) or from monitoring tools at all layers of the app. Engineers simply take the next piece of work off the rank.
-
A Learner. Your engineering team fractures into pairs: product-oriented and technically oriented. Those pairs situate themselves with the users: by understanding their world and goals, and curating what needs to be done. That pair then uses harnesses and agents to change any part of the enterprise. Inbound work arrives through a highly curated channel.
The first runs the risk of the software equivalent of ‘grey goo.’ That can be mitigated by a continuously evolving central, shared harness of architecture guidance and engineering rigour. The second appears to move more slowly. But learning is the constraint now, not engineering delivery.
The only difference between the two is who owns the stream of inbound work? Data and measurement, or conspicuously humanist curation?
Has engineering rigour found a new home yet?
There is real experience of locating engineering rigour in a variety of places: tests (obviously), BDD making a come-back (did it ever go away?), linting, but also formal models. My experience with formal models has a circularity: I’m not smart enough to write TLA+, so I get Claude to do it. I then get Claude to use that as input to design work, and to verify the program. But is that rigourous? Sam Ruby has already written that his belief that using agents to extract rigour survived contact with the retreat. His example works because he is able to perform whole program type inference, using the semantic understanding of the Rails app. What other ‘higherings’ are possible with agents? For example, don’t manually review your harness after every new model drop (as Anthropic recommends) &emdash; get the agent to do it.
In that vein, while agents can bring all the expertise, they can’t bring judgement. But what does that mean? Well, one idea that kept being repeated was domain modeling. Domain modeling to steer agents, domain modeling to scale teams. But, these aren’t really new ideas. Why hasn’t domain-driven design become the standard way to model teams across an org? Yes, it happens but this is not a solved problem. Why is it suddenly going to work now, when teams are expanding their scope and going faster at the same time?
What still feels unresolved?
Some things I’m still wondering about.
-
Are we going to see harness engineering teams? Yes: these are already emerging. It’s too early to say, but that feels wrong in the same way that DevOps teams were a misunderstanding of DevOps-the-movement. My belief is that while there is friction in having every team create their own harness, that friction is generative and creative. There’s value for your teams there.
-
And following on from that, what’s the equivalent of the DevOps movement for agentic engineering? Does that question even make sense?
-
Finally, the question from Deer Valley remains: is the technical system/code persistent, or is it discarded and re-generated continuously?
And one thing I’m not wondering about: the value is clearly here. Agentic engineering works, and it’s here to stay.