Why did Martin Fowler invite 60 engineers to a ski resort?

The event ran under the Chatham House Rule, so I'll share the ideas — but not the names.

Should we still look at code?

Once a factory is fully automated, you can turn the lights off. But should software be built in such dark factories? Should systems be written and maintained entirely by AI, with no human ever reading the code?

This was probably where I saw the largest divide, and the most passionate debates. While most agreed that improving the agent's capabilities is higher leverage than improving the system it builds directly, not everyone agreed that the former can replace the latter.

Some industry experts have shared their experience running systems that are 100% built by AI, although after discussing the specific domains it was clear to me that whether it's viable depends heavily on the context.

It's genuinely viable for transactional backend systems, and it works particularly well for rewriting COBOL (and similar old languages) to more modern systems.

The debate boils down to whether Agents are more like compilers, regenerating code from scratch whenever needed, or more like engineers, maintaining an existing codebase and moulding it over time.

Does this software work?

The sad truth is that our industry has never been good at producing bug free software, but the last year has made this an order of magnitude worse.

GitHub currently struggles to claim even one nine of availability, and I have ended up writing my own video editing tool and my own teleprompter software, because the commercial options kept crashing to the point of being unusable.

AI agents are producing code at a rate that is impossible to review, not to mention that human review is woefully inadequate at catching bugs. So testing is more important than ever.

Where opinions split was on what kinds of tests we should write and review — and whether a detailed enough specification can substitute for them entirely.

In this area my position is firm: the specification should include examples that do double duty as automated tests. In case you are interested in this approach, I suggest watching the second half of this talk.

Does code quality still matter?

Is code that's easy to change the same for humans and AIs, or are those two different things? Should AIs even be required to write in high-level languages — or should they just write machine code?

Regular readers won't be surprised that I was firmly in the camp arguing that code that is good for Agents and code that is good for humans are the same thing.

My two main arguments are these:

• AIs are trained on human readable code, and as a result that is what they understand best
• AIs have a short attention span, hence any strategy that helps humans with short attention spans (including yours truly) is just as beneficial for AI agents.

That also lines up with my experience building and using Habit Hooks. While initially my aim with this tool was to keep code human maintainable, it has ironically nudged me closer to the dark factory camp. Since the agent is keeping the code maintainable, it can make more progress independently, and thus the need for my direct involvement is greatly reduced.

How to manage the risk of Citizen Developers?

In the mid 2010s Robert C. Martin estimated that the number of developers is doubling about every 5 years. If that trend continued, by 2050 every single human on earth - including children - would have to be software developers.

The pessimistic reading on the recent reduction in software engineers being hired is that the profession has become less in demand. The more optimistic read - the one I subscribe to - is that Agentic tools have dramatically lowered the bar for someone to be considered a software developer.

I do want every single person to wield the magical power that is building useful tools just by moulding a system one tiny experiment at a time. The fact that people don't need to wait for me and my fellow engineers to build a tiny simple tool for them is nothing short of miraculous.

However, this also comes with significant risk. The most obvious is security, but complacency — accepting incorrect results as truth — can be just as damaging. And this isn't a theoretical concern: several participants told stories of colleagues in finance and customer service accidentally exposing sensitive data, or making poor decisions on the back of results they trusted too readily.

Becoming a developer has become easier than ever, yet also riskier than ever, and how we manage that tension is a genuinely open question.

But in the end, these are exciting times. We get to focus on the hard problems instead of the toil of building yet another CRUD layer for yet another glorified database client. And we get to imagine a future in which building systems is a commodity — and define what that future really looks like.

Let's build that future together!