Open any serious platform for project work and search for one phrase: "about 90 percent done". You will find it in listing after listing. The app is almost finished, it just needs completing. The prototype works, it just needs stabilising. Someone has already done most of the work, all that is missing is someone to close the rest.

Those listings have always existed. There have never been this many. And that, to me, is the most honest picture of what is happening to software development right now. Not the demo videos, not the conference talks, but that queue of products that got to ninety percent and stopped.

What I learned about transitions

I have been building software for twenty-five years. That is long enough to stop believing in revolutions and start treating them as weather. They arrive, they pass, they leave something behind. I have been through several, and every one of them was announced, in its moment, as the end of everything we knew.

What stayed with me from all of them is one simple rule. There is only one way to get technological progress wrong: be late. Everything else can be fixed. You can misjudge a tool, miss on an architecture, invest in something that disappears. Those are mistakes that cost a month. Failing to keep up costs a career.

About twenty years ago I started working seriously for the American market, and that is where I first felt what speed means. Not the speed of writing code, but the speed of deciding. A meeting in the morning, a decision by noon, the first code that evening. Build first, figure out what to do with it later. For someone raised in a culture where every decision is thought over three times, that was liberating. Only now do I see the other side of that tempo, and I will write about it, because AI has multiplied it by ten.

The engineer nobody was hiring

All that time I carried a certain discomfort with me. I was not the engineer the industry was looking for. I cared about how a product looked, how it felt under the fingers, why someone opened it a second time or did not. The user's side interested me as much as the database did. Back then, that was not a virtue. Companies wanted narrow specialists, on a logic that sounds unbeatable: whoever does only one thing knows that thing best.

For years I had to prove that breadth is not a lack of depth. And for years the market slowly, without ever apologising, changed its mind. Today a developer is expected to understand the product, the user, the architecture, the infrastructure, the data, security, cost, and on top of all that to make decisions and stand behind them. To say that everything is expected would be an understatement.

AI did not create that expectation. It only made it merciless. While writing code was expensive, you could say there was no time to understand the product. Now that code appears faster than we can read it, that excuse is gone. What is left is one question: do you know what you are building, and why.

The revolution of bad products

Back to those ninety percent.

It has never been easier to make something that looks finished. In one afternoon you get an app with sign-in, a database, an interface that looks like a designer made it, and a landing page that promises. It has never been harder to make something that actually works. That holds under load, that can be maintained once the first euphoria has passed, that does not fall over when the thousandth user opens it instead of the tenth.

The difference between those two things is exactly that last ten percent. Projects have always broken there. What is new is that a hundred times more of them reach that point, and most of the people who brought them there do not know they have stopped. To them, the product looks done.

That is why I call this the revolution of bad products. If it used to be true that one startup in ten succeeds, I am convinced we are heading towards one in a hundred. Not because there are fewer good ideas. Because there are a hundred times more that do brilliantly in a demo.

Bad work has learned to look good

This is the part that interests me most, because nobody talks about it.

Bad work used to be visible. A bad developer shipped code that fell apart, a bad project manager a plan that did not hold, a bad analyst a document nobody could read. It was painful, but it was honest. You could see who you were dealing with.

Today a bad developer, a bad project manager, a bad analyst, whoever you like, can put in front of you, with AI, a solution that cannot be told apart from a good one. The documentation is tidy. The presentation is convincing. The code is clean, commented, well structured. It is still bad. You just no longer see it in the meeting. You see it three months later, when it costs ten times as much.

Which means that managing projects, time and decisions has not become simpler, as promised. It has become harder than ever. Because the thing intuition used to do, spotting bad work at a glance, no longer works. Bad work has learned to look good. The people who commission it, run it and pay for it have not yet learned that.

Why I am writing

With this post I am opening a series on software development from the point of view of someone who builds it every day, with AI and agents in the loop, on my own products and for clients. It will be concrete. How I work, what has genuinely helped, where a tool cost me weeks and why I let it.

But the main motive is a single one, and it is not technical. The relationship between people and AI, and the price many will pay for it in the coming years. Not because AI will replace them. Because, alongside it, they will stop doing precisely the parts of the job it cannot do for them: understanding what is being built, deciding what will not be built, answering for the result.

That price will not show up right away. It will show up in those listings. About ninety percent done, looking for someone to finish it.

Open eender welk serieus platform voor projectwerk en zoek op één zin: "ongeveer 90 procent klaar". Je vindt hem in de ene vacature na de andere. De app is bijna af, hij moet alleen nog afgewerkt worden. Het prototype werkt, het moet alleen nog stabiel gemaakt worden. Iemand heeft het meeste werk al gedaan, er ontbreekt alleen iemand om de rest af te sluiten.

Die vacatures zijn er altijd geweest. Er zijn er nog nooit zoveel geweest. En dat is, voor mij, het eerlijkste beeld van wat er op dit moment met softwareontwikkeling gebeurt. Niet de demovideo's, niet de conferentietalks, maar die wachtrij van producten die tot negentig procent zijn geraakt en daar zijn gestopt.

Wat ik leerde over transities

Ik bouw al vijfentwintig jaar software. Dat is lang genoeg om niet meer in revoluties te geloven en ze te gaan bekijken als weer. Ze komen, ze gaan voorbij, ze laten iets achter. Ik heb er een paar meegemaakt, en elk ervan werd op zijn moment aangekondigd als het einde van alles wat we kenden.

Wat mij van al die transities is bijgebleven, is één eenvoudige regel. Er is maar één manier om technologische vooruitgang verkeerd aan te pakken: te laat zijn. Al de rest valt recht te zetten. Je kunt een tool verkeerd inschatten, naast een architectuur grijpen, investeren in iets dat verdwijnt. Dat zijn fouten die een maand kosten. De aansluiting missen kost een carrière.

Een twintigtal jaar geleden begon ik serieus voor de Amerikaanse markt te werken, en daar voelde ik voor het eerst wat snelheid betekent. Niet de snelheid van code schrijven, maar de snelheid van beslissen. Een meeting 's ochtends, een beslissing tegen de middag, de eerste code die avond. Eerst bouwen, later uitzoeken wat je ermee doet. Voor iemand die opgroeide in een cultuur waar elke beslissing drie keer overwogen wordt, was dat bevrijdend. Pas nu zie ik de andere kant van dat tempo, en daar zal ik over schrijven, want AI heeft het met tien vermenigvuldigd.

De engineer die niemand zocht

Al die tijd droeg ik een zeker ongemak met me mee. Ik was niet de engineer die de sector zocht. Het interesseerde mij hoe een product eruitzag, hoe het aanvoelde onder de vingers, waarom iemand het een tweede keer opende of niet. De kant van de gebruiker boeide mij evenveel als de database. Toen was dat geen deugd. Bedrijven wilden smalle specialisten, op basis van een logica die onklopbaar klinkt: wie maar één ding doet, kent dat ene ding het best.

Jarenlang moest ik bewijzen dat breedte geen gebrek aan diepte is. En jarenlang veranderde de markt langzaam, zonder zich ooit te verontschuldigen, van mening. Vandaag wordt van een developer verwacht dat hij het product begrijpt, de gebruiker, de architectuur, de infrastructuur, de data, de beveiliging, de kost, en dat hij daarbovenop beslissingen neemt en erachter staat. Zeggen dat alles verwacht wordt, zou een understatement zijn.

AI heeft die verwachting niet gecreëerd. Het heeft ze alleen genadeloos gemaakt. Zolang code schrijven duur was, kon je zeggen dat er geen tijd was om het product te begrijpen. Nu code sneller verschijnt dan we ze kunnen lezen, is dat excuus weg. Wat overblijft is één vraag: weet je wat je bouwt, en waarom.

De revolutie van de slechte producten

Terug naar die negentig procent.

Het is nog nooit zo makkelijk geweest om iets te maken dat af lijkt. Op één namiddag krijg je een app met login, een database, een interface die eruitziet alsof een designer ze maakte, en een landingspagina die belooft. Het is nog nooit zo moeilijk geweest om iets te maken dat echt werkt. Dat standhoudt onder belasting, dat onderhouden kan worden als de eerste euforie voorbij is, dat niet omvalt als de duizendste gebruiker het opent in plaats van de tiende.

Het verschil tussen die twee is precies die laatste tien procent. Daar zijn projecten altijd al gebroken. Wat nieuw is, is dat er honderd keer meer tot op dat punt raken, en dat de meeste mensen die ze tot daar brachten niet weten dat ze gestopt zijn. Voor hen lijkt het product af.

Daarom noem ik dit de revolutie van de slechte producten. Als het vroeger klopte dat één startup op tien slaagt, ben ik ervan overtuigd dat we naar één op honderd gaan. Niet omdat er minder goede ideeën zijn. Omdat er honderd keer meer zijn die schitteren in een demo.

Slecht werk heeft geleerd er goed uit te zien

Dit is het stuk dat mij het meest interesseert, omdat niemand het erover heeft.

Slecht werk was vroeger zichtbaar. Een slechte developer leverde code die uit elkaar viel, een slechte projectmanager een planning die niet hield, een slechte analist een document dat niemand kon lezen. Het deed pijn, maar het was eerlijk. Je zag met wie je te maken had.

Vandaag kan een slechte developer, een slechte projectmanager, een slechte analist, wie je maar wilt, met AI een oplossing voor je neerleggen die niet te onderscheiden is van een goede. De documentatie is netjes. De presentatie overtuigt. De code is proper, gedocumenteerd, goed gestructureerd. Het is nog altijd slecht. Je ziet het alleen niet meer in de meeting. Je ziet het drie maanden later, wanneer het tien keer zoveel kost.

Wat betekent dat projecten, tijd en beslissingen beheren niet eenvoudiger is geworden, zoals beloofd. Het is moeilijker dan ooit. Want wat intuïtie vroeger deed, slecht werk in één oogopslag herkennen, werkt niet meer. Slecht werk heeft geleerd er goed uit te zien. De mensen die het bestellen, leiden en betalen, hebben dat nog niet geleerd.

Waarom ik schrijf

Met deze post open ik een reeks over softwareontwikkeling vanuit het standpunt van iemand die het elke dag bouwt, met AI en agents in de lus, aan eigen producten en voor klanten. Het wordt concreet. Hoe ik werk, wat echt geholpen heeft, waar een tool mij weken heeft gekost en waarom ik het liet gebeuren.

Maar het hoofdmotief is er maar één, en het is niet technisch. De relatie tussen mensen en AI, en de prijs die velen daar de komende jaren voor zullen betalen. Niet omdat AI hen zal vervangen. Omdat ze, ernaast, precies die delen van het werk zullen laten vallen die AI niet voor hen kan doen: begrijpen wat er gebouwd wordt, beslissen wat niet gebouwd wordt, instaan voor het resultaat.

Die prijs zal niet meteen zichtbaar zijn. Hij zal opduiken in die vacatures. Ongeveer negentig procent klaar, iemand gezocht om het af te maken.

Krnic blog

The last ten percent