Ud over AI-hype: Hvorfor din hurtigt sammensatte løsning sandsynligvis ikke er et rigtigt produkt

Jeg ser det hele tiden. En developer smider en "revolutionerende" kommando-linje-værktøj sammen på en aften med hjælp fra Claude. Deployer det uden nogen som helst dokumentation. Tærsklen er væk. Med en API-nøgle og et problem kan du kode hurtigere end du kan tænke.

Det er både fantastisk og et rod.

Værktøjsoverskuddet

Vi drukner i værktøjer. ChatGPT og lignende har ændret softwareudvikling fra "planlæg, design, iterér" til "kaffe og godt humør". Resultatet? Hylder fulde af engangs ting. Tusindvis af GitHub-repos, der samler støv. Reddit-tråde med "bygget på en nat!" – der forsvinder igen onsdag.

Problemet er ikke, at folk bygger. Det er godt. Men vi forveksler at lave noget med at lave godt noget. Du kan generere kode. Det betyder ikke, det er brugbart.

Tre ting, der adskiller ægte værktøjer fra sløseri

1. Almindelighed: Løser det et rigtigt, generelt problem?

De fleste hurtig-projekter fejler her. De er lavet til én person: dig selv. Din workflow, dit problem, din tankegang.

Et ægte værktøj løsner sig fra skaberens liv. En fremmed kan tage det op og forstå det med det samme. Tænk på Git, nginx, Redis – de tackler hele problemer, ikke små irritationsmomenter.

Den developer med hundrede mikro-værktøjer? Det er ikke en toolbox. Det er bare personlige noter, der kun giver mening i eget hoved.

2. Fællesskab: Kan andre bruge det uden at læse dine tanker?

Et værktøj, der kun kører lokalt hos dig, kun brugt af dig, aldrig delt? Det er ikke et værktøj. Det er terapi. Måske fin terapi, men ikke et værktøj.

Ægte værktøjer lever i fællesskabet. De bliver bedre via feedback: bug-rapporter, feature-ønsker, dialog. En README er ikke fællesskab. Det er bare papir. Fællesskab er respons, tilgængelighed og engagement.

Overnight-projekter crasher her. Koden er uigennemskuelig for andre. Fejlbeskeder er mystiske. Afhængigheder uden spor. Skaberen vil ikke vedligeholde efter "ship it".

Det er som digital graffiti – en besked på fremmed sprog til et ligegyldigt publikum.

3. Færdiggørelse: Føles det som et fuldendt værk?

Der er forskel på "koden kører" og "et færdigt produkt". Det første virker, når du kicker det. Det andet inviterer til brug, udvikling, integration.

Færdiggørelse handler om smart arkitektur. Rene abstraktioner. God fejlhåndtering. En klar vej frem. Det skal kunne udvides uden kaos. Fremtidige versioner er mulige, fordi det er bygget med omhu, ikke hastværk.

Kl. 23 med inspiration og energy drink? Du tænker ikke færdiggørelse. Du tænker næste idé. Resultatet er kode, der modstår forbedring. Den vokser ikke. Den står bare der som en midlertidig telt.

Håndværk tæller stadig

AI gør det lettere at kode. Lavere tærskel betyder mere eksperimenter, hurtigere iterationer, flere med på banen. Det er fremskridt.

Men fremskridt sletter ikke standarder. De bedste værktøjer – dem, der holder i årtier – startede som kløe-løsninger. De blev værktøjer, fordi nogen:

• Færdiggjorde det, ikke bare smed det ud
• Lyttede til brugere
• Vedligeholdt det efter hype
• Dokumenterede det klart til fremmede
• Designede det til at vokse

En LLM kan spytte kode ud. Den kan ikke skabe hensigt. Den kan ikke give disciplinen, der adskiller en sløset script fra et bidrag til økosystemet.

Vejen frem

Byg dine værktøjer. Gør det. Friktionen er lavere end nogensinde. Men før du pusher til GitHub og poster på Hacker News, spørg dig selv:

• Vil andre have gavn af det, eller er det kun til mig?
• Kan jeg vedligeholde det om seks måneder, hvis folk bruger det?
• Er dokumentationen telepatifri?
• Er det starten på noget større, eller bare en midlertidig patch?

Forskellen på sløseri og ægte værktøj er ikke teknologien. Det er hensigten. AI hjælper dig bygge hurtigere. Men det tænker ikke klogere end dig.

Håndværk kræver tanke. Omsorg kræver engagement. Hensigt former resultatet.

Det mest generøse, du kan gøre for dev-fællesskabet? Vær selektiv med, hvad du slipper løs. Vær streng med, hvad du shipper.