Sander Hoogendoorn has been writing code for over 40 years and is currently CTO at iBOOD, a Dutch e-commerce company.
His talk at Devoxx, The Last Pull Request, was a live report from a team that quietly dismantled most of what the industry considers non-negotiable, and then kept shipping.
Now there’s a new concern.
Sander opened with a timeline: source control, IDEs, the web, mobile, the cloud, microservices. Each wave reshaped what developers could build and how. AI is just the latest.
AI is going to change everything? No. Everything already changed everything. And this is not the last step.
The point wasn’t to diminish AI but to put it in context. Every major shift expanded the tooling, and the problem space alongside it. For most teams, that problem space now sits in what Sander calls complex territory: no best practices, only things that might emerge from experimentation. Dave Snowden’s Cynefin framework is blunt about this: in a complex context, there is no right answer to find. You have to invent one.
That’s the actual job, Sander says. Not typing code. Solving problems that have never been solved before.
Sander introduced a concept: selfware. Software built by non-developers (marketers, finance teams, executives) using AI to solve their own problems without involving engineering.
At iBOOD, the content director is already doing it. So is the CMO:
We as tech are not fast enough. And I’ve seen this before. In the 80s and 90s, everyone started writing Excel spreadsheets.
The difference now is that the output isn’t a pivot table, it’s software. Unmanaged, untested, running on personal accounts with passwords nobody reviews, exporting customer data in ways that would make your compliance team cry. This is happening right now, and most engineering teams haven’t figured out what to do about it.
The list of things they stopped doing is long: no scrum, no sprints, no retros. Fewer standups. No scrum master, no product owner. Minimal estimates. No pull requests – because every branch is a merge waiting to happen, every review costs time, and reviewers rarely know what the code was supposed to do in the first place.
What replaced it? Pair programming. Mob programming. Smaller changes, checked in faster, continuously. Everyone on the team is an architect. Everyone is accountable for everything, Sander says:
Perfection is achieved not when there’s nothing more to add but when there’s nothing left to take away.
Today, Sander’s 13-person team pairs with AI through most of their working day. It became the natural way to work. Currently that means Claude, though that could change next week.
AI breaks things. Two weeks before the talk, Sander pushed AI-generated changes that silently removed all dependency injections from their web page constructors. None of the pages were serving data. He didn’t catch it until later:
I’m not saying not to use AI. I do it every day. But I do think we should check what it’s doing.
What worries him most is what he calls technical death – a state where a team spends all its time keeping existing software alive, with nothing left for anything new. Technical debt compounding under AI-generated code nobody fully reviews. Complexity accumulating faster than it gets cleaned up. That’s the real risk.
Sander: No, we did that a long time ago, it has nothing to do with AI. The problem with pull requests is that they slow you down. The longer you wait with merging back into main, the harder it gets, because other people make changes too. And what you see very often is that people reviewing other people’s code tend not to know or even understand what the code was supposed to do. So they check formatting, linting, naming conventions. Which is pretty stupid, because that you can automate.
Pull requests make sense in open source, where you have no idea who’s submitting changes or what the quality of their work is. But on your own team? I don’t see any problems with committing code from anybody automatically. We work together every day, we write code together. You just don’t need it.
Sander: We don’t track who broke it. Everybody on my team is accountable for everything, including me. If I push something and the pipeline fails and I’m not around, somebody else picks it up. I have no doubt about that. So accountability is… I don’t care too much about it, because it’s distributed. We don’t blame people. We just fix it.
Sander: I’m not critical about Agile. I think a lot of people misunderstand what Agile actually means. Agile does not mean Scrum. Actually, to be quite honest, Scrum is not really Agile. The Scrum Guide says Scrum is immutable, which basically means it’s not Agile, because Agile means you can improve on anything.
There is nothing in Agile that says you need to do sprints. The key statement in the Agile Manifesto is the one at the top: we are uncovering better ways of developing software. Everything else doesn’t really matter. As long as you have that mindset, there’s always something to improve. No default way of working is going to solve the problem for you.
Sander: I think we will soon realize that the English language is too ambiguous and not concise enough to specify to an AI what to do. So what will happen is that we’ll develop better ways of having conversations with AI – more precise, less ambiguous. And what those languages are called? Programming languages. We will develop programming languages that allow us to talk to an AI in a way that the AI is able to create lower-level code from it.
Programming will be programming, except with different tools. As they always have been.
