TransIP- en Combell-eigenaar koopt AI-tool waarmee klanten apps bouwen via chat

Team.blue heeft Macaly overgenomen, een Tsjechisch bedrijf dat zich een AI-vibecodingplatform noemt en gebruikers webapps laat maken via chatbotprompts. De tool komt beschikbaar voor klanten van team.blue.

Macaly werd in 2023 opgericht en laat gebruikers via een AI-chatbot 'complete, productieklare webapps maken', schrijft het Belgische team.blue. Met Macaly kunnen gebruikers 'zakelijke webapps maken met data, logica en workflows' zonder technische kennis. Hierdoor kunnen kleinere bedrijven, freelancers of interne teams 'in minuten van een idee naar een werkende liveapp' gaan, zonder tussenkomst van een ontwikkelteam.

Bij de dienst kunnen gebruikers in natuurlijke taal uitleggen wat ze willen bouwen. Macaly blijft als een losstaand merk bestaan, maar stelt een webappmaker beschikbaar voor de klanten van team.blue. Het is nog onbekend hoeveel deze klanten hiervoor moeten betalen. Deze tool moet 'binnenkort' beschikbaar komen. Er is geen overnamebedrag bekendgemaakt. Team.blue is in Nederland onder meer bekend van TransIP en Vimexx, en in België van Combell.

Reacties (151)

[Zyphlan]

Voor de echte IT’ers onder ons (waar ik er zelf niet 1 van ben) is dat zogeheten vibe-coding zonder IT-kennis nu echt wat?

Of is het, net als bij ChatGPT in sales, vooral schijn?

Het kan hartstikke mooie e-mails schrijven, maar als je zelf geen inhoudelijke kennis hebt, ziet iedereen met kennis binnen twee seconden dat je complete troep aanlevert en het lijkt me dat je hier nog zit met GDPR en andere privacy wetgeving?

[cricque]

Werkt voor geen meter. Grotere projecten mag je vergeten. Bij nieuwe projecten kan het je helpen, maar eenmaal 1-2000 lijnen code begint het enorm traag te gaan en regelmatig werkende dingen die aangepast worden. Je moet al zeggen om een backup te maken voor de laatste aanpassing, en die moet je dikwijls terugzetten. En zelfs bij microservices zit je al snel aan wat regels code

Maar je kan er wel iets mee maken als je enige kennis hebt, maar dit is verre van productie ready. Het is eerder als de maan/sterren/zee in de correcte positie staan dan zal het werken.

Zelfs een lijntje autocomplete zit er dikwijls naast. Maar het hangt af van de code ... kijk ik geef ook een cursus python aan volwassenen. Echt vanaf 0 ... ja een for loop kan nog wel ofzo, maar dat is heel triviale code. Als het wat uitgebreider is, mag je het vergeten, dan werkt het voor geen meter. Ik het begin gebruiken ze nog wel eens copilot/chatgpt/claude etc, maar op het einde van de het 2 jaar hadden ze dit dus allemaal al uitgeschakeld omdat het niet meer werkte en het trager werkte dan dat ze het zelf deden, door de vele correcties die ze moesten doen

Het enige waar je tijd mee kan winnen is ipv google zoeken je dit in veel editors rechtstreeks kan doen. Kijk ik ken niet elke functie in elk framework dat ik gebruik, en er zijn nu eenmaal bepaalde dingen die je niet elke dag/maand gebruikt, dan moet je soms wel eens zoeken.

Vergeet ook niet dat als je de nieuwste dingen gebruikt, je het bijna helemaal mag vergeten, want je krijgt altijd dingen van oudere versies. En dit zowel met betalende als niet betalende abonnementen.

En hoe kan het ook leren ? Van de code op github, daar is meer dan de helft (zelfs 3/4de als je het mij vraagt) gewoon complete troep. Daar gaan we nog wat AI rommel bijgooien en daar opnieuw van leren. Ik heb gewoon het gevoel dat het slechter geworden is ipv beter.

Als je wat kan programmeren, moet je zoveel voorkauwen en opnieuw bekijken dat ik het zelf gewoon sneller en beter kan. Heb zelfs gehad dat een project op bepaalde punten bijna helemaal gewist werd en dat de AI opnieuw begon .... Terwijl ik had gevraagd pas dit en dat aan met id X ... Dus 2 lijntjes ...

Sommige mensen zijn tevreden met "het werkt", dat is niet genoeg voor mij. Uiteraard een "scriptje" is wat anders. Veel hangt af van hoe je het wilt doen en qua snelheidsoptimalisaties is het gewoon helemaal niks. Mij kan het geen bal schelen als ik een veld 2x in een db heb om een bepaalde query sneller kunnen uit te voeren, maar zo een dingen mag je dus wel vergeten. Het draait et voila. Ik wil dat het zo "lean" mogelijk is en de beste snelheid heeft met de minste kosten en resources. Dat mag je dus helemaal vergeten

[Luchtbakker]

Werkt voor geen meter. Grotere projecten mag je vergeten. Bij nieuwe projecten kan het je helpen, maar eenmaal 1-2000 lijnen code begint het enorm traag te gaan en regelmatig werkende dingen die aangepast worden.

Ik heb projecten in react laten schrijven die in zijn geheel de +70.000 regels over gaan (in tientallen files Uiteraard) en dat gaat gewoon prima. Ik doe het in Claude Opus. En nee, foutloos is het zeker niet. Maar een klein beetje debuggen en dat doorgeven en het fixt alles zelf. En als je vraagt zaken logisch te bouwen, met logische indelingen en verspreiden van de juiste code dan komt dat echt wel goed.

[gybe]

Dit is ook mijn ervaring. Wanneer je bijvoorbeeld gewoon Claude Code gebruikt in VSCode kan hij via RAG je context redelijk herleiden. Maar zeker voor veel simpele kleine projecten werkt het prima. Het is zeker bruikbaar om lokale en interne apps/sites te maken die functionaliteiten bieden waarvoor je normaliter 3rd party sofware nodig hebt of zelf maatwerk moet laten doen. En ja AI maakt ook vaak fouten, dingen die niet werken. Maar in de 70-80% van de tijd gaat het naar mijn ervaring goed en vereist het wat trial & error.

Er wordt redelijk vaak gedaan alsof het alles of niets is. Maar het is een tool ter ondersteuning en het biedt zeker meerwaarde. Het biedt mensen de mogelijkheid dingen te doen die ze voorheen niet konden. Zoals met vele technologische vooruitgangen.

[R_Zwart]

Grote projecten niet, maar vergeet niet dat de meeste apps vrij eenvoudig zijn. Dat kan je al snel via AI in elkaar flansen.

[themadone]

Je moet codex eens proberen. Dan heb je heel veel van de issues die je hebt niet meer, kan als plugin in Visual Studio Code gehangen worden en is echt stukken beter als standaard chatgpt. Levert standaard rustig meer dan 2k lines op op een single prompt en comment in de code om context goed te houden.

Laat ik het zo zeggen, zolang je kan lezen en soms corrigeert wat hij doet is het een handige speedhack.

Deze startup klinkt als codex met een vast app frame eromheen. Maar ken het product verder niet dus dat is aanname.

[cricque]

Het probleem zijn dus nadien aanpassingen, doe dit zo, of doe dit eens zo, dan slaagt echt alles tilt.
Soms is je eerste idee qua UI niet het beste, en daar begint het dan, je moet aanpassingen doen. In bestaande projecten mag je dat gewoon vergeten. Ik heb een serieuze codebase en dan nog de optimalisaties moet je mee beginnen, anders kom je er niet, of kan je zogoed als opnieuw beginnen (aka het meeste opnieuw schrijven), waar is de winst qua tijd dan naar toe ? Ja ik heb sneller een poc, en daar stopt het dan.

Maar ik zal het eens proberen, binnenkort nog een "klein" nieuw projectje en eens kijken wat eruit komt.

[PiHole]

Ik heb wel mooie app gemaakt, haakt in op de bekende API's.
Volgens ai 8000 regels.

Maar zeker in UI is AI juist niet goed

[wizzkizz]

Codex, Gemini CLI of Claude Code en in wat mindere mate Github Copilot kunnen in mijn ervaring heel erg goeie code produceren in de stijl van jouw applicatie. Ze raken zeker niet in de war van een codebase van een paar 1000 regels code. Dat was in het begin van het jaar nog wel het geval, maar de ontwikkelingen dit jaar zijn enorm snel gegaan.

Dat gezegd hebbende, ik zie dat soort toepassingen veel meer als een productiviteitshulp voor software ontwikkelaars dan echt iets voor vibe coding voor mensen die geen idee hebben wat ze aan het doen zijn. Dat was en is nog steeds een recept voor initieel enthousiasme en een enorme kater een week of wat later.

[themadone]

Ik had precies hetzelfde toen ik via chatgpt bezig was, maar met codex werkt het wel lekkerder. Het is vooral handig als ik bijvoorbeeld een snelle weergave nodig heb van het een of ander. Dan zeg je gewoon houdt je aan de bestaande CSS, die wordt dan als context meegenomen.

Voor mij wint het tijd, maar ben er heilig van overtuigd dat zonder kennis van programmeren het niet goed gaat uitpakken. Het is nog niet op het niveau dat iedereen het blind kan gebruiken en er geen problemen ontstaan.

[Cybje]

Precies dit. Hoewel ik zelf ook prima Python kan schrijven, heb ik met Codex een aardig groot project opgezet en dat gaat echt heel goed. En als er iets niet goed gaat, komt dat meestal doordat m'n prompt niet helemaal 100% was (onbewust doe je als mens toch aannames en vergeet daardoor dingen in je prompt te vermelden).

Bij een wat groter project helpt het wel om een goede AGENTS.md file te maken merk ik. En als je ook AI code reviews doet (wat wel helpt voor de kwaliteit) is het slim om de AI een rol mee te geven, bijv. Python programmeur met focus op 'Pythonic' code, of security engineer, of nog iets anders. Dan komt hij vaak met veel hogere kwaliteit feedback. En zo kun je continu de code verbeteren, naast dat je kwetsbaarheden in je code al vroeg afvangt.

Ik sta er echt van te kijken hoe goed Codex werkt. Werkt het foutloos? Nee. Werkt een mens foutloos? Ook nee. Daarom denk ik dat de combinatie van AI en mens wel een heel sterke combinatie is. Dat betekent dus ook dat je kritisch moet zijn op wat AI (en dus Codex) genereert.

[fuzzyIon]

Modulair werken?

[cricque]

Geprobeerd met meerdere: zelfde probleem

[BPG908]

Dan doe je toch echt iets fout. Ik kan niet anders zeggen dan dat het fantastisch werkt; ik schrijf (letterlijk) geen regel meer zelf. Ik werk (met een team) aan grote webprojecten. We werken veel met Laravel en dat gaat echt heel goed. Maar ook .NET: no problemo.

“Vergeet ook niet dat als je de nieuwste dingen gebruikt, je het bijna helemaal mag vergeten, want je krijgt altijd dingen van oudere versies.”
Dit is echt onzin. Je moet het alleen wel serieus aanpakken; dus: gebruik je iets nieuws, dan geef je dat gewoon mee in je main prompt (net zoals je dat bij een developer zou doen). Gebruik versie x.x, de changelog is hier te vinden: %file%, de belangrijkste aanpassingen t.o.v. de vorige release zijn x en y. (En die regels genereer je natuurlijk ook met AI; je gaat het niet zelf lopen typen 😉).

“Het werkt”, nee: het werkt echt heel erg goed! Mits je bereid bent te betalen (200 euro per maand voor Cursor, Opus 4.5 e.d.). Maar je output gaat na een week of twee wennen enorm omhoog, en de kwaliteit ook. Ik werk fulltime met Cursor; de kosten zijn rond de 2000,- per maand aan Opus. Maar de output? Ik gok x20 t.o.v. zelf schrijven. Dat lukt alleen als je het professioneel aanpakt en denkt: ik ga dit gewoon doen. Na een week of twee heb ik nooit meer achterom gekeken!

[Snikker]

Ik heb precies dezelfde ervaring met Laravel, Kotlin en Flutter met Opus 4.5, dus wil mijn ervaring graag delen als tegenhanger. Ik gebruik Claude Code Web en schrijf mijn prompts meestal op mijn smartphone. Google heeft met Jules een vergelijkbare tool op basis van Gemini; sinds versie 3.0 schrijft die ook redelijk goede code — daarvoor was het eerlijk gezegd ondermaats.

Momenteel werk ik aan software met een behoorlijk complex permissie- en authorisatiesysteem, en dat gaat verrassend goed. Het is een groot project, maar Claude kan dit prima aan. Als ik dit volledig zelf had moeten bouwen, was het al snel te ingewikkeld geworden en had het waarschijnlijk jaren gekost.

Daarnaast gebruik ik AI ook om de code te auditen en security checks te doen, wat eveneens erg goed werkt.

Voor mijn zoontje heb ik een app gebouwd met mini-games, afgestemd op zijn leeftijd (3 jaar). Die app is geschreven in Kotlin, een taal waarin ik vóór dit project nog nooit een regel code had geschreven — en eigenlijk nog steeds niet echt. Inmiddels bevat de app bijna 50 mini-games: educatief, maar ook creatieve spellen zoals kleuren. De leukste vind ik de games die aansluiten bij dingen die hij zelf meemaakt.

Een voorbeeld: een spel met rode paddenstoelen met witte stippen. Bekend uit het liedje en hij vond een echte in het bos. In de game verschijnen kabouters op of naast de paddenstoel, en hij moet zo snel mogelijk op de kabouter tikken om punten te verdienen. Met text-to-speech krijgt hij aanmoedigingen en instructies, inclusief het uitspreken van zijn naam.

Na tien succesvolle tikken krijgt hij een filmpje te zien waarin familieleden juichen. Ook dat is met AI gemaakt, op basis van foto’s. Dit alles kostte letterlijk maar een paar uur werk, en een nieuwe game toevoegen is nu een kwestie van minuten.

Hoewel ik wel wat programmeerervaring heb als hobbyist, zou alles wat ik nu heb gebouwd zonder AI jaren hebben geduurd.

Uit nieuwsgierigheid heb ik ook een stuk software met een lange legacy en veel functionaliteit getest. Ik heb alle features aan Opus 4.5 gevoerd en binnen een half uur had ik feature parity. Dat gaat om zakelijke software waar programmeurs al jaren aan werken.

Ik ben hier echt enorm enthousiast over. Wel lijkt Anthropic nog te sleutelen aan Opus; ook op Reddit geven mensen aan dat de codekwaliteit soms wat wisselt. Het voelt alsof ze nog zoeken naar een balans tussen codekwaliteit en resourcegebruik. Maar we staan pas aan het begin, dus ik ben erg benieuwd wat er nog komt. Als ik nu professioneel programmeur was, zou ik AI zo snel mogelijk omarmen.

Met tools als Claude kun je bovendien echt de diepte in: je kunt skills en agents maken die gespecialiseerd zijn in specifieke taken. Door die goed te beschrijven en je eigen kennis en werkwijze daarin vast te leggen, krijg je merkbaar betere output.

(Natuurlijk ook deze tekst even door ChatGPT gehaald 😄)

[Reactie gewijzigd door Snikker op 30 december 2025 09:27]

[Cartman!]

Daarnaast gebruik ik AI ook om de code te auditen en security checks te doen, wat eveneens erg goed werkt.

Hoe valideer je dit dan precies?

(Natuurlijkook deze tekst even door ChatGPT gehaald 😄)

Dat is te merken, niet doorheen te komen

[Reactie gewijzigd door Cartman! op 30 december 2025 10:44]

[Hiroj]

Ik sluit mij hierbij aan. Zelf werk ik veel met Claude Code en die kost mij 200 euro per maand. Als je de rol aanneemt van een projectleider en Claude Code ziet als een developer waaraan je uitlegt wat het moet maken, kom je een heel eind.

Mensen die dat ontkennen verwachten over het algemeen een compleet product op basis van één prompt.

Als freelance developer heb ik inmiddels meerdere klanten kunnen overtuigen dat mijn output hoger is dan mijn concurrentie bestaande uit een team van minstens 8 developers.

[djunicron]

Heb ondertussen een project lopen, om te kijken of het gaat, waarbij AI in de nacht in twee sessies (want token limits) zelfstandig een project aan het uitvoeren is.

Heb een uitgebreide instructie achtergelaten met parameters, project omschrijving, domein model, code style en voorkeuren. Welke componenten in welke taal moeten, etc.

PCtje wordt wakker om 1:00 en gaat dan meestal tussen de 50 min en 2:30h aan de slag. Enige wat ik doe is in de job 2x terminal openen en de AI aanroepen. Code schrijven, tests schrijven, CLI testen gaat allemaal automatisch. Hij schrijft MDtjes terug met wat gedaan is, en wat ik zou moeten testen in de GUI als "mens".

Ja, het model of één van de agents hebben wel eens communicatie fouten, slaan de plank volledig mis. Eén bepaalde bug heb ik nu al 7x terug gezien. Maar ze (de agents) hebben NodeJS, Python, Java + Scala, alle dev ops zaken zoals Docker, build street, etc helemaal op orde gemaakt.

Kijk, het is alsof je PM bent met een PO die om de dag een ontzettende kater heeft, maar doorgaans wel redelijk werk oplevert. Gaat wel af en toe de mist in. De "ontwikkelaars" zijn juniors die heel goed kunnen googlen en naar de Youtube school zijn geweest. Maar ze houden zich wel aan de unit test Goldens die ik heb aangedragen en de strenge linting volgen ze wel op.

Inmiddels hebben ze 5.500 regels backend geschreven, een Docker test omgeving + mock data, zelf ingerichte database, een frontend die "redelijk" is met flexbox en Vue.JS (zelf gekozen, zo mochten ieder JS framework kiezen) met Vite gepakt. Claude is de baas, en dus zijn de graphics ondermaats. Maar dat is allemaal geen ramp. de API's werken allemaal, de code coverage is goed, en ik heb geen finger hoeven optillen voor de build street. Als ik code aanpas en doorgeeft dat ze dat eerst moeten bekijken voordat ze verder bouwen, gaat dat ook gewoon goed. Refactoren toegestaan of niet kan je gewoon opdragen hierbij.

Nu ben ik zelf geen code meester, maar heb ik aan genoeg dingen gewerkt die gewoon jaren in productie hebben gedraait. En AI is toch echt sneller. In de 2x "1 uur" die "het team" werkt terwijl ik slaap, doen ze rustig wat een klein ontwikkel team + PO in één werkdag doen. (zeg 3 personen over 5 uur efficient werken)

Kijk, ik zou ze nog niet op een echte productie omgeving loslaten. Maar b.v. een server in een VM laten installeren, configureren en testen, om vervolgens alle stappen chronologisch op te hoesten, een Ansible te schrijven, te onderzoeken welke versies van dependancies gebruikt moeten worden, etc. heeft mij wel al zeker 2 dagen tijd bespaard. Exploratief zou ik AI dus zeker in productie durven inschakelen. Fouten opsporen, unit en e2e testen aanscherpen, allemaal zaken die al goed genoeg zijn.

Vibe coden door in de browser wat bestanden te uploaden en dan het resultaat terug te plakken is afgrijselijk. Maar het moment dat je één host hebt voor meerdere SaaS en lokale modellen en je de modellen "oneindig context" ruimte geeft en compactable historie? Dan gaat de effcientie en kwaliteit van de modellen met een factor 300 omhoog.

[Snikker]

Dat van die token limits is ook killing. Omdat ik met Claude Code Web werk, en mijn smartphone naast mijn bed ligt, is het zeer verleidelijk toch nog een prompt in te schieten.

Dat voert hij dan uit en als ik weer wakker ben heb ik én nieuwe code én is de limiet weer gereset zodat ik weer een nieuwe prompt kan ingeven.

Maar ik ben dan soms toch benieuwd of Claude nog vragen heeft of ik ben nieuwsgierig naar de uitkomst en dan heb ik ineens weer de smartphone in mijn hand

Slaapt veel te onrustig en nu maar bij neergelegd dat niet meer te doen

[Reactie gewijzigd door Snikker op 30 december 2025 12:40]

[djunicron]

Dat is dus precies waarom ik em op een geplande taak heb lopen en die in twee sessies gedurdende de nacht heb staan. Op een redelijk geisoleerd systeem waar de "voorman" agent alle rechten heeft. Ergste geval is de linux omgeving weg en moet ik die in een minuut of 40 weer herstellen.

Daarnaast gaan commits na een groen buildstreet direct GIT in, waarna ik er zelf een PR van maak indien ik tevreden ben over de resultaten.

De eerste week ofzo was het inderdaad snel kijken naar de GIT om te kijken wat er binnen was gekomen, maar inmiddels laat ik er wel eens een week overheen gaan voordat ik met master merge... Alles went zeg maar.

[REDSD]

Ik probeer het regelmatig, maar de uitkomst is bijna altijd verraderlijk. Je hebt vaak het idee dat er een werkende oplossing staat, maar vaak is dat het halve verhaal, meestal is de uitkomst het gene wat je denkt te verwachten, maar de manier waarop je er komt klopt niet.

Daarnaast als je iets uitgebreiders dan een simpele functie wilt gaat het al snel goed mis, vol met fouten, inconsistenties, veiligheidsissues, rare code die onder bepaalde omstandigheden je applicatie express lijken te bricken. Ik gebruik nu claude en chatgpt en ben daar al zoveel rare dingen tegengekomen. Mensen met geen of weinig kennis, die zullen echt niet begrijpen wat er allemaal gebeurd en dus ook deze fouten niet zien/begrijpen.

[Kerfuffle]

AI die speciaal voor coding is opgetuigd kan behulpzaam zijn voor boilerplate spullen. Het helpt ook met troubleshooting van vage foutmeldingen van frameworks die je inzet. Ook als je bijv. niet thuis bent in de ene taal maar op basis van je kennis in een andere taal wel in staat bent om uit te drukken wat je wilt, wetende wat moet kunnen, kun je snel een begin neerzetten. Snel resultaten genereren en daarop itereren werkt lekker als je gauw iets opgetuigd wil hebben, wat leidt tot enthousiasme rondom experimenten en proof-of-concepts.

Maar mijn ervaring met AI is dat itereren al gauw verzandt in back-en-forth tussen zaken met tekortkomingen, waarna je alsnog zelf aan de gang moet (maar dan ben je dus arguably al niet meer aan het vibecoden). En dan is de ervaring eigenlijk hetzelfde als wanneer je midden in andermans project gedropt wordt: er is code waar lastig tabak van te maken is en degene die het heeft achtergelaten die het zou kunnen toelichten is er niet meer.

Software development behelst veel meer dan code kloppen, maar één van de minst leuke aspecten is onder zulke omstandigheden code reviewen. Greenfield code kloppen is dan weer één van de leukste dingen, maar juist dat vervang je bij vibecoding dus door prompt engineering, wat in mijn ervaring een combinatie van ontzagwekkend (er kan veel), frustrerend (er zijn meer misverstanden dan bij menselijke communicatie) en tijdrovend (je verdiepen in gegenereerde code kost meer tijd dan je verdiepen in je eigen code, en ik merk dat ik beter in staat ben om ervan te leren wanneer ik iets zelf bouw) is.

Het internet staat al vol met voorbeelden van gesuggereerde succesverhalen van vibecoding die door de mand vallen wanneer blijkt dat het niet te onderhouden is, de security lek als een zeef is en de database gewoon open staat of plots gewiped wordt zonder backup, de boel niet opschaalt onder load of juist constant veel te veel resources eet, de boel geen telemetry heeft om uberhaupt te kunnen troubleshooten, etc.

Ik zie meer heil in het verbeteren van de tools die developers al gebruiken - IDE code completion die net wat slimmer is dan functienamen aanvullen, in lekentaal templates laten kiezen voor monitoring, delivery pipelines e.d., maar alhoewel dat nuttig is, denk ik dat managers en investeerders daar niet de miljoenen winst in gaan zien waar ze op hopen..

[Renzmeister]

Ik ben een hobby projectje aan het vibe coden en zonder IT kennis had ik waarschijnlijk een lastig te onderhouden codebase gehad. Paar dingen die me opvallen:

- de LLM maakt merkwaardige architectuurkeuzes. Zo bouwde Gemini een app met backend en frontend, waar enkel een frontend volstond.

- LLMs hebben de neiging om alle code in 1 bestand te dumpen, tenzij je hier iets van zegt. Dus zonder programmeerkennis kan je hier gemakkelijk mee de fout in gaan.

- Gemini gebruikte een oude versie van Fabric.js in mijn project. Claude Code weigert nu gewoon om te migreren naar een nieuwe versie, omdat de aanpassingen te ingrijpend zijn. Het zegt dus wel iets als zelfs de LLM moeite heeft met onderhoud.

- Je moet de LLM expliciet vragen om unit tests te schrijven. Vervolgens kan hij de tests wel zelf runnen en dat is heel handig. Maar zonder programmeerkennis ga je hier ook de fout in.

- Sommige bugs kon ik alleen oplossen door de LLM te vragen debug statements (console.log) toe te voegen zodat ik van de juiste feedback kon voorzien. Ik denk dat je zonder IT-kennis wellicht niet zo snel op zo’n oplossing zou komen.

[djwice]

Dus eigenlijk net als bij projecten met mensen: als je wil dat het team goed samenwerkt maak je afspraken over de frameworks, versies en opbouw en structuur van de code. En je DoD en best practices,

[Ulysses]

Ja, ik heb een aardig productie gereedgemaakte Levensloop applicatie waarmee ik ook juridische entiteiten zoals mijn bedrijf in kaart kan brengen voor evenementen en daar een compleet chronologisch document beheersysteem op basis van Events van gemaakt met BUNQ en NS-Business integratie ... Conclusie: Het werkt en ik had het uit mijn hoofd niet gekund in dit bestaan, met mijn beperkingen - maar door het harde coderen en repeterende vertalen uit te besteden en de visie en design van de app aan mij over te laten is het gelukt. (Je vind hem in mijn profiel terug tevens)

*knip*

[Reactie gewijzigd door Santford op 29 december 2025 21:42]

[RoestVrijStaal]

Bedoel je deze kom met spaghetti?

Als ik dit bestand waar het allemaal om lijkt te draaien zo door neem, zie ik dingen gebeuren waar je in die programmeertaal een paar decennia terug nog mee weg kon komen, maar nu keihard afgestraft zou worden. Ook worden er basisprincipes en best practices van programmeren overschreden.

Typering van variabelen bijvoorbeeld. Zoiets kan tegenwoordig in PHP.
En WTF in een catch-blok doodleuk de tabel aanmaken die je in de try probeerde te benaderen.

Nee, deze AI slop leest dat het uit een codebase van de jaren 1990-2000 komt.

Leuk voor je als het nu werkt (volgens medetweakers die mij al voor zijn doet dat het momenteel al niet). Maar als je een goede ontwikkelaar gaat vragen of ie die codebase wilt gaan uitbreiden, gaat ie je vriendelijk voor de eer bedanken of een factuurtje sturen voor een equivalente codebase die wel modern, uitbreidbaar en onderhoudbaar is.

[djwice]

Toch interressant dat iemand zonder programeer ervaring blijkbaar code kan schrijven die aan de standaarden van eind jaren '90 voldoet. Dat geeft dus aan dat we al heel ver zijn.

Drie jaar terug had iemand zonder programeer ervaring in dezelfde tijd welllicht net de server geinstalleerd met publiek toegankelijke mongoDB. Nu worden de queries zelfs al prepared.

Dus ja, de code is niet zoals iemand met 20 jaar ervaring en up-to-date kennis het zou schrijven, maar als dat wel zo zou zijn, zonder enige extra uitleg of instructie, zou er dan nog werk zijn voor IT-ers? Of zou een manager/directeur dan gewoon zeggen wat ie wilde tegen een AI?

Aangezien jij nog een baan hebt, zijn we daar nog niet. Ondanks dat je directie heel de dag tegen AI-kletst om de meest uiteenlopende dingen gedaan te krijgen.

[Reactie gewijzigd door djwice op 29 december 2025 20:25]

[RoestVrijStaal]

Toch interressant dat iemand zonder programeer ervaring blijkbaar code kan schrijven die aan de standaarden van eind jaren '90 voldoet. Dat geeft dus aan dat we al heel ver zijn.

Drie jaar terug had iemand zonder programeer ervaring in dezelfde tijd welllicht net de server geinstalleerd met publiek toegankelijke mongoDB. Nu worden de queries zelfs al prepared

Dat gaat nog intressant worden bij de volgende datalek door dit soort brakke code. Want er is geen afdeling IT / Software development meer om de schuld te geven. "Ja die datalek kwam door de AI". Ik ben benieuwd hoe Autoriteit Persoonsgegevens daarop gaat antwoorden.

Dus ja, de code is niet zoals iemand met 20 jaar ervaring en up-to-date kennis het zou schrijven, maar als dat wel zo zou zijn, zonder enige extra uitleg of instructie, zou er dan nog werk zijn voor IT-ers? Of zou een manager/directeur dan gewoon zeggen wat ie wilde tegen een AI?

Dat is natuurlijk ook het "gevaar" van AI en coding: als een manager zus en zo wil, en de ervaren medewerker zegt op basis van zijn ervaring "Nope, kunnen we beter niet doen.". Dan is die medewerker "lastig". Een AI gaat geen strobreed in de weg leggen als er een bepaalde wens per se erin moet. Hoe erg dan ook dat de architectuur, performance en/of onderhoudbaarheid van de applicatie om zeep brengt. Het "mooiste" is ook dat het probleem door die wens manifesteert als die manager die die wens per se wilde allang een functie elders heeft.

Aangezien jij nog een baan hebt, zijn we daar nog niet. Ondanks dat je directie heel de dag tegen AI-klents om de meest uiteenlopende dingen gedaan te krijgen.

Gelukkig zitten hedendaags programeertalen en frameworks ook niet stil en worden steeds beter waardoor het allemaal net wat efficiënter kan dan met "publiek inzichtelijke code" dat door AI gescraped wordt. De (IT)managers die denken dat nog krachtigere hardware ertegenaan gooien gaat helpen, leven in een illusie.

[djwice]

Dat gaat nog intressant worden bij de volgende datalek door dit soort brakke code. Want er is geen afdeling IT / Software development meer om de schuld te geven. "Ja die datalek kwam door de AI". Ik ben benieuwd hoe Autoriteit Persoonsgegevens daarop gaat antwoorden.

De gene die de AI aanstuurd en het review team blijft gewoon verantwoordelijk voor de code.

Dat is natuurlijk ook het "gevaar" van AI en coding: als een manager zus en zo wil, en de ervaren medewerker zegt op basis van zijn ervaring "Nope, kunnen we beter niet doen.". Dan is die medewerker "lastig". Een AI gaat geen strobreed in de weg leggen als er een bepaalde wens per se erin moet. Hoe erg dan ook dat de architectuur, performance en/of onderhoudbaarheid van de applicatie om zeep brengt. Het "mooiste" is ook dat het probleem door die wens manifesteert als die manager die die wens per se wilde allang een functie elders heeft.

Dat hadden we vroegen ook al, was ik op vakantie en werd een junior zo lang geduwd dat het moest dat ie basic-auth implementeerde over http in productie. Gelukkig melde die mensen dat direct bij mijn terug komst. Uiteraard heb ik de manager die dit eiste ondanks de terechte en schrieftelijke waarschuwingen van de junior, zelf excuses laten maken waar het hele team bij stond én zelf de code laten terug rollen en laten aanpassen tot het werkte, de jonior mocht reviewen. En de manager mocht de melding doen aan de hogere laag dat het zijn fout was dat het onveilig was geworden.
Dus ligt niet aan AI, maar aan een mindset.

Gelukkig zitten hedendaags programeertalen en frameworks ook niet stil en worden steeds beter waardoor het allemaal net wat efficiënter kan dan met "publiek inzichtelijke code" dat door AI gescraped wordt. De (IT)managers die denken dat nog krachtigere hardware ertegenaan gooien gaat helpen, leven in een illusie.

Toch zou ik wel blij zijn als ik een RTX 6000 Pro met 96GB op m'n bureau had staan, kunnen een aantal modellen goed op draaien en dan is het maken van LoRA's op die modellen een stuk makkelijker. Bijvoorbeeld QWEN3-Omni full.

Draait nog niet op laptop

[djunicron]

Dat is precies waar het fout loopt, mensen die AI als echte medewerker zien en daarmee casual via de browser in gesprek gaan en dan werkende software verwachten.

Maar zo werkt het dus niet helemaal. Dat is leuk om even snel een concept website neer te zetten, wat een programmeur nog steeds sneller kan waarschijnlijk, maar ok.

Uiteindelijk moet je dus een hoop conventies zelf definieren en je model exact vertellen hoe je het wilt hebben. Aangeven dat je b.v. een oudere taal wilt gebruiken, maar dan wel ENKEL standaarden X en Y, dat je een object oriented domein model in de backend wilt hanteren, wat je verwacht van de code standaarden wat betreft testen etc. En hoe je de agents tot overeenstemming wilt laten komen, hoeveel vrijheid er genomen mag worden. Vanaf dat moment is het gewoon weer werk voor iemand met een wat meer technische achtergrond. Maar dat is dus precies het probleem dat je in de VS wel al ziet. AI kan prima een junior vervangen. Een PM, PO en de senior, de database architect, de security specialist, die zet je allemaal nog niet buiten spel. Die weten wat een systeem goed maakt, die maken de afwegingen die een CEO niet met overleg met een LLM boven water krijgt.

Vraag me ook af of dit nog heel veel gaat veranderen. Deze dingen worden namelijk niet simpler over X jaar. Anders worden zaken wel, genoeg voorbeelden over de afgelopen 30 jaar ICT, maar ik zie eerder een AI personeelsbestand een heel bedrijf runnen dan dat 3 managers samen met AI dingen voor elkaar gaan krijgen. Dan heb je eerlijk gezegd meer kans dat 3-4 programmeurs een klein bedrijf van de grond krijgen, zoals dat nu met startups natuurlijk vaker lukt.

[djwice]

De keuzes en voorkeuren die wij nu als senior experts maken zijn ook vast te leggen, elke architectuur etc.
En daar kan een lijst met voor/nadelen in begrijpelijke taal voor leken aan gekoppeld worden.
Ook een lijst met wat wel en niet goed samen werkt (event systeem met state model die afhangt van volgorde van events is bijvoorbeeld niet zo'n goed idee).

En zo kun je een soort keuze systeem faciliteren dat de meeste applicaties en de meeste implementaties afdekt met wellicht wel betere consistentie en hogere efficiëntie en betere onderhoudbaarheid dan de meeste software projecten in bedrijven nu.

En een stappen plan met wanneer je een expert moet aanhaken voor de architectuur. Of het probleem moet opknippen in verschillende stukken die simpelweg met elkaar praten - separation of concerns (voorbeeld: operationeel systeem voor klant aankopen moet niet op dezelfde database ook de audit logs vast houden en daar over rapporteren: dat moet in een apart domein, apart cluster etc.).

Je ziet bijvoorbeeld in de systeem prompt van Lovable AI dan ook duidelijke architectuur en ontwerp keuzes die voor de meeste van hun gebruikers goed genoeg zijn. En tool koppelingen die dat helpen sturen.

Ik verwacht dat het bij Macaly vergelijkbaar werkt.

[Reactie gewijzigd door djwice op 30 december 2025 23:04]

[djunicron]

Dergelijke professionele gang van zaken dingen, die experts als business as usual zien, moet je dan ook gewoon nog steeds doorlopen met AI. Alleen zie je nog wel eens dat het fout gaat. 10 projecten online gevonden die zeggen dat iets werkbaar te krijgen is, wordt nog wel eens gezien door AI (of niet seniors / luie seniors) als een prima route. Alleen zal AI nog minder snel terugkomen van een besluit, zonder dat de gebruiker em terugfluit.

Juist de afwegingen helder boven water krijgen, is AI bijzonder sterk en rationeel in. Je moet het dan wel met meerdere agents laten werken bij voorkeur, maar de documentatie ervan, als je die wederom uitvraagt, al dan niet structured, is juist exceptioneel goed in mijn beperkte ervaring hiermee (2 use cases). Vooral omdat AI heel snel kan documenteren en rustig 5 versies diep gaat in de uitwerking in 2 minuten tijd. Zoveel tijd willen Seniors hier helemaal niet aan besteden, terwijl het voor het management extreem nuttig kan zijn.

Dus ik verwacht inderdaad dat de "value" die Macaly en andere leveranciers aanleveren niet veel meer zijn dan een prompt waarin dit soort stappen genomen worden en worden gedocumenteerd door AI. En als je er over nadenkt is dat natuurlijk extreem makkelijk verdienen, voor één maal werk doen.

Het andere haakje is denk ik dat AI niet snel zal toegeven dat er een echte Expert nodig is. Terwijl dat waarschijnlijk direct een advies zou zijn het moment een flowchart aanlevert met separation of concerns, hardware infra, domein en micro services design, etc. Dat zijn dan ook allemaal dingen waar je de business iets beter voor moet kennen en waar AI slechts een sparringspartner kan zijn.

Persoonlijk reken ik al deze dingen niet meer echt onder vibe-coding. Hoewel het nog steeds kan betekenen dat je tot de expert nodig is, helemaal niet meer zelf code hoeft te schrijven.

[djwice]

Wat mijn indruk is dat als wij, de experts, dit soort dingen "inbakken" op de achtergrond, we interfaces kunnen bieden die voor mensen overkomen als vibe coding, maar onderhuids gestuurd wordt door gestructureerde en wel overwogen keuzes
Dus dat we meer mensen enablen om goede systemen en code op te leveren, waar ze dat zelfstandig of met hun team niet konden door gebrek aan sturing, expertise, 'tijd', onverschilligheid of wat dan ook.

(mijn droombeeld is dat software inherend beter wordt in de basis als we dat doen)

[Bor]

Toch interressant dat iemand zonder programeer ervaring blijkbaar code kan schrijven die aan de standaarden van eind jaren '90 voldoet.

Hier sla je de plank mis. De gene die de Ai vraagt iets op te leveren code zelf niet. Een Ai is geen echte medewerker of persoon en wat de Ai oplevert levert de "aanvrager" niet. Dit is echt een compleet scheve interpretatie.

Verder; wat vervolgens wordt opgeleverd is een spagetti van niet volgens best practices geschreven code regels.

[Reactie gewijzigd door Bor op 31 december 2025 10:33]

[djwice]

Ik reageerde op de gene voor mij die zei:

Nee, deze AI slop leest dat het uit een codebase van de jaren 1990-2000 komt

En over het algeheel zien mensen AI als een tool, dus met de inzet van de tool maakt de gebruiker code die lijkt op code gemaakt eind jaren 90.

Dat is toch best indrukwekkend?
En lijkt me geen misinterpretatie of gemiste planken aan mijn kant.

[pietvelleman]

Dat is ook mijn ervaring met AI!

Wanneer je grotere applicaties opknipt in kleine deel-projectjes, dan kun je mooie dingen bouwen zonder al te veel kennis van zaken. Ofwel: modulair opgebouwde software/microservices/api's etc met ieder één concreet doel... en die samen 1 geheel vormen.

Ik gebruik AI de hele dag door... maar laat het nooit aan code werken >50 regels (en gemiddeld genomen wellicht een regel of 15). Ik plaats alles in aparte classes/deelfuncties met ieder 1 afzonderlijke taak.
En zo kun je toch mooie dingen bouwen...

[FrankHe]

Programmeren is zoveel meer dan alleen coderen.

Je geeft zelf al aan dat LLM's werken op kleine deel-projectjes. Daar komt al een basisvaardigheid van een programmeur om de hoek kijken, een groter systeem opknippen in kleinere delen. Een leek zal alles in één groot ding willen proppen daar waar een programmeur weet dat je functies beter wat meer kunt scheiden.

Wat betreft 'best practice' zijn er legio zaken die een LLM gewoonweg niet kan beredeneren. Een LLM genereert woorden op basis van statistische informatie en is niet in staat om inhoudelijk te toetsen of het goede code is. Wanneer iets werkt dan wil het nog niet zeggen dat er een goede oplossing is gekozen.

Het is wellicht leuk voor het prototypen van een 'proof of concept' maar neem het a.u.b. niet klakkeloos in productie want daar gaan echt ongelukken van komen.

[pietvelleman]

Je hebt natuurlijk gelijk als je de output van een goede programmeur met voldoende tijd vergelijkt met de output van een LLM.

En dan nu de praktijk...
Laten we wel wezen: de gemiddelde software zit vol met bugs... En we verlangen van klanten 'onderhoudscontracten' zodat ze updates krijgen waarin we onze eigen fouten herstellen.
En ze trappen er nog in ook : )

Ik ben iets minder negatief over LLM's dan jij. En wellicht iets negatiever over de gemiddelde staat van de software die wordt opgeleverd. Maar ook met een LLM kun je bijv. direct goede unit-tests schrijven en foutlogging doen....

Maar - in het kader van deze discussie over vibe-coding - het is wel noodzakelijk om over redelijke basis-vaardigheden te beschikken...

Onlangs geprobeerd - na wat lovende youtube filmpjes - om een automatisch chat-rag systeem in elkaar te klikken met N8N en wat andere tools en vibe coding. Ik vond het resultaat uiterst bedroevend en totaal niet aanpasbaar met wat ik zelf wilde.

[CrazyBernie]

Wij zijn ook weer gestopt met unit tests schrijven met behulp van een LLM. Onze ervaring was namelijk dat zodra je daaraan gewend raakte je soms gewoon compleet verkeerde unit testen over het oog zag.

Waar wij wel de een LLM voor gebruiken is naamgeving (soms is sparen over een bepaalde method of class naam heel handig), vragen om voorstellen om de code te verbeteren en dan zelf de voorstellen implementeren en om code templates voor visual studio te maken om zelf sneller boiler plate neer te zetten.

Maar mijn grootste probleem is dat je inmiddels begint te merken dat grote codebases niet meer publiek zijn want de kwaliteit van de welke AI dan ook is relatief gezien veel slechter met het gebruik van nieuwe API's of diensten dan 2 jaar geleden. Je merkt gewoon dat de toevoer van voorbeeld projecten aan het stokken is en dat het dan dus niet meer lekker werkt of relatief vaak hallucineerd. Onlangs nog een heel ding gehad met het gebruik van .net 9 waar ie consequent methods en classes bleef voorstellen die in .net 10 pas konden. Maar ook sommige nieuwere versies van AWS of Azure diensten blijft ie gewoon consequent halluniceren wanneer het gaat over basis vragen. En aangezien sommige van die diensten al een jaar oud zijn is dat echt een mega probleem, waarvan ik verwacht dat het alleen maar groter gaat worden wanneer de eerste rechtzaken over AI property theft een feit zijn.

Zelf vind ik het super goed in te zetten als prototype tool en daar zie ik een groot voordeel. Maar om nou te zeggen dat het de productiviteit met meer dan 5% verhoogd dan is het veel op dit moment.

Laatste punt is dat de kosten voor de AI tools ook nog flink omhoog moeten zodat alle investeren en running cost uitkunnen. Ben benieuwd wie straks voor gemiddeld 500 dollar in de maand dit nog steeds een super goed idee vind.

[Blinkin]

Mijn programmeerkennis is niet geweldig. Maar ik vraag mij dan toch af of een unit test door AI laten schrijven niet het hele punt van die unit test onderuit schoffelt?

Zoals ik hem zie benader je bij unit testing je code als een blackbox waar je weet wat je erin stopt en een bepaalde uitkomst verwacht. AI op zichzelf is al een blackbox, dus die ook de unit test laten schrijven klinkt tegenstrijdig en oncontroleerbaar. En je wilt juist controleren of de code doet wat je er van verwacht.

[demianmonteverd]

Dit is een hele goede vraag. Het werkt vrij aardig in de praktijk overigens.

De truuk is de setup van de test te bekijken zodra deze is geschreven en daarna te kijken naar de namen van de methoden en de assertions waar op getest word. Als deze juist zijn, kun je daarna gaan kijken naar de code, maar als deze al niet goed zijn hoef je natuurlijk niet te raden of de testen kloppen, ze kloppen dan natuurlijk niet.

Alles staat of valt bij je prompt en hoeveel context de LLM had op het moment van schrijven. Daarom is het soms zo onvoorspelbaar als je werkt met grote prompts, veel files, veel MCP en veel code. Er zijn veel truukjes die je kunt doen om met de context om te gaan, ik heb daar veel aan gewerkt zelf omdat ik al twee jaar werk met gratis modellen via aider. Inmiddels heb ik op het werk ook Claude. Het is goed om te begrijpen dat mensen die reageren een andere 'werkomgeving' kunnen hebben (taal waarin ze werken, tools, prompts, type werk dat ze proberen te doen, hoe ze deze ingeven, etc.). In deze thread bijv. schrijft iemand dat hij 's nachts ook zijn prompts ingeeft voor de LLM's, dat doe je waarschijnlijk wanneer je net zoals ik doe in prive, gratis modellen gebruikt met beperkte limieten. Andere schrijven over applicaties die ze schrijven in een middag van rond de 8000 regels, dat kan ook met de gratis modellen soms, als ze bijv. een nieuwe versie van gemini of chatgpt aan het testen zijn op openrouter bijv.. Maar over het algemeen genomen, zijn dit mensen met een betaald abonnement (edat werkt beter natuurlijk).

Als je wilt kun je zoeken naar de berichten die djwice eerder heeft geschreven hierover, ik heb zelf ook mijn aider workflow gedeeld in een andere forum thread. Djwice heeft geschreven vanuit zijn ervaring met betaalde diensten en ik heb mijn best practices bij gratis gebruik ervaringen opgeschreven.

[pietvelleman]

Hoe groot is jouw codebase die je voorlegt aan een LLM?
Ik geef een LLM nooit meer dan 50 regels code...

[demianmonteverd]

Voor de hobby, 100000 regels voor het gehele project. Ik geef altijd de files handmatig mee met aider. Een file is meestal minder dan drie honderd regels. Het gaat hier om Java voor de goede orde.

Als je 50 regels geeft dan moet bijna elk model er goed mee om kunnen gaan. Dat werkt ook nog prima met gpt-oss-120b. Als het niet werkt, laat even weten waar je tegenaan loopt, maar pas op dat je niet iets deelt dat van je werk is, etc..

[Blinkin]

Zeer interessant. Dankjewel voor het delen van je kennis en ervaringen hiermee.

[pietvelleman]

Onderstaande een simpel Python voorbeeld van een unit-test:

def add(a: int, b: int) -> int:
"""Retourneert de som van twee integers."""
return a + b

En dit is een simpel voorbeeld van een unit-test:

def test_add():
result = add(2, 3)
assert result == 5, f"Verwachtte 5, maar kreeg {result}"

Met een dergelijke test is het makkelijker om te controleren of de functie werkt of niet.
Vervolgens kun je iets veiliger aan de functie 'add' werken en allerlei zaken toevoegen. En een jaar later kan een collega er in werken... Je runt de test en dan kun je iig een aantal problemen afvangen (en zeker niet alles!)...

Zelf vind ik het schrijven unit-tests erg vervelend. En voor hobby-projecten doe ik dit ook zelden.
Maar met een LLM is het iig minder tijdrovend.

Wat je zegt... dat klopt. Als je de code van de unit-test niet begrijpt dan moet je er niet aan beginnen.
Maarrr unit-tests zijn - in mijn ervaring - niet zo ingewikkeld. De ingewikkelde dingen gebeuren in de functie 'add' zelf. De unittest controleert slechts:
- "wat die functie ook doet..." als ik 2 en 3 invoer, dan wil ik 5 terugkrijgen.
- En als ik een string bij een int wil optellen, dan wil ik foutcode x terugkrijgen.
- etc.

En onder de voorwaarde dat de codebase niet te groot is (ik geef een LLM nooit meer dan 50 regels code, en gemiddeld zo'n 25 regels), dan werkt het vrij goed.

[Annihlator]

De consensus is ook dat je Unit-testing enkel met whitebox principes doet vanwege die reden.

Middels een tweede blackbox kan je enkel result-verification doen; iets nogal anders.en dat kan pas nadat je die blackbox ge unit-test hebt... dit dien je enkel toe te passen wanneer je de werking van de eerste blackbox niet "hoort"/kunt weten.

Het verschil ligt hierin; de whitebox kan je ontwerpen om bewust ook edge-cases te verifiëren (doorgaans dé reden om te unit testen, by the way), als je dat middels een tweede blackbox doet moet je aannemen dat dit wel of niet gebeurt is, normaliter wordt die kans statistisch groter bij meer testen.

lang verhaal in het kort; als je iets met whitebox kan testen is dat accurater en minder resource-verslindend.

Mijn opvatting is zodoende dat zolang de testmethode niet bevestigt dat de edge-cases ook goed opgepakt worden, het gewoon geen unit-test genoemd dient te worden.

[Reactie gewijzigd door Annihlator op 30 december 2025 15:56]

[Blinkin]

Kan ik mij in vinden. Dank voor je toelichting.

[djwice]

Daarvoor heb ik een aparte workflow die de gebruiker begeleidt in het opknippen, dat doet de AI zelf, niet de gebruiker. Het is een stappen-plan dat het model volgt en steeds moet toetsen, zodat elk onderdeel behapbaar en overzichtelijk blijft; modulair.

Eigenlijk werkt dat ook heel goed bij menselijke teams, overzichtelijke modulaire code waar elke file maar 1 taak en doel heeft, netjes geordent in een uniforme logische structuur zodat je direct naar de juiste file gaat en weet waar je dingen moet toevoegen of aanpassen en hoe je die moet noemen.

Helaas zijn niet alle projecten al zo opgezet, maar als we dat wel doen, is het niet alleen fijner en sneller werken voor mensen, en zullen er minder fouten zijn; het werken met AI is dan ook ineens veel effectiever, de context blijft klein dus is het model sneller, en als alles ondubbelzinning benoemd is, is zowel bij mensen als bij AI de kans op (interpretatie)fouten vele malen kleiner.

Ik laat AI altijd veel testen maken en uitvoeren en ook goed beschrijven wat ie moet gaan doen, voordat ie code schrijft, dat gaat vele malen sneller dan mensen dat doen, maar helpt enorm in de kwaliteit en het kunnen laten zien wat de software doet en aanpasbaarheid door mensen later.

[djunicron]

Nou nou, 50 regels is wel weer heel klein...

Heb tot nu toe geen heel grote problemen ondervonden met b.v. 5500 regels aan Scala.

Meerdere componenten tegelijk gaat wel fout, kost ook gewoon teveel tokens. Maar functie voor functie is ook wel weer wat overdreven. Laat regelmatig LLMs stukken code refactoren, dat gaat zeker niet altijd in één keer goed, maar een document met 500+ regels recht trekken of verder abstraheren gaat prima! (Niet in de browser natuurlijk, CLI)

[barbarbar]

Niet om flauw te doen, maar heb je dit zelf al eens getest? Ik krijg fout op fout in de demo. Menu's die na de eerste klik niet meer werken.

Heel eerlijk: dit geeft het nivo aan van vibe-coding. Je komt met je basis dingen best een eind. Maar de gehele werking doorgronden, alles goed testen, zorgen dat je een productie klaar product hebt. Dat is dit niet.

Zonder programmeer ervaring is dit heel leuk gemaakt. Maar... dit zou op m'n mbo opleiding 20 jaar geleden een oefening geweest zijn.

[PrimusIP]

En dan is het nog iets wat niet werkt. Wat je ook kunt hebben is dat het wel werkt, maar dat de output gewoon onjuist is.

Stel je zet het voor data analyse in, dan kan zo'n AI ding prchtige diagrammetjes opleveren, maar je zult wel iemand moeten hebben die snapt wat die AI doet en een beetje verstand heeft van die materie. Anders neem je voor je het weet beslissingen op foutieve (eind)gegevens.

[Zorg]

Maar daarom kan het wel heel goed ingezet worden waarbij de output 100% juist is, alleen moet je daar als analist wel zelf in staat zijn om de verificatie te kunnen doen. Ik werk circa 20 jaar in (data)analyse in grote multinationals. Ik gebruik vibe coding elke dag in data analytics en ben daardoor vele malen efficiënter dan dat ik daarvoor was en hoef me niet druk te maken om het programmeerwerk. Ik geef gewoon aan wat ik wil, wacht tot het klaar is, doe de verificatie en als het ok is ga ik verder. Mijn focus is voornamelijk financiële dataanalyse waarbij ik dus perfect kan toetsen of hetgeen wat eruit komt 100% juist is.

Dus ook een vorm van vibe coding waarbij ik banale python programmeertaken echt niet meer zelf ga doen. AI is een tool die je als professional gebruikt en niet (direct) vervangt. Probleem is dat veel mensen zich nogal overschatten en denken dat hetgeen wat ze doen ook daadwerkelijk dataanalyse is. 9/10 keer zijn het manuele Excel robots die 80% bezig zijn met de data goed te krijgen (of er überhaupt in te krijgen) en dan eens 20% (op een goeie dag) daadwerkelijk zinvolle analyses maken waarbij het niveau qua wiskunde ongeveer gelijk staat als 3e jaars middelbaar. Guess what? Dat kan ai inmiddels al prima hoor ;)

Dit zegt overigens niks over de business kennis die er nodig is! Maar de gemiddelde onderneming qua data analyse is niks meer dan a+b=c , als ze daar al in slagen.

[Ulysses]

Ik heb een werkende versie in mijn eigen domein, die daadwerkelijk voor mijn usecase doet wat het moet doen. De code kun je zelf kopieren, aanpassen en gebruiken zoals je wil, maar ik verzeker je dat het werkt - als je er maar moeite voor wil doen. Je krijgt het gratis. Wat had je nu gedacht - ook nog support erbij?
Hier kun je LIVE-werkende demo plaatjes zien

[Reactie gewijzigd door Ulysses op 29 december 2025 17:17]

[barbarbar]

"Productie klaar" en "het werkt op mijn pc" zijn heel wat anders. Helemaal als je het groot verkondigd, en een demo adverteerd. Ben zelf ook ondernemer, en zo'n reactie is gewoon niet acceptabel. Maar goed, moet je zelf weten.

Ik vraag ook helemaal geen support, want zou niet weten wat ik er mee moet. Ik probeer je wat feedback te geven over een product waarvan je vond dat het productie klaar is.

[Reactie gewijzigd door barbarbar op 29 december 2025 17:30]

[RoestVrijStaal]

Ik heb een werkende versie in mijn eigen domein, die daadwerkelijk voor mijn usecase doet wat het moet doen. De code kun je zelf kopieren, aanpassen en gebruiken zoals je wil, maar ik verzeker je dat het werkt - als je er maar moeite voor wil doen. (...)

Huh? U zei wat?

Spreek je nu jezelf niet een beetje tegen?

[StefanJanssen]

Ik dacht zelf ook eens kijken en ik zie ook rare dingen, bij het registreren worden bv geen wachtwoord velden getoond ondanks dat dit verplicht is.

De Google Analytics banner is niet compliant, men zou dit moeten kunnen afwijzen (dit zou een gemiddelde developer ook zo bouwen, maar juist dit is iets waarvan ik dacht dat een AI dat wel zou kunnen)

Waarom is de 2FA zowel optioneel als verplicht? Ik denkd at de AI daar aan het hallucineren was?

[RoestVrijStaal]

Ik vind het erg jammer en vervelend dat je de reacties van mij, @djwice en anderen zo persoonlijk hebt opgevat en daardoor een over-the-top defensieve reacties er tegenover zet en later de boel hebt verwijderd en/of afgeschermd.

Ik hoop dat je ooit gaat begrijpen waarom men zo kritisch was.

Nogmaals, je presenteerde je vibe-coding gegenereerde applicatie als "klaar voor gebruik".

Gegeven de staat van de publieke versie van de code base, het juridisch plaatje die @Quintiemero en @Annihlator aankaarten en het feit dat die applicatie nogal wat persoonlijke gegevens gaat verwerken. Die combinatie maakt dat het live gaan van die applicatie bedenkelijk is.

Bezie de reacties als geen aanvallen op jou.
Ze zijn deels advies voor je eigen bestwil en deels een reactie op het gebruik van vibe-coding in het algemeen.

[Reactie gewijzigd door RoestVrijStaal op 30 december 2025 08:34]

[Ulysses]

Jouw bijdragen waren nog iets dat het meest leek op constructief. Feedback is ook beslist niet erg, onthoud dat als dit respectvol en met oog voor de persoon gebeurt - dit normaal geen probleem is.

Je verhaal mist een documentje uit mijn REPO, namelijk LEGAL (text-bestandje) en dat miste iedereen hier.

Daar staat dit in:

Verklaring Omtrent Doel en Risico (Proof of Concept)

Deze applicatie (de "Levensloop"-software) is ontwikkeld als een Proof of Concept (PoC).

Het primaire doel van deze software is om de kracht en toegankelijkheid van moderne AI-tools (zoals Vision- en Language-modellen) aan te tonen bij het verwerken en koppelen van diverse datapunten, zoals foto's, documenten en handmatige invoer.

Risico's en Misbruik

De functionaliteit die hier wordt gedemonstreerd — het uploaden van beelden, het extraheren van metadata (locatie, tijd), het analyseren van documenten, en het koppelen van al deze informatie aan specifieke gebeurtenissen — vormt in essentie een doxing kit.

Wanneer deze software in verkeerde handen valt, kan deze direct worden misbruikt voor het systematisch verzamelen, correleren en publiceren van privégegevens van een individu zonder diens toestemming.

Context

Hoewel het risico op misbruik reëel is, is het belangrijk te erkennen dat de onderliggende processen (het verzamelen en verwerken van data) in wezen niet verschillen van de praktijken van talloze legitieme, gegevensverwerkende bedrijven. Het verschil zit in de intentie en de juridische kaders.

Met deze simpele en doeltreffende code hopen we inzichtelijk te maken hoe laagdrempelig het is geworden om krachtige data-aggregatie tools te bouwen, en daarmee het belang van robuuste privacywetgeving en ethisch handelen te onderstrepen.

Tot slot geef ik toe dat ik mij persoonlijk uit de tent heb laten lokken en verlaagd heb tot een primair reactief niveau. Met een aantal dagen van minder dan 5 uur slaap. En een klant die ook mijn goede aandacht kreeg tussendoor IRL. We zijn mensen die machines besturen, niet andersom.

[Cartman!]

Het punt is meer dat je begon met "aardig productie gereedgemaakte" naar "works on my machine" en nu is het een "proof of concept". Het feit dat je meteen je code offline gehaald hebt bewijst voor mij dan ook genoeg. Echt geloofwaardig is het natuurlijk niet.

Het vat ook wel m'n eigen ervaringen samen met AI/LLMs: het is super handig als je weet wat je doet en het kan flink tijd besparen maar als je er niet in thuis bent is het gewoon wachten op security en/of performance issues. Ik hou m'n hart vast voor als dergelijke tools ooit in productie gaan draaien en er persoons- en betaalgegevens op straat komen te liggen.

[Ulysses]

Die tijdlijn klopt niet. Dat LEGAL bestand stond er altijd al in. En om de rest niet te laten gissen heb ik de Repo weer public gezet.

Ik zou het fijn vinden als mensen wegblijven bij intenties en kwade bedoelingen en vermeende handelingsbekwaamheid aan mij toe te schrijven. Je weet dit niet, kan dit niet weten en moet dit niet willen beoordelen.
Hier is het bestandje - kijk naar de bewerkdata.
https://github.com/PCPal-nl/LevensLoop/blob/Master/LEGAL

[Cartman!]

Ik zeg nergens dat het de tijdlijn is van het project maar wel hoe jij het hier hebt gebracht.

En qua code, als jij er blij mee bent helemaal prima natuurlijk maar dit volgt geen enkele standaard voor code (zowel qua code style als clean code), echt een rommeltje van alles door elkaar. Voor mij bewijst dit keurig waarom ik voorlopig niet bang ben dat vibe coding m'n functie zal overnemen.

Als basis om wel een productie waardige versie te maken kan het handig zijn maar persoonlijk doe ik t liever in 1 keer goed dan.

[Ulysses]

Doe maar.

[Cartman!]

Ik ben wel een stuk duurder dan je LLM alleen ;)

[Ulysses]

Ik ook.

[Annihlator]

Even om aan te vullen:

Het gaat hier ook om expectation-management. Je deed het voor alsof de weblet als een voorbeeld beschouwd zou kunnen worden van hoe mijn bestaande beeld van vibe-coding onderuit gehaald zou kunnen worden.

Maar als dan binnen zo'n 2 minuten er al van-alles opvalt, dan bevestigt het enkel mijn bestaande gevoelens over vibe-coding.

Ik ben bot genoeg om het als volgt te verwoorden:
Bij elk vakgebied waar enige techniek aan te pas komt, kan alles jofel lijken voor de non-expert.
Echter op het moment dat er een vakexpert langs komt, kan die voorspellen waar een niet-expert aan vergeet te denken.

Waarom ik dan vervolgens vooral het juridische deel aangrijp; hier kan je gewoon geen lukrake methodiek accepteren. Of alles is weldegelijk proper afgeborgen (en ook getest) of je dient het niet publiekelijk te exposen; vooral dat mensen grote platforms kunnen ontwerpen zonder dit te waarborgen is een van de dingen waar ik mij actief aan hekel bij Vibe-coding.

Een simpeler voorbeeld is anders de stijling/ux; Je gebruikt NOOIT donkerdere elementen tegen een lichtere achtergrond met meerdere overlopen. en áls je dat doet gebruik je geen flauwe schaduw om de rand the hinten ipv onderscheiden.
Je dacht zelf vast dat je er tegenaankeek "dit ziet er leuk uit", maar als ik er naar kijk denk ik "Dit is een accesibility-ramp!". (noot: ik ben een UX mierenneuker)

[Reactie gewijzigd door Annihlator op 30 december 2025 15:46]

[RoestVrijStaal]

Ik geloof dat je jouw post richting @Ulysses bedoelde, toch?

Het was even verwarrend om als bijstander overal "je" te lezen

Los van dat, kan ik deze quote van jou beamen.

Bij elk vakgebied waar enige techniek aan te pas komt, kan alles jofel lijken voor de non-expert.
Echter op het moment dat er een vakexpert langs komt, kan die voorspellen waar een niet-expert aan vergeet te denken.

Dit is helemaal waar.

[Reactie gewijzigd door RoestVrijStaal op 30 december 2025 16:03]

[Annihlator]

Oh ja sorry, ik had idd op de verkeerde post gereageerd omdat ik begon met "willen toevoegen" haha.

Vond het vooral wel zo eerlijk om een beetje toe te lichten waarom ik reageerde zoals ik deed :)

[Ulysses]

Ik vind het allemaal prima. Iedereen heeft meningen, ik had een productje. Niemand is verplicht het leuk te vinden. Succes met bestaan verder.

[Annihlator]

prototype*

[Quintiemero]

En je hebt een amerikaans privacy policy, why?

[Annihlator]

Noemt juridische entiteiten en gebruikt vervolgens de verwijzing naar een zéér brakke weblet...

Lijkt niet geheel verstandig.

[Hopperdepop]

Oei @Ulysses, iets aan de hand? Je GitHub repository juist op private gezet en je vibe-coded web application is offline zie ik?

[H.Boss]

Zelf heb ik ook wel wat programmeerkennis mbt JavaScript, Python, PHP.

Maar dat vibe-coding is echt een hele uitkomst. Ik doe tegenwoordig niet anders. Wat ik met mijn eigen kennis doe is vooral debugging en snel zelf nog wat dingen toevoegen of aanpassen.

Maar er rolt letterlijk binnen een aantal uren een heel complex systeem uit waar normaal een developer met een team misschien wel een hele week mee bezig is als je echt de code zelf schrijft.

Zelf merk ik in het onderwijs dat vibe-coding echt een hele uitkomst biedt, omdat collega's nu snel makkelijk gamification kunnen toepassen en oefenapps kunnen maken binnen no-time. Waar je normaal al gauw bij een externe aanbieder moet aankloppen en weer licentiekosten moet afdragen. Dus ik zie er veel voordelen in.

[Annihilism]

Zelf een poosje als hobby nog met python bezig geweest maar had er geen tijd meer voor. Misschien moet ik me er ook maar ééns in gaan verdiepen, vibe code klinkt als een behoorlijke tijdsbesparing. Heb je nog tips welke vibe-code platforms ik het beste kan gebruiken?

[Seamonstah]

Elke fatsoenlijke AI chatbot (Chatgpt, LeChat etc.) kan je daar mee helpen is mijn ervaring.

[H.Boss]

Bolt.new, Google AI Studio , Lovable.ai, v0, Replit etc. Deze tools bieden all-in-one oplossingen aan, zoals werkbare preview van de app, versiebeheer, databases, visual coding( selecteren welk elementen je wilt aanpassen) en hosting(link genereren naar je app als je deze snel wilt delen met mensen). Het zijn gewoon AI gestuurde IDE's en je kan dus zelf ook de code direct aanpassen. Je kan ook syncen met je eigen Github en uiteindelijk ook de code op je eigen domein/hosting plaatsen.

De normale AI chatbots zoals ChatGPT, Claude, Gemini etc. zijn uiteraard ook gewoon een uitkomst.

[Reactie gewijzigd door H.Boss op 29 december 2025 15:17]

[djwice]

Als je de standaard AI omgevingen de mogelijkheden wil geven van de tools die je noemt zoals lovable, dan kun je hier https://github.com/x1xhlo...ts-and-models-of-ai-tools kijken voor systeem prompts die je kunt omzetten naar instructies voor de AI omgeving die je gebruikt.

Inclusief de tool instructies / commandline instructies om bijvoorbeeld testen te draaien.

Uiteraard kun je ze ook verbeteren, zo kun je in plaats van react native html5/css3 en vanilla javascript er uit laten komen als je wilt.

[olafmol]

Uit interesse: hoe valideer je dat de applicatie daadwerkelijk doet wat ie moet doen? Heb je functionele en technische testen gespecificeerd die je kunt draaien? Context: Normaliter als je een extern team van developers aan het werk zet, is de Q&A vrij essentieel en onderdeel van de acceptatie criteria.

[djwice]

Je kunt dat inderdaad doen, o.a. AWS Kiro, Spect-IT en BMAT-Method zijn daar voorbeelden van; eerst specificaties duidelijk krijgen. En daarmee testen laten schrijven, je software structuur en opbouwen en dan de code. Het taalmodel kun je toegang geven tot het mogen starten van je test software en het lezen van de resulatten daarvan, en je kunt instruren wat daarmee gedaan moet worden.

[olafmol]

Zijn dat ook functionele testen? Bv BDD achtige frameworks zoals Gherkin/cucumber?

[djwice]

Ja, klopt, ik las eerst scenarios in gherkin schrijven, dan die implementeren en dan code structuur bouwen - welke functies zijn nodig -, dan unit tests - en dan de code.

Werkt erg fijn omdat de agent dan gedurende het code schrijven regelmatig de unit tests draait en dan weet wat er nog gebouwd moet worden.

En daarna de bdd test weer draait om te zien of alles ook werkt zoals bedoeld.

Scheelt veel handmatige feedback en iteraties richting de agent vanuit mij. Soms wel saai dan ben je aan het wachten tot ie klaar is met de iteraties en testen. Daarom is zo veel mogelijk parallel testen kunnen draaien belangrijk, dat scheelt tijd.

[eborn]

Vibe programmeren kan ideaal zijn voor situaties waarbij het niet uitmaakt of het werkt en/of veilig is. Daar ligt momenteel nog de echte kracht van AI. Natuurlijk zullen er ook situaties zijn waarbij het werkt voor productie-zaken, maar ik zou op dit moment mijn bedrijf er nog niet op laten lopen. Vergelijk het met outsourcing: als je de opdracht perfect omschrijft, dan kan er best een goed resultaat uit komen. De vraag is alleen of dat omschrijven uiteindelijk niet meer resources kost dan het daadwerkelijk bouwen.

[djwice]

Je zou kunnen kijken of https://github.com/dsilahcilar/sdlc-agents je verder kan helpen richting productie readyness. Op m'n werk hebben we een aantal java applicaties zonder toezicht kunnen upgraden naar een aantal versies nieuwer, inclusief dus de nieuwe patterns en het uitfaseren van oude patterns en lib-upgrades etc.

Dat duurde ongeveer 23 uur per applicatie.

Uiteraard is daarna de applicatie en de change log ook door mensen zorgvuldig doorgelopen en zijn alle tests uitgevoerd. Alles werkt naar behoren, 15 jaar oude applicatie. Dit is in een sterk gereguleerde omgeving met business continuity kritieke applicaties.

Er worden ook beheer agents gemaakt die incidenten verzamelen, omzetten in issues, tests en implementatieplan en uiteindelijk fixen.

[Reactie gewijzigd door djwice op 29 december 2025 19:27]

[H.Boss]

Helemaal mee eens!

Maar voor eenvoudige dingen zoals oefenapps, quizzapps, gamification etc zijn bijvoorbeeld docenten echt geholpen met dit soort vibe-coding applicaties. In het onderwijs wordt vaak gegrepen naar externe leveranciers van diverse apps, maar dat hoeft nu dus niet meer. Je kan letterlijk alles zelf bouwen met dezelfde functionaliteit. Het is daarom heel laagdrempelig.

Grotere complexe applicaties kan je prima maken met dit soort tools, heb ik zelf ook gedaan. Zowel in Javascript als Python. Maar dan moet je zelf de code reviewen(dus er is zeker wel kennis nodig van de programmeertalen) en checken op security. En daarbij kan je het ook ondersteunend gebruiken, dus advies of voor een snel concept.

[Mellow Jack]

Moeten we niet AI gebruiken om nieuw onderwijs te gaan bieden ipv dezelfde dingen doen alleen dan "efficiënter en goedkoper"?

Niet betwetend bedoeld hoor. Ik zit zelf in het ondersteunen van onderwijs en het is een onderwerp wat mee bezig houdt

[H.Boss]

Doe je ook op deze manier, want je zal apps en gamification willen toepassen om een deel van het vernieuwde curriculum op een aantrekkelijke manier te willen aanbieden. Dit staat los van de inhoud, dus ontwikkeling van het curriculum. Want dit wordt ook volop gedaan met behulp van AI. Maar die inhoud kan je op diverse manieren gebruiken en voor bijv. de vormgeving gebruik je dan vibe-coding om er een leuke game of app omheen te bouwen. Maar ook een leuke visualisatie, podcast, video, e-learnings etc, dat kan ook allemaal met AI.

Dus nee, de inhoud blijft zeker niet hetzelfde, althans niet binnen mijn organisatie. We zijn volop met vernieuwing bezig en ook zeker met het integreren van AI in het curriculum. Want uiteindelijk kunnen we niet meer omheen en zullen we het moeten omarmen, zowel studenten als medewerkers hierin meenemen en de professionalisering op dit vlak aanpakken.

[Reactie gewijzigd door H.Boss op 29 december 2025 18:15]

[Christoxz]

is dat zogeheten vibe-coding zonder IT-kennis nu echt wat?

Ja maar met heel veel haken en ogen.
Zonder IT kennis kan je echt wel een niet kritische (simpele) app in elkaar zetten, maar in sommige gevallen is echte kennis wel echt vereist om te kunnen auditen of het ook echt veilig is, en werkt naar behoren.

Het ligt er dus echt aan de complexiteit, doel, functies etc.

ziet iedereen met kennis binnen twee seconden dat je complete troep aanlevert

Dat valt echt wel mee, maar dat hangt weer af van de complexiteit. AI schrijft soms betere, georganiseerde code dan een gemiddelde developer.
Troep kan je het niet persee noemen, maar hoe het allemaal soms samen komt, kan wel troep zijn.

[Reactie gewijzigd door Christoxz op 29 december 2025 13:00]

[Zyphlan]

@Ed Vertijsment @Ulysses @himlims_@Christoxz bedankt voor de verduidelijking.

Ja ok , dan komt het dus aardig goed overeen met Sales/Marketing bij Chatgpt het kan een heel mooi plan schrijven maar zonder de onderliggende knowhow weet je nou niet echt of het ook echt klopt en of het geschikt is waar je het voor wilt gebruiken.

[himlims_]

Een van de onderdelen die ik een ai altijd aangeef; [i]bij twijfels, maken van keuzes of ondeugdelijk instructies vraag mij om toelichting[/]


Duurt wat lang(er) maar functioneel krijg ik vaak wel een beter resultaat

[Reactie gewijzigd door himlims_ op 29 december 2025 13:29]

[Henk1827]

20+ jaar softwareontwikkel ervaring. Eerder hierop gereageerd: Henk1827 in 'Techreuzen pompen elkaars waarde op: waarom vrees voor een AI-crash toeneemt'

Ik heb betaalde Claude en Copilot en gebruik het regelmatig. Voor simpele taken die niet zo exact hoeven te zijn is het heel nuttig. Wordt het ook maar een beetje complex, gaat het nut gauw achteruit. Iedereen kan nu een frontend inelkaar vibecoden. Maar voor productieapps moet je begrijpen wat er gebeurt, er daar is vibecoding bijna niet geschikt voor. Er zijn al diverse onderzoeken die laten zien dat voor productieapplicaties je 0-10% meer productiviteit kán hebben. Dat is ook wat ik en 90% van mijn collegas ervaren. Trap niet in de marketing BS. Het is een handige tool, voor sommige type devs meer dan andere, maar niet meer dan dat.

[djwice]

Hoe is you set-up met Claude? Gebruik je custom skills, custom agents en workflows waarin je de project context ondubbelzinnig vastlegt? En modulair ontwikkelen met files < 200 lines of code, met 1 taal per file (dus geen configuratie + code in 1 file, geen HTML + CSS in 1 file, geen HTML uitschrijven met code, geen SQL in je programma files etc.)

Zo ja, waar gaat Claude bij jou de mist in en waarom? En welke dingen heb je gedaan om dat te voorkomen?

[Reactie gewijzigd door djwice op 29 december 2025 20:01]

[Henk1827]

Je vraagt hier zoveel tegelijk, ik krijg de indruk dat je op deze manier de discussie probeert uit te putten en zo in jouw voordeel probeert te beslechten. Ook heb je alleen voor dit artikel al 14 (!) comments achtergelaten, allemaal waarin je met weinig of geen onderbouwing Tweakers die niet zoveel nut in AI zien becommentarieert.

Als jij succes hebt met AI, leuk voor je. Maar de grote meerderheid van de developers ziet het als een nuttige tool, niet meer. Ben je niet overtuigd? Kijk eens in https://www.reddit.com/r/ExperiencedDevs/ of https://www.reddit.com/r/vibecoding/ en je ziet overal hetzelfde liedje: superhandig voor simpele taken, kleine refactor, one-shot scripts, prototyping, etc. Serieuze productiecode afleveren? het kan, soms, met extreem context management en een hoop geluk. Verwacht geen wonderen van AGENTS/CLAUDE.md, agents en andere “game-changers. Als senior ontwikkelaar ben je in 9/10 gevallen sneller, lever je hogere kwaliteit, en heel belangrijk, snap je beter wat je doet als je zelf de code schrijft.

Kan iemand me een seintje geven als deze gebakken lucht show voorbij is? ❤️

[djwice]

De reden dat ik deze vragen stel is omdat ik bij mij op het werk zie dat mensen vaak het model bijvoorbeeld niet vertellen wat de DoD van het team is, en dan verbaast zijn dat de output van het model niet voldoet aan hun DoD.

Ik probeer mensen inzicht te geven hoe ze stappen kunnen zetten hoe de tool nog nuttiger voor ze kan zijn.

En inzicht te verwerven waar mensen tegen aan lopen en waardoor de komt.

Ik kan er niets aan doen dat jouw referenties een andere ervaring hebben dan ik. Ik weet alleen wat ik doe waardoor het voor mij werkt. En probeer te leren waarnemer het voor anderen niet werkt en wat het verschil is en waardoor dat komt.

Dat is te ch niet raar?
Ik wil geen discussie maar uitwisseling van inzicht. En dat wil ik juist niet stoppen maar aanwakkeren door vragen te stellen, juist omdat er geen onderbouwing van oorzaak bij staat vaak. Dat een ander dezelfde ervaring in een paper of blog zet boeit niet zo, interessanter is om te weten waarom het gebeurd en wat we kunnen doen om elkaar te helpen.

Ik loop letterlijk tegen een bilability probleem omdat ik te snel ben door AI. Een taak van 3 maanden voor 2 senior ontwikkelaars deed ik in 4 uur, maar wij starten pas mee de rekening sturen na 2 weken werk en we hebben alleen uurtje factuurtje contracten in die sector.
Dus willen detacherings managers mij niet inzetten op die projecten - de klanten wel. Dus veroorzaakt een spanning.

Dus je kan proberen mij te overtuigen, maar zoals je in verschillende van mijn reacties leest, ik schrijf letterlijk op wat ik mee maak en doe. Ik kan er niets aan doen dat jou ervaring - en zoals je aangeeft van vele anderen - anders is. Ik neem je graag mee op mijn reis zodat je ook mijn ervaringen kunt hebben.

Maar je kunt ook kiezen om het te negeren en je te verschuilen achter 'gebakken lucht' of 'markering'. Maar kijk even goed. Ik schrijf zonder enig eigen belang: geen eigen tool promotie, geen eigen bedrijf promotie etc.
Wel tips en linkjes in reverse posts. Doe er je voordeel mee zou ik zeggen.

[Reactie gewijzigd door djwice op 29 december 2025 23:48]

[Bor]

Een taak van 3 maanden voor 2 senior ontwikkelaars deed ik in 4 uur, maar wij starten pas mee de rekening sturen na 2 weken werk en we hebben alleen uurtje factuurtje contracten in die sector.

In 3 uur kan je doorgaans die code niet eens goed auditen en grondig testen..

[djwice]

Dat verschilt van persoon tot persoon en hoe je de repo en software architectuur hebt opgezet. Door goede opzet, zorgvuldige automatische testen etc. is de software veel beter te doorgronden dan een gemiddeld project van een mens.

Van begin tot eind pas ik al mijn design best practices toe, is intensief werken en continu alert zijn, dat klopt. En design first, etc. en baat gelegd in instructies en testen.

Ik neem dat je ervaring hebt met het automatiseren van alle testen, van security, code analyse tot aan bdd en unit testen en dat je die altijd zo veel mogelijk paralel executeert zodat de testen allemaal samen binnen een paar minuten klaar zijn. En unit testen allemaal samen nog veel sneller.

Dat is wat ik sinds 2016 doorgevoerd heb, ook presentaties gegeven over hoe je 1000 headless browsers in parallel kunt aansturen om extreem snel je website te kunnen testen. De hele test van je site duurt dan zo lang als de langste deel test.

Tegenwoordig laat ik AI deze tests starten op het moment dat ie denkt klaar te zijn en dan de output weer tot zich neemt en kijkt waar ie nog fouten heeft gemaakt, en die worden dan weer automatisch aangepakt. Door het modulaire ontwerp blijven we netjes binnen de context grote van het model, en maakt het minder fouten en blijft de code overzichtelijk met gemiddeld 100 regels code per bestand. En zo min mogelijk externe libs, liefst alleen de standaard libs van het framework dat gebruikt wordt en meer niet. Dat houdt de boel simpel en overzichtelijk, voor mensen en voor AI.

[Reactie gewijzigd door djwice op 30 december 2025 22:42]

[Ed Vertijsment]

Ligt eraan, een simpel scriptje in elkaar flansen werkt prima (als het niet te specifiek wordt). Wil je de architectuur bewaken en controle houden over specifieke requirements en of implementation details wordt het snel minder.

Als assistance prima, standalone serieuze projecten zie ik et (nog) niet.

[djwice]

Als je gebruik maakt van de workflow, skill en agent modes en duidelijke instructies geeft en modulair in kleine bestanden laat ontwikkelen - bijvoorkeur ook elk type taal in een aparte file, elk type functionaliteit in een aparte file, etc.

Dan blijft de context klein en kan de flow van zelfs tienduizende regels code foutloos worden geïmplementeerd. Bijvoorbeeld een heel systeem inclusief infrastructuur, firewalls, containers, cloud en onprem infra én de software die er op draait én de logging én de documentatie én de test én HIPAA en PCI-DSS compliant, WCAG 2.1 AA, Observatory A+, Light House alles groen, OWASP test: 0 findings, SonarQube : on par met eisen, etc.

Juist door het toevoegen van allerlei testen en de resulatten te laten consumeren kun je heel goed sturen zonder daar zelf iets voor te hoeven doen anders dan vereisen dat de testen voldoen aan je eisen.

Dit een keer goed vast leggen en mensen met minder ervaring of kennis kunnen het systeem gebruiken om goede software te maken.

[Reactie gewijzigd door djwice op 29 december 2025 19:49]

[Oon]

Met weinig kennis kun je heel snel een leuke webapp bouwen, maar daar stopt het ook. Iteraties daarna zijn bijna niet te doen, en de code die eruit komt is gewoon van dusdanig lage kwaliteit dat je er echt geen productie mee in wil gaan. Al die mensen op bijv. Twitter die zelf een appje hebben gemaakt met ChatGPT en daar geld mee willen verdienen zijn heel gevaarlijk bezig, want één kwaadwillende bezoeker met genoeg kennis en er liggen heel wat persoonsgegevens op straat.

[SwaggyEggs]

Met Firebase App Check en Database security rules kan je dat wel aardig afvangen en hoef je dus niet te coden

[Reactie gewijzigd door SwaggyEggs op 29 december 2025 14:45]

[Merik]

Zelf niet zo'n ervaring mee, maar bij een toepassing als een webshop lijkt me dat dat zoiets best wel een beveiligingsrisico geeft, als de app toegang heeft met klantengegevens. Maar dat kan je ook opsplitsen in tweeen (1 gewone, 1 'AI'-app).

Bij simpelere toepassing zoals verwerken van klachtenformulieren of data in het algemeen heb je dat probleem sowieso een stuk minder.

[aikebah]

Vergis je niet in de data-risico's van klachtenformulieren. Net als voor support tickets verwacht ik dat daar heel wat jan-doedels veel meer persoonlijke data delen dan goed voor ze is.

[barbarbar]

Het is voor mij een ondersteuning die het saaie repeterende deel weer een stukje weg neemt. En ik ben soms écht verbaasd in wat het kan voorstellen. Soms ben ik ergens mee bezig, denk: hier moet ik wel twee dagen voor uit trekken. Gooi een prompt in AI en een uur later kan ik een functie opleveren.

Andere keren, zoals vanochtend nog: collega gooit wat spul door AI, denkt dat ie een heel eind is. En vervolgens zijn we samen nog de hele ochtend bezig om zelf de oplossing te bedenken voor een bug. Want wat AI voorstellende klonk wel goed en logisch, maar was gewoon compleet nutteloos.

AI mist alle informatie die een ontwikkelaar wel heeft. AI kan soms hele goede code voorstellen. Of snel dingen omzetten waar ik handmatig veel meer tijd aan kwijt zou zijn. Maar écht snappen waar het mee bezig is zoals een mens, dat kan AI niet.

[olafmol]

En als je de Ai agent wel van die missende info voorziet? Welke info is dat precies? Bv specifieke domein kennis?

Zelf is mijn ervaring met Ai agents dat je ze, net als externe developers, moet voorzien van zoveel mogelijk en zo specifiek mogelijke info en context. Bv SpecKit e.d. helpen daarbij goed. Als je goed specificeert scheelt dat echt veel.

Wat AI zo tricky maakt is dat ze echter geen intelligentie hebben, alleen platte kennis uit informatie. En ze hebben ook geen ingebouwd model van de wereld en hun rol daarin, zoals wij mensen wel hebben. Daarom kunnen we als mens best veel aannames doen over wat een ander mens allemaal snapt zonder dat we dat expliciet hoeven te benoemen. Wat bij een ai agent wel expliciet moet worden benoemd. En dus tijd kost.

Verder is de communicatie stijl zodanig dat het lijkt alsof de inhoud en geproduceerde content heel hoogstaand is qua kwaliteit. Maar dit hoeft absoluut niet het geval te zijn, en het is dus heel lastig om daar doorheen te prikken. Je zult allerlei truukjes en guard rails moeten inbouwen om de daadwerkelijke kwaliteit te valideren, zeker ook omdat er erg snel erg veel content kan worden geproduceerd, en dit allemaal met de hand uitpluizen is bijna niet te doen zonder de efficiency teniet te doen.

Ben benieuwd wat er nog aan tools en ontwikkelingen komen om bovenstaande uitdagingen aan te pakken.

[Ruthhl3ss]

Dit is exact mijn ervaring. :-)

[djwice]

Hoe kun je AI de context/informatie geven die de ontwikkelaar wel heeft?

[Rogers]

Ik denk dat we nog veel data lekken gaan zien door ge-vibe code applicaties van mensen die niet de benodigde kennis hebben.

[Bor]

Die kans is behoorlijk groot. Ai code is niet altijd geoptimaliseerd en vibe coded apps worden niet altijd gereviewed of geaudit. Daar is kennis en tijd voor nodig.

Ik heb een paar testen gedaan met het schrijven van een simpele web app waarbij de standaard Ai output basis zaken als sql injection meerdere keren niet wist te voorkomen.

Natuurlijk kan je daar beperkt wat aan doen door eisen te stellen en kaders te scheppen maar veel mensen zullen dat niet doen. Programmeren is nog steeds een vak.

[Reactie gewijzigd door Bor op 30 december 2025 11:46]

[himlims_]

zeker; maar .... ik merk wel, dat je wat technische know-how moet hebben, wil je 'eruit krijgen' waar je om vraagt. maar inmiddels 2 tools gemaakt; eoa linux netwerk ping ding, en vandaag een volledig werkende chrome-extentie

[Cambionn]

Een goede developer is vele malen beter dan een AI, maar AI is met regelmaat beter dan mediocre developers. Helaas bestaan er ook een hoop menselijke devs die net zo goed onveilige, slecht geschreven en slecht maintainable code vol fouten schrijven. AI is daar niet uniek in.

Maak ervan wat je wil. Imho: of het wat is hangt af van een hoop afwegingen en variabelen.

[Reactie gewijzigd door Cambionn op 29 december 2025 13:27]

[JairSterre]

Ja en nee.

Ja, het kan volledig functionele webapplicaties schrijven, ook met compliance en alles van de GDPR.

Nee, het kan niet een platform uitdenken zoals mensen dat doen. Het neemt een soort gemiddelde van alle in de dataset gevoerde code plus je prompt, en creeërt een product dat zo veel mogelijk als een antwoord op je prompt(s) zal antwoorden. Het kan ook niet alle veiligheidsmethoden (juist) implementeren, het zal zich niet altijd aan je design guidelines houden(kleuren e.d. wel maar grootendeels standaard CSS of andere GUI opmaaktalen)

Ja en nee dus, als je vraagt om een simpele database tool moet je zelf maar rekening ermee houden dat het mogelijk niet GDPR-compliant is, wanneer je prompt niet juist gestructureerd is om dat te doen.

Het beste is om deze programma's niet te gebruiken als je zelf absoluut niks van programmeren weet, iets met AI alignment en dat soort dingen. Als je zo'n programma redelijk kan doorlezen om te controleren dat het geen onnodige of onbekende libraries gaat zitten inladen om functies uit te voeren die je niet kent, dan zou het een mooie, snellere oplossing kunnen zijn om een programma te schrijven.

[djwice]

Ik heb hem voor een samenwerkingsverband van streamingdiensten in Duitsland de infrastructuur kunnen laten ontwerpen in 2 minuten die volledig aan alle wensen en eisen voldoet, sterker nog, ze ver overtrof ook qua kosten (extreem veel lager).

En dat was met een agent die ik eerder geschreven had om te voldoen aan alle eisen die ik altijd stel aan infrastructuur ontwerpen.

En eerder een volledig infra + metadata + applicatie archiectuur ontworpen met AI binnen een dag voor een systeem met miljarden berichten en bijlages, vele malen efficientere achitectuur dan die er stond, met dezelfde hardware en tools. En ook geïmmplementeerd in die dag, wat voorheen maanden werk was voor meerdere teams.

Maar wellicht kan dat inderdaad alleen als je echt weet wat je doet en de AI bij kunt sturen of al de exact juiste dingen kunt vragen. Daarom maak ik steeds vaker agents die anderen kunnen gebruiken waarin ik mijn "standaard" heb vastgelegd, zodat hun werk daar aan zal voldoen als ze de agent gebruiken,

[Luchtbakker]

Voor de echte IT’ers onder ons (waar ik er zelf niet 1 van ben) is dat zogeheten vibe-coding zonder IT-kennis nu echt wat?

Of is het, net als bij ChatGPT in sales, vooral schijn?

Ik weet niet hoe het met Macaly zit. Ik heb wel ervaring met bouwen van complete systemen met bijvoorbeeld Claude en Chatgpt. En zeker met Claude is dit echt wel mogelijk. Wel moet je zelf wat debug kennis hebben want het maakt zeker geen foutloze code, maar het komt er aardig in de buurt van.

Het is echter door de limieten wel een prijzige hobby. Maar het is slechts de prijs van 1 uur een echte dev inhuren dus alles is relatief.

[System]

Het gaat voor kleine stukjes. Denk aan een functie optimaliseren of een bug op sporen.
Maar echt complete applicaties ontwikkelen is nog heel ver weg.

Maar browser plugins of zo kan al.
Of heel kleine websites die niet te veel moeten doen.

[Zorg]

Hangt van je applicatie af. Wil je Enterprise software ontwikkelen? Dan niet. Wil je efficiënter kunnen werken en daarvoor een webapp maken? Complete apps in een vrijdagmiddag.

Voor mijn onkosten (reizen voor werk) moet ik een expense nota binnenbrengen. Wij hebben geen (dure) SaaS oplossing en moeten dit rechtstreeks in SAP invoeren. Dus heb ik een simpele webapp gemaakt waar ik reizen kan aanmaken, foto's kan uploaden, analyseren met openai api en de bonnetjes omzetten naar data, deze in een tabel gooien om handmatig eventueel te kunnen overwriten (bv een datum die verkeerd wordt gelezen) een pdf (moeten we toevoegen) en een excel (makkelijker om te pasten in SAP) aanmaakt voor me.

Simpel appje wat me een namiddag heeft gekost. Bespaard me een hoop frustratie en werk en werkt meer dan voldoende voor het doel. Het noemt treffel, omdat mijn eerste speech to text commando van ik wil een travel appje maken werd vertaald naar treffel

[Reactie gewijzigd door Zorg op 29 december 2025 15:23]

[fuzzyIon]

Voor de echte IT’ers onder ons (waar ik er zelf niet 1 van ben) is dat zogeheten vibe-coding zonder IT-kennis nu echt wat?

Jazeker wel. Mits je logisch kan nadenken en bereid bent om te leren gaandeweg. Is dat het geval dan ga je als een speer en bouw je in no time linux ebpf modules die bijvoorbeeld bij sockets accept() deny keihard enforcen. Als je een stille client only verbinding wil. Of je bouwt enterprise grade netwerken in een maand tijd waar ervaren mensen soms wel een half jaar over doen. Kort gezegt garbage in is garbage out en onthoud je de pitfalls en hou je het overzicht dan zijn tools als Chatgpt goud waard. Maar kerst kaartjes en wallpapers laten maken kan natuurlijk ook. Het is maar net wat je wil.

[Bender]

Ja, het werkt.. maar ook weer niet.

Maar je weet niet echt wat het doet zonder de kennis en controle.
Je kunt dus vragen "Maak de klanten voor me inzichtelijk", maar je hebt geen idee of er dan niet ergens een publieke pagina ontstaat waar alle klanten te zien zijn.
(tenzij je een code audit doet, maar het is door ai-code heel lastig doorheen te komen)

Code efficiency is in mijn ervaring ook nog een probleem, je hebt steeds nieuwe wensen, en die wensen komen bovenop bestaande wensen. Code wordt niet echt herzien maar er wordt weer iets bovenop gezet, als je dat vaak doet komt het niet ten goede van de hoeveelheid code en dus snelheid.
Ik heb ook al bij andere gezien dat database tabellen gedropt worden, omdat het iets verkeerd interpreteerde.

Dus het is prima voor niet kritische business zaken of je wil wat spelen, maar je moet er voorzichtig mee zijn.

[Indy81]

Zoals ik het nu zie is dat AI voornamelijk junior developers kan vervangen.

Dit zal later problemen geven op de arbeidsmarkt. Niemand zoekt meer junior posities, dat kan AI wel doen. Zo worden er geen juniors meer aangenomen en kunnen juniors ook nergens meer een baan vinden en zullen zo nooit senior worden.

Wat hou je dan over: Seniors. Te weinig seniors zelfs, want bedrijven kunnen de functies van Juniors makkelijk opvullen met AI, maar hebben daar niet genoeg seniors voor om dit bij te houden.

Dit kan betekenen dat de werkdruk te hoog wordt, of dat er seniors bij andere bedrijven weg gekocht worden.

Al met al, het zal er niet prettiger op worden.

[djwice]

Leg je kennis en stappen plannen vast in markdown, refereer naar commandline executies die je doet, en als je dat goed doet sta je verbaast hoe senior de AI zich kan gedragen.

[Reactie gewijzigd door djwice op 29 december 2025 20:08]

[unf0rg0tt3n]

Zelf heb ik via Jules een App ge-vibecode om een hypervisor te manager op android. Nu was dit vrij eenvoudig te realiseren omdat de API goed gedocumenteerd is. Daarnaast heb ik nog niets online gezet omdat ik midden in het proces zit, maar vooralsnog werken alle functies 100%. Jules maakt Branches aan per feature set (als je daar om vraagt), die je dan intensief kunt testen en bijsturen door te reageren op de pull requests voordat je een merge doet.

Wat ik tot nu toe heb, werkend en wel:

• Backups plans maken, aanpassen en uitvoeren
• Inzicht in alle statistieken
• VM management met: metrics, remote shell, aanpassen en toevoegen van hardware, snapshots, backups en powercontrol
• cluster management met shell
• storage overzicht meet de inhoud hiervan, vulling van schijven etc.
• Tasks: gelukt, failed, in progress en de informatie
• Uiteraard dark mode
• MFA (alleen nog TOTP)

Nog lang niet af, maar nog lang niet gepubliceerd.

Wat ik wel heb gemerkt met AI vibecoding: Onzin in = onzin uit. Je moet praten alsof het een 2 jarige is. Je moet precies vertellen waar het moet kijken en je moet zeker goed bijsturen.

[HijDieAllesWeet]

Ik ben geen programmeur. Maar afgelopen jaar wel met Ai meerdere appjes gebouwd. Ze zijn heel simpel, voornamelijk dingen die we hiervoor gewoon op een papieren formuliertje bijhielden en dan handmatig in een spreadsheet zetten.

Het is allemaal niet heel belangrijk, zeker niet de kosten waard om een extern bedrijf voor in te huren. Ik heb vroeger wel een klein beetje geprogrammeerd. En met genoeg googlen zou ik het zelf ook wel kunnen maar zou heel veel tijd kosten.

Met Ai heb je in paar uurtjes wel gewoon een prima werkend simpel appje. En nu ik het een paar keer gedaan heb ben ik in een uurtje wel klaar. Best wel handig hoor!

Je moet wel echt oppassen dat je steeds kleine stapjes neemt. Soms gaat ie ook de mist in en dan wordt het alleen maar erger als je verder gaat. Sowieso als er wat fout gaat heb ik niet echt de kennis om het op te lossen. Als je de app uit wil rollen naar gebruikers zou ik het zeker anders aanpakken. Maar voor iets simpels dat je met een paar mensen intern gebruikt echt dikke prima.

[johnbetonschaar]

Mijn ervaring tot nu toe (ben er nog niet heel diep in gedoken overigens) is dat als ik al weet wat ik nodig heb en hoe ik het moet doen, de code zelf intiepen of refactoren simpelweg sneller gaat dan wachten op de AI agent, die vaak ook nog meerdere iteraties met extra instructies nodig heeft voordat hij doet wat ik wil. Alleen heel specifieke mechanische refactoring ('verplaats deze code', 'hernoem al deze variabelen op de volgende manier', etc) leveren tot nu wel wat tijdwinst op maar ook alleen als er veel code moet worden veranderd.

Als ik nog niet precies weet wat ik nodig heb of twijfel aan mij eigen oplossing dan genereert de AI vaak best wel nuttige code die regelmatig in theorie zo gebruikt zou kunnen worden. Ik gebruik die code dan meestal alleen als voorbeeld en doe de aanpassingen handmatig.

Als ik uberhaupt geen idee heb wat een mogelijke aanpak is en er dus research nodig is dan is de AI chat functie super nuttig, veel efficienter dan zoeken op internet. Voor mij is dat op dit moment de grote toegevoegde waarde.

Denk overigens dat het er erg van af hangt wat je maakt, ik schrijf zelf bijna alleen maar system/lbrary-level code en praktisch geen UI/frontent. Afgezien van snippets voor standaard algoritmen werkt de AI daar niet heel best voor (voor mij tenminste), het resulteert bijna altijd in onnodige complexiteit en architectuur keuzes die ik zelf nooit zou maken. Voor web frontend code zal het vast en zeker beter werken. Ik denk echter dat je zelfs dan niet veel verder gaat komen dan een proof-of-concept als je zelf geen idee hebt wat de code die de AI genereert nu precies doet.

[djwice]

Als je als IT-Expert de juiste instructies definieerd voor de agents komt een persoon zonder IT-kennis heel ver. Dus ja dit kan én het kan heel goed. Zo heb ik een AWS Infrastructuur als Code expert gemaakt die in een minuut of 2 een compliant infrastrcutuur definieerd, van firewall, cdn, gateways, routing en functions.
De agents ontwerpt altijd conform mijn best practices en de hoogste eisen die regelgeving kan stellen.

En beschrijft waar elke keuze gemaakt heeft.
De infrastrcutuur als code bevat geen hard gecodeerde input, dat gaat parametrisch en ook die is zo danig afgeschermd met validaties en meldingen dat de eindgebruiker die parameters zonder extra hulp foutloos kan invoeren.

Uiterard helpt het in complexe situaties als de gebruiker kennis heeft en kan bij sturen, maar dat zijn vooral kleine finesses.


Maar ook voor het veel simpelere als een website, heb ik voor HTML5/CSS3/SVG/emoticons en script specifieke instructies die er voor zorgen dat de meeste AI-modellen zo goed als geen fouten maken, typisch minder dan de meeste ontwikkelaars.

Voor PowerPoints heb ik een abstractie ontworpen die er voor zorgt dat AI foutloos huisstijl slides maakt. Het bedrijf waar ik werk heeft meer dan 400 verschillende elementen die op een slide kunnen worden gezet en daar kunnen AI-modellen door de abstractie laag foutloos mee omgaan.

En die laatste wordt gebruikt door non-IT mensen om presentaties te maken.
Scheelt ze vele uren tijd.


Ik verwacht dat BlueTeam de AI inzet met templates voor de bestaande CMS-en zoals WordPress. Met een validatie laag die valideerd of de abstractielaag goed is ingevuld. Met de huidige modellen van bijvoorbeeld Qwen in combinatie met ollama of andere intterface is dat prima te doen.

[Reactie gewijzigd door djwice op 29 december 2025 15:32]

[Menesis]

Werkt alleen voor simpele boiler plate achtige dingen. Maar zodra het om complexere zaken gaat, gaat het steeds vaker de mist in. Ik heb nu een jaar verschillende hobby projecten geprobeerd in andere taal. Mijn achtergrond is ontwerper en kennis van alleen C# binnen Unity. Het is gelukt om een kaarten app te maken die data van verschillende APIs inzamelt en in 1 kaart verwerkt. Maar wat dan weer niet lukt is een complexer stuk software maken waarbij frameworks moeten worden gebouwd (openCV) en dan bijv als Unity plugin moeten worden gemaakt. Gaat helemaal de mist in, nu al 5x geprobeerd op verschillende (vibe) manieren . Terwijl het wel mogelijk is.

Het blijven echt LLMs (met de nadruk op language), die eigenlijk geen logica begrijpen.

Maar het is onwijs handig als hulp, als je naar veel kleinere contexten kijkt. React dingetje hier, integratie daar. Dat werkt wel.

AI bubble burst in 3,2,1...

[Reactie gewijzigd door Menesis op 29 december 2025 16:18]

[Amanoo]

Ik heb onlangs een simpele app gevibecoded omdat ik geen zin had in Qt te leren en omdat ik slecht ben in UI design. Ik had het net zo goed wel kunnen leren. Het resultaat is precies wat ik wilde, maar ik was lang genoeg bezig met dingen fixen en prompts opnieuw vragen om het zelf te doen.

En ik vroeg ooit AI om een pagina te beveiligen achter een inlogmenu, en hij deed gewoon een andere pagina waar je inderdaad heen gaat als je het wachtwoord goed hebt, maar je kon ook direct de pagina intikken in de URL balk en dan hoefde je het wachtwoord niet in te voeren. Het deed heel letterlijk wat ik vroeg, maar niet wat ik wilde.

En dan heb je soms momenten dat het dingen verzint die gewoon niet bestaan.

[xelagbs84]

Op tweakers altijd weer een hoop negatieve geluiden over coden met Ai. In de tussentijd draai ik meer productie met twee man dan 3 jaar geleden met 12 man. Tegen dezelfde budgetten. Ik sluit 2025 met een mega winst nadat ik pre ai in 23/24 bijna alles kwijt was door te lage marges.

[jorisvergeerTBA]

Ja het werkt, maar je moet heel goed de relevante context en specificaties in de prompt neerzetten. Of met een goede agentic tool die zelf zorgt dat de tool zelf relevante context op kan zoekt binnen je codebase. Echter moet je dan ook nog steeds je project goed beschrijven in agent instructies, en zorgen dat je voldoende consistente code hebt waar de LLM vanaf kan afkijken hoe jij je code structureert.


Vibe code vanaf scratch werkt inderdaad niet. Maar als je je skelet al hebt. En je hebt al een paar data modellen en controllers in je project heb zitten kan je heel goed een model je data formaat geven en vragen of die voor dat data formaat code wilt schrijven in dezelfde structuur als de bestaande code.

Dat werkt meestal wel gewoon goed.


En je moet ook echt wel wat geld neerleggen voor goede resultaten. Verwacht niet goede resultaten met de budget of free varianten van een LLM. Maar een OpenAI ChatGPT 5.x Codex die iets van 10-20 euro per miljoen output token kost levert echt wel resultaat.


In mijn ervaring levert op deze manier werken sneller beter resultaat dan uitbesteden aan India of aan een junior. Waarbij de Junior vooral veel kan leren van code die door chatgpt geschreven word.


Maar het belangrijkste is dat je nog altijd een ervaren programeur nodig hebt om een goed werkend skelet meer te zetten. (Zeg het uitdagende deel van programeur zijn). En als het saai wordt waarbij je vooral steeds hetzelfde truukje aan het herhalen bent, dan kan je een LLM voor een groot deel het werk laten doen.

En bonus tip, laat de LLM (in geval van agentic coderen met bijv. Codex) dan ook de unit tests schrijven, compileren en uitvoeren. Dan zal deze daarna nog zijn eigen fouten herstellen voor een groot deel.

Bonus bonus tip: Specificeer in je agent.md (de instructies voor de agent) wel dat die tijdens het unit testen enken zijn eigen relevante unit tests moet doen. Anders raakt de context heel snel te vol met onrelevante unit test resultaten.

[Atlantis1995]

Ik maak actief gebruik van Claude. Dat werkt goed, maar je moet oppassen dat AI niet je project overneemt. D.w.z. dat je het a. functioneel niet weet wat er in zit en b. dat dat gene erin zit onderhoudbaar is voor de toekomst. Los daarvan moet je AI soms naar een bepaalde richting delegeren als die bij een wijziging blijft hangen en je echt denkt dat AI iets ander moet doen.

Maar dit doen zonder kennis van zaken kan niet. Misschien dat het hier meer bouwblokken zijn. Maar echt complex zal het dan niet worden.

[BPG908]

Het lijkt wel alsof er enkel developers reageren die bang zijn voor hun baan. In mijn bedrijf werken geen developers meer in de traditionele zin van het woord. We werken allemaal met AI (Cursor), voornamelijk met Opus 4.5. Het zijn veel grote projecten en we werken voornamelijk met PHP (Laravel) en .NET. (niet met elkaar ;-) Het zijn allemaal ontwikkelaars, in de zin dat ze begrijpen wat de bedoeling is van de code en de structuur, maar het zelf nouwelijks code kunnen schijven.

Iedereen die zegt dat het niet werkt, heeft het of niet (goed) geprobeerd, of is bang voor zijn baan. Werk je functies uit met de planmodus, schaaf het plan bij tot je tevreden bent en bouw je functie. Bouw niet je hele project met één plan, maar doe dit per functie, stuk voor stuk.

Is de output 100%? Nee, maar zeker niet minder dan die van een medior developer met 5+ jaar ervaring.

Het is zeker niet gratis, vooral niet met Opus en het duurste Cursor-abonnement, maar onze output is ongeveer x20 gegaan. "Probeer" je het op gratis modus, en verwacht je dan de output van een senior, tja.. dan "werkt het niet" nee.

[Zyphlan]

Maar dan vraag ik me af , je hebt dus geen juniors meer nodig hoe ga je dit aanpakken? Op een gegeven moment zijn je seniors op.

[demianmonteverd]

De kwaliteit van de modellen blijft toenemen (voor nu in elk geval). Het is inderdaad een probleem voor de toekomst.

Ik zou zeker niemand aanraden nu in te stappen in de IT, tenzij je wilt gaan werken in een omgeving waar veel aspecten spelen op het gebied van defensie (zeker nu), privacy, etc., en je daar mee wilt gaan werken. Beter even wachten tot we weten hoe we mensen moeten inwerken in deze nieuwe wereld. Hoewel het niet echt heel snel lijkt te gaan, gaat het wel snel genoeg om 'disruptief' te zijn.

[BPG908]

Je hebt niemand meer nodig die code kan schrijven, letterlijk niet. Ik heb al maanden geen regel code geschreven.

Een junior, een senior; het maakt niet uit in de ‘oude’ betekenis ervan. Je hebt enkel iemand nodig die snapt hoe code werkt, en die snapt hoe je ai kan promoten en creatief genoeg is de juiste vragen te stellen en opdrachten te geven voor en eindresultaat wat je zoekt.

[sdziscool]

Als persoon met IT kennis die de replies hier leest kan ik zeggen dat basis IT skills nog steeds best belangrijk zijn voor het ontwikkelen met AI.

Dingen zoals version control lossen een hoop van de problemen op, maar schijnbaar als je toch al geen programmeren wilt leren en alles met AI wilt doen is Git leren een stap te ver.

Ook is weten wat je wilt heel belangrijk, je kan leuk een idee hebben, en de AI wilt nog best meedenken, maar uiteindelijk moet je de AI 'sturen' zodat het dingen efficient/correct implementeerd. Anders wordt het heel snel heel vervelend als de AI iets niet goed begrijpt, want jijzelf begrijpt het ook niet echt.

Denk dat het vooral interessant is voor proof of concept ideeen, als jij een versie 1 wilt om van te leren. Iets echt klaar/afmaken werkt alleen voor simpele dingen.

[Jumpiefox]

Voor simpele webapps, waar het je niet veel uitmaakt hoe de architectuur in mekaar zit en beveiliging werkt het prima. Voor complexere projecten is het voor iemand zonder technische kennis op een gegeven moment niet te doen. Voor iemand die kan programmeren en zelf al complexe apps kan bouwen is AI imo gewoon een wonder tool. Ben zelf bezig met een enterprise app, heb vandaag in 9 uurtjes 1500regels aan code "geschreven". Alles volgens de spec. Dat zou me zonder AI op een gemiddelde dag niet zo snel lukken. Die focus zit er gewoon niet in zo lang en al helemaal niet elke dag. Code verspreid over meerdere controllers/entities/bussiness logica/wip front-end pagina's etc. Je moet het alleen wel heel gestructureerd doen. Voordat ik begin bespreek ik het hele project. Laat ik de Ai een plan maken gebasseerd op mijn input. Verdelen we het werk in hoofdstukken. Ik weet dat na ongeveer 2000-3000regels chatgpt bv al heel traag wordt. Dus werk ik met milestones. Zo van als dit af is: Dan kan ik soort van "opnieuw" verder met de rest van de functionaliteit al vergeet de AI de context (nieuwe chat). Ik neem wel een prompt mee en een pdfje met een samenvatting zodat het wat achtergrond info heeft.

En dat is waar het dan fout gaat bij pure vibe-coding. Op een gegeven moment verliest de AI de context en de link tussen alle bestanden etc..als programmeur weet ik precies hoe de architedtuur in mekaar zit en kan ik de Ai prima sturen. Ik vraag het eigenlijk om gewoon functies/code te schrijven die ik zelf ook zou schrijven..

Ik combineer AI ook gewoon. Heb ik bijvoorbeeld wat werk af, en het lijk allemaal prima en goed, volgens onze spec etc..dan laat ik bij Copilot (claud sonnet 4.5) er ook ff naar kijken. Van hey, geef eens wat feedback. Zo heb ik ook wat leuke dingen geleerd waar ik eerst niet zo snel aan had gedacht.

Dit gaat ook alleen maar beter worden. Vandaag was voor mij echt zo een moment dat ik dacht wow..heb letterlijk maar een keer of 4 wat moeten verbeteren zelf. Kan me echt voorstellen dat als je bijvoorbeeld met agents werkt, meerdere ai's die mekaar controleren/verbeteren/context bewaken het maken van complexe apps "ai-solo" niet een droom is.

[PLYRZR0]

Heel eerlijk, ik ben dan ITer en heb wat basic verstand van een paar programmeertalen

Via vibe coden maak ik nu volledig websites in een handomdraai. Je kan in principe elke functie binnen 1 of een paar prompts toevoegen en na elke nieuwe versie krijg je steeds betere resultaten.

Alleen wat je duidelijk merkt is dat de kwaliteit van de output sterk afhankelijk is van de kwaliteit van de input. Jij kan een expert in Python of JavaScript zijn, maar als jouw prompts slecht zijn, krijg je ook slechte resultaten.

Het is zeker niet perfect en zelfs zonder kennis krijg je de fouten snel gevonden.

Eerst werkte ik met WordPress en dan betaal je al snel voor wat uitgebreidere functies en een leuk thema. Vibe coden is vele malen makkelijker, goedkoper, sneller en toegankelijk.

Meerdere tevreden klanten ondertussen met websites, webshops en een paar PaaS oplossingen.

Je kan gewoon gratis versies gebruiken en eens proberen. En je kan uiteraard ook iets simpels maken voor jezelf ook mee te experimenteren. Bijv. een timer app/website.

Let niet op die zure mensen die moeite hebben met verandering of bang zijn dat ze binnenkort niet meer relevant zijn. Daar komen 99% van de negatieve reacties vandaan en die zijn (subjectief) volledig onterecht!

[Slavy]

Daarom dat de Trans-IP prijzen omhoog zijn gegaan, ze hadden geld nodig om troep te kopen.

[Sponge]

Klopt, ik heb het enkele jaren aangezien, maar ik ben er nu ook echt klaar mee qua tarieven.

Ik ben ondertussen elk domein een maand voor een verlenging aan het verplaatsen naar een andere partij (gisteren toevallig ook weer en transfer in gang gezet). Met slechts een handvol aan domeinen bespaar ik gewoon honderden euro's.

Enige wat ik wat eng vind is de webhosting waar mijn hoofd email account aan hangt. :)

Vanmiddag ga dan ook beginnen met een nieuwe VPS.. bij Hetzner krijg ik heel wat meer terug qua specs voor een lagere prijs.

[Luchtbakker]

Vanmiddag ga dan ook beginnen met een nieuwe VPS.. bij Hetzner krijg ik heel wat meer terug qua specs voor een lagere prijs.

Hetzner is ook gewoon een hele degelijke partij en hebben hun zaakjes absoluut dik op orde. En de prijzen zijn ook zeker prima. Ik heb jarengeleden alle VPS en hosting diensten al bij ze ondergebracht. Mijn domeinen heb ik volledig naar Oxxa.com verhuist en dat scheelde ook bakken met geld.

TransIP heeft ook prima diensten hoor, maar de prijzen staan absoluut niet meer in verhouding met de concurrentie.

[pven]

Toevallig ben ik recent naar Oxxa overgestapt voor mijn domeinen. Scheelt tientallen euro's per jaar, zonder dat het zo te veel moeite kost. Al dat fancy gedoe heb ik niet nodig, dus waarom daar indirect aan mee betalen.

[Saven]

Inderdaad. Thanks but no thanks Ali

[Lord Anubis]

Ben er iets meer dan een jaar daarbij geweest. Te veel issue’s, mogelijkheden waar ik voor kwam werkte niet. Volgorde van iets bewaren werkte niet, tickets gemaakt. Te langzaam, beloftes en uiteindelijk bleek het niet te werken en wilden geen tijd aanbesteden om het te fiksen en zou uitgefaseerd worden.
ook dat opslag gebeuren, veel te traag.

[Maverick2001]

Het zal wel een meerwaarde hebben voor sommige klanten, maar ik zie de meerwaarde voor mijzelf niet.  Ook ik heb het jaren aangezien en sinds een paar maanden geleden toch alles weggehaald bij Transip. Ik wil wel even vooropstellen dat ik altijd heel tevreden ben geweest over de stabiliteit van de servers. Alles was prima geregeld, maar na de laatste prijsverhogingen was ik er eigenlijk wel klaar mee. Ook bij het kleine broertje Vimexx heb ik de domeinen weggehaald na de zoveelste verhoging.

[Morkatog]

Ik denk dat dit ook niet gericht is op de gemiddelde Tweaker als klant, maar vooral op de minder technische klanten die bijvoorbeeld via een dergelijk systeem een website willen kunnen maken. Op dat gebied zijn er nu een paar vibe-tools op de markt en hoewel die naar mijn mening nog ruimte voor verbetering hebben zie ik daar het nut wel van in.

Ben je bijvoorbeeld gitaarleraar en heb je werkelijk nul verstand van wat dan ook qua techniek en wil je een eigen website? Praat met een chatbot en krijg er een. Nou snap ik dat systemen als WordPress en Weebly de drempel op technisch vlak al verlagen, maar voor meeeer dan genoeg mensen is dat nog steeds een drempel te ver. Dat is de groep klanten die je met een systeem als deze bedient.

[Skit3000]

Als je zoiets in de handen van niet-technische eindgebruikers geeft, moet je (denk ik) ook een soort van dashboard beschikbaar stellen met daarop een lijst met alle eisen zoals die via de chat zijn ingegeven (of "bedacht" door de AI). Als je voor elke eis op de achtergrond een test laat genereren, kan je na elke via de chat aangevraagde wijziging tonen welke eisen niet meer strikt worden opgevolgd. De gebruiker kan dan extra context geven ("oh ja, dat was ik vergeten") waarna de test kan worden bijgewerkt, of een handeling terugdraaien of anders implementeren.

[dbzokphp]

Wat ik me afvraag, krijg je wel toegang tot de code van je website, wat deze AI-chatbot creëert? Zo ja, welke programmeertaal is het? Gewoon static HTML of ook PHP/andere talen?

Aan de ene kant zou je denken dat je wel toegang krijgt, gezien je normaal ook een hostingpakket hebt waarbij je toegang hebt tot je bestanden.

Maar ik kan me voorstellen dat dit een apart pakket kan zijn waarbij je website uitsluitend via deze tool te beheren is, zonder dat je bij de code kunt komen. Daar ben ik dus wel benieuwd naar. In dit geval ben je denk ik beter af met bijvoorbeeld WordPress i.c.m. een AI-plugin voor het creëren van je website, dan blijf je veel flexibeler zonder vendor lock-in.

[Bender]

Ja je krijgt toegang tot de code, het ziet er overigens qua gui niet heel anders er uit dan Lovable, Google AI Studio of Bolt.
(screenshot)

Alle tools die ik noemde maken Typescript, nu weet ik niet wat Macaly doet want dat kan ik helaas niet vinden.

[willemb2]

Sinds het private-equity bedrijf HG Capital team.blue in 2018 of 2029 overnam had ik de indruk dat het vooral uitgemolken werd (elk jaar flinke prijsverhogingen zonder noemenswaardige vernieuwing).
Ik hoef gelukkig niets met AI, maar dit lijkt me meer dan "we doen iets met AI omdat dit nu eenmaal de hype is". Het lijkt me echt iets nieuws, op de toekomst gericht. Misschien te danken aan het Canadese pensioenfonds dat vorig jaar voor 20% ingestapt is. Bron.

[kodak]

Met geen woord lijkt het bedrijf dat deze dienstverlening maakt, net zo min als de nieuwe investeerders, verantwoording te tonen voor veilige ontwikkeling of hun verantwoordelijkheid daarin. Het lijkt een groot marketingverhaal alsof niet-technische klanten, zonder enige basiskennis, maar apps of websites kunnen laten maken. Als je als bedrijf bewust wil verdienen aan ondeskudige klanten dan hoort daar op zijn minst vooraf bij te blijken dat je verantwoording af legt ze geen slechte kwaliteit te leveren. Anders is er geen duidelijke ondergrens aan het leveren en lijkt het doel kennelijk geld verdienen aan onwetendheid en onnozelheid van klanten die in de marketing trappen dat dit hun zou helpen.

[spep]

ik gebruik het om php6 om te zetten naar php8 , en 99% werkt dan weer

[HSG]

Dat is goed nieuws want dan kun je al die duurbetaalde ontwikkelaars op straat gooien.