BRAIN Nederland interview: AI makes building software easier — which is exactly why the foundation has to be better

BRAIN Nederland, the Dutch trade association for artificial intelligence, published an interview with our founder Marc Dekeyser this month. Crimson Owl Technologies is a founding member.

Read the full interview on brainnederland.nl → (in Dutch)

The argument

The barrier to building something has, in the interview’s words, all but disappeared in two years. Anyone can now produce working software quickly. What has not changed at the same pace is the architectural, security and compliance judgement that decides whether the thing should have been built that way at all.

That gap is the whole subject. When producing a system costs less, the proportion of total cost that sits in the foundation goes up, not down. A design flaw that once surfaced after months of slow building now surfaces after a fortnight of fast building — in production, at scale, with more of it already written.

The interview puts it more bluntly: right now it is partly the wild west.

What we took from it

Two things in the piece are worth restating here, because they are the parts we act on rather than merely agree with.

An AI system’s output has to be checkable against criteria it did not choose. A model that marks its own homework is not a control. This is the reasoning behind how Platform Architecture Authority works: the assessment criteria are fixed in advance and the result is traceable back to them, so a verdict can be disagreed with on the evidence rather than on trust.

Speed is only worth having if the result is inspectable. The interview describes design work compressing from weeks of discussion to something produced in about an hour. That figure is only meaningful alongside the second half of the sentence — that what comes out can be examined, argued with and rejected. A fast answer nobody can check is not an improvement on a slow one.

Where this shows up in practice

Most of our published work is some version of this argument applied to a specific surface: Azure architecture principles, configuration drift, and what an architecture assessment actually tests that a policy engine does not.

The interview is the general case. Those are the particulars.