Team achter offline meshchatnetwerk Meshcore valt uit elkaar vanwege vibecoding

Er zijn grote problemen in de organisatie achter Meshcore, een opensource chatapp die ook offline werkt. Een van de ontwikkelaars blijkt een groot deel van de dienst te hebben lopen vibecoden en is inmiddels onbereikbaar. De ontwikkelaar heeft ook zonder overleg het Meshcore-handelsmerk geregistreerd. De rest van de ontwikkelaars zijn nu een nieuwe website begonnen, maar de toekomst van de app lijkt vaag.

Wat is Meshcore?

Meshcore is een meshprotocol waarmee gebruikers via een smartphone en radio berichten over LoRa kunnen verzenden. Daarmee is het mogelijk berichten in chatvorm te versturen, ook als er geen internet is. Gebruikers hebben naast de software ook een radiomodule nodig om de dienst te gebruiken, maar die is verder gratis en opensource.

De makers van Meshcore schrijven dat in een blogpost op hun nieuwe site, Meshcore.io. Dat is een heel nieuwe site; de dienst gebruikte eerst altijd Meshcore.co.uk. Die laatste is nu nog steeds operationeel.

De ontwikkelaars liggen met elkaar overhoop, of beter gezegd, alle overgebleven ontwikkelaars liggen met een van de anderen overhoop. Andy Kirby blijkt een groot deel van de apparaatontwerpen, mobiele apps en webconfiguratietools te hebben overgenomen. Kirby blijkt, zeggen de andere ontwikkelaars, het meeste van zijn werk te vibecoden, ofwel het laten schrijven van code door AI-modellen. Dat is voor een simpele webapp misschien nog wel te overzien, maar Meshcore is een offline berichtenapp die ook nog eens versleutelde berichten bevat. Dat is nou net code waar je wat voorzichtiger wil zijn met llm's.

De overgebleven ontwikkelaars stellen ook dat Kirby het handelsmerk MeshCore Trademark heeft geregistreerd, zonder dat met de rest te overleggen. Ze krijgen inmiddels ook geen contact meer met Kirby.

Dat leidt ertoe dat er op dit moment veel onduidelijkheid is over de huidige en toekomstige staat van Meshcore. De makers verwijzen naar de officiële GitHub-repo. Daar staat 'de bron van waarheid over wat Meshcore is', zeggen de makers. Zij gaan ook verder op meshcore.io, maar de bestaande Discord die de devs eerder gebruikten, is nog in handen van Kirby.

Reacties (98)

[Confi]

Kleine nuancering op het artikel: Kirby heeft vooral zijn eigen app MeshOS zitten vibe-coden — zijn invloed op de officiële MeshCore firmware en app was beperkt. Zijn rol was eerder die van early adopter en promoter, met het .dev- en .co.uk-domein in handen. Dat gaf hem een centrale positie die hij uiteindelijk heeft misbruikt.

De andere devs roken al onraad toen Kirby MeshOS begon te pushen zonder duidelijk te maken dat dit geen officiële MeshCore-software was. Dat gebrek aan transparantie was het eerste teken aan de wand.

Vibe-coden op zich is geen misdaad, en third-party tools rondom een open protocol zijn juist welkom. Maar het ongezien claimen van het trademark, het kapen van domeinen en het vasthouden van de Discord zonder enig teamoverleg — dát is wat hier echt fout zit. Dat is geen slordigheid meer, dat is bewust toe-eigenen.

De toekomst van MeshCore onzeker noemen gaat dan ook te ver. De core-devs zitten gewoon aan het stuur, ze hebben meshcore.io opgezet en de GitHub-repo staat als een huis. Ze hebben te veel vertrouwen gesteld in iemand die dat vertrouwen heeft beschaamd — les geleerd. Zie meshcore.io als de enige bron van waarheid, en MeshOS/meshcore.co.uk voor wat het is: een community-fork die gewoon eerlijk zou moeten communiceren over wat het is.

[GS3315]

Kirby heeft zowel de domeinen en Discord server geregistreerd.

"wie het eerst komt wie het eerst maalt".

En wie er als eerste bij is, en daarmee de eigenaar is van de boel bepaald ook wat ermee gebeurt.

Of het netjes is, is een betere vraag maar dat maakt iemand nog geen dief, kaper, gijzelaar etc.

[Reactie gewijzigd door GS3315 op 25 april 2026 02:41]

[kodak]

Het is niet zomaar toegestaan om zelf recht te claimen uit een gezamenlijk project. Het feit dat iemand achteraf individueel een registratie of beweringen kan doen maakt deze nog niet zomaar legaal.

[GUVWAF]

Maar het ongezien claimen van het trademark, het kapen van domeinen en het vasthouden van de Discord zonder enig teamoverleg — dát is wat hier echt fout zit. Dat is geen slordigheid meer, dat is bewust toe-eigenen.

Claimen van het trademark zonder teamoverleg is inderdaad echt fout. Echter, Andy was wel degene die als eerste de website, Discord en YouTube channel met de naam MeshCore bezat. MeshCore.io is pas net nieuw, ik weet dus niet of ze echt poten hebben om op te staan. MeshOS is geen community-fork, het is een interface rondom de main "core", exact wat de bedoeling was van een open core met MIT licentie.

Maar ook wel goed om de geschiedenis achter MeshCore te weten. De main developer heeft eerst geprobeerd om een "Meshtastic compatible" firmware voor de T-Deck te maken en te verkopen. Aangezien Meshtastic een trademark heeft en een GPL licentie gebruikt voor alle software en zelfs het pakketformaat, mag dit niet. Na wat geruzie (https://buymeacoffee.com/ripplebiz/meshtastic-a-dead-end) heeft hij er uiteindelijk voor gekozen om samen met Andy een nieuw open-source protocol te ontwikkelen (door heel goed af te kijken en te leren van de fouten van Meshtastic).

[Dannydekr]

• Dat is voor een simpele web-app misschien nog wel te overzien, maar Meshcore is een offline berichten-app die ook nog eens versleutelde berichten bevat. Dat is nou net code waar je wat voorzichtiger wil zijn met llm's.

Dit slaat eigenlijk nergens op. 'Vibecoding' is vooral het produceren van code door mensen die doorgaans geen enkel verstand hebben van de basis concepten, de architectuur etc. Althans, dat is wat de term werd toen veel van dit soort mensen code gingen produceren.

Als je als senior-developer een LLM als Opus 4.7 of GPT5.5 binnen een framework als Claude Code en Codex instrueert om bepaalde zaken voor je te fixen, door dit tot in detail te omschrijven met je eigen kennis als fundering, kun je beter spreken van AI Engineering. Hij zou wel gek zijn om dit niet te doen. Je bent hierdoor misschien wel 10x productiever, creatiever maar vooral ook capabeler. Fouten die je zelf maakt, dingen die je over het hoofd zou zien, vangt zo'n framework vaak juist wel af inmiddels.

Als je zelf je checks doet, je testen goed op orde hebt is er echt niks mis met deze manier van developen. Sterker nog, ik denk dat je echt niet meer mee kunt komen als je niet op deze manier AI benut of capabel genoeg bent om AI op deze manier te benutten. Als je nu de vlieguren niet maakt ben je straks echt nergens meer.

[Henk1827]

Je bent hierdoor misschien wel 10x productiever, creatiever maar vooral ook capabeler.

Als senior engineer I call BS. Ja je kan inderdaad code 10x sneller laten genereren. Dat betekent niet dat je 10x sneller bent. Bij hele simpele 13-in-een-dozijn code ben je sneller. Niet 10x maar in gunstige gevallen 2-3x. Echter in de meeste gevallen is je code niet 13-in-een-dozijn, en ben je amper sneller. Netto haal je niet veel snelheidswinst zonder in te leveren op de kwaliteit.

[Exodai]

Dat ligt er dus net aan wat jij verwacht van een AI. Even een promptje schrijven met "Bouw een chatapp" zal idd geen kwaliteit zijn. Net zoals ik jouw vraag een chatapp te schrijven zonder enige context, dan komt er ook geen zinnig project uit. Maar als je regels stelt kom je veel verder.

Ik heb voor bij ons een AI pipeline web app geschreven (hoop het ook ooit publiekelijk te lanceren) die zich moet houden aan een gespecificeerde pipeline:

- Agent 1 : Analyze van het prompt
- Agent 2: Interpretatie van het prompt delen met de ontwikkelaar
- Ontwikkelaar approves or declines
- Agent 3: Brainstorm en noteer alle benodigdheden
- Agent 4: Schrijf een A tot Z ontwikkel plan
- Agent 5: Verifieer ontwikkelplan
- Agent 6: Na verificatie verdeel het plan in fases van ontwikkeling in een Trello of Jira manier
- Agent 7: Check DB voor ontwikkel regels zoals Design pattern, code examples van hoe de structuur eruit moet zien (camelCase, extensions, actors voor networking, Requestbuilder voor dynamic endpoints, welke ontwikkelaars code of regels de agent moet volgen.)
- Agent 8: wordt dan aan het werk gezet en werkt dan de fases af en schrijft na elke fase de documentatie van de fase.
- Agent 9: gaat dan nogmaals over alle code om te verifiëren. Dit is dan Claude, Gemini en of Grok.
- Agent 10 deployed het met Podman en een beta PSQL server en we testen.

En tijdens alfa deployment krijgen wij Lead developers het project te zien en laten de LLMs ons zien waar ze vraagtekens bij hebben en wordt ons om input gevraagd wanneer ze er niet uitkomen. (Vooral Grok brutally honest modus is hier heel geschikt voor)

Met dit soort regels krijg je echt goed gestructureerde en relatief goed geschreven software. Je moet AI alleen niet als een wondermiddel behandelen. Bij mij behandelen we AI als Jr developers en naar mijn mening is het echt niet zo slecht als veel mensen beweren.

De pipeline app volgt nu iets van 500 specifieke code examples van mij en rond de 300 project regels die het moet volgen en in 90 procent van de tijd lijkt het net alsof ik het geschreven heb. Het maakt mits goed opgezet developers echt wel productiever.

[Reactie gewijzigd door Exodai op 25 april 2026 02:03]

[berchtold]

Wrm zoveel agents als je ook claude code dat in een plan kan laten opstellen en een takenlijstje kan laten afwerken.

[Exodai]

O heel simpel. Ik heb dit 3 maanden lang getest in verschillende fases en dit was de beste en meest accurate manier van werken. Agents van Claude en Codex en zelfs cursor volgen niet altijd hun eigen ontwikkel plan of regels. Wij hebben na bijna 70 geteste projecten besloten dat deze 9-11 agents de beste manier waren om LLMs te laten programmeren zoals wij programmeren.

[Xanthine]

Dit is ook de manier van werken die ze bij mijn werkgever pushen. Je gaat meer een teamlead functie krijgen waarbij je agents gaat aansturen. Dat is de toekomst.

[Moortn]

Het zal heel erg afhankelijk zijn van het project waar je aan werkt. Als je een nieuwe project begint en direct AI meeneemt, kan het erg veel tijd besparen en gaat het niet ten koste van de kwaliteit (in tegendeel).

Voorbeeld: ik ben bezig met een hobby project (C# API, aspire, Postgres db, cqrs). Het project heb ik zelf opgezet met een simpele eerste flow. Copilot heb ik daarna een copilot-instructions laten genereren, zodat hij deze structuur en conventies zou aanhouden. Vervolgens voeg ik tests, endpoints, handlers, entities en repositories toe met AI. Als dat niet op de manier gaat zoals ik wil, corrigeer ik dat. Vervolgens worden de instructions weer ge-update (of uitgebreid).

Het resultaat is daardoor dat AI “weet” wat ik wil en binnen welke kaders het moet werken. Ik hoef het steeds minder te corrigeren en de kwaliteit is echt wel goed.

Als senior engineer hou ik me liever bezig met architectuur keuzes dan het mappen van models of schrijven van tests of documentatie.

Ik durf wel te stellen dat het nu zeker 3x zo snel gaat. Bij legacy projecten zal het een ander verhaal zijn, dan moet je AI waarschijnlijk veel meer controleren en corrigeren.

[Henk1827]

Als je een nieuwe project begint en direct AI meeneemt, kan het erg veel tijd besparen en gaat het niet ten koste van de kwaliteit

Volgens mij is het juist andersom. Een LLM kan goed de patronen volgen van een bestaande codebase. Dus als je al iets gestructureerds hebt staan kan het daarvan afkijken. Als je weinig kennis van programmeren hebt lijkt het inderdaad of het heel snel een bootstrap kan maken. Maar mijn ervaring is dat het daar niet goed in is, omdat het voorbeelden en sturing mist.

[blackSP]

Daar ben ik het dus weer mee oneens. Als je de programmeertaal goed beheerst, goed in staat bent om een applicatie of systeem te ontwerpen en er heel strak bovenop zit kun je wel degelijk enorm vaart maken. Uiteraard is er, qua model, geen one size fits all oplossing dus kun je er niet willekeurig een uitkiezen en er vanuit gaan dat het verder wel goedkomt. Ik gebruik inmiddels een mix van modellen, lokaal en cloud based en ik kan niet meer terug. Technische wel maar niet qua productiviteit.

edit: fixed typo "en" ipv "een"

[Reactie gewijzigd door blackSP op 25 april 2026 11:38]

[disguisedpotato]

Wat voor mij goed werkt is om zelf het ontwerp te maken van de code, en het zelf te splitsen in functies. De LLM genereert dan de eerste versie van zo'n functie. Dit levert met enkele uitzonderingen code op van hoge kwaliteit. Die lees ik regel voor regel door en pas ik dan aan. Bijna altijd is de code gewoon correct, maar vaak pas ik het aan om het meer in mijn eigen stijl te maken. Dan is een functie die 10 minuten zou kosten om te schrijven in 3 minuten geschreven. Op een heel project scheelt het gigantisch veel tijd. Dit is dus geen vibe coden want je zorgt ervoor dat je exact weet wat elke regel code doet. Ik denk dat dit de toekomst is en velen met mij.

[Q.K. Pinees]

Ben ik het niet helemaal mee eens, AI- mits goed gebruikt, kan echt super veel tijd en ellende schelen. Zolang je zelf de opzet en de code snapt, is AI echt een goed stuk gereedschap.

[Squixx]

De meeste code is sowieso 13 in een dozijn.. t ligt er puur aan hoe klein je het probleem slaat.

Alles is _uiteindelijk_ een if statement... Als je als engineer je je specs schrijft tot het punt functie x moet y doen is het zeker wel 13 in een dozijn naast de specs.

[Tassadar32]

En bij veel klanten zie ik microservices op Spring. Daar is het niet meer dan de juiste stukjes aan elkaar lijmen en testen. Vaak ben je veel tijd kwijt aan het debuggen van configuratie die moeilijk in testen te vangen is, perfect om daar een AI op te zetten en ondertussen lekker wat anders te doen. Ook vaak zat werk wat iets is als "Maak een kopie van module A, noem die B en pas hem op 2 punten aan zo en zo". Perfect werk om een AI voor in te zetten.

[cascer1]

Die 10x productiever claim wil ik graag een bron van zien

[CopyCatz]

n=1: ik ben niet opgeleid als programmeur. Ik zit in een ander vakgebied waarin development mijn bijvak is, en ik dat werk helaas wel zelf moet doen. Ik kan goed verzinnen en uitwerken wat er nodig is, maar moet het vervolgens ook zelf bouwen en dat kost me tijd (en steeds meer stress). Heb onlangs een project waarvoor ik 6 maanden had uitgetrokken in 1,5 week afgerond. Gebouwd door Claude Code, ik kan de code volgen (en leer er ook nog een hoop van).

Ik word een beetje zat van de vibe code vibe hier. Het zijn voornamelijk developers die tot nu toe met een dik salaris bij een software toko zaten die dit soort comments maar blijven posten in de hoop dat het weer over waait. Dat gaat niet meer gebeuren. Voor mij is AI development een godsgeschenk. Ik heb nog nooit zoveel rust in mijn hoofd gehad.

[Reactie gewijzigd door CopyCatz op 24 april 2026 22:25]

[GoldenSample]

Of een tool nuttig is (of kan zijn) betekend niet magisch dat het niet misbruikt wordt. Met CAD is het ook al decennia een stuk makkelijker een (3D) ontwerp te maken, dat maakt nog niet plots iedereen die met een CAD overweg kan een werktuigbouwkundig ingenieur. Zoeken op ziekte symptomen maakt jou en mij niet plots huisarts en Claude maakt mij geen developer. Maakt dat thuisarts.nl of Claude nutteloos? Zeker niet.

Het probleem is niet zo zeer de tool zelf (Hoewel LLM AI opzichzelf enorme problemen h/geeft). Het probleem is het te breed gebruiken, aan het resultaat veel te hoge verwachtingen hangen en dat zonder de juiste kennis (toe te passen).

[chrome moral]

“Met CAD is het ook al decennia een stuk makkelijker een (3D) ontwerp te maken, dat maakt nog niet plots iedereen die met een CAD overweg kan een werktuigbouwkundig ingenieur. Zoeken op ziekte symptomen maakt jou en mij niet plots huisarts en Claude maakt mij geen developer. Maakt dat thuisarts.nl of Claude nutteloos? Zeker niet.”

Ik denk dat een beter voorbeeld is: door de komst van de foto camera zijn portretschilders niet compleet verdwenen, maar iemand die een portret wilt hebben hoeft nooit meer een portretschilder op te zoeken

Algemene programmeurs zijn volgens mij de portretschilders wat AI betreft.

[Sjaimon]

Ik snap je helemaal. Ik ben ook niet opgeleid als programmeur maar vind het leuk om te doen en kan het goed toepassen in het werkveld. Ik heb het programmeren geleerd voordat AI uitkwam. De stappen die je moet zetten begrijp ik goed. Ik kan de code nu met AI sneller kloppen, en ben daarmee efficiënter. Daarnaast leer ik nog veel bij door met AI in gesprek te zijn en projecten te ontwikkelen. N=2

[ocn]

Dit

AI gebruik is prima voor niet mission-critical applicaties.

[J_van_Ekris]

Ik word een beetje zat van de vibe code vibe hier. Het zijn voornamelijk developers die tot nu toe met een dik salaris bij een software toko zaten die dit soort comments maar blijven posten in de hoop dat het weer over waait.

Niets persoonlijks, maar dit soort opmerkingen heb ik echt moeite mee. In mijn beeld zijn het mensen die zich oprecht zorgen maken over de belabberde kwaliteit van spullen die ontstaat als je beginners zonder opleiding code laat creeren? Zeker omdat ze denken van de AI iets te leren. Maar leren ze dan ook de juiste zaken, of leren ze alleen maar slechte gewoontes? Want in de afgelopen 30 jaar heb ik als informaticus één ding geleerd: als de beginners het verkloten moeten de professionals de bende weer komen opruimen.

Ik heb 15 jaar serieus grote organisaties geholpen systemen technisch weer op de rit te krijgen. Ik heb de ellende gezien die ontstaat als je 100 geschiedenis-studenten met een maand opleiding Java bij een klant neerzet. Of dat je mensen zonder opleiding of ervaring met Low code complexe dingen laat bouwen. Nadenken over architectuur: niet gedaan. Code bevat een NP probleem: wat is dat? Defensive programming: waarom? Inputvalidatie: is alleen maar overhead. En documentatie is niet boeiend.

Ik maak me geen zorgen over werkgelegenheid. Ik weet intussen uit ervaring dat ik het komende decennium weer werk heb, en me er serieus voor laat betalen omdat ik weer andermans shit mag gaan opruimen.

[xFeverr]

Die laatste alinea is belangrijk. Ik heb er geen zin in dat dat mijn werk zou gaan worden. Als je toko leeg loopt en niemand wil je troep komen fixen, gaat de prijs flink oplopen.

[maartenyh]

Bij mij op kantoor wordt veel te veel ge-vibecode. Ik zit erdoor in de burnout omdat ik elke keer de problemen mag oplossen die mijn collegas in de code proppen en het dan niet kunnen oplossen wegens de circlejerk waar een LLM ze doorheen begeleid

Ja, ik zoek ander werk. Maar eerst herstellen van mijn burnout.

Programeren/sparren met een LLM is prima. Het alles voor je te laten schrijven en/of het volledig je architectuuur laten uiteenzetten is langzaam je eigen graf graven zonder dat je het zelf door hebt.

Wat mij wel opvalt is dat een LLM bepaalde software VEEL beter schrijft dan andere software. Helaas is mijn specifieke tak hetgeen wat het heel slecht schrijft.

[Sandor_Clegane]

Username post combo.

Mooi man, meer doen.

One of the promises of AI is that it can reduce workloads so employees can focus more on higher-value and more engaging tasks. But according to new research, AI tools don’t reduce work, they consistently intensify it: In the study, employees worked at a faster pace, took on a broader scope of tasks, and extended work into more hours of the day, often without being asked to do so. That may sound like a win, but it’s not quite so simple. These changes can be unsustainable, leading to workload creep, cognitive fatigue, burnout, and weakened decision-making. The productivity surge enjoyed at the beginning can give way to lower quality work, turnover, and other problems. To correct for this, companies need to adopt an “AI practice,” or a set of norms and standards around AI use that can include intentional pauses, sequencing work, and adding more human grounding.

https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies-it

Pas maar op.

[kitkat007]

Je reactie riekt wel een beetje naar afgunst maar goed. Vibecoders zijn oké. Scriptkiddies bestonden altijd en niemand erkent de waarde ervan.

Alleen zal niemand jou aannemen om de backend van bijvoorbeeld een financieel department op zich te nemen. Als het fout gaat wat ga je doen ? Wijzen naar Claude zei het zit wel goed ?

[Djerro123]

Maar het is helemaal niet erg dat het voor jou goed werkt. Maar zoals je al zegt; je bent geen professional.

Ik ben geen professional fotograaf, ik vind de foto’s die ik kan maken met mijn iPhone helemaal prima. Een professional zal er geen bruiloftfotos mee maken. Dat zijn twee totaal verschillende werelden die heel goed naast elkaar leven.

Waar ik dus echt moe van wordt is het fenomeen dat iedere non-developer nu ineens denkt dat hij een developer kan zijn. Het gaat echter om meer dan het produceren van code. Het werkend krijgen van een stukje software is de eerste stap op een kwaliteitsladder. Als het niet eens werkt, dan is het echt waardeloos. Maar in een professionele setting is die eerste stap niet het eindpunt. Veel software hoeft niet meer te zijn dan “te werken”, en dat is echt helemaal prima! Maar in een bedrijf setting? Daar komen meer dingen om de hoek kijken.

[Joncik91]

Genoeg apps die programmeurs gebruiken om zaken te fixen die gewoon "met vibecoding" worden onderhouden deze tijd. vooral de Claude codes van deze tijd. Vraag maar aan Boris Cherney

[jpsch]

Ja, ben benieuwd. Ander onderzoek zegt 20% minder efficiënt.

https://blog.vibecoder.me/what-metr-study-found-about-ai-coding-productivity

[Firestorm666]

Het hangt er ook puur af hoe je AI (of willekeurig andere tool) gebruikt en wat je doel is.

In mijn geval gebruik ik het voor powershell scripts te laten schrijven. AI maakt mij perfect werkende soms best complexe scripts op korte tijd. Daar waar als ik het zelf zou moeten maken veeeeeeeeel meer tijd in moet steken. Deels ook omdat ik geen Powershell guru ben.

In die context ben ik veel efficienter met AI dan zonder.

Als ik aan ChatGPT zou vragen om mij een CRM programma te schrijven, dan zal ik hoogstwaarschijnlijk meer tijd spenderen aan trial & error, ChatGPT correcties laten uitvoeren en ooit zal er wel iets van komen na verloop van heel veel tijd.

Mocht ik een developer zijn en dus "weten" hoe ik moet programeren, dan kan ik een deel zelf schrijven en een deel door AI te laten doen. Omdat ik weet hoe de vork aan de steel zit, kan ik ook aan AI specifieke vragen stellen waar vast wel iets werkend uit komt. In die context ben ik wel efficienter.

Trouwens,
Dit is niet anders dan zoals bij ouderwets "googlen". Als je geen flauw idee hebt van scripts maken kan je nog lang googlen en misschien komt er iets uit. Heb je wel een idee hoe je scripts moet maken, zal je heel wat makkelijker via zoekmachines een oplossing vinden voor je probleem.

Ik zie eerder een ander "probleem" en dat is voldoening halen.
In de tijd dat ik volledig m'n eigen scripts maakte haalde ik daar wel een voldoening uit als het eindelijk werkte.

Dit is niet het geval met m'n scripts gemaakt door AI.

[jpsch]

Uit dat onderzoek bleek dat de deelnemers dachten 20% efficienter te zijn, terwijl ze 19% minder efficient waren. Gevoel strookt schijnbaar niet met de meting.

[Firestorm666]

You might think this means AI tools are only useful for beginners. But actually, the study specifically tested experienced developers on codebases they knew well. The 19% slowdown applied precisely to the scenario where you would expect AI to help most: skilled people doing familiar work. The finding is not that AI never helps. It is that the help is not automatic, and the situations where AI adds genuine speed are more specific than the marketing suggests.

Zoals ik al zei. Het hangt sterk af van hoe je AI gebruikt en in welke context. Dat is wat ik ook vermeld in m'n comment, er zijn gerust voorbeelden dat je met AI je wel degelijk sneller bent.

De onderzoekers hebben met dat onderzoek vooral willen bewijzen dat de (marketing) claims van AI = hogere produciviteit heel wat meer genuanceerd is en je zulke claims met een korrel (soms een hele zak) zout moet nemen.

[overhyped]

Je moet je niet zo vast pinnen op een nummer. 10x klinkt leuk, net als de mythische 10x engineer. Feit is dat serieuze dev teams grote performance wist halen bij het juist inzetten van AI. Ik werk zelf als product manager bij een groot wereldwijd it bedrijf, categorie die kent iedereen wel. Als ik zie wat de feature velocity, zonder kwaliteitsverlies, is van ai native teams VS teams die nog nog vroeger in de journey zitten is dat extreem. Ook als product manager helpt het enorm, door ai kan ik betere prd’s schrijven, meer klant feedback verwerken, sneller met design overleggen, en soms zelfs een prototype maken om een concept door te geven aan engineering. 10x? Mischien nog niet, maar die kant gaan we wel op.

[Firestorm666]

AI is in de 1ste plaats een geweldig hulpmiddel. Echt vervangen kan het (nog?) niet.

Jammer genoeg heb je een redelijke groep mensen die spontaan een orgasme krijgen bij de term "AI" en vervolgens AI gebruiken als vervanging waardoor shit ontstaat en kennis verdwijnt / verroest.

[Macshack]

Beetje een vreemde titel. Niks komt DOOR vibe coding. Het ligt aan de afspraken en cultuur die men wel of niet heeft weten te bewaken en/of formuleren. Er is niks inherent slecht aan vibe coding. Het is wat je er mee doet, en hoe je het wilt inzetten. Waren er geen afspraken, Pull Requests, code reviews, architectuur, design en andere standaarden?

Het klakkeloos overnemen van AI geschreven code is in veel gevallen fout. Maar ook niet in alle gevallen. Dus het lijkt erop dat Andy Kirby misschien onjuist, zelfzuchting en onbedachtzaam heeft gehandeld. Maar de andere hebben ook zitten slapen.

[Bazi]

Vibe coding is dat je zelf niet meer naar de code kijkt. Je neemt klakkeloos over wat AI aangeeft. Dat is hoe Andrej Karpathy de term heeft geïntroduceerd.

Dan heb je dus per definitie geen pull requests, code reviews, architectuur etc. Dat gaat dus een heel stuk verder dan AI als een tool gebruiken waarbij je zelf de kwaliteit bewaakt.

Bron: https://x.com/karpathy/status/1886192184808149383

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. (...)

I "Accept All" always, I don't read the diffs anymore. (...)

The code grows beyond my usual comprehension, (...)

I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.

[Reactie gewijzigd door Bazi op 24 april 2026 21:53]

[Kerfuffle]

Dank. Ik zie de laatste tijd vaker discussies waar fans van AI-assisted coding het willen verdedigen tegen kritiek van AI-hardliners en waar beide kampen voorbijgaan aan de definitie van vibecoding.

Bij vibecoding is de enige check & balance je functionerende product, en soms zelfs alleen de PoC / MVP. Je kijkt niet naar de code, je kent de code niet, je hebt geen zicht op de technical debt, je hebt niet eens de intentie die ooit handmatig op te lossen. Er zijn echt mensen die nu aan het coden zijn die absoluut geen ambitie hebben om die code beter te begrijpen en geen idee hebben waar ze andere developers - en de klant - mee opzadelen. Mensen die AI-assisted coding toepassen en dus gewoon wel de code reviewen en de kwaliteit van de opgeleverde code snappen, zijn in mijn ervaring soms iets te naïef - zoals de waard is, vertrouwt hij zijn gasten - of voelen zich op één hoop gegooid met vibecoders waardoor ze het bredere concept van AI-assisted coding moeten verdedigen.

Ik hou de definitie daarom graag zuiver. Bij AI-assisted coding heb je alle good practices van het software vakmanschap plus een handige tool die je helpt om verantwoord onderhoudbare producten te bouwen. Bij vibecoding heb je fire&forget codeproductie die je wellicht snel op gang helpt om functionele feedback te kunnen krijgen op een idee, maar die je technisch niet kunt vertrouwen, waar je niet op door moet willen itereren en die je zo snel mogelijk weg moet gooien. Iemand die iets vibecodet en niet de beperkingen snapt, of die verhult dat dat is hoe het product tot stand is gekomen voor easy money, wil je gewoon niet aan je product hebben werken.

[david-v]

Een paar kanttekeningen op je verhaal.

Je kijkt niet naar de code, je kent de code niet, je hebt geen zicht op de technical debt, je hebt niet eens de intentie die ooit handmatig op te lossen

Ik weet niet wat voor ontwikkel proces je gewend bent, maar onze pipelines bevatten quality gates waarmee technical debt deels mee wordt voorkomen. Bovendien heb je ook een review process waarbij andere ontwikkelaars (en tegenwoordig ook AI review erbij) naar je code kijken.

Elke review/PR hoort kort en bondig te zijn. Dus het liefst niet tientallen bestanden in één keer. Je houdt je ook aan de coding standards en elke functie is niet langer dan 15 of minder regels code.

Bij code generatie vanuit AI kan je al deze aanbevelingen opnemen. De AI zal ook rekening houden met je coding standards.

Een van mijn favoriete acties bij het schrijven van een functie is dan ook vragen aan de AI of de code beter leesbaar en onderhoudbaar gemaakt kan worden. Soms komen daar constructies uit die inderdaad beter te lezen zijn, ipv mijn gedachten kronkels die ik wil eens in een functie wegschrijf.

Soms, dan is een functie zo triviaal in wat het moet doen, dat ik de code voor lief neem, net zoals je soms een stukje code uit stackoverflow overnam zonder dat je de gebruikte regexp volledig begreep. Met unittests dek je de functionele werking.

Is dat iets wat heel erg is? Ik twijfel, omdat ik op een duur wel voorzie dat er een hogere programmeertaal komt gebaseerd op prompts. Dat is weer een stap verder dan code die door een compiler wordt omgezet naar IL en/of instructiesets/assembler, maar ik hou de mogelijkheid open dat het wel die kant op zou kunnen gaan.

[uiltje]

Nou ja, ik merk dat een AI zich ook heel vaak niet aan de style guides houdt. Dat kan komen omdat de AI niet goed geconfigureerd is of omdat hij na een tijdje gewoon gaat afwijken. Natuurlijk valt dat ook weer te fixen, maar dan moet het je wel opvallen. Uiteindelijk wil een AI natuurlijk vooral doen wat anderen ook al gedaan hebben, en dat wil nog wel eens afwijken. Sommige LLM's zijn ook erg lastig weer terug op de rails te krijgen als ze eenmaal ontspoort zijn.

[david-v]

Dat valt heel erg mee als je de juiste instructies meegeeft. Je kan zelfs aan de hand van een applicatie coding guidelines laten opstellen door copilot en vervolgens dezelfde code laten analyseren met de opgestelde guidelines. Je krijgt dan de plekken in de code te zien die afwijken van de rest. Dat werkt best goed moet ik zeggen. Als je maar weet hoe je de AI moet aansturen, dan krijg je echt hele goeie resultaten.

Is je prompt en de instructies aan de AI niet concreet dan krijg je een slechte resultaat. Hoe meer je ermee bezig bent hoe handiger je erin wordt. Je hebt wel een leercurve, dat moet je echt niet onderschatten.

[Reactie gewijzigd door david-v op 25 april 2026 21:35]

[uiltje]

Ik ben iemand die echt de voordelen van AI wel ziet. Maar net als generics / templates en helemaal met lambda's hangt het inderdaad af van de programmeur. Mijn grootste probleem is als iemand gaat zitten vibe-coden zonder echt door te hebben hoe je de AI aan moet sturen. Net als met die andere functionaliteiten krijg je dan al snel een zootje.

Het principe is gelijk: als je niet weet wat je doet wordt het een zootje. En zoals anderen ook al zagen: de kans dat dit gebeurd is best groot, en degenen die de code moeten gaan onderhouden zijn dan het haasje. Maar goed, misschien kunnen die AI dan juist gebruiken om de code te begrijpen en documenteren

[david-v]

Maar goed, misschien kunnen die AI dan juist gebruiken om de code te begrijpen en documenteren

Dat gebruik ik best vaak als ik een functie heb door iemand anders geschreven die ik niet begrijp. Uitleg vragen aan de AI en je krijgt een goed gedetailleerde uitleg. Zeker als het functies zijn met veel if..else, for loops enz. "Kan je deze code herschrijven zodat het beter leesbaar is en splitsen in meerdere functies". Het resultaat is vrijwel altijd een stuk beter.

Maar, het is wel wat je zegt, je moet wel weten wat je aan het doen bent. Aan de andere kant, soms zie ik code voorbij komen van mensen die "iets minder affiniteit" hebben en/of geen programmeer/ict opleiding hebben gevolgd....tja. Dan heb ik toch liever de AI code

[uiltje]

Alles is beter dan code van een slechte coder. Er zijn mensen die met een week coderen een maand aan puin maken. Ik ben een keer een week bezig geweest om mijn eigen rommel van vrijdagmiddag op te ruimen. Dit na een glaasje champagne op een lege maag bij een nieuwjaarsborrel. En zo ken ik nog wel een paar CodeSod-waardige episodes.

[Kerfuffle]

Wat je zegt is dat je dus niet vibecodet.

[david-v]

Het is soms een grijs gebied. Kan je een specifieke functie of microservice(s) bouwen met vibe coding? Ik denk het wel. Je weet precies wat de functionaliteit is van de code, want dat heeft de AI nodig om de code te genereren. Je hebt unittests, al dan niet door AI geschreven, regressietests en functionele tests en allerlei andere tooling die de code kwaliteit garandeert. Bovendien heb je overal comments staan.

Hoever kan je hier in gaan? Als ik een bug moet oplossen dan is dat niet altijd code die ik ken of geschreven heb. Omdat de code goed gestructureerd en simpel te onderhouden is (daar zorgt de AI voor met je instructies) kan ik de code goed interpreteren en de bug oplossen. Of, ik laat de AI op zoek gaan naar de bug, wat met de beschrijving in de bug melding al vaak goed lukt.

Is dat allemaal beter of slechter dan AI alleen als assistent gebruiken en alle code zelf beoordelen en snappen?

Ik vergelijk het daarom ook met hogere programmeertalen, compilers, IL en assembler/instructie sets. Niemand bouwt een business applicatie met een frontend in assembler. Dat gaat allemaal met hogere programmeertalen.

is het aansturen van van een AI programmeur de volgende (abstractie) stap die ons als ontwikkelaars te wachten staat?

[Kerfuffle]

Ik heb in assembly geprogrammeerd. Programmeren in Python / Java / C++ is echt wel een ander soort abstractie dan programmeren met AI, en vibecoding heeft daar allemaal niks mee te maken. Dat je code goed kunt interpreteren en bugs oplost met/zonder AI betekent dat je niet vibecodet.

[jgoor]

Ik zie vibecoding als hulpmiddel voor een PoC. Niet eens prototype. Handig, en als het idee aanslaat dan gwn aan de bak met gezond verstand en programmeerkennis.

[Sandro!]

Hoezo zou je geen PRs en code reviews meer hebben? Als één van de ontwikkelaars in een project met AI codet, zal hij dat toch in zijn eigen branch doen die daarna weer in de main moet worden opgenomen? Op dat moment voer je een review van die code uit, en als die voldoet aan de standaarden die je als team gebruikt, accepteer je de PR en worden de wijzigingen gemerged.

Tenminste, ik ben niet anders gewend dan dat je niet je eigen PRs kunt approven, en dat je als reviewer ook niet gewoon op OK drukt.

[Bazi]

Als je echt overgaat op vibe coding, dan doe je dat niet meer, nee. Maar dat moet je dan inderdaad als team gezamenlijk besluiten.

Ik weet verder niet hoe het precies zit bij dit project. Als ik hun blog post goed begrijp, is het project eigenlijk alleen het MeshCore protocol. Daar heeft de betreffende persoon niets aan bijgedragen, zeggen ze. Hij is echter, op basis van het MeshCore principe, allerlei standalone apps gaan ontwikkelen onder de naam MeshOS. Dat heeft hij dus helemaal in z'n eentje gedaan, buiten het project om, met vibe coding.

Hij heeft dus niet zozeer het project gekaapt, alleen de website, en is eigen dingen gaan doen onder dezelfde naam.

[Reactie gewijzigd door Bazi op 25 april 2026 10:45]

[Sandro!]

Het lijkt erop alsof één persoon binnen het team heeft besloten te gaan vibecoden, niet het team als geheel. De PRs en code reviews houd je in dat geval wel. Als die code voldoet aan de standaarden van het team is het niet netjes om niet te vermelden dat je alles bij elkaar hebt geprompt, maar de kwaliteit is dan blijkbaar wel gewoon op orde. Of er wordt niet inhoudelijk naar de code gekeken, maar dat is weer een heel ander issue.

Hoe dan ook is er een vertrouwensbreuk en die is niet zomaar opgelost lijkt me.

[MrMonkE]

Hmm zit er 1 op dorp hier. Hoe ver reiken die dingen? En.. zijn er ook relays over internet?
Dus:

ikke -> node-> node-> internet naar uSA -> node -> node -> iemand

[Jorah_Newstone]

Dit gaat er juist over in het geval er geen internet is, dus geen relays over internet, maar wel via de radio. Naar de USA zal lastig gaan, dit is juist erg handig om te kunnen chatten in een gebied. Bijvoorbeeld als een land internet afsluit. In een stad zal je dan gewoon nog met elkaar kunnen chatten.

[MrMonkE]

Ja, ik snap het principe. Ik vroeg me alleen af of er 'bridges' zijn om het intercontinentaal te maken.

[brainbuddy]

Nee, dat is niet mogelijk met MeshCore (zonder scripts te maken dan, maar dat heb ik nog niet gezien). Wat wel gedaan wordt, is dat mensen hun repeater (een device dat alleen een bericht ontvangt en deze doorstuurt) koppelen met het internet, zodat je het daar kan lezen.
In de onderstaande URL kan je de berichten lezen van MeshCore: https://cornmeister.nl/#/channels/public


Meshtastic is een alternatief op MeshCore en daar kan je dit wel doen, maar omdat de bandbreedte erg beperkt is, loopt het netwerk hier snel van vol.

[Snelletomaat]

Nee, het is radio only. Het netwerk werkt omdat mensen zich inzetten om antennes op goede locaties te krijgen en ontvangst te verbeteren. Op het dak, in een mast bij de sportvereniging, boven op een flat, noem het maar. Dat is de hobby en uitdaging. Bij Meshtastic grepen velen naar MQTT over Internet als backup omdat dat standaard in de firmware aanwezig was en er een paar MQTT servers voor waren ingericht. Maar het resultaat was iedereen via MQTT communiceerde en er van het off-grid idee weinig overeind bleef. Er zal vast iemand zijn die het met MeshCore ook in elkaar kan prutsen maar dan ben je ver weg van het principe om een off-grid offline chat infra te maken, met nodes die low power op zonnepaneeltjes en accu's draaien. Dat maakt het leuk om ermee te experimenteren.

[GeroldM]

Denk eerder dat het nuttig is in rampgebieden. Want 1 enkele node op hoogte hangen, zonder dat deze veel energie vergt en reddingswerkers wel in staat stelt om relatief snel te communiceren, ik denk dat dit veel levens zou kunnen besparen.

En ja, rampgebieden zijn vaak terug te vinden in landen met regimes die zich maar al te graag van het internet afkoppelen, om wat voor reden dan ook.

[lenwar]

Daar heb je in de praktijk satelliettelefoons (voor open veld) en portofoons voor. De wat defitigere portofoonsystemen hebben ook eventueel repeaters enzovoorts. Je zou kunnen beargumenteren dat dit 'open' is, en dat iedereen er in principe op kan en gaan werken, maar als er gecoördineerde hulpverlening nodig is, zou dat denk ik geen probleem zijn.

[N8w8]

Zoals gezegd was MeshCore bedoeld om alleen over LoRa te werken.
Een vergelijkbaar project is Nomad, dat werkt over vanalles, o.a. LoRa en internet.
Geen verstand van maar lijkt me in theorie prima voor jouw scenario.
Maar in de praktijk denk ik dat MeshCore veel populairder is, dwz meer kans op radio relays in de buurt.

[teesee64]

Meshcore gaat ten onder aan zijn eigen populariteit. Ik heb een solar repeater in een mast hangen en die is gewoon constant bezig berichten door te sturen. Het is zelfs zo druk dat ik mijn eigen repeater niet kan bereiken omdat hij bezig is.

[William_H]

Daarom lees je hier in de comments ook dat er binnenkort wat gaat veranderen aan de firmware instellingen. Dus dat wordt in je maar klimmen.

[GS3315]

Of ... wat je met CB, Packet Radio, Meshtastic en DMR ziet... er blijft nog een grote groep mensen hangen op oude firmware nconfig omdat ze hun repeater niet 1.2.3. kunnen bereiken. Daardoor stort de in waardoor het helemaal onbruikbaar wordt.

[GS3315]

Meshcore gaat ten onder aan zijn eigen populariteit. Ik heb een solar repeater in een mast hangen en die is gewoon constant bezig berichten door te sturen. Het is zelfs zo druk dat ik mijn eigen repeater niet kan bereiken omdat hij bezig is.

Deze klacht komt in steeds meer gebieden voorbij, zoals een aantal radioamateurs al aanhaalde. Het gaat dezelfde kant op als 27Mc (CB), Packet Radio en DMR. Op den duur zit de boel zo vol door gebrek aan duidelijke afspraken, en zijn groepen zodanig opgesplitst dat de ether op dat stukje frequentie vervuild en onbruikbaar is voor fatsoenlijke communicatie.

[Chris.nl]

Wie zich afvraagt of Meshcore een beetje gebruikt wordt in Nederland .... Ja dus

[MMaster23]

Maar kan ik dus een bericht via andere nodes sturen naar een familielid 30km verderop?

[Chris.nl]

Ja, in principe wel. Veel nodes zullen ook solar powered (met batterijen voor de nacht) zijn dus 't is echt off-grid communicatie.

Als je dieper down the rabbithole gaat dan is 't op dit moment relatief druk op Meshcore. Er hangen veel repeaters (voordeeltje voor nieuwe gebruikers, die hoeven er wellicht geen te moeten), die wat onnodige airtime innemen. Wat dan weer te verbeteren is qua instellingen.

Vanuit de communicty wordt gepushed naar nieuwe instellingen die het bereik wat minder groot maken maar meer bandbreedte geven. Daarnaast wordt het belangrijker om scope(s) in te stellen, d.w.z. de regio's (land, provincie(s) of stad, zodat niet elk bericht onnodig door heel nederland verspreid wordt.

Wie een repeater heeft zou ik willen adviseren deze te updaten naar de laatste firmware en zich in te lezen welke instellingen vanaf 9 mei een actief deel van de gebruikers waarschijnlijk zal aannemen. Los van mijn eigen keuze of mening hierover; sommige repeaters gaan 'denyf*' doorvoeren, d.w.z. dat berichten zonder scope (bijvoorbeeld nl) niet doorgestuurd worden. Men mag dus iets bewuster omgaan met de instellingen per groep of chat, dan voorheen.

[Reactie gewijzigd door Chris.nl op 24 april 2026 21:24]

[kars noordhuis]

In principe kan je, als de omstandigheden goed zijn zelfs dat bericht linea recta sturen! Het is bij dit soort platformen zelfs een sport om zonder hops zo'n groot mogelijke afstand af te leggen binnen de limieten van de wet (zonder zendvergunning dan)

[N8w8]

idd, grootste probleem voor bereik is obstakels.
Bij langere afstanden wordt de aarde (kromming) het voornaamste obstakel.
Dan is het een kwestie van de hoogte in, om daar overheen te kunnen kijken.
Het LoRa afstand record was dacht ik iets van 400km? En dat zonder bijzondere radio's/antennes.
Maar wel tussen twee zorgvuldig gekozen hoge plekken.

[ouweklimgeit]

Zeker, hier in oost Nederland komen continue berichten uit de randstad binnen. Hele land is voor een groot deel wel aan elkaar gekoppeld, maar er staan technische wijzigingen op de planning die impact hebben op de werking. Een portable node updaten is geen probleem, maar er hangen ook solar nodes op lastig bereikbare plaatsen die een firmware update nodig hebben.

Dus voor ‘familie en vrienden’ is het nog te vroeg

[remco111]

Leuke kaart. Zie dat bij mij in de straat ook een node geregistreerd staat.

[cagXZ]

Snap ik het niet? Is vibecoding een reden om alles in elkaar te laten vallen? Er is een werkend product die voor een deel met een LLM is gemaakt, who cares?


edit kom -> llm

[Reactie gewijzigd door cagXZ op 24 april 2026 21:00]

[Jeffrey2107]

Ai code is ruk, veels te omslachtig en niet te onderhouden. Oh en onveilig.

[cagXZ]

Dit is niet waar. Het is net zo onveilig als dat de vibecoder ervaren is. Als iemand vertsand heeft van code en enkel vibecode om het codekloppen te versnellen, dan kan je vibecoded applicatie net zo veilig zijn als een volledig maatwerk applicatie

[Jeffrey2107]

Goed, die uitzondering bestaat ook inderdaad. Maar dat gebeurt zo weinig dat het voor mij niet echt de moeite waard is om rekening mee te houden.

[Webgnome]

Nee, AI Code is niet ruk. Internetridders vinden AI en alles wat daar mee samen hangt ruk. Dat je dingen in elkaar vibe-code maakt echt helemaal geen kont uit. Als het goed is zitten er in je dev straat gewoon checks en balances om dingen te regelen en te zorgen dat je code gewoon goed is. Dat kunnen tests zijn ( al dan niet geschreven door ) en door jezelf gecontroleerde code of door je mede ontwikkelaars gereviewde code. Dat laatste daar staat of valt het mee. Als jij gewoon PRs accepteert van je collega's zonder te checken dan ben je niet alleen erg te goeder trouw, ook gewoon naief en moet je inderdaad niet raar op kijken als de code vervolgens bugs bevat. Er kan altijd iets mis gaan.

Dat is overigens niet anders dan wanneer je collega de code gewoon met het handje had gebeiteld. Daar kunnen ook bugs in zitten en die zul je altijd zelf moeten uitzoeken.

AI code is echt niet altijd slecht, altijd onveilig of crappy. Om maar even een n+1 te doen. Vandaag zelfs nog op de vingers getikt door AI omdat ik een simpele check was vergeten in xml handling. Dat had theoretisch grote volgen kunnen hebben. AI wees mij er op. En na verificatie door docs en een beetje internet afstruinen kon ik concluderen dat AI het hier gewoon bij het rechte eind had.

Het probleem hier is dat waarschijnlijk de developer door de mand is gevallen en er vervolgens zijn eigen hachje mee probeert te redden / geld mee probeert te verdienen.

[xFeverr]

Mijn collega’s komen niet met hele grote PRs en gegenereerde tests die eigenlijk niet veel toevoegen (= ruis) en daar ben ik dan ook niet heel lang mee bezig om het te reviewen. Omdat het qua grootte menselijk blijft, we op elkaar ingespeeld zijn en omdat ik de desbetreffende collega vragen kan stellen. Hij heeft er namelijk over nagedacht en het zelf geproduceerd.

Er zit zoveel meer achter allemaal dan slechts wat regels code.

[Webgnome]

Ja tuurlijk zit er zoveel meer achter dan alleen maar de code. No shi.. Ik reageerde dan specifiek op ' AI CODE is ruk ' mantra. Dat klopt gewoon niet en is aan zoveel dingen onderhevig.

Als jij een PR te verduren krijgt van niet behapbare brokken dan kun moet je daar je collega op aanspreken en dan moet hij/zij het maar in stukjes hakken. Dat is niet anders dan dat een stagiair dat zelfde doet omdat hij/zij de scope niet goed bewaakte.

Zoals ik al zei, als je code accepteert van je collega zonder enige checks/balances dan is dat verkeerd. Als ik een stuk code krijg van een collega en ik zie dat daar door AI heel veel comments in verwerkt zijn, rare constructies die ook gewoon met 1 regel afgedaan hadden kunnen worden dan spreek ik mijn collega daar op aan. Dat is onderdeel van het review proces.

Ook als ik de code dingen zie doen waarvan ik zeker weet dat mijn collega dat normaal nooit zelf zou hebben bedacht dan ga ik daar achteraan en komen we er uit. Het kan er uit worden gehaald, herschreven of we laten het gewoon staan omdat de collega het begrijpt , ik het begrijp en het werkt.

Zoals gezegd. Alles staat of valt met checks/balances. Gebruik AI als een tool zoals je ook andere dingen tijdens je werk als tool zou gebruiken. Dat ontslaat je nog steeds niet van je verantwoordelijkheid die gepaard gaat met je salaris.

[wildhagen]

Snap ik het niet? Is vibecoding een reden om alles in elkaar te laten vallen?

Nee. Dat is slechts één van de redenen. Komt bij dat één lid meteen (individueel) het merk claimde, en dit alles zonder overleg met de rest van de groep.

Lees het blog en het wordt duidelijk wat hieraan ten grondslag ligt.

Als wat in het blog staat echt klopt (geen idee...) lijkt de afsplitsing me wel erg begrijpelijk. Dit is niet echt een kleinigheidje zeg maar, maar een fundamentele vertrouwenscrisis tussen de groepsleden.

[rob12424]

Maar hoe zit dit juridisch dan? Je hebt toch een statuut neem ik aan. Je kan niet zomaar zeggen ik ben eigenaar en een merken recht claim neerleggen mag ik hopen?

[neversium]

Maar ook gewoon heel dom om dit niet snel te trademarken als je ziet dat je applicatie goed ontvangen wordt en steeds populairder wordt.

[punishedbrains]

Niet het enige dus, maar als het puur vibe-coden is geweest zit je snel met onzinnige stukken, niet goed te managen code te werken. Geen idee wat er precies aan de hand is, maar dat zou voor mij zeker al een reden zijn iemand anders te zoeken.

[Stukfruit]

Ik denk dat het meer zit in het bijbehorende gedrag zoals dit laatste: "... to have an insider team up with a robot and a lawyer".

Maar de app en de map zien er beiden inderdaad uit alsof ze gevibecode zijn.

[Snelletomaat]

Volgens mij verandert er weinig. Er zijn twee apps om MeshCore op je telefoon te draaien en gebruik te maken van het MeshCore radionetwerk. De ene is van het team en staat in de App Stores. Gratis.

De andere is MeshOS. Die is van Andy Kirby. Andy heeft een heel actief YouTube kanaal, vlotte babbel en een gunfactor. En die wil geld zien voor zijn app. Nou, dan gebruik je de app van het team.

[Reactie gewijzigd door Snelletomaat op 24 april 2026 21:45]

[Golenes]

Ik hoop sterk dat de FOSS versie van de Meshcore app de ontwikkelingen goed bij gaat houden. Die werkt voor mij trouwens prima. Dit soort ontwikkelingen brengen de nood aan een volledig vrij ecosysteem toch wel in het licht voor mij.

[Luckystriike]

Drama… drama? Dat valt wel mee. Alles is en blijft gewoon MeshCore. Men spreekt er al niet meer over. Ik denk dat de post behoorlijk wat context mist. MeshCore is hun officiële product. Andy heeft op een gegeven moment een eigen app ontwikkeld genaamd MeshOS. Daarnaast beheerde hij ook de website.

Andy heeft nooit een regel code geschreven voor de officiële MeshCore-firmware of apps. Toch heeft hij, zonder de developers in te lichten, een trademark aangevraagd. Bovendien heeft hij de volledige code van de app gevibe coded en wilde hij er ook een betaalde app van maken. Overigens zou hij ditzelfde verhaal ook hebben geprobeerd bij Meshtastic.

[GS3315]

Toch heeft hij, zonder de developers in te lichten, een trademark aangevraagd. Bovendien heeft hij de volledige code van de app gevibe coded en wilde hij er ook een betaalde app van maken. Overigens zou hij ditzelfde verhaal ook hebben geprobeerd bij Meshtastic.

Bedoel je niet dit toevallig voor wat betreft die trademark? > Youtube.

[Reactie gewijzigd door GS3315 op 25 april 2026 02:39]