Nieuwe plek in de Devschuur?

[Sp00n]

Ik ben geen programmeur. Maar ik bouw tegenwoordig wel apps met AI.

Ik kan code een beetje lezen en ik kan bugs fixen met AI.

Maar ben ik nu echt software aan het ontwikkelen? (Ja!)

De komende maanden / jaren gaat dit gebied een enorme vlucht krijgen. Iedereen kan straks apps bouwen. Voordat ik mijn eerst app gepubliceerd kreeg, ben ik door heel veel LLM's en CLI's en AI Studio's heen gevlogen.

Nu weet ik een beetje wat werkt en wat niet en hoe ik dingen aan moet pakken.

Ik kan me voorstellen dat er heel veel van dit soort vragen en walkthroughs komen van mensen die hier actief mee aan de slag gaan.

Zou het dan niet een mooi moment zijn om hier een apart plekje voor in te richten in de Devschuur? Vibe coding?

Ben benieuwd naar jullie mening...

[ZveenT]

Leuk idee - volg.

[Harmsen]

Iets soort gelijks is bij het bedrijf waar ik werk ook gebeurd: Laagdrempelig de enthousiastelingen voor AI assisted coding bij elkaar zetten. Omdat ze elkaar lieten zien wat ze maakten ontstonden meteen ideeën om nog meer aan elkaar te koppelen en volgende stappen te maken.

Hierdoor zie je dat het gebruik van AI icm MCP en Instructions ook ervoor zorgt dat er niet alleen mee geprogrammeerd wordt, maar ook review slagen op architectuur designs worden gedaan. Daarna wordt met AI ook de Work items/Test cases in het item tracking systeem aangemaakt. Dit was normaal handwerk wat niemand leuk vond om te doen...

Natuurlijk blijft het een hulpmiddel, dus controles voeren we altijd uit op wat er gemaakt wordt!

Dit zou ook prima hier op Tweakers kunnen! Ik denk dat juist kennisdeling en ideeën opdoen waardevol kan zijn.

[SiErRa]

Ah een real-life vibecoder.

Als ervaren developer vind ik het echt een doodeng fenomeen. Niet vanwege mijn eigen toekomst ofzo, maar mee vanwege de gevolgen:

Je bent als vibecoder toch een beetje een olifant in een porseleinkast.
Het ding met AI is dat je de output die je terugkrijgt niet voor waarheid moet aannemen, want is het gegenereerd en het kan best fout zijn.
Maar als vibecoder doe je dit wel, want je kan zelf niet inschatten of de geproduceerde code klopt. Dan kan je denken, ah de AI kan ook best debuggen en de bugs oplossen. Maar dan moet je wel weten dat die bugs er zijn. Als iets functioneel niet goed werkt, dan ontdek je dat wel, maar als er een security probleem in zit, dan merk je dat niet. Totdat het te laat is.

Die opleiding is niet voor niets en gaat niet (alleen) over het produceren van de juiste syntax, dat is eigenlijk bijzaak.

Maar wel goed om er hier over te posten, want dat kan er hopelijk nog wat worden bijgestuurd, voordat het mis gaat.

[Sp00n]

Ik test alle apps die ik maak natuurlijk ook zelf.

Dat kan nog steeds betekenen dat er ergens onder water iets niet goed gaat, maar de output is wel wat ik wil.

Security problemen merk je als je zelf codeert ook niet altijd. Maar ik moet zeggen dat ik ook nog geen (geautomatiseerde) pentesten heb geprobeerd, noch iets van security libraries toegevoegd omdat ik ervan uitga dat het voor de simpele dingen die ik maak, niet nodig is.

Ik zal eens vragen aan m'n AI of het nodig is ;-)

De discussie is voor mij vooral bedoeld om dit topic op het focum wat meer aandacht te geven. Misschien is Devschuur niet de juiste plek, dat zou kunnen. Maar het is wel een heel interessant groeimarkt voor Tweakers denk ik.

[Cartman!]

Sp00n schreef op maandag 2 februari 2026 @ 11:49:
omdat ik ervan uitga dat het voor de simpele dingen die ik maak, niet nodig is.

Daar gaat het al mis. Security is niet iets erbij, het is absolute noodzaak vanaf t begin af aan goed te doen.

Development is veel meer dan wat code produceren.

[Marber]

Mijn beheerdershart doet nu al pijn

[Patriot]

Op zich zou ik het als ontwikkelaar best grappig vinden om te zien waar mensen die verder geen ontwikkelervaring hebben zoal mee aan de slag gaan, en zou ik gerust ook wel een beetje willen sturen of helpen.

Wel deel ik de vrees die @SiErRa ook heeft, dat juist dit soort ontwikkeling erg gevoelig is voor het introduceren van subtiele maar relatief ernstige beveiligingsproblemen. Op oppervlakkig niveau zijn in LLM's er in mijn ervaring best goed in om consequent de basale beveiligingsmaatregelen in acht te nemen, maar ook makkelijk gaten over het hoofd zien. Dat gebeurt 'echte' ontwikkelaars natuurlijk ook, maar het is m.i. ook een beetje te simpel om te doen alsof die twee dingen hetzelfde zijn.

Dat gezegd hebbende, op zich hoeft het ook weer niet in de weg te staan dat we er een forumonderdeel aan toewijden.

[Kheos]

Sp00n schreef op maandag 2 februari 2026 @ 11:49:
Ik test alle apps die ik maak natuurlijk ook zelf.

Dat kan nog steeds betekenen dat er ergens onder water iets niet goed gaat, maar de output is wel wat ik wil.

En da's meteen al een attitude verschil met een 'echte' developer. "Het werkt toch?" is niet hetzelfde als "het is makkelijk uit te breiden en te onderhouden" bijvoorbeeld.

Sp00n schreef op maandag 2 februari 2026 @ 11:49:
Security problemen merk je als je zelf codeert ook niet altijd. Maar ik moet zeggen dat ik ook nog geen (geautomatiseerde) pentesten heb geprobeerd, noch iets van security libraries toegevoegd omdat ik ervan uitga dat het voor de simpele dingen die ik maak, niet nodig is.

En da'a een tweede attitude verschil.
Want na een tijdje wil je die app uitbreiden, uitbrengen... En ineens moet je alles from scratch herschrijven omdat de AI alles met gare SQL statements aan elkaar heeft gehangen. Weet jij veel waarom dat niet de way to go is: als AI het zegt zal het zo slecht niet zijn, zeker?

[Sp00n]

Kheos schreef op maandag 2 februari 2026 @ 11:56:
En da'a een tweede attitude verschil.
Want na een tijdje wil je die app uitbreiden, uitbrengen... En ineens moet je alles from scratch herschrijven omdat de AI alles met gare SQL statements aan elkaar heeft gehangen. Weet jij veel waarom dat niet de way to go is: als AI het zegt zal het zo slecht niet zijn, zeker?

Ik kan je verzekeren dat dat (gare SQL statements) niet gebeurt (bij de AI die ik op dit moment gebruik).

Ik zou em eerder omdraaien. Waar is je technical debt?

Kan best zijn dat de app helemaal opnieuw wordt opgebouwd bij een update met de nieuwste libraries en frameworks. Ik weet niet of dat een feature of een bug is.

We zijn met ons bedrijf nu al 18 maanden bezig om naar een nieuwe architectuur te gaan. En het duurt waarschijnlijk nog een jaar voor we weer "on par" zijn met ons huidig product. Dat is me ook een partij ellende.

[Cartman!]

Sp00n schreef op maandag 2 februari 2026 @ 12:06:
Ik kan je verzekeren dat dat (gare SQL statements) niet gebeurt (bij de AI die ik op dit moment gebruik).

Hoe kun je dat verzekeren als je zelf eerst aangeeft geen programmeur te zijn?

[Kheos]

Sp00n schreef op maandag 2 februari 2026 @ 12:06:
[...]
Kan best zijn dat de app helemaal opnieuw wordt opgebouwd bij een update met de nieuwste libraries en frameworks. Ik weet niet of dat een feature of een bug is.

Geen feature, wel een bug. Slecht design ook trouwens. Nu kost het je x maanden aan testing effort extra omdat je nergens meer op kunt vertrouwen.

[Lethalis]

Het vervelende van AI is dat normies nu denken dat programmeren iets is dat je wel even snel kan doen. De waardering voor het vak daalt zienderogen.

Dat vind ik persoonlijk erg jammer. Ik heb een groot deel van mijn leven gestoken in het leren van alle ins en outs, om een betere software ontwikkelaar te worden. Om nu de hele tijd geconfronteerd te worden met dat AI mijn baan gaan inpikken.

Vooralsnog geloof ik daar niet in, maar het is wel iets dat het verdere traject van mijn loopbaan kan beïnvloeden. Ik sta eigenlijk voor een T splitsing waarin ik of een betere domein specialist moet worden (waarbij het echte programmeren een steeds kleinere rol gaat spelen, en ik meer moet leren over de dingen die ik programmeer), of juist mijn technische kennis naar een niveau moet tillen waar ik geen last meer heb van vibe coders (als ik low level C++ of Rust software programmeer die kritiek is voor het aansturen van allerlei processen en hardware, dan is dat veel te spannend om daar AI op los te laten).

Ik weet nog niet wat het gaat worden eerlijk gezegd

De tijd dat we als software developers makkelijk geld verdienden is wel een beetje voorbij. Je moet straks echt dingen kunnen die normies niet voor elkaar krijgen met AI.

Cartman! schreef op maandag 2 februari 2026 @ 12:10:
[...]
Hoe kun je dat verzekeren als je zelf eerst aangeeft geen programmeur te zijn?

Dat vraag ik mij ook af

Ik heb zelf 4 SQL Server certificaten, en nog een paar andere SQL certificaten van het HBO en de universiteit, en schrijf al 20+ jaar SQL statements en hou daarbij rekening met indexing strategieën, analyseer data execution plans, enzovoorts.

Is al die kennis nu zinloos? Ik kan het mij bijna niet voorstellen Ik hoop het niet althans.

Kortom, laat die SQL statements eens zien!

[ Voor 20% gewijzigd door Lethalis op 02-02-2026 12:15 ]

[Sp00n]

Lethalis schreef op maandag 2 februari 2026 @ 12:11:
Vooralsnog geloof ik daar niet in, maar het is wel iets dat het verdere traject van mijn loopbaan kan beïnvloeden. Ik sta eigenlijk voor een T splitsing waarin ik of een betere domein specialist moet worden (waarbij het echte programmeren een steeds kleinere rol gaat spelen, en ik meer moet leren over de dingen die ik programmeer), of juist mijn technische kennis naar een niveau moet tillen waar ik geen last meer heb van vibe coders (als ik low level C++ of Rust software programmeer die kritiek is voor het aansturen van allerlei processen en hardware, dan is dat veel te spannend om daar AI op los te laten).

Ik denk beide. Leer samen te werken met AI. Vriend van me heeft een software bedrijf met programmeurs die zeer nadrukkelijk worden aangespoord om AI te gebruiken. Scheelt gewoon heel veel tijd. En bij hun is het natuurlijk anders dan bij mij.

Zij krijgen een nieuw stuk code en weten precies wat dat doet. Ik denk veel meer: ja het zal wel.

[Sp00n]

Cartman! schreef op maandag 2 februari 2026 @ 12:10:
[...]

Hoe kun je dat verzekeren als je zelf eerst aangeeft geen programmeur te zijn?

Ik heb informatica gestudeerd, niet afgemaakt.

SQL vind ik niet echt programmeren. Ik kan SQL lezen en schrijven.

Belangrijker is je databasestructuur denk ik.

[Yucon]

Ik vind het wel interessant om eens te zien wat voor een soort vragen naar boven komen. 20+ jaar geleden ben ik developer geweest en ik heb ook een opleiding in die richting, maar daarna ben ik de business kant uit gegaan. Tegenwoordig gebruik ik regelmatig LLMs om wat code in elkaar te draaien voor prototypes/PoC's/data-transformatietooltjes die in de IT context blijven en het niet tot bedrijfskritische prod tooling schoppen.

In die zien ben ik me door mijn achtergrond wel bewust van wat je ook vooral niet dat spul moet doen. Maar tegelijkertijd zie ik als bedrijfskundige ook dat klassiek programmeren ook z'n tekortkomingen heeft waar het om bovengenoemde use cases gaat.

Daarnaast zijn alle risico's en tekortkomingen die bij vibe coding horen ook wel gewoon een soort nieuwe iteratie van alle ellende die je bij gare access tooltjes of excel macro's had.

Ergens ben ik daarom wel heel benieuwd waar zo'n topic toe zou leiden.

[Lethalis]

Sp00n schreef op maandag 2 februari 2026 @ 12:16:
[...]
Ik denk beide. Leer samen te werken met AI. Vriend van me heeft een software bedrijf met programmeurs die zeer nadrukkelijk worden aangespoord om AI te gebruiken. Scheelt gewoon heel veel tijd. En bij hun is het natuurlijk anders dan bij mij.

Zij krijgen een nieuw stuk code en weten precies wat dat doet. Ik denk veel meer: ja het zal wel.

Het scheelt in mijn geval erg weinig tijd, maar dat komt ook omdat ik bijna uitsluitend bestaande software moet onderhouden. En elke regel code die ik tik, kan vergaande gevolgen hebben in het systeem... dus ja, dat laat je niet aan AI over.

Soms laat ik Copilot Chat weleens wat stukjes code genereren en meestal schud ik dan mijn hoofd en schrijf ik het alsnog zelf.

Ik denk dat AI veel meer van invloed is op nieuwe projecten. Als je snel iets nieuws wil bouwen. Zodra je aan een systeem werkt dat al decennia cruciale bedrijfsprocessen ondersteunt dan ga je daar niet achteloos in harken.

Maar zelfs dan vraag ik me soms af wat ik eraan heb en kom ik in een prompt loop terecht met een AI die nogal vaak "je hebt gelijk" schrijft, om vervolgens weer iets te doen wat ik niet goed genoeg vind En dan komt er vanzelf een moment dat je het zat bent en weer ouderwets zelf gaat doen.

Mijn probleem met AI is alleen dat ikzelf die technische eisen stel aan de software. Mijn opdrachtgever boeit het wellicht minder en daar loert het gevaar. Dat er ergens een "goed genoeg" situatie komt, waarbij mensen de lat simpelweg minder hoog leggen.

Kortom, "het doet het toch?".

Dat zou al het plezier uit software ontwikkelen voor mij halen, omdat ik juist de kwaliteitsattributen van complexe systemen interessant vind (de -ilities). Het wordt dan niet zozeer een kwestie van of ik AI zou kunnen gebruiken, maar of ik het überhaupt wil. Als wij naar een wereld gaan waarin alles AI slop wordt, dan check ik uit en ga ik maar een ander vak leren

[Yucon]

Sp00n schreef op maandag 2 februari 2026 @ 12:16:
[...]
Zij krijgen een nieuw stuk code en weten precies wat dat doet. Ik denk veel meer: ja het zal wel.

Ik denk dat dit een misvatting is. Volgens mij is het eerder zo dat zij weten waar ze op moeten letten om te zien of het goed zit, en dat ze intuïtief beter in kunnen schatten waar de problemen gaan zitten.

[CodeCaster]

Ik ben een verstokte back-end-developer die dat ruim anderhalf decennium als beroep uitvoert, en na drie jaar te hebben gehaat op alles wat naar AI ruikt, ben ik dankzij een paar weken Claude Code licht overstag.

Het is nog steeds objectief allemaal bagger wat er uit LLM's komt, maar je hebt qua applicatie wel snel iets relatief functioneels staan. Zo heb ik met het handje een datamodel en een set API's gebouwd die precies doen wat ze moeten, en het zal mij een worst wezen of de front-end 1 MB of 20 MB is en of het Vue 3.1 of 3.2 is.

Die front-end hebben we met twee man en een paar dagen vibe-coden mooi wel neergezet, iets wat anders een designer en een front-ender een veelvoud van die tijd had gekost.

Dus meer aandacht voor zo'n werkwijze kan in de Devschuur wat mij betreft geen kwaad. Laat men elkaar wijzen op tooling, werkwijzen, valkuilen en wat dies meer zij.

Ik ben alleen bang dat je, net als in het AI-softporn-topic, alleen maar prompting heroes krijgt die je wel even vertellen dat het aan je prompt ligt als iets niet doet wat je verwacht, maar niet hun werkwijze delen. Laten we daarop letten.

[Sp00n]

Misschien nog even goed voor alle reageerders die wat offtopic gaan.

Ik snap dat de dino's de lucht in kijken en zich niet realiseren dat het toch een flinke komeet is die op (jullie) ons afkomt.

Het gaat me meer om de discussie of dit een aparte plek verdient binnen GoT. Er zijn genoeg pro's en con's te bedenken voor vibe coding / programmeren met AI. En er zijn zeker grote risico's.

De vraag is of we daarmee onderdeel van het probleem of van de oplossing kunnen zijn door hier een plek te bieden waar mensen terecht kunnen voor hun vragen / verhalen / twijfels.

[Lethalis]

CodeCaster schreef op maandag 2 februari 2026 @ 12:35:
Het is nog steeds objectief allemaal bagger wat er uit LLM's komt, maar je hebt qua applicatie wel snel iets relatief functioneels staan. Zo heb ik met het handje een datamodel en een set API's gebouwd die precies doen wat ze moeten, en het zal mij een worst wezen of de front-end 1 MB of 20 MB is en of het Vue 3.1 of 3.2 is.

Dat is dus exact wat ik bedoel met de lat minder hoog leggen

Maar goed, ik zal wel een echte dino zijn die nog geeft om de efficiency van zijn software.

[Joep]

Hoewel ik vibe coding maar niks vind, mag er wat mij betreft best een subforum voor gecreëerd worden. De devschuur is op het moment namelijk zo dood als een pier en mogelijk is het een opstapje naar daadwerkelijk fatsoenlijk programmeren voor beginnende leken.

[CodeCaster]

Lethalis schreef op maandag 2 februari 2026 @ 12:40:
[...]

Dat is dus exact wat ik bedoel met de lat minder hoog leggen

Maar goed, ik zal wel een echte dino zijn die nog geeft om de efficiency van zijn software.

Ik geef absoluut om efficiëntie, maar die halen we in dit geval uit de database; de app is een intern ding dat na het eerste request vanuit de browsercache draait. Optimalisatie komt na realisatie.

[ Voor 4% gewijzigd door CodeCaster op 02-02-2026 12:45 ]

[Sp00n]

Nog groener dan groen. De:

Joep schreef op maandag 2 februari 2026 @ 12:44:
... beginnende leken.

[Yucon]

Lethalis schreef op maandag 2 februari 2026 @ 12:40:
[...]

Dat is dus exact wat ik bedoel met de lat minder hoog leggen

Maar goed, ik zal wel een echte dino zijn die nog geeft om de efficiency van zijn software.

En dit, beste Lethalis, is precies waarom PoC's e.d. met echte developers vaak te lang duurt en te stroef gaat

Absoluut geen waardeoordeel. Ik begrijp echt hoe je erin staat, alleen sluit dat gewoon niet aan bij een deel van de use cases. Ik sta ook vooraan om te roepen dat jouw standpunt in genoeg situaties ook echt juist wel precies het juiste is. Maar niet altijd.

Enerzijds zijn efficiency, maar ook bijvoorbeeld architectuur die overhead met zich meebrengt in sommige situaties gewoon overbodig ballast die juist contra-productief kan zijn. Even gewijzigde inzichten meenemen zorgt er dan ineens voor dat je de helft weer op de schop moet nemen. En anderzijds merk ik dat veel developers er ook gewoon slecht mee om kunnen gaan dat requirements onduidelijk zijn. Dat kunnen functionele requirements zijn, maar soms ook gewoon zelfs semi-technische omdat je bijvoorbeeld met een API moet interfacen waarvan je het gedrag vooraf slecht kunt inschatten. Trial&error is dan vaak de beste oplossing maar dat werkt in de praktjik slecht als het over twee personen verdeeld is.

Ergens hoop ik misschien ook wel een beetje dat zo'n forumdeel of topic ervoor kan zorgen om zolderkamerknutselaars van al te slechte ideeën af te brengen. Maar dat kan dan weer mijn naïviteit zijn.

[Oon]

Sp00n schreef op maandag 2 februari 2026 @ 12:36:
Misschien nog even goed voor alle reageerders die wat offtopic gaan.

Ik snap dat de dino's de lucht in kijken en zich niet realiseren dat het toch een flinke komeet is die op (jullie) ons afkomt.

Het gaat me meer om de discussie of dit een aparte plek verdient binnen GoT. Er zijn genoeg pro's en con's te bedenken voor vibe coding / programmeren met AI. En er zijn zeker grote risico's.

De vraag is of we daarmee onderdeel van het probleem of van de oplossing kunnen zijn door hier een plek te bieden waar mensen terecht kunnen voor hun vragen / verhalen / twijfels.

Aan alles dat je zegt lees ik vrij expliciet af dat kwaliteit, performance, security e.d. je geen reet boeien en je gewoon lekker snel zelf iets wil laten knutselen door je AI. Prima, maar dat heeft dan ook weer helemaal niks te zoeken in een professionele/commerciele setting.

Ik heb heel wat AI-geproduceerde code gezien en met wat expliciete prompting is het zeker nuttig, maar als ik zie hoeveel tijd ik als softwaredeveloper kwijt ben om zelfs de betere AI agents code te laten produceren die voldoet aan de eisen die ik aan een vers afgestudeerde junior zou stellen dan denk ik dat we het toch over totaal andere usecases hebben.

Waar vibe coden heel leuk voor is, is bespoke persoonlijke software; snel een tootlje maken dat jouw Instagram posts bij elkaar raapt of dat twee heel specifieke datasets met elkaar vergelijkt. Maar ik zou toch oppassen met roepen dat jij het gemaakt hebt, en al helemaal met dergelijke codebases online zetten, want dat betekent dus ook dat mensen bij jou aankloppen wanneer het mis gaat.
De meeste repo's die met vibe coden gemaakt zijn zitten zo ramvol lage kwaliteit AI slop dat ze echt geen enkele code review doorkomen, laat staan een professionele pentest.

Dit alles niet om je te ontmoedigen en ik ben ook zeker geen tegenstander van het geheel, maar ik vind Devschuur toch wel gericht op mensen die willen (leren) ontwikkelen, en vibe coden heeft daarmee net zo min een plek hier als DALL-E of Midjourney in Fotografie -> Showcases en creaties

[CodeCaster]

Lethalis schreef op maandag 2 februari 2026 @ 12:31:
[...]

Mijn probleem met AI is alleen dat ikzelf die technische eisen stel aan de software. Mijn opdrachtgever boeit het wellicht minder en daar loert het gevaar. Dat er ergens een "goed genoeg" situatie komt, waarbij mensen de lat simpelweg minder hoog leggen.

Kortom, "het doet het toch?".

Dat zou al het plezier uit software ontwikkelen voor mij halen, omdat ik juist de kwaliteitsattributen van complexe systemen interessant vind (de -ilities). Het wordt dan niet zozeer een kwestie van of ik AI zou kunnen gebruiken, maar of ik het überhaupt wil. Als wij naar een wereld gaan waarin alles AI slop wordt, dan check ik uit en ga ik maar een ander vak leren

Jouw reactie geeft meteen het probleem hier aan, wat @Yucon hierboven perfect aangeeft.

Wat als iemand een onschuldig appje wil bouwen waarmee die, ik noem maar wat, z'n boodschappenlijst kan maken zonder die data meteen bij Big Tech te stallen of op Team.Blue Hosting te moeten zetten. Zit er een SQL injection vulnerability in voor SQLite? Gefeliciteerd, heeft precies niemand last van. En is die z'n boodschappenlijst kwijt door z'n eigen foute invoer: eigen schuld, leermomentje.

Zelfde leermomentje als iemand een gevibecode POC in productie zet voor de hele wereld en die trekt een Azure-rekening naar de tienduizenden dollars, of die gaat klantgegevens in het rond spuwen. Experts blijven nodig.

Ik herken en volg je sentiment wel dat dit mogelijk een bedreiging voor het opgehemelde vak van softwareontwikkelaar is: als alle software "straks" "goed genoeg" is, dan is er mogelijk veel minder vraag naar gemiddelde developers, ja.

Ik geloof en hoop dat ik dat niveau inmiddels ontstijg, en dat ik aan het werk kan blijven als expert, als ontwerper, als finetuner. En weet je hoeveel bagger er nu in de markt wordt gezet en is gezet zonder LLM's?

Als mijn baan verwordt tot prompttyper, ga ik inderdaad wel wat anders doen. Iets met voertuigonderhoud of tuinieren lijkt me machtig mooi.

[Cartman!]

Sp00n schreef op maandag 2 februari 2026 @ 12:36:
Ik snap dat de dino's de lucht in kijken en zich niet realiseren dat het toch een flinke komeet is die op (jullie) ons afkomt.

Ik voel me aangesproken Nee, ik ben niet bang dat vibe coders mn werk overnemen. Ik maak platformen voor miljoenen gebruikers en waar miljoenen euro's doorheen gaan en dit zal echt niet snel vervangen worden door een vibe coder.

Ik maak dagelijks gebruik van Windsurf met Claude Sonnet en vind het veel toevoegen. Wat ik al zei; code schrijven is niet moeilijk, de meeste tijd zit in het goed uitdenken van features en randzaken als security en performance.

Waar ik me wel zorgen maak is dat er bepaalde tools of dingen gemaakt zullen worden door lui die het eigenlijk niet snappen waardoor mijn gegevens niet goed beveiligd worden en op straat komen te liggen. Zelfs ervaren developers zien niet alles, waarom een onervaren iemand denkt dit met een LLM wel voor te kunnen zijn is me n raadsel.

[CrankyGamerOG]

Sp00n schreef op maandag 2 februari 2026 @ 11:49:
Ik test alle apps die ik maak natuurlijk ook zelf.

Hoe doe jij als leek pentesten of je app wel veilig is dan?

[CrankyGamerOG]

Sp00n schreef op maandag 2 februari 2026 @ 12:18:
[...]


SQL vind ik niet echt programmeren. Ik kan SQL lezen en schrijven.

Lol. Deze statement zegt dan ook meteen alles.

[Lethalis]

Yucon schreef op maandag 2 februari 2026 @ 12:52:
[...]
En dit, beste Lethalis, is precies waarom PoC's e.d. met echte developers vaak te lang duurt en te stroef gaat

Als PoC's met mij te lang duren en stroef gaan, dan komt dat omdat de stakeholders vaak niet inzien dat de daadwerkelijke realisatie complexer is dan de PoC. Kortom, het wordt dan een stuk zelfbescherming.

Ik heb in het verleden weleens snel dingen in elkaar geflanst voor een proof of concept en vervolgens moet je lullen als Brugman om uit te leggen dat het nog niet af is. Mensen snappen dat gewoon niet.

Tsja, dan ga je die fout niet nog eens maken en doe je het meteen goed. Waarbij "goed" niet betekent dat je meteen aan premature optimization doet en te complexe architectuur, maar dat je het iig zo opzet in de basis dat je het niet weg hoeft te gooien zodra je er een echt product van wil maken.

[Standeman]

CodeCaster schreef op maandag 2 februari 2026 @ 12:55:
[...]

Jouw reactie geeft meteen het probleem hier aan, wat @Yucon hierboven perfect aangeeft.

Wat als iemand een onschuldig appje wil bouwen waarmee die, ik noem maar wat, z'n boodschappenlijst kan maken zonder die data meteen bij Big Tech te stallen of op Team.Blue Hosting te moeten zetten. Zit er een SQL injection vulnerability in voor SQLite? Gefeliciteerd, heeft precies niemand last van. En is die z'n boodschappenlijst kwijt door z'n eigen foute invoer: eigen schuld, leermomentje.

Zelfde leermomentje als iemand een gevibecode POC in productie zet voor de hele wereld en die trekt een Azure-rekening naar de tienduizenden dollars, of die gaat klantgegevens in het rond spuwen. Experts blijven nodig.
...

Hoe vak ik wel eens een PoC in elkaar gehacked heb en een omhooggevallen manager riep "duw maar naar productie, want het werkt toch" is niet op 1 hand te tellen.
En dan ben je meer tijd kwijt om die manager te overtuigen dat die PoC de vuilnisbak in kan dan dat je bezig bent geweest met de PoC.

Maar LLM heeft zeker z'n nut. Ik gebruik het voornamelijk als rubber duck, hoewel mijn kat daar ook geschikt voor is. En soms gebruik ik het om een klein gaatje in mijn kennis op te vullen, maar dan werkt google ook wel voor.

Om terug on-topic te gaan.. Ik denk zeker dat er een plek is voor LLM's binnen Devschuur. Vibecoden an sich niet zo heel erg.

[Joep]

Sp00n schreef op maandag 2 februari 2026 @ 12:52:
Nog groener dan groen. De:

[...]

Ik zag het pleonasme al toen ik het schreef, maar ik dacht, wat kan het kwaad

[Lethalis]

CodeCaster schreef op maandag 2 februari 2026 @ 12:55:
[...]
En weet je hoeveel bagger er nu in de markt wordt gezet en is gezet zonder LLM's?

Dat kan ik niet ontkennen inderdaad

[Sp00n]

Oon schreef op maandag 2 februari 2026 @ 12:53:
[...]

Aan alles dat je zegt lees ik vrij expliciet af dat kwaliteit, performance, security e.d. je geen reet boeien en je gewoon lekker snel zelf iets wil laten knutselen door je AI. Prima, maar dat heeft dan ook weer helemaal niks te zoeken in een professionele/commerciele setting.

Ik heb heel wat AI-geproduceerde code gezien en met wat expliciete prompting is het zeker nuttig, maar als ik zie hoeveel tijd ik als softwaredeveloper kwijt ben om zelfs de betere AI agents code te laten produceren die voldoet aan de eisen die ik aan een vers afgestudeerde junior zou stellen dan denk ik dat we het toch over totaal andere usecases hebben.

Waar vibe coden heel leuk voor is, is bespoke persoonlijke software; snel een tootlje maken dat jouw Instagram posts bij elkaar raapt of dat twee heel specifieke datasets met elkaar vergelijkt. Maar ik zou toch oppassen met roepen dat jij het gemaakt hebt, en al helemaal met dergelijke codebases online zetten, want dat betekent dus ook dat mensen bij jou aankloppen wanneer het mis gaat.
De meeste repo's die met vibe coden gemaakt zijn zitten zo ramvol lage kwaliteit AI slop dat ze echt geen enkele code review doorkomen, laat staan een professionele pentest.

Dit alles niet om je te ontmoedigen en ik ben ook zeker geen tegenstander van het geheel, maar ik vind Devschuur toch wel gericht op mensen die willen (leren) ontwikkelen, en vibe coden heeft daarmee net zo min een plek hier als DALL-E of Midjourney in Fotografie -> Showcases en creaties

Ik ben bezig met dit project: *spam* en 95% is gemaakt met AI.

Dit is misschien "een snel tooltje", maar we blijven bouwen met AI en binnenkort is dit niet meer enkel een tooltje.

Elke week melden meer dan 100 mensen zich aan en de eerste betalende klanten (7) zijn er ook al.

Ik lees uit alles wat jij schrijft dat je nog niet in 2026 leeft

[ Voor 0% gewijzigd door MueR op 02-02-2026 23:59 ]

[Lethalis]

Maar om even ontopic te gaan over de vraag of vibe coding / LLM gebruik een plek heeft binnen de Devschuur... ik vraag mij serieus af waarom het een aparte plek nodig heeft?

Je kunt eigenlijk niet het ene hebben zonder het andere. Dus of je ziet LLM gebruik en vibe coding als onderdeel van software ontwikkeling, of niet. En als je het wel zo ziet, dan kun je ook gewoon topics in de Devschuur erover aanmaken zonder dat hiervoor een aparte plek hoeft te worden ingericht.

Het is nou ook weer niet zo alsof er zoveel gebeurt in dit subforum.

Ook al geloof ik zelf niet zo in alles met AI doen, wil ik best meelezen in die topics. Als ze maar over een concreet probleem gaan dat je probeert op te lossen. Of dat nou met of zonder AI is, is eigenlijk een detail.

Een topic over prompt engineering kan ook interessant zijn. Zoals eerder gezegd, word ik er niet vrolijk van, maar je kan er best veel mee als je het maar genoeg context voert. Zo heb ik ook weleens wat code laten genereren die data ophaalde uit een database en in een class stopte, door alleen maar het CREATE TABLE DDL statement aan een AI te geven, zodat hij iig wist wat hij moest maken.

Het is alleen dat ik 3 seconden later bedacht dat ik al 10 ORM tools heb die ditzelfde probleem voor mij oplossen, en nog beter ook, maar toch... het was even een leuke gimmick.

[Lethalis]

Sp00n schreef op maandag 2 februari 2026 @ 13:26:
[...]
Ik ben bezig met dit project ******** en 95% is gemaakt met AI.

Elke week melden meer dan 100 mensen zich aan en de eerste betalende klanten (7) zijn er ook al.

Ik lees uit alles wat jij schrijft dat je nog niet in 2026 leeft

Reclame maken voor jouw product is volgens mij niet toegestaan op Tweakers. Ook niet in 2026.

[Kheos]

Sp00n schreef op maandag 2 februari 2026 @ 13:26:
[...]
Ik ben bezig met dit project: *spam* en 95% is gemaakt met AI.
Dit is misschien "een snel tooltje", maar we blijven bouwen met AI en binnenkort is dit niet meer enkel een tooltje.
Elke week melden meer dan 100 mensen zich aan en de eerste betalende klanten (7) zijn er ook al.
Ik lees uit alles wat jij schrijft dat je nog niet in 2026 leeft

In combinatie met

Sp00n schreef op maandag 2 februari 2026 @ 11:49:
Ik test alle apps die ik maak natuurlijk ook zelf.
Dat kan nog steeds betekenen dat er ergens onder water iets niet goed gaat, maar de output is wel wat ik wil.

Security problemen merk je als je zelf codeert ook niet altijd. Maar ik moet zeggen dat ik ook nog geen (geautomatiseerde) pentesten heb geprobeerd, noch iets van security libraries toegevoegd omdat ik ervan uitga dat het voor de simpele dingen die ik maak, niet nodig is.

Ik zet de popcorn alvast klaar want dit is gewoon wachten tot dit misgaat. En ja, dat gaat mis.

Heerlijk toch dat er decennia aan best practices en ervaring opzij worden geschoven om dan te horen dat we niet in 2026 leven. Ja hoor. Op een dag ontdek je vast waar die best practices voor nodig waren.
Succes ermee!

[ Voor 1% gewijzigd door MueR op 03-02-2026 00:01 ]

[Cartman!]

Kheos schreef op maandag 2 februari 2026 @ 13:45:
Op een dag ontdek je vast waar die best practices voor nodig waren.

Betaal- en persoonsgegevens bij een platform waarbij de maker zegt dat security niet nodig is, ik deel je zorgen.

[Sp00n]

Kheos schreef op maandag 2 februari 2026 @ 13:45:
[...]

In combinatie met

[...]

Ik zet de popcorn alvast klaar want dit is gewoon wachten tot dit misgaat. En ja, dat gaat mis.

Heerlijk toch dat er decennia aan best practices en ervaring opzij worden geschoven om dan te horen dat we niet in 2026 leven. Ja hoor. Op een dag ontdek je vast waar die best practices voor nodig waren.
Succes ermee!

Thanks!

Bij elk product is het wachten tot het misgaat. Alleen als je niet wacht en door blijft ontwikkelen en updaten, is de kans groter dat er geen kwetsbaarheden uitgebuit kunnen worden.

Een wordpress instalaltie van 2024, in 2024, was toen zo veilig als maar zijn kon. Open source. Duizenden mensen die er aan werken. Maar als je je site niet update naar de nieuwste versie, krijg je kwetsbaarheden in de software die eerder nog veilig was.

Zelfde geldt voor (maatwerk|AI) software.

[Oon]

Sp00n schreef op maandag 2 februari 2026 @ 13:26:
[...]


Ik ben bezig met dit project: <reclame> en 95% is gemaakt met AI.

Dit is misschien "een snel tooltje", maar we blijven bouwen met AI en binnenkort is dit niet meer enkel een tooltje.

Elke week melden meer dan 100 mensen zich aan en de eerste betalende klanten (7) zijn er ook al.

Ik lees uit alles wat jij schrijft dat je nog niet in 2026 leeft

Pfoe, ben benieuwd wat die 7 mensen gaan doen als jouw app gehackt wordt, jij geen idee hebt hoe je het überhaupt moet dichten en geen monitoring hebt op toegang omdat je de AI daar niet voor hebt geprompt, en je pas als die klanten komen klagen aan kan geven dat je van niks weet..

Verder heb ik letterlijk aangegeven dat ik er ook mee bezig ben, alleen dan vanuit het oogpunt van een developer. Ik weet wat de normale standaarden zijn, welke eisen veilige code heeft, hoe ik zelf mijn performance op orde kan krijgen etc. Voor je eigen lokale tooltje is het allemaal prima, lekker blijven spelen, maar als je iets online gaat zetten zijn die standaarden en eisen er niet voor niks.

[Sp00n]

Cartman! schreef op maandag 2 februari 2026 @ 13:52:
[...]

Betaal- en persoonsgegevens bij een platform waarbij de maker zegt dat security niet nodig is, ik deel je zorgen.

Waar ik het eerder over had heeft niks met die project te maken. Ik heb hier niet aan gewerkt met AI. Dat doet mijn compagnon.

[Cartman!]

Sp00n schreef op maandag 2 februari 2026 @ 13:53:
Bij elk product is het wachten tot het misgaat. Alleen als je niet wacht en door blijft ontwikkelen en updaten, is de kans groter dat er geen kwetsbaarheden uitgebuit kunnen worden.

Een product lanceren is meer dan alleen code deployen net zoals programmeren meer is dan alleen code te schrijven. Ik vind dat het als software bedrijf je morele verplichting is aan je (al dan niet betalende) klanten dat je zo zorgvuldig mogelijk om gaat met hun gegevens. Dit houdt dus in om veilig te werken op je systemen, code schrijft met security best practises en je infra zo goed mogelijk beveiligt. Dat kun je dan weer valideren met automatische tools als Aikido/Snyk als mede door handmatige pentests. Kost tijd, kost geld en ga je dingen van terug krijgen maar dat hoort bij het maken van een product.

Een wordpress instalaltie van 2024, in 2024, was toen zo veilig als maar zijn kon. Open source. Duizenden mensen die er aan werken. Maar als je je site niet update naar de nieuwste versie, krijg je kwetsbaarheden in de software die eerder nog veilig was.

Zelfde geldt voor (maatwerk|AI) software.

Wordpress was in 2024 ook niet veilig en dat is een probleem op zichzelf, een whataboutism.

Sp00n schreef op maandag 2 februari 2026 @ 13:56:
[...]

Waar ik het eerder over had heeft niks met die project te maken. Ik heb hier niet aan gewerkt met AI. Dat doet mijn compagnon.

Dan hoop ik dat hij wel weet hoe hij veilige software schrijf en beheert

[ Voor 10% gewijzigd door Cartman! op 02-02-2026 14:04 ]

[Patriot]

Sp00n schreef op maandag 2 februari 2026 @ 12:36:
Misschien nog even goed voor alle reageerders die wat offtopic gaan.

Ik snap dat de dino's de lucht in kijken en zich niet realiseren dat het toch een flinke komeet is die op (jullie) ons afkomt.

En voor elke dino die zich niet heeft aangepast aan een geslaagde technologie heb je een lemming die zich achter een falende technologie van een klif heeft gestort omdat hij net zo min de toekomst kon voorspellen. Om nog maar te zwijgen over al die gevallen waar de soep niet zo heet werd gegeten en uiteindelijk bleek dat het oude en het nieuwe een plekje had.

Het gaat me meer om de discussie of dit een aparte plek verdient binnen GoT. Er zijn genoeg pro's en con's te bedenken voor vibe coding / programmeren met AI. En er zijn zeker grote risico's.

De vraag is of we daarmee onderdeel van het probleem of van de oplossing kunnen zijn door hier een plek te bieden waar mensen terecht kunnen voor hun vragen / verhalen / twijfels.

Maar het is ook niet erg om er verantwoordelijk mee om te gaan. Je vraagt specifiek naar een subforum voor vibecoding, dat betekent dus mensen die geen of nauwelijks inhoudelijke kennis hebben er wel mee aan de slag gaan. Dat betekent dat er bijv. overwegingen gemaakt moeten worden in welke mate je dat wil ondersteunen in die gevallen waar bepaalde risico's worden genomen. Dat is dus allemaal zeker niet offtopic.

[Oon]

Patriot schreef op maandag 2 februari 2026 @ 14:14:
[...]


Maar het is ook niet erg om er verantwoordelijk mee om te gaan. Je vraagt specifiek naar een subforum voor vibecoding, dat betekent dus mensen die geen of nauwelijks inhoudelijke kennis hebben er wel mee aan de slag gaan. Dat betekent dat er bijv. overwegingen gemaakt moeten worden in welke mate je dat wil ondersteunen in die gevallen waar bepaalde risico's worden genomen. Dat is dus allemaal zeker niet offtopic.

Sowieso wordt er hier op Tweakers altijd eigen inzet verwacht, die is er toch per definitie niet met vibe coden?

Ik kan me niet voorstellen dat vraagtopics met iets anders beantwoord (kunnen) gaan worden dan 'leer eerst even de basis van programmeren en probeer het dan opnieuw', want ook als je een AI al het werk laat doen lost snappen waar de AI mee bezig is de meeste problemen direct op. Spoonfeeden doen we hier niet, en als je zelf niet snapt waar je mee bezig bent en hier om hulp komt vragen is dat de enige andere mogelijke oplossing.

Óf vibe coden is daadwerkelijk de toekomst en gaat snel goed genoeg werken dat er geen los forum of topic voor nodig is, óf vibe coden heeft hier niks te zoeken, denk ik..

[Patriot]

Oon schreef op maandag 2 februari 2026 @ 14:20:
[...]

Sowieso wordt er hier op Tweakers altijd eigen inzet verwacht, die is er toch per definitie niet met vibe coden?

Ik heb ervoor gekozen om het te interpreteren als "een subforum voor prompt engineering waar je misschien wat hulp kunt krijgen van programmeurs," al was het alleen maar omdat we allemaal meer hebben aan een constructieve insteek. Maar ik kan me ook heel goed voorstellen dat er uiteindelijk voor wordt gekozen om het niet te doen.

Ik kan me niet voorstellen dat vraagtopics met iets anders beantwoord (kunnen) gaan worden dan 'leer eerst even de basis van programmeren en probeer het dan opnieuw', want ook als je een AI al het werk laat doen lost snappen waar de AI mee bezig is de meeste problemen direct op. Spoonfeeden doen we hier niet, en als je zelf niet snapt waar je mee bezig bent en hier om hulp komt vragen is dat de enige andere mogelijke oplossing.

Óf vibe coden is daadwerkelijk de toekomst en gaat snel goed genoeg werken dat er geen los forum of topic voor nodig is, óf vibe coden heeft hier niks te zoeken, denk ik..

offtopic:
"spoonfeeden", was dat een bewuste woordkeuze?

[Oon]

Patriot schreef op maandag 2 februari 2026 @ 14:30:
[...]


Ik heb ervoor gekozen om het te interpreteren als "een subforum voor prompt engineering waar je misschien wat hulp kunt krijgen van programmeurs," al was het alleen maar omdat we allemaal meer hebben aan een constructieve insteek. Maar ik kan me ook heel goed voorstellen dat er uiteindelijk voor wordt gekozen om het niet te doen.

Prima, maar dat zou dan beter passen in een heel nieuw AI forum met daar ook de video/afbeelding tools, algemeen schrijven van tekst en dingen als Claude's nieuw Cowork feature erbij. Dat heeft allemaal net zo veel met software development te maken als vibe coden

[...]

offtopic:
"spoonfeeden", was dat een bewuste woordkeuze?

Ik was de Nederlandse term 'voorkauwen' even kwijt

[Sp00n]

Cartman! schreef op maandag 2 februari 2026 @ 14:03:
[...]

Een product lanceren is meer dan alleen code deployen net zoals programmeren meer is dan alleen code te schrijven. Ik vind dat het als software bedrijf je morele verplichting is aan je (al dan niet betalende) klanten dat je zo zorgvuldig mogelijk om gaat met hun gegevens. Dit houdt dus in om veilig te werken op je systemen, code schrijft met security best practises en je infra zo goed mogelijk beveiligt. Dat kun je dan weer valideren met automatische tools als Aikido/Snyk als mede door handmatige pentests. Kost tijd, kost geld en ga je dingen van terug krijgen maar dat hoort bij het maken van een product.

Ik ben benieuwd hoe je ervoor zorgt dat alle dependencies in je project "veilig" worden verklaard. Een kluwen aan libraries die niet altijd goed worden bijgehouden. Sommige die misschien ook al tijden geen update meer hebben gehad. Je denkt dat je safe zit omdat je de laatste versie hebt, maar schijn bedriegt natuurlijk. Want hij wordt al maanden (of jaren) niet meer geüpdatete.

[Standeman]

Sp00n schreef op maandag 2 februari 2026 @ 14:43:
[...]


Ik ben benieuwd hoe je ervoor zorgt dat alle dependencies in je project "veilig" worden verklaard. Een kluwen aan libraries die niet altijd goed worden bijgehouden. Sommige die misschien ook al tijden geen update meer hebben gehad. Je denkt dat je safe zit omdat je de laatste versie hebt, maar schijn bedriegt natuurlijk. Want hij wordt al maanden (of jaren) niet meer geüpdatete.

Door artikelen te lezen, de communities in de gaten te houden, OWASP checks om te zien of er CVE's zijn en geautomatiseerde version check in je build proces, licentie controles, auditing, code reviews, NIS2 richtlijnen volgen, procedure's, SLA's, pentesting door externen, etc.

Maar het aller aller belangrijkste is door te weten wat er allemaal je project ingetrokken wordt, waarom en wat het doet.

Allemaal geen 100% garantie, maar het beperkt de risico's behoorlijk.

[ Voor 6% gewijzigd door Standeman op 02-02-2026 15:28 ]

[Cartman!]

Sp00n schreef op maandag 2 februari 2026 @ 14:43:
Ik ben benieuwd hoe je ervoor zorgt dat alle dependencies in je project "veilig" worden verklaard. Een kluwen aan libraries die niet altijd goed worden bijgehouden. Sommige die misschien ook al tijden geen update meer hebben gehad. Je denkt dat je safe zit omdat je de laatste versie hebt, maar schijn bedriegt natuurlijk. Want hij wordt al maanden (of jaren) niet meer geüpdatete.

Daar heb je tooling voor zoals Aikido/Snyk die dat netjes voor je bijhouden, alerten en evt PRs voor kunnen doen. Maar het zijn gewoon 2 verschillende dingen, dat je een dependency hebt die geen known vulnerability heeft betekent niet per definitie dat jij als developer geen vulnerability introduceert door fout gebruik van die dependency.

OT: volgens mij had ik de eigenlijke vraag van dit topic niet behandeld; nee, ik denk niet dat dit een losse plek moet zijn. Als je tijdens het vibe coden een issue hebt moet je ook gewoon debuggen en met een duidelijk probleem komen en wat je al geprobeerd hebt om het op te lossen.

[ Voor 14% gewijzigd door Cartman! op 02-02-2026 15:13 ]

[Kheos]

Sp00n schreef op maandag 2 februari 2026 @ 14:43:
[...]
Ik ben benieuwd hoe je ervoor zorgt dat alle dependencies in je project "veilig" worden verklaard. Een kluwen aan libraries die niet altijd goed worden bijgehouden. Sommige die misschien ook al tijden geen update meer hebben gehad. Je denkt dat je safe zit omdat je de laatste versie hebt, maar schijn bedriegt natuurlijk. Want hij wordt al maanden (of jaren) niet meer geüpdatete.

Door een correcte strategie uit te denken en uit te voeren in combinatie met de juiste tooling. Genoeg tools die in je ci/cd pipeline de sbom inlezen en die dan checken met known issue databases.

[Joep]

Sp00n schreef op maandag 2 februari 2026 @ 14:43:
[...]


Ik ben benieuwd hoe je ervoor zorgt dat alle dependencies in je project "veilig" worden verklaard. Een kluwen aan libraries die niet altijd goed worden bijgehouden. Sommige die misschien ook al tijden geen update meer hebben gehad. Je denkt dat je safe zit omdat je de laatste versie hebt, maar schijn bedriegt natuurlijk. Want hij wordt al maanden (of jaren) niet meer geüpdatete.

Dat is wel even van een andere orde van grootte qua risico t.o.v. 100% afgaan op het antwoord van b.v. Claude op de vraag "Is de code die je daarnet hebt gegenereerd wel veilig?"

[Lethalis]

Sp00n schreef op maandag 2 februari 2026 @ 14:43:
[...]
Ik ben benieuwd hoe je ervoor zorgt dat alle dependencies in je project "veilig" worden verklaard. Een kluwen aan libraries die niet altijd goed worden bijgehouden. Sommige die misschien ook al tijden geen update meer hebben gehad. Je denkt dat je safe zit omdat je de laatste versie hebt, maar schijn bedriegt natuurlijk. Want hij wordt al maanden (of jaren) niet meer geüpdatete.

Daar heb je doorgaans gewoon tools voor?

Voor de gemiddelde developer betekent dat gewoon even een blik op zijn package manager werpen. Of dat nou NuGet, npm, of wat dan ook is, meestal kun je eenvoudig een lijst opvragen van outdated packages inclusief veiligheidswaarschuwingen. Even vanuit de IDE bijwerken, unit en integratie tests draaien en je kan er weer even tegenaan?

Of je hebt een automated tool die regelmatig dit soort checks voor je uitvoert. Je kunt dan denken aan Jenkins, of een andere CI/CD tool. Op mijn werk gebruiken we Jenkins om bijvoorbeeld regelmatig een code scan uit te voeren. Als er iets fout gaat, dan krijgen we automatisch een mailtje daarover.

[ Voor 7% gewijzigd door Lethalis op 02-02-2026 16:18 ]

[Sissors]

Lethalis schreef op maandag 2 februari 2026 @ 12:11:
Het vervelende van AI is dat normies nu denken dat programmeren iets is dat je wel even snel kan doen. De waardering voor het vak daalt zienderogen.

Maar als niet IT'er: Datzelfde heb ik al jaren lang gezien vanuit IT'ers. IIG op specifiek code schrijven. Dat is code kloppen. Nee de architectuur, dat is het belangrijke. Maar het daadwerkelijk code schrijven? Dat kan elke aap wel.

En nu kan ik me prima voorstellen dat een goede architectuur essentieel is. Tegelijk zolang een chat app sinds een ~2020 prima een gigabyte RAM nodig heeft, een kalender widget 150MB RAM vraagt, een home assistent met 1GB RAM als toch wel erg weinig wordt gezien voor wat automatisatie, etc. Dan is mijn conclusie dat het misschien maar beter is een AI code te laten schrijven, die dan hopelijk beter geoptimaliseerd kan zijn, in een efficiëntere taal.

(Waarschijnlijk ben ik nu naiief optimistisch dat er efficientere code uit komt, gezien het ook getrained is op diezelfde belabberde code, maar de hoop is er).

[Standeman]

Sissors schreef op maandag 2 februari 2026 @ 17:28:
[...]

Maar als niet IT'er: Datzelfde heb ik al jaren lang gezien vanuit IT'ers. IIG op specifiek code schrijven. Dat is code kloppen. Nee de architectuur, dat is het belangrijke. Maar het daadwerkelijk code schrijven? Dat kan elke aap wel.

En nu kan ik me prima voorstellen dat een goede architectuur essentieel is. Tegelijk zolang een chat app sinds een ~2020 prima een gigabyte RAM nodig heeft, een kalender widget 150MB RAM vraagt, een home assistent met 1GB RAM als toch wel erg weinig wordt gezien voor wat automatisatie, etc. Dan is mijn conclusie dat het misschien maar beter is een AI code te laten schrijven, die dan hopelijk beter geoptimaliseerd kan zijn, in een efficiëntere taal.

(Waarschijnlijk ben ik nu naiief optimistisch dat er efficientere code uit komt, gezien het ook getrained is op diezelfde belabberde code, maar de hoop is er).

Alles is belangrijk. Architectuur, goede code kloppen, onderhoud, weten wat je doet, etc.

Maar efficiëntie is duur en wordt afgewogen door de prijs van hardware (met de huidige prijzen kunnen we wel wat efficiëntere code verwachten )

En trouwens.. waar je chatapp in 2010 amper plaatjes kon versturen van (gechargeerd) 320x240 in cga, moeten ze nu 8k video met HDR en 30 talen audio over de lijn kunnen pompen en direct zichtbaar zijn in de preview, het liefst 10 tegelijk.

[Eric Z]

Hardware er tegen aan gooien is goedkoper dan uren werk om te optimaliseren. Zeker met cloud is even opschalen zo gedaan. Totdat de kosten echt uit de klauwen lopen, dan komt er best wat ellende naar boven en had er toch iets eerder een en ander ge-optimaliseert moeten worden.

AI ben ik nog niet ondersteboven van, vooral nog een goede samenvatter indien je werkt met gesloten of relatief nieuwe systemen.
Linksom of rechtsom kwam ik in een soort eindeloze verwijzing tussen manier A en manier B. Waarbij beide niet volledig konden wat ik wilde bereiken. De oplossing is er niet, maar 27 variaties van A en B verder was ik er wel klaar mee.
Ok, er zijn ook zeker gevallen geweest waar het wel goed geholpen heeft. Een melding over exposen van tokens in je front-end was goede om direct op te pakken die door mensen gemist is.

Ik ben er in ieder geval nog niet van overtuigt dat het ons als developer overbodig maakt.

Voor het eerder genoemde linkje, als AI zo goed is mag het ook aan zoiets simpels als security headers van de site denken. Iedere (web)developer weet er vanaf. Maar zolang je er niet om vraagt begint AI er blijkbaar niet zelf aan. En daar raak je een kern van het probleem, het ziet er visueel goed uit. Maar is het ook solide basis en veilig? Zonder kennis van code is dat niet te beoordelen.

White-hat hacker gaat zich niet vervelen om te assisteren/melden van gaten in AI geknutselde projecten.
En black-hat gaat ook zeker nog wel wat mooie projecten om zeep helpen door gebrek aan kennis en kunde.

[Joost1981_2]

My two cents:
- Quality is value to someone that matters.
- Wie een passie heeft voor code schrijven, testen, yaml, k8s, sql, code first of database first is af. Wie businessproblemen wil/kan oplossen is in.

Als iemand een businessprobleem kan oplossen door vibecoden en dit op een sustainable manier doet, dikke prima! Hoort er zeker thuis, net zoals low code.

[MueR]

Sp00n schreef op maandag 2 februari 2026 @ 11:49:
Ik test alle apps die ik maak natuurlijk ook zelf.

Dat kan nog steeds betekenen dat er ergens onder water iets niet goed gaat, maar de output is wel wat ik wil.

Gefeliciteerd, je hebt jezelf naar het niveau gevibecode van een happy flow kunnen testen.

Sp00n schreef op maandag 2 februari 2026 @ 11:49:
Security problemen merk je als je zelf codeert ook niet altijd.

Allereerst. Programmeurs programmeren. "Coderen" is iets anders. En deze hele statement is, los van de enorme nekharen-omhoog "coderen" uitspraak die alleen leken en scriptkiddiesvibecoders gebruiken, dit is precies het probleem.

Sp00n schreef op maandag 2 februari 2026 @ 11:49:
Maar ik moet zeggen dat ik ook nog geen (geautomatiseerde) pentesten heb geprobeerd, noch iets van security libraries toegevoegd omdat ik ervan uitga dat het voor de simpele dingen die ik maak, niet nodig is.

Yeah.. ehm.. "ik heb geen idee van security en het is toch niet nodig voor mijn slop". Oke.

Sp00n schreef op maandag 2 februari 2026 @ 11:49:
De discussie is voor mij vooral bedoeld om dit topic op het focum wat meer aandacht te geven. Misschien is Devschuur niet de juiste plek, dat zou kunnen. Maar het is wel een heel interessant groeimarkt voor Tweakers denk ik.

Nee. Nee dat is het niet. Niet binnen de context van de Devschuur met het niveau wat jij impliciet voorstelt.

Sp00n schreef op maandag 2 februari 2026 @ 12:36:
Misschien nog even goed voor alle reageerders die wat offtopic gaan.

Ik snap dat de dino's de lucht in kijken en zich niet realiseren dat het toch een flinke komeet is die op (jullie) ons afkomt.

Zullen we de moderatie gewoon overlaten aan de moderators? En iedereen die niet de AI bubble omarmt op jouw manier wegzetten als dinosaurier?

[ Voor 12% gewijzigd door MueR op 03-02-2026 00:13 ]