Er vibe coding dette århundredes svar på Excel?

Der er noget velkendt over den begejstring, der i øjeblikket omgiver "vibe coding" — den stadig mere udbredte praksis, hvor man bygger software ved at beskrive, hvad man vil have, i almindeligt sprog, og lade en AI-model skrive koden. Ifølge en analyse på Version2 er sammenligningen oplagt: Vibe coding minder om dengang Excel for alvor gjorde regnearksberegninger tilgængelige for folk uden en teknisk baggrund.

Pointen er ikke, at teknologien i sig selv er barrieren. Det har den aldrig rigtig været. Både med Excel dengang og med AI-værktøjer til kodning i dag er den reelle udfordring at vide præcis, hvad løsningen skal kunne. Har man ikke styr på problemet, hjælper det ikke ret meget, at værktøjet er nemt at betjene.

Fra idé til fungerende prototype på en time

Et konkret eksempel fra artiklen illustrerer, hvor hurtigt vibe coding kan omsætte en idé til noget brugbart. En konsulent og en kollega brugte Claude Code til at bygge en fungerende prototype af et værktøj — kaldet "Værdikompasset" — på under en time. Prototypen tog udgangspunkt i en teoretisk model for, hvordan man måler værdien af AI-projekter, og gjorde den til et faktisk, klikbart værktøj.

Det sætter fingeren på noget, mange virksomheder kæmper med lige nu. En it-direktør nævnt i artiklen sad med 23 AI-projekter i kø — men ingen målte KPI'er til at afgøre, om projekterne rent faktisk skabte værdi. Her kunne en hurtigt vibe-codet prototype gøre det muligt at teste en idé, før man investerer store ressourcer i den.

Faren ved for hurtig succes

Men ligesom et Excel-ark, der vokser sig for stort og uoverskueligt, kan et vibe-codet program hurtigt blive svært at vedligeholde, hvis man ikke tænker sig om fra starten. Det, der begynder som en hurtig prototype til at teste en idé, ender let som et stykke skyggesoftware, ingen i IT-afdelingen kender til — og som ingen kan drifte eller udbedre fejl i, når det først går galt.

Dermed peger sammenligningen med Excel i to retninger på én gang. Dels som en demokratiserende kraft, der gør det muligt for flere end de traditionelle udviklere at bygge software. Dels som en advarsel om, at lav barriere for at komme i gang ikke er det samme som lav risiko på den lange bane.

Teknologien var aldrig den egentlige barriere

Den centrale påstand i artiklen er, at teknologien aldrig har været det, der stod i vejen. Det, der gjorde prototypen mulig at bygge på en time, var ikke først og fremmest, at værktøjet var kraftfuldt — det var, at ophavsmanden vidste præcis, hvad han ville have. Samme logik gælder for Excel: Et regneark er kun så godt som den, der bygger det, forstår problemet, det skal løse.

For softwarebranchen betyder det, at vibe coding næppe erstatter behovet for at forstå forretningsproblemer grundigt. Men det sænker markant, hvor dyrt det er at afprøve en idé — og det kan i sig selv vise sig at være den vigtigste udvikling af dem alle.