'Amazon verwacht dat ontwikkelaars veel meer code schrijven door gebruik AI'

Managers bij techgigant Amazon zijn afgelopen jaar gaan verwachten dat ontwikkelaars veel meer code opleveren dan voorheen. Zij moeten dat bereiken door AI te integreren in hun werkzaamheden. Zo moet één team met half zoveel mensen dezelfde hoeveelheid code maken.

Ontwikkelaars bij Amazon zeggen tegen The New York Times dat managers meer code verwachten per ontwikkelaar en dat zij actief sturen op het gebruik van kunstmatige intelligentie om hun output te verhogen. Zo moeten zij meer door AI gegenereerde code reviewen in plaats van zelf code schrijven.

De krant vergelijkt het werk met de transitie van handarbeid naar lopendebandwerk aan het begin van de 20e eeuw. Daarbij ging de productiviteit omhoog door elke medewerker verantwoordelijk te maken voor één element en dat zo snel mogelijk te doen, in plaats van één persoon die het hele proces van productie op zich neemt.

Amazon-ceo Andy Jassy zei vorige maand al dat de normen rond programmeren zouden veranderen en dat daardoor het werk anders wordt. "De eerste AI-workloads die worden ingezet, richten zich op productiviteit en kostenbesparing, bijvoorbeeld klantenservice, orkestratie van bedrijfsprocessen, workflow, vertaling. Dit bespaart bedrijven veel geld. Daarom worden er bij Amazon meer dan duizend AI-applicaties gebouwd, die tot doel hebben de klantervaring op het gebied van winkelen, programmeren, persoonlijke assistenten, streaming video en muziek, reclame, gezondheidszorg, lezen en huishoudelijke apparaten, om er maar een paar te noemen, betekenisvol te veranderen."

Reacties (194)

[MoonSafari]

Ik merk zelf als developer dat ik momenteel in constante tweestrijd leef op het werk. In de helft van de gevallen helpt AI mij om sneller te werken, maar in de andere helft van de gevallen zet het mij op het verkeerde been.
Het zelf kunnen controleren en begrijpen van code blijft een essentieel onderdeel van programmeren. Dat is iets wat steeds minder gemeengoed wordt onder de jongere developers. Puristen zullen zeggen dat je moet snappen hoe de 0-en en 1-en werken en dat is deels waar. In de meeste gevallen gaat het goed en kun je ergens wel (online) het antwoord vinden, maar bij complexere gevallen zul je toch terug moeten vallen op de basis programmeer- en computerkennis.

[freektech]

Een hele codebase die niet de jouwe is controleren op bugs of een bug eruit halen, is echt een mega taak. Vaak is het helemaal opnieuw schrijven van de code sneller om het probleem op te lossen.
Ik merk dat zelfs met mijn eigen code, soms is er geen touw meer aan vast te knopen en moet je gewoon opnieuw beginnen.

[rvt1]

Ik merk dat zelfs met mijn eigen code, soms is er geen touw meer aan vast te knopen en moet je gewoon opnieuw beginnen.

Als dat zo is, dan heb je misschien een te kort aan unit/it testen...

Het komt bij ons zelden of nooit voor dat we iets opnieuw schrijven met als reden dat we het zelf niet meer begrijpen. Wat nog wel eens voorkomt is dat we van framework A naar framework B overstappen, dan hebben we nog wel eens een re-write, maar zelf dan ook vaak delen van logica, niet altijd business layer.

[Wraldpyk]

Dit is meer een architecture probleem dan een unit test probleem. Als je je code goed organiseert heb je geen rewrites nodig. Unit tests zijn ook helemaal niet nodig voor code te begrijpen, dat zorgt er alleen maar voor dat de code doet waarop je 'm test (niet waarvoor je 'm geschreven hebt).

[108rogar]

Unittests doen meer dan alleen testen. Als je test-driven werkt, helpen unittest ook om die goed georganiseerde code te bereiken waar je het over hebt. Want je wordt gedwongen om na te denken wat je unit precies moet doen en nodig heeft (tenzij je alles gaan mocken).

[Wraldpyk]

Zowel met als zonder tests kun je gigantische bestanden met slechte naamgeving, callback-hell en ongeorganiseerde structuur, maar ook netjes opgesplitste, georganiseerde code hebben. Het enige wat tests doen is zorgen dat je je dependencies in orde hebt in dat geval.

[OruBLMsFrl]

Mwa, goede sets hebben van unit en integratie tests, maar tegelijk een callback-hell? Lijkt me een heel onwaarschijnlijke combinatie, en dan hooguit iets dat iemand die alleen werkt overkomt, erg zeldzaam in (online) teamverband.
Net zo voor wat andere dingen die je noemt zoals slechte naamgeving, ongeorganiseerde structuur. Technisch kunnen die dingen bestaan ook als er unit tests aanwezig zijn, maar in praktijk zijn het dan eerder een paar versnipperde unit tests in mijn ervaring, dan iets dat daadwerkelijk lijkt op test driven development en > 90% code coverage. Dat vraagt om een bepaalde (project)mentaliteit welke ook op die andere aspecten van het ontwikkelen werkt.

[Bart.net]

Het mooie van AI is dat je het ook kan gebruiken om comments te schrijven die de code uitlegt. Ook kan je het vragen een bug op te lossen: "ik krijg deze output, hoe komt dat", en mee te denken als dat ook niet lukt. AI heeft mij meer geholpen bugs op te lossen dan ze te maken. Maar ik ben het er wel mee eens dat je code moet kunnen begrijpen om met behulp van AI te programmeren.

[Tassadar32]

Als code comments nodig heeft om begrijpbaar te zijn is het vaak beter om de code begrijpbaar te maken door te herschrijven of zaken naar functies te verplaatsen. Ook het renamen van functies en variabelen kan een groot verschil maken voor de leesbaarheid.

[sjakie66]

Echter, als je goed commentaar plaatst op de juiste plekken, scheelt dat veel tijd. In plaats van te analyseren wat iets doet, wordt je geholpen door degene die de code ooit heeft geschreven.
Dat een stuk code zonder commentaar uiteindelijk te doorgronden is, snap ik, maar met goed commentaar scheelt echt tijd.

[JvpCpp]

Commentaar wordt gezien als een code smell. Over het algemeen is het zo dat wanneer code commentaar nodig heeft om het makkelijk te kunnen begrijpen is het waarschijnlijk slecht geschreven code.
Alleen in uitzonderlijke gevallen wordt commentaar gezien als nuttig.

[krosis]

Comments plaats je als er een bijzondere reden is *waarom* iets gedaan wordt, comments die uitleggen *wat* er gedaan wordt zijn een code smell.

[JvpCpp]

Dat is precies wat ik bedoel met de uitzonderlijke gevallen.
Maar wanner dit in de code base geen uitzondering is, maar regel, is dat alsnog een code smell.

[michelr]

TIL code smell Code met een niet-evidente bedoeling voorzien van een toelichting is niks mis mee; toelichtingen op dat je een rare workaround moet doen omdat er anders elders een probleem optreedt (noem maar wat), helemaal mee eens.

[JvpCpp]

Dat zijn inderaad de uitzonderlijke gevallen die ik bedoel.

[YopY]

De comments bij een rare workaround zijn goed, maar het belangrijkste daarbij is het "waarom" - precies wat je omschrijft.

[YopY]

Het eerste wat commentaar moet doen is het "waarom" uitleggen, wat het doel is van een stuk code. Als je code vervolgens nog comments nodig heeft om specifieke details uit te leggen is prima. Zolang je maar niet basiszaken zoals "add foo to bar" ofzo gaat beschrijven.

[hoeksmarp]

Ik werk zelf niet in development, maar in het onderwijs en het aantal keren dat AI studenten op het verkeerde been zet bij uitleg van code/debuggen is echt schrikbarend groot (ik gok tientallen procenten voor de ingewikkeldere taken).

[Patrick_Wolf]

Dan komt natuurlijk de vervolg vraag. Welke 'AI' gebruiken deze studenten, want de resultaten daarvan variëren nogal.

[hoeksmarp]

Het meeste wordt volgens mij de meest recente gratis versie van ChatGPT gebruikt.

[YopY]

Ze lopen gelukkig zelf tegen de lamp (neem ik aan), fout antwoord is immers een slecht cijfer. Maar ik krijg wel sterk het gevoel dat mensen AI sneller vertrouwen dan bijvoorbeeld een antwoord op StackOverflow.

[hoeksmarp]

Als ze niet tegen de lamp zouden lopen, zou ik het hier niet kunnen schrijven

[smiba]

Net als dat AI compleet verkeerde antwoorden kan geven, annoteert AI ook vaak genoeg best wel onzin.

Niet heel behulpzaam dus..

[david-v]

Ik merk dat zelfs met mijn eigen code, soms is er geen touw meer aan vast te knopen en moet je gewoon opnieuw beginnen.

In copilot: "can you rewrite this function to make it better readable and more sustainable?" Doet al wonderen.

Maar het gebruik van een software analyse tool zoals sonarqube voorkomt vaak dat je code na verloop van tijd onleesbaar wordt door de lengte of complexiteit van je functie.

Achteraf hele stukken code (lees meerdere functies en classes) herschrijven is inderdaad wat lastiger. Opnieuw netjes doen is dan vaak beter. Maar daarna wel software quality toevoegen aan je build proces, dan blijft de code in principe ook wel goed te onderhouden

[YopY]

In copilot: "can you rewrite this function to make it better readable and more sustainable?" Doet al wonderen.

Tot op zekere hoogte; ik had een serie if/else, werkte prima en beschreef precies wat er wanneer moest gebruiken, maar het was wel tien regels lang en vier of vijf verschillende voorwaarden. Ik vroeg Copilot of het beter / compacter kon, misschien dat die nog dingen zag die ik niet zag, maar het enige wat die deed was een if / else omzetten naar een ternary. Doorvragen ging het naar een switch/case. Zowel een ternary als switch/case zijn IMO minder leesbaar (in die context) dan een gewone set if / else, maar de LLM bleef het proberen ipv zeggen "nee hoor dit is prima, houwe zo".

[Die_ene_gast]

Ik merk dat zelfs met mijn eigen code, soms is er geen touw meer aan vast te knopen en moet je gewoon opnieuw beginnen.

Dat heb ik alleen met mijn code van toen ik net leerde programmeren.

[michelr]

Ik snap van mijn C64 assembler sources ook weinig meer, maar dat heeft een andere oorzaak.
Die kan ChatGPT/Copilot trouwens wel redelijk interpreteren.

[xorpd]

Je moet voor de grap maar eens code van jezelf van 10 jaar geleden bekijken. Meestal is het of dit is briljant, of wat gebruikte ik toen voor drugs. En voortschrijdend inzicht natuurlijk.

[Die_ene_gast]

Ik denk dat ik de afgelopen 10 jaar niet echt veranderd bent qua coderen, maar ik snap je punt

[YopY]

Ik heb laatst wat code van mijn stage gezien, de "wat gebruikte ik toen voor drugs" zat hem vooral in het blok comments / documentatie bij een functie van 3 regels,

[YopY]

Maar helemaal opnieuw schrijven is alleen een optie als je daar het budget en/of de tijd voor hebt; in het bedrijfsleven gebeurt dit ook met enige regelmaat, maar de beslissing om dat te doen heeft veel afwegingen.

Als ervaren developer moet je die afweging kunnen maken, maar ook het probleem met "grote codebases" tolereren - andermans code begrijpen is immers ook onderdeel van het takenpakket.

[Nap]

Grappig dat je dat zegt, had zelf dat idee ook toen ik begon met coden, maar het is vaak een enorm slecht idee. Helemaal opnieuw beginnen kost veel tijd, hoog risico op introduceren oude bugs, en aangezien je zegt dat je het ook hebt bij code die je zelf schrijft, lijkt het me eerder zaak om beter te documenteren en te commenten.

Geloof ook niet dat het netto minder tijd kost.

https://codeopinion.com/never-rewrite-code/
https://leaddev.com/softw...you-shouldnt-rewrite-code

[JvpCpp]

Dat is alleen sneller wanneer de code van zeer slechte kwaliteit is. Code moet altijd zodanig geschreven zijn dat het eenvoudig te begrijpen is. Wanneer dat niet het geval is, zou het nooit door een review mogen komen.

[xorpd]

Dat is iets wat meer mensen zouden moeten begrijpen. Er zijn legio mensen namelijk die denken dat complexiteit een teken van goede code is, integendeel. Keep it small and simple.

[YopY]

Het gevaar dat veel (medior?) developers hebben is dat "gewoon doen wat gebeuren moet" te saai wordt. Veel back-end is bijvoorbeeld recht toe, recht aan CRUD; databaseje, wat business logica, REST/JSON API, klaar.

Maar dat is saai om gewoon uit te schrijven dus gaan mensen naar creatieve oplossingen zoeken; query generators, ORMs, code generators, frameworks, programmeertalen, etc. En dat voor consultancy tarieven.

Schrijf gewoon die code en ga door met je leven, jezelf en je opvolgers zullen je bedanken.

[phiemstra]

En jij hebt de ervaring om te beoordelen wat de AI als suggestie geeft. Hoe krijg je de ervaring als je nooit zonder AI programmeert?

[Powerblast]

Je slaat de nagel op de kop, daar maak ik me dus ook zorgen over. De nieuwe generatie lijkt om het even kort door de bocht te stellen met de AI prompt te leren werken maar echt code snappen zit er bij de start niet in. Ja code review hoor ik dan dikwijls. Ok, maar die generatie gaat er dus stilaan over de jaren dus uit. Wie dan op termijn de AI code moet gaan reviewen of verbeteren is mij een raadsel. Dan kom je dus in het tijdperk dat code volledig door AI geschreven zal zijn. Wie dan verantwoordelijk is als er wat foutgaat, geen idee. Want "de programmeur" snapt er in ieder geval niks meer van.

Ik hoop in ieder geval dat het zo geen vaart zal lopen

[Reactie gewijzigd door Powerblast op 26 mei 2025 21:29]

[Tassadar32]

Ik zie nu al in het veld dat Seniors liever AI gebruiken dan samenwerken met een junior. Is veel goedkoper en de AI heeft vaak minder handholding nodig. Voor juniors is het op dit moment ontzettend moeilijk om ervaring op te doen. En inderdaad ook zat juniors die zelf veel te weinig code schrijven en vastlopen als de AI er niet meer uit komt.

[Mellow Jack]

In veel gevallen zijn programmeurs mensen die zich bezig houden met het aan elkaar lijmen van libraries. Hoeveel % vd wereldwijde programmeurs begrijpt echt hoe zijn of haar code werkt?

[phiemstra]

Beetje platte blik op software engineering. Ik werk met veel getalenteerde studenten en collega's die prima weten wat ze doen en waarom.

[Henk1827]

Een beetje plat, maar ook wel pijnlijk waar. De Javascriptgeneratie weet niet meer hoe een CPU werkt. Ik werk soms ook met een paar “rockstars”, maar de meesten die ik tegenkom in het bedrijfsleven weten net genoeg.

[Munchkin]

Nu noem je ook wel een club waarvan de ceo ooit geroepen heeft dat als de toko niet jaarlijks net 20% groeit dat het voor hem niet meer interessant is. De focus lijkt voornamelijk omzet gedreven, ook voor de programmeurs zelf. Ik heb van horen zeggen begrepen dat de kwaliteit van de programmeurs daar op zijn best wisselend is.

[bzzzt]

De term "rockstar" duidt op programmeurs die echt weten wat ze aan het doen zijn, niet alleen op een Nederlandse detacheerder die dat als naam gekozen heeft
Zie bv https://www.hanselman.com...f-the-rockstar-programmer

[Glewellyn]

Of op programmeurs die in de alternatieve programmeertaal Rockstar programmeren: https://codewithrockstar.com/

[Munchkin]

Ah, die term kende ik nog niet (live and learn!), maar vergelijkbaar met 10x developers dus.

[nallath]

Yeah en beide zijn nogal onzin.

[bzzzt]

Het verhaal komt natuurlijk wel ergens vandaan. Er zijn wel degelijk flinke productiviteitsverschillen tussen programmeurs en vrijwel iedereen in de business kent wel mensen die buitengewoon productief zijn. Maar veel code is niet hetzelfde als goede code en beide zeggen niets over hoe de klant daarmee geholpen is.

[nallath]

Het verhaal komt vooral van recruiters vandaan om klanten te overtuigen dat hun kandidaat het beste ding sinds gesneden brood is.

Tuurlijk zijn er mensen die beter zijn. Maar een programeur die 10x zo goed is? Ik ben ze nog niet tegen gekomen. Als ze al bestaan dan zijn ze zo zeldzaam dat de hele term nietszeggend is.

[bzzzt]

De term 10x is natuurlijk niet wetenschappelijk, en is 'goed' geen eendimensionale schaal. Toch heb ik genoeg "0.1x programmeurs" gezien om te geloven dat het verschil inderdaad een orde kan zijn.

[Wraldpyk]

Dat je niet weet hoe een CPU werkt betekend niet dat je niet een goede programmeur bent. Vroeger schreven ontwikkelaars letterlijk in nullen en eenen, en elke generatie verder heeft nieuwe taken weggeautomatiseert, dat de volgende generatie niet weet hoe de vorige werkte heeft geen invloed op hoe goed een programmeur is.

[Kaasrol]

Precies, zolang je het op een abstract niveau kan plaatsen is het prima. Een oude C programmeur weet misschien ook nog maar net de basis van logische schakelingen. Een elektriciën in de jaren 50 wist ook niet alles van metaalbewerking. Enzovoort.

[david-v]

De Javascriptgeneratie weet niet meer hoe een CPU werkt

Als je een opleiding volgt krijg je dat echt wel mee en moet je in assembler code het een en ander voor elkaar krijgen. Bedoel je niet mensen die geen opleiding hebben gevolgd en "programmeren" leuk vinden en als "carrière" kiezen?

Overigens ben ik al lang blij dat ik die kennis niet meer paraat heb 😅. Low Level code schrijven is echt niks voor mij.

[Tassadar32]

Maar er zijn nog zat jobs waar je embedded werkt en dus nog precies moet weten wat er op hardware niveau gebeurt.

[david-v]

Klopt, en daar verwacht ik geen JavaScript generatie "ontwikkelaars". Als high level programmeur verwacht ik niet dat je de instructieset van een CPU kent of überhaupt hoe een high level taal vertaald wordt naar de specifieke cpu instructies. Het niet (meer) weten hoe een cpu werkt is voor een high level programmeur geen ramp. Dat was mijn punt.

Ga je embedded, dan is dat uiteraard wel een vereiste, het is dan je vak om het volledig uit te pluizen.

[Tassadar32]

Mja, ik doe beide. Af en toe wat embedded, af en toe wat backend (java/kotlin) en soms wat mobile. Ook soms opdrachten waar twee van deze vakgebieden overlappen.

[phiemstra]

Er is wel een enorm verschil tussen "weet niet hoe een cpu werkt" naar "programmeurs begrijpen niet waar ze mee bezig zijn". Naar mijn mening is voor moderne talen precies weten hoe een cpu werkt niet meer nodig. Vroeger was het nodig om coredumps te kunnen lezen om te weten waarom iets niet werkte. Dat doen we ook al jaren niet meer.

[rvt1]

Ik werk aan verschillende project en kan echt goed vertellen hoe elk project precies werkt, en waarom het werkt....
Ik kan dat zeggen van de Finagle features die wij gebruiken..
En voor de prive projecten (Conspicuity) weet ik heel goed hoe verschillende protocollen werken (FANET, OGN, ADS-L, FLARM (behalve het stukje van de security, ik kan niet vertellen hoe veilig het is, alleen dat het niet veilig is..)

De meeste van de ontwikkelaars waarmee ik werk, weten het ook heel precies... Maar ook hoe andere processen werken.

[thomasv]

Heel je reactie zegt dat je geen verstand hebt van het vakgebied, en voelt extreem denigrerend aan.

[klakkie.57th]

Nou nou … wie kan er vandaag de dag nog assembler schrijven ? Ik vraag me zelfs af of dit nog onderdeel is van de opleiding ? Zelfs gewoon C begrijpen, is voor de meesten al een hele opgave.

Programmeren heb ikzelf al snel opgegeven, maar in mijn carrière heb ik toch de nodige “wizards” gezien die hele fabrieksprocessen konden draaien op enkele KB’s. Ik zie de huidige generatie het ze niet snel nadoen al dat gegoochel met pointers en geheugenadressen.


Dus ja ik betwijfel of nog meer AI wel goed is

[Reactie gewijzigd door klakkie.57th op 26 mei 2025 20:07]

[Munchkin]

De vraag is wel of je daar echt waarde mee creëert. Assembler en C zijn voor low-level zaken interessant, o.a. het creëren van een jvm, of drivers. Voor business logica creëer je gewoon veel sneller business waarde door in een hoger abstractie processen te vatten en je het omzetten daarvan overlaat aan de compiler. Ja, het is potentieel minder efficiënt (maar huidge compilers werken typisch beter dan een mens qua optimalisatie), maar aangezien resources veel goedkoper zijn geworden zitten de kosten meer in de mensen dan in de hardware. Iedereen die ooit zelf geheugen beheer heeft gedaan zal beamen dat het erg foutgevoelig is. Laat dat maar aan een algoritme over...

[Powerblast]

Er is idd ene reden waarom ze bijvoorbeeld bij Rust een heel systeem errond hebben gebouwd (borrow checker) om maar geen manueel geheugen beheer te moeten doen. Zelfs de beste C goeroe verbrand er geregeld zijn vingers aan. Ik zeg altijd, C is een leuke taal om mee te werken, maar ik zou er geen productie software mee (durven) schrijven. Je moet verdomd goed weten wat je doet, de taal op zich is niet complex, maar het gebruik zit vol met valkuilen. C++ spreken we zelfs maar even niet over

[JvpCpp]

Wat is er mis met C++. Zelf vind ik het een van de beste programeertaal die er is. Zeker na C++11. Door de toevoeging van smart pointers is het geheugenbeheer sterk vereenvoudigd. Dat je over geheugenbeheer moet nadenken zie ik juist een kracht van de taal.Je moet nu eenmaal als programeur daar bewust mee bezig zijn. Zelfs met talen als Rust en garbage collected talen. Wanneer je dat niet doet, kan dat grote gevolgen hebben op het resource gebruik en performance. Ook kennis over hoe een CPU werkt is van belang wanneer performance en resource gebruik van belang is. In het bijzonder de CPU cache. Wanneer je de code zo schrijft dat het optimaal gebruik kan maken van de CPU cache, heeft dat een grote impact op de performance.

[xorpd]

"C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, your whole leg is blown off".

Het probleem met C++ is dat het nog veel complexer is dan C. Dus niet alleen kun je kiezen uit signed/unsigned, value/reference, static/extern, const/non-const, maar nu ook virtual/static, 3 verschillende constructors, 4 smaken pointers, en dan nog de hel die templates heet. Ik snap ook wel waarom, de focus lag op snelheid, en niet op simpliciteit, zoals bij Java.

[JvpCpp]

Juist dat geeft je als programeur de mogelijkheid de juiste optie in de juiste situatie te gebruiken. De focus ligt inderdaad op veel flexibiliteit/vrijheid voor de programeur zodat je resource gebruik CPU/Memory zo laag mogelijk kunt houden.
Die vrijheid/flexibiliteit heeft natuurlijk een prijs. Het vereist dat de programeur zich bewust is van welke impact bepaalde keuzes (kunnen) hebben en vereist ook een goed begrip van geheugenbeheer maar ook van zaken als multithreading. Wat basis kennis zou moeten zijn van elke programeur, maar wel heel erg vaak ontbreekt.
Daarbij vind ik zelf C++ in de basis niet complex. Een taal als Java is inderaad minder complex, maar daardoor ook minder flexibel en efficient. Talen als C# en JavaScript vind ik broken by design.

[xorpd]

Ik heb hier nog een leuke hersenbreker in C. Always true or not?

signed int value;
... // assign some value
if (value >= 0x80000000) { ... }

[JvpCpp]

Niet zo relevant, aangezien dit code is wat nooit door een review zou mogen komen. Zowiezo zou portable code niet mogen vertrouwen op de size van int, afhankelijk van de compiler kan daar verschil in zitten.
Ook zal de compiler klagen over het feit dat je unsigned met signed int aan het vergelijken bent.Kortom code die nooit in een code base terecht zou mogen komen.

[xorpd]

De compiler klaagt dus niet, aangezien het een literal betreft (je wil niet weten wat er gebeurt als dat wel zo zou zijn) en volgt vervolgens de normale promotieregels, in dit geval dus signed -> unsigned.

Maar je hebt gelijk, deze code kan en moet beter.

[Reactie gewijzigd door xorpd op 27 mei 2025 13:09]

[Powerblast]

Niks mis mee, verre van zelfs. Maar het is wel zo vind ik dat het nog fout gevoeliger is dan C. C++ impliceert nog meer dan C dat je weet wat de regel code doet (ook achter de schermen) en "expressed" het niet via de code die er staat. Ik vind bijvoorbeeld het bij C en C++ niet altijd duidelijk of een functie een fout kan throwen en dewelke dan en of ik verwacht wordt om memory vrij te geven of dat de API het voor mij doet.

C++ geeft je volledige vrijheid, zelfde als C. Maar verwacht wel dat je volledig weet wat je doet om het optimaal te schrijven. CPU cache trucjes moet je in bijvoorbeeld Java zelfs niet proberen, werkt gewoon niet. De taal heeft er geen ondersteuning voor.

[Reactie gewijzigd door Powerblast op 27 mei 2025 20:35]

[JvpCpp]

C++ geeft je inderdaad de volledige vrijheid. Maar geeft je zeker ook voldoende mogelijkheden om aan te geven of je verwacht wordt om memory vrij te geven of niet. Wanneer dat niet duidelijk is in bv de class API, is het geen goed geschreven code en zou dus nooit in een code base terecht mogen komen. In C++ heb je sinds C++11 smart pointer classes zitten die het kristal helder maken. Code behoord dan ook dit te gebruiken voor dit doel en raw pointer zoveel mogelijk te vermijden. Dus C++ is op dit vlak veel beter dan C.
Rekening houden met CPU cache werkt zeer goed in C++ en kan flinke performance verbeteringen geven wanneer goed toegepast. Inderdaad in talen als Java heb je daar veel minder controle over. Dat maakt C++ een stuk krachtiger.
Dat C++ verwacht dat je volledig moet weten wat je doet en wat het effect van bepaalde keuzes is, zie ik juist als iets positiefs. Als programeur behoor je dit te weten, ook bij gebruik van andere talen.

[bzzzt]

Assembler? Overbodige luxe, heb op de opleiding nog met een hex keypad opcodes in moeten kloppen
Maar gegoochel op byte nivo doe je alleen als het business winst oplevert. Er is helemaal niets mis met het gebruiken van een 'logge' runtime of taal als je daarmee sneller kan ontwikkelen of meer developers kan vinden ook al weten ze misschien iets minder van de bytes.
De echte vraag is waarom zoveel "programmeurs" tegenwoordig helemaal niet nieuwsgierig lijken te zijn naar hoe hun spullen nou eigenlijk werken. In essentie zijn veel computer internals niet zo heel ingewikkeld, maar het vraagt wel om een bepaalde op onderzoek gerichte mindset.

[klakkie.57th]

Low-level code mag absoluut geen doel op zich zijn, maar je wil toch begrijpen hoe iets werkt. Wat met calibratie van sensoren die de juiste hoeveelheid straling moet afleveren op de millimeter juist … soms heb ik de indruk dat iedereen in FINTECH werkt en vergeet dat er zoveel meer is.

[Reactie gewijzigd door klakkie.57th op 26 mei 2025 21:22]

[bzzzt]

Ook in fintech zie je wel hardware/OS level werk, bijvoorbeeld om op de juiste manier high availability te realiseren voor de applicaties. Daarnaast heb je nog niche gevallen als high-frequency traders waarbij iedere microseconde telt.

[Xander2]

Nou nou … wie kan er vandaag de dag nog assembler schrijven ? Ik vraag me zelfs af of dit nog onderdeel is van de opleiding ? Zelfs gewoon C begrijpen, is voor de meesten al een hele opgave.

Dit is alleen relevant als je toepassing hardware gericht is, ik kan ook de koppen van een harddisk niet afstellen zoals ze vroeger deden.

En assembly? Vroeger linux kernel patches geschreven allemaal in C. De matige kennis die ik heb van asm is niet meer van toepassing en compilers kunnen uitstekend optimaliseren, in veel gevallen zelfs veel beter.

Dat gegoochel met pointers/geheugen is nu voor iedereen een probleem ongeacht kunde, de codebase is enorm veel groter geworden en past niet meer op kettingpapier.

En een CPU begrijpen? De klassieke MIPS/68xxx kom ik nog wel mee weg maar een moderne SMP multicore oef.

Computers/IT/electronica is enorm veel volwassener geworden en een kwestie van op de schouders van anderen. Vroeger was het simpeler, niet beter.

Die logge webui clients komt doordat de klassieke UI kits incapabel, niet-uniform en geen onafhankelijke specificatie/implementatie hebben. Is er een nieuwe UI toolkit kun je het programma opnieuw schrijven in plaats van apart document, styling en glue code wat in dit geval javascript is.

[Mellow Jack]

Het zal misschien denigrerend voelen voor bepaalde personen. Zo is het niet perse bedoeld.

Het is naar mijn gevoel wel de realiteit. Heel weinig mensen hebben echt een gevoel hoe iets werkt. Ze leven in een framework en daarbuiten is het abracadabra. Staat los van het feit dat er zat mensen zijn met interesse naar alles daaromheen.

Dit zie je over de hele linie, van game design (engines) tot webdesign (Angular, React) en alles daartussen en omheen. Ik ontwikkel zelf ook. Maar besef me ook wel dat veel van mijn kunsten niet heel uniek zijn.

[Moortn]

Dit is wel extreem kort door de bocht. De libraries waar je het over hebt bevatten vaak een lading hulpfuncties die kunnen zorgen dat programmeurs zich voornamelijk bezig kunnen houden met de domeinlogica.

Performance is vaak geen (groot) issue, maar beheerbaarheid van grote projecten wel. Software zit daarom tjokvol met design patterns en architectuurkeuzes. Het lijkt me veel belangrijker voor de meeste programmeurs dat ze het domein, de architectuur en de flows begrijpen dan weten hoeveel cycles een bepaald for-loopje kost.

Ik vind wel dat er soms te snel een extra library wordt toegevoegd voor simpele zaken. Zeker in de front-end kan dat een een hoop ellende opleveren met het up-to-date houden van alle packages.

[YopY]

Dat is een deel van het werk, maar vervolgens moet je ook wat met die libraries doen, dwz, features bouwen. Libraries aan elkaar knopen is iets dat je aan het begin van een project doet.

[sdziscool]

Nouja zoals ze zeggen: AI van vandaag is 'the worst it will ever be from now on' dus die tweestrijd zal door de jaren heen waarschijnlijk steeds vaker aan de pro-ai kant vallen, aannement dat ze nog verbeteringen kunnen maken.

[Fourtrain]

AI van vandaag is 'the worst it will ever be from now on'

Nou dat moeten we nog gaan zien. Uit onderzoeken is gebleken dat naarmate meer AI content in je training data terecht komt dit ten koste gaat van de kwaliteit van je model. Er bestaat dus een hele kleine kans dat als we het internet genoeg vervuilen met AI content er geen schone training data meer zal zijn, AI modellen in een cyclus van training-incest terecht komen en onze toekomstige AI assistenten allemaal een Habsburg kin hebben.

[Reactie gewijzigd door Fourtrain op 27 mei 2025 00:45]

[Xerpan]

Precies.
Een analogie is het continu recyclen van plastics. Op een gegeven moment zijn alle producten vervuild met oude plastics, waarvan de kwaliteit niet kan tippen aan 'verse' producten.

[CelisC]

Ik vraag mij vooral af waar die 'AI' dan op getraind is, als het zelf code uit kan spugen.

Heeft het geleerd om alles netjes te documenteren? Om aan te geven wat de voorwaarden van de inputs moeten zijn en wat dat betekent voor de garantie van de output? Kan het automatisch algoritmes optimaliseren om de complexiteit van berekeningen te reduceren? Is het in staat zichzelf te debuggen als het eindproduct tegen bugs aanloopt? Wie mag de rommel opruimen als AI dat zelf niet kan?

En hoe gaat het in hemelsnaam taken als UX/UI op zich nemen, of blijft dat nog in handen van echte mensen?

Ik snap dat er absoluut potentieel in de technologie zit, maar het wordt door mensen getraind op waarschijnlijk relatief recent materiaal, dat vaker wel dan niet haastig is geschreven omdat er altijd druk op zit, waardoor optimalisaties uitblijven? Niet echt 'puur' trainingsmateriaal in mijn optiek, wat hoogstwaarschijnlijk te zien zal zijn in de 'kwaliteit' van het eindproduct.

Maar misschien is dat mijn eigen bias.

[laurxp]

Aangezien Amazon flink veel geld heeft gestoken in de AI-services die ze nu proberen te verkopen: "Wij van WC-eend verwachten dat mensen veel WC-eend gaan gebruiken, en zien dat WC-eend schoonmakers veel werk kan besparen. WC-eend is de toekomst van het schoonmaken."

[koelpasta]

Nadeel is dat non-coders ook meer gaan coden, maar niet in staat zijn de kwaliteit van de code in te schatten. In totaal gaan we dus gemiddeld meer slechte code krijgen. En dat is denk ik een heel groot probleem voor de toekomst.

[SprockerJock]

In de realiteit gaat het echter anders uitdraaien. Een echt programmeur vraagt redelijk wat centen voor zijn expertise. Een vibe coder een stuk minder. Economisch gezien gaan ze opteren voor vibe coders. En wat krijgen we dan? Eufy-like security flaws die super makkelijk te misbruiken zijn.

In mijn eigen tests heb ik AI al gatenkaas weten voorstellen, gekende breach vectors. Ik heb AI packages, libraries en sample projects zien voorstellen die malware bevatten. Kan je zomaar overnemen, voldoet aan je eisen. Alleen zit er een backdoortje in dat volledig toegang kan bemachtigen. Of een cryptominer. Of een data hoarder.

[Brilsmurfffje]

Is dat niet al aan de gang door de enorme wildgroei aan frameworks en libraries? Zat mensen die gehele libraries zoals Numpy importeren om simple wiskunde uit te voeren die ook prima met de veel kleinere standaard aanwezige math library kan.

Waar vroeger een simpele statische website een paar kilobyte was zitten de meeste websites nu ruim over de 10mb per pagina heen..

[koelpasta]

Is dat niet al aan de gang door de enorme wildgroei aan frameworks en libraries?

In zekere zin wel, al is het lang niet zo problematisch als gegenereerde code.
Bij AI code-genereren heb je potentieel elke keer een andere oplossing voor het probleem. Dat betekent elke keer een kans dat het op een onvoorziene manier mis kan gaan. Daarnaast kan AI stelselmatig bepaalde fouten genereren die vervolgens in heel veel code terecht kunnen komen.
Dus aan de ene kant is er meer kans dat er unieke fouten (hallucinaties) optreden omdat iedereen eigen code genereert ipv libraries gebruiken.
En aan de andere kant kan een AI een afwijking hebben waardoor het standaard bepaalde fouten maakt die vervolgens in heel veel code terecht komen.

[rboerdijk]

En dat is denk ik een heel groot probleem voor de toekomst.

Hoezo? Die managers die nu ontwikkelaars willen vervangen, staan straks bij diezelfde ontwikkelaars om de puinhoop op te ruimen. Prima toch?

[koelpasta]

Ik denk niet dat er genoeg devs zullen zijn om die puinhopen tijdig op te ruimen en tot dat het is opgeruimd zitten we met potentieel levensgevaarljjke zwakheden en andere bugs.

[YopY]

Nee ik denk het ook niet; als er productie-software uit AI komt met die gaten, lijkt het me waarschijnlijk dat de hele boel vervangen gaat worden ipv dat ze mensen inzetten om het te verbeteren.

[YopY]

Dat is in principe geen nieuw probleem; in de jaren 90 / 2000 waren er dezelfde alarmsignalen over websites die in Frontpage of Dreamweaver gemaakt waren ipv dat mensen html leerden.

En dat kwam ook redelijk uit (misschien een self-fulfilling prophecy), want er zijn voor zover ik weet geen Frontpage / Dreamweaver sites tegenwoordig. Zeker niet van bedrijven.

[koelpasta]

Bedenk dat met ai onkundige mensen allemaal hun eigen dreambeaver gaan 'schrijven'....

[Kaasrol]

Er kwam wel een hele lading bagger uit die competente developers hebben moeten fixen. Dreamweaver was als een aap met een hakbijl, vibecoding is als een aap met een machinegeweer.

[Rogers]

Als regels code belangrijk is dan laat je de AI maar alle loops unrollen
Dat dat vandaag de dag nog gebruikt wordt om performance te meten, schaamteloos.

Heb het idee dat de mensen die zeggen dat AI veel helpt met code schrijven maar code monkeys zijn of geen programmeur.
Bij mij zit het werk in te bedenken wat je moet maken en hoe, de hoeveelheid code valt meestal mee maar is zo gespecialiseerd dat AI het niet kan maken.

[Reactie gewijzigd door Rogers op 26 mei 2025 22:12]

[elmuerte]

Want meer code is beter.

Productiviteit meten in de software development is in de afgelopen 50+ jaar niet gelukt, en zal in de komende 50+ waarschijnlijk ook niet lukken. Regels code is zeer zeker geen manier om productiviteit te meten.

[Reactie gewijzigd door elmuerte op 26 mei 2025 17:23]

[jerisson]

Ik zie dit ook terug bij onze studenten. Op zich heb ik niks tegen het gebruik van AI voor code, indien correct gebruikt. Echter lijkt het eerder een belemmering te zijn dan een echte hulp. Voor de kleine schoolopdrachtjes die het 10-tallen tot 100-en keren gezien heeft werkt het prima, maar van zodra het iets moet doen dat het amper gezien heeft...

Kortgeleden nog zo een situatie gehad: student geeft aan AI gebruikt te hebben om een half-werkende oplossing voor een gespecialiseerd probleem te bekomen. De oplossing bestond uit +-1000 regels code. Na identificatie van de fout en bespreking met de student kwam de student een week later terug met code die wél werkte, slechts 150 regels was, en - schijnbaar - vrijwel zonder AI geschreven was.

Dusja, meer code is inderdaad niet noodzakelijk beter. En blijkbaar ook serieus tijdsverlies.

Bovenstaande is ook geen alleenstaand geval. Zo kregen we dit jaar ineens klachten van studenten dat ze niet genoeg tijd hadden voor een project. Dat project gaat echter al jaren mee, en de timing is nooit gewijzigd. Degene met tijdsgebrek gaven aan AI gebruikt te hebben (deze zonder problemen zijn niet aan bod gekomen, dus of zij het wel/niet gebruikt hebben is onduidelijk.)

Ik vrees dat velen het inzetten om een totale oplossing te bekomen, of om grote stukken te laten genereren. Op zich geeft het vaak iets dat er correct uitziet, maar als je er dieper op in gaat vol fouten zit. En die dingen zijn moeilijk te debuggen als je niet weet wat er staat. (En al helemaal als je basis-skills niet meer ontwikkeld worden.)

[gfhoihoi72]

Goed prompten is ook een vak apart. Je kunt een AI heel goed code laten schrijven, ook op onbekendere vlakken, maar je moet het prompt nog steeds schrijven vanuit het oogpunt van een programmeur. Tot in detail uitleggen wat je precies wilt dat de code doet, wat daar voor nodig is en hoe het integreert met je applicatie. Je moet de AI voor je laten werken, niet voor jou de keuzes laten maken. Dat is waar het bij de meeste (beginnende) ontwikkelaars nog vaak mis gaat.

[Tassadar32]

Je kan nog zo goed prompten, maar als je de output niet zelf kan verifiëren weet je niet wat er opgeleverd is. Dit is al decennia lang het probleem van managers en nog steeds niet opgelost.

[YopY]

Maar dat is ook een van de belangrijkste taken van een ontwikkelaar; niet zozeer code kloppen, maar het probleem begrijpen, de juiste vragen stellen om het probleem te begrijpen, en het probleem in stukken opdelen om de deelproblemen op te lossen.

Ik denk wel dat je zowel met als zonder AI dat stuk moet blijven doen. Als je tegen een programmeur of een AI zegt "bouw me een website over katten" kun je van alles krijgen, maar de programmeur kan je nog vragen stellen zoals "welke kleur wil je 'm hebben" en "is comic sans OK?".

Ik denk wel / zie wel gebeuren dat een volgende generatie AI tools die kant op gaan; niet klakkeloos doen wat een gebruiker vraagt, maar uitvragen tot de requirements en non-functional requrements helemaal duidelijk zijn.

[stuko]

Je zal het ongetwijfeld weten, maar developers worden niet betaald per regel (of het aantal tekens) code. Ik snap de verwachting bij Amazon prima. Waar een developer voorheen zelf de oplossing moest bedenken of met behulp van Stackoverflow of Github code moest toepassen in de eigen applicatie, kan dat nu simpeler via een AI tool. Die schrijft of herschrijft (een deel van) de code voor je. Sterker nog, ik gok dat de meeste developers het nu al toepassen. Dat Amazon dat terug verwacht te zien in het sneller opleveren van projecten lijkt me niet ongebruikelijk.

[Wolfos]

Je bent alleen 90% van de tijd geen code aan het schrijven. Het grootste deel van de tijd ben je bezig met de vraag "hoe ga ik dit aanpakken". En dat is zo uniek aan jouw codebase dat AI daar gewoonweg niet bij helpt.

[_NooT_]

Mijn ervaring is dat je juist bij het proces om tot een blauwdruk voor de aanpak te komen een AI ondersteuning veel tijd kan besparen.

Ondanks dat ik regelmatig out-of-the-box maatwerk oplossingen bedenk, is de kans ontzettend groot dat anderen ook tegen vergelijkbare situaties aan zijn gelopen en dat hier ergens online informatie over te vinden is.
De huidige AI basseert de antwoorden op hetgeen online gevonden is en kan in tegenstelling tot een Google zeer gerichte informatie aanbieden.
Kwalitatief is het niet veel beter dan wat je zelf met Google vindt, maar je kan de vraagstelling steeds specifieker maken.

Uiteindelijk moet je zelf in staat zijn om te begrijpen wat wel en niet werkt. Daar speelt inzicht, ervaring en creativiteit een grote rol en dat zal voorlopig nog wel zo blijven.
Als je 100 regels code krijgt zitten er geheid 3 tot 10 fouten in, of bevat het soms complete onzin.
Maar dan nog kan je er een hoop tijd mee besparen.

Het enige wat wel bijna foutloos gaat is code voorzien van documentatie en refactoren ahv duidelijke instructie.

Het is en blijft een tool.
Net als een IDE. Ook niet essentieel, maar toch wel verdomd handig.

Mijn productiviteit is in ieder geval aanzienlijk gestegen mag een AI assistent (binnen IDE).

[stuko]

Als je vanaf scratch in een nieuw project heb je gelijk, als je halverwege vastloopt biedt AI echt in alle gevallen een betere uitkomst dan jezelf had kunnen verzinnen in dezelfde tijd. Sterker nog, als je een beetje je best doet kan AI het zelfs voor je deployen.

[Marijnus]

Nee, ook in een bestaand project is een (goede) ontwikkelaar vooral bezig met "hoe pak ik dit aan" en "hoe past dit in de bestaande code base". En dat betekent dat je vooral code (en specificaties) aan het lezen bent, en niet aan het schrijven.

En AI kan (voorlopig) echt niet beter strategisch denken en leesbare code schrijven dan een (ervaren) ontwikkelaar.

Ps. Voor "deployen" hebben bedrijven meestal al bestaande tooling, dat is de uitdaging niet.

[Webgnome]

Het werk van een developer is gewoon veel meer dan code kloppen. Uiteindelijk gaat het om het oncijferen van de requirements, het ontleden in problemen en dat aanpakken en passen in de huidige code-base. En ja daar kan AI zeer zeker bij helpen ( gebruik het dagelijks ) en ja AI maakt daar ook grote fouten in. Is het een duizend dingen doekje? Ja, is het een GOED duizend dingen doekje? Nee

[Alfa1970]

Dat is juist, maar een developer heeft dan ook een hele andere taak dan een programmeur.
Een developer zal uit zichzelf inderdaad erg weinig code in gaan kloppen.
Dat is de taak van de programmeur.

AI is een mooie veredelde zoekmachine, en kan je, als je geluk hebt, snel voorzien van de juiste argumenten voor library functies. Als je geluk hebt, want het is sterk afhankelijk van waar de AI op getraind is en welke library, en ook welke versie van die library op moment van trainen populair was.

Voor auto-complete kun je het echter beter uitzetten is mijn ervaring.
Ik ben veel te vaak bezig met herhaaldelijk op de escape knop te rammen en ctrl-z als ik een fractie van een seconde te laat was en het onding weer een hoop onzin had toegevoegd alleen maar omdat de eerste twee letters die ik intypte overeen kwamen met iets waar een miljoen artikelen van zijn op stack overflow.
Het zit me letterlijk in de weg en zorgt ervoor dat ik minder productief ben dan wanneer het uit staat.

[wehave]

Beter en sneller.
Krijg het gevoel dat iedereen denkt aan aan chatgpt 4o.
Er zijn veel betere versies die weinig fouten makenn.
Duurt wel wat langer maar dat maakt niet veel uit.
Je kan ook je eigen maken wat ook veel zullen doen lijkt me.

[Barsonax]

Ehm in een goed opgezet project kopieer je toch gewoon de al bestaande code? Pas hier en daar kleine zaken aan en klaar.

Heb ik echt geen AI voor nodig en als ik tegen moeilijkheden aanloopt is dat wellicht een teken dat er optimalisatie mogelijk is.

Als het echt wat unieks is heb je niet zoveel aan AI, die valt vooral terug op de standaard set aan problemen.

AI is vooral handig als zoekmachine en dat zeg ik als iemand die bij iedereen bekend staat als een zeer productieve dev.

[Reactie gewijzigd door Barsonax op 26 mei 2025 18:45]

[Alfa1970]

Ehm, in een goed opgezet project is code duplicatie een doodzonde.
Als het gaat om een uitbreiding op bestaande functionaliteit dan maak je een nieuwe functie en afhankelijk van het paradigm van je poject plak je je nieuwe functie erachter, gebruik je de oude functie als argument voor de nieuwe functie, of roep je de oude functie rechstreeks aan in de nieuwe functie. (functioneel, dependency injection, procedural resp).

[Barsonax]

Enige duplicatie is geen enkel probleem. Niet alles hoeft tot in de puntjes reused te worden.

Over reuse is namelijk iets wat ik veel tegenkom en problemen veroorzaakt. Dat 2 stukken code hetzelfde zijn wil nog niet zeggen dat dat echte duplicatie is. Je moet je ook echt afvragen of dat stuk code echt hetzelfde concept representeert en niet wat anders wat erop lijkt. Gevaar zit em namelijk erin dat die 2 stukken code hele andere redenen hebben om te veranderen en dat nekt je als je alles probeert te reusen.

In het project waar ik zat waren er bijv generieke api handlers gemaakt want code reuse. Probleem alleen dat er allerlei uitzonderingen in slopen en nog was het nog niet het gewenste gedrag. Bovendien was het lastig te lezen.
Die zijn toen weggehaald en we hebben de code gewoon uitgeschreven. Sommige concepten zoals paging extraheerden we wel naar een aparte module voor reuse maar niet de hele api endpoint. Uiteindelijk hadden we nog minder lijntjes code ook en het was zoveel leesbaarder en deed gewoon meer.

Niet dat ik zeg dat reuse slecht is maar het is veel genuanceerder dan 'duplicatie is doodzonde'.

[rboerdijk]

Duplicate is wel een harde indicatie "om nog een keer goed erover na te denken".

Probleem wat ik zo vaak gezien heb is dat een stukje code 3x gedupliceerd wordt. Daarna een bug gevonden wordt en het op alle drie de plekken gefixt wordt - die vierde plek vergetend.
Een half jaar later zie je dan een bugreport wat bekend voorkomt, en dan fix je dus die vierde plek. En dan zijn er nog slechts 5 plekken met hetzelfde probleem, (namelijk de 2 nieuwe plekken die in de tussentijd gedupliceerd werden, en omdat de fix toch net iets anders is worden de originele 3 plekken weer vergeten).

Ik geef hier alle nieuwelingen met dat zodra ze "copy & paste" van een functie willen doen - de instinctieve reactie moet zijn "wacht even, vermoedelijk geen goed idee".

Als het echt specifieke handlers vereist, dan schrijf specifieke handlers. Maar als je idee is om (veel) code te dupliceren en een klein detail aan te passen, dank ben je zo goed als zeker verkeerd bezig.

[Reactie gewijzigd door rboerdijk op 27 mei 2025 13:24]

[Barsonax]

Het is denk juist goed om de neiging to abstraheren even uit te stellen tot je ziet dat je voor een derde keer iets herhaald. Pas als je meer voorbeelden heb ga je goed de patronen zien. Niet voor niets bestaat de rule of three bijvoorbeeld Wikipedia: Rule of three (computer programming).

Uitzonderingen daargelaten natuurlijk want dat je meer dan 3 api handlers heb die bijna hetzelfde lijken te doen vind ik geen enkel probleem zolang ze een ander doel hebben.

Maar we dwalen wel een beetje af onderhand. We begonnen bij chatgpt die de code voor je kopieert en daar zie ik niet zo veel meerwaarde in. Heb dan liever een mens die ernaar kijkt en misschien het juiste patroon ziet en refactored. Dan bouw je ook meer kennis op over je codebase.

[Reactie gewijzigd door Barsonax op 27 mei 2025 16:36]

[MadEgg]

Ik gebruik best regelmatig LLM tools voor code. Het is goede inspiratie en het helpt regelmatig wel om een oplossingsrichting te vinden. De code die eruit komt voldoet in de meeste gevallen lang niet aan onze kwaliteitseisen en er zitten ook vaak veel bugs in.

Het is een waardevolle tool maar absoluut geen vervanging voor een beetje ervaren ontwikkelaar. Juniors zijn er relatief meer bij geholpen dan de seniors - het helpt zeker om aan een ontwikkelrichting te komen.

[the_stickie]

En dat is zo uniek aan jouw codebase...

Imo is net dat 'wat wij doen is uniek' idee dat aan de basis ligt van een hoop gerommel, dubbelwerk en zelfs fouten.
Ik ben er overigens van overtuigd dat een AI heus wél kan helpen om te helpen bij de vraag 'hoe kunnen we dit aanpakken' ofte de architecturale en logsiche kanten van een applicatie.

[jerisson]

Imo is net dat 'wat wij doen is uniek' idee dat aan de basis ligt van een hoop gerommel, dubbelwerk en zelfs fouten.

Hangt er maar vanaf. Het andere uiterste heb ik ook maar al te vaak gehoord. Massa's geld uitgeven of een duur abbonement nemen op een software-library die net die ene functionaliteit heeft die je écht ábsoluut moet hebben van die vendor, maar die je eigenlijk op twee dagen zelf had kunnen schrijven.

Gevolg: veel geld kwijt en een gedrocht van een programma met veel te veel dependencies (waarvan je 99,9% niet gebruikt) en de daarbij horende risico's/vulnerabilities.

In de realiteit moet je geval per geval bekijken wat het beste is.

[YopY]

Dat ze het er uberhaupt over hebben (output als een meetbaar iets) geeft al aan dat dit ontstaan is uit twee of drie management lagen hogerop, die software development niet meer zien als mensenwerk maar targets en geld in, meetbare resultaten uit. Die maakt het niet zoveel uit of het een miljoen aan werkuren of een miljoen aan AI credits is.

[Jeoh]

Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure."

[Florimon]

oblig xkcd : https://m.xkcd.com/2899/

[Wozmro]

Als de baas meer regels code wenst dan zal die er krijgen

[latka]

Ik heb gewerkt in een outsourcing constructie met pricing op lines of code.... Het was 'amusing' om te zien hoe inefficiënt je kunt.programmeren. kijken of ai dat beter kan.

[YopY]

kijken of ai dat beter kan.

Gegarandeerd! Ik heb ChatGPT even gevraagd, die heeft van een half dozijn regels "FizzBuzz" code het volgende gemaakt: https://pastebin.com/cyVq14dE

[Reactie gewijzigd door YopY op 27 mei 2025 14:32]

[n4m3l355]

Toen de voorloper van Excel uitkwam, verwachtte men dat accountants de zak zouden krijgen. We hebben heden ten dagen veel meer accountants die veel meer kunnen met hun software dan ooit te voren.

AI is niet anders, het kan banen kosten maar specifiek voor ontwikkelaars is het niet onrealistisch dat Amazon verwacht dat we veel meer gaan produceren in plaats dat we ontwikkelaars de zak geven. Of die code kwalitatief is laat ik in het midden al geloof ik tegelijkertijd wel dat we ook hier in de toekomst verbeteringen zullen zien.

[Ricco02]

Ik vind dit een beetje krom.

Heeft excel er juist niet voor gezorgd dat een accountantsbureau minder accountants hoeft aan te nemen voor hetzelfde hoeveelheid werk? Aangezien excel ze enorm helpt?

Dat betekent toch juist dat veel accountants de zak hebben gekregen?

Zo zie ik het ook met AI gebeuren.

[Triblade_8472]

Nee, er is gewoon meer werk bijgekomen. Alleen dat wordt voor 't gemak vergeten.

We komen nu al mensen tekort. AI kan soms werkverlichting meebrengen, maar dat vult eerder gaten dan dat het huidig personeel wegdrukt.

[Ricco02]

Klopt. Maar als excel dus niet zou bestaan zou voor dat meer werk dus meer accountants zijn aangenomen. Nu worden die accountants in dit voorbeeld niet aangenomen.

Uiteindelijk zal er een omslag komen waarbij er niet meer een tekort is aan programmeurs en kom je op een punt dat er dus minder programmeurs worden aangenomen vanwege AI, zelfs al zou het werk meer worden.

Wat er ook bij komt kijken is dat ik nu goed kan onderhandelen over mijn salaris omdat er een tekort is. Dat gaat straks niet meer zo gemakkelijk als het tekort er niet meer is.

[Reactie gewijzigd door Ricco02 op 26 mei 2025 18:41]

[fenrirs]

Klopt. Maar als excel dus niet zou bestaan zou voor dat meer werk dus meer accountants zijn aangenomen. Nu worden die accountants in dit voorbeeld niet aangenomen.

Hier ga je er vanuit dat er een oneindige hoeveelheid accountants (of whatever voor vaklui) zijn. Laat dat laatste nou nét het probleem zijn

In mijn vak zorgt AI alleen maar voor meer vragen, vooral op gebieden waar nog niets over bekend is. ( en waar AI je dan ook niet verder helpt)

[Reactie gewijzigd door fenrirs op 26 mei 2025 19:11]

[doltishDuke]

Ja, maar dat is natuurlijk wel iets van alle tijden. De straatlantaarn-aanstekers waren ook niet blij met elektrische verlichting.

Het arbeidsveld beweegt naarmate de samenleving zich ontwikkelt. Met zoals bij de straatlantaarns zijn daar nu een hele zwik onderhoudsmonteurs voor nodig.

Zo zal het bij software development ook gaan. Weg gaat het niet, anders wordt het wel.

Ik ben gelukkig boswachter, en dat zie ik AI nog niet zo snel doen

[YopY]

Wat er ook bij komt kijken is dat ik nu goed kan onderhandelen over mijn salaris omdat er een tekort is. Dat gaat straks niet meer zo gemakkelijk als het tekort er niet meer is.

Dat is in de aanname dat de vraag naar developers afneemt, maar als het makkelijker wordt om software te produceren kan het ook zijn dat de vraag naar software toeneemt, waardoor netto er meer werk is dan eerder.

Kijk naar het weefgetouw; de Luddieten maakten ze kapot omdat het hun werk zou kosten. Maar het uiteindelijke effect van automatisering in de textielindustrie is o.a. "fast fashion", mensen met volle kledingkasten. De consumptie van textiel is vele malen vermenigvuldigd.

[svenk91]

Met excel wordt een accountant productiever, je krijgt dus veel meer terug per euro die je in accountants steekt. Dat is een goed argument om meer zaken via accountants te laten lopen en kan dus juist zorgen voor een netto toename in het aantal accountants. Het kernwoord is kan, het is heel erg afhankelijk van de casus.

Als AI zorgt dat de gemiddelde ontwikkelkosten dalen, dan gaan we misschien voor minder geld hetzelfde doen. Er is ook een goede kans dat we ontwikkelkosten juist voor veel meer zaken gaan inzetten. Wat in beiden scenarios veranderd is hoe men het ontwikkelwerk doet, maar dat is met andere vernieuwingen in de sector niet anders (betere IDE’s, version control, etc.).

[jpsch]

Nee, dat is een paradox. Nu gaat met alles vastleggen en rapporteren, zonder zich af te vragen wat ze echt nodig hebben. Accountants krijgen ook steeds meer taken toebedeeld rondom rapportage over milieu maatregelen e.d.

[sfc1971]

Hoe veel werkeloze accountants ken je?

[mrmrmr]

Dit verhaal is niet waar. Accountants doen weinig spreadsheetwerk, daar hebben ze boekhouders voor en ze kregen niet minder werk toen Lotus 1-2-3 voor PC (v.a. 1983) en software voor mini's verscheen. Gebruik van computers had wel effect op de hoeveelheid handwerk zoals gebruik van de calculator.

Terug on topic: er was al veel bloat door de huidige wijze van softwareontwikkeling, daar komen ze meer weg omdat computers sneller zijn geworden, maar feitelijk is het een wirwar van hergebruik en nieuwe code. Die vaak ook nog eens niet grondig getest wordt. Alles moet veel sneller. Met AI code voorspel ik dat die trend nog verder gaat doorzetten, onvoldoende getest, met meer bugs. De kans is steeds groter dat fundamentele problemen niet worden opgelost.

[vrije_vogel]

"Simplicity--the art of maximizing the amount of work not done--is essential."

(Agile manifesto)

[klakkie.57th]

Zo weet je als developer dat je Amazon ook meteen van je lijstje van toekomstige werkgevers mag schrappen. 🤷🏻‍♂️

[SuperDre]

Nee, meer code gaat het niet zo om. Het gaat er meer om dat AI een groot deel van je code nu schrijft in heel veel minder tijd, en dat jij dat 'alleen' nog hoeft na te kijken, eigenlijk een beetje hetzelfde wat een gedegen developer ook doet als code in checked. Dus uiteindelijk blijft het wel hetzelfde aantal code, maar dan met minder mensen/tijd.

[cdwave]

Krijg je een beetje het "codeproject code" effect.

Sites als codeproject zorgen voor een "de manke helpt de blinde" ecosysteem. Programmeurs die de juiste antwoorden hebben, komen niet aan bod, want die hebben geen reden om de site te bezoeken (karma-whoring daargelaten).

De AI code generators halen hun code kennis ook van dit soort bronnen. Dus krijg je ook dezelfde twijfelachtige kwaliteit.

[CorHeijboer]

Correct. Aan de andere kant is het gebruik van AI wel een oplossing voor de vraag of het gewenste aantal regels code gehaald wordt. "chatGPT schrijf een programma van <doelaantal regels>. Het hoeft niets te doen maar wel echt te lijken." Ondertussen kun je als techneut focussen op het denkwerk dat nodig is om het issue daadwerkelijk op te lossen.
Aan het eind is iedereen blij. Manager, want issue is opgelost en kpi aantal tegels is gehaald. Techneut, want issue opgelost zonder conflict over niet halen kpi. Allebei, want geen gedoe.

[Wouterie]

Ofwel: Ontwikkelaars bij Amazon moeten nog meer opleveren voor hetzelfde salaris. En uiteraard blijven zij ook verantwoordelijk voor de kwaliteit van het werk. Want een AI maakt nooit fouten en die code hoef je nooit na te lopen.

[the_stickie]

Ja, net zoals een bakker mét deegmixer meer brood kan/moet maken dan zonder... Ik vind het zelf niet zo gek dat bedrijven/management productiviteit koppelt aan de tools. Andersom zou betekenen dat werknemers net minder hoeven te doen voor hetzelfde geld; dat is vanuit economische realiteit onhoudbaar. Aansturen op productiviteitstoename (en dus opbrengsten) en dat werknemers dat jammer vinden lijkt me een voortdurende realiteit.

...Want een AI maakt nooit fouten en die code hoef je nooit na te lopen.

is volgens mij een foute representatie. Als ze ergens ter wereld weten dat een AI niet onfeilbaar is, is het wel bji Amazon.

[Sfynx]

Ja, net zoals een bakker mét deegmixer meer brood kan/moet maken dan zonder... Ik vind het zelf niet zo gek dat bedrijven/management productiviteit koppelt aan de tools. Andersom zou betekenen dat werknemers net minder hoeven te doen voor hetzelfde geld; dat is vanuit economische realiteit onhoudbaar. Aansturen op productiviteitstoename (en dus opbrengsten) en dat werknemers dat jammer vinden lijkt me een voortdurende realiteit.

Als de baas er meer aan overhoudt is het best redelijk om te verwachten dat de rest van de mensen er ook evenredig meer aan overhouden. In de vorm van meer vrije tijd of meer geld. Waarom zou alleen het grootkapitaal hiervan mogen profiteren?

[the_stickie]

Dat zeg ik toch ook niet? Imo profiteert iedereen ervan als bedrijven goed draaien? Wel wss ondernemers als eerste en meeste - maar hoe dat komt en loopt is imo een ethisch-economische discussie die hier niet echt relevant is ...

[Cyclonist]

Het klinkt alsof je gelooft in trickle-down-economics. Het enige directe voordeel voor Amazon-medewerkers dat ik me kan bedenken, is behoud van hun baan (phew) en eventuele stock-options die uiteindelijk meer waard worden. Maar dat laatste zal bij veel andere bedrijven/medewerkers niet het geval zijn, en gaat de productiviteitswinst uitsluitend naar het bedrijf.

[the_stickie]

Het is (meestal) niet zo dat als een bedrijf meer winst maakt, werknemers op slag meer gaan verdienen.
Maar... zonder winstgevende bedrijven zijn er geen jobs.... op middellange en lange termijn profiteert iedereen (werknemer, werkgever, zelfstandige en zelfs uitkeringstrekkende) van de welvaart die gecreëerd wordt.

Amazon werknemers zullen productiever moeten zijn, maar daarom niet persé harder hoeven te werken. Hun werkgever biedt hen immers 'geavanceerde' tools om dat te bereiken. Dat maakt hun job anders, maar niet persé slechter imo.

[84hannes]

Ik vind het zelf niet zo gek dat bedrijven/management productiviteit koppelt aan de tools.

Dat ben ik helemaal met je eens. Maar ik denk dat management bijzonder weinig interesse toont in tools. Sinds de jaren negentig zijn de tools veel beter geworden, maar ik denk dat weinig managers een expliciet een hogere productiviteit verwachten door code completion of debuggers, refactoring tools osf syntax highlighting.

AI is een beetje overrated.

[Reactie gewijzigd door 84hannes op 26 mei 2025 17:50]

[the_stickie]

Interesse in de tool zelf hebben ze inderdaad meestal niet. Wél in de productiviteit die ze brengen. Meer nog, daar wordt graag voor betaald/ in geïnvesteerd!
Gelukkig zijn de tools beter geworden, anders zaten we nu nog bytecode in ponskaarten te knippen Maar ik denk ook dat de verwachtingen meegeschaald zijn met de tools, net zoals nu aan het gebeuren is met AI.

[DdeM]

Ja, net zoals een bakker mét deegmixer meer brood kan/moet maken dan zonder...

Slecht voorbeeld. Met dezelfde instellingen en inhoud zal een deegmixer altijd dezelfde uitkomst geven, een AI niet. Je kan niet verwachten dat een tool die een inconsistente output geeft dezelfde productiviteit opleverd dan een consistente tool. Als het nou een ML Model had geweest die getrained was op een samengestelde dataset zodat het consistent had geweest, ja, maar een LLM die puur werkt op basis van een voorspellend algoritme is gewoon een risico die je niet zou moeten willen nemen.

[the_stickie]

Is goed... heb jij een beter voorbeeld?
AI is een tool die de productiviteit van devvers verhoogt - oneens? Hoeveel of hoe consistent/reproduceerbaar is niet relevant imo.

[downtime]

Er staat letterlijk in de tekst dat de ontwikkelaars minder code schrijven en "meer door AI gegenereerde code reviewen". Er wordt dus helemaal niet vanuit gegaan dat de AI geen fouten maakt.

[dez11de]

Ofwel: Ontwikkelaars bij Amazon moeten nog meer opleveren voor hetzelfde salaris.

Yep.

En uiteraard blijven zij ook verantwoordelijk voor de kwaliteit van het werk.

Hmhmja.

Want een AI maakt nooit fouten en die code hoef je nooit na te lopen.

?? Dat claimt niemand??

[Sito]

Zijn laatste punt is hoogstwaarschijnlijk sarcasme

[burgt]

En ze moeten meer reviewen en refactoren in dezelfde tijd.. ben benieuwd hoe ze dat gaan doen.

[SuperDre]

Nee dus, want ze zijn nu dus in principe veel minder tijd kwijt aan het zelf schrijven van de code. Dit is eigenlijk gewoon hetzelfde als dat jij de code schrijft en jouw collega controleert het, alleen AI kan die code vele malen sneller schrijven dan jij dat kan. Je wordt dus meer designer dan code klopper.
Zeker voor developers die eigenlijk verwachten dat het design aangeleverd wordt en zij het alleen nog in code moeten omzetten, zijn degene die hard voor hun baan moeten vrezen. Degene die ook echt zelf nog domeinkennis heeft en eigenlijk alles doet, design en code, zijn degene die het langer zullen volhouden totdat AI ook dat design verder beter kan doen obv wensen.

[Reactie gewijzigd door SuperDre op 26 mei 2025 23:11]

[BasHouse]

Ik denk dat het wel los zal lopen zolang werelds beste AI coding programma nog een discussie aangaat of CMake 4.0.2 wel of niet bestaat. Ik moest hem uitleggen dat het mei 2025 was, voordat ie stopte met mij te vertellen dat ik waarschijnlijk een typo gemaakt had. Pfff

[lkruijsw]

Hier wordt van zeer hoog niveau in het management voorgeschreven hoe op het laagste niveau de programmeur zijn werk moet doen.

Over het algemeen gaan dat soort dingen die van boven opgelegd worden niet goed. Laat de programmeurs zelf uitzoeken hoe ze efficienter kunnen werken.

Wat weten de managers hier nu vanaf? Ze lezen het nieuws, weten dat AI een hype is, oh, dat moeten we in ons bedrijf ook wat mee doen. Okay, maar als je dat vervolgens gaat opleggen...

[Smuey]

Klinkt wel als een succesformule, 'meer code = meer beter', ja. Ik mag toch hopen dat er bij het beoordelen ook andere criteria meegeteld worden dan alleen maar het aantal regels dat je hebt ge(co)produceerd. Zaken als, begrijp je ook wat het doet, of is het resultaat ook te onderhouden ofzo... Tuurlijk gebruik ik het ook af en toe, maar naar mijn ervaring is, in veel (te veel) gevallen, wat er uit een AI komt niet al te best - Tenzij je het aantal regels als enige criterium neemt.

[YopY]

De krant vergelijkt het werk met de transitie van handarbeid naar lopendebandwerk aan het begin van de 20e eeuw. Daarbij ging de productiviteit omhoog door elke medewerker verantwoordelijk te maken voor één element en dat zo snel mogelijk te doen, in plaats van één persoon die het hele proces van productie op zich neemt.

Dit is een denkfout die de managers maken; softwareontwikkeling is (moet geen) lopendebandwerk zijn, software engineers bedenken en bouwen de lopende band. Ik zie wel in hoe ze dat kunnen denken; een goedlopend project werkt immers redelijk voorspelbaar tickets / taken af, dus als je daar twee-drie management lagen boven staat zie je alleen wat metrics omtrent taken die afgerond worden.

Software development is automatisering; in hoeverre is automatisering te automatiseren? Zijn er lopende bandwerk productielijnen die lopende band productielijnen produceren?