Vibe coding en vakmanschap

ProgHead

Gepokt en gemazeld
Lid sinds
26 februari 2019
Berichten
8.342
Locatie
Zeist
Ik ben zelf geen programmeur, maar heb mij de afgelopen tijd wel in C en C++ verdiept. Dat heeft zijn nut gehad in die zin dat ik er nu een aardig beeld van heb hoe programma's in C of C++ eruit zien. Maar zelf programma's in C of C++ schrijven lukt me nog niet of nauwelijks. Voor dat laatste zou ik nog een of twee jaar verder moeten oefenen. Tenzij ik ook zelf aan vibe coding ga doen. Maar met vibe coding heb ik er geen lol meer in. Ik wil dingen zelf begrijpen en bouwen, want dat is wat mij een kick geeft. AI het werk laten doen schenkt mij geen bevrediging.

Op YouTube zie ik inmiddels video's van professionele programmeurs die door AI hun baan hebben verlopen, of wiens functie gedegradeerd is tot het uitwerken en testen van door AI gegenereerde programma's. Hun vakmanschap doet er met de opkomst van AI steeds minder toe. En bijgevolg hebben ook zij steeds minder eer van hun werk.

Wat betekent dit alles voor professioneel en hobbymatig audio programming?
 
Ik ken nu een aantal professionals die nogal sceptisch over AI coding waren en nu helemaal om zijn.
Iedereen heeft een bepaald niveau in de IT en met AI mag je dat x 1000 doen.
Dus een noob x1000 of een expert x1000.

Ook leer ik juist veel van llm's. Zo weet ik nu hoe je een binary van een baremetal mcu kan decompilen. Hoe je kan vinden welke compiler en libs ze hebben gebruikt etc...

Er komt ook bij dat je wel zelf dingen zelf moet sturen. En hoe meer je al weet hoe beter dat gaat.

Vind wel dat als je code dan voelt het niet alsof je het zelf hebt gemaakt. Een llm poept er zo een lang script uit waar ik normaal een week mee bezig ben.

Dus alles goed bestuderen wat de llm doet en kritische vragen stellen.

Zo laat ik de llm altijd voor alle code een test maken en de boel linten.
 
Domein kennis wordt steeds belangrijker, weten wat je moet bouwen en waarom. Gecombineerd met goede engineering skills en een AI gestructureerd maakproces en je bent veel sneller en zaken als testen en documentatie zijn er ook in geregeld. Nu lijkt het even of programmeren niet meer nodig is als vak gebied maar ik denk dat het tegenovergestelde waar is. Je moet mensen hebben die dingen kunnen bouwen om zaken echt goed sneller te kunnen doen met behulp van nieuwe tools, zoals llm’s.
 
@Cornerman Zou het met AI voor de programmeurs nog wel leuk zijn als hun eigen inbreng in het hele proces relatief gezien steeds kleiner wordt? In hoeverre is het afgeleverde programma dan nog hun eigen werk waar ze met recht trots op kunnen zijn? Dat is waar ik mee zit.
 
@Cornerman Zou het met AI voor de programmeurs nog wel leuk zijn als hun eigen inbreng in het hele proces relatief gezien steeds kleiner wordt? In hoeverre is het afgeleverde programma dan nog hun eigen werk waar ze met recht trots op kunnen zijn? Dat is waar ik mee zit.
Wat ik zelf ervaar is dat ik heel hard moet nadenken over de architectuur. Wat moet er gemaakt worden? En hoe ?
Dat is ook wat een vriend van me een doorgewinterde programmeur en business architect. De focus ligt op het nadenken.

Over C / C++ leren.
Dat kan juist zo goed met een llm. Tot in het kleinste detail.
Ik ben nu in de details aan het leren en onderzoeken om een C/C++ binary van een sequencer te decompilen en het werkelijk te gek.
Heb echt wel zelf veel input moeten geven maar wat ik terug krijg is gewoon high level hacking.

Ding Open gemaakt, chip part gedeeld, met strings hints gezocht, vond the stm32 hal libs. Dezelfde versie achterhaald compiled met dezelde compiler en daarna de signatures van veel functies. Het wat raar hij is met softfloat compiled terwijl de mcu een hardware float instructie heeft. Ja maar de midiloop die tijd kritische is werkt met unsigned integers zodat het zijn loop in 1 cpu cycle kan uitvoeren. Daarom is de boel dus expliciet met softfloat compiled.
Anyhow lang verhaal. Uiteindelijk heb ik die arn binary de en recompiled.
Maar het avontuur gaat door.

mijn punt is dat AI je juist in staat stelt veel te leren het hangt helemaal van je eigen aanpak af.
 
Laatst gewijzigd:
Dus alles goed bestuderen wat de llm doet en kritische vragen stellen.

Zo laat ik de llm altijd voor alle code een test maken en de boel linten.
Zo doe ik het ook. Alles in GIT, CI/CD ingericht met test suites en linters. Werkt voor mij echt goed. Je kunt nu kwalitatief goede oplossingen generen zonder dat je alle ins en outs hoeft te weten. Ik ben zelf wel een hardcore IT-er, dus ik heb wel veel technische bagage. Dat helpt mij om voorstellen van Claude te reviewen, en kritisch te blijven.
 
Domein kennis wordt steeds belangrijker, weten wat je moet bouwen en waarom. Gecombineerd met goede engineering skills en een AI gestructureerd maakproces en je bent veel sneller en zaken als testen en documentatie zijn er ook in geregeld. Nu lijkt het even of programmeren niet meer nodig is als vak gebied maar ik denk dat het tegenovergestelde waar is. Je moet mensen hebben die dingen kunnen bouwen om zaken echt goed sneller te kunnen doen met behulp van nieuwe tools, zoals llm’s.
Klopt. Het werk verschuift van code kloppen naar het uitdenken van frameworks, domeinen en processen, architectuur, security etc. vertel je AI-tool hoe jij deze spelregels ziet (oa skills, linters, CI/CD Checks etc), en rol dat uit in je bedrijf of bij je klant. Het gaat dan vóór je werken, en wordt zo onderdeel van de afgesproken werkwijze. Super krachtig.
 
Zo doe ik het ook. Alles in GIT, CI/CD ingericht met test suites en linters. Werkt voor mij echt goed. Je kunt nu kwalitatief goede oplossingen generen zonder dat je alle ins en outs hoeft te weten. Ik ben zelf wel een hardcore IT-er, dus ik heb wel veel technische bagage. Dat helpt mij om voorstellen van Claude te reviewen, en kritisch te blijven.
Ja en git idd. Bij vergeten en heel belangrijk.
Das dan ook weer handig dat de llm in de commit log kan checken en is dus een goed langetermijn geheugen.
Nu ik er over nandenk zou je ook nog specifieke commits handmatig kunnen doen om die reden.

Hardcore IT'er ? zoiets ?

1794132304234.png
 
In vroegere jaren nog hexadecimaal geprogrammeerd. Uiteindelijk is eea doorgeëvolueerd dat de afstand tot de feitelijke hardware waar het op draait steeds groter is geworden. Denk aan functiebibliotheken e.d. waardoor het programmeren alleen maar makkelijker is geworden. Tuurlijk moet je wel in staat zijn deze te organiseren in een programma zodat het doet wat je wil. Nu is met AI ook deze hobbel weggenomen. Is dit dan niet gewoon een logische volgende stap?
 
Code is een intermediair tussen het gesproken woord en de uiteindelijke machine specifieke assembly.
C/C++/Rust/asm etc staan heel dicht bij de hardware. Daar kun je precieze cpu instructies programmeren.
Maar meer highlevel talen zoals bv python, lua zijn daar minder geschikt voor. Ik zeg minder want je kunt als je echt wil in iedere taal wel een compiler schrijven.

Dus ja ik zie AI dan ook als een programmeer taal. In de "highest level".
 
Ja en git idd. Bij vergeten en heel belangrijk.
Das dan ook weer handig dat de llm in de commit log kan checken en is dus een goed langetermijn geheugen.
Nu ik er over nandenk zou je ook nog specifieke commits handmatig kunnen doen om die reden.

Hardcore IT'er ? zoiets ?

Bekijk bijlage 3878034
Haha nee, ik hou mij niet bezig met duistere zaken :D Ben ook geen ethisch hacker, maar ik heb wel contact met mensen die zich daar mee bezig houden.

Mbt GIT: ik heb mijn Claude omgeving zo opgezet dat de Claus.md, skills, andere .Md’s met kennis, afspraken, architectuur etc etc allemaal in GIT vast worden vastgelegd. Zo kan ik ook snel switchen van AI-tool, bv van Claude naar Codex of wat dan ook. Skills e.d. worden automatisch gesynchroniseerd met GIT als master. Werkt goed.
 
In vroegere jaren nog hexadecimaal geprogrammeerd. Uiteindelijk is eea doorgeëvolueerd dat de afstand tot de feitelijke hardware waar het op draait steeds groter is geworden. Denk aan functiebibliotheken e.d. waardoor het programmeren alleen maar makkelijker is geworden. Tuurlijk moet je wel in staat zijn deze te organiseren in een programma zodat het doet wat je wil. Nu is met AI ook deze hobbel weggenomen. Is dit dan niet gewoon een logische volgende stap?
Klopt. Je kunt AI-technologie zien als de volgende abstractielaag, en waarmee je zelf je abstractielagen kunt bouwen. Vergelijk het met de GUI van een operatiegebied systeem. Gewone gebruikers hebben geen idee wat er onder de motorkap gebeurd. Maar een GUI maakt het een stuk gebruikersvriendelijker.
 
Laatst gewijzigd:
Ik heb er nog niet heel veel mee gedaan, maar voor zaken als HTML en JavaScript applets vind ik het een uitkomst. Ik heb iets meer dan basale kennis en ook wat ervaring, maar veel daarvan is roestig en achterhaald (ik programmeer inmiddels al bijna 25 jaar niet meer echt/vaak). Maar goed genoeg om een AI te vertellen wat ik wil en dan zelf in de code de puntjes op de i te zetten op detailniveau of uit te leggen wat anders moet. Ik ben ook zeker geintresseerd in die firmware hacks, heb ook een apart Windows laptopje gekocht om daar wat meer mee te gaan doen.

Voor het vak/ambacht heeft het zeker invloed, al zie ik bij ons dat de meeste programmeurs vooral de voordelen zien omdat hun werk veel meer gaat zitten in ideeën voor oplossingen en veel minder in code kloppen/debuggen. Zoals @flyweight opmerkt kun je gewoon veel meer doen in veel minder tijd en ook dingen die je voorheen gewoon niet zelf voor elkaar zou krijgen. Ik vind dat wel mooi.
 
Laatst gewijzigd:
Ik ben ook helemaal om juist omdat ik zelf de architectuur en de oplossing verzin (lastige algoritmes en de manier waarop de code ingericht moet worden). De AI doet vooral het "typ-werk" waar ik zelf lang over zou doen en waar AI razend-snel is. En als je er vervolgens een goede CI structuur omheen zet met test-driven-development krijg je echt goede resultaten. Ik maak nu in mijn eentje software waar je normaal een heel team voor nodig zou hebben.

Met vibe-coding laat je weten wat je hebben wilt maar niet hoe het gebouwd moet worden. Je geeft de regie aan de AI agents en in dat geval krijg je vaak suboptimale oplossingen. Dus op dit moment heb je echt nog ervaren programmeurs nodig om met AI goede oplossingen te ontwikkelen. AI wordt pas een bedreiging voor ons vak als vibe-coding daadwerkelijk optimale implementaties op gaat leveren. Dan hebben we het punt bereikt waarop "iedereen kan programmeren". Dat zou voor de wereld mooi zijn maar ik denk dat er voor kritische systemen (medische, infrastructuur en andere kritische zaken waarbij leven of dood een rol spelen) altijd wel een menselijke expert betrokken zal blijven...Wie weet. Ik hoop wel dat de mensheid zo slim is om zich niet totaal over te geven aan de kennis van AI maar dat we de kennis en vaardigheden blijven leren om ook zonder AI te kunnen functioneren.

@ProgHead je kunt ook AI inzetten als 'onderwijskracht'. Programmeer zelf een oplossing, vraag AI hetzelfde te doen en laat AI ze vergelijken en jou vertellen welke beter is en waarom.
 
Wat ik wel gemerkt heb is dat je veel betere resultaten haalt door je AI-tool te trainen op jouw best practices (architectuur, UI/UX, security, etc). Dat voorkomt veel rework, en levert veel betere software op. AI-tools hebben namelijk moeite met uitzoomen, en hebben de neiging jou een een vanille oplossing voor te schotelen. Voor een privé projectje of demo is dat OK. Voor serieuze oplossingen kom je daar niet mee weg. AI-tools kunnen dit dit wel, maar je moet ze dat zelf leren. Dan ga je ook zien wat AI echt kan toevoegen. Allerlei controles worden dan automatisch afgedwongen, en je hoeft die niet keer op keer uit te leggen. Daarmee los je het AI-Alzheimer probleem grotendeels op.

Qua vakmansschap ga ik erop vooruit. Ik heb vroeger veel geprogrammeerd, maar ik heb dat nooit zo boeiend gevonden. Het gaat mij om het creatieve proces, hoe ga je iets schalen, en het resultaat. AI helpt mij met het verder uitwerken van mijn eigen ideeen. Zo hoef ik mij veel minder bezig te houden met allerlei, voor mij, minder interessante IT dingen. Ik beperk Claude wel. Voor privé apps bouwt hij met Javascript, en Python. Voor mij is een programmeertaal een abstractielaag geworden waar ik zo min mogelijk van wil weten. Laat anderen dat maar doen. Dan hou ik mij wel bezig met leuke ideeen en oplossingen.

Voorbeeldje: ik heb voor mijn 80s coverband een player app gebouwd. Per nummer kies je uit het origineel of de individuele stems, met of zonder cues en clicks. De labels voor de secties (Intro, Chorus etc) worden gegenereerd op basis van de Ableton Live .als file. Zonder Claude was mij dat gewoon niet gelukt.

1794143708198.png
 
@Sjaak Kun je je AI-tool dan persoonlijk maken door die tool te trainen om voor jouw interessante resultaten te leveren?
 
@Cornerman Zou het met AI voor de programmeurs nog wel leuk zijn als hun eigen inbreng in het hele proces relatief gezien steeds kleiner wordt? In hoeverre is het afgeleverde programma dan nog hun eigen werk waar ze met recht trots op kunnen zijn? Dat is waar ik mee zit.
Leuker denk ik, het uitdenken van de oplossing of het product is altijd wat ik leuker vind dan code kloppen, testen bouwen en documenteren van alles. Het is wel zo dat je nu minder hebt aan mensen die puur code schrijven. Steeds belangrijker wordt kennis en ervaring in de industrie waarin je werkt. En goede kennis van hoe je software bouwt en hoe je architectuur in elkaar zet. Het helpt dus wel als je wel programmeer ervaring hebt. Voor beginners is het anders leren. Leren werken net CI/CD pipelines, AI tooling en ontwerp principes. Kleine projecten zelf coderen en leren hoe dat met AI ook kan. En leren de juiste keuzes te maken. Als je nu een ervaren programmeur bent die goed oplossingen kan ontwerpen wordt het alleen maar leuker eigenlijk. Je kan alles sneller bouwen en kan betere oplossingen bouwen omdat je aandacht kan verleggen naar ontwerpen
 
Back
Top