Do You Still Need Software Developers?

By Pini Reznik
That's the question I opened with at AI Meetup #2 in Utrecht last Friday. If AI can write code faster than you can, do you still need software developers?
Afterwards, a lot of people came up and said some version of "this is exactly what we're seeing." The conversations were different from the usual post-talk small talk. The market is starting to register this shift, and it's been good to see.
These are the main things I covered.
The CFO who built a real system
I started with an example from inside re:cinq. Our CFO — zero development background, can't read code — built a working internal system for hour tracking and accounting using Claude. It's in GitHub, runs on Google Cloud, and we use it daily. He hasn't looked at the code — he passed that part to our CTO, who actually knows how to build real software.
Getting from something functional to production took about half a day.
What the spectrum looks like now
The talk tried to map out the full range of what's possible today, from non-developers at one end to software factories at the other.

On the non-developer end: tools like Lovable let people with no coding background build applications and websites. My colleague Michael wrote a piece about automating email workflows using n8n — the system reads incoming emails, compares them to previous ones, drafts a reply, and drops it in the draft folder. No development background required. We work with a logistics customer with 200 to 300 trucks, roughly 25 people managing shipment allocation. That kind of workflow — mostly conditional logic running at volume — is a strong candidate for automation that doesn't require a developer.
At the professional developer end, the interesting recent development is software factories. Tools like Gas Town and Loki mode. The idea: orchestrate swarms of specialised agents running in parallel — one for architecture, one for coding, one for testing, one for QA — and merge everything into functional software. You're not writing code in an IDE. You're expressing intent and letting the factory build it.
I used construction as an analogy. With an electric drill, most people can put up a shelf or build a shed. Building your own house is still unreasonable for most. A skyscraper is out of reach entirely. The tools changed. The discipline moved toward harder problems. Software development is following the same path.
What breaks when code gets faster
When AI writes code in 20 minutes, the two-week sprint stops making sense.
The traditional development cycle assumes most of the time goes into writing, testing, and debugging. Planning happens at the start of the sprint, then the team disappears for two weeks to build. When the build takes 20 minutes, that whole structure falls apart — and with it, the two-pizza teams, the sprint ceremonies, the backlog grooming rituals. They were calibrated to a world where writing code was the bottleneck.
We've seen this in multiple companies. Once a team gets efficient with AI-assisted development, the development process starts breaking down and they have to rethink the whole operating model: how features get planned, how teams are structured, how architecture decisions get made.
The direction most teams are moving toward is intent-driven development, or spec-driven development — the two are sometimes interchangeable, sometimes complementary. The developer's job becomes more about expressing intent clearly and validate the final results. The writing becomes a smaller part of the work.
The transformation wave
The last section was about the bigger picture. This isn't the first time a new technology has reshaped how work gets done.
Agricultural labour went from roughly 70-80% of the workforce two hundred years ago to about 2% today. The Industrial Revolution didn't eliminate work — it shifted it. People moved into factories, then into services. The specific people who were displaced had real problems. But broadly, humans adapted.
Cloud-native was a smaller version of the same pattern. It came in a wave, created a period of disruption, and settled into a new normal. Most companies are somewhere in that transition now — microservices, containers, Kubernetes, agile delivery.
The AI wave is following a similar shape, and it's moving faster than any wave I've seen. Whether it behaves differently at the tail, I don't know. My belief is that the models will keep improving, but the bigger change over the next three to five years will be the tooling ecosystem around them. The models matter. The tooling is what will make this land in production at scale.
What that means for timing: the Innovator's Dilemma applies. Jump too early and you're burning investment on technology that isn't ready. Jump too late and someone else has already used it to outpace you. The window for making this move well isn't unlimited.
The full thinking is in the book — including where most companies are on this curve and what the transition looks like in practice. Free digital copy available at the link below.
Table of Contents
The CFO who built a real system
What the spectrum looks like now
What breaks when code gets faster
The transformation wave
Continue Exploring
You Might Also Like
A Pattern Language for Transformation
Browse our interactive library of 119 transformation patterns. Each one describes a specific architectural problem and a tested way to solve it, so your team can talk about real tradeoffs instead of abstract ideas.





