An AI-native SDLC is about transforming the organisation, not the tools

For obvious reasons, most companies now want an AI-native SDLC (I prefer the term AI-driven SDLC, but it is still less popular). And an unpleasant surprise is waiting for them here: their current architecture, processes and teams are often simply not ready for such a change. They were built for a completely different reality, resting on two fundamental limits: “writing code by hand is slow and hard” and “people can master and maintain only a narrow range of knowledge”.

If you want to go faster, you need to work in parallel. To work in parallel, you need more people. People have narrow technical skills, so you need different developer specialisations. Since they work on the same feature, you have to bring them together into teams. The business has neither the time nor the desire to prepare good artefacts for development, so let’s add extra roles such as a business analyst or a project manager. On top of their narrow specialisation, developers can’t check their own work objectively. Let’s add QA engineers to the team. And there you have it: the modern development team of FE, BE, QA and extra roles.

Now development processes grow up around this team. Since we in IT never learned to share information well (nobody likes writing documentation by hand, and keeping it up to date is hard), we get together in countless meetings and talk things through. Since development takes a long time, we have to plan more carefully where to spend our effort and when to expect results. Even more meetings appear. When people work on a feature in parallel, their efforts need to be synchronised. Here come the task trackers, chats, daily stand-ups and the other familiar attributes.

I could go on for a long time, but I hope you’ve caught the general chain of cause and effect. Now imagine that both fundamental limits no longer apply. With AI tools we can generate code of any complexity very quickly and draw on knowledge of any breadth. Can we really fit AI effectively onto the existing reality in companies and get a several-fold speed-up?

I very much doubt it. And practice shows that the results fall far short of expectations. Developers start generating several times more code and put a huge load on the testing stage, which in most companies is still manual or semi-manual, with a focus on end-to-end testing. That brings a whole bundle of new problems, from scaling environments to cutting manual testing down in a hurry. If the business still doesn’t take part in development, an even funnier effect appears: “slop generation”. In the past, during long development, the team had extra questions for the business, and the answers were found before the work was done. Now LLMs can fill every gap with guesses or assumptions and then generate a solution from them. The more such gaps there are, the further the solution drifts from what the business expects. These are just a couple of examples of the effects to expect.

So which companies will an out-of-the-box AI-native SDLC help reach a new level of productivity? Those that already have practices such as a service architecture split along domain lines, Continuous Delivery, a QA strategy aimed at maximum automation, small domain teams with an engaged PO, easily scalable infrastructure and so on. In other words, AI once again makes the strong several times stronger and does little for the weak.

That’s why adopting an AI-native SDLC is not about AI tools and models but about transforming the organisation from within. And that is an order of magnitude harder than adopting new tools.