Voorbij de AI-hype: Waarom je snelle tool geen echt product is

Ik zeg het maar meteen: ik zie het probleem overal. Elke week duikt er weer een developer op met een 'revolutionaire' CLI-tool, in één avond in elkaar geflanst met Claude en zonder handleiding online gekwakt. De drempel is nul. Met een API-sleutel en een irritatie heb je al code voordat je een plan hebt.

Dat is tegelijk een zegen en een vloek.

De tool-overload

We verdrinken in tools. ChatGPT en consorten hebben software maken veranderd van 'zorgvuldige planning' naar 'koffie en een gok'. Gevolg? Repositories vol eenmalige snufjes. Duizenden GitHub-pagina's die stof vangen. Reddit barst van de 'ik bouwde dit in één nacht'-posts die volgende week al dood zijn.

Bouwen is prima. Het probleem zit in het verschil tussen knutselen en vakmanschap. Code spugen kun je makkelijk, maar iets bruikbaars maken? Dat is een ander verhaal.

Drie kenmerken van echte tools

1. Universeel nut: Lost het een breder probleem op?

De meeste snelle projecten mislukken hier al. Ze zijn voor één persoon: de maker. Jouw workflow, jouw quirk, jouw fix.

Een echte tool gaat verder. Een vreemde pakt hem op en snapt meteen waar het voor dient. Denk aan Git, nginx of Redis: die pakken hele probleemcategorieën aan, geen incidentele jeuk.

Die developer met honderd micro-tools voor elk kleinigheidje? Dat is geen toolbox. Dat is rommel die alleen in zijn eigen brein logisch is.

2. Samenwerking: Kan een ander het ook gebruiken?

Een tool die alleen op jouw machine draait en door niemand anders wordt aangeraakt? Dat is geen tool. Dat is een dagboek.

Echte tools bloeien in een community. Ze groeien door feedback: bugmeldingen, wensen, discussies. Een GitHub-README is geen interactie. Dat is papierwerk. Echt contact betekent reageren, toegankelijk maken en meedenken.

Snelbouw-projecten bakken het hier meestal af. Code die alleen de maker snapt. Foute foutmeldingen. Ontbrekende dependencies. En onderhoud? Vergeet het maar na de eerste push.

Het is als graffiti in een onleesbaar handschrift: voor even leuk, maar nutteloos voor de rest.

3. Afwerking: Voelt het als een compleet geheel?

Werkende code is niet hetzelfde als een product. Het eerste doet het als je erop klikt. Het tweede nodigt uit tot gebruik, aanpassen en uitbreiden.

Afwerking vraagt om slimme opbouw. Schone lagen. Goede foutafhandeling. Een heldere toekomstvisie. Zo kun je het uitbreiden zonder chaos.

Bij een nachtelijk brouwsel denk je niet aan afwerking. Je jaagt op de kick. Resultaat: code die niet schaalt. Het hangt maar wat rond, als een noodoplossing die blijft plakken.

Vakmanschap blijft koning

AI maakt code maken makkelijker. Meer experimenten, snellere tests, iedereen doet mee. Top.

Maar dat schaft geen normen af. De blijvende tools – die tientallen jaren meegaan – begonnen als krabbels. Ze werden groot door zorg:

• Afronden, niet alleen lanceren
• Luisteren naar gebruikers
• Onderhouden na de hype
• Documenteren voor outsiders
• Ontwerpen met toekomst in zicht

Een LLM spuwt code. Maar wil, discipline en toewijding? Dat moet je zelf brengen. Anders is het geen tool, maar troep.

Hoe verder?

Bouw gerust je tools. De horde is laag. Maar voor je het deelt op GitHub of HN, check dit:

• Vindt een ander dit ook handig, of is het puur voor mij?
• Zou ik dit over zes maanden nog fixen als anderen het gebruiken?
• Staat de docs zonder gedachtenlezen?
• Is dit een start, of een quick fix?

Het verschil zit niet in de tech. Het zit in je intentie. AI versnelt, maar denkt niet slimmer dan jij.

Vakwerk vraagt denkwerk. Zorg vraagt inzet. Doel bepaalt resultaat.

Het beste voor de community? Niet meer code dumpen. Maar selectief zijn en kwalitatief leveren.