Google: 'AI genereert kwart van onze nieuwe code'

Kunstmatige intelligentie genereert een kwart van de nieuwe code bij Google. Dat zegt directeur Sundar Pichai in een bespreking van de kwartaalcijfers. Het is voor het eerst dat een directeur van een groot techbedrijf zo'n cijfer noemt.

De stap om AI te gebruiken voor het maken van code maakt het proces efficiënter, claimt Pichai. "We gebruiken AI om intern ons proces van programmeren te verbeteren en dat geeft een boost aan productiviteit en efficiëntie. Nu genereert AI een kwart van alle nieuwe code, waarna engineers het nakijken en goedkeuren. Dit helpt onze mensen om meer te doen."

De omzet van Googles moederbedrijf Alphabet groeide met 15 procent naar 88 miljard dollar. Het netto-inkomen steeg met 34 procent naar 26 miljard dollar. Die groei zat in alle geledingen van het bedrijf. De divisie 'Search and other' groeide met 5 miljard naar een omzet van 49 miljard dollar. Ook de inkomsten op YouTube-advertenties en uit abonnementen en hardware stegen van 8,3 miljard naar 10,6 miljard dollar.

Reacties (183)

[rijnsoft]

Als programmeur kan ik je verzekeren dat een hoeveelheid code heel weinig zegt. Sommige stukken code zijn herhalingen van zetten, en die kun je zelf snel schrijven, of door AI laten genereren. Eigenlijk maakt dat niet uit. Andere stukken vergen veel werk, zelfs voordat je de eerste regel code schrijft. Hoe benader je een probleem? Welke aanpak voldoet het beste aan alle eisen van leesbaarheid, flexibiliteit, veiligheid, en onderhoud?

Ik gebruik "AI" voornamelijk als zoekmachine, voor heel specifieke problemen of om ideeën op te doen. Geen enkel stuk AI code komt er bij mij door zonder dat het volledig geanalyseerd en goedgekeurd is. Vaak gaat het al bij basale zaken mis.

[Q]

Ik denk dat het doel van de opmerking over 25 procent code vooral bedoeld is om de eigen AI strategie te promoten.

Hoe gaat die strategie geld opleveren? Tot nu toe lijkt AI alle partijen miljarden te kosten maar niets op te leveren. Dus ze moeten virtue signalen.

AI —> minder mensen —> ontslagen —> shareholder value.

Dat is mogelijk de échte waarde van AI. Niet zozeer wat je er inhoudelijk mee kunt, maar om veel minder afhankelijk te zijn van programmeurs of creatieven, dus kun je hun salarissen drukken.

[Sgrovert]

Ik heb naar aanleiding van dit artikel maar eens geprobeerd om wat code door ChatGPT te laten genereren.
Mijn prompt :

create a Python enum containing all statuses of a Kubernetes pod

The respons code was voor mij bijna exact zoals ik het zelf ook zou maken

from enum import Enum

class PodStatus(Enum):
PENDING = "Pending"
RUNNING = "Running"
.....

Als added bonus kreeg ik er een aantal statuses bij die ik nog nooit gezien heb, en welke ook niet direct bij mijn google query gezien heb.

Dit scheelt inderdaad wel wat werk, en gezien het aantal regels code dat mijn feature waarschijnlijk nodig heeft, komt 25% ai generated behoorlijk in de buurt. Helaas bestpaart het niet 25% van de tijd

[vrije_vogel]

... en de statussen behoor je op te halen uit de officiële documentatie en niet uit zomaar een Google query. Voor zo'n class zit het werk niet in het schrijven van de code maar in het raadplegen van de correcte bronnen.

[84hannes]

... en de statussen behoor je op te halen uit de officiële documentatie en niet uit zomaar een Google query. Voor zo'n class zit het werk niet in het schrijven van de code maar in het raadplegen van de correcte bronnen.

Dat raadplegen van correcte bronnen is saai, repetitief en foutgevoelig werk. Vroeger gebruikten we altijd computers en machines om dat soort werk over te nemen, zodat wij het leuke werk kunnen doen. Als AI dit met een acceptabele foutmarge kan lijkt het me slechts een voortzetting van mechanisering/automatisering/digitalisering zoals we dat eigenlijk al doen sinds de uitvinding van het allereerste gereedschap.

Dat AI creatief is betwijfel ik. De eerste keren dat we resultaten van LLM zagen leek het creatief, maar na een paar prompts ga je een patroon herkennen en blijken LLM's alleen maar beter dan mensen in grote hoeveelheden data verwerken.

[Sgrovert]

Het kopt wat je zegt.
Het probleem met statuses is echter dat deze in de loop der tijd niet gegarandeerd zijn. bij upgrades van kubernetes kunnen er bijkomen of afvallen. Als je je processen heel goed ingericht heb, check je voor je upgrade of er veranderingen zijn die imact op je codebase hebben. In praktijk zullen de meeste de upgrade in een staging omgeving testen en kijken of er niks crashed.
Bij het parsen van de status dien je dus rekening te houden met toekomstige veranderingen.

try:
status = JobStatus(pod.status)
except ValueError:
raise UnsupportedJobStatus(f'Received an unexpected status {pod.status} from the Cluster')

Bovenstaand pattern maakt issues traceable.

In mijn huidige usecase had ik een paar statuses nodig. (running, finshed, failed). Er waren 3 opties
1) Officiele documentatie.
2) ChatGPT
3) Alleen benodigde set implementeren.

In de officiele documentatie kreeg ik het niet snel gevoden, en dit artikel leek me een interessant experiment. Gezien de huidige set geen ganranties naar de toekomst geeft, maakt het in mijn optiek weinig uit waar ik de informtie exact vandaan haal.

[Q]

Het schrijven van code is vaak niet eens het meeste werk. Het belangrijke en meest tijdrovende werk is uitvogelen met stakeholders hoe het proces er uit moet zien en hoe een workflow moet worden ingericht.

Met alle tools die er al zijn tegenwoordig is heel veel code gewoon een invul oefening, nog los van AI.

Het échte probleem wordt dat jij straks nog productiever moet worden om dat je bazen boven je AI hebben gekocht en ROI willen zien. Dus links om of rechts om moet je dat ook laten zien of er vallen ontslagen. Heeft niets met feiten of realiteitszin te maken.

[RemcoID]

"gezien het aantal regels code dat mijn feature waarschijnlijk nodig heeft, komt 25% ai generated behoorlijk in de buurt. Helaas bestpaart het niet 25% van de tijd "

Volgens mij de spijker op de kop.

[Killah_Priest]

Hiermee loop je dus wel het risico dat AI gewoon statussen gaat hallucineren.
Ik heb regelmatig dat Github Copilot dingen verzint die simpelweg niet bestaan: van properties tot aan methods (en dan op "bekende" MS libraries die goed gedocumenteerd zijn).
Ook als ik vraag of iets überhaupt mogelijk is met library X moet ik ook altijd expliciet in mijn prompt opnemen dat nee ook een antwoord is, anders krijg ik weer niet bestaande methods voorgeschoteld.

Voor de standaard boilerplate code werkt het overigens prima, voor de moeilijkere zaken krijg ik gewoon te vaak bullshit code voorgeschoteld om er echt iets aan te hebben.

[Jasperrr]

Is natuurlijk enorm subjectief. Voor mij bespaart het juist meer dan 25% van de tijd. Als full-stack web developer kan ik zoveel simpele stukken code automatisch genereren nu. Door goede namen voor variabelen te gebruiken en hier en daar een JSDoc comment wordt een boel automatisch al aangevuld door CoPilot. Iets grotere vraagstukken gooi ik in ClaudAI en krijg ik, met een redelijke hit or miss, antwoorden op terug.

Het is wel van belang dat je goed alles naloopt en reviewed zoals je dat bij een gewone collega ook zou doen. En het helpt enorm als je dingen betreffende code styling en linting regels in je context opslaat.

Edit: kleine kanttekening. Qua programeertijd scheelt het mij dus meer dan 25% van de tijd. Zaken als overleg met stakeholders en requirements analyse, daar helpt het een stuk minder bij.

[Reactie gewijzigd door Jasperrr op 31 oktober 2024 14:29]

[w3news]

Zoals je dat altijd terug ziet, een proces om iets efficiënter te maken zorgt er niet voor dat je minder hoeft te werken of minder mensen nodig zijn, alleen dat je meer werk kunt verzetten.
Zelf denk ik daarom dus niet dat erg echt programmeurs ontslagen gaan worden.
Maar het lijkt inderdaad vooral ter promotie van AI en de aandelen van Google.

[jerisson]

Dat hangt puur af van wat dat proces inhoudt. Het proces kan in een bepaald stuk van de pipeline mensen ondersteunen (lopende band, computer graphics in de filmindustrie). In sommige gevallen worden de jobs dan wel vervangen door jobs voor mensen met een ander profiel.

Maar het proces kan ook jobs overbodig maken: zelfscankassas zorgen er bijvoorbeeld voor dat je geen kassier nodig hebt tussen de klant en de betaling. Daar zijn amper jobs voor in de plaats gekomen en de jobs die ervoor in de plaats komen zijn in aantal minder dan de jobs die opgeheven worden. Een ander voorbeeld zijn de stemacteurs: een stemacteur gebruikt zijn stem om een script - al dan niet met eigen creativiteit - om te zetten naar geluid. Door AI stellen sommigen dat die stemacteurs overbodig worden. De job van stemacteur wordt volledig uit de pipeline gehaald en vervangen door een computer. Maar er komt geen nieuwe job bij (de opdrachtgever geeft zijn opdrachten nu aan een computer ipv een mens.) [Persoonlijk denk ik dat men hier snel terug vanaf zal stappen, tenzij voor projecten met weinig budget, of low-quality massaproductie. Maar goed, dat is een andere discussie.]

Voor programmeurs zie ik geen problemen voor zij die echt aan nieuwe dingen werken, maar voor zij die enkel wat basisdingetjes doen waar 100'en voorbeelden van zijn daarentegen ...

[Q]

Het plaatje is wat mij betreft veel groter.

We zitten letterlijk in een late-stage capitalism fase. De middenklasse is uitgewrongen. We weten niet waar de groeiende groei voor aandeelhouders vandaan moet komen.

De AI tool is vooral een nieuwe hype tool om die groei in stand te houden. Er is geen 'mensen met een ander profiel' dat werk gaan doen. Het gaat nu gewoon om minder mensen, daar kun je die shareholder value genereren. Vandaar ook al die grote ontslagrondes bij de grote tech bedrijven.

De volgende stap is nu in volle gang: om jouw keuzevrijheid als burger aan banden te leggen. Democratie en iedere vorm van een rectstaat is niet efficient en winstgevend. Daarom zien we nu aan alle kanten op globaal vlak grote aanvallen op democratie en het concept van een overheid, omdat dit het genereren van shareholder value in de weg staat. Zie wie er gepromoot wordt door de grote Tech reuzen op politiek vlak.

We koersen rechtstreeks af op een scenario waarbij het woord 'slaaf' voor jou en mij straks de lading niet eens meer dekt. De kapitalisten denken dat ze volledig buiten schot zullen blijven en juist meer controle over ons zullen krijgen, de overheid en de burger wordt buitenspel geplaatst.

[Reactie gewijzigd door Q op 30 oktober 2024 13:06]

[Q]

Dat we als (globale) samenleving dit met elkaar totaal geaccepteerd hebben is een kunstig stukje PR van de kapitalisten. Dat we normaal vinden en dat er in de commments waarschijnlijk mensen dit gaan verdedigen is 'the greatest trick ever pulled'.

En daarom ben jij loon of freelance 'slaaf' voor 32-40 uur in de week.

Maar nu gaan we zien dat ook wij tech werkers, de mensen die altijd de personen waren die zaken automatiseren zodat andere mensen ontslagen konden worden, nu zelf ook ontslagen gaan worden.

Dus een deel van de tech workers werkt nu aan technologie, zodat de rest ontslagen kan worden.
Ik proef ironie.

[Lawyerson]

Dat jij kapitalisten als vijand ziet is vermoedelijk ook het gevolg van PR van een andere groepering.

[Q]

Ik geef toe dat ik luister en open sta voor de gedachtes en ideeën van andere mensen. Dat lijkt mij een gezonde houding, maar ik maak mijn eigen afweging: kan ik dat rijmen met de werkelijkheid.

Wat ik nu feitelijk waarneem is dat kapitalisme in rap tempo zowel de rechtstaat als democratie aanvalt omdat wet en regelgeving in de weg staat van shareholder value / het genereren van meer kapitaal.

Een grote groep usefull idiots ziet helaas het grote plaatje niet en laat zich voor het karretje spannen van de mensen die werkelijk de macht hebben, de mensen met geld. Politieke visie, maar makkelijk aan te wijzen.

Het is zo erg dat de burgers het materieel gezien prima hebben met hun telefoonjes en autotjes die ze mogen kopen. Maar toch zjin ze super ontevreden (die in hun hart weten ze dat ze niet vrij zijn, afhankelijk van werk). En dat ze boos en ongelukkig zijn reageren ze af op anderen, buitenlanders zijn een uitstekende scapegoat om mensen hun frustratie op bot te laten vieren.

En dat is prachtig, want dat leidt af van de wérkelijke redenen van de problemen die we nu ervaren, zoals het gebrek aan huizen. Bijvoorbeeld: huizen die als speculatie object massaal door mensen met geld zijn opgekocht. Gek toch dat we dat toestaan in een samenleving?

Maar ach, als "tijdelijk in verlegenheid gebrachte milionair" zul je ongetwijfeld redenen hebben om dit alles volledig van tafel te vegen.

“John Steinbeck once said that socialism never took root in America because the poor see themselves not as an exploited proletariat but as temporarily embarrassed millionaires.”

[Reactie gewijzigd door Q op 30 oktober 2024 14:15]

[Lawyerson]

Ik probeer ideeën ook te rijmen met de werkelijkheid. Vooralsnog lijkt de werkelijkheid te zijn dat niemand geboren wordt met het fundamentele recht om betaling te ontvangen voor jobs die geautomatiseerd kunnen worden, of de plicht om jobs te creëren waar er geen nodig zijn. Er is geen PR truc nodig om mij hiervan te overtuigen, het is gewoon evident.

Dat die werkelijkheid voor velen onaangenaam is is een andere discussie. Je kan vaststellen dat het beter kan en daar ook naar streven, maar dat wil niet zeggen dat we nu met z'n allen een loer worden gedraaid door de abstracte globale kapitalist. Het is gewoon wat het is.

[Q]

Ik denk dat niemand claimt het fundamentele recht te hebben om betaald te worden voor werk dat weggeautomatiseerd kan worden. Ik begrijp niet zo goed waarom je denkt dat dit mijn punt is.

Het probleem is dat zonder werk je uiteindelijk je huis en alles kunt verliezen. Je moet dus werk vinden, ook al is het werk waar je dood ongelukkig van wordt - met alle gevolgen van dien, omdat het werk wat je wél leuk zou vinden, waar je plezier en voldoening uit haalt, niet 'rendabel'.

Jouw waarde als mens wordt bepaald aan de hand van hoe rendabel je bent. Wie jij bent en wat voor werk je doet is jouw identiteit en je waarde. Het eerste wat we mensen vragen is 'en wat doe jij voor werk'.

Maar puur theoretisch zouden we een prima leven kunnen hebben met die 10-urige werkweek - op globaal niveau - en een hoop mensen zouden minder boos en ongelukkig zijn met hun leven.

Vergeet ook niet trouwens dat de heropkomst van fascisme wederom wordt mogelijk gemaakt door financiering van de kapitalisten. En dat werkt omdat zoveel mensen ontevreden zijn, maar niet begrijpen waarom dat is.

Er is geen PR truck nodig om mij te overtuigen dat het kapitalisme nog nooit zo machtig is geweest en op dit moment democratie en de samenleving in rap tempo buitenspel zet, dat zij ons nietzozeer een loer draait, maar gewoon heel open is over haar doelstellingen. Democratie en vrijheid van burgers om hun eigen leven in te richten - waarbij werk niet de primaire focus is van hun leven - is extreem ongewenst.

[Lawyerson]

Ik begrijp niet zo goed waarom je denkt dat dit mijn punt is.

Ik meende dat je reageerde op een bericht waarvan dat de essentie was maar ik zie nu inderdaad dat het ging over het feit dat verhoogde efficiëntie niet leidt tot minder werk.
Dat klopt inderdaad en wordt in de hand gewerkt door het systeem.

Toch denk ik niet dat "de kapitalisten" zich moeten beroepen op misleiding om dat verkocht te krijgen aan het volk. De steeds toenemende productiviteit zorgt ook mee voor het ongeziene niveau van comfort, gezondheidszorg, kennis enz. waartoe de gemiddelde burger nu toegang heeft. Ook dat is een verdienste van het kapitalisme. Of dat het nu waard is of niet is denk ik eerder een persoonlijke mening dan een objectieve vaststelling.

Het is zeker zorgwekkend hoe de middenklasse wordt uitgebeend en hoe de kloof tussen arm en rijk blijft toenemen. Dat de gemiddelde middenklasser dit zelf normaal vindt en zelfs zou verdedigen geloof ik dan weer niet.

[GigaHenk]

Het echter issue dien je te zoeken in geld. Ze zeggen niet voor niks 'follow the money'

Het loslaten van de goudstandaard door de US Dollar op 15 augustus 1971 heeft er voor gezorgd dat geld verdween en fiat daarvoor terugkwam. Fiat heeft een beperkte levensduur en leidt altijd tot meer uitgegeven dan je hebt en uiteindelijk gaat de waarde naar nul. Uiteraard kun je wat spelen met rentes en bail-outs. Een belangrijk gezegde in de financiële wereld is: You can't taper a Ponzi, wat zo veel wil zeggen dat je als je eenmaal de boel voor de gek houdt, dat, dat altijd uitkomt, want er mist gewoon geld, en iemand moet de rekening gaan betalen. Vandaar de kunstmatige rentes en bail-outs, maar op een gegeven moment houdt dat op. You can't keep kicking the can down the road.

Daarnaast speelt er een ander fenomeen en dat is het einde van een cyclus van de wereldmunt. Wie de wereldmunt bezit heeft de macht en als bijeffect moet je productie gaan verplaatsen van jouw land naar andere landen zodat zij ook die munt kunnen verdienen. Dat holt op een gegeven moment het land uit en de boel klapt in elkaar. Dat gaat niet ineens, maar geleidelijk. Dat is nu aan het gebeuren en een nieuwe rangorde moet ontstaan (zie ontstaan van BRICS). En dat gaat meestal gepaard met grote oorlogen

Kortom er gaat een hele heftige tijd op ons afkomen. En dat zie je wereldwijd al. De Euro en Dollar zijn niet meer geschikt om vermogen in op te slaan/te sparen. Vandaar dat geld vlucht in vastgoed, goud, grondstoffen en Bitcoin. Kortom allemaal zaken die de banken niet kunnen bijdrukken. Je wordt als burger gedwongen om te investeren om je vermogen te bewaren. Zekerheden vallen weg en het vertrouwen in overheden en media daalt hard. Want iedereen mag de schuld krijgen, behalve de veroorzaker.....

[Orgel]

Mooi gesproken. De elite houd namelijk stevig de handjes vast om het pleps in het gareel te houden. Niet voor niks gisteren het nieuwsbericht dat het vermogen van de rijken weer flink is gestegen. Lekker man! Is dat deels schuldig door de kudde zelf met z'n oogkleppen...zeker. Liever slikken dan uitspugen en we pakken ons telefoontje er maar weer bij kijkend naar diegene die het wel gemaakt hebben. Een verrotte maatschappij krijg je ervoor terug bestaande uit een slappe hap die constant z'n schouders optrekt.

[Tintel]

Dus een deel van de tech workers werkt nu aan technologie, zodat de rest ontslagen kan worden.
Ik proef ironie.

Dat gold indirect toch altijd al? En we werken ook zodat we minder kunnen / hoeven te werken - helaas lukt dat dus niet.
En het zou niet erg zijn om niet te werken als het systeem (en de maatschappij) erop ingericht zou zijn. Wat uiteindelijk noodzakelijk zal worden. Het sociale stelsel voorziet hier al deels in.

[Q]

Dat gold indirect toch altijd al?

Dus een deel van de tech workers werkt nu aan technologie, zodat de rest van de ICT-ers ontslagen kan worden. Ik denk dat dit juist een relatief nieuwe trend is, misschien van de laatste <10 jaar.

En het zou niet erg zijn om niet te werken als het systeem (en de maatschappij) erop ingericht zou zijn. Wat uiteindelijk noodzakelijk zal worden. Het sociale stelsel voorziet hier al deels in.

De maatschappij zal er nooit op ingericht worden want dat is niet in het belang van het kapitaal.
Het kapitaal heeft altijd werkers nodig en die wil je zo min mogelijk macht geven. Je moet hun lonen onderdrukken en ze moeten continue de dreiging ervaren dat ze hun huis en baan kunnen verliezen als ze niet braaf binnen de lijntjes kleuren.

Je ziet een grote opleving van vakbonden, maar ook een enorme tegenreactie om die vakbonden te breken. En vaak halen de vakbonden niet eens een inflatie correctie binnen, dus de werkende klasse gaat er steeds meer aan achteruit.

Een populatie met teveel vrije tijd, educatie en te weinig angst voor het kapitaal is gevaarlijk via de weg van democratie, langs welke weg wet- en regelgeving kan worden ingevoerd die het kapitaal voor de voeten loopt.
Niet dat via lobby daar wat aan gedaan kan worden, maar het is handiger als dat soort ongemak kan worden voorkomen.

[Tintel]

Ik bedoelde meer: als we iets automatiseren dan regelen eigenlijk we dat anderen niet meer nodig zijn.
Nu zijn ICT-ers bezig om te zorgen dat andere ICT-ers niet nodig zijn inderdaad.
Jij zegt dat het bijzonder is maar binnen de ICT is toch juist niet zo bijzonder?
Dat is eigenlijk niet nieuw. Assembler programmeurs zijn ook minder nodig omdat andere ICT-ers next-gen talen hebben ontwikkeld.

De maatschappij zal er nooit op ingericht worden want dat is niet in het belang van het kapitaal.

Dat is helaas waar... andersom betekent dat de macht van kapitaal dus minder moet worden en stom genoeg heeft kapitaal, zeker nu nog, mensen nodig.
Maar jij noemt zelf ook al trends die proberen de macht enigszins te doorbreken.

[Q]

Ik ben het met je eens vanuit dat perspectief, ik heb het gevoel alleen dat er in het verleden altijd ruimte was om ICT-ers gewoon een nieuw trucje te leren en dan weer nuttig in te zetten en dat zie ik voor mijn gevoel juist veel meer verdwijnen.

[Tintel]

Denk je? Ik vermoed dat we juist steeds meer ICT-ers nodig hebben omdat totale integratie nog ver weg is. En ook omdat automatisering uit zichzelf leidt tot nog meer automatisering.
Alleen een boekhoudpakket is niet genoeg. Daarna heb je ook DIS nodig en 'access-anywhere' en 100% uptime enz....

Zelfs binnen fabrieken waar veel automatisering te vinden is zijn nog lang niet alle systemen aan elkaar gekoppeld. En vervolgens bestaan er 2 systemen waarvoor weer een 3e systeem of interface moet worden ontwikkeld om te zorgen dat die systemen met elkaar kunnen werken.

En daarnaast zie je de automatisering steeds verder doorzetten in produkten die het eerst niet eens nodig hadden (een lamp kon aan of uit en dat was het...).

[Q]

Ik zie het aan mijn neef die allerlei certificaatjes (microsoft) heeft gehaald de afgelopen 20+ jaar en nu toch op straat wordt gezet, en gegeven wat ik van hem weet en wat hij doet kan hij gewoon niet meer mee komen en zeker niet voor dat salaris.

Maar wat hij doet is misschien niet representatief.
Ik weet het uiteindelijk ook niet.

[w3news]

Doordat we voortgang maken, en meer werk kunnen verzetten, groeien we.
Dit is inderdaad niet nodig.
Je zou steeds minder hoeven te doen om hetzelfde te bereiken.
Alleen wie wil op hetzelfde blijven hangen?
Wil je een nieuwere, betere, snellere van iets?
Kijk naar dingen als je computer, telefoon, auto, ...
Je kunt prima werken op een computer met de techniek van 20 jaar oud, en in een auto rijden met de techniek van 20 jaar geleden, en bellen met de telefoon van 20 jaar geleden.
Al die dingen zijn nu goedkoop te krijgen, maar we (veruit de meeste) kiezen toch voor de nieuwste ontwikkelingen. (hoewel ik oldtimer autos kies boven een gloednieuwe auto)
En we maken steeds weer een stap verder.
Om dit te kunnen bereiken, moet je steeds moeite doen om verder te ontwikkelen.

Zo ook met AI, dat kan zorgen dat je als programmeur sneller iets voor elkaar kan krijgen, of ingewikkelder issues op te lossen in dezelfde tijd.
Als je denkt dat je minder programmeurs nodig zal hebben, dat programmeurs zichzelf overbodig maken, is een utopie.
Een programmeur is geen lopende band medewerker, maar een professional in zijn vak.

Ook met AI heb je bepaalde kennis nodig om AI de juiste opdrachten te geven.
AI moet je zien als assistent, en is geen senior op een bepaald vakgebied.

Het kan zijn dat het werk van programmeurs veranderd, maar je zult ze nodig houden, om steeds verder te groeien.

Kapitalisme is geen aanwijsbaar groep van personen, wat een PR kunstje kan doen, het is een gedachte in de maatschappij, waarmee we zelf onze verlangens bevredigen.

[Q]

[quote]

Kapitalisme is geen aanwijsbaar groep van personen, wat een PR kunstje kan doen, het is een gedachte in de maatschappij, waarmee we zelf onze verlangens bevredigen.

Kapitalisme kent twee groepen, de mensen mét het geld, het kapitaal en de mensen die dat niet hebben.
Wij weten heel goed wie dat zijn. En we weten heel goed wat ze doen en waar ze hun geld in steken, waar de focus van hun lobby nu ligt.

Maar als jij je leven afmeet aan geproduceerde shareholder value, be my guest.

[Reactie gewijzigd door Q op 30 oktober 2024 18:54]

[HEY_DUDE]

AI —> minder mensen voor huidige productie nodig—> uitbreiden productie / sneller groeien —> shareholder value.


Het zal een beetje van beide zijn. Maar zowel de lopende band als computers hebben niet gezorgd dat mensen overbodig werden. Het wordt waarschijnlijk deels ook schuiven in functies. Met de vergrijzing zal er voorlopig nog werk genoeg blijven.

[Q]

De lopende band en de computer hebben er voor gezorgd dat mensen productiever worden en daardoor dingen mogelijk waren die dat eerst niet waren, waar weer mensen voor nodig waren.

Maar dat was vaak in een context waarbij de markt nog onontgonnen was en voor zowel autos als computer toepassingen is daar al lang en breed een verzadiging opgetreden.

Verhoogde arbeitsproductiviteit is voor ons niet relevant, wij moeten toch 32-40 uur werken - we blijven loonslaaf of freelance slaaf. De waarde die wij met die 32-40 uur produceren als 'slaven' komt allemaal in de zak van de kapitalisten.

Waarom vinden wij dat normaal? Waarom komt dat niet in onze zakken zodat we minder hoeven te werken? Waarom moeten wij onderling met elkaar 'vechten' om baantjes terwijl de kapitalisten smalend en lachend toekijken en ons (en onze samenleveing) compleet kaalplukken.

[Tintel]

Omdat dit helaas al heel lang de situatie is... en die situatie lijkt voorlopig niet te veranderen omdat macht en (veel) geld nogal sterk samenhangen.
Natuurlijk profiteren we wel deels van de verhoogde productiviteit omdat nu ook meer mensen bepaalde produkten kunnen bezitten.
Maar stom genoeg zijn veel van die produkten weer nodig om te zorgen dat we idd ongeveer 40 uur per week werken....

[Q]

Precies, helemaal mee eens.

Het is zo erg dat we geconditioneerd zijn om te willen wat we willen. De mooie auto, het kekke truitje, een nieuwe telefoon, het blinkende lichtje.

Maar waarom eigenlijk?

[Tintel]

Maar waarom eigenlijk?

Idd - goeie vraag. De mooie auto om naar het werk te gaan...

Maar deels komen die wensen niet zozeer vanuit de ambitie om te willen werken. We hebben ook nog wel wat oerinstinct over denk ik - en dat instinct is op zoek naar een partner en/of een nest... en daarvoor heb je middelen nodig en dien je 'indruk' te maken.

[djwice]

Er is een te kort aan personeel om al het werk te doen, bij ons alleen al hebben we 10% meer mensen nodig (HBO+ in NL) om het huidige werk te kunnen doen.

AI != minder mensen

AI => meer werk dat bleef liggen kan worden gedaan.
AI => er is nu technisch meer mogelijk => er komt meer werk bij.
AI => werk dat onbetaalbaar was voor vele wordt nu betaalbaarder => meer vraag => meer werk

=> meer waarde creatie
=> beter voor bedrijfszekerheid
=> goed voor de betrouwbaarheid van het aandeel
=> meer vraag naar het aandeel
=> aandeel waarde structureel omhoog

[Reactie gewijzigd door djwice op 30 oktober 2024 14:16]

[Q]

Het zou best kunnen dat je gelijk hebt.

Maar ik denk niet dat het zo zal lopen of ik moet een aantal structurele voorbeelden zien waarbij het spel zich zo zal uitspelen zoals jij het schetst.

Het werk van 10 mensen weg automagiseren op een bestand van 100 mensen is best een hoge lat.
Wat jij schetst vraagt om een best-case scenario met behoorlijk competente mensen door de hele linie van het bedrijf om dit succesvol te maken.

Ik vraag me echter vaak wel af in hoeverre er écht een tekort van 10% is, of dat het zo georganiseerd is om druk uit te oefenen op het huidige personeel. Of betekent een 10% tekort dat de geboden salarissen gewoon niet aantrekkelijk zijn?

Ik bedoel marktwerking werkt twee kanten op.

[djwice]

Ik heb letterlijk opdrachten op de plank liggen waar we meerdere IT-scrum teams voor nodig hebben, meerdere jaren, in regio Zuid-Holland.

Alleen nog niet alle mensen om dit werk te doen. Als we 150 goede IT-ers aangeboden krijgen kunnen we ze na hun opzegtermijn en de onboarding direct in zetten op plekken waar nu niemand aan werkt.

Het werk en het geld ligt letterlijk te wachten op mensen. En dat zijn goed betaalde banen met vaste contracten en opleidingsmogelijkheden etc.

[Reactie gewijzigd door djwice op 30 oktober 2024 14:42]

[Q]

Bedankt voor het delen. Maar als je een moment mijn cynische circelredenerende bril opzet, is de conclusie niet gewoon dat de salarissen en het gebodene blijkbaar gewoon niet aantrekkelijk is voor de doelgroep?

Het is makkelijk van mij om dat te schrijven, maar als je geen mensen kunt krijgen is het werk niet interessant en/of het salaris niet aantrekkelijk genoeg om mensen de overstap te laten maken?

Mag ik vragen over welke salaris ranges we het hebben? En zijn freelancers (g)een optie?

[djwice]

Het is uiteraard gissen zonder context.

Maar kort samengevat denk ik dat veel mensen gewoon niet weten dat we er zijn en hoe leuk het is om bij ons te werken.

We focussen op projecten waar je voor lange tijd aan wil werken. Als freelancer/ondernemer wil je denk ik juist vaker van opdrachtgever wisselen?
Wellicht dat de mensen die nu freelancer zijn, maar eigenlijk niet willen ondernemen, met de wetswijzigingen komend nieuw jaar, sneller naar onze vacatures voor een vaste betrekking kiezen.

Onze salarissen zijn niet publiek. En je salaris is zeer afhankelijk van je kennis en ervaring; wat kom je brengen, wat wil je leren, wat is je ambitie. Maar ter indicatie ik ben zelf overgestapt uit de financiële wereld.
En ik heb hier als IT-er wel een optie regeling, een bonus regeling en tegemoetkoming in zorgkosten.

[Q]

Het blijft wat vaag en dat is je goed recht. Echter een goede freelance dev zit op, of fors over de Balkenende norm. Misschien dat de komende wetswijzigingen de markt gaat drukken, kan. Dat je geen mensen kunt krijgen op het prijspunt dat je zoekt, tja. Dan denk ik toch dat je te weinig betaald of idd te weinig marketing doet

[djwice]

Als ik het zo uitreken:
€233.000/1.800 =
€130,- per uur is de Balkenende norm.

Er zijn niet veel opdrachten die dat kunnen betalen voor elk team lid.

[Tintel]

Dat heeft eigenlijk niet met AI an-sich te maken...
Zodra ergens 'verlichting' optreedt (dus iets minder tijd nodig), dan wordt meer (ander) werk mogelijk.

En meer output vanuit een bedrijf is altijd gunstig.

Dat we steeds meer kunnen met iets minder mensen betekent dus meer output voor de volgende fase in het proces en vervolgens neemt niet overal de hoeveelheid output verwerking even snel toe en heb je een tekort (aan verwerkingsmogelijkheden = mensen).

[djwice]

Precies. En dus ook in het geval van AI is dat zo. Vandaar dat ik

AI —> minder mensen —> ontslagen —> shareholder value

ontkracht. Shareholders worden over het algemeen niet blij van minder mensen. Meer value en voorspelbaarheid is veel belangrijker.

Kort voor verkoop van bedrijfsonderdelen door financiële partijen wordt er gekeken naar kosten van bemensing conform standaard modellen, en dan wordt er 'gesneden' tot voorbij het bot om er aantrekkelijk uit te zien of om overlappende functies (voor bepaalde personen) na de fusie te voorkomen.
Maar dat is in de IT niet aan de orde, mensen zijn daar juist het kapitaal.

[bzuidgeest]

AI —> mensen nodig om het allemaal na te lopen —> Geen verschil in personeelsbestand —> no shareholder value.

[Q]

Het gaat niet om hoe het écht werkt, het gaat erom wat je kunt spinnen zodat je aandeel omhoog gaat. Dat is het spel wat gepeeld wordt.

[Reactie gewijzigd door Q op 30 oktober 2024 11:10]

[bzuidgeest]

Voor google gaat het daar misschien om, voor mij gaat het om hoe het echt werkt. Ik zit op de laag waar ik resultaat moet leveren

[Q]

Voor jou werkt dat spel ook zo, maar je hebt ‘m nog niet door

Er wordt bepaald resultaat verwacht maar hoe je dat realiseert maakt niet uit toch?

Sneller iets opleveren is onverstandig, dat schept precedent en dat leidt tot een race to the bottom

[bzuidgeest]

Er wordt bepaald resultaat verwacht maar hoe je dat realiseert maakt niet uit toch?

Maar dat is ook niet wat ik zeg. Ik zeg dat er geen verkleining is van het personeelsbestand omdat alles van de AI moet worden nagekeken op hallucinatie en functioneren.,

[Q]

Het punt is dat je waarschijnlijk gelijk hebt, maar zo werkt het spel denk ik niet.
Mogelijke scenario’s:

- Het AI boxje is afgevinkt en verder kijken we nergens naar
- Het AI boxje is afgevinkt maar iemand wil ROI zien

Iemand wil ROI zien:

- ontslag van mensen (los van de vraag of het verstandig is (irrelevant))
- meer omzet / marge (meer werk om daar causaal ROI uit te frauderen)

Iemand die een beetje competent is kan dat tweede punt wel bij elkaar fraudiceren.
Maar wie lui is ontslaat gewoon een zooi mensen

[bzuidgeest]

Het gebeurt wel zo in die grote bedrijven, maar het is ook iets waar zelfs grote bedrijven af en toe kapot aan gaan.

Het is wat mij betreft vergelijkbaar met GDP/BBP of dat soort dingen. Er werd en word of veel plekken gestuurd om dat zo hoog mogelijk te krijgen want dan zou je economie het goed doen en dat is goed voor het volk. Een extra cijfer dat gebruikt word is dan GDP per inwoner. Dan delen ze de GBP door het aantal inwoners. Hoe hoger hoe beter......
Als je dat voor Nederland doet krijg je wellicht nog een redelijke uitkomst, maar doe je dat voor Amerika dan ga je de boot in. Het houd namelijk geen rekening met inkomens ongelijkheid en die is enorm in Amerika. Wellicht wel een van de ongelijkste in de wereld.
Maar tussen 0 en ultrarijk zit hetzelfde gemiddelde als iedereen wanneer in de middenstand zit.
Het IMF raad dus tegenwoordig af dit nummer te gebruiken als maat voor welvaart, maar dat verander je niet zomaar.

Je kan wel alles bij elkaar frauderen en slechte beslissingen nemen die er wel leuk uitzien voor de aandeelhouders (ROI), maar ergens word je door de werkelijkheid ingehaald.
Boeing doet tegenwoordig ook alles voor de aandeelhouders waar het in het verre verleden een bedrijf was gerund door engineers. Leuke cijfers, maar nu dondert het hele kaartenhuis in elkaar. Personeel dat het zat is om uitgeknepen te worden en vliegtuigen met design issues en veiligheid issues. Ons Europese Airbus kan niet de onderdelen bij elkaar slepen om vliegtuigen voor alle ex-boeing klanten te bouwen.

Dus ja, wat jij suggereert is een manier om een bedrijf te runnen. Je kan er korte termijn rijk van worden, lange termijn is het heeeeeel slecht.

[Q]

Ik ben het eens met alles wat je schrijft.
Boeing is juist een voorbeeld van short-term shareholder value najagen en dat gaat soms mis. Door heel veel mensen al jaren voorspeld, maar dat maakt niets uit voor de mensen die op de waarde van het aandeel worden afgerekend. (Denk aan Enron).

[seanpaul]

Zelf gebruik ik ai om mijn code na te kijken voor verbeteringen. Bijvoorbeeld, ik schrijf kotlin code en dan vraag ik aan ai of het mijn code "idiomatischer" kan maken met expliciet de vermelding om de functionaliteit niet aan te passen.

[djwice]

Ik gebruik CoPilot in Edge en kun je verzekeren dat met een goede prompt en een OpenAPI spec met strikte input en output definities je goede en werkende code kunt krijgen.

Zowel voor je infrastructuur zoals CDN, FireWall, Database en API Gateway, Proxy, als je software, zoals je HTML5, CSS3, Service worker als je backend API incl. stricte type definities, input validatie en validatie schema's voor je MongoDB.

De infrastructuur voldoet dan aan eisen als HIPAA, PCI-DSS, incl. least privilege principes en encryptie waarbij de sleutels tijdens deploy buiten de software (en mensen) om worden gegenereerd en opgeslagen in het key management systeem.
En de software voldoet aan de strengste WCAG, Observatory en Google Light House testen.

Dit werkt ook met Gemini2. Je kunt dan zelfs vragen om de infrastructuur die je op AWS hebt laten genereren om te zetten naar code voor Azure infrastructuur.

Ook algoritmes voor natuurkundige principes worden foutloos geïmplementeerd, met de juiste prompt.

Hoe meer kennis je zelf hebt over wat je wil dat er gemaakt wordt, hoe beter je een instructie kunt schrijven in de prompt.

En ja, de OpenApi definitie incl. stricte validaties kun je ook laten schrijven. Dit kan door te beschrijven wat je wil dat de applicatie gaat doen en en welke normen die moet voldoen. Bij sommige AI modellen moet dat in een paar sequentiële stappen.

[Reactie gewijzigd door djwice op 30 oktober 2024 11:30]

[_eLMo_]

Zelfs al doet hij alleen de herhalingen, dan scheelt dat nog flink wat werk.

Ik ben tevreden over AI. Gisteren heb ik Claude.ai nog een Java commandline utility laten schrijven om SQL insert scripts te maken voor E2E test scenario's. De code was in 1x goed. Kostte me 10 minuten in plaats van 2 uur. En natuurlijk kijk je de code even na, maar een code review is een stuk minder werk dan zelf schrijven.

Prompt engineering is wel een skill die je aan je toolbag moet gaan toevoegen in dit vakgebied.

[jorisporis]

Ja 25% lijkt me weinig. Boilerplate genereren met juiste variable namen is al bijna 25%.
Het enige waar ik me aan erger zijn collega's die denken dat alles gewoon door AI gebeurd. Je moet de juiste prompts kunnen vragen dus vereiste kennisniveau blijft gelijk. (of zelfs hoger, het zal meteen opvallen als je een dag vast zit op iets) en uiteraard de responses kunnen analyseren op bugs.

[ZinloosGeweldig]

We zijn hier lekker aannames aan het doen over wat 25% nou inhoud, maar dat lijkt me niet zo simpel. Is een vrij ambigue stelling.

25% van de regels?

25% van de bytes aan programma code?

25% van de commits volledig door AI geschreven?

[jorisporis]

Commits die volledig autonoom gebeuren lijken me nog niet mogelijk tenzij google stiekem al een AGI heeft draaien

[djwice]

AWS heeft al een AI die dat doet. Die leest de Jira stories, kiest er een. Pakt de codebase en gaat aan de slag.

Als er dingen onduidelijk zijn, stelt ie vragen. En anders commit ie de code en zet de story "to review".

Bestaat al een tijdje.

Vaak heeft het wat tussenstappen. Dan geeft hij eerst een plan van aanpak en vraagt om een review daarvan etc.

[Reactie gewijzigd door djwice op 30 oktober 2024 14:23]

[jorisporis]

Lijkt me niet dat hij zelfstandig commit dan.
Bovendien ben ik erg benieuwd naar een praktijkvoorbeeld.
Als je programmeurs niet met de neus op de code zitten lijkt het risico op introductie van bugs me gigantisch.
Gaat het misschien om een webpagina of single page app zonder backend dan?

[djwice]

Wat bedoel je met een commit? Een merge naar main? Of een feature branch die na goede test/review kan worden ge-merge-t?

De tools schrijven vaak eerst de tests, denk aan BDD, en een ontwerp aanpak. Na goedkeuring kan de code gewoon geschreven worden toch?

Die nieuwe developer op je team laat je immers ook toe


Ik zie het een beetje zo: hoe meer code er voor een taal of framework is op internet beschikbaar is, hoe beter de best practices online verwoord zijn door authoriteiten in het vakgebied of taal, hoe kleiner de kans dat een AI het slechter doen dan een mens.

Dus hoe duidelijker de DoD alom bekende standaarden aanhaalt. Hoe beter de code.

Dus maak je dingen in Java (Spring, Boot, Quakus) of Python of NodeJs. Of infrastructuur voor AWS. Die dingen zijn zo alom goed vertegenwoordigd met ook beschikbare patterns, dat je simpelweg naar de patterns als eisen verwijst en dat het (zo goed als) foutloos gaat. De foutjes worden vaak door je standaard checks ook gevonden. Uiteraard krijgt de AI die ook als feedback en past zo de code aan.

[Reactie gewijzigd door djwice op 30 oktober 2024 20:55]

[jorisporis]

Met een commit bedoel ik code die goed genoeg is om naar de rest van je team te pushen zonder dat het een last voor hen is.
Uit je uitleg hierboven begrijp ik dat een ai dit momenteel niet kan. Je moet de patterns kennen om een goede prompt te geven aan je ai, je moet de werking van code doorzien. Wel kan het je werk versnellen. Een junior kan nog steeds zaken die ai niet kan.
Een prompt in de trend van "bouw mijn applicatie", "hier is code en los de bug op" heb ik nog nooit resultaat mee behaald.

[ZinloosGeweldig]

Oke maar dat is niet wat ik bedoelde met commits volledig door AI geschreven.

AI schrijft feature en commit naar feature branch.

Mens reviewt pull request.

Dat is wat ik bedoel. En dan heb je het toch over een feature die volledig door AI geschreven wordt, niet alleen boilerplating.

[djwice]

Dat is wat ie doet: feature implementatie.

Bijvoorbeeld hier is de OpenAPI spec, schrijf een service worker die fungeert als proxy die alleen requests naar de API door laat die voldoen aan de input validatie. Als het requesr niet voldoenlt geef dezelfde foutmelding terug als dat de API zou doen.

Gaat gewoon foutloos.

[jorisporis]

Goed, maar als iemand in je team de hele tijd merge requests maakt die op niks trekken...
Het kan natuurlijk perfect. Maar mij lijkt dat een mens in de loop moet zitten eerder. Ai is voor mij net als een junior die je een simpele taken geeft.
De meeste juniors kan je complex werk geven en na een tijdje komen ze er wel uit en kijk je nog eens na. Ai haalt dit niveau niet als ik dit test. Je moet gedetailleerde prompts geven voor kleine stukjes codes. Alsof je de hele dag naast een junior zit om uitleg te geven. Het is inderdaad sneller. Maar het gaat zeker geen user stories omzetten in kwalitatieve commits zoals jij doet uitschijnen.
Als jij wel consistent van concept naar werkend, kwalitatieve code gaat met AI met minimale menselijke tussenkomst ben ik benieuwd naar je use cases.

[ZinloosGeweldig]

De meeste juniors kan je complex werk geven en na een tijdje komen ze er wel uit en kijk je nog eens na. Ai haalt dit niveau niet als ik dit test. Je moet gedetailleerde prompts geven voor kleine stukjes codes.

Ik verwacht niet dat de AI die google gebruikt om code binnen hun code base te genereren een algemeen getrainde LLM is. Die zal veel specifieker getraind zijn op de codebase van Google en gebruikte technologieën. Wat jij met een algemeen getrainde LLM (bijv gpt-4o of Copilot) kan zegt niet veel over wat zo'n veel specifieker model kan.

Het lijkt een beetje alsof je jou ervaring met general LLM's projecteert op de mogelijkheden van specifiekere LLM's.

[Reactie gewijzigd door ZinloosGeweldig op 31 oktober 2024 17:10]

[djwice]

Als de AI toegang heeft om de code uit te voeren en de logs te zien, kan het wel degelijk bugs oplossen.

[jorisporis]

In welke context en toepassing behaal je hier goeie resultaten mee?
Laat je AI zelfstandig je codebase aanpassen en pushen naar git? Jij drukt enkel nog ok voor de zekerheid?
lijkt me dat er grote rampen gaan gebeuren in jou projecten. Wat chatbots genereren heeft toch niet de kwaliteit om op die manier te werken?

[djwice]

Mijn ervaring is anders. Wellicht gebruiken we andere prompts.

[jorisporis]

Of we werken op andere technologie.
een goede regel is in mijn ogen: Als het niet op stackoverflow is uitgelegd en 10 verschillende blogs is de kans klein dat AI het lukt.
Websites, ja.
Basic Excel macro, Ja,
nieuw algoritme om de chocoladeproductie van volgende maand op punt te stellen op basis van je Erp en MES, nee.
De meeste IT-vraagstukken zitten toch in de 3e categorie en ik zie niet hoe een ai dit voor het eerst gaat oplossen.

[djwice]

ERP systemen zoals SAP, Siebel, Dynamics, Salesforce en hun programmeertalen zijn goed bekend en gedocumenteerd.

Ze gebruiken SOAP of Rest voor communicatie. Die hebben daarvoor in het algemeen een WSDL of Swagger (OpenAPI) definitie.

Van MES-systemen weet ik niet veel, ik neem aan dat zij op een gestandaardiseerde/gestructureerde manier hun data ontsluiten.

Algoritmes voor chocolade voldoen aan standaard chemische en natuurkundige principes. Dus met de juiste instructie en data koppeling moet een AI juist uitermate geschikt zijn om een sturings algoritme te ontwikkelen.

[jorisporis]

Dergelijke systemen zijn per definitie op maat van een bedrijf gemaakt en doorgaans enorm bagger gedocumenteerd.
Je hebt doorgaans mensen binnen het bedrijf nodig om de nodige context en toelichting te geven.
AI kan hiermee helpen om zaken snel te documenteren. Maar doet het lijken of een AI alles kan en een programmeur erbij zit om ernaar te kijken. Terwijl je nog steeds alle kennis nodig hebt.
Daarbij heeft eens mens nog het inzicht wat een llm niet heeft, zoals hieronder aangegeven.

[Reactie gewijzigd door jorisporis op 31 oktober 2024 19:52]

[djwice]

Je hebt alle kennis nodig om de AI aan te sturen, je moet immers duidelijk maken wat je wil.

En dat kunnen vereist over het algemeen brede en diepgaande kennis van de systemen en functie.

Als dingen niet goed zijn gedocumenteerd is dat voor de meeste mensen lastig, ook voor ervaren programmeurs. En hoe minder uniform een systeem werkt (een output in liters, ander in gallons, maar moeten wel samen gebracht, maar de eenheid is nergens gedocumenteerd), hoe groter de kans op (menselijke) fouten in het bedrijfsproces door onduidelijkheid/verwarring.

Ik probeer altijd eerst te zorgen dat systemen uniform(er) worden en eenduidig (bijvoorbeeld: de betekenis van negatief en positief op een bepaalde meet as is in alle systemen gelijk). Dat reduceert de complexiteit in de sturing enorm, en dus ook in de nauwkeurigheid en ondubbelzinnigheid van je algoritmes.

[Reactie gewijzigd door djwice op 31 oktober 2024 20:57]

[w3news]

Wat ik overigens aardig vindt werken is als ik eerst de tests schrijf, met de scenario's.
Daarin beschrijf je wat het zou moeten doen. (TDD)
Daarna kan AI de code genereren.
Hiermee kun je veel code genereren, en bepaal je door je tests de input en output.
De code zelf kun je daarna eventueel refactoren.

[SoloH]

Ik gebruik dan ook vaak AI om juiste een opzet te maken van een probleem wat ik wil tackelen.

[Boost9898]

AI om intern ons proces van programmeren te verbeteren en dat geeft een boost aan productiviteit en efficiëntie. Nu genereert AI een kwart van alle nieuwe code, waarna engineers het nakijken en goedkeuren.

Exact, AI verhoogt productiviteit en efficiëntie, maar het kan ten koste gaan van de kwaliteit. Ik denk daarom ook dat deze werkwijze op de lange termijn problematisch kan zijn. Op een gegeven moment zullen ervaren engineers met pensioen gaan, en toekomstige generaties zouden minder vaardig kunnen zijn omdat zij afhankelijk zijn van AI die is getraind op data van ervaren programmeurs.

[SuperDre]

In de nabije toekomst is AI beter in programmeren dan nu de ervaren mensen zijn.

[Boost9898]

Ja en nee. AI wordt zeker steeds beter en kan veel simpele code tasks sneller aan dan mensen. Maar echt programmeren is meer dan alleen code kloppen; het vraagt inzicht, creativiteit en begrip van context waar AI nog lang niet aan kan tippen. Ervaren developers zien problemen die AI gewoon mist en kunnen creatieve oplossingen bedenken voor specifieke situaties, wat een model niet kan.

[Tintel]

Idd. Het idee dat deze non AI opeens inzicht heeft. Over de gehele linie van automatisering (en mechanisering) is dat nu juist het grootste probleem. Natuurlijk is het relatief eenvoudig om problemen die al ooit eens eerder zijn opgelost, weer op te lossen met behulp van een heel krachtig zoek-algoritme en combinatoriek om bepaalde afwijkingen van de originele probleemstelling op te vangen en misschien zelfs combinaties van oplossingen kan maken. Zeker indrukwekkend daar niet van maar...

Deze AI vindt opnieuw het wiel uit zeg maar - iets wat handig kan zijn maar laten we niet doorslaan.

Ik begrijp wel dat we (de maatschappij) daar naar toe willen - maar ondertussen wordt er hard gelachen om (bijv.) Elon Musk die al meer dan 10 jaar roept dat de autonome auto 'bijna' klaar is.

En nu hebben we dan AI die kan programmeren..... iets wat notoir ingewikkeld is - moeilijker dan autorijden zou ik denken....

[Orgel]

Uiteindelijk zullen AI's ook gehackt worden of ze hacken zichzelf door een stuk malware te implementeren die de junior programmeur even over het hoofd zag.

[xorpd]

Nope. De eerste creatieve (dus niet generatieve) AI moet nog uitgevonden worden.

[Die_ene_gast]

Daar geloof ik niets van.

Recentelijk eens copilot (betaald) uitgeprobeerd. "refactor dit ff" en tot 3 keer toe de array indicator vergeten.

Dat kan zelfs een eerste jaars hierzo.

[MarCreative]

Precies dit heb ik al ondervonden. Zelf ben ik werkzaam als senior ontwikkelaar, en waar ik eerder gemotiveerde junioren onder de vleugels nam, zijn dit nu junioren (wellicht ook gemotiveerd) maar die alleen code kunnen schrijven met AI tooling. Het zelf begrijpen van de code is een stuk minder geworden.

[Stukfruit]

En zo wordt de gemiddelde programmeur een productiemedewerker.

Maar dat proces was al een tijd gaande voor de introductie van LLM's

[jorisporis]

En zo wordt de gemiddelde programmeur een productiemedewerker.

Als dat zo is, zit je met een gigantisch probleem. Heb gewerkt bij bedrijven waar er documentjes geschreven worden, over de muur der verwarring gegooid worden richting de "programmeurkes", en dan weer naar productie. Nooit zo'n lage kwaliteit gezien en ging over safety systemen.
Als je zo opereert ben je over enkele jaren failliet of in geval van overheid gaan grote rampen gebeuren.
Je moet de juiste prompt kunnen geneneren en de code kunnen reviewen!

[Stukfruit]

Oh hou op inderdaad, documenten van veel managers die omschrijven wat ze willen kun je meestal beter per direct in de prullenbak gooien

Maar die prompts hoef je straks natuurlijk niet meer te schrijven. Je doet tegenwoordig tenslotte meestal ook niets meer met assembly. Het is maar een extra laag aan abstractie. Dat zie je door de jaren heen voor veel nieuwe tech ontstaan en ik verwacht niet dat het hier anders zal zijn.

[bzzzt]

Of je nou assembly of Prolog schrijft maakt een wezenlijk verschil in het abstractieniveau maar voor beide talen kan je prima beredeneren wat er gaat gebeuren en of dat wel of niet juist is.
Als je bouwt 'bovenop' AI wat inherent enigszins willekeurig is en niet 100% traceerbaar van de vraag naar het antwoord verlies je domweg de mogelijkheid zelf garanties over je software te geven (of, in het geval dat je zelf je abstracties niet begrijpt, iemand anders die garantie te laten geven).

[Stukfruit]

Structured output en temperatuur op 0 doet een hoop

En ik weet niet of je wel eens met grote hoeveelheden aan dynamische data uit variërende bronnen hebt gewerkt, maar die garantie is al wat jaren niet meer te geven op basis van de gebruikte abstracties.

Bij de complexere systemen wordt al gewerkt op zo'n manier dat eventuele fouten er uit worden gewerkt voordat data wordt gebruikt. Normaliseren dmv o.a. stream processing, enz.

Dat geldt niet voor het gemiddelde chatbotje maar daar is het niet echt een vereiste te noemen.

Het is maar net hoe je het toepast. Hacken kan iedereen. Dat gaat hiermee niet anders zijn.

[bzzzt]

Structured output en temperatuur op 0 doet een hoop

De oplossing voor het niet precies zijn van AI is niet nog meer AI er op gooien om de kans naar 'bijna 0' te halen, maar zorgen dat je causaal bewijs kan leveren dat je oplossing klopt.

En ik weet niet of je wel eens met grote hoeveelheden aan dynamische data uit variërende bronnen hebt gewerkt, maar die garantie is al wat jaren niet meer te geven op basis van de gebruikte abstracties.

Wat je daar beschrijft is een werkwijze waarbij je feitelijk al statistiek aan het bedrijven bent. Dat je daar met een bepaalde foutmarge kan dealen maakt AI nog niet geschikt voor alle softwareproblemen.
Je zal als klant maar aan het ontvangende eind van een AI pijplijn zitten en bv duizenden euro's extra belasting moeten betalen want de kans op fouten wordt zo klein geacht dat het systeem altijd gelijk krijgt...

[Stukfruit]

Dat je daar met een bepaalde foutmarge kan dealen maakt AI nog niet geschikt voor alle softwareproblemen.

Dat is hier bij mijn weten niet direct of indirect gezegd.

Je zal als klant maar aan het ontvangende eind van een AI pijplijn zitten en bv duizenden euro's extra belasting moeten betalen want de kans op fouten wordt zo klein geacht dat het systeem altijd gelijk krijgt...

Ik denk niet dat je begrijpt wat ik schreef: ML is een onderdeel in het proces, niet "een AI pijplijn". Dat laatste is voor marketeers.

Verder is het enorm afhankelijk van wat er gemaakt dient te worden, zoals je ongetwijfeld zal weten.

[Reactie gewijzigd door Stukfruit op 30 oktober 2024 18:53]

[jorisporis]

Ik bedoel de prompt aan de ai chatbot, niet je shell 😁

[NLxAROSA]

Als mensen denken dat het schrijven van code het werk is van een developer en niet het hele gedachten proces erachter, dan denk ik dat heel veel bedrijven zometeen zitten met code waarvan niemand weet waarom het doet wat het doet.

Dit gaat keihard in Googles gezicht opblazen.

Dat je met trots aankondigt dat “25% van onze code is gekopieerd van stack overflow” zou bizar zijn toch? Dit is min of meer hetzelfde.

[Reactie gewijzigd door NLxAROSA op 30 oktober 2024 09:43]

[drdelta]

"We hebben een zwarte doos op kantoor staan die 25% van onze bedrijfskritische code verzint. We weten niet hoe het apparaat werkt, we weten niet of de code gestolen is, het kost ontzettend veel geld en stroom, en we weten dat we alles moeten controleren om zeker te zijn dat het daadwerkelijk werkt. Maar, er is nog niets mis gegaan."

[Stukfruit]

Dat van die zwarte doos is marketing en selectieve incompetentie

Het is prima uit te zoeken wat er het model in gaat (tenzij dat onderdeel closed source is) en de rest is maar een geavanceerde blender.

[drdelta]

Dat van die zwarte doos is marketing en selectieve incompetentie

[warzaw]

Ik vraag me dat sterk af. Bij Google werkt op technisch gebied alleen de elite van de elite (de 1% van de 1%), met andere woorden: hier hebben heel extreem slimme mensen echt wel goed over nagedacht. Daarnaast is het zoals in andere comments ook te lezen valt natuurlijk vooral marketing en het spel op de juiste manier spelen waar Google heel erg goed in is geworden.

[bzzzt]

Als mensen denken dat het schrijven van code het werk is van een developer en niet het hele gedachten proces erachter, dan denk ik dat heel veel bedrijven zometeen zitten met code waarvan niemand weet waarom het doet wat het doet.

Je beschrijft nu de situatie van een significant aantal bedrijven met softwarepakketten ouder dan 10 jaar waarvan de originele ontwikkelaars al lang zijn vertrokken.
AI zorgt er alleen voor dat dat punt sneller bereikt wordt.

[Dazzyreil]

Dat je met trots aankondigt dat “25% van onze code is gekopieerd van stack overflow” zou bizar zijn toch? Dit is min of meer hetzelfde.

Dat is toch ook precies wat een normale dev ook doet?

[Sailor69]

Bv bij Voyager 1

[SgtElPotato]

Is het nog wel nodig om alles te begrijpen aan code om het te kunnen maken? Ik heb thuis zelf diverse scripts en docker containers gemaakt met software (die ook elders te vinden was) die ik zelf nooit zou kunnen maken vanwege beperkte kennis. Op deze manier kan ik ook veel makkelijker scripts maken die data ophalen, formateren en op mijn manier uitprinten. Of websites maken zoals ik ze wil.

Over een jaar of 5-10 denk ik dat dit soort banen ook gaan verdwijnen en dat we dan meer software controleurs krijgen in plaats van ontwikkelaars. Het zijn immers taken die door AI gedaan kunnen worden, en vele malen efficienter en sneller straks.

[Jobjl]

Prima als hobby projectje.
Maar dit moet je natuurlijk niet willen als er grote (financieele) belangen aan zitten.
Zal code in productie gaan, blijkt er een bug te zitten. Helaas begrijpen de devs niet alles meer en de AI die dit heeft gemaakt kan t ook niet oplossen.
Daar gaan je klanten...

[SgtElPotato]

Op dit moment zeker nog niet haalbaar inderdaad, maar als het zo doorgaat zie ik het over 5-10 jaar echt wel voorbij komen. Zelfs bij grote software bedrijven heb je genoeg prutsers die maar iets in elkaar flansen omdat ze eigenlijk niet weten wat ze exact doen / moeten maken, prima vervangbaar door AI!

[bzzzt]

5-10 jaar, net als zelf rijdende auto's?

[SgtElPotato]

Ik denk van wel. Een applicatie programmeren of iets anders is wat makkelijker dan een zelfrijdende auto maken met oneindig veel variabelen.

[bzzzt]

Iedere niet triviale applicatie heeft ook heel snel een effectief oneindig aantal variabele-combinaties dus ik zie het verschil niet zo.

[Tintel]

Maar wat je nu beschrijft is dat met een zaagmachine rechte planken kunnen worden gezaagd en dat klopt. Maar met enkel de kennis van de zaagmachine kom je toch niet helemaal.

Het kernpunt is:
Als een systeem enorme herhaling vertoond kan het relatief simpel opnieuw worden gemaakt (met afwijkingen).

Een website is zo'n 'plank'.

Code generatie bestaat al een tijdje en herhaling van zetten gaat daardoor veel sneller. Maar het blijft herhaling.

5-10 jaar om te gaan naar enkel software-controleurs, is naar mijn idee te hoopvol / te snel.

Deze AI is een hele knappe zoekmachine met mogelijkheid om (nieuwe) combinaties te maken.
Stellen dat het enige wat ontwikkelaars doen is het zoeken van bestaande oplossingen en deze combineren, is gewoon niet juist.
Het net als een AI die verhalen schrijft - iets waar heel veel 'leermateriaal' voor beschikbaar is, maar vervolgens zijn de verhalen complete onzin - ook al lijkt het op het eerste gezicht te kloppen.
En dat kan een mens dan corrigeren.... maar wanneer is het corrigeren en niet opnieuw doen?

Deze AI is een mooi stuk gereedschap - maar elk stuk gereedschap is nooit beter dan z'n gebruiker.

Het mooie is dat we dit al langer verafschuwen: iemand die met beperkte kennis een complex systeem gaat uitbreiden of verbeteren, maakt er vaak een complete bende van.

Voor deeltaken is het geweldig - maar voor hele systemen? Ik denk van niet.

Of de prompt wordt zo complex dat het 'programmeren' dus verschuift naar 'prompt-bedenker'...

[JackJack]

Het maakt wel snel duidelijk wie nou daadwerkelijk weet waar ze het over hebben.
Zet de AI tooling uit en als de productiviteit van iemand daalt weet je genoeg

[Reptile209]

Zet mijn Word uit en je moet een stuk langer wachten op mijn handgeschreven of getypte rapport.
Zet mijn auto uit en ik ben een stuk langer aan het fietsen om bij je te komen.

Dus tooling 1-op-1 koppelen aan iemands productiviteit of kennisniveau is een beetje te kort door de bocht. Sterker nog: iemand die heel vaardig is met zijn/haar tools is beter dan iemand die stug zelf voor allerlei standaardzaken een nieuw wiel gaat uitvinden. Want die tweede is over de hele linie langer bezig en minder productief, ook al heeft hij/zij misschien een beter fundamenteel begrip.

[sovereignthrone]

De productiviteit zal sowieso dalen toch? Maar het verschil zal ongetwijfeld veel duidelijker zijn

[Orangelights23]

Je beschrijft nu een probleem dat al eeuwen speelt: innovatie.

Wetenschappelijk onderzoek en innovatie hebben vaak als doel om nieuwe technologie te ontwikkelen. Maar zodra deze nieuwe technologie beschikbaar is, voldoende stabiel en de toegevoegde waarde heeft aangetoond, wordt deze nieuwe technologie weer ingezet om verder onderzoek te doen.

Exact hetzelfde gebeurt met generatieve AI. Dit is nu volop in ontwikkeling en wordt alleen maar beter. Over 20, 10 of misschien wel 5 jaar vraagt men zich af waarom miljoenen mensen nog zelf code aan het kloppen waren, omdat de technologie het zelf goed genoeg kan doen. Er is dus helemaal geen behoefte meer aan het hebben van mensen die de code zelf snappen, want die technologie is onderdeel van AI.

Net zoals de maatschappij geen behoefte meer heeft aan een lantaarnopsteker, een menselijke deurklopper die als wekker fungeerde of zelfs een hofnar, maakt dat AI steeds meer zal zorgen dat puur code schrijven niet meer iets is wat mensen hoeven te doen.

[EricBruggema]

Oneens, je hebt altijd mensen nodig die begrijpen hoe AI en programmeren werkt. Je kunt er niet vanuit gaan dat AI altijd maar het juiste antwoord geeft.. Dus heb je domweg mensen met specifieke kennis nodig en die zullen blijven.

Anders moet je alleen maar gaan vertrouwen op AI en alles voor waarheid aannemen...

[Orangelights23]

Ik schrijf niet dat er niemand meer benodigd is om het te begrijpen - net zoals straatlantaarns zijn er ook mensen nodig die snappen hoe de verlichting werkt, hoe het geautomatiseerd kan worden, hoe storingen opgelost kunnen worden, enzovoorts. Zo zal het ook gaan in de development. Waar nu tientallen developers nodig zijn om een web app te ontwikkelen, is er over enkele jaren slechts één persoon nodig die foutmeldingen oplost.

Anders moet je alleen maar gaan vertrouwen op mensen en alles voor waarheid aannemen... Ik werk al jarenlang in de cybersecurity en daar is een gezegde dat mensen de zwakste schakel zijn. De meeste cyberincidenten vinden plaats door fouten - bewust of onbewust - van mensen. Technologie vermindert fouten al aanzienlijk, van geautomatiseerde access control lists tot aan code validatie.

[Tintel]

is er over enkele jaren slechts één persoon nodig die foutmeldingen oplost.

Hoe zie je dat voor je? Een systeem wat totaal gegenereerd is door AI (of andere ontwikkelaars) is toch niet zomaar te doorgronden?

Ik werk al jarenlang in de cybersecurity en daar is een gezegde dat mensen de zwakste schakel zijn

Omdat mensen geen machines zijn... en bovenal omdat die systemen zijn ontwikkeld door mensen die juist toegang willen... die 2 zaken bijten elkaar nu eenmaal.

Dit is net zoiets als stellen dat bij huisbeveiliging [tegen fysieke inbraak], de openingen de zwakste schakel zijn.... Maar zonder openingen (zoals deuren en ramen) is het geen huis....

Technologie vermindert fouten al aanzienlijk

Dankzij technologie hebben we cybersecurity nodig....

[Orangelights23]

Ik heb geen antwoorden op je vragen, goede vragen, ik ben geen AI expert. Maar in mijn netwerk hoor ik deze visies wel, een netwerk bestaande uit PhD’s en wetenschappers in deze richting.

Overigens, om op je laatste opmerking te reageren, is cybersecurity meer dan alleen technologie. Rapporten geven een percentage van tussen de 80% tot 95% aan cyberincidenten als direct gevolg van mensenlijk handelen. En uit mijn ervaring, oa CISO bij een enterprise hoop ik dat de mens als factor grotendeels verwijderd kan worden: van subjectieve assessments tot aan natig habdelen en van digibeten tot aan geraffineerde hacks - de mens is en blijft de zwakste schakel.

[Tintel]

de mens is en blijft de zwakste schakel.

Maar de mens is eigenlijk geen schakel - die wil toegang en daardoor heb je 'openingen' nodig. Ik begrijp wat je bedoelt en dat het uitsluiten van toegang kan helpen. Natuurlijk zijn veel incidenten een gevolg van menselijke acties / nalatigheid. Maar het is net als bij fysieke deuren; de echte gebruiker is veel blijer als die deur geen slot heeft en laat hem daarom liever open staan...
Die rapporten zijn er meer om aan te geven dat de fout niet in het slot van de deur zat, maar eerder bij de gebruiker met de sleutel.

[sdziscool]

Zeer mee oneens.
Als junior zie ik veel seniors die ik graag met pensioen zie gaan. 30-40 kan nog wel, maar 45+sers die nog aan de code zitten zijn vaak erg pijnlijk, hebben vaak een aantal notities betreffende wat goede code is gemist sinds 2005 en zijn soms ook zeer zelfingenomen als "senior". Dan mag de hele bak juniors dat allemaal gaan oplossen/opruimen naderhand (onder geklaag van de senior natuurlijk want "dit is niet hoe ik het zou doen").

Na 10 jaar in het veld ben je op zijn best, na 20 jaar is je kennis in principe grotendeels outdated (ook niets aan te doen, je krijgt kinderen, een leven buitenom werk en je houd het gewoon niet meer bij zoals vroeger), zelfs als het oudere softwareontwikkelmethodes betreft zoals embedded.

[Xanion]

Dank je. Ik durf te zeggen dat ik met mijn 51 volledig bij ben op alle hedendaagse technieken en dat ik iedere junior eruit blaas op programmeer gebied. Sterker nog, ik neem ze dagelijks mee op een rondreis waarbij ik ze leer hoe het programmeren daadwerkelijk werkt binnen een bedrijf die meer bouwt dan een website pagina en zorg ervoor dat de junior's inzicht krijgen in hoe grotere projecten gebouwd moeten worden. Als senior zie ik teveel juniors die thuis een PHP website in elkaar kunnen zetten en denken dat ze daarom alles op deze wereld kunnen automatiseren. Die net als jij klagen dat de senior aangeeft dat het anders moet, maar dan gigantisch op hun bek gaan zogauw ze zelfstandig een groter project moeten oppakken dan dat PHP websiteje.
Ervaring = Kennis

[Reactie gewijzigd door Xanion op 30 oktober 2024 10:42]

[jhhest]

Ik begrijp niet helemaal waarom PHP soms een negatieve bijklank krijgt. Een groot deel van het internet draait immers op deze taal, en net als bij elke programmeertaal kan de kwaliteit van de code afhangen van hoe het wordt toegepast.

Het klopt dat PHP in zijn beginjaren beperkingen kende, maar dat geldt ook voor talen zoals JavaScript. Tegenwoordig zijn de mogelijkheden enorm uitgebreid, vooral met een framework als Laravel, waarmee je prachtige en efficiënte applicaties kunt bouwen. Laravel biedt robuuste oplossingen en best practices die breed toepasbaar zijn. Wie twijfels heeft, raad ik aan om het YouTube-kanaal “Laravel Daily” eens te bekijken om te zien wat er tegenwoordig mogelijk is met Laravel en PHP.

In mijn ogen blijft een programmeertaal een instrument, die – mits juist ingezet – de gewenste resultaten kan leveren.

[Xanion]

Niet bedoelt om PHP negatief in het licht te zetten... :-). Gebruikt het zelf ook.
Maar PHP is nou eenmaal veel gebruikt door tieners in het verleden om de eerste programmeer ervaring mee op te doen, want was makkelijk en gratis te verkrijgen. Vandaar het vergelijk.
Ik begeleid overigens zelf ook ieder jaar meerdere HBO-ICT stagiairs en ik verbaas mij erover hoe weinig kennis men tegenwoordig heeft van programmeren in het laatste jaar van de opleiding... En dat komt m.i. dan weer vooral door gebrek aan lekker thuis hobbyen. Alle stagiairs die ik de afgelopen jaren heb begeleid heeft nooit thuis geprogrammeerd voor men aan de opleiding begon, nul dus. Allemaal gingen ze pas de eerste regels code schrijven op de opleiding...

[jhhest]

Je kan zoveel tegenwoordig met een computer. Kan mij voorstellen dat programmeren voor de jeugd nogal abstract is en een afleiding snel is gevonden op de pc.

Ben nu zelf weer begonnen na jaren om mijn hbo af te maken en het valt mij op dat het onderwijs enorm verandert is. Ook op het werk hebben we weleens stagiaires van scholen ontvangen die eigenlijk niet klaar zijn om in de praktijk te beginnen.

Antwoorden van een tweedejaars zoals. "De code die in vscode draait" en vervolgens ook echt denken dat die code alleen in vscode draait.

Er wordt meer gestuurd op ontwikkeling, maar minder op kennis. En dat is soms best lastig. Net alsof mensen een bepaalde basis missen. Best ellendig om te zien, je ziet jongeren hierdoor enorm strugglen. School lijkt wel te denken dat alles wel in stage wordt aangeleerd, maar daar is niet altijd tijd voor. Voorlopig proberen we dat tackelen door ze tijd te geven om een goede online cursus te laten doorlopen.

[sdziscool]

Ah, weer een gevonden! nieuw spul = slecht, oud spul = goed natuurlijk!

Natuurlijk zijn juniors in hun eerste jaren... junior! Maar na een jaar of 5 zijn ze competent genoeg, en na 10 zie ik ze als senior. Alles daarna is vastroesten in "hoe het moet" en "hoe het altijd gedaan is". Natuurlijk niet per definitie slecht, er is een reden waarom dingen zo zijn zoals ze zijn. Maar het zit hem in de flexibiliteit en het durven toegeven dat sommige dingen nu eenmaal verandert zijn. Deze flexibiliteit mist enorm bij velen van de oudere generatie, en zorgt ervoor dat veel bedrijven en projecten vastroesten en oneindig veel technical debt bijbouwen, en ja, dan zijn er meerdere juniors nodig puur om die technical debt op te lossen, dat is geen indicatie van dommere juniors, maar van verouderde werkmethodes en concepten waar seniors maar niet van af willen/durven stappen.

[Xanion]

Ik noem het een hele generatie over één kam scheren omdat jij op jouw werkplek blijkbaar een slechte ervaring ermee hebt. Wat net zo stom is als dat ik zou zeggen dat alle juniors nog niet kunnen programmeren en eerst maar eens 10jaar ervaring moet opdoen voor ze het wel kunnen. Ik kom zat junior's tegen die langs hun schoenen lopen omdat ze zelfstandig een script aan de praat hebben weten te krijgen, gelukkig zijn er ook zat juniors die begrijpen ze wel kennis hebben maar geen ervaring en dit nog moeten opdoen. Dat worden de goede programmeurs later.
Probeer eens wat minder te generaliseren... Een bedrijf profiteert het meeste van gemixte kennis van junior's en senior's

[Tintel]

nieuw spul = slecht, oud spul = goed natuurlijk!

Dat heeft niets met junior/senior te maken. Alsof een junior geen oude techniek kan gebruiken en andersom.....

Blijft bijzonder hoe jij tegen een concept aankijkt wat jouw situatie overstijgt.....

Deze flexibiliteit mist enorm bij velen van de oudere generatie

Alleen al dat soort opmerkingen geeft aan dat je het eigenlijk niet begrijpt - je beseft toch wel dat al dat 'speelgoed' wat ons nu ter beschikking staat, gemaakt is door mensen die jou voorgingen????
Maar nee, die waren niet flexibel en stopten echte goede dingen maken na 10 jaar....

Ik stel voor dat jij met een enorme inzicht, ervaring en flexibilteit, van scratch af begint (dus eerst maar eens een transistor ontwikkelen?) want die rommel van de oudere generaties is toch niet bruikbaar toch?

[bzzzt]

Als senior zie ik teveel juniors die thuis een PHP website in elkaar kunnen zetten en denken dat ze daarom alles op deze wereld kunnen automatiseren.

Als mede senior ben ik blij voor je dat je juniors nog een PHP site in elkaar kunnen zetten
Ik zie al jaren een dalende instroom van mensen die thuis nog een eigen Linux doosje beheren of begrijpen hoe hardware werkt. Een van de nadelen van tegenwoordig alles kant en klaar kunnen krijgen denk ik, de noodzaak maakte vindingrijker.

[berzerker]

Als ik je bericht zo eens lees kom je op mij (betrekkelijk leek voor wat betreft programmeren) zelf nogal zelfingenomen over, dus eigenlijk precies wat je anderen verwijt. Jij weet het als junior immers allemaal beter en wil mensen die het anders doen dan jij zelfs wegsturen? En ook nog impliceren dat wie ouder wordt niets wil bijleren: mij lijkt dat nogal generaliserend en denigrerend.

[sdziscool]

In tegenstelling van de persoon waar ik op reageerde die zei dat alle nieuwe generaties automatisch minder competent zouden zijn. Die was natuurlijk heel relativerend bezig.

Maarja wel typisch hoor, geen tegengeluid kunnen hebben, maar niet inzien dat je eigen geluid evenveel (dezelfde) fouten erin heeft zitten.

[Xanion]

In tegenstelling van de persoon waar ik op reageerde die zei dat alle nieuwe generaties automatisch minder competent zouden zijn. Die was natuurlijk heel relativerend bezig.

Ik hoor graag van je waar ik dat roep...

[Tintel]

Zelfs al heeft iemand die stelling gemaakt en die stelling is volgens jou onjuist dan denk je dat het verstandig is om net zo'n stelling neer te zetten?

want...tegengeluid.....

En je beseft toch hopelijk ook wel dat jij dan dus over enkele jaren - volgens jouw stelling - niet meer zo nuttig bent......? Of ben je behalve bijzonder zelfingenomen ook nog bijzonder kortzichtig?

Ik weet dat dit fenomeen bestaat; zelfoverschatting op basis van relatief weinig ervaring. Maar het schijnt een karaktertrek te zijn van de wat minder competente mensen....

[purplevendetta]

Grappenmaker. Het enige aan je bericht wat klopt is dat er een hele bak juniors nodig is om 1 senior te vervangen.

[xorpd]

Ben eigenlijk wel benieuwd naar die notities sinds 2005 omtrent 'goede code'. Je realiseert je wel dat 90% van alle computeralgoritmes in de jaren 70 is ontworpen?

[Tintel]

Na 10 jaar in het veld ben je op zijn best, na 20 jaar is je kennis in principe grotendeels outdated

Jij durft....
Het hele idee van senoir zijn komt vanuit ervaring maar jij stelt simpelweg dat het 'afbouwt' vanaf 10 jaar....

Misschien heb je anekdotisch te maken gehad met ouderen die het niet zo goed deden maar het is een uiterst arrogante opmerking om te stellen dat alles wat jou voorging, eigenlijk maar nuttig was voor een periode van 10 jaar. Absoluut onwaar natuurlijk.

Ik mag toch hopen dat je beseft dat juist het hele idee van junior/senior betekent: de junior moet het nog leren....
Dus als jij iemand "zelfingenomen" noemt - tja - misschien vanuit jouw perspectief naar die persoon op dit moment. Maar om vervolgens durven te beweren dat dit voor alle seniors geldt.....aiaiai...dat is de definitie van 'zelfingenomen'.....

[david-v]

Exact, AI verhoogt productiviteit en efficiëntie, maar het kan ten koste gaan van de kwaliteit

Ik ben het niet eens met deze stelling. Of het nou met de hulp is van AI, van een boek, stackoverflow of dat je een deel van de code van een collega overneemt en aanpast, het verhoogd mi juist de kwaliteit van de code. Beter goed gejat dan slecht zelf verzonnen.

Ik loop al wat jaartjes mee en ik weet ook niet alles. Ik geniet dan ook enorm van pull requests waar een ontwikkelaar iets doet wat ik niet eerder gezien heb, een slimme oplossing heeft bedacht, of simpelweg nieuwe taal features gebruikt. Hetzelfde bij het gebruik van intellisense, een AI zoals copilot of chatgpt of het overnemen van een stukje code uit stackoverflow. Je leert hier enorm van.

Wat betreft de kwaliteit, ik mag aannemen dat je een degelijke PR review proces hebt ingesteld, dat je een software kwaliteitstool gebruikt zoals SonarQube/SonarCloud en dat je misschien ook wel DAST tooling geïntegreerd hebt in je pipeline. Unittest en integratietesten noem ik al niet eens, want als je dat niet hebt ben je echt verkeerd bezig, met of zonder AI gebruik.

Met andere woorden, de kwalitiet van je code moet elke iteratie iets beter worden en staat los van het gebruik van hulpmiddelen zoals copilot/chatgpt of welke andere AI tooling.

[gevoelig]

Op dit moment zie ik het eerder bijdragen aan de kwaliteit maar op de lange termijn heb je gelijk. Nieuwe ontwikkelaars zullen grote moeite hebben met het begrijpen van specifieke code constructies omdat ze eigenlijk nooit low level bezig hebben gekregen. Aan de andere kant is er altijd een AI om die delen van de code uit te leggen.

[Robbierut4]

Is dat waarom de zoekresultaten zo slecht zijn tegenwoordig?

[The Zep Man]

De zoekresultaten zijn slechter door een combinatie van search engine optimization (SEO) waardoor je een berg sites met veel woorden en weinig inhoud hebt, en Google die het wel fijn vindt als je langer van hun diensten gebruik moet maken om tot het gewenste resultaat te komen.

[Reactie gewijzigd door The Zep Man op 30 oktober 2024 09:08]

[MazeWing]

Het is toch treurig dat je bijna achter elke zoekterm "reddit" moet zetten om nog iets relevants te krijgen.
En kennelijk boeit het Google allemaal geen bal want het lijkt er niet echt op dat ze ook maar iets hebben ondernomen de laaste 5+ jaar om dit te verbeteren. Het lijkt allemaal alleen maar slechter en slechter te worden:
- meer reclame
- meer handelingen nodig om iets uit te voeren
- UI veranderingen die alleen maar een mindere gebruikerservaring opleveren

Het is eigenlijk gewoon verdrietig om te zien hoe erg Google is afgegeleden de laatste 10 jaar...
Sundar Pichai is het slechtste wat Google ooit is overkomen!

[Reactie gewijzigd door MazeWing op 30 oktober 2024 10:42]

[himlims_]

de resultaten waren al slecht, voor die AI hype AI marketing, SEO en kunstmatige content om zo de ranking te beïnvloeden zorgen voor terugloop in kwaliteit van zoekresultaat.

[Stukfruit]

Nee, die zijn zo slecht door dit:
https://www.wheresyoured.at/the-men-who-killed-google/

TL;DR: er wordt niet alleen meer onzin gepushed maar er wordt blijkbaar ook gepoogd om je meer zoekqueries uit te laten voeren zodat er een grotere kans is dat je geld oplevert

[Sicos]

Ik gebruikte Google vroeger altijd om oplossingen te zoeken voor programmeer problemen maar mijn standard to go to is tegenwoordig ChatGPT voor die dingen. Voor andere dingen gebruik ik nog wel Google maar het is sinds LLM een heel stuk minder geworden.

[janderk]

MrWhoIsTheBoss had recent een goede overview waarom Google een stuk slechter is geworden.
YouTube: Why Google Search is Falling Apart.

Korte versie: Ze verdienen heel veel geld met advertenties en nog meer indien de echte resultaten slechter zijn.

Ironie wil dat Google in de jaren 90 populair is geworden omdat ze een cleane interface hadden met goede resultaten. De concurrentie (Yahoo!, Altavista, Excite) stopten hun interface helemaal vol met advertenties omdat dat veel geld opbracht.

De geschiedenis herhaalt zich.

[el_mariachi76]

Ik denk dat er een groot verschil zit tussen de jubelstemming van management en developers en dat Sundar dit zegt om de gigantische kostenpost AI te verantwoorden.
Als developer die zelf copilot and wat ander AI tooling gebruikt, moet ik werkelijk alles 3x checken voordat ik de gegenereerde code accepteer. Het is 50/50 dat er wel of geen nieuwe bug in zit. Vaak zet ik 't ook gewoon uit en gaat het programmeren sneller.

[timonb]

Het is net of je een collega een oodracht geeft om een stuk code te schrijven. Ook daarvan weet je dat je er wat op aan te merken hebt.

Het start allemaal met heel precies uitleggen wat je wilt hebben. Dan is het verschil tussen een menselijke collega en de command prompt van een AI niet anders.

[Tjeerd]

De vraag is wat uiteindelijk efficiënter zal zijn. Zelf de code schrijven en nadenken/uitwerken en daar bijvoorbeeld een uur mee bezig zijn. Of door een gerichte doordachte prompt te maken waar je een paar minuten over nadenkt en telkens binnen twee tellen een stuk code hebt, die je vervolgens nog toetst en controleert of het voldoet aan je eisen. Desnoods nog wat kleine dingen bijschaven.

Uiteindelijk zou het zomaar kunnen zijn dat het wel de richting meer op gaat van als ontwikkelaar goed kunnen uitleggen wat je wil en meer controleren wat voor code je terug krijgt. Het bespaart mij echt heel veel tijd in ieder geval, ook al is het misschien maar voor 80% kloppende code (vaak hoger is mijn ervaring).

De race is in ieder geval ingezet m.b.t. AI als ondersteuning voor ontwikkelaars en de tijd zal het uitwijzen of het genoeg tijd zal besparen en handig blijft. Sowieso komt er nu toch een generatie ontwikkelaars aan die straks niet beter weet om hulp van AI te krijgen. Je zal misschien vooral op niveau van domeinkennis nog met collega's van gedachten wisselen.

[elmuerte]

Auto complete van mijn IDE genereert al snel 25% van de code al 30 jaar, en dat zonder prompt "engineering".

[Tassadar32]

De auto-complete van je IDE is al heel lang een combinatie van property/method lookups en een lokaal language model (net als autocomplete op een telefoon-keyboard). De huidige autocomplete met "AI" is in feite niks meer dan een veel groter language model wat in de cloud draait.

[elmuerte]

Er zit geen local language model in mijn auto complete. Alleen goede rules en betrouwbare statistieken. Het is een deterministisch model.

[sjettepetJR.]

Is een AI model wanneer het eenmaal getraind is niet net zo goed deterministisch? Dat zegt vrij weinig.

[Tassadar32]

Klopt!

[The Zep Man]

Nu genereert AI een kwart van alle nieuwe code, waarna engineers het nakijken en goedkeuren. Dit helpt onze mensen om meer te doen."

Het specifieke citaat betreft:

We're also using AI internally to improve our coding processes, which is boosting productivity and efficiency. Today, more than a quarter of all new code at Google is generated by AI, then reviewed and accepted by engineers. This helps our engineers do more and move faster.

Dit citaat noemt dus enkel de engineers en niet de rest van de mensen die iets doet met code (QA, assurance, etc.).

Dat engineers (programmeurs) dit gebruiken is logisch. Welke programmeur gebruikt niet bijvoorbeeld de boilerplate code van een ander indien beschikbaar? Een goede programmeur controleert dit uiteraard. Kleine stukken code zijn snel te controleren en te testen, en wanneer vaak genoeg herhaald bespaart dit veel tijd.

Het enige verschil is dat de code "van een ander" nu gegenereerd wordt door complex data processing, gebaseerd op bestaande geanalyseerde code van anderen. Hiermee wordt een deel van het saaie uitzoekwerk van een programmeur bespaard. Een programmeur heeft liever ten eerste een praktisch voorbeeld van hoe iets gebruikt kan worden en daarnaast pas de achterliggende referentie over hoe het geheel in elkaar steekt. In de praktijk is het vaak voldoende om te weten hoe een ander iets gebruikt om het zelf te gebruiken. Wat een goede programmeur onderscheidt van een gewone is herkenning van situaties waarin deze vlieger niet opgaat. Zulke vaardigheden zijn nog steeds nodig, AI of geen AI.

[Reactie gewijzigd door The Zep Man op 30 oktober 2024 09:01]

[Caelorum]

Engineers zijn niet alleen maar programmeurs. Google heeft ook functies zoals SWE & Test Engineer, Software Release Engineer, Developer Relations Engineer, CAD Engineer, etc. Zie ook https://www.google.com/ab...ny=Google&skills=software
Ik denk dat je ernstig onderschat hoeveel je AI al kan inzetten om zaken te automatiseren waarbij er alleen nog oversight/controle nodig is.

[Reactie gewijzigd door Caelorum op 30 oktober 2024 09:20]

[The Zep Man]

Ik doel met "programmeurs" op "iedereen die iets doet met programmeren", niet "iedereen die programmeert als primaire functie in diens werk".

Ik denk dat je ernstig onderschat hoeveel je AI al kan inzetten om zaken te automatiseren waarbij er alleen nog oversight/controle nodig is.

Ik denk dat men ernstig overschat hoe goed mensen zijn in "oversight/controle".

[Caelorum]

Ik geef ook voorbeelden van beroepen die niets met programmeren doen, zoals die CAD engineer, die tegenwoordig (een deel van) het model gewoon voorgeschoteld kan krijgen.

Ik overschat verder niets? Geen idee hoe je tot die conclusie komt. Ik geef nergens ook maar een hint van hoe ik de kwaliteit van de AI assistentie inschat...

[The Zep Man]

Ik overschat verder niets?

Ik noemde "men", niet jou specifiek.

[Reactie gewijzigd door The Zep Man op 30 oktober 2024 11:31]

[YopY]

nvm

[Reactie gewijzigd door YopY op 30 oktober 2024 09:33]

[switchboy]

Ik was nou niet echt onder de indruk van wat chatGPT genereerd. Misschien dat ze bedoelen dat ze a la copilot autocompleet boilerplate laten genereren. Dat kan soms best ceel van de code zijn. Afhankelijk van hoewel abstractie er is. En dat spinnen als AI genereert zoveel percent van de code.

[Reactie gewijzigd door switchboy op 30 oktober 2024 08:57]

[YopY]

ChatGPT is een generieke chatbot die "alles van het internet" plukt; Copilot (van Microsoft / Github) is geoptimaliseerd op het genereren van code; Google's Gemini, of de interne versie die ze gebruiken, is getrained op de interne codebase van Google (2 miljard regels code), en zal dus geoptimaliseerd zijn op code door & voor Google.

[JJ Le Funk]

ik hoorde laatst: "Het is als taart snijden met een kettingszaak. De klus wordt geklaard maar iemand moet de troep opruimen."
Echter zal dat ook de tijdsgeest zijn, AI staat nog in de kinderschoenen (hoewel ik ook gelezen hebt dat de piek bereikt is ondanks de hype).

[YopY]

Maar om die analogie door te trekken, software op Google schaal is als een taart van een paar kilometer in doorsnee; Google heeft tot 100.000 engineers. Je kunt ze allemaal een taartmes geven en loslaten, maar grover geschut zal de taart niet stuk maken.

Dat gezegd hebbende, het overgrote merendeel van code, ook bij Google, is kei saai - dat is trouwens goed. Ze hebben de Go programmeertaal ontwikkeld wat nog saaier is dan de C++ die ze gebruiken. Saaie code kun je prima door tools laten genereren.

Uiteindelijk is het een afweging in wat is sneller; code genereren, testen, en waar nodig corrigeren, of zelf code schrijven, testen, en waar nodig corrigeren.

MBT de piek is bereikt, wat ik ervan weet (en dat is niet veel) is dat de technologie "klaar" is, tenminste tot de volgende grote innovatie / uitvinding, en waar de bedrijven nu mee bezig zijn is het opschalen - meer input, grotere modellen, sneller ophalen van resultaten - en het "productisen". Microsoft is bijvoorbeeld bezig met het integreren van AI tools in VS Code en Github zodat je bijvoorbeeld je Azure deployment logica / je datacenter architectuur kunt laten genereren.

[josttie]

Okee hij zegt dus niks over of het betere kwaliteit code oplevert, en ik ben benieuwd hoeveel tijd het bespaart als je het na moet kijken (en vooral als je het moet debuggen). Ik had een tijdje copilot aan staan, dat is stilletjes uitgezet en ik gebruikte het zo weinig dat ik het niet eens heb gemerkt. De code was nogal hit and miss, het produceerde redelijk wat op code leek maar nooit van zijn leven zou compileren. Ook paste het totaal niet bij de code stijl van ons project. Anderzijds, voor documentatie is het wel weer erg handig (nadat je alles dus al hebt voorgekauwd in code). Als hij met die 25% code ook documentatie bedoelt, dan bespaart het wel tijd, maar uiteindelijk heb je er dus niks aan om problemen op te lossen. Ik gok dat die 25% generatie op z'n best 5% tijd bespaart (puur vanwege boilerplate en documentatie generatie) maar wellicht 50% meer hoofdpijn veroorzaakt in het oplossen van problemen in de echte logica.

[YopY]

Wat er uiteindelijk gedeployed in productie wordt zal hoe dan ook voldoen aan Google's standaarden (alhoewel ik niet weet hoe hoog die zijn), niks wordt in productie gezet zonder dat het langs meerdere personen en tools gegaan is.

[josttie]

Dat zal zeker wel. Maar dan alsnog, ik zeg niet dat het hele proces slechte code oplevert, maar ik vraag me af hoe goed de code is die the AI aflevert en hoeveel extra werk het is om het allemaal netjes te maken.
En of het dat allemaal waard is. Wellicht krijg je developers die niet snappen wat ze doen, maar wel een AI kunnen aansturen. Kunnen die nieuwe problemen ook oplossen of alleen bestaande?

En bedenk je eens: Stel je genereert code met AI, en dan ook de tests met AI Die tests zullen groen zijn en de coverage 100%.

[Omegium]

Een paar regels Java of Python levert ook honderden regels machinetaal op, dus je kunt stellen dat de compiler altijd al 99% van alle code schreef. In die zin zijn LLM's gewoon een nog hogere programmeertaal.

Maar wat ik tot nu toe gebruikt heb ben ik niet zo onder de indruk, het lijkt prima, maar het is vergelijkbaar met code van Stack Overflow kopieeren. Niet dat daar iets mis mee is, ik heb ook duizenden regels van Stack Overflow gehaald, maar je moet wel blijven opletten

[Xanion]

Ik kan Claude aanraden. De nieuwe engine 3.5sonnet is vele malen beter dan de oude of ChatGPT en levert daadwerkelijk goed resultaat. Ik gebruik het voor templating en makkelijkere stukken
repetitive coding te automatiseren en daar is het ook goed in. Daardoor kan ik juist aandacht geven aan de lastigere stukken code die AI niet begrijpt, maar ik wel... :-)