Where AI-Assisted Development Does Not (Yet) Work

I have claimed a fair amount in this series: that coding is no longer the hard part, that projects get considerably cheaper, that implementation happens in days instead of months. I consider all of it correct. Even so, the series would be incomplete without the article that names the limits. Tell only the good half and the first project that fails will catch up with you.

So: where does it not work?

When nobody can say what is needed

That is the most common case, and it has nothing to do with technology.

AI-assisted development presupposes a description. If nobody in the company can say precisely how a process works – because three people describe it differently, because the rules grew over years, because the only person with the overview left two years ago – then speed does not help. It makes things worse, because you quickly get a lot of software that cleanly implements a misunderstood process.

The solution is not technology but analysis. What matters is knowing that beforehand instead of discovering it mid-project.

When nobody can judge the result

The second case is more dangerous, because it stays inconspicuous for a long time.

A generated solution that runs is not automatically right. It is plausible. The difference between plausible and right is the entire subject matter. If there is nobody on the project who can check a calculation, a rule or a report against the business, then what you get is not software but a guess with a user interface.

That, incidentally, is why I sharpened the claim about the disappearing developer. What disappears is the translation of requirements into syntax. What remains and grows more valuable is the ability to recognise that something is technically correct and factually wrong.

When there is no end to it

What does not work: one person installs Claude Code and assumes good software will now appear by itself. It is not that simple.

It always takes an end-to-end view. From the business analysis through implementation to deployment, including determining the target infrastructure – and above all operations and maintenance afterwards. Cover only the middle part and you have not delivered a project, you have built a prototype.

You do not notice it on day one. You notice it at the first outage, the first security update, the first change somebody has to make who does not know the system. The prototype is still there – only by now a business process depends on it.

When the environment does not keep up with the speed

There are projects where implementation was never the bottleneck. A system replacement where the effort sits in migration, training and organisation. A regulated environment where acceptance and evidence processes set the pace. An integration with systems whose operators need weeks of lead time for test access.

In these cases development gets faster and the project does not. That is not a disappointment if you know it in advance – and quite a disappointment if you started with different expectations.

When availability is missing

An underestimated case: the undertaking is clear, the domain knowledge is in-house – but the person who could answer the questions has a full calendar. If queries sit for three days, the project runs on a weekly rhythm regardless of how fast the building goes.

That is why I now ask before a project starts not only about the goal but about availability. Half a day a week from the right person is worth more than a large budget.

Where it gets technically tighter

That belongs in an honest account too. Anything buried deep in a very specific environment – exotic legacy systems, undocumented proprietary formats, hardware-level interfaces – is considerably more laborious, because the knowledge about it is barely written down anywhere. Very large, organically grown codebases without structure are harder as well, because every change has side effects in places nobody oversees anymore.

None of that is impossible. It is simply not the case where the marketing promises get delivered.

What follows from this

Not that you should leave it alone. Rather that you should answer three questions honestly before starting:

Is it clear what is needed – and if not, am I planning the analysis as a step of its own? Is there somebody who can judge results against the business and has time for it? Is it settled who operates and owns the thing after go-live?

Answer those three with yes and you will experience the speed I write about in this series. Answer one of them with no and that is exactly where to start – not with the code.

The next article is about the third question, the one most readily postponed: what happens after go-live.