Article
3 reasons why your SDLC has not improved with AI
There is a hadith, recorded by al-Bukhari ﵀, in which the Prophet Muhammad ﷺ is asked how it is that trust comes to be lost. The answer is that when a matter is entrusted to those unfit for it, then you may await the Hour. It is one of the signs given to us for the end of times, and it is stated with no ambiguity at all: the people who do not know will be the ones deciding.
You do not have to share my tradition to recognise the shape of the thing. Look at almost any failure in enterprise software over the last two decades and trace it back far enough, and you will arrive at a decision made confidently by somebody who did not have the knowledge to make it, and who was never going to be present for the consequences. That is the ultimate cause. Everything else is mechanism.
Artificial intelligence has not changed this. It has only made it faster and cheaper to act on an unqualified decision. That is why so many organisations can honestly say that they have rolled out copilots to every engineer, run three agentic pilots, bought the enterprise tier — and cannot honestly say that anything downstream of that has improved. Not cycle time. Not change failure rate. Not the number of Fridays somebody spends restoring a service.
There are many reasons for this. I want to deal with three.
1. The tool does not travel left to right
We draw the software development lifecycle as a line. Business analysis, then solution architecture, then engineering, then test, then release. It is drawn left to right because that is how we read, and because a line implies that each station hands a finished thing to the next one.
So when AI arrived, the assumption was obvious and almost nobody stated it out loud: put a copilot at every station and the whole line moves faster. Each role produces its artefact more quickly, each artefact arrives sooner at the next desk, and the compression at each station adds up to compression overall.
It does not work, and the reason is not that the tool is weak. It is that the line was always a diagram of sequence, never a diagram of knowledge.
A business analyst can now produce a forty-page requirements document in an afternoon. The document is fluent. It is complete in form — sections, acceptance criteria, edge cases, a glossary. What it is not is decidable. An engineer reading it still cannot tell which of six plausible implementations is the one that survives contact with the existing data model, the authentication boundary, the latency budget and the two other teams who own half of the write path. That knowledge does not exist at station one. It has never existed at station one.
Before, the thinness of the document made the gap obvious. Nobody was fooled by three bullet points; the engineer walked over and asked. Now the fluency of the document conceals the gap. Nothing has been closed. It has been upholstered.
The same happens one station further along. The architect generates a richer design, faster, on top of an amplified guess. By the time it reaches an engineer, there is far more material to reconcile and exactly the same number of unanswered questions — except that the questions are now buried in prose that reads as though somebody had already answered them.
The direction that works is the other one. The person AI genuinely multiplies is the person who already knows what the end result has to be, and can therefore work out what has to go in to get the right output. That person can write the constraint precisely, read the answer critically, and throw away nine of the ten things they are offered. They get a real multiple, because their judgement is the scarce input and the tool has removed the typing around it.
Everyone upstream of that person gets a volume multiple on guesswork.
This has a practical consequence that most organisations have not drawn. If value is pulled backwards from the outcome, then the specification is not an artefact to be handed forward — it is a thing written with the person who knows what production demands, or written after they have said it. Collapse the stations rather than accelerating each one. Put the engineer in the room while the requirement is formed. State the definition of done as a verifiable property of the running system, not as a paragraph of intent. Then let the tool loose on the part that is genuinely mechanical.
An organisation that keeps the handoffs and adds AI to each one has not built a faster line. It has built a louder one.
2. Nobody agreed what the gains were for
Here is a conversation that has never taken place in most companies, and which decides the outcome of the entire investment.
Management does the arithmetic one way. If a day’s work now takes two hours, that is four times the output. Four times the roadmap, four times the throughput, the same headcount, and — this part is rarely said, but it is always in the room — possibly less headcount. The commitments to the board get revised upward on that basis. Sometimes before a single pilot has reported.
The engineer does the arithmetic the other way. If a day’s work now takes two hours, then the day is now two hours. The remaining six are recovered, spent on the backlog of things that were never funded, or spent quietly on nothing at all. This is not laziness. It is the rational response of someone who has watched every previous productivity gain get absorbed into the baseline and rewarded with a larger baseline.
Both parties are being reasonable within their own frame. The frames are directly opposed. And because neither has been stated, nobody experiences it as a disagreement — they experience it as the other party being difficult.
What makes it worse is that both numbers are fictional anyway. The engineer’s day was never eight hours of typing. It was reviews, waiting on an environment, a production question, a meeting that could have been a message, a decision escalated three levels and returned unchanged. If writing code was thirty per cent of the day, then compressing that thirty per cent by eighty per cent moves the day by twenty-four per cent — not by four hundred. Two groups of people are negotiating hard over a surplus that mostly does not exist, while the actual constraint, which is decision latency and the sprawl of coordination, has not been touched by anything anyone bought.
This is what a value stream exercise is for, and it is the step almost universally skipped. Not the workshop, not the poster — the actual question: what are we trying to buy with this? Throughput? Cost? Cycle time? Defect rate? Faster onboarding for new engineers into an unfamiliar codebase? Fewer people? These are different objectives requiring different measures, and some of them are in tension.
Say it out loud, and say what the surplus is for. If some of it goes back to the business as throughput and some goes to engineers as slack for the maintenance nobody funds, that is a legitimate bargain and it can be honoured. If all of it is being claimed by one side, that is also a decision — but make it in the open, because the other side is going to respond to it either way. What cannot work is leaving it unsaid and then being surprised, two quarters later, by inflated commitments on one side and quiet withdrawal on the other.
And pick a measure that cannot be gamed by the tool itself. Lines of code, pull requests raised and story points are now trivially inflatable and are being trivially inflated. Cycle time from commitment to production, change failure rate and time to restore are harder to fake, because they are all measured after the artefact has left the building.
3. Knowledge did not stop mattering
The third reason is the one closest to the beginning of this piece, and it is the one that will still be true when the current tools are two generations obsolete.
Getting something done and knowing how to do it right are two different things. They have always been two different things. Software delivery is the field where the distinction is most brutally obvious and most consistently ignored, because for a short window after delivery the two are indistinguishable. The feature works. The demonstration succeeds. The difference between the version that works and the version that is correct does not present itself for another six months — as a schema that cannot be migrated, an authorisation model that cannot be extended, a retry that silently double-charges, a queue that has no idea what to do with a message it has seen before.
AI is extremely good at producing the first kind. It will produce something that works, quickly, and it will describe it confidently. What it does not have is your production incident history, your regulator, your data residency obligation, your one strange upstream that returns 200 with an error in the body, and the three architectural decisions you are still paying for from 2019.
Knowledge is what tells you the difference — and, crucially, it is what makes the tool usable at all. You cannot ask for what you cannot name. Idempotency, isolation levels, backpressure, ordering guarantees, blast radius: these are not vocabulary, they are the handles by which a problem is picked up. An engineer who does not have them cannot instruct the model to avoid the failure, and cannot recognise that the answer in front of them has walked directly into it.
Which brings us to the part that senior people consistently underestimate. Reviewing generated code requires more knowledge than writing it, not less. When you write something yourself, you arrive at the final line having reasoned through every decision on the way; the review is largely a memory exercise. When you review generated code, you are reading unfamiliar work, at volume, without any of that reasoning, and you have to reconstruct the intent before you can judge the result. Organisations have handed that task to their least experienced people on the grounds that the tool has made the work easy. It has done the opposite.
So the leaders and the teams who treat software delivery like pizza delivery — an order goes in, a box comes out, the only interesting variable is how fast — are exactly as wrong as they were before. AI has not corrected them. It has equipped them.
What they get is bigger and faster disasters. This is the part worth sitting with. In the old failure mode, a badly conceived programme took eighteen months to become visibly bad. That was slow enough to be survivable in a career sense: there was time to reorganise, rename the programme, rotate the leadership, absorb it into a transformation. The same misconception now reaches production in six weeks, across ten times the surface area, because the mechanical work that used to act as a brake has been removed. There is less time to cover it up and less time to recover. The failure arrives before the story about the failure is ready.
Back to where we started
None of this is an argument against the tools. I use them daily, and the leverage is real where it lands on someone who knows what they are doing. That is the whole point: the leverage lands on knowledge, and where there is none, there is nothing to leverage.
So if your SDLC has not improved, I would not begin with the tooling, the licences or the pilot. I would ask three questions, in this order.
- Direction — who in this organisation actually knows what the end result must look like in production, and are they present when the work is defined, or are they receiving a document at the end of a line?
- Alignment — has anyone stated, in one sentence, what the gain is for and who receives it? If two answers exist and neither has been said aloud, that is the state you are in.
- Knowledge — are the people reviewing the output qualified to reject it? If reviewing has become approving, the tool is not producing throughput, it is producing exposure.
These are not tooling questions. They are questions about who is deciding and whether they know. Which is where we came in — and which is why I am not especially optimistic about the industry-wide answer, however good the tools become.
— Meezaan-ud-Din Abdu Dhil-Jalali Wal-Ikram, founder of Mamluk