Microsoft: 'Tot 30 procent van onze nieuwe code is door AI gegenereerd'

Twintig tot dertig procent van alle code in de repositories van Microsoft is door AI gegenereerd. Dat zegt Microsoft-ceo Satya Nadella. "Sommige van onze projecten zijn waarschijnlijk zelfs al helemaal door software geschreven."

Nadella deed zijn uitspraken tijdens een gesprek met Meta-ceo Mark Zuckerberg, schrijft CNBC. Zuckerberg zegt niet te weten hoeveel van de code van Meta door AI gegenereerd is. Wel ziet hij de hoeveelheid werk die AI doet enorm toenemen. "We gokken erop dat volgend jaar mogelijk de helft van alle ontwikkeling door AI gedaan wordt, in plaats van door mensen. En dat blijft vervolgens alleen maar toenemen."

Zuckerberg vertelt verder dat Meta aan een AI-model werkt dat zelfstandig toekomstige versies van de Llama-modellen van het bedrijf kan maken. Veel meer details over dat project worden echter niet gegeven. Het is dus onduidelijk wanneer dat model moet verschijnen.

Google-ceo Sundar Pichai zei afgelopen week nog dat ook bij Google ruim dertig procent van alle code door AI wordt geschreven, weet MoneyControl. Dat is meer dan afgelopen oktober, toen het volgens Pichai nog om een kwart van alle nieuwe code ging. Toch zit het genereren van code door AI nog in een vroeg stadium, zegt Pichai. "Er moet nog veel gebeuren."

Door Eveline Meijer

Nieuwsredacteur

01-05-2025 • 07:25

130

Reacties (130)

Sorteer op:

Weergave:

Dit is marketingpraat. Natuurlijk beweren ze dat, ze willen copilot promoten. Maar de werkelijkheid is dat copilot alleen zeer simpele zaken kan en vaak onjuiste code hallucineert. Het zou me niets verbazen als ze het met die 30% zelfs over alleen gegenereerde unit tests hebben...
Intussen is de support op de bestaande frameworks teruggeschroefd. Ik programmeer C# voor desktop applicaties en ervaar dat de support voor WinUI 3 en MAUI door anderhalve kip wordt gedaan. Zelfs als je zelf met een pull request komt die een bug oplost, hebben ze de mankracht niet om die te reviewen. Het wordt met het jaar erger. Het is bizar.

[Reactie gewijzigd door MeMoRy op 1 mei 2025 08:22]

Mijn ervaring is anders.
Ik gebruik het voornamelijk om complexe Azure werkzaamheden te automatiseren in Powershell en af en toe wat C# console apps.

Het enige waar ik tegenaan loop is dat er af en toe veroudere of verkeerde AZ CLI of Azure management API calls worden gebruikt terwijl ik duidelijk aangeef welk commandos ik wil gebruiken.
Maar ik merk wel dat deze fouten steeds minder word.

De code die gegenereerd word, werkt meestal in een keer en hoef ik meestal maar een klein beetje aan te passen zodat het precies doet wat ik wil. En dat komt vaak doordat de AI mij net wat anders begrijpt.

Voor mij scheelt dit enorm veel tijd in het schrijven van scripts. Waarbij ik soms 1 a 2 uur bezig was dingen te automatiseren, ben ik nu soms in minuten al klaar.
Toegegeven, de code die uitgespuugd word is niet altijd zoals ik het zelf zou doen, maar aangezien het gaat om ons eigen werk te versimpelen, boeit dat me niet veel. Zolang het maar doet wat het moet doen.
Beetje dezelfde ervaring hier. Zeker voor werk/coding dat je niet elke dag doet, en dus niet direct helemaal uit je mouw schudt, helpt het enorm. En dan is het maar de vraag hoe je telt. Als je een paar functions/delen van classes laat genereren en overneemt, dan is die code door AI gegenereerd. Als je dan her en der wat aanpassingen maakt zou je kunnen zeggen dat AI dat stuk code voor 80% geschreven heeft. In die zin is het natuurlijk wel weer marketingpraat ;)

De waarheid zal in het midden liggen.
Het punt is denk ik dat er uit wordt gegaan van de code. “30% van de code” is een nietszeggend statement. Het is geen eenheid.

Als de uitgespuugde code half zo efficiënt is als handgeprogrammeerde code, heb je effectief 15% gespaard.

Klassieke doch vaak bewuste fout in de IT, wanneer men een product of service wil verkopen.
Er staat dan ook niet “30% van de code”, maar “tot 30% van de code”. Verder overigens met je eens hoor, dus het is geen kritiek op het punt dat je wilde maken. :)
Aaii je bevestigt mijn grootste angts : "Zolang het maar doet wat het moet doen", in de praktijk betekent dat vaak "Zolang het maar lijkt te doen wat ik denk dat het moet doen". AI is getraind op een hoop "voorbeeld code" die al laag van kwaliteit of verouderd is. (Eigenlijk niet heel anders dan de meest beginnende developers).

Alles bij elkaar zie ik AI nog gewoon als een stukje gereedschap, het doet dingen voor je... maar het maakt niet een kwalitatief goed eindproduct. Dat is nog steeds mensenwerk.
Het enige waar ik tegenaan loop is dat er af en toe veroudere of verkeerde AZ CLI of Azure management API calls worden gebruikt terwijl ik duidelijk aangeef welk commandos ik wil gebruiken.
Maar ik merk wel dat deze fouten steeds minder word.
Maar wie is wie hier aan het helpen?

En hou verhoudt zich dit tot de belofte van MS (30% overname) en toekomstige kwaliteitsborging?
Toegegeven, de code die uitgespuugd word is niet altijd zoals ik het zelf zou doen, maar aangezien het gaat om ons eigen werk te versimpelen, boeit dat me niet veel. Zolang het maar doet wat het moet doen.
De vraag is of als je het in een paar minuten bakt je wel lang genoeg hebt nagedacht over of dat een goede oplossing is en of er niet sluipende fouten in zitten., Ik hou iig mn hart vast voor een golf van 'I dunno. The AI did it' problemen.,
Ik vraag me af hoe ze dit meten. Als ik 5x een paar regels code anders hint en dan uit de lijst van 5 opties de juiste kies voor die regel, en dan op "auto complete" druk, is die regel dan door AI geschreven of door mij? Vergelijk als je de oude intellisense gebruikt en een method name auto complete is dat dan door intellisense geschreven?

En rekenen ze de 3x refactoring ook mee, of alleen de uiteindelijke regel code als boven?

[Reactie gewijzigd door Zoijar op 1 mei 2025 09:53]

Het zou me niets verbazen als ze het met die 30% zelfs over alleen gegenereerde unit tests hebben...
Eerlijk gezegd, dat is waar ik het voornamelijk en slechts af en toe voor gebruikt heb, ook omdat unit tests vaak meer volume hebben dan de code die het test. Dan is het makkelijk om aan zo'n cijfer toe te komen.
Ik heb een best complexe applicatie, maar als ik een nieuwe API endpoint wil aanmaken dat laat ik sowieso de bootstrap van die code genereren. Dan importeer ik de juiste functies en op basis van de spec die AI kan lezen kan deze de juiste functies gebruiken, en een deel van de logica voor me maken.

Daarnaast als ik bijvoorbeeld een database call doe en begin te typen dan autocomplete ie, vaak op basis van de overkoepelende logica en functie(naam) al de query code, de juiste aanroep, en ook nog juiste filtering en parsing van bepaalde elementen op basis van bepaalde voorwaarden die ik elders in de code ook gebruik.

Ik heb ergens tussen de 10% en soms zelfs 75% van de code gegenereerd door AI, en ik gebruik geen enkele chat, alleen maar Github copilot.

Haal je dan er nog een deel aan tijd vanaf die ik nodig heb om te valideren dat de code juist is, dan haal ik die 30% wel gemiddeld

[Reactie gewijzigd door Wraldpyk op 1 mei 2025 19:00]

Opmerkelijk hoe pessimistisch de reacties hier zijn en dat er consensus bovendrijft dat dit hooguit boilerplate en unit tests kan betreffen. Dat is de Copilot van vorig jaar.

De ontwikkeling van AI code agents gaat super snel. Copilot staat al op achterstand met tools zoals roo, cline en windsurf en cursor. Dit zijn agents in VSCode die met een enkele prompt vrij complexe taken uit kunnen voeren. De tooling begrijpt de context van een groter project een zoekt al zelf referenties in de codebase op. Test ook de code die het schrijft. Hele klasses worden eenvoudig gerefactort en voor nieuwe klasses kan het een hele goede werkende voorzet geven.

De mogelijkheden voor bedrijven die hun eigen modellen kunnen trainen op codebase en eigen MCP servers bouwen zijn alleen nog maar groter dan wat iedere hobbyist nu al kan opstarten.

Bekijk dit filmpje (helaas een clickbait titel, maar toch de moeite) als je dit in actie wil zien. YouTube: VS Code Agent Mode Just Changed Everything

[Reactie gewijzigd door JasperE op 1 mei 2025 20:16]

Ik ben ook enorm verbaasd dat nota bene bezoekers van Tweakers zo pessimistisch zijn over deze technologie. Ik merk dat ook in mijn netwerk: bedrijven die het inzetten zien zeer duidelijk de ROI, maar bedrijven die er weinig tot niets mee doen, zien alleen maar hype en weinig kwaliteit. Het lijkt wel alsof aardig wat Tweakers bij de tweede groep werkzaam is en geen interesse heeft in het ontdekken van de mogelijkheden
Ik snap je punt, maar ik zie er ook een serieus risico in om zo heavy op AI te vertrouwen. Snappen nieuwe programmeurs eigenlijk nog wel wat ze schrijven? AI dicteert het voor en ze kopieren. Maar geen kat (zeker geen nieuwelingen) die de code volledig snapt. Wordt dus leuk als je later het moet gaan onderhouden. Ik merk het nu al bij mezelf, code die ik zelf ooit heb geschreven snap je gewoon veel beter op een later tijdstip als er een bug uit komt. Een bug hoeft niet perse een technische bug te zijn maar kan ook fucntioneel iets zijn dat niet werkt zoals gewenst.

Ik kan meestal bij de analyse al in m'n hoofd nagaan "ik weet het al zitten want ik weet nog dat ik het zus en zo gedaan heb...". Dat heb je met AI totaal niet. Copy paste en klaar. Ik lees dikwijls, ja maar je moet nog altijd controleren wat je kopieert. Klopt en zullen de iets meer ervaren programmeurs ook doen, maar nieuwelingen? No offence, maar ik zie het nu al in de praktijk dat ze maar half snappen wat er uit komt, dus hoe ze dat dan moeten gaan controleren op correctheid is mij een raadsel. Code review komt dan bij de ervaren mensen, maar die pool droogt met de jaren dan gewoon op als we er volledig op inzetten.

Ik deel dus je mening dat je moet openstaan voor de technologie maar het is ook een zeer gevaarlijk iets qua kennis opbouw en ervaring die op lange termijn naar mijn mening hieronder gaat lijden.

[Reactie gewijzigd door Powerblast op 1 mei 2025 13:29]

Je moet ook tijd hebben om de mogelijkheden te ontdekken. Wanneer je vandaag werkweken klopt die al veel langer zijn dan hetgeen waarvoor je betaald wordt, waat ga je dan de tijd vandaan halen om met deze tools te leren werken? Want om deze toold productief in te zetten is er een leercurve en, ook niet onbelangrijk, moet je ook zeker de juiste tools vinden daar er niet 1 algemene AI tool is.

Dat zie je hier ook in de comments, waar mensen direct verschillende tools opnoemen die gebruikt zouden kunnen worden. AI gebruiken is dus investeren en niet iets waar je van de ene dag op de andere dag winst mee gaat maken.

Want als ik kijk naar de collega's die wel proberen om AI te omarmen, zonder goed en wel te beseffen van wat ze ermee moeten doen en dan zie hoe hard ze vloeken op het gebrek aan resultaat dat ze boeken en de tijd die ze net verliezen, dan begrijp ik de scepsis zeer goed.

Ik loop zelf nog altijd met een boog omheen alles wat AI is. Ja, ik stel heel af en toe een vraag aan Copilot, Maar ik ben vaker teleurgesteld in het resultaat dan tevreden, en zelfs als ik tevreden ben dan heb ik slechts een beginpunt om mee te werken en moet ik er alsnog tijd in steken om tot een degelijk eindresultaat te komen.

Uiteraard zullen we met onze tijd meemoeten en zijn LLMs niet meer weg te denken. Maar een kritische noot en wat tegengeluid kan echt geen kwaad.
Wat opgelost kan worden door bij een bedrijf te werken met een visie die dit ondersteunt en waar je tijd voor krijgt. Daarnaast mag je van veel mensen in de IT wel verwachten dat zij deze technologie interessant is.
Ik werk bij een consultancy/IT bedrijf dat voor verschillende klanten werkt. Veel software is dus niet onze eigendom, maar van de klant. Men is zeer panisch dat dit via AI gebruik uitlekt. Dus AI is interessante techniek, maar je mag er (voorlopig) geen gebruik van maken.
Er zijn meer dan genoeg opensource taalmodellen die je lokaal kunt draaien om dit probleem op te lossen.
Helemaal mee eens. Het is een toolset die verre van perfect of heilig is. Volop in ontwikkeling en nog zoekende naar stabiliteit, volwassenheid of voorspelbaarheid. Iedere maand verschuift het perspectief, positionering en de mogelijkheden van de verschillende aanbieders van zowel LLM als agents. Ik VScode al volop keuzemogelijkheden, in Visual Studio (c#/++) nog weinig te kiezen. In dat ecosysteem is het niet gek dat je terughoudend bent in het omarmen van het concept, echter de voortgang en sprongen die gemaakt worden zijn niet te ontkennen. De opkomst van de MCP standaard (eind '24) en de telkens grotere token context Windows als enablers in de inzetbaarheid. Althans voor zover ik de techniek begrijp.
probeer maar eens wat c++ code te genereren. Dat gaat wel en het is prima om je over punten een te helpen waar je even vast zit maar nog niet meer dan dat. Zelf Python gaat nog lang niet altijd goed. Ik blijf in ieder geval heel kritisch op de code die ik krijg en zoals hierboven gezegd, je moet wel kunnen begrijpen wat er gegenereerde wortd. Dat is helmaal niet pessimistisch, ik gebruik het gewoon waar mogelijk maar erg kritisch. Als iets lijkt te werken maar is achteraf niet goed genoeg voor alle cases dan heb je een probleem. Dat heb je ook met eigen code maar die ken je veel beter
Zeker /juist voor c++ zou ik het denk ik niet snel gebruiken omdat dingen vrij precies komen. In elke taal moet je natuurlijk scherp zijn maar dan is het vaak een domme werking, met C++ kun je echt gekke dingen doen als je code niet klopt.
klopt, maar zo goed ben ik zelf ook niet! Mijn code is redelijk rechttoe-rechtaan.

Ik ben bezig net vliestof dynamica, flood meolling, en zit te worsetelen met sommige stukjes code. En ik verwacht ook helemaal niet dat AI voor mij complete modules schrijft. Maar ik gebruik het vaak en vooral om ideeen te genereren die vaak voorbeelden zijn hoe andere modellen iets oplossen, en dat is zeker efficient. Dus ik ben positief maar ook kritisch natuurlijk. En ik wil zources zien van de antwoorden.
Ahja, ik neem aan dat je bedoelt vloeistof dynamica en fluid of echt flood modeling?
Daar hebben ze altijd mooie uitbreidingen die je zelf in C++ kan schrijven ja. Wanneer mogelijk blijf ik daar toch vandaan
eh flood modeling, weer gebasseerd natuurlijk ip vloeistof dynamica, maar dat eerste dus soms heb ik even hulp nodig
Dat komt ook omdat je helemaal dood gegooid wordt met "AI neemt al je werk over!!" presentaties, blogs, linkedIn posts, etc. Maar als ik het in mijn dagelijkse werk (.NET developer) gebruik dan merk ik dat het heel vaak code genereert dat niet compileert, tests maakt met duidelijk onjuiste test cases, verouderde api's gebruikt, omslachtige code genereert en ik kan nog wel even doorgaan.

Voor sommige taken is het super handig. Ingewikkelde SQL-queries om iets te controleren werken eigenlijk altijd en ook met typescript/angular zijn de resultaten al een stuk beter dan met C#. Maar heel veel code kan je ook binnen 30 seconden met een google search vinden.
Laatst zag ik een linkedin post waar AI de hemel in werd geprezen omdat het een kaart van europa kon genereren. Gek zeg, als het getrained is op duizenden vrijwel identieke kaarten. Bovendien, wat is het nut daarvan? Waarom niet een bestaande kaart gebruiken? Dat stoort me soms: het wordt aangeprezen als iets revolutionairs terwijl je exact hetzelfde kan bereiken met een zoekmachine. Bovendien kan je de bron dan een stuk beter controleren en kost het vele malen minder electriciteit.

Het is nog steeds één van de belangrijkste ontwikkelingen van de afgelopen decenia, maar het is nog lang niet zo perfect als de hype doet vermoeden.
De AI agent gaan echt wel verandering hierin brengen. Alle punten die jij op op noemt zijn eigenlijk user errors bij het gebruik van AI bij programmeren. Context, zorgen dat alles up to date is en de juiste promps, in kleine stappen werken. Setup is belangrijk,steeds makkelijker. Agents kijken nu al naar de context van de codebase en kijken naar de gebruikte implementaties, patterns etc.
Om de context de begrijpen moet AI de volledige code hebben en dat lijkt mij nogal link om te uploaden. Jou code gaat dan deel uitmaken van de gegevens waar AI over bezit. Ik merk wel dat AI handig is om wat ingewikkelde queries te schrijven of om een (kleine) functie te genereren. De code is niet altijd compileerbaar omdat dit soms afhangt van specifieke library versies. Je moet de AI vaak wel bijsturen maar dat is niet zo erg want het scheelt meestal wel tijd.
Nee je volledige code is niet nodig. Wel de directe context en files waar code terugkomt of andere implementaties.

Alle agents (edities/ide's) hebben privacy modes waar code geen deel uitmaakt van het trainen, beter maken van de AI of dat code opgeslagen blijft op de server.
Ik begrijp dat wel, angst.
Mijn pessimisme komt door de teleurstelling die het telkens opnieuw is. Op het werk mogen we enkel Claude 3.7 gebruiken wegens confidentiality, etc. Dus die hele cursus stack is geen optie. Maar toch, Claude staat toch vrij hoog aangeschreven dacht ik.

En naar mijn ervaring spaart het gewoon amper tijd uit op business logic. Ja het genereert code, en regelmatig werkt die ook. Maar ik moet ook elke keer achteraf nog dingen gaan opkuisen en refactoren. Ik zou dat ook aan Claude kunnen vragen, maar wat ik in bericht 3 heb gevraagd vergeet en overschrijft die weer tegen bericht 5.

Dat laatste had ik dus ook voor met tests. Hij genereert inderdaad een hoop tests, en een aantal ervan zijn zelfs goed. Maar ik wil het in een andere stijl met wat andere tooling want zo doen wij dingen. Elke stap apart ging goed maar het was gewoon onmogelijk om alles in 1 uiteindelijk resultaat te krijgen.

En zelfs voor documentatie vind ik het enorm tegenvallen. Vraag je om een bepaald stuk code te documenteren, begint die hele boeken te schrijven die in veel te veel detail gaan. Vraag je om het korter te maken, geeft die iets dat amper korter is. Vraag je 3 zinnen, geeft die er 8.

Die junior programmeurs die een paar weken geleden gestart zijn, doen het echt veel beter. Ja ze missen kennis, maar ze hebben tenminste geen dementie. Al die CEOs die beweren dat AI zo goed is als een mid-level ingenieur... Ik vraag me af wat voor prutsers die dan voor zich hebben werken...
Heb je overwogen dat mensen misschien wel een heel goede reden hebben om het niet te (willen) gebruiken, en dat de cijfers van bedrijven vooral meten wat men wil zien en in veel mindere mate wat er echt gebeurt, zoals ook al bij veel andere 'interne statistieken' in bedrijven gebeurt?

Het idee dat je met 'persoonlijke ervaring' (oftewel anecdata) een beter beeld hebt van de waarheid is sowieso al heel lang achterhaald, er is een reden dat dat bijvoorbeeld niet geaccepteerd wordt binnen wetenschappelijk onderzoek; en dat is dubbel van toepassing wanneer het systemen betreft die bewust de gebruiker voor de gek houden (zoals LLM-systemen doen door gedrag te emuleren maar niet de achterliggende redeneringen).
Persoonlijke ervaring houdt in een groot traject als CISO bij een internationale bank, een groot aantal freelance klussen en inmiddels ook investeerder vanuit een groot netwerk in onder andere OpenAI. Ik ben niet een willekeurige man die het leuke technologie vindt, maar iemand die de toegevoegde waarde en kwaliteit aan overheden en partijen zoals De Nederlandsche Bank en Bafin uit heeft moeten leggen.
Dat zal ongetwijfeld, maar dat alles heeft niets te maken met de reden dat 'persoonlijke ervaring' onbetrouwbaar is; ook jij bent (net zoals ik en alle andere mensen) vatbaar voor allerlei cognitieve biases, ongeacht hoeveel ervaring je hebt. En zoals ik hierboven al noemde is dat zeker van toepassing bij systemen zoals LLMs die bewust ontworpen zijn om op dergelijke biases mee te liften.
Ach ja, de vele investeringen, tientallen startups en wetenschappers/universiteiten die in mijn directe netwerk zitten maken het inderdaad een zeer persoonlijke ervaring ;)
Deze attitude is niet pessimistisch maar gezond skeptisch. Aangezien er weinig kwaliteitscijfers zijn is het een hele goede manier om de grootste troep uit codebases te houden.

Een voorzet die je niet zelf verzint is leuk, maar dan wordt de afhankelijkheid van de tool ook veel groter dan als je zelf met een papiertje en pen een voorzetje bedenkt bij de koffiemachine.

Alles heeft een prijs, de business-kant van bedrijven ziet alle prijsvoordelen en alle (ervaren) ontwikkelaars zien de kosten. Beetje de omgekeerde wereld is het in die zin.
Dat is wel deel van het gesprek om door te kunnen.
Dat gaat op voor de meeste automatisering. Automatiseer je iets, dan wordt je er ook afhankelijk van. Vroeger hadden we typistes, nu zijn we afhankelijk van computers.

Het skeptische verhaal zou m.i. toch best gecombineerd mogen worden met wat pioniersgeest en vooruitstrevendheid. Vandaar mijn input :)
En daar zit de crux bij AI, de POC’s zijn klaar en laaghangend fruit is geplukt, Nu mogen de serieuze bedrijven/mensen ermee aan de slag.
En dan blijkt dat er helemaal geen rekening is gehouden met onderliggende datakwaliteit of segregation of duties of AVG.

De codebase is maar een klein onderdeel van een bedrijf en daar staat echt niet alle bedrijfsprocessen volledig in uitgewerkt.

Pionieren is leuk, als er geen salarissen uitbetaald worden omdat AI heeft zitten rommelen in de code van urenregistratie en verlof, waardoor verderop in het proces payrolling niet werkt dan is het toch echt niet leuk meer.

Dan laat ik het pionieren daarin toch aan mij voorbij gaan voordat er bij een potentiële klant waar ik daaraan werk geen lonen gaan naar (bijv.) 10.000 medewerkers.
Tja, ik snap je voorbehoud wel, maar o1 vat het goed samen.
> Prompt: Vat de drogredenen in dit bericht samen als die er zijn. [ons gesprek eronder geplakt]
“Slippery slope” (hellend vlak) / “appel aan angst(stok)”
• Voorbeeld: “Als AI ergens in de code van urenregistratie en verlof gaat rommelen, dan krijgen 10.000 medewerkers geen salaris meer.”

– Hier wordt een worstcasescenario gepresenteerd, waardoor iets wat in theorie mogelijk is (maar in de praktijk vaak met checks en tests wordt ondervangen) tot een groot afschrikbeeld wordt opgerekt. Dat kan onder “slippery slope” of “appel aan angst” vallen, omdat de suggestie is dat één stap (AI inzetten) onvermijdelijk tot een hele reeks negatieve gevolgen leidt.

“Hasty generalization” (overhaaste generalisatie) / “sweeping generalization”
• Voorbeeld: “Er is helemaal geen rekening gehouden met onderliggende datakwaliteit of AVG/segregation of duties.”

– Dit impliceert dat ‘niemand’ dat zou doen of dat ‘geen enkel bedrijf’ goed nadenkt over deze zaken. Dat kan te sterk veralgemeniseerd zijn; sommige organisaties doen dit immers wel degelijk. Wanneer een spreker stelt dat iets “helemaal niet” gebeurt, is er een risico op overhaaste generalisatie.

Mogelijk “vals dilemma” (false dilemma)
• Voorbeeld: “Een voorzet die je niet zelf verzint is leuk, maar dan word je (te) afhankelijk van de tool.”

– Het kan overkomen als een tegenstelling: óf je bedenkt het helemaal zelf zonder tool (en dus ben je onafhankelijk), óf je gebruikt een tool en raakt er direct afhankelijk van. In de praktijk kun je natuurlijk beide combineren. Als het wordt neergezet alsof je slechts één van die twee opties hebt, dan dreigt een vals dilemma.

“Argument from ignorance” (in milde vorm)
• Waarneembaar bij uitspraken als: “Er zijn weinig kwaliteitscijfers, dus het is beter om (heel) sceptisch te zijn.”

– Dit kan worden geïnterpreteerd als een vorm van “we weten niet genoeg, dus we nemen aan dat het meest negatieve scenario” (of althans een erg terughoudende houding). Strikt genomen is dat niet altijd fout; scepsis kan natuurlijk terecht zijn. Maar als het wordt ingevuld als: “omdat we die getallen niet hebben, moeten we ervan uitgaan dat het slecht is,” kan het neigen naar een argument uit onwetendheid.
Overigens betekent het benoemen van drogredenen niet dat de gehele strekking onjuist is. Vaak zijn zorgen over AI of over automatisering (bijvoorbeeld omtrent privacy of afhankelijkheid) heel legitiem. Maar vanuit een technisch-logisch oogpunt is het goed om te herkennen waar redeneringen worden aangedikt of veralgemeniseerd, zodat je meer feitelijk en genuanceerd kunt blijven. Uit eigen ervaring heeft deze hele nieuwe toolset mij regelmatig juist goed op weg geholpen of, zoals ik al schreef, een mooie voorzet gegeven. Daarmee problemen kunnen oppakken waar ik eerder juist geen tijd voor had ivm uitzoekwerk die dat vereiste.

[Reactie gewijzigd door JasperE op 1 mei 2025 21:14]

Het uitbesteden van je beargumentering aan een LLM communiceert nou denk ik niet echt het punt dat je probeerde te communiceren. Waarom zouden mensen uberhaupt nog met je in gesprek gaan als je niet eens de moeite wilt nemen om zelf de visie van een ander te begrijpen en die van jou te delen?
Ik gebruik Copilot gewoon dagelijks in Visual Studio. Wat het generereert is een mix van modellen, analyze op je bestaande code en wat je recent getypt hebt. Er komt daar zeer regelmatig complete onzin uitrollen. Iig voor C++. Voor copilot in VS Code voor javascript of react is het beter, maar die taal is ook eenvoudiger.

AI begrijpt namelijk ook niets. Het combineert ook zaken, die niets met begrijpen te maken hebben, maar op waarschijnlijkheden dat het bij elkaar past. Dat klopt regelmatig, helpt je ook, maar slaat ook soms finaal de plank mis.

Als MS claimt dat 30% door AI gemaakt wordt, dan is het al interessant of AI zelf code maakt (dus zonder menselijke sturing op prompts, eerste woorden typen) of de trigger altijd bij de mens ligt. Want AI is per definitie reactief. Het neemt geen initiatief. Om die reden ben ik geneigd de claim van MS te betwijfelen c.q. meer als marketing praat te bestempelen. Het lijkt een beetje op dit ronkende artikel: nieuws: Nederlands kabinet overweegt inzet AI om externe inhuur ict'ers terug....

Ik zeg niet dat ik een expert ben, maar als de goegemeente amper snapt waarover het gaat, is het simpel om onzin en onmogelijkheden te geloven. Hoe minder kennis er in het algemeen is, hoe makkelijker je de grootste leugens/onzin op iemands mouw kunt spelden (en de bereidheid om ergens diep in te duiken en zelf te lezen, regelmatig ontbreekt). In dat opzicht is ontlezing wellicht een oorzaak van dit probleem. In die zin ben ik geen voorstander van filmpjes kijken om je kennis op te krikken.

PS. Het lijkt soms een beetje een 'geloof' in de betere toekomst, die te bereiken is door nog meer techniek, maar dat is een andere discussie. Net als aandelen: behaalde resultaten in het verleden bieden geen garantie voor de toekomst. En de bijna stompzinnige inzet op nog meer inzet van AI (en daarmee toenemend energieverbruik), daar erger ik me ook af en toe aan.
PS. Het lijkt soms een beetje een 'geloof' in de betere toekomst, die te bereiken is door nog meer techniek, maar dat is een andere discussie.
Ja dat 'geloof' zie je met elke hype wel terug. De cryptobro's die je altcoins wilden aansmeren op verjaardagen. De metaverse die het helemaal zou worden (was ik zelf nog het meest fan van) en nu AI weer.

Ik denk dat het wel wat gaat veranderen maar dat de scope lang niet zo groot is als de hijgerige investeerders zich nu aanpraten in de angst de boot te missen. FOMO is een heel sterk aspect van hypes, en daar vormt zich een hele religie omheen want iedereen wil graag horen dat ze niet verkeerd geinvesteerd hebben. Dus dan krijg je die hele circlejerk bro omgeving eromheen die elkaar lopen op te jutten hoe geweldig het wel niet gaat worden en dure lezingen gaan volgen van de guru die de hoogste bergen belooft. In de praktijk is het altijd veel minder en/of duurt het veel langer. En als het een tijdje niet als een raket stijgt, is het meteen een flop (denk aan de dotcom crash) omdat het de torenhoge verwachtingen niet stantepede waar kan maken. Als je de beperkingen aankaart dan word je al gauw afgeschoven als "je gebruikt het niet goed", in dit geval bijvoorbeeld "dan prompt je niet goed". Een beetje het "you're holding it wrong" van Apple vroeger.

Ik heb meer iets van: Laat eerst maar eens zien wat het nu kan, in beloften van wat het later allemaal zal gaan kunnen heb ik weinig interesse. Ik werk niet zoveel met programmeren maar ik vind de copilot in MS Office nog heel erg beperkt en zeer inconsequent in elk geval.

Niettemin ben ik wel met de technieken bezig, op mijn werk met de copilot spullen want dat moet daar, en thuis meer met self-hosted boel omdat ik nogal cloud-wantrouwig ben. Maar mijn emailtjes typ ik gewoon zelf want het is meer werk om copilot uit te leggen wat hij moet gaan schrijven dan het gewoon even zelf te doen. Maar het heeft nog een flink aantal stappen te gaan, ook in de cloud. Wat cloud betreft heb ik API accounts bij de meeste groten, ik vind perplexity nog het best momenteel, met name de 'special sauce' die ze eroverheen gooien is heel goed want hun modellen zijn gewoon die van de bekende spelers.

[Reactie gewijzigd door Llopigat op 1 mei 2025 20:16]

Dit zijn agents in VSCode die met een enkele prompt vrij complexe taken uit kunnen voeren. De tooling begrijpt de context van een groter project een zoekt al zelf referenties in de codebase op. Test ook de code die het schrijft. Hele klasses worden eenvoudig gerefactort en voor nieuwe klasses kan het een hele goede werkende voorzet geven.
Dat klinkt leuk op papier maar het probleem waar ik met copilot (vandaag, niet vorig jaar) tegen aan loop is niet dat het te weinig handelingen kan uitvoeren, het is dat wanneer je iets complex vraagt ze over het algemeen kwalitatief slecht werk leveren.

Dat een AI Agent een 13 in een dozijn webapp in VScode kan generen is leuk om te zien en indrukwekkend vanuit een technologisch perspectief maar buiten een beetje aanpielen met hobbyprojecten voor mij niet bijzonder bruikbaar.

AI zal vast en zeker nog wel beter gaan worden in de toekomst maar dit soort headlines klinken vooral als enigszins misleidende claims van bedrijven die de hype machine aan de gang willen houden.
Heb ook dezelfde ervaring. Laat je een AI agent in een schone en relatief eenvoudige applicatie aan de slag gaan dan komen er heel snel hele mooie dingen in beekd, Echter laat ik diezelfde agents in onze vrij complexe codebase aan de slag gaan dan is het huilen met de pet op. Ik probeer het maandelijkse met alle bekende ai agents en de afgelopen periode wordt er gewoon null vooruitgang geboekt.

En dan vraag ik dus eenvoudige dingen zoals deze applicatie pagina moet meer mobile friendly gemaakt worden.

Waar werkt het voor mij goed als assistent bij het schrijven van sommige dingen waar ik weinig mee heb. En het genereren van eenvoudige bijna boiler plate unit tests. Maar ook daar valt het om zodra je echt complexere processen wilt gaan testen.
Bekijk dit filmpje (helaas een clickbait titel, maar toch de moeite) als je dit in actie wil zien. YouTube: VS Code Agent Mode Just Changed Everything
Eeh, je begrijpt hoop ik dat dit een promotiekanaal van microsoft is?
Copilot staat al op achterstand met tools zoals roo, cline en tailwind.
Tailwind? Dat is bij mij een 'utility-first' CSS framework.
Oeps, bedoelde windsurf, aangepast
Lees: door Microsoft developers met Visual Studio met copilot eraan die boilerplate genereert.
Denk dat het leeuwendeel van de code die genereert is unit tests zijn. Daar is VS Copilot in mijn ervaring best goed in namelijk.
Als ze auto-complete ook meetellen dan kun je aardig richting die 30% gaan ja ;)
Genereer zo nu en dan zowel unit als functionele tests, al valt het me daarbij vaak op dat de tests vaak zo gegenereerd worden dat ze slagen al klopt de code welke het test niet 8)7
Copilot is best OK in het verzinnen van een basis opzet voor unit testen, maar als het een beetje complex word is mijn ervaring dat die het snel laat afweten. Extension methods in C# zijn een groot struikelblok bij het genereren van mocks, naast nog wat andere niet bestaande functies die gebruikt worden.

Code completion is beter maar dat is meestal ook niet de meest complexe code.
Precies dit dus, bij mij op werk gebruiken we het inmiddels ook allemaal, want ja je kan niet ontkennen dat het vaak gewoon een snelle start geeft. Maar dat is ook wat het is, het is een start punt voor kleine stukjes code, of uiteindelijk stukjes code optimaliseren. Maar volledige code die echt alles aan elkaar knoopt is nog heel ver te zoeken.
En zelfs als jij stukken code genereert van AI moet je eigenlijk in 99% van de gevallen nog steeds wel kunnen begrijpen en aanpassen wat die code daadwerkelijk doet voordat je deze kan overnemen. Ja de letters en cijfers zijn misschien door de AI geschreven en niet meer vanaf het toetsenbord ingvoerd, maar wanneer spreek je nou echt van we gebruiken AI code als vervolgens nog steeds een mens gewoon er naar moet kijken aanpassen etc.
Je kan het dan eerder zien als een andere invoer methode dan echt AI code in gebruik nemen. Bedoel stel je gebruikt een (niet dat je dat ooit zou doen) swipe touchpad keyboard om code te maken waarin je gewoon wat over het scherm veegt. Gebruik je dan swipe generated code? Bedoel is een prompt geven en dit laten vertalen naar code welke je zelf implementeerd echt AI generated code gebruiken? Het staat mijn inziens dichterbij gewoon een snellere invoer methode, dan zeggen ja we laten AI onze code schrijven ofzo.
Mooi verwoord, dit is hoe ik het ook zie en ook mijn ervaring.
Ook, de developers van Microsoft worden sinds een maand of twee o.a. beoordeeld op basis van hoeveel ze gebruik maken van copilot. Intern wordt het gebruik letterlijk geforceerd. De cijfers in deze claim zijn het resultaat.
Ja dat probeerden ze bij ons op het werk ook (de consultants van microsoft). Dat we uitgebreide analyses moesten maken van wie het niet genoeg gebruikt, en die dan extra training moet krijgen. Fuck dat. Als mensen geen behoefte hebben aan een tool, dan gebruiken ze hem niet. Dan halen we de license gewoon terug na een paar weken. Maarja dan verkopen ze daar minder van, daar zit 'm natuurlijk de kneep.

[Reactie gewijzigd door Llopigat op 1 mei 2025 19:35]

Ik word ook moe van al die wilde claims over AI. Laatst een kop in de media dat AI een eeuwen oud wiskundig probleem had opgelost. Als je er meer over leest is AI in feite alleen als tool ingezet door een paar wiskundigen. Op dat niveau zelfstandig redeneren kan AI nog lang niet, dus complexe algoritmen hoef je van AI ook nog niet te verwachten.
Ja ik gebruik ook AI om code problemen op te lossen maar loop er nog geregeld tegenaan dat ChatGPT, Gemeni, etc met oude zooi oplossing komt aanzetten omdat het model getraind is tot datum X en de wereld daarna niet heeft stil gestaan. AI is zeker handig maar gaat voorlopig echt niet uit zichzelf een compleet complex programma in elkaar zetten.
Ik herken ook dat er foute code gegenereerd wordt. Deze de syntaxis is correct, maar kan niet werken. Bijv aanmaken van record kan niet met status inactief. Dat moet eerst actief en daarna omzetten naar inactief.
Na copiloot hierop te attenderen, komt de volgende gegenereerde code met een al lang deprecated request. Hierop gewezen en ontstaat uiteindelijk de juiste code. Zucht.
Het scheelde wel wat type werk 😂
Dit komt dus door al die oude en achterhaalde informatie die op internet blijft rondzwerven.
Herkenbaar. Ik gebruik AI vooral om voorzetjes te geven, maar kom ook dan nog regelmatig fouten tegen. En je moet niet denken dat AI deze zelf kan corrigeren. Ja, hij doet wel een poging, maar begrijpen doet hij het niet. Als hij het echt begreep was het namelijk wel in één keer goed gegaan. Als je AI vraagt een correctie toe te passen kom je waarschijnlijk in een oneindige loop terecht waarbij AI nieuwe fouten gaat introduceren bij het corrigeren van voorgestelde onjuistheden. En bij het corrigeren van een nieuwe fout introduceert hij doodleuk weer de voorgaande fout omdat hij vergeten was dat die al gecorrigeerd was.

AI kan wat tik- en zoekwerk schelen maar onderaan de streep is het vooral belangrijk dat jij zelf weet waar het over gaat en wat er gebeurt. Anders kom je bedrogen uit.
Die zelfde ervaring heb ik ook. Als je het gebruikt op onderwerpen of coding die je zelf ook niet helemaal begrijpt dan kun je debuggen tot je een ons weegt.

Voor Autocad is het handig om LISP routines mee te schrijven. Hoef je vaak niet zoveel bij na te denken. Als het werkt dan werkt het. Maar er zit in de basis 0 errorhandling in of als je het niet precies uitvoert zoals het op die ene manier werkt, werkt het dus vaak niet meer. En er zijn heel veel dingen om af te vangen.
Het verzint ook vaak functies die helemaal niet bestaan in de gebruikte taal of niet van toepassing zijn op de objecten waar je het op wilt gebruiken.

Na 20 itteraties heb ik dan eindelijk iets wat voldoende werkt, waarvan ik eigenlijk hoopte dat het na 2-5 keer wel geregeld was.

Als je dan zelf weinig van de code begrijpt kun je de AI er ook niet op attenderen waar mogelijk de fout ligt. En als ik het zelf dan ook niet helemaal snap vraag ik om debugfeatures toe te voegen zodat in de foutopsporing sneller is te vinden waar de fout ligt. Onder aan de streep kom je er wel.

Ondertussen probeer ik ook een hele webapplicatie te maken met behulp van chatgpt, en daar moet je ook veel in sturen. Het gaat niet efficiënt om met CSS code, niet objecten met de zelfde opmaak scharen onder dat ene stukje CSS maar gewoon een nieuwe class aanmaken met de zelfde opmaak.
Steeds de zelfde fout maken met Z-layers en floats. En dat zijn nog maar wat basisdingen.

Als ik een stuk voorbeeldcode heb die goed werkt kan die daar over het algemeen wel weer een redelijke implementatie van maken, maar als je het zelf de de vrije hand geeft kunnen er nog wel eens verrassingen uit komen.
Toevallig apt-key dat deprecated is?
Bij mij gaan de AI's de fout in zoals ChatGPT, Claude, Gemini en copilot. Ook al geef je het van te voren aan, blijft die fout maken.
Nee, sorry is iets anders
Dan is het extra mooi om te lezen dat repo's vervuild worden met AI gegenereerde code, zo dat de kans groot is dat die daar weer op getraind word.

Ik moet sowieso nog zien dat AI daadwerkelijk een oplossing voor mij genereerd die daadwerkelijk is wat ik zoek en niet de oplossing die ook op stackoverflow staat.

En stackoverflow bloed zo dood, en alle repo's waar AI op getraind word zal steeds meer AI code bevatten om een mooie feedbackloop te creëren.
Ik wacht eigenlijk op het moment dat de zogenaamde progress van AI stagneert. Eens internet vol staat met AI gegeneerde content, in veel gevallen dus rommel, valt er nog weinig te verbeteren aan de modellen lijkt mij. Zie je nu al zoals je aangeeft dat stackoverflow dood bloed. Niet dat alle commenst daarop altijd even nuttig waren of zijn, maar het had wel in veel gevallen toegevoegde waarde. Eens je die comments dus niet meer hebt, vraag ik me dus af hoe AI zichzelf nog gaat verbeteren.

Echt top notch code moet je er vind ik niet van verwachten. Code valt mijn inziens in twee categorieën:
* Boilerplate => perfect te genereren met AI, maar daar had je eigenlijk ook in de meeste gevallen ale lang tooling voor. Elke IDE kan tegenwoordig wel getters en setters generaten. Of bindings waarvoor je generators hebt, enz...

* Zeer specifieke performante code => veel te specifiek om een globaal programming model op los te laten en daar dan ook nog eens met de perfecte code voor je use case af te komen.

Laat ons nog een derde categorie toevoegen, quick start en tutorial achtige dingen. Daar zal AI sterk in zijn/worden. Ik gok er persoonlijk op dat AI op vlak van programmeren gaat blijven steken op een hulpmiddel en de tools die er al waren vervangen omdat het dynamischer is.

[Reactie gewijzigd door Powerblast op 1 mei 2025 13:17]

Ik lees vaak vergelijkbare termen als dit wanneer het over AI gaat en heb dan geen idee waar het over gaat maar het klinkt zo interessant! Vraag trouwens ook niet om uitleg, ben blij dat ik niet zulk werk heb en "gewoon" met een vrachtwagen rijd voor mijn werk. Die trouwens ook wel met AI geprogrammeerd lijken en anders door ontwikkelaars met een hekel aan chauffeurs. Ik heb bijvoorbeeld een appje op het externe scherm van mijn Volvo met "Aslasatindicator" ipv "Aslastindicator". En overal notificaties voor de hele werkdag door die 9 van de 10 eigenlijk compleet overbodig zijn.
Ik gebruik het heel basic, vooral om geen hele API naslagwerken te hoeven doorspitten. Dus zoiets als ‘voorziet framework X in de mogelijkheid om Y te doen’. Gaat net wat sneller dan Googlen, al komt er zelfs dan vaak onzin uit. Als iets niet direct mogelijkheid is, komt het systeem met alternatieven die vaak incorrect en soms ronduit hallucinant zijn.
Ik heb vaak dat chatGPT GraphQL fields verzint. Het ziet er dan heel logisch uit en je vraagt je dan af waarom het niet geïmplementeerd is want wat chatGPT als oplossing biedt zou een very nice to have zijn. Maar dan probeer je het uit en dan blijkt dit niet te bestaan. Vooral vaak bij Shopify gehad.
exact dit, heel irritant ook bij snel evoluerende 'nieuwe' talen zoals Julia, waar het soms met inmiddels niet meer werkende code komt. (iets uit versie 1.3 ofzo)
Dit klinkt bij mij heel vreemd in de oren. AI is niet eens in staat om te rekenen, tenzij de berekening en het antwoord in de LLM staat.

[Reactie gewijzigd door enetrati op 1 mei 2025 22:10]

Ja dit is het effect van de LLM als een god te zien die alles gaat opleveren. Een LLM is goed in taalbewerking, voor berekeningen heb je hele andere modellen. Maar die zijn niet zo hip bij de consument want die kunnen je niet vertellen dat je zo goed bezig bent.
AI moet je ook gewoon als hulp tool zien.
Het is een slimmere zoekmachine, niet een develloper.
Inderdaad. De claim van microsoft is een beetje sensationeel.

Voor mensen die niks met programmeren hebben: Dit percentage is nog redelijk laag. Bij heel veel programmeertalen heb je heel erg veel kleine stukken code die niets functioneel interessants doet, maar wel benodigd is en vaak herhaald wordt. Ik denk dat het eerder richting de 40-50% gaat als elke micorosoft dev continu copilot zou gebruiken.

[Reactie gewijzigd door youridv1 op 1 mei 2025 08:51]

Wat kan er misgaan....................
Weinig tot nu toe. Tenminste als die bedrijven vergelijkbare regels toepassen als bij mijn werkgever.

Zoals @ThaStealth hier ook al aangeeft, wordt bijvoorbeeld Copilot door ontwikkelaars gebruikt binnen hun ontwikkelgeving voor "boilerplate" code. Coplilot genereert dan bepaalde code in opdracht vam de ontwikkelaar, zoals bijvoorbeeld unit tests en andere code repetitive code, wat al een aanzienlijk deel van de totale hoeveelheid code kan zijn. Ik schat dat we in ons geval ook al snel richting die 30 procent gegeneerde code gaan.

Als ontwikkelaar ben je nog altijd verantwoordelijk voor de code die jij met je "AI assistent" oplevert. Bij ons vinden er binnen de teams dan ook nog steeds pull request reviews plaats in het kader van het vier-ogen-principe en wordt de code ook bij elke wijziging getest door test engineers.
Hoe gaat het eigenlijk met het opleiden van nieuwe mensen nu? Dat vraag ik mij al een tijdje af.

Verliezen mensen hiermee niet langzaamaan de kunst van het programmeren en debuggen? Je moet immers het werk goed kunnen als je wil controleren of de uitkomst van een AI degelijk is.

Repeteren is juist goed voor het cementeren van kennis.
Zoals gezegd gaat het bij gegenereerde code vooral om randzaken. De applicatielogica wordt nog altijd door de ontwikkelaars zelf geprogrammeerd, met de AI assistent als hulpje.

Bij ons bestaan de teams uit een mix van "senior", "medior" en "junior" ontwikkelaars. Dat is niet voor niets en was al zo voordat de AI assistenten opkwamen.

Wat je bij junior ontwikkelaars ziet is dat ze veel kunnen leren van de voorstellen die de AI doet om code te genereren, al hangt dat van de mentaliteit van de ontwikkelaar af. Zo is het de bedoeling dat ze begrijpen wat de code doet en waarom die zo geschreven wordt, wat vaak door een medior of senior ontwikkelaar uitgelegd kan worden als ze dat zelf nog niet kunnen. Er zijn ook junior ontwikkelaars die de AI assistent gewoon niet gebruiken omdat ze er nog niet goed mee overweg kunnen. Hoe dan ook moet je wel al een redelijk beeld hebben van wat je wilt programmeren voordat de AI je kan ondersteunen daarin.

Er kijkt altijd minstens een andere ontwikkelaar en een tester mee middels pull request reviews en dergelijke om te voorkomen dat er baggercode in de applicatie terechtkomt.

[Reactie gewijzigd door Aristo op 1 mei 2025 08:47]

Ik voorzie een enorme hoeveelheid "excel als database" applicaties in de toekomst.
Dat is inderdaad een leuk vraagstuk.
Als eerste begint het met de kwaliteit van de guide code waar de AI op getraind is. Ik verwacht dat het gros van de code geen pareltjes zijn.
Daarnaast wanneer je veel code laat genereren, kan ik me voorstellen dat je zelf ook niet leert om nette en goede code te schrijven. Wanneer dat dan ingecheckt wordt, dan wordt dit weer voor AI training gebruikt.
De vraag is dan nu... Wordt de publieke code hiermee op den duur kwalitatief beter of slechter en daarmee de AI.
Zie je al een beetje terug in de markt. De vraag naar starters neemt af, mediors/seniors zijn meer in trek.
Uiteindelijk zullen er minder mensen "doorstromen" richting medior/senior.
Hopelijk hebben we tegen die tijd genoeg progressie met LLM's gemaakt om dit op te vangen.
Mij werd in de tijd aangeleerd om zelfs zonder IDE te starten en gewoon de source code in notepad++ te typen en manueel te compilen door de compiler aan te roepen. Inderdaad vanuit het idee zoals je zegt, dat je snapt wat er eigenlijk allemaal gebeurd en wat een IDE eigenlijk uit je handen neemt.

Ik doe dat zeker niet meer dagelijks, maar ik merk wel dat in de talen waarin ik dat heb leren doen, veel beter snap wat de foutmeldingen zeggen als er weer eens iets niet compiled (door linking, includes, enz..) :).

Daar heeft bijvoorbeeld Copilot en ChatGPT het ook nog erg lastig mee. Linking, include en library reference issues oplossen. Heb voor de grap eens de exacte foutmeldingen die ik kreeg erin gesmeten van een privé projectje. Kreeg als advies om x aantal andere tools te gebruiken om het te compilen i.p.v. de library waar ik mee begonnen was.. Tja dat is natuurlijk ook geen oplossing. Daaruit zie je dat het model gewoon teruggeeft wat het al eens gevonden heeft, maar eigenlijk niet snapt wat er aan de hand is.

[Reactie gewijzigd door Powerblast op 1 mei 2025 13:43]

Misschien een filosofische vraag, maar waarom zou AI code genereren in een taal die bedoeld is zodat mensen geen assembler of machine taal hoeven te schrijven?

Als software voor 100% door AI gegenereerd zou kunnen worden, dan is het misschien efficiënter als het direct bijv. assembler genereert. Of evt IL zodat het nog wel hardware onafhankelijk is.
Omdat een mens het nog wel moet kunnen controleren.
Omdat LLMs taalmodellen zijn. Een LLM heeft het makkelijker in high level talen dan low level. LLMs hebben de ballen verstand van programmeren en kunnen niet een een AST trekken uit wat ze voor zich zien. Als ze ooit wel rechtstreeks programmas kunnen modificeren als een AST dan zijn LLM specifieke talen te overwegen.
Als software voor 100% door AI gegenereerd zou kunnen worden,
Alleen kan dit nog helemaal niet.
Daarnaast maakt die software nog genoeg fouten waardoor er alsnog een mens naar moet kijken.,
Dus aan de ene kant moet het aansluiten bij software die nog door mensen gemaakt wordt en aan de andere kant moet het door een mens kunnen worden gecontrolleerd.,.
Met een beetje geluk vindt die AI de oude code en wordt de taakbalk weer verplaatsbaar.
Als de AI echt intelligent was zou hij alle spyware er uit halen. En open source maken om het te bewijzen natuurlijk.

Oh, en hij zou instellingen niet op 3 plekken zetten, een consistente UI maken, een fatsoenlijke package manger toevoegen. :+
Dát dacht ik dus ook, de laatste wijzigingen lijken wel door AI bedacht te zijn ;-)

Zelfde als het kortere Explorer menu. Uch man.
Veel belangrijker, wat is de waarde hiervan?
30% zegt op zich niets. Ik denk dat met veel prompts en slim omgaan met een chatgpt of concullega er wel voor 90% (10% is dan prompts invoeren) een applicatie te bouwen is.
Hoeveel beter is die applicatie dan als het door menselijke developers geschreven wordt?

In het beste geval krijg je denk ik de gemiddelde van alle code input in de modellen en als daar veel bagger in zit (inclusief 10+ jaar oude code die toen prima voldeed)…

Zoals de timmerman en wetenschapper altijd zegt: meten is weten, dus totdat er cijfers komen die de code kwalificeren vind ik dit niet echt nieuws waar ik wat mee kan.

En om nog een ouderwetsche beroepsgroep aan te halen, een slager keurt niet zijn eigen vlees, dus hoe controleer je een en ander?
Geautomatiseerde testen? Die ook door AI gegenereerd worden? Hoe zit het dan met optimalisatie en een beetje vaart in de software houden, duurzaamheid door minder opslag in te nemen (1gb vervoeren en opslaan kost veel minder dan 2gb).
Code reviews kosten in het algemeen meer tijd dan schrijven ervan, dus zit er dan ook meer dan 1/3 tijd voor de menselijke developer teams in die moet aftekenen dat het goed is?

Ik denk dat ik de eenheidsworst in ieder geval vanaf hier al kan ruiken en dat die slechter is dan de HEMA-worst ;)

Edit: Ik ben al een tijdje uit het echte ontwikkelwerk, dus deze reactie is echt op basis van hoe het 7-8 jaar geleden ging

[Reactie gewijzigd door Monzo op 1 mei 2025 08:06]

Zuckerberg vertelt verder dat Meta aan een AI-model werkt dat zelfstandig toekomstige versies van de Llama-modellen van het bedrijf kan maken.
Oké dit is echt Skynet. Ai die nieuwe ai ontwerpt.
Ik ben benieuwd of men deelt hoeveel minder developers er dan nodig zijn?
Ik vind het bizar dat dat als een "flex" wordt gezien. Tuurlijk, AI kan in sommige gevallen de productiviteit verhogen en ervoor zorgen dat niet alles helemaal from scratch geschreven hoeft te worden wat veel tijdswinst kan opleveren. De hoeveelheid zegt weinig over of het ook echt goede code is, het zou me niet verbazen als hele stukken toch herschreven zullen moeten worden.

Op dit item kan niet meer gereageerd worden.