Carrièreperspectief software development in AI revolutie

[Wozmro]

Ergens moet de vraagsteller toch niet al te naïef zijn? Ik ga toch ook geen aardbeientaart vragen bij de slager?

Klinkt voor mij toch een beetje als: kijk iedereen, ik ga iets stoms doen om zogezegd te 'bewijzen' dat iets niet (goed) werkt.

[Marc3l]

Wozmro schreef op woensdag 8 juli 2026 @ 09:09:
Ergens moet de vraagsteller toch niet al te naïef zijn? Ik ga toch ook geen aardbeientaart vragen bij de slager?

Maar als de ai een slager zou zijn, dan zou hij het zeker proberen.
Pakt een runderbaklap, snijdt die in de vorm van een taartpunt, pureert een rauwe varkenslever tot een soort roze "aardbeiencreme", spuit er wit vet bovenop als slagroom en garneert het met een paar rauwe nieren. Hij legt het glimlachend op de toonbank en zegt: *"Alstublieft, je aardbeientaart!"

[Wozmro]

Ja, dat klopt. En er zullen waarschijnlijk ook wel echte slagers bestaan die zullen zeggen: ik zal het eens proberen.

Net zoals er ook wel softwareprojecten het schip in gaan omdat de programmeur denkt: zal wel lukken, hoe moeilijk kan het zijn.

Ik denk dat we moeten voorzichtig zijn met alle verantwoordelijkheid weghouden van de vraagsteller.

[Furion2000]

Wozmro schreef op woensdag 8 juli 2026 @ 09:28:
Ja, dat klopt. En er zullen waarschijnlijk ook wel echte slagers bestaan die zullen zeggen: ik zal het eens proberen.

Net zoals er ook wel softwareprojecten het schip in gaan omdat de programmeur denkt: zal wel lukken, hoe moeilijk kan het zijn.

Ik denk dat we moeten voorzichtig zijn met alle verantwoordelijkheid weghouden van de vraagsteller.

Voorzicht word als eerste het raam uit geflikkert als management geld ziet. Waar devs op een lager tempo veel crap produceerde met de beperkte context window, gaan dezelfde devs in een hoger tempo crap maken. Zolang dat geaccepteerd is (en dat doet de samenleving op heel veel andere producten al jaren), dan hobbelt dat vrolijk verder.

(ik maak ook genoeg crap, maar ik verkoop het niet als productie ready)

@Glashelder kan wel zeggen dat LLM's steeds beter worden en een grotere context hebben dan mensen, tot dusver moet ook Fable met genoeg guardrails aan de slag en heb ik nog steeds al mijn oplettendheid/ervaring nodig om een complete feature te maken die acceptabel is. We lezen dat laatste maanden met trust me bro benchmarks dat het 10x beter is geworden, maar ik merk er maar weinig van en zelfs een plateau. Zonder een stricte structuur zit je geld/tokens te verbranden met trial and error en brute force.

Ik ga nu wel 3x sneller en kan in principe 100x sneller, maar het blijft een creatief proces waar je energie/focus voor nodig hebt. Met agentic development ga je ook redelijk hard door die tokens heen

Gelijk/ongelijk who knows, maar ik zie de werkgelegenheid voor mij niet zomaar kelderen.

[ Voor 7% gewijzigd door Furion2000 op 08-07-2026 09:44 ]

[R_Zwart]

Wozmro schreef op woensdag 8 juli 2026 @ 09:09:
Ergens moet de vraagsteller toch niet al te naïef zijn? Ik ga toch ook geen aardbeientaart vragen bij de slager?

Klinkt voor mij toch een beetje als: kijk iedereen, ik ga iets stoms doen om zogezegd te 'bewijzen' dat iets niet (goed) werkt.

Aardbeientaart is wellicht wat erg branchevreemd, maar veel slagers verkopen wel veel zaken die geen vlees zijn. Denk alleen al aan de kant-en-klaar maaltijden die ze verkopen. Sommige met vijrwel geen vlees er in.

[lordgandalf]

Ik zie AI alleen maar nuttig zijn als vraagbaak en hulp bij code zodra alles uit een AI komt ga je ook juridische problemen op de hals halen vrees ik want de code waarop de AI is getrained is ooit door iemand gescrheven. en die heeft daar auteursrecht op dus zou me niet verbazen als we daar ooit rechtzaken over zien komen.

[Valandil]

AI gaat zorgen voor een shifting in taken en verantwoordelijkheden.
Voor nu is het nog niet volwassen genoeg om volledig autonoom te draaien en deployen.
Let wel, ook dit is slechts een kwestie van tijd.

Voor de medior+ / senior is er zeker nog voldoende werk. Alleen is dat werkveld veranderd. Juist al deze kennis en ervaring is zeer waardevol bij de review van AI gegenereerde code.
Voor junior developers is het wel verdomd lastig om aan de slag te komen. Daar waar je als Jr juist repeterende taken of eenvoudige bugs / features kon ontwikkelen om het te leren, is dit nu vervangen door A.I.


Als je developer bent kan je het beste A.I. in volle glorie omarmen en gebruiken. Dit is namelijk een ontwikkeling die je niet gaat tegenhouden en in een hard tempo doorontwikkelt.

Ja de A.I. bubbel zal een keer barsten, maar dat is meer in relatie tot de hoeveelheid geld die er in gepompt wordt en onrealistische verwachtingen. Dus meer een barst aan de financiële kant (aandelen, waardevermindering etc) dan de ontwikkeling van wat A.I. allemaal straks kan.


Het management van TS is dus een klassiek voorbeeld van te grote verwachtingen. 10x meer output met A.I.. Nou succes daarmee, die gaan straks een illusie armer worden. Zover is het ook nog niet, zeker niet als je alles nog moet inrichten.


Maar dat A.I. het werkveld van developers aan het veranderen is, dat is een feit. Dus omarm het en daardoor blijft je juist waardevol.


Toevoeging:
Het omarmen van A.I. geldt overigens niet alleen voor developers. Het verschil tov van eerdere revoluties is dat met AI deze technologie niet alleen lichamelijk werk automatiseert, maar ook cognitief werk. Daardoor raakt het veel meer sectoren tegelijk. Dat maakt deze overgang mogelijk ingrijpender dan eerdere automatiseringsgolven.

Dit in combinatie met een kapitalistisch systeem, zorgt wel voor een giftige cocktail. Meer werk kunnen doen met minder mensen is vaak meer winst en blije aandeelhouders en tegelijkertijd daling in werkgelegenheid. Meer mensen met achterstand tot de arbeidsmarkt die niet kunnen aanhaken bij deze ontwikkelingen. Shifting in vraag en aanbod.


Heel eerlijk; ik zie het redelijk somber in. Niet op korte termijn, maar wel stapje voor stapje. Iedereen juicht mee op de hype, maar staat straks met lege handen. De utopie van minder werken voor hetzelfde geld, daar geloof ik niet in. Bedrijven streven doorgaans voor maximale winst, en personeel is eenmaal de grootste kostenpost.

[ Voor 26% gewijzigd door Valandil op 08-07-2026 10:29 ]

[TheGhostInc]

lordgandalf schreef op woensdag 8 juli 2026 @ 09:47:
Ik zie AI alleen maar nuttig zijn als vraagbaak en hulp bij code zodra alles uit een AI komt ga je ook juridische problemen op de hals halen vrees ik want de code waarop de AI is getrained is ooit door iemand gescrheven. en die heeft daar auteursrecht op dus zou me niet verbazen als we daar ooit rechtzaken over zien komen.

Ik zie nog eerder gebeuren dat alle developers de gevangenis ingaan wegens grove schending van de AVG. Iedereen die daarna nog vrij is gaat vanwege grove nalatigheid, samen met de PO's, scrummasters en projectleiders, voor het bankje komen. Geen PEN test gedaan? Gewoon aansprakelijk voor de gevolgen. Alle data in een S3 bucket of andere shared storage die publiek beschikbaar is gekomen? De rest van je leven krijg je geen VOG meer om iets met software te mogen doen. /s
Boeing komt ook gewoon weg met honderden doden door een 'software foutje'.

Het voordeel dat AI heeft is dat het enorm veel 'berekeningen' doet om tot jouw antwoord te komen, daardoor is het best lastig om 2x exact hetzelfde antwoord te krijgen. Daarmee zit je dus direct al in een 'afgeleid werk' en veel minder in een 'slaafse kopie'.
Los daarvan is software zelden echt heel bijzonder. En juist de technische 'trucjes' worden weer breed gedeeld, waardoor de kans op echte problemen heel klein is.

Dus stel ik vraag om een CRM systeempje voor mijn sportclub, dan zijn er meer dan 5 verschillende Open Source CRM's die hij waarschijnlijk direct of indirect in zijn training heeft zitten. Daarmee kun je dus 'mix & match' doen. Misschien pakt hij het datamodel van de PHP variant, aangevuld met het tagging systeem van de 2de, het dynamische velden systeem van het derde, de layout van de vierde en het logo ontwerp van de 5de. Daarna pakt hij de API van Salesforce, het rechtenmodel van MS en is er een mooie applicatie in Rust geschreven waar hij de architectuur en code stijl van pakt. En elke iteratie die ik doe zal hij verder van een van de gebruikte bronnen af gaan wijken.

[Wozmro]

De opleidingen zullen ook wel de bocht maken denk ik. Die zitten niet in een vacuüm. De focus zal verlegd worden zodanig dat afgestudeerden ook hun weg zullen vinden in een AI it-wereld.

Minder syntax, minder zelf debuggen (niet helemaal niets meer), meer focus op bijblijven op gebied veiligheid, meer best practices, denk ik dan als niet IT'er.

Ik heb zelf een elektronica opleiding gevolgd. Ik leerde diepgaand over de transistor, de generatie voor mij over de zendbuizen. De huidige generatie over arduino's en pi's.

Ja, een en ander moet wel eens aangeraakt worden maar dat is nog een groot verschil met diepgaande kennis.

Ik denk niet dat er tegenwoordig nog een trimester over de transistor gepraat wordt 🙂

[lordgandalf]

TheGhostInc schreef op woensdag 8 juli 2026 @ 10:32:
[...]

Ik zie nog eerder gebeuren dat alle developers de gevangenis ingaan wegens grove schending van de AVG. Iedereen die daarna nog vrij is gaat vanwege grove nalatigheid, samen met de PO's, scrummasters en projectleiders, voor het bankje komen. Geen PEN test gedaan? Gewoon aansprakelijk voor de gevolgen. Alle data in een S3 bucket of andere shared storage die publiek beschikbaar is gekomen? De rest van je leven krijg je geen VOG meer om iets met software te mogen doen. /s
Boeing komt ook gewoon weg met honderden doden door een 'software foutje'.

Het voordeel dat AI heeft is dat het enorm veel 'berekeningen' doet om tot jouw antwoord te komen, daardoor is het best lastig om 2x exact hetzelfde antwoord te krijgen. Daarmee zit je dus direct al in een 'afgeleid werk' en veel minder in een 'slaafse kopie'.
Los daarvan is software zelden echt heel bijzonder. En juist de technische 'trucjes' worden weer breed gedeeld, waardoor de kans op echte problemen heel klein is.

Dus stel ik vraag om een CRM systeempje voor mijn sportclub, dan zijn er meer dan 5 verschillende Open Source CRM's die hij waarschijnlijk direct of indirect in zijn training heeft zitten. Daarmee kun je dus 'mix & match' doen. Misschien pakt hij het datamodel van de PHP variant, aangevuld met het tagging systeem van de 2de, het dynamische velden systeem van het derde, de layout van de vierde en het logo ontwerp van de 5de. Daarna pakt hij de API van Salesforce, het rechtenmodel van MS en is er een mooie applicatie in Rust geschreven waar hij de architectuur en code stijl van pakt. En elke iteratie die ik doe zal hij verder van een van de gebruikte bronnen af gaan wijken.

Kijk een crmtje bouwen voor een AI is wat anders dan een CRM laten bouwen door AI voor een overheidsorganisatie. Dus daar zal ook de zwaarte liggen. AI is beter geworden maar er zijn nog steeds programmeurs en kunstenaren die gewoon hun code of gedeeltes uit ai modellen getoverd zien worden. En dan kan de code zelf wel anders zijn maar dat stuk is dan gewoon een 1 op 1 kopie van zijn code. Maar je hebt gelijk de AVG enz zal ook problemen geven.

[wiemelen]

Er worden allemaal valide argumenten aangehaald waarom AI wel of niet een programmeur zal vervangen, in welk tijdsbestek of dat "iedereen in de toekomst zal programeren".
Iedereen moet er vroeg of laat mee leren werken en gebruiken waar het kan, want het is een grote hulp. Maar ik zie vooral praktische issues:

• Kennis opbouwen en in stant houden terwijl AI het sneller (en misschien beter kan).
  Want validatie van code, AVG richtlijnen, inzicht in generieke herbruikbare code, "in controle" zijn van je systeem / code.
  Ik vraag me af hoe dit in de toekomst gaat ingevuld worden.
• Voor analyse en architectuur zal je ook in de toekomst de juiste kennis moeten hebben om de juiste vragen te kunnen stellen[l/i]
• AI krijgt (vooralsnog) niet alle vraagstukken opgelost. Juist de meer complexe dingen, waar je dus kennis en ervaring voor nodig hebt, worden bij mensen belegd. [l/i]
• Er is nu al een grote kennis kloof tussen mensen die met IT kunnen werken en de IT leken. Ik merk dat dat kennisgat, de complexiteit en de schrik voor IT nu al groter wordt. Hoe zal er in bedrijven daarmee omgegaan (kunnen) worden.
• Hoe betaalbaar en beschikbaar zal AI in de toekomst zijn? Momenteel gaat dit best goed, maar als je nu al de issues met datacenters hoort (en de aantallen die ze nog willen bijplanten) en de extra kosten die in de toekomst (mogelijk) betaald dienen te worden.[l/i]
• Hoe goed zal AI / een LLM zijn kennis kunnen blijven updaten? Momenteel bestaan vele LLM's omdat ze massaal veel data gebruiken die in vele gevallen niet legaal verkregen zijn. Tenminste, er lopen daar nu al rechtzaken over. Wat als software aanbieders hun eigen AI gaan aanbieden en dit intellectueel/gerechtelijk gaan afschermen van andere AI tools. Of extra licentie kosten vragen aan hiervoor. Ik zie dit in de toekomst nog als een cashcow voor hen, zeker gezien de verminderde inkomsten uit training. Waarom zou ik jaarlijks 5.000 - 10.000 euro aan cursus volgen als AI het antwoord heeft?
  Daarnaast zal je zien (zie ik nu al gebeuren) dat er veel minder op software forums gepost wordt. Waarom zou je ook, want AI weet het toch wel. Helemaal terecht voor de "simpele" dingen, maar voor de complexe zaken waar AI geen antwoord voor heeft, vind je dan ook minder/niets meer. Ik heb zelf ook al lange tijd geen antwoorden meer gepost. Waarom zou ik ook als AI o.b.v. mijn antwoorden (geen volledige code, maar verwijzingen naar klasses, methodes, modules of kleine code snippets) hele lappen code gaat uitspuwen die iemand kan copy/pasten terwijl ik er een week werk aan heb gehad.
• Mensen worden "dommer" en leren niet meer nadenken/analyseren. Opnieuw niet meer nodig want er is AI, maar anderzijds leren je hersenen ook niet meer de juiste verbindingen te leggen waardoor je effectief niet meer goed kan nadenken/analyseren. Heb ik een tijd geleden een uiteenzetting over gezien. Er lopen daar nu al onderzoeken over, maar de verwachting is dat er een gelijkaardige conclusie gaat zijn als kinderen die op de lagere school veel met de laptop doen i.p.v. zelf te schrijven. Niet voor niets dat de voorlopers van IT gebruik in de lagere school (o.a. Scandinavische landen), opnieuw meer tijd en nadruk leggen op schrijven.

Niemand zal er aan ontsnappen om AI te gebruiken, zeker in de IT sector, want anders zal je op een dag vervangen worden. Maar er spelen andere vraagstukken waar overheden en bedrijven vooralsnog denk ik niet echt mee bezig zijn. Benieuwd wat de toekomst brengt.

[107mb]

Ik draai al een tijdje mee en AI is gewoon een vernieuwing die omarmd moet worden. Toen ik begon met werken kwamen net de moderne talen in opkomst. De oude garde vond dat maar niets, want een moderne programmeur hoeft niet meer na te denken over registers, geheugenadressen en CPU-instructies. Dus echt programmeerwerk was uitstervend en de moderne programmeur hoefde niets meer te kunnen, vond men. Onzin dus. Toen kwam internet in beeld, dus de modernere programmeur was als de dood dat zijn werk tot halt kwam, want alle info is op internet te vinden, en niet meer in de hoofden of de 1000 pagina's dikke programmeer-boeken. Ook onzin dus. Deze hele AI-ontwikkeling zal uiteindelijk ook meevallen, en we staan eind 2027 echt niet massaal op straat.

Ik heb onlangs een verhaal gehoord (helaas geen bron) waarbij een software bedrijf al 500.000 euro per maand kwijt is aan tokens. Daar zet je een boel programmeurs voor aan het werk. Het zal dus allemaal wel loslopen.

[Gr4mpyC3t]

Ik heb eigenlijk maar één zorg: als we met z’n allen code gaan zitten prompten, wat blijft er dan over van de kennis van de prompter, die de code moet beoordelen?

Nu is dat nog niet zo’n probleem, want er is ervaring genoeg, maar de nieuwe generatie die straks aan het werk gaat schrijft dus nooit meer iets, maar moet het wel beoordelen?

[Glashelder]

Gr4mpyC3t schreef op vrijdag 10 juli 2026 @ 11:21:
Ik heb eigenlijk maar één zorg: als we met z’n allen code gaan zitten prompten, wat blijft er dan over van de kennis van de prompter, die de code moet beoordelen?

Nu is dat nog niet zo’n probleem, want er is ervaring genoeg, maar de nieuwe generatie die straks aan het werk gaat schrijft dus nooit meer iets, maar moet het wel beoordelen?

Niet. Je laat de code beoordelen door andere AI. Elke developer zal beamen dat het kut is om code van anderen te lezen en dat is niet anders met AI code.

Dit is gewoon een soortgelijke discussie als toen C kwam en Assembly eruit ging. En toen unmanaged talen voor veel projecten werden ingeruild door managed. Nu zetten we een veel grotere stap: geen eigen code schrijven.

[Liegebeest]

Wozmro schreef op woensdag 8 juli 2026 @ 09:28:
Ik denk dat we moeten voorzichtig zijn met alle verantwoordelijkheid weghouden van de vraagsteller.

De gebruiker van een oplossing gebaseerd op AI is en blijft verantwoordelijk voor de keus wat hen doen met de uitkomsten die worden geboden. Een data analyst is verantwoordelijk voor het verifiëren van de analyse, een programmeur is verantwoordelijk voor de wijzigingen aan de codebase. Deze aansprakelijkheid kan je niet delegeren naar de AI, noch naar diens leverancier.

[defiant]

Gr4mpyC3t schreef op vrijdag 10 juli 2026 @ 11:21:
Ik heb eigenlijk maar één zorg: als we met z’n allen code gaan zitten prompten, wat blijft er dan over van de kennis van de prompter, die de code moet beoordelen?

Nu is dat nog niet zo’n probleem, want er is ervaring genoeg, maar de nieuwe generatie die straks aan het werk gaat schrijft dus nooit meer iets, maar moet het wel beoordelen?

Dat is onderdeel van het business model, de beoordeling wordt onderdeel gemaakt van het AI proces. Echter er zijn verschillende niveaus van correctheid en beoordeling in software: voldoet aan specificaties, voldoet aan architectuur eisen, voldoet aan onderhoudbaarheid, etc. Het kern probleem met AI is dat het iets probeert op te lossen wat software engineering zelf nog nooit goed heeft opgelost, namelijk op zowel business als software vlak correcte specificaties kunnen vergaren.

En dat is sinds het begin van software al een probleem Fred Brooks had dit in de jaren 60/70 al ontdekt en gedocumenteerd in The Mythical Man-Month en No Silver Bullet – Essence and Accident in Software Engineering. Zeker de opmerking in het laatste boek is imho veelzeggend:

Brooks argues that "there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity." He also states that "we cannot expect ever to see two-fold gains every two years" in software development, as there is in hardware development

AI "belooft" natuurlijk af te rekenen met dat principe, maar het is de vraag of het kan omgaan met de oorzaken die Brooks benoemd:

Brooks claims that accidental complexity has decreased substantially, and today's programmers spend most of their time addressing essential complexity. Brooks argues that this means shrinking all the accidental activities to zero will not give the same order-of-magnitude improvement as attempting to decrease essential complexity.

En de essential complexity is natuurlijk het business model zelf, hoe complexer de business en de requirements, hoe complexer ook de software wordt. Dat is complexiteit die niet gesimplificeerd of weggemanaged kan worden, zonder afbreuk te doen aan requirements.

Requirements is het probleem wat nooit is opgelost op een manier waarbij je frictieloos deze kan omzetten ("coderen") in software. Zowel aan de business kant als aan de programmeerkant.

Je ziet dit dus ook al terug met AI, alle lovende verhalen over AI zijn vaak probleem die vallen in Fred Brooks accidental complexity. Een game geschreven in C++ met AI "one shotten" naar bijvoorbeeld Rust is natuurlijk indrukwekkend, maar het heeft helemaal niets gedaan met essential complexity, die is precies hetzelfde gebleven, de game werkt hetzelfde.

Aan de andere kant zijn er weinig verhalen over bedrijven die opeens 10x zoveel features opleveren met AI en hun concurrentie positie en winstgevendheid opeens significant hebben verbeterd. En dat is de hele premisse waar de hype op gebaseerd is: get onboard or get left behind.

[Wozmro]

Liegebeest schreef op vrijdag 10 juli 2026 @ 12:07:
[...]

De gebruiker van een oplossing gebaseerd op AI is en blijft verantwoordelijk voor de keus wat hen doen met de uitkomsten die worden geboden. Een data analyst is verantwoordelijk voor het verifiëren van de analyse, een programmeur is verantwoordelijk voor de wijzigingen aan de codebase. Deze aansprakelijkheid kan je niet delegeren naar de AI, noch naar diens leverancier.

Dat klopt zeker.

Verantwoordelijkheid nemen kan enkel door mensen gedaan worden. En is een essentieel onderdeel van gelijk welke job. Ook los van AI.

[Orangelights23]

Ik zie best veel vragen en aannames van mede Tweakers hier, op de frontpage en ook van anderen die ik spreek, waaruit blijkt dat zij nog weinig ervaring hebben met AI binnen de IT an omliggende vakgebieden. Ik ben dan ook benieuwd naar jullie ervaringen. Op basis van die informatie kunnen we misschien relevantere discussies voeren en elkaar helpen, want ik zie best veel aannames voorbij komen die vaak incorrect zijn.

Ik weet overigens dat veel bedrijven amper of recentelijk begonnen zijn met AI (voornamelijk LLM’s) waardoor het kennisniveau van de gemiddelde medewerker niet bijzonder hoog is, maar dit is wel Tweakers

[Gr4mpyC3t]

Glashelder schreef op vrijdag 10 juli 2026 @ 12:03:
[...]

Niet. Je laat de code beoordelen door andere AI. Elke developer zal beamen dat het kut is om code van anderen te lezen en dat is niet anders met AI code.

Dit is gewoon een soortgelijke discussie als toen C kwam en Assembly eruit ging. En toen unmanaged talen voor veel projecten werden ingeruild door managed. Nu zetten we een veel grotere stap: geen eigen code schrijven.

Lijkt me ontzettend spannend, eerlijk gezegd. Het is een beetje als in een fabriek: prima dat de meeste fabrieksprocessen uiteindelijk geautomatiseerd zijn, maar als zo’n machine stukgaat moet je toch wel in staat zijn om het op te lossen of desnoods weer terug te schakelen naar handmatig werk.

Voor AI‑development lijkt me dat niet anders. Je AI‑agents moeten wel betrouwbaar werk afleveren, maar ook de agents die de controle uitvoeren behoren net zo betrouwbaar te zijn. Ik kan me voorstellen dat we er vanzelf achterkomen dat het best prettig is om mensen in dienst te hebben die begrijpen welke code daar uit komt rollen en of die ook voldoet aan alles wat bij goede code komt kijken.

En dan val ik toch weer terug op mijn vraag: als niemand meer code schrijft, waar komen die mensen dan vandaan?

[Kurkentrekker]

Orangelights23 schreef op vrijdag 10 juli 2026 @ 16:27:
Ik zie best veel vragen en aannames van mede Tweakers hier, op de frontpage en ook van anderen die ik spreek, waaruit blijkt dat zij nog weinig ervaring hebben met AI binnen de IT an omliggende vakgebieden. Ik ben dan ook benieuwd naar jullie ervaringen. Op basis van die informatie kunnen we misschien relevantere discussies voeren en elkaar helpen, want ik zie best veel aannames voorbij komen die vaak incorrect zijn.

Ik weet overigens dat veel bedrijven amper of recentelijk begonnen zijn met AI (voornamelijk LLM’s) waardoor het kennisniveau van de gemiddelde medewerker niet bijzonder hoog is, maar dit is wel Tweakers

Om het gesprek dan leuk te starten, wil je een paar van die aannames eens benoemen die jij vaak tegenkomt en incorrect zijn? Ik zie er ook een hoop hoor, inclusief aannames die in de basis correct zijn maar vervolgens compleet andere aspecten negeren. Alsof ze in een vacuüm bestaan.

[Marc3l]

Gr4mpyC3t schreef op vrijdag 10 juli 2026 @ 11:21:
Ik heb eigenlijk maar één zorg: als we met z’n allen code gaan zitten prompten, wat blijft er dan over van de kennis van de prompter, die de code moet beoordelen?

Dat was ook een vraag in mijn eerste bericht in dit topic. Maar ook, ai wordt getraind op onze geschreven code. Als wij geen code meer schrijven staan we stil. Dus ai moet dan ook zichzelf gaan ontwikkelen.

Ik ben ook benieuwd naar je aannames @Orangelights23

[Tjeerd]

Bij mijn vorige werkgever (detachering) kwam ik een jaar of 4 (?) geleden in aanraking met een collega bij een klant die het over iets nieuws had genaamd "ChatGPT". Gooide een stukje frontend erin en vroeg of hij er een test voor kon maken. Binnen 5 tellen klaar. Daarna zelf wat gaan spelen ermee en bij mijn vorige werk ben ik denk ik twee jaar terug het steeds serieuzer gaan gebruiken. Je kent het wel, van die taken die je kunt kloppen, maar ook even goed kunt nadenken over een prompt (zeg vijf minuten prompten) en je hebt precies dat wat je wilde. Wat normaal een half uur of misschien een uur 'dom' typwerk zou zijn.

Dat gevoel had/heb ik steeds vaker, ik heb geen zin meer om veel van dat domme typwerk te doen. Zeker omdat ik al een jaar of 25 codeklopper ben, leer ik altijd wel nieuwe dingen, maar zit er ook een hoop bij waar ik gewoon steeds minder zin heb om dat wéér opnieuw te kloppen in een andere variant. Eigenlijk liep ik de laatste paar jaar wel een beetje rond met het idee dat ik softwareontwikkeling op die manier een beetje zat begon te worden.

Na mijn positieve ervaringen bij mijn vorige werk, ben ik bij mijn huidige werk vanaf dag één eigenlijk bijna alles met AI gaan doen. Ik prompt dus heel veel, maar heb binnen enkele maanden tijd nu al dingen in elkaar gezet, die normaliter misschien een jaar zouden duren. Vooral frontend vind ik echt niks aan en er is geen frontend(er) omdat ik zelf de enige ontwikkelaar ben, maar met AI kan ik toch degelijke frontends in elkaar zetten.

Het is wel zo dat ik redelijk goed door kan vragen omdat je soms ideeen hebt opgedaan uit werkervaring uit het verleden en daardoor redelijk goed kunt inschatten wat je neer wil zetten. Maar heb ook regelmatig dat AI met oplossingen komt en al van tevoren dingen heeft uitgedacht, waar ik zelf nog niet eens bij had stilgestaan. Ik doe het tot nu toe trouwens nog allemaal met gratis AI. Dus ik weet dat het (nog) beter kan met betaalde versies.

Maar persoonlijk heb ik met AI veel meer zin in het bouwen van software gekregen. Je kunt ook sneller wat proberen om te kijken of het wat is en werkt. Dat doet me ook denken, vind ik nou echt het code kloppen leuk of vind ik het leuker om dingen voor elkaar te krijgen en te realiseren? Ik denk dat als je AI helemaal links laat liggen als softwareontwikkelaar het wel een gemiste kans is. Kan me niet voorstellen dat AI 'over' gaat en we binnen een paar jaar weer ouderwets alleen maar code kloppen. Je moet echt (nog) meer handig zijn in het kunnen omschrijven in prompts wat je wil (eisen/requirements). Dus persoonlijk wil ik wel proberen om te blijven weten wat er mogelijk is met AI in de softwareontwikkelwereld.

[GoingDutch]

wiemelen schreef op dinsdag 30 juni 2026 @ 10:11:
[...]

Beetje vreemde vraag misschien, maar wat voor soort code schrijf je dan?
...
Let wel, wij worden verplicht om met Co-pilot te werken.

…

Vooral C, C++, en Python. Ik denk niet dat Co-Pilot de beste keuze is, er zijn betere alternatieven om code te schrijven. Het ontwikkelt zich ook nog steeds, er komen regelmatig weer nieuwere en betere modellen uit.

Ik vind de mens over het algemeen ook vrij slecht in programmeren. Hier heeft de AI ook niet echt sterke concurrentie. Het schrijven van leesbare code, documentatie en tests schrijven is vaak al te veel gevraagd. Dit doet de AI meestal veel beter en veel sneller.

Invloed op de arbeidsmarkt zal het zeker hebben, ik zou zelf ook geen software ontwikkelaars meer aannemen. Je kan je beter op ‘prompt engineering’ richten. Daarbij kost een AI ook vrijwel niets in vergelijking met een mens(hooguit enkele 10-tallen euros per maand).

[Wozmro]

Marc3l schreef op vrijdag 10 juli 2026 @ 20:59:
[...]

Dat was ook een vraag in mijn eerste bericht in dit topic. Maar ook, ai wordt getraind op onze geschreven code. Als wij geen code meer schrijven staan we stil. Dus ai moet dan ook zichzelf gaan ontwikkelen.

Ik ben ook benieuwd naar je aannames @Orangelights23

Vraag als niet-programmeur: hoeveel % van de programmeurs houdt zich bezig met ontwikkeling en onderhoud van de diverse compilers/interpreters?

En verifieert een programmeur de (machine)code die uit een compiler komt?

[Tjeerd]

GoingDutch schreef op zaterdag 11 juli 2026 @ 12:24:
[...]
Ik vind de mens over het algemeen ook vrij slecht in programmeren. Hier heeft de AI ook niet echt sterke concurrentie. Het schrijven van leesbare code, documentatie en tests schrijven is vaak al te veel gevraagd. Dit doet de AI meestal veel beter en veel sneller.

Nog niet zo heel veel bij stilgestaan, maar wat je zegt zit wel wat in. Ik denk dat er een hoop code is geschreven die AI qua structuur, leesbaarheid, efficiëntie en beste praktijken naar een hoger niveau kan tillen. Wat dat betreft is AI wel een mooie assistent om de wat minder nette softwareontwikkelaars op het juiste pad te houden en hun vaardigheden te verbeteren. Ik denk dat een hoop ontwikkelaars echt heel mooie creatieve oplossingen hebben, maar dat AI daar mooi op aan kan sluiten om de code ook wat meer kwaliteit te geven.

En ik durf best toe te geven dat ik ook na zoveel jaren software ontwikkelen ik dingen maak en het tegen AI houd en het toch verbeterpunten ziet, ben altijd aan het leren. Je zou kunnen zeggen een collega zou dat ook net zo goed kunnen doen, maar ook daar evenaart AI zich vaak in om van gedachten te wisselen.

[ Voor 14% gewijzigd door Tjeerd op 11-07-2026 13:08 ]

[crisp]

Wozmro schreef op zaterdag 11 juli 2026 @ 12:52:
[...]

Vraag als niet-programmeur: hoeveel % van de programmeurs houdt zich bezig met ontwikkeling en onderhoud van de diverse compilers/interpreters?

En verifieert een programmeur de (machine)code die uit een compiler komt?

Compilatie is, in tegenstelling tot AI, deterministisch.

[Marc3l]

Wozmro schreef op zaterdag 11 juli 2026 @ 12:52:
[...]

Vraag als niet-programmeur: hoeveel % van de programmeurs houdt zich bezig met ontwikkeling en onderhoud van de diverse compilers/interpreters?

En verifieert een programmeur de (machine)code die uit een compiler komt?

Ik snap waar je naar toe wilt. Het is ook meer hardop denken/vragen van mijn kant. Wat we nu hebben, dat hebben we nog zelf gemaakt dus ook zelf de controle over. In de toekomst laten we dat ai doen, die heeft dan ook geen menselijke logica (if else enz.) meer nodig, dus helemaal een black box voor ons. Niet dat ik zeg dat dat goed of fout is, eerder fascinerend.

[Cobb]

Glashelder schreef op vrijdag 10 juli 2026 @ 12:03:
[...]

Niet. Je laat de code beoordelen door andere AI. Elke developer zal beamen dat het kut is om code van anderen te lezen en dat is niet anders met AI code.

Dit is gewoon een soortgelijke discussie als toen C kwam en Assembly eruit ging. En toen unmanaged talen voor veel projecten werden ingeruild door managed. Nu zetten we een veel grotere stap: geen eigen code schrijven.

Het is wel een probleem als vervolgens de A.I. duurder en duurder wordt gemaakt na het monopolie te hebben op deze specifieke kennis.

[R_Zwart]

GoingDutch schreef op zaterdag 11 juli 2026 @ 12:24:
[...]

Vooral C, C++, en Python. Ik denk niet dat Co-Pilot de beste keuze is, er zijn betere alternatieven om code te schrijven. Het ontwikkelt zich ook nog steeds, er komen regelmatig weer nieuwere en betere modellen uit.

Ik vind de mens over het algemeen ook vrij slecht in programmeren. Hier heeft de AI ook niet echt sterke concurrentie. Het schrijven van leesbare code, documentatie en tests schrijven is vaak al te veel gevraagd. Dit doet de AI meestal veel beter en veel sneller.

Invloed op de arbeidsmarkt zal het zeker hebben, ik zou zelf ook geen software ontwikkelaars meer aannemen. Je kan je beter op ‘prompt engineering’ richten. Daarbij kost een AI ook vrijwel niets in vergelijking met een mens(hooguit enkele 10-tallen euros per maand).

Ik denk dat mensen "slecht" programmeren omdat het zo laagdrempelig is om even snel iets te proberen. En als het dan werkt laat je het daarbij en kan een prototype in een product terecht komen. In iedere andere sector heb je veel hogere kosten voordat je iets bruikbaars hebt dus moet er veel zorgvuldiger gewerkt worden. Plus dat er veel meer (al dan niet wettelijke) kaders zijn waarbinnen je moet werken. Als software op dezelfde manier gemaakt zou worden als bijvoorbeeld auto's of elektronische producten dan zal de kwaliteit, ook als het door mensen wordt gemaakt, veel beter zijn.

[wiemelen]

R_Zwart schreef op zaterdag 11 juli 2026 @ 16:04:
[...]

Ik denk dat mensen "slecht" programmeren omdat het zo laagdrempelig is om even snel iets te proberen. En als het dan werkt laat je het daarbij en kan een prototype in een product terecht komen. In iedere andere sector heb je veel hogere kosten voordat je iets bruikbaars hebt dus moet er veel zorgvuldiger gewerkt worden. Plus dat er veel meer (al dan niet wettelijke) kaders zijn waarbinnen je moet werken. Als software op dezelfde manier gemaakt zou worden als bijvoorbeeld auto's of elektronische producten dan zal de kwaliteit, ook als het door mensen wordt gemaakt, veel beter zijn.

Dit is dus ook de reden dat wij pertinent weigeren om niet-programmeurs programmeer autorisatie te geven. Afgelopen paar jaar hebben we al meerdere externe functionele consultants gehad die verontwaardigd waren omdat ze zelf niet snel snel wat mochten aanpassen in ons systeem. Maar 22 jaar consutant en 28 jaar programmeer ervaring heeft mij geleerd hoe "goed" de programmeerskills van functionele consultants en (helaas) van talloze programmeurs echt is.

Nu met het hele AI vraagstuk zijn wij ook aan het nadenken hoe wij best onze herbruikbare en generieke custom code componenten en templates kunnen in kaart brengen zodat AI bij het genereren van code hier ook gebruik van maakt. Het heeft namelijk geen zin dat AI code uitspuwt die enerzijds logica bevat waarvoor wij reeds een goede, herbruikbare maatwerk oplossing voor hebben. Anderzijds kijken wij bij iedere custom functionaliteit of er (deels) logica in zit die hoogstwaarschijnlijk in de toekomst kan herbruikt worden op andere plekken. Daar nemen we dan gelijk de tijd voor om daar een generiek component voor te bouwen.
Zeer tegen de zin trouwens van enkele zogenaamde "agile puristen" die claimen dat je pas iets generiek moet maken zodra er effectief hergebruik is. Gelukkig is mijn "hergebruik glazen bol" zo effecient dat ze tegenwoordig meestal hun mond houden.

[ Voor 4% gewijzigd door wiemelen op 11-07-2026 16:56 ]

[pieter.a]

R_Zwart schreef op zaterdag 11 juli 2026 @ 16:04:
[...]

Ik denk dat mensen "slecht" programmeren omdat het zo laagdrempelig is om even snel iets te proberen. En als het dan werkt laat je het daarbij en kan een prototype in een product terecht komen.

Er zijn makkelijk tientallen redenen te benoemen waardoor we "slechte" door mensen gemaakte code tegen komen.

[Kist]

De vraag is natuurlijk dan wel hoe goed is die AI gegenereerde code dan echt? Ik zie de afgelopen jaren de problemen die door mijn testers(test lead perspectief) wordt gevonden significant toenemen. En ja dat loopt parallel aan de hoeveelheid AI gebruik van onze bouwers.

En dan praten we op sommige type features over honderden procenten meer dan we een jaar of twee geleden zouden hebben gevonden. Vaak ook meer op kritieke paden.

Door ons type applicatie(we hebben geen noemenswaardige voorkant) is het ook niet zo dat we gebruik maken van agents die voor ons allerlei paden door de voorkant lopen.

We zien ook een vals vertrouwen bij veel developers. Dan wordt bijvoorbeeld letterlijk gevraagd, joh wat heb je gedaan aan error handling, en dan krijg je een heel relaas over hoe dat allemaal gedaan wordt. Vervolgens kijk je paar minuten naar het endpoint en dan zie je dat niks conform spec is afgehandeld en dat door kleine verschillen het grote problemen elders zal veroorzaken. Komt het leuk door je lokale tests maar daar hebben we weinig aan.

[Hillie]

Als ik de reacties zo eens lees dan bekruipt mij het idee dat menigeen denkt dat AI een soort single-shot oplossing is, terwijl je als menselijke ontwikkelaar iteratief aan zaken werkt.

Zelf ben ik alweer een paar decennia actief in de chipontwikkeling, front end digitale design verificatie. Ik werk sinds korte tijd bij een AI startup waar iedereen eigenlijk vrije keuze heeft in het gebruik van AI hulpmiddelen of niet. Zelf ben ik jaren geïnteresseerd doch terughoudend geweest, maar inmiddels tik ik vrij weinig code zelf meer, maar ik stuur aan en beslis over hoe en wat. Het mooie is eigenlijk ook wel dat je veel sneller zaken op kunt zetten en bij kunt stellen. Ook het abstraheren naar generieke en/of common componenten gaat vlot. Sterker nog, dat heb ik de laatste weken ook gedaan. Een aantal collega's had eigen componenten gebouwd voor een generieke interface, ieder met net kleine zaken anders (vooral in de API en gebruiksgemak). Dat heb ik in een paar slagen met m'n maat Claude in een generieke component gebruikt en het mooie is dat die ook automatisch opgepikt wordt in andere projecten door de AI. Ook weer teruggeintegreerd in de omgevingen van collega's en ik heb exact 0 klachten gehad dat iets niet meer werkte.

Maar voor dat laatste is de menselijke input belangrijk. Je moet nog altijd iteratief te werk blijven gaan. Die droom van een single shot oplossing zie ik ook weleens voorbijkomen, maar dat hangt dan wel af van een volledig duidelijke probleemstelling en specificatie. En dat is vaak onmogelijk. En in de dagelijkse realiteit van velen waarin specificaties en wensen van klanten geregeld veranderen is een iteratieve aanpak gewoon noodzakelijk. Voor AI begonnen we ook niet volledig opnieuw als er een paar dingen bijgesteld werden. Op dat punt zijn de tools gelukkig ook goed genoeg. Ik laat geregeld analyse uitvoeren op documentatie en implementatie en het aanpassen van bestaande code base gaat heel goed. Wel blijft het natuurlijk zaak om zelf grenzen te stellen in wat gedaan moet worden, net zoals je een externe inhuur geen vrije hand geeft om alles maar naar wens en eigen interpretatie aan te passen.

En daar zie ik een punt waar de huidige tools nog kunnen groeien, interpretatie en redeneren. De AI wil soms weleens teveel in de eerste prompt/suggestie blijven hangen, of een punt wat voor mensen duidelijk nog open is toch maar te interpreteren. Ook de overtuiging van het eigen gelijk versus het om input vragen mag nog weleens beter. Misschien (waarschijnlijk) ligt dat ook aan mijn persoonlijke (on)vermogen tot betere prompts of configuratie. Al doende leert men. Maar ik verwacht wel dat er verbetering blijft komen in de menselijke interactie en interpretatie.

[Wozmro]

Zou een AI-agent dan ook niet goed in staat moeten zijn om de afgesproken kaders in de gaten te houden, dat iedereen zich daaraan houdt, zowel de mens als een andere AI?

Dat je een waarschuwing krijgt als je iets wil aanpassen wat niet binne de afspraken valt?

Iedereen is wel eens verstrooid of het moet snelsnel, doen wel later nog wel eens deftig,...

[Liegebeest]

Hillie schreef op zondag 12 juli 2026 @ 17:29:
En daar zie ik een punt waar de huidige tools nog kunnen groeien, interpretatie en redeneren. De AI wil soms weleens teveel in de eerste prompt/suggestie blijven hangen, of een punt wat voor mensen duidelijk nog open is toch maar te interpreteren. Ook de overtuiging van het eigen gelijk versus het om input vragen mag nog weleens beter. Misschien (waarschijnlijk) ligt dat ook aan mijn persoonlijke (on)vermogen tot betere prompts of configuratie. Al doende leert men. Maar ik verwacht wel dat er verbetering blijft komen in de menselijke interactie en interpretatie.

Je vraagt daar om een bewustzijn, wat er niet is. Het is geen rationeel, denkend iets; het is en blijft een tekstgenerator.

Wat betreft het “blijven hangen in een prompt”: meerdere mensen hebben gewaarschuwd voor wat er gebeurt met een lange context. De een noemt het “the dumb zone”, een ander stelt dat je de belangrijkste dingen aan het begin en het eind van de context moet hebben, omdat modellen minder waarde hechten aan “het middenstuk”.

[Furion2000]

Mijn grootste 'valkuil' blijft dat AI te graag wil gaan en guardrails (MUST / SHOULD) stiekem toch vaak weer in verval raken. Als in ik heb een regel dat hij een functie moet testen maar heb claude al meerdere keren moeten zeggen dat die 25 testen voor een simpele functie overkill zijn. Mijn context zal vast niet helemaal optimaal zijn, maar imo ligt het niet alleen daar aan. Zelfde als de responses, vaak te langdradig, ondanks dat ik wil dat hij bondig reageert.

Ben wel benieuwd naar de nadelen die anderen ervaren tijdens het programmeerwerk.

[Reinier]

Vijf taalfouten in de topictitel plus de eerste zin van de openingspost. Wat zijn we allemaal blij met AI
We hoeven niet meer na te denken en inderdaad worden we allenaal steeds dommer en luier.
Ik ben inmiddels zo ver dat ik AI-geile collega's niet meer help als ze ergens niet uitkomen en Claude/ChatGPT/Copilot/etc. ze niet meer kunnen helpen

/rant

[Pieter.txt]

Glashelder schreef op vrijdag 10 juli 2026 @ 12:03:
[...]

Niet. Je laat de code beoordelen door andere AI. Elke developer zal beamen dat het kut is om code van anderen te lezen en dat is niet anders met AI code.

Dit is gewoon een soortgelijke discussie als toen C kwam en Assembly eruit ging. En toen unmanaged talen voor veel projecten werden ingeruild door managed. Nu zetten we een veel grotere stap: geen eigen code schrijven.

Die vergelijking gaat IMHO toch mank. Bij de stap van de ene programmeertaal naar de andere veranderd weliswaar de taal, maar de programmeur moet zelf blijven nadenken. Ik zie meer in de vergelijking tussen zelf een verbouwing uitvoeren of dat laten doen door een aannemer. In het eerste geval snap je precies hoe alles werkt en hoe het in elkaar zit. Als er dan iets niet werkt, dan weet je veel beter waar je moet zoeken. Dit in tegenstelling tot wanneer je een aannemer alles laat doen en jij nog steeds twee linker handen hebt.

De uitdaging met AI is dan ook dat we naast technical debt nu ook last krijgen van cognitive debt. Zoals iemand anders al schreef, de code van anderen lezen en vooral begrijpen is vaak erg lastig. Onderzoek van onder meer Anthropic laat dit ook zien. Naar mate de complexiteit van de te schrijven code toeneemt, neemt de tijdswinst van het gebruik van AI t.o.v. ontwikkelaars af. Het echte probleem zit erin dat de groep die AI gebruikt slechter scoort op begrip van de code, het doen van onderhoud of uitbreidingen en debugging.

Nu is dit gemeten m.b.v. ontwikkelaars die, naar ik aanneem, allemaal zijn "opgegroeid" zonder AI en dus nog handson ervaring hebben met programmeren en zaken als design patterns. Ik vraag me af hoe iemand zoiets als het visitor-pattern goed gaat leren als AI alles voor hem doet. En kun je dat dan nog beoordelen als je in het rijtje "see one, do one, teach one" nooit voorbij "see one" komt?

[Glashelder]

Reinier schreef op maandag 13 juli 2026 @ 09:11:
Vijf taalfouten in de topictitel plus de eerste zin van de openingspost. Wat zijn we allemaal blij met AI
We hoeven niet meer na te denken en inderdaad worden we allenaal steeds dommer en luier.
Ik ben inmiddels zo ver dat ik AI-geile collega's niet meer help als ze ergens niet uitkomen en Claude/ChatGPT/Copilot/etc. ze niet meer kunnen helpen

/rant

Hoeveel zullen dat er geweest zijn zonder AI en/of spellingcontrole? Waarschijnlijk nog meer.

@Pieter.txt goede punten, waar we als ontwikkelaars mee om moeten leren gaan. Ik denk persoonlijk niet dat de oplossing zal blijven liggen in menselijke reviews, maar eerder in de modellen leren hoe ze goede onderhoudbare oplossingen bouwen, waarbij wij als mensen hier niet over na hoeven denken. In plaats daarvan hebben we goede controlevragen nodig waarbij het model zelf gaat reflecteren (of een ander model).

Ik verwacht echter wel dat zaken als techical debt veel minder een rol gaan spelen, net zoals geheugengebruik vandaag de dag nauwelijks nog een rol speelt terwijl dat vroeger heel belangrijk was. Simpelweg omdat het contextwindow van LLM's groter en groter wordt en de snelheid waarmee tokens worden uitgepoept zal ook steeds hoger worden. Who cares over dat kleine beetje technical debt dan? En als niemand je code nog leest, who cares, zolang de LLM het maar begrijpt.

[edie]

De "prompt" is gewoon de nieuwe hype in programmeertaalland. Met als enige probleem dat de output niet consistent is en praktisch altijd achterloopt op de ontwikkelingen, want de nieuwe ontwikkelingen zitten niet in de statistieken van de tekstgenerator.

Plus het is volkomen onzinnig: prompt -> statistisch gegenereerde code in bepaalde taal -> compiler -> machinecode. Waarom kan dat ding niet meteen machinecode genereren? Dat zou toch veel efficienter zijn? Het enige dat we nu hebben gedaan is een extra stap toegevoegd aan het begin van de softwareontwikkeling... Lekker efficient bezig mensen!

[Corrit]

edie schreef op maandag 13 juli 2026 @ 09:59:
De "prompt" is gewoon de nieuwe hype in programmeertaalland. Met als enige probleem dat de output niet consistent is en praktisch altijd achterloopt op de ontwikkelingen, want de nieuwe ontwikkelingen zitten niet in de statistieken van de tekstgenerator.

Plus het is volkomen onzinnig: prompt -> statistisch gegenereerde code in bepaalde taal -> compiler -> machinecode. Waarom kan dat ding niet meteen machinecode genereren? Dat zou toch veel efficienter zijn? Het enige dat we nu hebben gedaan is een extra stap toegevoegd aan het begin van de softwareontwikkeling... Lekker efficient bezig mensen!

Daar ben ik het niet mee eens. Ik gebruik claude regelmatig om stukjes code te schrijven en vind het toch wel verdomd handig dat claude leesbare code produceert die ik zelf nog even kan doorlezen en checken op correctheid. En als ik dan nog labelteksten of kleuren oid wil aanpassen dan doe ik dat rechtstreeks in de code en hoef ik het niet aan claude te vragen.

Efficiënte code klinkt leuk maar is pas zinvol als het (honderd)duizenden keren wordt uitgevoerd. Voor veruit de meeste toepassingen is het veel belangrijker dat de functionaliteit controleerbaar is dan dat het stukje software zo snel mogelijk werkt. (en ik ben iemand die vaak zit te vloeken op trage software )

[Hillie]

Liegebeest schreef op maandag 13 juli 2026 @ 06:34:
[...]

Je vraagt daar om een bewustzijn, wat er niet is. Het is geen rationeel, denkend iets; het is en blijft een tekstgenerator.

Nee, ik vraag "slechts" om nog betere interpretatie en aanpassing aan de persoon aan de prompt. Het verschil met een jaar en twee jaar terug is al enorm en ik verwacht dat die verbetering nog wel een tijdje door blijft zetten.

Wat betreft het “blijven hangen in een prompt”: meerdere mensen hebben gewaarschuwd voor wat er gebeurt met een lange context. De een noemt het “the dumb zone”, een ander stelt dat je de belangrijkste dingen aan het begin en het eind van de context moet hebben, omdat modellen minder waarde hechten aan “het middenstuk”.

Daarom schrijf ik een paar zinnen en blijf aanpassen/verbeteren, de iterative aanpak. Ik lees overigens nauwelijks wat de zogeheten experts vinden, dat zijn over het algemeen net zulke krabbers in de marge als ik, alleen hebben zij een paar maanden extra ervaring.

Wat me sinds het begin al stoort is hoe makkelijk de engines overtuigd zijn van de correctheid van foutieve interpretatie, maar dan ook weer meteen het roer omgooien als je tegengas geeft. Meer terughoudendheid en terugkoppeling zou wel prettig zijn.

[Stukfruit]

Wozmro schreef op zondag 12 juli 2026 @ 18:26:
Zou een AI-agent dan ook niet goed in staat moeten zijn om de afgesproken kaders in de gaten te houden, dat iedereen zich daaraan houdt, zowel de mens als een andere AI?

Het automatiseren van de automatisering inderdaad

Zelfs met een agent erbij een tijdrovende klus...

Iedereen is wel eens verstrooid of het moet snelsnel, doen wel later nog wel eens deftig,...

Zodra je programmeerwerk als tool gaat zien om echte problemen mee op te lossen dan is dat sowieso geen uitdaging meer

Voor een agent is je code context. Niet in metaforische zin, maar letterlijk. Het is puur context.

Dus als je begint met slechte code maar zelf de skills hebt om te vertellen hoe het beter moet (of de skills hebt om te vragen hoe het beter moet ) dan krijg je door de werking van taalmodellen ook de effecten van compounding: is de code die je als input gebruikt goed of beter, dan wordt natuurlijk ook automatisch dat patroon vaker gevolgd dan wanneer je ongecontroleerde spaghetti laat genereren.

Uiteraard moet je dat alsnog onder toeziend oog doen, maar langdurige refactors waarbij je 2 weken met 50 tabs open zat om het werk te verrichten dat nodig was om eindelijk en überhaupt te kunnen beginnen aan feature X zijn nu wel een beetje voorbij.

2 uur laten refactoren, uurtje controleren, daarna beginnen met de feature.

[Stukfruit]

Maar het belangrijkste is echt dat je die IDE er weer bij pakt en niet achter de tool van Claude gaat zitten slapen.

Dat is de grootste fout die je kan maken.

[Hillie]

Stukfruit schreef op maandag 13 juli 2026 @ 12:21:
Maar het belangrijkste is echt dat je die IDE er weer bij pakt en niet achter de tool van Claude gaat zitten slapen.

Dat is de grootste fout die je kan maken.

Dat is denk ik wel de kern en zodra je dat niet doet is het heel makkelijk het overzicht kwijt te raken.

[Marc3l]

Stukfruit schreef op maandag 13 juli 2026 @ 12:21:
Maar het belangrijkste is echt dat je die IDE er weer bij pakt en niet achter de tool van Claude gaat zitten slapen.

Dat is de grootste fout die je kan maken.

Dat zeker, anders ben je net zoals 'vroeger' aan het copy/pasten van bijvoorbeeld Stack Overflow. 
Mijn Claude is ook Italiaans, hij maakt graag spagetti, maar is ook niet vies van 
functies bedenken die niet bestaan voor een taal waar ik mee bezig ben.

edie schreef op maandag 13 juli 2026 @ 09:59:
De "prompt" is gewoon de nieuwe hype in programmeertaalland. Met als enige probleem dat de output niet consistent is en praktisch altijd achterloopt op de ontwikkelingen, want de nieuwe ontwikkelingen zitten niet in de statistieken van de tekstgenerator.

Nee, zeker geen hype, het is zeker wel iets wat je tijd bespaart.
Maar niet alleen code schrijven, ook herhalende taken. Ik heb bijvoorbeeld een opensource package.
Bij een update moet ik de code fixer runnen, testen runnen, git commit (bericht) maken, nieuwe tag aan maken, nieuwe release maken. Dit doe ik nu met 1 Claude skill.

[Liegebeest]

Hillie schreef op maandag 13 juli 2026 @ 12:19:
[...]. Wat me sinds het begin al stoort is hoe makkelijk de engines overtuigd zijn van de correctheid van foutieve interpretatie, maar dan ook weer meteen het roer omgooien als je tegengas geeft. Meer terughoudendheid en terugkoppeling zou wel prettig zijn.

maar dat is wat ik eerder zei: er is helemaal geen overtuiging. Er is niets aan de overkant dat is overtuigd van diens gelijk, want er is geen bewustzijn. Het is een tekstgenerator en die is gebouwd om zelfverzekerd te klinken en om beleefde tekst te schrijven wanneer iemand het niet eens is.

[edie]

Marc3l schreef op maandag 13 juli 2026 @ 15:05:

[...]

Nee, zeker geen hype, het is zeker wel iets wat je tijd bespaart.
Maar niet alleen code schrijven, ook herhalende taken. Ik heb bijvoorbeeld een opensource package.
Bij een update moet ik de code fixer runnen, testen runnen, git commit (bericht) maken, nieuwe tag aan maken, nieuwe release maken. Dit doe ik nu met 1 Claude skill.

Dat specifiek kan ook met een simpel .bat of .sh scriptje (of met een custom task binnen je favoriete IDE). Geen LLM voor nodig, en nog sneller, voorspelbaarder en goedkoper ook.

Juist herhalende zaken zijn veel beter te automatiseren via scripts of templates dan het via een LLM te laten doen. Hier op het werk ook: wordt gepoogd om Claude een 'standaard web api project' te laten genereren met onze eigen code/libraries/configuratie al volledig klaar. Heeft meerdere weken aan prompts gekost. Ondertussen had men ook ook in 5 minuten gewoon een template kunnen maken van een bestaand project welke vervolgens te selecteren is bij nieuwe projecten.

[Marc3l]

edie schreef op maandag 13 juli 2026 @ 16:13:
[...]

Dat specifiek kan ook met een simpel .bat of .sh scriptje (of met een custom task binnen je favoriete IDE). Geen LLM voor nodig, en nog sneller, voorspelbaarder en goedkoper ook.

Juist herhalende zaken zijn veel beter te automatiseren via scripts of templates dan het via een LLM te laten doen. Hier op het werk ook: wordt gepoogd om Claude een 'standaard web api project' te laten genereren met onze eigen code/libraries/configuratie al volledig klaar. Heeft meerdere weken aan prompts gekost. Ondertussen had men ook ook in 5 minuten gewoon een template kunnen maken van een bestaand project welke vervolgens te selecteren is bij nieuwe projecten.

Deels, een commit message maken aan de hand van de staged code niet.
Ik heb Claude Pro en ga zelden door mijn (sessie)tokens heen.

[Hillie]

edie schreef op maandag 13 juli 2026 @ 16:13:
[...]

Dat specifiek kan ook met een simpel .bat of .sh scriptje (of met een custom task binnen je favoriete IDE). Geen LLM voor nodig, en nog sneller, voorspelbaarder en goedkoper ook.

Juist herhalende zaken zijn veel beter te automatiseren via scripts of templates dan het via een LLM te laten doen. Hier op het werk ook: wordt gepoogd om Claude een 'standaard web api project' te laten genereren met onze eigen code/libraries/configuratie al volledig klaar. Heeft meerdere weken aan prompts gekost. Ondertussen had men ook ook in 5 minuten gewoon een template kunnen maken van een bestaand project welke vervolgens te selecteren is bij nieuwe projecten.

Daar gaat het dus duidelijk om slimme en juiste keuzes maken. Als je kunt scripten dan is dat meestal duidelijk de betere keuze. En dan kun je Claude het script laten schrijven.

Overigens is Claude gelukkig al voorzien van aardig wat middelen om te bepalen wanneer te scripten als het zelf met iets bezig gaat. Dat scheelt ook alweer een hoop onzin.

[Kurkentrekker]

Om dan toch nog even in te gaan op de vraag die in de topictitel centraal staat: wat is het effect van AI op het carrièreperspectief van softwareontwikkelaars: ik denk dat die best wel groot is. Er zijn, zoals in de reacties hierboven ook ruimschoots aangetoond, veel situaties denkbaar waarbij de mens nog veel moet bijsturen. Waarbij kennis van onderliggende systemen, principes en best practices echt heel relevant is. Toch denk ik dat AI, met name de manier waarop het nu kan programmeren, een enorm effect zal hebben op de carrièreperspectieven van softwareontwikkelaars. (Overigens, @Reinier, het is vaak de AI-spellingscontrole die nutteloze spaties juist toevoegt! Kots-emoji… Maar bedankt voor je observatie)

De reden dat AI zo’n groot effect zal hebben is dat het een heel groot deel van de vraag in de markt kan doen afnemen. Ja, een groot deel van de markt bestaat uit ontwikkelaars die dingen maken die je niet gemakkelijk bij elkaar kunt promoten (misschien nog wel efficiënter kunt laten doen). Maar een zeer groot deel van de markt bestaat ook gewoon uit eenvoudig werk. Een simpel tooltje in de bedrijfsvoering hier, een CRUD-systeempje daar, een CMS-je, allemaal kleine projecten die vroeger gerust duizenden euro’s aan maatwerk kostten, en nu zo in een avondje door Claude in elkaar gezet worden. Dat is niet spannend, maar een aanzienlijk deel van de  softwareontwikkelaars zijn gewoon het grootste deel van hun werkweek bezig met dit soort projecten. En die carrières zijn echt wel eindig. Niet allemaal, maar hetzelfde (of een beter) resultaat kan ook met een kwart van de mensen worden bereikt.

Waar leidt dat toe? Een grote verschuiving op de arbeidsmarkt: als softwareontwikkelaars ineens niet meer schaars zijn omdat alle figuren die vroeger Wordpress sites zaten te programmeren nu ineens nieuwe banen gaan zoeken, dan wordt de markt een stuk competitiever. Dan kun je dus niet meer met je BSc software engineering tekenen bij het kruisje, je lease-BMW ophalen, en 3x modaal verdienen in je startersfunctie.

Natuurlijk, er blijft heus werkgelegenheid voor de mensen die echt handig zijn en aan systemen werken die niet gemakkelijk kunnen worden gerund of onderhouden door AI-agents, maar de arbeidsmarkt zal er niet makkelijker op worden. Ik denk dus dat er een soort tweedeling zal kunnen ontstaan: de mensen die de echt complexe shit maken zullen misschien nog wel waardevoller worden (omdat juniors niet meer echt worden opgeleid en de eisen van de markt aan enterprise grade software alleen maar zullen toenemen), en dat de ontwikkelaars die vooral commodity-achtige applicaties maken juist enorm zal verslechteren. AI schrijft immers betere wegwerpcode.


Ps; geen AI gebruikt bij het schrijven van deze post. ik zeg het er maar even bij.

[Stukfruit]

Kurkentrekker schreef op maandag 13 juli 2026 @ 23:26:
AI schrijft immers betere wegwerpcode.

Daarom is ook daar aansturing (menselijk of geautomatiseerd) nodig om te voorkomen dat die code geschreven moet worden.

Als ik een dashboardje wil, dan verwacht ik iets in Grafana (intern) of zoiets als Refine (meer voor eindgebruikers), omdat je anders met een berg code en tests (zelfs BDD) eindigt die je zelf moet managen omdat een agent maar een beperkte aandachtsspanne kan hebben. Dat gaat vast nog omhoog, maar het is nu eenmaal hoe de achterliggende techniek werkt.

De beste code is code die je niet hoeft te schrijven. Dat blijft met een agent erbij en 17k tokens per seconde nog steeds staan omdat code niet alleen schrijf(generatie)werk is. Je moet de fouten eruit halen, het moet doen wat nodig is (en dat blijven doen), het moet efficiënt of snel kunnen draaien, je wil het kunnen hergebruiken omdat genereren onzinnige tijdverspilling is...

[Sissors]

Dan kun je dus niet meer met je BSc software engineering tekenen bij het kruisje, je lease-BMW ophalen, en 3x modaal verdienen in je startersfunctie.

Nu verwar je volgens mij Amerika met Europa. Op uitzonderingen na zijn de salarissen hier nooit zo geweldig geweest, en ik denk dat gemiddelde HBO'er blij is met een modaal salaris bij zijn startersfunctie. En juist degene die 3x modaal ging verdienen na zijn studie (oké niemand, 1.5x modaal dan), zal dat blijven doen, omdat de goede alleen maar productiever kunnen zijn. En natuurlijk er is meer aanbod op de markt. Maar laten we wel wezen, er is ook geen enkel andere engineering functie waarbij je ook communicatiewetenschappen kan studeren, een traineeship van een maand krijgen, en instromen.

[wiemelen]

De arbeidsmarkt heeft ook de neiging om zichzelf in evenwicht te houden.
Ik heb net even gezocht naar artikels over een verminderde in/uitstroom van studenten in IT richtingen. Blijkt toch dat er nu al een verminderde instroom zichtbaar is.
Benieuwd wat dit voor de toekomst gaat betekenen. De tijd van de gouden bergen zijn misschien voorbij, maar je hebt nog steeds (junior) IT'ers nodig, al is het bij bedrijven (veelal MKB), waar IT of automatisering nog steeds een vies of onbekend woord is. En zeker ook op bestaande posities waar AI zeker nog wel even tijd nodig heeft om goed te landen, waardoor de IT-ers zelf ook de tijd hebben om zich aan te passen aan de veranderende wereld (net zoals we al jaren doen).

• Digitaal Talent Nederland (10 feb 2026) – instroom HBO-ICT daalt met 14,4%.
  https://digitaaltalentned...-hbo-ict-vraagt-om-actie/
• BeInCrypto (20 jun 2026) – studenten verlaten informatica wegens angst voor AI-gerelateerd banenverlies.
  https://nl.beincrypto.com...ppen-inschrijving-daling/
• TechCrunch (15 feb 2026) – "The great computer science exodus (and where students are going instead).
  https://techcrunch.com/20...udents-are-going-instead/

[CVTTPD2DQ]

Sissors schreef op dinsdag 14 juli 2026 @ 08:34:
Nu verwar je volgens mij Amerika met Europa. Op uitzonderingen na zijn de salarissen hier nooit zo geweldig geweest, en ik denk dat gemiddelde HBO'er blij is met een modaal salaris bij zijn startersfunctie. En juist degene die 3x modaal ging verdienen na zijn studie (oké niemand, 1.5x modaal dan), zal dat blijven doen, omdat de goede alleen maar productiever kunnen zijn. En natuurlijk er is meer aanbod op de markt. Maar laten we wel wezen, er is ook geen enkel andere engineering functie waarbij je ook communicatiewetenschappen kan studeren, een traineeship van een maand krijgen, en instromen.

Maar wat is ‘goed’?

Vanaf het moment dat mensen de term ‘software engineering’ gingen gebruiken, werd al opgemerkt dat programmeurs relatief veel van hun tijd dezelfde problemen (al dan niet correct) oplosten. En dat het proces zoveel efficiënter zou zijn als er standaardmethoden werden gebruikt. In volgorde zijn de volgende zaken geprobeerd:

1. boeken, bijvoorbeeld Numerical Recipes of de boeken van Knuth. Dat recipes ‘recipes’ heet is al een indicatie dat het geen goed idee is om er zelf je eigen creatieve variant op te bedenken
2. Object-oriented programmeren één van de motivaties achter de hype was dat er een markt zou ontstaan voor componenten die, net als ICs, aan elkaar konden worden gekoppeld zonder te hoeven begrijpen hoe ze intern werkten. In plaats daarvan kregen we een combinatorische explosie van puzzelstukjes die op geen enkele manier in elkaar pasten.
3. Service-oriented architectures zodat je functionaliteit bij een derde partij on-demand kunt aanroepen, in plaats van zelf implementeren. Het resultaat is dat veel bedrijven een ‘service-landschap’ hebben van intern gebouwde services die vooral met elkaar praten.
4. Open Source en Stack Overflow om de barrière voor hergebruik nóg lager te maken.

Al die oplossingen draaiden om integratie, en alle integraties hebben nadelen: het begrijpen van de integratie kost zelf tijd, en redeneren over een black box is moeilijker (dus er is een grens waaronder integratie van een kleine component simpelweg niet rendabel is). De belangrijkste is natuurlijk churn, het continu bijwerken van de integraties naar nieuwere versies. Of niet, het laten versloffen, alle bugs en securityproblemen op de koop toenemen.

Het beroep van ‘software-developer’, ongeacht opleiding, convergeerde dus naar relatief eenvoudig en gelijkvormig onderhoudswerk. Misschien was iemand in staat om moeilijke nieuwe algoritmes te bedenken: jammer dan, de meeste bedrijven hebben geen moeilijke nieuwe algoritmes nodig. Een bootcamper was eigenlijk ook wel goed. En de salarissen kónden eenvoudigweg niet superhoog zijn, omdat de toegevoegde waarde zo laag was.

Een ‘goede’ developer in deze wereld was iemand die goed bestaande componenten kon integreren. Een goedverdienende was een developer die er heel snel in was, maar telkens weg was voordat die integratie door churn onrendabel werd in het onderhoud.

En dan nu LLMs, de ultieme patroonherkennende copy-paste machine. Als ik nog iets cynischer
zou zijn, zou ik me afvragen wat programmeurs nu weer zullen verzinnen om hun baantjes te kunnen behouden. Maar het is ook te zien als het antwoord op zestig, zeventig jaar aan pogingen om op een efficiënte manier software te ontwikkelen.

Ik ben het eigenlijk wel eens met @Glashelder : mensen hebben decennialang laten zien dat ze niet zo goed zijn in programmeren. En ik wil toevoegen, we zijn abominabel slecht in software engineering.

Er zal vast wel iets van menselijk werk in software development overblijven (net zoals er nog een paar timmermannen en hoefsmeden zijn), maar het is moeilijk om je voor te stellen hoe dat eruit zal zien. Of zelfs maar wat een ‘goede’ software developer is in deze situatie: de kwaliteiten die je eerst ‘goed’ maakten zijn nu niet zo belangrijk meer.

Verder vermoed ik dat het een kwestie van tijd is voordat aansprakelijkheid en wetgeving ertoe leiden dat bedrijven het als risico gaan beschouwen om code te leveren / draaien die niet door een LLM is nagelopen op securityproblemen.

LLMs zijn misschien niet de intelligentste securityanalisten, ze hebben wel het vermogen om onbeperkt hun volledige aandacht aan een probleem te geven, en dat effect zien we nu met de stortvloed aan CVEs die over ons wordt uitgestort (wat weer leidt tot churn, wat weer leidt tot meer werk voor mensen die ‘traditioneel’ werken).

Op termijn zal alles wat nu in software gebeurt natuurlijk gebeuren met banen die zich voornamelijk in het digitale domein afspelen. Doe je je werk op een computer en wordt het resultaat op een computer opgeslagen? Draait het om patroonherkenning en redeneren? Kijk maar uit

[wiemelen]

CVTTPD2DQ schreef op woensdag 15 juli 2026 @ 07:52:
Een ‘goede’ developer in deze wereld was iemand die goed bestaande componenten kon integreren. Een goedverdienende was een developer die er heel snel in was, maar telkens weg was voordat die integratie door churn onrendabel werd in het onderhoud.

Dat is 1 van de grote issues van externe consultants/programmeurs.
Ze verzinnen iets, maar blijven niet lang genoeg hangen om de rotzooi achteraf op te ruimen of te leren uit hun fouten. En op hun volgende project herhalen ze exact dezelfde fout "want het werkt op een vorig project".
In mijn ogen moet een goede programmeur/oplossing niet zorgen voor de allerbeste/allersnelste/modernste oplossing. Alle programmeurs binnen 1 team/bedrijf moeten achter dezelfde visie staan die er voor zorgt dat er een goede, onderhoudbare (ook door juniors), gedocumenteerde, gebruiksvriendelijke oplossing komt, liefst met gebruik van generieke, herbruikbare, makkelijk te onderhouden (custom) componenten. Een soort "future proof" oplossing waarbij toekomstige wijzigingen makkelijk en snel te integreren zijn.
In mijn ervaring kan dit perfect in praktijk toegepast worden met gebruik van "gezond verstand", ervaren programmeurs die voor langere tijd blijven en een management dat hier ook in volgt.
Helaas ontbreekt 1 van deze schakels in vele bedrijven.

En dan nu LLMs, de ultieme patroonherkennende copy-paste machine. Als ik nog iets cynischer
zou zijn, zou ik me afvragen wat programmeurs nu weer zullen verzinnen om hun baantjes te kunnen behouden. Maar het is ook te zien als het antwoord op zestig, zeventig jaar aan pogingen om op een efficiënte manier software te ontwikkelen.

Ik ben het eigenlijk wel eens met @Glashelder : mensen hebben decennialang laten zien dat ze niet zo goed zijn in programmeren. En ik wil toevoegen, we zijn abominabel slecht in software engineering.

Het zullen net de goede programmeurs zijn die LLM's slimmer gaan maken ... en het zullen net de minder goede programmeurs zijn die er voor zorgen dat bedrijven LLM's blijven gebruiken ter verbetering van hun code.

Verder vermoed ik dat het een kwestie van tijd is voordat aansprakelijkheid en wetgeving ertoe leiden dat bedrijven het als risico gaan beschouwen om code te leveren / draaien die niet door een LLM is nagelopen op securityproblemen.

Wat dan zoals zo vaak uitdraait op een wassen neus.
Ik werk in een bedrijf waar "security en autorisatie" zwaar onder de loep ligt en alles dichtgezet wordt, o.a. o.b.v. audits van externe "security experts", penetration tests en ethische hackers. Blijkt dat wij als programmeurs (met interne functionele en technische kennis) toch telkens nieuwe gaten vinden of manieren waarop we dingen kunnen omzeilen (wat dan telkens ook mooi gemeld en opgelost wordt).
Dus een LLM zal vast een lijst van aanbevelingen en security/autorisatie issues kunnen checken (net zoals de scripts van audits nu ook al doen) en zeker tot verbeteringen leiden, de mens achter de knoppen heeft het voordeel van creativiteit die een LLM vooralsnog niet heeft.

[CVTTPD2DQ]

wiemelen schreef op woensdag 15 juli 2026 @ 10:44:
In mijn ogen moet een goede programmeur/oplossing niet zorgen voor de allerbeste/allersnelste/modernste oplossing. Alle programmeurs binnen 1 team/bedrijf moeten achter dezelfde visie staan die er voor zorgt dat er een goede, onderhoudbare (ook door juniors), gedocumenteerde, gebruiksvriendelijke oplossing komt, [...]

Dat is inderdaad een manier om software te ontwikkelen ... met mensen. In grotere bedrijven wordt het lastiger, omdat het moeilijker wordt om dezelfde 'visie' te delen met allerlei teams met verschillende taken en belangen, maar in dit scenario zijn de mensen de dragers van de kennis van en de visie op de systemen.

Heb je overwogen dat het veel voordelen voor een bedrijf heeft als je het zonder mensen kunt doen? Als de kennis over de systemen ergens opgeslagen ligt, en er ontwikkelcapaciteit is die je on-demand kunt aanschakelen (200 virtuele developers die 24 uur per dag doorploeteren ... of andersom, zes maanden lang in de pauzestand staan zonder dat het iets kost). Als kennis niet bij medewerkers ligt die zwanger of ziek kunnen worden, een wereldreis willen maken, of ergens anders een beter salaris krijgen?

wiemelen schreef op woensdag 15 juli 2026 @ 10:44:
Het zullen net de goede programmeurs zijn die LLM's slimmer gaan maken ... en het zullen net de minder goede programmeurs zijn die er voor zorgen dat bedrijven LLM's blijven gebruiken ter verbetering van hun code.

Leg eens uit hoe programmeurs die LLMs slimmer gaan maken. En welke programmeurs zijn dat, de programmeurs van Anthropic in Silicon Valley? Of onderbetaalde datamasseurs in Kenia? Welke rol hebben Nederlandse programmeurs daarin?

wiemelen schreef op woensdag 15 juli 2026 @ 10:44:
Wat dan zoals zo vaak uitdraait op een wassen neus.

Zeker. Maar dat maakt niet uit als die wassen neus verplicht wordt.

wiemelen schreef op woensdag 15 juli 2026 @ 10:44:
Dus een LLM zal vast een lijst van aanbevelingen en security/autorisatie issues kunnen checken (net zoals de scripts van audits nu ook al doen) en zeker tot verbeteringen leiden, de mens achter de knoppen heeft het voordeel van creativiteit die een LLM vooralsnog niet heeft.

Heb je later dan januari 2025 eens een coding tool gebruikt?

[Philip Ross]

CVTTPD2DQ schreef op woensdag 15 juli 2026 @ 18:31:
[...]


Dat is inderdaad een manier om software te ontwikkelen ... met mensen. In grotere bedrijven wordt het lastiger, omdat het moeilijker wordt om dezelfde 'visie' te delen met allerlei teams met verschillende taken en belangen,

Daar zijn zaken als programmeer afspraken voor. En standaarden.

maar in dit scenario zijn de mensen de dragers van de kennis van en de visie op de systemen.

Als de kennis over de systemen ergens opgeslagen ligt,

Als kennis niet bij medewerkers ligt die zwanger of ziek kunnen worden, een wereldreis willen maken, of ergens anders een beter salaris krijgen?

Die kennis is bij een degelijk bedrijf juist heel goed vastgelegd. Zeker bij grotere bedrijven moet dat wel.
Er bestaat ook zoiets als documentatie.

en er ontwikkelcapaciteit is die je on-demand kunt aanschakelen (200 virtuele developers die 24 uur per dag doorploeteren ... of andersom, zes maanden lang in de pauzestand staan zonder dat het iets kost).

Zolang het model consistent blijft, geen storing heeft, en niet afgesloten wordt door de regering van de VS.

[...]
Leg eens uit hoe programmeurs die LLMs slimmer gaan maken. En welke programmeurs zijn dat, de programmeurs van Anthropic in Silicon Valley? Of onderbetaalde datamasseurs in Kenia? Welke rol hebben Nederlandse programmeurs daarin?

Door de code die door LLMs gelezen en gestolen wordt te schrijven

[Nutral]

Ik denk dat omdat LLM's en AI gebruikt gaat worden om zoveel andere bedrijfstakken te automatiseren/vervangen van mensen er daardoor toch weer extra vraag gaat zijn naar software devs, door LLM's is software makkelijker te schrijven maar door LLM's word er ook meer software gebruikt.

Het is heel erg afhankelijk van de kwaliteit (en fouten) in hoe goed een LLM een business vraag/case kan omzetten naar code die goed werkt in dat domein.

[Kist]

Wel lachen. Allerlei grote bedrijven lopen er tegen aan dat agents een godsvermogen aan tokens kosten en dat daardoor het heel moeilijk zo niet onmogelijk is om ROI te zien.

Sterker nog die ROI wordt nu nog hoger geacht bij menselijke Devs.

Roept iemand hier non stop 24/7 honderden agents laten draaien.

Als je je bedrijf door het afvoerputje wil spoelen lijkt mij dat inderdaad een geweldig idee.

[ Voor 9% gewijzigd door Kist op 15-07-2026 19:17 ]

[Glashelder]

Er wordt ontzettend veel geëxperimenteerd en geprutst met AI. We staan aan het begin van de ontwikkelingen. Niet alleen de technische maar ook de menselijke kant: hoe gaan we ermee om?

Ik zie veel developers worstelen met AI. Vaak omdat ze eigenlijk niet eens goed weten wát ze nou willen bouwen maar dan wél van de AI goede resultaten verwachten.

[GoingDutch]

Hillie schreef op donderdag 11 juni 2026 @ 04:28:


Ben je zelf bekend met de Amerikaanse markt, of allemaal uit dezelfde soort bronnen? (YouTube zal je ook meer van hetzelfde geven als je een paar filmpjes hebt gezien).

Zelf woon en werk ik in de VS, bijna 17 jaar, maar uit eigen ervaring met kleine en grote organisaties merk ik dat men graag snel toeslaat bij goede kandidaten. 1000 sollicitaties en 0 resultaat, dan ben je als sollicitant het probleem.

Het probleem dat ik bij het overgrote merendeel van de juniors en stagiairs zie is dat men te slim denkt te zijn, door stiekem AI te gebruiken tijdens (remote) gesprekken, ondanks expliciete waarschuwing dat het niet is toegestaan en je afgewezen wordt.

Wat ik zie is dat getalenteerde engineers van junior tot principal/fellow niveau nog steeds erg gevraagd zijn. De krabbers die net voor de AI golf met een bootcamp cursusje aan de bak zijn gekomen, die hebben het zwaar. De talenten uitgezonderd natuurlijk.

Qua verdiensten is het in de VS ook nog steeds goed toeven.

Een wat late reactie maar m.i. is dit niet wat er werkelijk speelt. Als je 1000 sollicitaties verstuurd en 0 reacties krijgt ligt dat aan de markt en niet aan een individuele ontwikkelaar. Er zijn in de VS honderdduizenden ontwikkelaars ontslagen bij Meta, Google, Microsoft, etc. De markt is overspoeld met goede kandidaten en dan is het zo goed als onmogelijk om iets te vinden.

In de VS is wie je kent belangrijker dan wat je kunt en connecties zijn belangrijker dan kennis en ervaring. (Ik heb zelf in Austin, TX gewoond en ben onder andere ook door de slechte markt weer in Europa terecht gekomen). Silicon Valley is ook niet beter, eerder nog slechter.

Dit komt niet door AI overigens maar m.i. door de wereldwijde economische neergang, de algemene onzekerheid en politieke instabiliteit en dat er te veel ontwikkelaars zijn aangenomen in de home-office hype tijdens Corona.

In Duitsland speelt nu precies hetzelfde door massa ontslagen in de auto industrie, heel veel embedded ontwikkelaars zijn op straat komen te staan die zoekende zijn terwijl de markt nog steeds verder krimpt.

[CVTTPD2DQ]

Philip Ross schreef op woensdag 15 juli 2026 @ 18:48:
Daar zijn zaken als programmeer afspraken voor. En standaarden.

En dan krijg je consistentie, maar geen gedeeld begrip, omdat menselijk begrip eenvoudigweg niet zo schaalbaar is. Maar deze discussie gaat niet over de vele manieren waarop ‘best practices’ in software engineering het paard achter de wagen spannen.

Philip Ross schreef op woensdag 15 juli 2026 @ 18:48:
Zolang het model consistent blijft, geen storing heeft, en niet afgesloten wordt door de regering van de VS.

[...]


Door de code die door LLMs gelezen en gestolen wordt te schrijven

Ik vermoed dat de cloud-providers beschikbaarheidsgaranties kunnen geven waar de meeste mensen een puntje aan kunnen zuigen.

En het morele verhaal van LLMs klopt van geen kanten, dat ben ik met je eens. Maar de wet- en werkgevers zullen altijd partij kiezen voor degenen die gouden bergen beloven. En je ziet hoe ook in Europa de wetgevende macht maar al te graag water bij de wijn doet om de AI-bedrijven ter wille te zijn. Zelfs de GDPR blijkt ineens zo heilig niet meer.

Als we het belangrijk vinden dat mensen betrokken blijven bij ontwikkelwerk, zullen we toch echt met iets beter moeten komen dan een beroep op rechtvaardigheidsgevoel. We moeten kunnen uitleggen waarom software geschreven door mensen béter is dan de code uit een LLM.

Kist schreef op woensdag 15 juli 2026 @ 19:13:
Roept iemand hier non stop 24/7 honderden agents laten draaien.

Als je je bedrijf door het afvoerputje wil spoelen lijkt mij dat inderdaad een geweldig idee.

Wat denk je dat honderden developers kosten?

[crisp]

CVTTPD2DQ schreef op woensdag 15 juli 2026 @ 22:52:
[...]
Wat denk je dat honderden developers kosten?

Dat zijn in ieder geval nog uitgaven binnen de eigen economie

[CVTTPD2DQ]

crisp schreef op woensdag 15 juli 2026 @ 23:29:
Dat zijn in ieder geval nog uitgaven binnen de eigen economie

En daar krijgen we misschien de wetgevers mee, het geld gaat naar de eigen inwoners, die zelf kennis opbouwen en hun loon weer laten circuleren in de eigen economie, in plaats van dat het de kennis en bottom line van Silicon Valley groter maakt.

-knip- ongepast

Maar de werkgevers gaan roepen dat we niet kunnen concurreren, alsof we dat uberhaupt al konden vóór de uitvinding van LLMs.

Ik sta zelf op het punt dat het heel verstandig is dat mensen (ook) zélf over dingen blijven nadenken. maar alle trends wijzen toch de andere richting op.

[ Voor 7% gewijzigd door ZieMaar! op 16-07-2026 17:49 ]

[Philip Ross]

CVTTPD2DQ schreef op woensdag 15 juli 2026 @ 22:52:
[...]


En dan krijg je consistentie, maar geen gedeeld begrip, omdat menselijk begrip eenvoudigweg niet zo schaalbaar is.

Begrip heeft een LLM sowieso niet.
Begrip is ook niet nodig als je goede documentatie hebt, dan zoek je gewoon op wat je niet direct weet.

[...]
Ik vermoed dat de cloud-providers beschikbaarheidsgaranties kunnen geven waar de meeste mensen een puntje aan kunnen zuigen.

De cloud providers wel. Maar een groot bedrijf heeft ook een vrij hoge uptime van arbeidskrachten.
De LLM providers daarentegen zijn minder betrouwbaar.

En dan heb ik het nog niet over de inconsistentie van modellen. Dat nieuwe modellen die steeds komen weer net even anders (en soms slechter) werken.

Bovendien draaien alle LLM bedrijven nog miljarden per jaar verlies.
Dus de prijs van die modellen gaat nog een veelvoud omhoog.

[GoingDutch]

-knip- dit is wel erg generaliserend

De huidige LLMs zijn nu al veel beter dan de gemiddelde ‘ontwikkelaar’. Daarnaast hoeft een AI geen salaris, werkt rustig 24/7 door, is nooit vervelend, geeft meteen z’n ongelijk toe, staat open voor kritiek, zeurt nooit en heeft de bijzondere eigenschap wel in staat te zijn om documentatie en tests te kunnen schrijven.

Dat er dingen fout gaan met context, agents, hallucinaties, etc komt omdat de verkeerde modellen of prompts worden gebruikt. Mijn achtergrond is Deep Learning(CNNs) en het heeft mij 6 tot 12 maanden gekost om bij te komen met alle recente ontwikkelingen op het gebied van LLMs, VLMs en VLAs.

[ Voor 206% gewijzigd door ZieMaar! op 16-07-2026 17:55 ]

[wiemelen]

-knip- niet zo generaliseren aub.

De huidige LLMs zijn nu al veel beter dan de gemiddelde ‘ontwikkelaar’. Daarnaast hoeft een AI geen salaris, werkt rustig 24/7 door, is nooit vervelend, geeft meteen z’n ongelijk toe, staat open voor kritiek, zeurt nooit en heeft de bijzondere eigenschap wel in staat te zijn om documentatie en tests te kunnen schrijven.

Even uit nieuwsgierigheid, als developer gebruik ik AI tools meermaals per dag.
Maar uiteindelijk werk ik ook maar 8 uur per dag, waarvan een deel van de dag ook nog analyse, beheer, testen, architectuur inhoudt. Hoe zie jij AI 24/7 doorwerken? Een argument dat ik wel vaker hoor, maar niet echt van toepassing lijkt in software ontwikkeling. Kan wél van toepassing zijn in andere toepassingen.

[ Voor 43% gewijzigd door ZieMaar! op 16-07-2026 17:53 ]

[Philip Ross]

-Knip- reactie op verwijderde tekst

[ Voor 96% gewijzigd door ZieMaar! op 16-07-2026 17:53 ]

[Glashelder]

-Knip- reactie op verwijderde tekst

[ Voor 106% gewijzigd door ZieMaar! op 16-07-2026 17:54 ]

[wiemelen]

-Knip- reactie op verwijderd bericht

[ Voor 107% gewijzigd door ZieMaar! op 16-07-2026 17:55 ]

[Lethalis]

GoingDutch schreef op donderdag 16 juli 2026 @ 09:00:
[...]

De huidige LLMs zijn nu al veel beter dan de gemiddelde ‘ontwikkelaar’. Daarnaast hoeft een AI geen salaris, werkt rustig 24/7 door, is nooit vervelend, geeft meteen z’n ongelijk toe, staat open voor kritiek, zeurt nooit en heeft de bijzondere eigenschap wel in staat te zijn om documentatie en tests te kunnen schrijven.

Dat er dingen fout gaan met context, agents, hallucinaties, etc komt omdat de verkeerde modellen of prompts worden gebruikt. Mijn achtergrond is Deep Learning(CNNs) en het heeft mij 6 tot 12 maanden gekost om bij te komen met alle recente ontwikkelingen op het gebied van LLMs, VLMs en VLAs.

Tenzij het je lukt om een LLM lokaal te draaien die enorm veel parameters aankan, zul je als bedrijf toch altijd een andere partij moeten betalen voor de AI tokens die worden gebruikt. En de prijs daarvan zal nog even doorstijgen, want al die datacenters zijn niet gratis.

En je hebt nog altijd iemand nodig die met de AI praat, want de opdrachtgever is vaak amper in staat om te formuleren wat hij / zij nou eigenlijk wil.

Is ook beetje het verschil tussen een ontwikkelaar (bedenkt oplossing) en een programmeur (doet alleen implementatie). Daarom hebben ook vooral juniors het moeilijk, want die kregen toch vooral de simpelere taken die je nu aan een AI agent kunt geven.

De lastigere dingen - niet zozeer qua techniek, maar wel qua het begrijpen van het business domein en dit vertalen naar een oplossing - zijn veel moeilijker te automatiseren.

Ik moet dan altijd aan een inmiddels gepensioneerde collega van mij denken. Die was ook eigenlijk meer consultant geworden dan ontwikkelaar. Toen ik nog wat jonger was, had ik altijd zoiets van "die collega is klaar als programmeur, laat hem alsjeblieft beschrijven wat er moet gebeuren en dan bouwen wij het wel".

Nou die meneer heeft het meeste baat bij AI. Want hij begrijpt de klant, weet wat hij wil en dan hoeft hij het alleen nog uit te leggen aan een AI.

Die mensen blijven werk houden.

De rest zal het lastiger krijgen, maar het is niet alsof we allemaal gedoemd zijn ofzo. Het is alleen dat je software ontwikkeling moet zien als iets groters dan alleen implementatie. Je lost een probleem op. Hoe je dat doet, doet er eigenlijk niet toe. Het kan immers ook zijn dat de oplossing simpelweg het gebruiken van een reeds bestaande tool is. Of tegenwoordig omdat je een AI een tool vraagt te maken. Maar je bent nog steeds nodig, omdat de klant het zelf niet gaat doen.

Wel kan ik mij voorstellen dat veel mensen zullen afvallen. En dat is ook logisch. Al die jaren dat er enorme tekorten aan ontwikkelaars waren, kwam inderdaad iedereen binnen. Dus eigenlijk is dit gewoon een kleine reset, waardoor de harde kern weer overblijft, net zoals vroeger.

De rest kan weer terug iets anders doen

[CVTTPD2DQ]

Lethalis schreef op donderdag 16 juli 2026 @ 16:08:
Tenzij het je lukt om een LLM lokaal te draaien die enorm veel parameters aankan, zul je als bedrijf toch altijd een andere partij moeten betalen voor de AI tokens die worden gebruikt. En de prijs daarvan zal nog even doorstijgen, want al die datacenters zijn niet gratis.

Er spelen twee zaken: op de tokens zelf (dwz. het 'denkwerk' door de AI) maken de AI-bedrijven vette winstmarges, die soms op wel 90% worden geschat.

Neem je de investeringen in steeds grotere nieuwe modellen en datacenters erbij, is het geheel inderdaad verlieslatend. De beurskoersen zijn te hoog, er zullen ongetwijfeld bedrijven failliet gaan, maar daardoor verdwijnt de technologie niet.

De mensen die roepen dat dit niet eeuwig door kan gaan hebben gelijk. Op een gegeven moment moeten de investeringen terugvallen naar een niveau dat uit de lopende inkomsten kan worden betaald.

En dan kan het nog twee kanten op: het trainen van nieuwe modellen is noodzakelijk voor de AI-bedrijven om 'bij te blijven', en bij een volhoudbaar investeringsniveau is het tempo van training niet voldoende om de modellen bruikbaar te houden. In dat geval ontstaat er een industrie waarin LLMs alleen "houdbare" verouderde kennis hebben, maar waarin ze wellicht nog wel nuttig inzetbaar zijn voor deeltaken.

Of het is mogelijk om (met een iets lager ambitieniveau) de modellen courant te houden.

In beide scenario's is het aannemelijk dat de prijs van tokens gaat dalen.

[Wozmro]

De huidige rekenkracht in onze modale smartphones werd vroeger ook als totaal onrealistisch weggezet. Kan niet, nooit nie.

En ik herinner mij artikels met de als titel: 'binnen 10 jaar verbruikt het internet evenveel energie als de rest van de wereld, zo kan het niet verder'.

Net omdat AI momenteel zoveel geld en energie kost wordt er naarstig gezocht naar oplossingen want meer winst.

Ok, Jevons-paradox speelt een rol maar ook de wet van Wright en de wet van massa is kassa.

[CVTTPD2DQ]

Wozmro schreef op vrijdag 17 juli 2026 @ 08:22:
Net omdat AI momenteel zoveel geld en energie kost wordt er naarstig gezocht naar oplossingen want meer winst.

Zelfs zonder technologische sprongen (efficiëntere modellen / hardware, en daar is nog genoeg winst te behalen) is het dus rendabel te rekenen.

Mensen die denken dat LLMs niet met hun baan zullen concurreren "omdat het allemaal een bubbel is" hebben dus niet zo'n overtuigend verhaal. In ieder geval niet op de lange termijn.

[Philip Ross]

Wozmro schreef op vrijdag 17 juli 2026 @ 08:22:
De huidige rekenkracht in onze modale smartphones werd vroeger ook als totaal onrealistisch weggezet. Kan niet, nooit nie.

Volgens mij was de wet van Moore er juist al decennia duidelijk over dat dat absoluut wel kon en ook zou gebeuren.

CVTTPD2DQ schreef op vrijdag 17 juli 2026 @ 08:27:

Mensen die denken dat LLMs niet met hun baan zullen concurreren "omdat het allemaal een bubbel is" hebben dus niet zo'n overtuigend verhaal. In ieder geval niet op de lange termijn.

Mensen denken dat niet "omdat het een bubbel" is maar omdat ze realistisch naar de mogelijkheden kijken.
Ik probeer met regelmaat gebruik te maken van AI maar zoals al eerder gemeld is er gewoon nog niets voor ons vakgebied dat ook maar enigszins in de buurt komt van een normale programmeur.

De bubbel gaat over de beurs waardering en de hoeveelheid AI die op de vreemdste plekken in producten gestopt wordt.

Ja, er is zeker toekomst perspectief voor AI. En het zal een goede ondersteuning zijn in veel vakgebieden en veel eenvoudige rollen vervangen. Maar het idee dat het uiteindelijk elk (behalve fysiek) vakgebied overhoop gaat halen is met de huidige manier van modellen trainen nog ver gezocht.

[Wozmro]

En ook de (daarom niet onterechte) uitgebreid beschreven tegenreacties bezorgen de ontwikkelaars van AI ook heel veel informatie om hun product te optimaliseren.

Iedere fout, onbestaande quote, rare reactie,... van een AI-bot daar wordt heel uitgebreid en tot in het detail online over gedebatteerd.

Moest het allemaal maar een bubbel zijn dan zouden al die critici daar gewoon geen tijd en moeite in steken. Het moet toch zijn dat er iets fundamenteels toch aangevoeld wordt?

Waarmee ik zeker niet wil zeggen dat kritiek onterecht is.

[Corrit]

De bubbel is naar mijn mening vooral financieel, niet technologisch. Uiteindelijk moet er idioot veel geld binnenkomen om de waardes waar de AI bedrijven momenteel op worden geschat te kunnen rechtvaardigen. Bij sommigen zal dat misschien lukken, maar bij veel ook niet. Er is toch ergens een limiet aan wat bedrijven willen uitgeven aan AI, en ik geloof er persoonlijk niets van dat het op lange termijn "normaal" wordt geacht om een paar honderd euro per medewerker per maand aan AI kosten te gaan aftikken. Dan gaan bedrijven echt wel zelf 'rondshoppen' om goedkopere opties te vinden.

Maar ook als alle AI bedrijven morgen in elkaar zouden klappen dan blijft de techniek bestaan, en die kan in veel gevallen nu al prima concurreren met het werk dat een mens kan leveren (administratief, programmeren, etc). Wat er ook gebeurt, daar moeten we ons individueel en als samenleving op aanpassen.

[Philip Ross]

Wozmro schreef op vrijdag 17 juli 2026 @ 08:47:
Moest het allemaal maar een bubbel zijn dan zouden al die critici daar gewoon geen tijd en moeite in steken. Het moet toch zijn dat er iets fundamenteels toch aangevoeld wordt?

Is dat niet gewoon omdat veel mensen moe worden van hoe hard AI gepushed wordt en hoe dood je ermee gegooid wordt op social media?
Dan krijg je logischerwijs een tegenreactie.

[Corrit]

CVTTPD2DQ schreef op vrijdag 17 juli 2026 @ 07:58:
Er spelen twee zaken: op de tokens zelf (dwz. het 'denkwerk' door de AI) maken de AI-bedrijven vette winstmarges, die soms op wel 90% worden geschat.

Neem je de investeringen in steeds grotere nieuwe modellen en datacenters erbij, is het geheel inderdaad verlieslatend. De beurskoersen zijn te hoog, er zullen ongetwijfeld bedrijven failliet gaan, maar daardoor verdwijnt de technologie niet.

Deze redenatie snap ik niet. Die omzet op tokens kun je m.i. niet los zien van alle investeringen die deze bedrijven moeten doen. Zonder concurrerend model (met bijbehorende ontwikkelkosten) dat op courante (dure) hardware moet draaien heb je geen omzet. De operationele kosten zijn gigantisch en vziw is nog geen enkele van de grote AI bedrijven in staat om daadwerkelijk winst te maken.

[Wozmro]

Je wordt met vanalles en nog wat doodgegooid op sociale media. Reageren zorgt net voor een versterkend effect.

En wat het financiële betreft: het zou best kunnen dat er een aantal bedrijven failliet gaan, dat investeerders geld kwijt zijn. Is dat zo erg of uitzonderlijk in het kapitalistisch systeem?

Ja, dan kan er een beurscorrectie/crash volgen, maar zou dat zo erg zijn voor de gewone mens in de straat, met een gewone job?

[Philip Ross]

Wozmro schreef op vrijdag 17 juli 2026 @ 09:04:
Je wordt met vanalles en nog wat doodgegooid op sociale media. Reageren zorgt net voor een versterkend effect.

Ik zou verwachten dat we hier op Tweakers wat inhoudelijker kunnen praten.
Op social media reageer ik inderdaad niet, hier wel.

Daarnaast is het niet alleen op social media maar ook op de werkvloer.

Directies die even besluiten dat je vanaf morgen alles in 50% van de tijd moet doen zonder onderzocht te hebben of AI wel geschikt is voor die rol. "Want bij ons in de directie konden we makkelijk de helft van ons werk door AI laten doen dus engineers moeten dat ook wel kunnen."
Alsof een secretaresse die notulen maakt laten vervangen door AI hetzelfde is als iemand die technische ontwerpen en tekeningen maakt.

[ Voor 41% gewijzigd door Philip Ross op 17-07-2026 09:53 ]

[Wozmro]

Gebeurd dat bij jullie op de werkvloer werkelijk op die manier?

[Philip Ross]

Wozmro schreef op vrijdag 17 juli 2026 @ 10:08:
Gebeurd dat bij jullie op de werkvloer werkelijk op die manier?

Bij mijn vorige werkgever wel ja.
Van de een op de andere dag mocht het project geen regel meer zelf programmeren en was de verwachting dat alles 50% sneller zou zijn.

Een van de redenen dat ik opgestapt ben daar. Zonder overleg met het team overigens over wat de mogelijkheden waren.

[Wozmro]

Amai, dat zegt ook iets over de communicatieve vaardigheden van de leidinggevenden.

[Philip Ross]

Wozmro schreef op vrijdag 17 juli 2026 @ 10:22:
Amai, dat zegt ook iets over de communicatieve vaardigheden van de leidinggevenden.

Zeker, veel bezwaar tegen AI gaat ook niet over de AI zelf maar over de manier waarop het vaak opgedrongen wordt.

[njitter]

AI is prima zolang er maar iemand aanwezig is om exact te vertellen wat gewenste output is.

Zelf gebruik ik CoPilot regelmatig om een query te optimaliseren. Ik ken genoeg SQL om data uit het systeem te halen. Maar als er allerlei logica nodig is met verschillende joins dan is het handig om dit door ai te laten verzinnen. De output is ook niet dusdanog lang dat het lastig te controleren is.

Maar als je een complete applicatie laat vibecoden inclusief UI en niemand heeft een idee wat er nu eigenlijk gebouwd is en hoe het werkt dan ben je verkeerd bezig. ZIe het als een tool en niet als een doel op zich.

[t_captain]

GenAI en agentic AI is gewoon een grote stap in developer productivity.

Kijk naar de afgelopen 60 jaar aan software ontwikkeling. Van assembly naar C en Fortran. De opkomst van C++ met betere mogelijkhedne tot code reuse en organisatie in grotere projecten. De opkomst van standaard libraries. De opkomst van IDE's met gelijdelijk steeds meer slimheid om sneller en fijner te kunnen coderen. De shift naar 3G talen met managed runtimes. De boom in frameworks. In het verlengde van die frameworks, productization als PaaS diensten door cloud providerd. En vergeet niet de websites als Github en Stackoverflow om je te helpen met je werk.

Al die ontwikkelingen hebben bijgedragen aan developer productivity: een gestage toename van hoeveel complexiteit je per werkdag kunt bouwen.

En de markt heeft die productiviteit tot nu toe steeds opgenomen. Software wordt steeds betaalbaarder (gemeten in inflatiegecorrigeerde dollars per complexiteit). We bouwen steeds meer systemen en steeds complexere systemen.

30 jaar geleden was een site als Hotmail een hoogvliegende start-up die voor veel geld werd overgenomen door Microsoft. Tegenwoordig kun je het in een manweek bouwen, als je leunt op alle beschikbare tools, LLM's, frameworks en clouddiensten.

De vraag nu: kan de markt ook een plotselinge grote stap in productiviteit opnemen? Of geeft het een echte shake-out? Time will tell. De zorg speelt in bredere context al langer: gaat de productiviteitswinst door technologische vooruitgang leiden naar een nieuwe boost aan welvaart of aan een structurele werkloosheid?

Dit is dus niet anders dan wat technologie maatschappijbreed doet. Landbouwmechanisatie maakte een eeuw geleden heel veel boerenknechten werkloos. Die vonden uiteindelijk ander werk in een groeiende industriele sector, die bijdroeg aan een forse toename van de levensstandaard. Tot nu toe is dat altijd de uitkomst geweest, maar er zijn ook stemmen die zeggen dat het huidige tempo niet kan worden geabsorbeerd.

De ironie is dat ICT de afgelopen 30 jaar juist de driver was van een bredere maatschappelijke modernisering en nu is begonnen om zichzelf in de staart te bijten.

[wiemelen]

Wozmro schreef op vrijdag 17 juli 2026 @ 08:22:
Net omdat AI momenteel zoveel geld en energie kost wordt er naarstig gezocht naar oplossingen want meer winst.

Lijkt me ook wel nodig als je het energieverbruik van datacenters ziet.
Zie ook https://tweakers.net/nieu...e-nederlandse-stroom.html.
Ben dan ook benieuwd hoeveel energie alle datacenters in Nederland tesamen gebruiken, rekening houdend dat er nog meer data centers gepland staan.

Dus datacenters die minder energie verbruiken lijkt wel streefdoel ja.

[njitter]

wiemelen schreef op vrijdag 17 juli 2026 @ 11:21:
[...]

Dus datacenters die minder energie verbruiken lijkt wel streefdoel ja.

Niet alleen minder stroomverbruik maar ook gewoon minder datacenters erbij. Zo heeft de gemeente Amsterdam vorig jaar de bouw van nieuwe datacenters voor een periode van tien jaar verboden.

https://www.bnr.nl/nieuws/tech-innovatie/10606372/meeste-datacenters-in-nederland-maken-stroomverbruik-niet-openbaar

[PWSteal]

t_captain schreef op vrijdag 17 juli 2026 @ 11:11:
GenAI en agentic AI is gewoon een grote stap in developer productivity.

Kijk naar de afgelopen 60 jaar aan software ontwikkeling. Van assembly naar C en Fortran. De opkomst van C++ met betere mogelijkhedne tot code reuse en organisatie in grotere projecten. De opkomst van standaard libraries. De opkomst van IDE's met gelijdelijk steeds meer slimheid om sneller en fijner te kunnen coderen. De shift naar 3G talen met managed runtimes. De boom in frameworks. In het verlengde van die frameworks, productization als PaaS diensten door cloud providerd. En vergeet niet de websites als Github en Stackoverflow om je te helpen met je werk.

Al die ontwikkelingen hebben bijgedragen aan developer productivity: een gestage toename van hoeveel complexiteit je per werkdag kunt bouwen.

En de markt heeft die productiviteit tot nu toe steeds opgenomen. Software wordt steeds betaalbaarder (gemeten in inflatiegecorrigeerde dollars per complexiteit). We bouwen steeds meer systemen en steeds complexere systemen.

30 jaar geleden was een site als Hotmail een hoogvliegende start-up die voor veel geld werd overgenomen door Microsoft. Tegenwoordig kun je het in een manweek bouwen, als je leunt op alle beschikbare tools, LLM's, frameworks en clouddiensten.

De vraag nu: kan de markt ook een plotselinge grote stap in productiviteit opnemen? Of geeft het een echte shake-out? Time will tell. De zorg speelt in bredere context al langer: gaat de productiviteitswinst door technologische vooruitgang leiden naar een nieuwe boost aan welvaart of aan een structurele werkloosheid?

Dit is dus niet anders dan wat technologie maatschappijbreed doet. Landbouwmechanisatie maakte een eeuw geleden heel veel boerenknechten werkloos. Die vonden uiteindelijk ander werk in een groeiende industriele sector, die bijdroeg aan een forse toename van de levensstandaard. Tot nu toe is dat altijd de uitkomst geweest, maar er zijn ook stemmen die zeggen dat het huidige tempo niet kan worden geabsorbeerd.

De ironie is dat ICT de afgelopen 30 jaar juist de driver was van een bredere maatschappelijke modernisering en nu is begonnen om zichzelf in de staart te bijten.

Ik denk dat de vraag hoofdzakelijk is of de toegenomen productiviteit daadwerkelijk vertaald naar een toename in levensstandaard. Waar zijn de nuttige producten die door deze toegenomen productiviteit zijn onstaan, ik zie ze namelijk niet?

[Wozmro]

Veel zaken zijn ook niet zichtbaar als je er niet rechtstreeks mee te maken hebt.

Medische toepassingen, bedrijfsprocessen, weersvoorspellingen, landbouw,...

Negatieve gebeurtenissen die niet voorvallen zorgen ook voor een stijging van de welvaart.

Een vermeden overstroming door betere weersvoorspelling, wat minder tijd in de file staan,...

[Gr4mpyC3t]

PWSteal schreef op zondag 19 juli 2026 @ 15:02:
[...]

Ik denk dat de vraag hoofdzakelijk is of de toegenomen productiviteit daadwerkelijk vertaald naar een toename in levensstandaard. Waar zijn de nuttige producten die door deze toegenomen productiviteit zijn onstaan, ik zie ze namelijk niet?

Nou ja, ik hoop vooral dat AI straks een bijdrage kan leveren aan een hogere kwaliteit van geleverde (digitale) diensten.

Bijvoorbeeld, er zijn al experimentele projecten in de zorg waar AI kijkt naar röntgenfoto’s om in een vrij vroeg stadium afwijkingen in het lichaam te vinden. Dat levert nu al hoopvolle resultaten op.

[PWSteal]

Gr4mpyC3t schreef op zondag 19 juli 2026 @ 15:36:
[...]

Nou ja, ik hoop vooral dat AI straks een bijdrage kan leveren aan een hogere kwaliteit van geleverde (digitale) diensten.

Bijvoorbeeld, er zijn al experimentele projecten in de zorg waar AI kijkt naar röntgenfoto’s om in een vrij vroeg stadium afwijkingen in het lichaam te vinden. Dat levert nu al hoopvolle resultaten op.

Als ik 1 ding zie gebeuren is het wel het tegenovergstelde van hogere kwaliteit diensten. Code reviewers, testers en QA worden volledig overspoeld door ontwikkelaars die nu aan de lopende band PRs van 5000+ regels maken. De volledige kwaliteitscontrole word hierdoor omzeild, geen enkele reviewer gaat dit namelijk serieus bekijken dan wel begrijpen wat er gedaan is.

Dan mag je geluk hebben met reviewers die de boel blokkeren, maar in praktijk word het rubber stampen. Inmiddels genoeg ervaring mee: ontwikkelaar denk na een dag klaar te zijn; levert 5000 regels op wat er 1000 hadden kunnen zijn. Niemand bekijkt de code dus ook niemand snapt hoe het werkt. Spendeert vervolgens 2 weken aan allerlei vage fixes. Deployed naar productie waar het nagenoeg onbruikbaar blijkt te zijn en vereist dus nog een week aan fixes. Op dat moment raken er meerdere mensen bij betrokken en de tijdsinvestering explodeert, die komen er dan achter dat het ook nog eens vol zit met architecturele problemen. Dan word de conclusie: bouw maar helemaal opnieuw want dit gaat nooit werken.

Ben je 4 weken aan het rotzooien, allerlei mensen tijd verspilt en een brak product aan klanten opgeleverd. Hetzelfde had iemand met een week handmatig programmeren ook kunnen opleveren, alleen dan had je niet 3 weken lang aan puin ruimen erachteraan gehad.

[R_Zwart]

PWSteal schreef op zondag 19 juli 2026 @ 16:15:
[...]

Als ik 1 ding zie gebeuren is het wel het tegenovergstelde van hogere kwaliteit diensten. Code reviewers, testers en QA worden volledig overspoeld door ontwikkelaars die nu aan de lopende band PRs van 5000+ regels maken. De volledige kwaliteitscontrole word hierdoor omzeild, geen enkele reviewer gaat dit namelijk serieus bekijken dan wel begrijpen wat er gedaan is.

Dan mag je geluk hebben met reviewers die de boel blokkeren, maar in praktijk word het rubber stampen. Inmiddels genoeg ervaring mee: ontwikkelaar denk na een dag klaar te zijn; levert 5000 regels op wat er 1000 hadden kunnen zijn. Niemand bekijkt de code dus ook niemand snapt hoe het werkt. Spendeert vervolgens 2 weken aan allerlei vage fixes. Deployed naar productie waar het nagenoeg onbruikbaar blijkt te zijn en vereist dus nog een week aan fixes. Op dat moment raken er meerdere mensen bij betrokken en de tijdsinvestering explodeert, die komen er dan achter dat het ook nog eens vol zit met architecturele problemen. Dan word de conclusie: bouw maar helemaal opnieuw want dit gaat nooit werken.

Ben je 4 weken aan het rotzooien, allerlei mensen tijd verspilt en een brak product aan klanten opgeleverd. Hetzelfde had iemand met een week handmatig programmeren ook kunnen opleveren, alleen dan had je niet 3 weken lang aan puin ruimen erachteraan gehad.

Dit komt deels omdat deze manier van softwareontwikkeling of relatief nieuw is. De meesten zullen de negatieve kanten herkennen, en dat zal ervoor zorgen dat tools worden aangepast in de komende jaren waardoor het resultaat beter wordt. Ook de hoge prijs van een geheugen zal voor extra eisen zorgen. Tevens moet je ook naar andere manieren van testen en QA moeten gaan kijken. Er mee stoppen omdat het nu niet perfect is, is het laatste wat je moet doen.

[Stukfruit]

PWSteal schreef op zondag 19 juli 2026 @ 16:15:
[...]

Als ik 1 ding zie gebeuren is het wel het tegenovergstelde van hogere kwaliteit diensten. Code reviewers, testers en QA worden volledig overspoeld door ontwikkelaars die nu aan de lopende band PRs van 5000+ regels maken. De volledige kwaliteitscontrole word hierdoor omzeild, geen enkele reviewer gaat dit namelijk serieus bekijken dan wel begrijpen wat er gedaan is.

Dan mag je geluk hebben met reviewers die de boel blokkeren, maar in praktijk word het rubber stampen. Inmiddels genoeg ervaring mee: ontwikkelaar denk na een dag klaar te zijn; levert 5000 regels op wat er 1000 hadden kunnen zijn. Niemand bekijkt de code dus ook niemand snapt hoe het werkt. Spendeert vervolgens 2 weken aan allerlei vage fixes. Deployed naar productie waar het nagenoeg onbruikbaar blijkt te zijn en vereist dus nog een week aan fixes. Op dat moment raken er meerdere mensen bij betrokken en de tijdsinvestering explodeert, die komen er dan achter dat het ook nog eens vol zit met architecturele problemen. Dan word de conclusie: bouw maar helemaal opnieuw want dit gaat nooit werken.

Ben je 4 weken aan het rotzooien, allerlei mensen tijd verspilt en een brak product aan klanten opgeleverd. Hetzelfde had iemand met een week handmatig programmeren ook kunnen opleveren, alleen dan had je niet 3 weken lang aan puin ruimen erachteraan gehad.

Is de kwaliteitscontrole in kwestie deterministisch (de nodige SAST-tools, volledige SonarQube zonder taalmodellen, enz) of gebaseerd op agents? Want dit klinkt alsof je niet beide kanten automatiseert.

Wat is er mis met reviewen met hulp van een agent die alles wat langer dan 1000 regels is helpt analyseren of nog beter: wegknikkert?

Als iemand bijvoorbeeld een "godfile" indient dan kan dat automatisch worden afgekeurd. Geldt ook voor zaken waarin de junior vrolijk dingen heeft zitten "vibecoduplicaten" tot aan de problemen met architectuur aan toe. Hoef je niet eens een hele pipeline voor op te zetten. Handmatig een setje prompts en skills bijhouden waarvan de resultaten afgedwongen kunnen worden doet een hoop goeds.

Setje goede architectuur- en reviewskills erop zetten icm systemprompt voor agent die echt heel graag door wil gaan en alles wat fout lijkt te zijn wil afkeuren. Eerst laten pruttelen voordat je er zelf ook maar een seconde naar kijkt. Niet goed? Direct terug naar indiener sturen om het werk te verplaatsen naar de persoon die nog moet leren of te lui is geweest.

Het pakt niet alles op omdat begrip van wat je nodig hebt op hoger niveau totaal ontbreekt, maar je kan wel gebrek aan begrip bij de indiener aanpakken en in de eerste laag alle vibecode-onzin er al grotendeels uithalen zodat je zelf een blik met intelligentie kan opentrekken voor de rest op basis van code die een stuk minder overdreven in elkaar steekt.

Pak je dat als bedrijf niet goed op, dan ga je inderdaad vaker slechtere producten leveren dan andere partijen omdat je niet (genoeg) aan automatisering doet en werk je jezelf uit de markt.

[t_captain]

PWSteal schreef op zondag 19 juli 2026 @ 15:02:
[...]

Ik denk dat de vraag hoofdzakelijk is of de toegenomen productiviteit daadwerkelijk vertaald naar een toename in levensstandaard. Waar zijn de nuttige producten die door deze toegenomen productiviteit zijn onstaan, ik zie ze namelijk niet?

Het hoeft niet altijd een nieuw product of nieuwe dienst te zijn. Het efficienter maken van bestaand werk is ook welvaartsverhogend. De nieuwe producten en diensten ontstaan dan elders. Zoals de landbouwmechanisatie de boerendochters van de boerderijen naar de Philipsfabrieken migreerde, waar ze transistorradio's gingen bouwen.


Een grote vraag is wel in deze tijd: in welke mate is arbeid nog de bottleneck van welvaartscreatie? Cleantech en greentech lossen andere efficiency-bottlenecks op dan AI en die kunnen wel eens relevanter blijken.

[Wozmro]

Dan komt de econoom Daniel Susskind in beeld met zijn concept van het conditional basic income.

Geen gratis geld maar een basisinkomen in ruil voor bijdragen aan de samenleving (niet economische taken). Bijvoorbeeld twee dagen per week mantelzorg, vrijwilligerswerk, gemeenschapstaken,...

En de rest van je tijd doe je hobby zoals bijvoorbeeld manueel programmeren, kunst, allerhande opleidingen. Niet omwille van economische perspectieven maar voor het leren om het leren zelf.

Dat wordt wel nogal een culturele en psychologische omslag waarbij mensen (de jeugd) stapje voor stapje (zonder veel gerucht aan te geven) in die richting evoluren en de politiek daar dan reactief zal op reageren met onder andere hogere belastingen op (AI-) bedrijven.

[pieter.a]

PWSteal schreef op zondag 19 juli 2026 @ 16:15:
[...]

Als ik 1 ding zie gebeuren is het wel het tegenovergstelde van hogere kwaliteit diensten. Code reviewers, testers en QA worden volledig overspoeld door ontwikkelaars die nu aan de lopende band PRs van 5000+ regels maken. De volledige kwaliteitscontrole word hierdoor omzeild, geen enkele reviewer gaat dit namelijk serieus bekijken dan wel begrijpen wat er gedaan is.

Ja, dat kan en dat gebeurt al.

In mijn team werken we sinds vorig jaar met een outsourcing partij. Uit de eerste code reviews kwam zoveel feedback dat we een checklist hebben gemaakt met conventies en best practices. Ik kijk er naar uit om AI de code te laten reviewen aan de hand van de checklist voordat er überhaupt een PR wordt gemaakt.

[CVTTPD2DQ]

Wozmro schreef op maandag 20 juli 2026 @ 12:07:
Geen gratis geld maar een basisinkomen in ruil voor bijdragen aan de samenleving (niet economische taken). Bijvoorbeeld twee dagen per week mantelzorg, vrijwilligerswerk, gemeenschapstaken,...

En de rest van je tijd doe je hobby zoals bijvoorbeeld manueel programmeren, kunst, allerhande opleidingen. Niet omwille van economische perspectieven maar voor het leren om het leren zelf.

Wederom, wie heeft het geld om dit te betalen? Want als jouw baan straks door een LLM ergens in een datacentrum in Texas gedaan wordt door een LLM uit Californië, komt ook de meerwaarde die jouw baan creëert grotendeels in de VS terecht.