Home   2026-10-22 19:56:51

←

Meta brengt terminalagent Muse Code uit voor grote codebases

Original article

Meta heeft een AI-agent voor programmeertaken uitgebracht. Muse Code werkt in de terminal en is gebaseerd op het bestaande Muse Spark-model van Meta zelf. Volgens Meta is de tool vooral gericht op werk met grote codebases.

Meta zegt dat de software in bèta beschikbaar is. Muse Code werkt in terminals en kan met één commando worden geïnstalleerd. Zoals de naam al doet vermoeden werkt Muse Code op basis van het AI-model Muse Spark, specifiek versie 1.2. Meta bracht Spark eerder dit jaar uit.

Muse Code slaat alle calls, toewijzingen en aanpassingen in een lokale log op. Dat maakt het model volgens Meta beter in staat om langdurige taken uit te voeren, omdat het de benodigde informatie maar uit één bron hoeft te halen.

Met commando's als '/plan' kan Muse Code een taak plannen waarin meerdere opdrachten moeten worden goedgekeurd. Met '/grill' kan een opdracht worden getest en met '/goal' kunnen specifieke doelen voor een opdracht worden opgesteld.

Muse Code werkt ook met agents die op de achtergrond draaien en goed naast elkaar kunnen werken. Als een bepaalde taak te groot blijkt, kan Muse Code subagents aanmaken die ook parallel kunnen werken. Volgens Mark Zuckerberg is de tool door die functies voornamelijk interessant voor grote codebases.

Muse Code

Door Tijs Hofmans

Nieuwscoördinator

Feedback • 07-08-2026 12:38
56 • submitter: Yeebo

07-08-2026 • 12:38

56

Submitter: Yeebo

Reacties (56)

Interessant: als je Meta laat trainen op jouw data is het model grofweg 20 keer zo goedkoop. Dan heb je het over $4.25 tegenover $0.20 voor output tokens. Hier zie je ook hoe belangrijk de data is voor het maken van een goed model.
Dat had ik ook gezien en is heel interessant, zeker voor code die ik toch open source wil publiceren. Maar de kwaliteit van het model is ook niet alles. Als ik er 4 dollar aan herhaalde prompt voor nodig heb om het zelfde te bereiken als de rest kan schiet het niet op. En meta kan dat niveau niet lange termijn volhouden. En meta komt niet in de buurt van iets als fable of gpt5.6

[Reactie gewijzigd door bzuidgeest op 7 augustus 2026 15:02]

Als ik er 4 dollar aan herhaalde prompt voor nodig heb om het zelfde te bereiken als de rest kan schiet het niet op. En meta kan dat niveau niet lange termijn volhouden.
Helemaal mee eens. Zo heb ik de afgelopen 2 dagen een Hermes agent gebouwd met qwen via openrouter. Fantastisch dat ik ineens geen ethische bezwaren meer voor mijn kiezen krijg met pentesting maar ik moet wel veel specifieker zijn wat ik precies van hem wil als ik het vergelijk met de laatste modellen van openai of anthropic.
Dat kan de inrichting van het model zijn. De manier waarop je het ontwerpt heeft invloed op welke prompts het beste werken. Het standaard advies is daarom altijd om de prompting-guide te lezen. Overigens als ze een model maar groot genoeg maken en voldoende post-trainen kan het gewoon met alle prompts overweg natuurlijk. Maar de onderliggende architectuur kan altijd invloed behouden. Er was iemand hier die er een mooie reactie over had geschreven, maar ben zijn naam vergeten helaas.
Fable gaat inderdaad veel te makkelijk op de rem staan. Gelukkig is gpt voor veel met zo goed en veel minder gevoelig daarvoor.
Dat is op zich geen slecht idee. In de juiste omstandigheden kan dat voor beide partijen aantrekkelijk zijn.

Maar als ik in ons bedrijf verantwoordelijk zou zijn voor ook maar iets dat hier mee te maken heeft zou mijn eerste gevoel zeggen dat Meta niet de eerste partij is waar we mee in zee gaan.
Vraagje aan echte gebruikers. Ik volg de AI ontwikkelingen nog altijd met veel interesse. Sommige mensen haten het, anderen gaan er volledig voor. Ik heb een vraag aan de ondernemers die hier aanwezig zijn. Ik lees vaak dat programmeurs of webdesigners zeggen dat ze wel 2 tot 10 keer zo productief zijn. Mijn vraag is, hoe vertaald dit zich door naar de omzet en de winst? Is deze ook 2 tot 10 keer toegenomen?
Waar lees je dat programmeurs of webdesigners zeggen dat ze 2 tot 10 keer zo productief zijn? Ik zie mijzelf omringd met developers en webdesigners die zeggen dat ze bij PoC's en selfware weliswaar snel meters maken, maar bij onderhoud aan grotere codebases van grotere projecten en producten problemen tegenkomen waardoor de aard van hun werk weliswaar is veranderd (minder boilerplate code schrijven, meer specificatie, review & test), maar de output / outcome nauwelijks.

Het verschil tussen de jay- als naysayers is in mijn ervaring vooral het geloof of dit allemaal (nóg) beter wordt (alles wat AI nu nog niet kan, kan het straks wel, en goedkoper/sneller) of dat we onszelf enorm tegen gaan komen (vendor lock-in, milieuimpact, privacy wetgeving, licenties, onbetaalbaar tokenmaxxing, enshittification, developer skill degradation).
Changes waar we voorheen met een volledig scrumteam 8 weken voor uittrokken, krijg ik nu vaak met AI in ~60 minuten rond. En ja, ik heb het hier over compliance-zware enterprise-systemen en omgevingen op schaal, niet over een simpele CRUD-app.

Dat is niet “minder boilerplate schrijven”; dat is een fundamentele verschuiving in wat softwareontwikkeling kost en welke changes economisch überhaupt nog viable zijn.

Voor mijn eigen werk is 10x productiever eerlijk gezegd nog een understatement.
Ik geloof niet dat ik in 30 jaar development ooit 8 weken heb ingeschat of uitgetrokken voor wat voor programmeerwerk dan ook, omdat voor de omvangrijkere features het programmeren zelden hetgeen is waar het werk in zit. Het zit altijd in het helder krijgen van de requirements, het begrijpen van wat er al is, het in kaart brengen van afhankelijkheden en integraties en het afstemmen met stakeholders en andere teams.
Als je AI/LLM’s niet vanuit hetzelfde referentiekader als 4GL, low-code en no-code had bekeken, was het je misschien al opgevallen dat juist de dingen die jij als het ‘echte werk’ noemt inmiddels al een poosje door AI worden opgeslokt.
Ik kan me dat niet voorstellen. Voor nu blijft het begrijpen van processen van een bedrijf en wensen van stakeholders toch echt mensenwerk. Hoeveel "context" je dan ook kan voeren. Een LLM kan geen stakeholder lezen op basis van een lange werkrelatie.

Het versnellen van opstellen van documentatie van requirements zou je kunnen aanvoeren als werk dat wordt "opgeslokt". Maar de winst daar valt mij persoonlijk heel erg tegen. De langdradigheid en retoriek lijkt eerder te vertragen. Achter woorden zit geen intentie. Developers gaan globaler lezen en missen vervolgens mogelijk kritische dingen.

Dan zou je kunnen zeggen: een LLM implementeert het toch? Maar dan wordt het een beetje een telefoonspelletje, en we weten hoe die eindigen.
Het ligt ook een beetje aan de codebase en of die er geschikt voor is. We hebben componenten waar AI helemaal in verzand. Eigenlijk elke middelmatige developer ook, zeker als ze niet eerst 12 maanden zijn ingewerkt. We hebben ook componenten die behoorlijk straightforward zijn qua technieken e.d. en goed aansluiten bij waar AI al voor wordt ingezet. Daar geeft het een vele malen grotere boost in productiviteit.

We zijn op architectuurvlak het één en ander aan het herorienteren en uitdenken zodat (nieuwe) developers effectiever ingezet kunnen worden met goede ondersteuning van AI.
Dat geloof ik direct. Maar ik vraag me vooral af, maak je ook 10x zoveel winst of is dit gewoon een nieuwe manier van werken? De concurrent doet het ook op deze manier, de klant krijgt dus meer/sneller wat hij wilt, maar eigenlijk gewoon tegen dezelfde prijs?
Ok, ik ga het schrijven...

Misschien ben ik wat negatief, maar als dit jullie proces is, en dit een typische ervaring, dan is er misschien een probleem op management nivo bij de partij waar je bij werkt. Dat kan zitten in de opzet van de samenwerkingen tussen afdelingen of intern bij de uitvoering, prioritisering, etc.. Misschien word er aan gewerkt. Kan door een overname komen waarbij een partij anders blijft werken dan de bovenliggende realiteit in de organisatie zin... Maar goed allemaal speculatie.

Als je in het begin van je carriere zit is dat helemaal niet erg, misschien zelfs enorm leerzaam, je leert er veel als je maar goed kijkt wat er om je heen gebeurd. En ga a.u.b. naar een andere partij over twee jaar die het totaal anders aanpakken of in een ander werkveld zit. Op die manier kun je wat je hebt gezien aan verkeerde aanpak goed 'inleren'.

Als je al wat jaartjes hebt gedaan 'in het veld'... Het lijkt mij dat je als je door was gegaan op die manier wel had kunnen opbranden, dan is die LLM oplossing inderdaad wel een uitkomst. Hoop op het eerste scenario, dan kun je een uitstekende developer worden!
Als developer kan ik zeggen dat ik wel degelijk meer kan doen. Echter het probleem treed op een zeker punt op dat de AI zoveel, zoveel vlugger kan dat ik het niet meer kan bijhouden. De limitatie is de mens hier. Echter dingen als fable en gpt5.6 worden zo veel beter dat steeds meer werk goed gedaan kan worden met durf ik het te zeggen minimale controle. Je moet weten waar wel en waar niet. En je hebt je testsuite en intelligentie ook nog. Een junior programmer hoef je ook niet altijd 100% na te kijken.

Zelfs als het niet meer beter word is dit een enorme hulp. Bepaalde tools die netwerkprotocollen moeten verwerken die low prio waren omdat het veel uitzoek en test werk was gaan nu in een paar uur uit de AI komen. Paar duizend credits en klaar.

Wat betreft vendor locking.... Dat valt mee. Via Microsoft github copilot, heb ik gpt, claude, kimi, mia, grok en wat al niet. En ik gebruik naar gelang taak complexiteit en kosten verschillende modellen van verschillende leveranciers. Als openAI morgen ontploft gaan we verder met claude, of andersom met gpt.

Ik gebruik meest interactive sessies. (een of meer). Achergrond werk vertrouw ik nog niet zo en er is best nog wel wat stuur nodig. Ik ben niet afhankelijk van wie dan ook als AI leverancier. Zolang de AI mijn code kan zien en voor mij bewerken is het goed. Ik investeer in weinig dat leverancier specifiek is.
Ik ben een ervaren softwareontwikkelaar. Bij de klant waar ik nu werk mogen we GitHub Copilot gebruiken in VS Code en IntelliJ, en hebben we verschillende LLM's beschikbaar (o.a. van OpenAI, Anthropic en ook Kimi).

Het afgelopen jaar is het heel hard gegaan. In het begin waren de modellen nog vrij dom; je kon 'm vragen een unit test te schrijven, maar het was hit-or-miss of je dan iets bruikbaars kreeg. Nu is dat geen enkel probleem meer met bijv. Opus 4.8 of 5.

Als experiment heb ik één van de oude zelf ontwikkelde apps van de klant proberen te herschrijven. Er zijn een aantal SOAP XML webservices met een behoorlijk uitgebreid datamodel, wat in XSD's is beschreven. Ik schreef één prompt, gaf het model ook de XSD's en een paar voorbeeldfiles. Hij was er een half uur op aan het stampen, en er kwam een enorm goede applicatie uit die heel netjes precies voldeed aan het datamodel. Het was verbazingwekkend hoeveel informatie hij uit de XSD's had weten te halen.

Ik vond het ook zelfs een beetje eng hoe het mogelijk was om dit met één prompt te maken. Als ik die applicatie met de hand had moeten maken dan was ik zeker twee weken bezig geweest.

Aan de andere kant, met een hobbyproject, wat een wat groter en meer compleet stuk software is en wat ik grotendeels met Claude Code maak, merk ik dat ik als softwareontwikkelaar niet overbodig ben - de AI stelt veel vragen, er zijn heel veel details waar beslissingen over moeten worden gemaakt en daarvoor moet je precies begrijpen waar het over gaat, de AI produceert soms bugs, inclusief security bugs, dus het is belangrijk om goed in de gaten te houden hoe de geproduceerde software in elkaar zit. Ik kan me voorstellen dat dit voor een pure vibe coder, iemand die zelf geen verstand heeft van programmeren, een te complex gebeuren zal zijn.

AI programmeertools zijn niet meer weg te denken en hebben in korte tijd het vak van softwareontwikkelaar veranderd en zeker sterk versneld. Maar dat betekent niet dat je zelf niets meer hoeft te weten.
Dit is iets dat zo'n LLM goed kan, specs voor (goed werkende en geteste) API's verwerken. Dit was ooit de belofte van SOAP en je kwam inderdaad best ergens met auto-complete en een paar voorbeelden. Maar zoals altijd kreeg je die verschillen in envelope, call wrapping van types en headers en te veel manieren om iets te doen en service discovery, etc.. Met LLM's is dat misschien een stuk beter te doen, je hoeft alleen maar de meest actuele documentatie te verstrekken. Lees er weinig over eigenlijk, wellicht omdat veel van die omgevingen geen cloud diensten mogen inzetten (begrijpelijk maar ben toch nieuwsgierig).
YouTube: What 6 months of AI coding did to my dev team

De juniors zijn weldegelijk 2x tot 10x zo productief, maar de medio's & seniors worden onder gesneeuwd. Ik denk dat AI nu gewoon een zware optimalisatie slag moet gaan beginnen. Net zoals google'n een skill is, is AI (goed) gebruiken dat ook. Je schrijft nu (terug) "technische" specs inplaats van echte code.
Ik schrijf een technische spec in een half a4-tje. De AI kan het daarna uitwerken. Zo schrijven dat een goedkoop model het kan bouwen. Inclusief een phase 0 om dat het goedkope model zichzelf laat testen of het de opdracht aankan..... Daar kwam fable zelf mee aanzetten. Ik moet de spec even nalezen maar doorgaans is deze uitstekend. Paar tweaks, misschien een misinterpretatie vragen weg te werken of iets te verduidelijken. Maar het kost echt nauwelijks moeite meer. Ik heb nog nooit zoveel en tegelijk zo weinig en zo goed gedocumenteerd in elk project. Markdown, Mermaid, je code is in een seconde gedocumenteerd.

Het is wel een probleem dat je zoveel kan doen dat je meer projecten in de AI kan gooien dan je als normaal mens kan verwerken. Dan loop je tegen AI burnout aan als je niet uitkijkt.

Ik ben nu een veredelde prompt engineer. Dat is aan de ene kant saai. Aan de andere kant kan ik nu zoveel meer. Voorbeeldje ik wilde spelen met chromiumOS, of ik google services voor aanmelden e.d. zou kunnen vervangen door eigen services. Als ik dat zelf moet doen ben ik weken bezig. De AI had het in een paar uur met mij werken volledig uitgescript. Build en done. Zoiets is dus nog gewoon bereikbaar als kleine test in plaats van iets dat een grote inzet vereist. Ofwel zoveel dingen kan je nu veel makkelijke als POC doen.
Specs schrijven, tests definiëren en laten schrijven, tests checken, implementatie grotendeels door AI. De hoofdmoot zit hem in ontwerp, documentatie, test baarheid en verificatie. Ik werk aan best complexe systemen en integraties, en echt handmatig hele stukken code schrijven zit er inderdaad al een tijdje elke maand weer een stukje minder in. Bijkomend voordeel is dat management eindelijk een verkoopcase ziet voor end to end testing, ook als de doelplatforms daar wat complexer voor zijn, 'want dan kan er meer betrouwbaar met AI'.

[Reactie gewijzigd door graey op 7 augustus 2026 18:39]

Momenteel werken wij binnen onze firma uitsluitend met subscriptions van openAI en anthropic, en door de token limit zie je ook dat mensen gaan afwegen wat ze met AI doen en wat niet.

Verder zou ik zelfs geen verdubbeling van de productiviteit stellen. Als je puur kijkt naar code wel ja, maar die gigantische aanpassingen moeten ook nagekeken worden door andere medewerkers in een code review, nadat de programmeur het al nakeek (want die blijft verantwoordelijk voor de opgeleverde code).

En voor je op enter kan duwen voor je prompt te versturen ben je vaak enkele uren kwijt met het opstellen van die prompt omdat je de taak volledig moet gaan analyseren, zeker als je ergens een vage beschrijving van een nieuwe feature krijgt.

Al die tijd die ze daaraan spenderen coderen ze natuurlijk niet.

Ik zou zeggen 25-50% productiever in het wild, waarvan een kwart weer verloren gaat tijdens het wachten op de output en opvolgen van de prompt.

Edit: wij zijn overigens van mening dat de gewonnen tijd 100% productief moet worden opgevuld. Ik zie vooral dat er meer ruimte ontstaat om even uit te waaien of te pauzeren, want werken met AI betekent ook een grotere cognitieve load voor de programmeur.

[Reactie gewijzigd door IskaRiot op 7 augustus 2026 13:39]

en je vaak enkele uren kwijt met het opstellen van die prompt omdat je de taak volledig moet gaan analyseren, zeker als je ergens een vage beschrijving van een nieuwe feature krijgt.
Dat pak je dan als ik zo cru mag zijn niet zo slim aan. Ik schrijf typisch in 5 minuten een spec, met de grove intentie. De grove outline met de prio's. Daarna vraag ik de AI het te lezen en uit te werken. Meestal nog 5 minuten om tweaks te laten doen. En misschien 10 minuten om het na te lezen. Spec schrijven door frontier modellen is stompzinnig goed.

Je kan dan de frontier model AI ook vragen om de spec zo te schrijven dat het goedkope model het werk kan doen. Toen ik dat onlangs testte kreeg ik een spec met fase 0 met een controle voor de cheap agent om aan te tonen dat hij het snapte door bepaalde doelen te testen en te bouwen. En pas phase 1 te doen met dat model als het door 0 heen kwam.
Zal je aanvullen dat een deel van onze klanten vibe coders zijn die een product ineen staken, vast kwamen te zitten om allerlei redenen, en bij ons ten rade komen. Gaande van debugging, security, hosting, mensen die maandenlang even op 5minuten een prompt schreven.... Mensen die een product ontwikkeld hebben, klanten aan zich gebonden hebben en nu zich genoodzaakt zien zich tot professionals te keren om hun te redden van de ondergang;

Verder werken wij ook aan grote platformen voor publieke instellingen waarbij stabiliteit en security belangrijker zijn dan flexibiliteit en snelheid. Platformen met 20 jaar aan ontwikkelingsgeschiedenis, etc... Dan merk je echt wel het verschil tussen de capaciteiten voor een greenfield project en een bestaande legacy codebase.

Edit: en verder heeft het ook weinig zin om 32k aan anthropic API calls te doen voor een project dat geraamd is op 15k, pijnlijk maar waargebeurd incident in mijn omgeving.

[Reactie gewijzigd door IskaRiot op 7 augustus 2026 15:50]

Edit: en verder heeft het ook weinig zin om 32k aan anthropic API calls te doen voor een project dat geraamd is op 15k, pijnlijk maar waargebeurd incident in mijn omgeving.
Dat komt in de nieuwe wereld van vandaag wel vaker voor. Maar dat is een management issue. Kosten en baten moet je nog steeds in de gaten houden. Maar in mijn ervaring zijn er enorme baten te halen bij correct gebruik. Ik heb de AI hele apache codebases laten omzetten in een andere programmeertaal als test. En die project zoek je uit op het hebben van grote test suites. Het neemt even, maar ze komen er wel doorheen. Dus legacy hoeft geen probleem voor ze te zijn.
Verder werken wij ook aan grote platformen voor publieke instellingen waarbij stabiliteit en security belangrijker zijn dan flexibiliteit en snelheid.
Dat is absoluut een geldige keuze. Zolang je klant bereid is de kosten daarvan te accepteren. De klanten bij ons komen vandaag vragen wat ze gisteren nodig hadden. Andere situatie.
Zal je aanvullen dat een deel van onze klanten vibe coders zijn die een product ineen staken, vast kwamen te zitten om allerlei redenen, en bij ons ten rade komen.
Ik kan niets over jou vibe codende klanten zeggen, maar AI rommel opruimen is big business. Ik denk echter dat ik met bijna 20 jaar ervaring in programmeren iets beter weet wat ik de AI laat doen en niet doen dan een klant met een enthousiaste prompt engineer. Een AI kan hele goede resultaten behalen. Als je weet wat je doet met programmeren en als je weet wat je doet met AI. Vibe coding moet ondersteunend zijn, je moet besef hebben van je doel en hoe de techniek in algemene lijnen moet werken. Een idee op een post-it aan een AI geven zonder enige verder besef van wat je wil.... Tja dat heeft ook wisselende resultaten bij mensen.
32k aan API calls? En dit kon niet binnen een subscription? Voelt wel een beetje als de verkeerde tool voor het verkeerde probleem gebruiken dan...
IskaRiot schreef net dat hij komt fixen bij partijen waar dingen fout zijn gelopen, dan kom je van alles tegen...
Ik ben er zo een. Als je zelf ondernemer bent, weet je dat omzet en winst natuurlijk van veel meer dingen afhangen dan productiviteit, tenzij die productiviteit je enige product / service is. Maar ik kan wel zeggen dat minstens twee derde van onze omzet niet had kunnen bestaan als alles zelf met de hand had moeten bouwen wat ik nu met hulp van AI doe. Eerst als kleine prompts en dan stukjes code van en naar chatGPT kopiëren, daarna geïntegreerd in VSCode en nu deels nog verder geabstraheerd met agents.
Ik ben C programmeur op Linux en werk nu aan een complex audio tool voor muzikanten (ik ben zelf gitarist). Code base nu zo'n 10.000 regels, 34 source files. Ik ga volgende week in beta na 6 weken programmeren, samen met Gemini Pro cloud en Qwen 3.6 lokaal. Als ik dit in m'n eentje had gedaan zou ik, schatting, 6 maanden zijn bezig geweest. Code kwaliteit is uitstekend, geoptimaliseerd voor low latency en minimaal systeem resources gebruik. Ja, AI kan enorm versnellen mists je minimaal een redelijke programmeur bent die de betreffende taal goed onder de knie heeft.
Voor ons betekent het met name een shift waar de vertraging zit in het proces. Voorheen het coderen zelf nu meer het uitdenken.
  1. de businsss kan het vaak niet bijbenen. Dus de wachttijd is nu of bij het uitwerken. Maar ook bij het adopteren van nieuwe stukken. Dus echt veel sneller is het zeker niet altijd in grotere producties. Bij kleine projecten en kleine groepjes zie je het vaak wel. Als je maar 2. - 6 mensen. Heb gebruiken gaat het vaak sneller.
  2. Er wordt meer geprobeerd met developers zonder goed wordt uitgedacht en er meer aanpassingen nodig zijn.
. Ik lees vaak dat programmeurs of webdesigners zeggen dat ze wel 2 tot 10 keer zo productief zijn. Mijn vraag is, hoe vertaald dit zich door naar de omzet en de winst?
De concurrentie gebruikt de tooling ook en zo is het voordeel op de concurrentie ineens weer weg ;)
Winst met 2 tot 10x toegenomen, nee helaas niet, ook de concurrentie gebruikt AI.

Wat wel voor ons een heel duidelijk verschil is dat wensen van klanten welke voorheen onevenredig duur waren ten opzichte van de toegevoegde waarde voor een klant. En daarmee in sommige gevallen dus onverkoopbaar nu vaak wel mogelijk zijn. Hier zit wel een stuk extra winst voor ons.

Het zelfde geld voor bijvoorbeeld opzetten van een kleine demo omgeving, soms met meerdere versies wat een klant over te streep kan trekken een opdracht te geven, omdat soms zien ook geloven is.

interne processen optimaliseren welke voorheen te veel werk waren om te automatiseren lukt nu een stuk eenvoudiger, wat simpelweg kosten bespaard.

Daarnaast extra verkoop opties, zaken die klanten regelmatig zelf deden ter voorbereiding op een traject om kosten te besparen (data optimalisatie, media voorbereiding etc) kunnen wij nu ineens wel voor een voor de klant acceptabel bedrag

dus extra winst ja, maar met name door extra diensten die nu ineens mogelijk worden
Bedankt, dat is een mooie inhoudelijke reactie. Duidelijk dan het niet zo kort door de bocht is als optimalisatie = winst, maar wel dat er veel voordelen zijn die uiteindelijk tot winst resulteren. Natuurlijk kunnen we zeggen dat dit tijdelijk is totdat iedereen het doet, maar zo zwart wit is het ook weer niet in de praktijk.
Grappig in 201x hoorde je atlijd leer programmeren, daar is altijd werk in. Nu zie je dat AI steeds meer junior programmeurfuncties replaced.
Grappig is dat AI vooral allerlei junior functies kan overnemen. En dat er dus steeds minder plaats is voor juniors... met als resultaat dat er langzaam steeds minder mensen zullen zijn met de kennis en de expertise om medior of senior te worden.
En ik heb niet het idee dat je al die functies aan AI moet kunnen of willen overlaten ;)
Tja, sinds de auto, kan bijna niemand meer paardrijden :)

De wereld veranderd. Met of zonder ons hij draait wel door.
Je mist zijn punt. Om auto te leren rijden hoef je niet eerst paard te leren rijden.
Nee, want om programma's te maken hoef je dus niet meer leren programeren in het AI tijdperk (of dat is het idee, we zijn daar nog niet).

Hij vraagt zich af of we wel alles aan AI moeten overlaten. Tja we laten vervoer nu ook aan de auto over. Als de auto het niet meer doet kunnen we niet zomaar het paard van stal halen. Coding kennis of paard, weg is weg.
Je zal nog altijd moeten leren programmeren, maar dan met AI/LLM. 30 jaar geleden leerden we ook al niet meer programmeren met punch-cards of in assembly.

Het is niet zozeer de taal specifiek, het is de methodiek. En die methodiek zal je moeten leren wil je met toekomstige AI/LLMs solide software kunnen ontwikkelen. AI/LLM is de moderne compiler imho, de programeer taal is alleen veranderd naar veel meer human readable.

En ja, weg is weg, maar we kunnen ook al decennia lang de punch-card en assembly programmeurs niet van stal halen en ook dat missen we niet. In diezelfde trend was het 15+ jaar geleden zelfs al zo dat nieuwe ITers bij hun HTS opleiding nog nooit een command prompt hadden gebruikt, niets wisten of interesse hadden in Linux, etc. Ik geloof dat we nog nooit zoveel Linux servers in gebruik hebben als nu...
Eens. Het enige wat ik niet zo zeker weet is of een menselijke architect zoals jij suggereert altijd nodig blijft. Ik weet niet hoe vlug het gaat zijn, maar ik acht het mogelijk dat ze op een gegeven moment goed genoeg worden om zonder ons te programmeren.

Kijk naar de auto. Eerst was dat een enkele. cylinder met steeds groter inhoud. Toen kwam opeens het idee van meerdere kleintjes op een enkele as. Etc. En nu is alles computer gestuurd en niet meer mechanisch in de auto.

Ik denk dat we met LLM nog maar bij de eenpitter zijn waar we de cylinder steeds groter maken. Ofwel iets als het aantal parameters. Maar als eu iemand met betere ideeën komt als MoE en dergelijke schuif het landschap ineens.

We zijn nog maar aan het begin.
Dat ligt er een beetje aan. Als we alleen nog software gaan over houden waar je een appel in gooit en er een banaan uit komt, dan zal niemand nog hoeven te programmeren. Maar als je heel veel als/dan situaties hebt die je software moet verwerken dan zal iemand dat toch gestructureerd zo een machine in moeten proppen en kunnen controleren of het goed is gedaan.

Het kan zelfs prima kunnen dat een machine dingen op een bepaalde manier interpreteert, denk aan bv. wetgeving. Of specs, of 100.000 andere zaken.

Iemands vibecoded app mag prima werken voor 1 persoon, die weet immers wat wel en niet werkt. Maar het is al een heel ander ding om dat voor de hele organisatie te laten werken, laat staan een heel land of de hele wereld...

En laten we wel wezen, niet elke developer/programmeur is een harde kei in het 'logisch nadenken', afhankelijk van de persoon kunnen ze slechts zoveel kwijt in hun hoofd voordat ook zij dingen gaan vergeten en hoe men dat goed structureert. Vandaar dat je nu ook ziet dat veel junior posities niet meer echt nodig zijn omdat de ervaring/kunde nog ontbreekt. En het is niet alleen juniors, maar ook bepaalde seniors die door de mand vallen. Maar je zal toch nog op de een of andere manier nieuw personeel moeten trainen en ervaring laten opdoen voordat ze een goede senior worden. En dat zien we ook in andere branches die niets van doen hebben met AI/LLM, denk aan bedienend personeel in de horeca of personeel in de OV sector, die waren opeens 'overbodig' in de pandemie en na de pandemie waren ze opeens wel weer nodig maar niemand die daar nog zin in had. Zelfs jaren erna loopt men hier nog steeds tegen aan. Er zijn al bedrijven die mensen die ze eerst hebben ontslagen opeens weer terug in willen huren, afhankelijk van de branch zegt een hoop personeel natuurlijk: "DAG! Ik heb al een andere baan of ik vertrouw jullie niet meer!".
Het is nog altijd een uitstekend idee om te leren programmeren als je daar genoegdoening uit haalt. AI gaat dat niet vervangen; het zal mogelijk de drempel verlagen om te beginnen en je helpen om generieke problemen op te lossen zodat je meer aandacht kunt hebben voor unieke oplossingen. Het zal enerzijds je tooling verrijken en anderzijds in bepaalde gevallen een nieuw soort oplossing zijn voor functionele problemen waar nondeterminisme een rol kan spelen.

Bij dit soort bewegingen (4GL, lowcode, no-code, Enterprise CMS, LLM, etc) gebeurt telkens hetzelfde: leveranciers van een nieuw idee of product kondigen aan dat programmeren overbodig wordt, managers die niet snappen dat de waarde van een developer voor 90% in andere zaken dan programmeren zit trappen erin, en ze zitten uiteindelijk opgescheept met een implementatie die lastiger en duurder is in onderhoud en uitbreiding dan wat ze hadden.

Ook nu komen bedrijven als Ford er al achter dat domeinkennis van je medewerkers nog altijd onmisbaar is, dat het verschuiven van de focus van schrijven naar reviewen de effectiviteit en het leervermogen van je developers niet ten goede komt, en dat tokens best wel onvoorspelbaar duur zijn terwijl de payoff achterblijft, en zijn weer extra developers aan het aannemen.
Dat is het gevoel, maar de data wil ik nog wel eens zien. Ik probeerde al enkele keren AI te gebruiken voor iets waar ik niks van kende ... daar kwam toch maar beperkt betrouwbare zaken uit.

Gedaan zijn de dagen dat je 3 uur op een syntax error zat te zoeken ... maar of we dat nu gaan missen :+
oor iets waar ik niks van kende ... daar kwam toch maar beperkt betrouwbare zaken uit.
Vragen en doorvragen, testen en weer vragen. Ik heb vele zaken getest en het resultaat is niet altijd in 1 keer goed, maar als je het concept begrijpt van waar je heen wil dan krijg je de AI ook wel zo ver. Reverse engineering, fpga code, hardware design, 3d modeling met openscad. Die laatste zijn ze nog erg slecht in, maar worden beter en je kan zo zien of het klopt.

Je moet wel zelf blijven denken en testen, maar je kan veel meer gebieden binnenstappen. Als ik kijk naar reverse engineering dient de AI ook als tutor voor de dingen waar een mens nog aan het werk moet.
Gedaan zijn de dagen dat je 3 uur op een syntax error zat te zoeken ... maar of we dat nu gaan missen
Flinke blast to the past van toen ik nog php deed! :o
Ik ben wel benieuwd hoeveel mensen hier met coding harnesses werken en of dat dan vooral van de partij is waar je een abonnementen hebt (Claude code of codex) of ook veel OSS zoals opencode en pi?

Ik weet niet of de markt nou zo'n behoefte heeft aan nog een harness, maar ik vermoed dat dit weer vooral een vemdor-lock-poging wordt. Net zoals Claude code, dat is de enige die je kunt gebruiken als je een abonnement bij Claude hebt, want de API-prijzen zijn veel hoger.

(Afhankelijk van het gebruik van je abonnement natuurlijk, maar genoeg verhalen van mensen die in een maand de hoeveelheid tokens gebruiken die 100x of meer zouden kosten dan het abonnement als je de API-prijzen zou betalen. Oftewel, die tokens zijn dan voor 99%+ gesubsidieerd; hoe sustainable is Anthropic dan?)
Vendor lock-in is natuurlijk bijna altijd slecht maar meer concurrentie op dit vlak is zeker welkom om alle partijen scherp te houden en te laten innoveren.

Alleen is dit tot nu toe een Claude Code kopie met ingebakken skills zo op het eerste oog, dus helaas nog geen bijzondere feature die andere niet hebben.

[Reactie gewijzigd door GewoonWatSpulle op 7 augustus 2026 12:53]

In die zin ben ik blij met github copilot. Ja API prijzen zullen wel hoger zijn (MS zal wel flink korting krijgen), maar ik heb toegang in vscode tot alles van anthropic Claude Haiku tot fable. GPT 4 to de laatste 5.6, kimi, grok, MIA etc etc...

Als de ene AI ergens moeite mee heeft of offline gaat stap ik door naar de volgende, schakel van goedkoop naar frontier met een click. Die flex is wel wat waard.

Het zou mooi zijn om iets equivalents te hebben op eigen servers op zonneenergie, met dezelfde tooling en open source. Maar zover ik weet is dat er gewoon nog niet. Het zal wel komen. Maar tot die tijd.... Modellen als fable zijn nog steeds niet perfect. Maar jeetje, in vergelijking met de eerste modellen zijn ze verbazend capabel. Zelf UI bouwen, zelf de visualisatie nakijken er even in rondklikken, ze kunnen het allemaal nu. Zelfs Kicad schema's wil nu lukken, met beperkingen. Reverse engineering word steeds beter. Alhoewel fables cyber blocks soms hinderlijk zijn. Maar dan is gpt er nog.

[Reactie gewijzigd door bzuidgeest op 7 augustus 2026 14:36]

Eens met @bzuidgeest. Ik gebruik ook vooral Github Copilot, de mode flexibiliteit is super fijn. Ik gebruik het in combinatie met Hermes Agent. Niet echt vanuit een IDE integratie zodat het ook sneller/makkelijker over meerdere repos heen dingen kan doen, en je kan er MCP servers aan hangen, daar hebben wij er inmiddels wel aantal van, ook voor een RAG.

Vendor lock-in is zeker een ding ja, elke AI club wil natuurlijk dat je hun tooling gebruikt. Als je bijv. een Anthropic API key voor Claude Code/Cowork aan een andere tool (zoals Hermes) probeert te hangen werkt dat ofwel niet of je key wordt snel genoeg geblokkeerd (heb ik gehoord).
MCP servers zijn handig. Ik laat de AI ze ook rustig maken waar ze niet bestaan zodat het bij tools kan waar het anders niet bij kan. Gelukkig is MCP niet vendor gebonden dus dat kan altijd mee naar een ander.
Interessant gerelateerd artikel: Yahoo Finance - Mark Zuckerberg’s Pivot to AI Is Blowing Up in His Face Spectacularly

[Reactie gewijzigd door P1nGu1n op 7 augustus 2026 12:53]

Niet zoveel interessants aan. Gewoon een mening gebaseerd op feiten die we allemaal inmiddels wel kennen.
Het is geen verrassing dat de persoon meest gelijk aan een robot tussen de big tech bazen vol inzet op robots maken die 24x7 kunnen werken. Het ego dat nodig is om te werken aan een digitale versie van jezelf zodat medewerkers daar mee kunnen chatten.,.. Het beste wat ik daar van dacht is dat die AI waarschijnlijk menselijker was dan zuckerberg....

Het artikel is leuk als opinie, maar eigenlijk is dit al jaren bekend. Zoals het artikel stelt. Verre van Zuckerbergs eerste fiasco. Metaverse anyone?
Maar.. wat gaat het kosten?
Ik zie weinig langskomen in het algemeen over Meta's AI in tegenstelling tot andere bots.

Zijn er mensen die ervaring hebben met de AI van Meta voor wat betreft programmeren.
Ik ben al terughouden met AI agents maar voordat ik ook maar iets van Meta toelaat op mijn systemen moet ik wel heel erg wanhopig zijn.

Om te kunnen reageren moet je ingelogd zijn