GitHub brengt AI-programmer uit die helpt bij het schrijven van code

GitHub heeft een technische preview uitgebracht van Copilot, een AI-gedreven pair programmer die ontwikkelaars helpt bij het schrijven van code. Copilot stelt contextgebonden code en functies voor, en helpt bij het oplossen van problemen door te leren van de code die iemand schrijft.

Github Copilot werd ontwikkeld samen met OpenAI en is gebaseerd op de OpenAI Codex. Deze AI-toepassing heeft kennis van hoe mensen code programmeren en is volgens Github beter dan bijvoorbeeld GPT-3 in het genereren van code, omdat het specifiek is getraind op een grote dataset van publieke broncode.

Tijdens het schrijven van code krijgt de ontwikke'laar suggesties voor hele regels code of zelfs complete functies die Copilot voorstelt op basis van de context tijdens het typen, dus op basis van de code waar een ontwikkelaar aan werkt. Copilot kan automatisch opmerkingen omzetten in code, repetitieve code aanvullen en een functie testen tijdens het schrijven. Gebruikers kunnen door de suggesties die Copilot voorstelt heen bladeren en deze kiezen te accepteren of te negeren. Voorgestelde code kan daarnaast handmatig aangepast worden.

Github benadrukt dat Copilot meer is dan een autocomplete, omdat het veel meer begrijpt en leert van de context. Het kan het verschil zien tussen bijvoorbeeld een docstring, een opmerking, een functienaam of code zelf. Daarnaast wordt Copilot slimmer als het meer gebruikt wordt, omdat het leert hoe een ontwikkelaar codeert.

Github zegt dat Copilot werkt met tientallen frameworks en programmeertalen, maar dat in deze technische preview de nadruk gelegd is op Python, JavaScript, TypeScript, Ruby en Go. Copilot is vooralsnog een extensie voor Visual Studio Code en gebruikers moeten zich inschrijven voor een wachtlijst om Copilot uit te proberen.

Github Copilot

Door Stephan Vegelien

Redacteur

30-06-2021 • 07:44

74

Submitter: systech2

Reacties (74)

74
72
38
11
1
28
Wijzig sortering
Als de GitHub Copilot getraind is op GPL code, die wordt weggegeven onder een expliciete copyleft licentie, is het dan toegestaan om deze tool closed-source te houden?

Of mag ik Microsoft vragen om een deel van de winst nu MIJN code wordt gebruikt om HUN AI tool te trainen?

En als ze straks geld vragen voor Copilot, mag ik dan gratis toegang omdat ik heb bijgedragen aan deze tool?

Zomaar wat vragen die in me opkomen.
Trainen is niet gelijk aan kopiëren en gebruiken. De algemene gebruikspatronen zijn er uit gehaald ("geleerd") en worden aangepast aan de context van de nieuwe situatie. Er wordt dus nieuwe code geschreven op basis van eerdere ervaringen. Daar kan geen licentie iets over afdwingen.

Want hoeveel verschilt dit nou van wat een mens doet? Ook hij leest code, distilleert hieruit de essentie en past deze kennis weer toe op nieuwe situaties. Of een apparaat dit nou doet, of een mens, het leerproces en de uitkomst zijn hetzelfde.
Copyright gaat niet over copy/paste, het gaat ook over afgeleide werken. Je traint GitHub op open source code en alles dat het weet komt uit open source code. Er is echt geen definitie van "afgeleide werken" waar dit niet onder valt.

Het verschil is dat mensen leren. Abstract begrip opdoen, en kennis en andere bronnen waar ze uit leren en meer worden dan de som van de delen. GitHub Copilot is gewoon een statistisch model dat een beetje slim code knipt en plakt.
Gezien de populariteit van Stack Overflow en vergelijkbare sites knippen, plakken en modificeren mensen er ook lustig op los. Is dat dan wel toegestaan omdat een mens dit doet in plaats van een machine?

En als ik een boek over design patterns pak, en de patronen hierin toepas in mijn eigen code. Moet ik dan ook opeens bij elke toepassing geld gaan overmaken aan de schrijvers van het boek? Moet ik mijn HBO elk jaar geld toeschuiven omdat ik daar geleerd heb te programmeren en nog steeds dagelijks de daar opgedane kennis toepas?

Op deze manier is alles een 'afgeleid werk' te noemen.
Het gaat hier specifiek over code die onder de GPL valt. En ja, als je dat knipt en plakt dan is dat een liability voor jou/je klant, of je dat nu leuk vindt/er mee eens bent of niet. Als er een permissive license opzit dan is het geen probleem. Er is een reden dat veel bedrijven wél OSS willen gebruiken, maar niet als dat onder een restrictive license als de GPL valt.

Als ik de FAQ lees op https://copilot.github.com/ dan staat daar expliciet in dat in 0.1% van de gevallen trainingsmateriaal 1:1 wordt overgenomen. Dat lijkt klein, maar met de populariteit van GitHub gaat het hier dus om heel veel gevallen waarin er materiaal dat valt onder de GPL wordt geplakt in code van anderen, zonder dat je dat weet. En dat kan rechtszaken opleveren. Ze hadden beter alleen code met een permissive license kunnen gebruiken. Dit is best wel vragen om problemen.
Volgens mij is de GPL of welke andere licentie de code die je op GitHub heb gezet niet van toepassing. Van toepassing zijn de voorwaarden van GitHub, en daar heb je mee ingestemd toen je je code daar opzette.

Zoals ik elders in deze draad al zei.
Code parsen of er een 1:1 kopie van maken zijn twee hele verschillende dingen in mijn ogen. Het gaat hier vooral om de 0.1% (zie de FAQ van Copilot die ik hierboven postte) waarin ze een exacte kopie (verbatim copy) maken. Dat lijkt een klein getal, maar dat betekent dus dat elke duizend suggesties een mogelijke GPL schending oplevert. Gezien de populariteit van GitHub gaat het dan om heel veel gevallen. Los van of iedere kopie nu werkelijk een schending oplevert of niet, of dat je in de rechtszaal gelijk krijgt of niet: veel bedrijven gaan dat risico niet willen lopen.

Enige dat ik mij afvraag is waarom ze zich niet hebben beperkt tot OSS code met een permissive license. Dat wordt nergens uitgelegd (voor zover ik kan vinden dan). Hebben ze vast redenen voor (of niet).
In de uitgebreide blogpost in diezelfde FAQ wordt verder uitgeweid hierover. De 0.1% lijkt voornamelijk veroorzaakt te worden door code constructies die zo algemeen zijn/zo vaak gebruikt worden dat ze niet meer onder enige vorm van copyright/licenties kunnen vallen. Zo pervers is het copyright systeem nog niet dat je moet gaan betalen voor code constructies zoals var = var + 1.

Als conclusie schrijft de auteur van het artikel dat in deze gevallen Copilot de gebruiker moet verwittigen dat het (een bijna) 1:1 kopie heeft toegepast.

Er wordt dus wel over nagedacht bij de ontwikkelaars, maar het zal uiteindelijk aan de juristen zijn om te zeggen of dit een praktisch inzetbare tool is of niet.
Leren is natuurlijk maar een term die uit het echte leven is getrokken om een indicatie te geven van wat Machine Learning software doet. Evenals:
- Compileren
- Assembleren
- Mijnen
- Inpakken

In dit geval wordt wel degelijk de code gebruikt om iets nieuws te creëren.

Maar wie de "Github's use of your data" pagina gelezen had wist dat hij ermee akkoord gaat dat de code (incl private repo's) door een machine gescand mag worden:
https://docs.github.com/e...-githubs-use-of-your-data
Dat maakt deze kwestie lastig. Aangezien machine learning en "AI" gewoon lineaire algebra is en niet daadwerkelijke "intelligentie".

De voorwaarden die een partij stelt mag niet tegen de wet ingaan. In dat geval zijn de voorwaarden ongeldig.

Dus wanneer er content op GitHub wordt gezet waar auteursrechten op zitten of een bepaalde exploitatie licentie, mogen hun (Microsoft) voorwaarden wel zeggen dat ze het zonder pardon mogen gebruiken, maar dat is natuurlijk niet zo.
Enige dat ik mij afvraag is waarom ze zich niet hebben beperkt tot OSS code met een permissive license. Dat wordt nergens uitgelegd (voor zover ik kan vinden dan). Hebben ze vast redenen voor (of niet).
waarschijnlijk omdat dat speelveld een stuk kleiner is, en dus minder geschikt om de AI op te trainen.
Goed, in die 0,1% kan er inderdaad een probleem zijn. En daar zijn ze zich ook van bewust. Diezelfde FAQ zegt namelijk:
Many of these cases happen when you don’t provide sufficient context (in particular, when editing an empty file), or when there is a common, perhaps even universal, solution to the problem. We are building an origin tracker to help detect the rare instances of code that is repeated from the training set, to help you make good real-time decisions about GitHub Copilot’s suggestions.
En dat kan rechtszaken opleveren.
Waarvan nog maar de vraag is of dat iets oplevert. Vanuit EU perspectief is het strong copyleft virale effect in algeheel niet rechtsgeldig. Tot nu toe heb ik geen jurisprudentie kunnen vinden waarin daadwerkelijk de rechtsgeldigheid van dat virale effect ergens in de wereld is bekrachtigd.
At the contrary and in most cases, it seems that in European law the fact of linking two programs and the technology used for it does not by itself produce a derivative work: viral licensing is just a ghost. It does not exist.
https://joinup.ec.europa....why-viral-licensing-ghost
Het gaat uiteindelijk om risico. Bedrijven die nu al de GPL vermijden hebben geen zin om er in een rechtszaal achter te komen of ze wel of niet aansprakelijk zijn.
Een bedrijf gevestigd in de EU hoef daar dus niet voor te vrezen.
Volgens mij moet je alleen bij het aanbieden van een binary de source code geven.
Zolang de AI niet als binary wordt aangeboden is er ook geen reden om de source aan te bieden.
Het verschil is dat er linksom of rechtsom redelijk expliciet wordt gemaakt dat je die kennis de wereld ingooit, al dan niet met een licentie erop van "doe maar wat je niet laten kunt" tot "alleen zus en zo". Ook de auteurs van het boek, de makers van je opleiding en de schrijvers van de stackoverflow posts hebben de intentie om de lezer iets te leren en vinden het dan impliciet of expliciet prima dat code wordt hergebruikt.

Bij een tool gaat dat wat verder - is het mogelijk om projectmatig toestemming te geven? Misschien gebruik ik VS Code in mijn vrije tijd wel voor open-source hobbyprojecten, maar van 9 tot 5 voor mijn bedrijfje waar ik propriëtaire code klop. Dat zie ik het liefst níét openbaar worden.

Als we dan naar Microsoft kijken, moet je inderdaad de IntelliCode per solution/project aanzetten en heb je dus meer fijnmazige controle over wat je wel of niet aan Microsoft wil delen. Gezien GitHub nu dus een soortgelijk iets de wereld in wil slingeren, lijkt het me aannemelijk dat ze ongeveer hetzelfde gaan doen.
Gezien de populariteit van Stack Overflow en vergelijkbare sites knippen, plakken en modificeren mensen er ook lustig op los. Is dat dan wel toegestaan omdat een mens dit doet in plaats van een machine?
Stack Overflow heeft ergens in de terms of use staan onder welke voorwaarden je voorbeelden over mag nemen (ik weet de exacte regels niet uit mijn hoofd, maar vermoedelijk komt het dicht in de buurt van "doe lekker waar je zin in hebt"). Dat betekent dat je als gebruiker er vrolijk op los kan copy-pasten en dat dat inderdaad allemaal mag. Maar er zit een andere kant aan: de mensen die op SO vragen beantwoorden en code posten die zouden zich er heel goed bewust van moeten zijn dat ze, door een antwoord te posten, die toestemming geven. Het zou mij niet verbazen als heel veel mensen daar totaal niet bij stilstaan en er een heleboel beschermde code op SO staat die daar eigenlijk helemaal niet had mogen staan.

Die mensen individueel aanklagen (door individuele gedupeerden) schiet echt totaal niet op. Maar als er één grote partij is (die diepe zakken heeft!)... dan wordt het opeens een heel ander verhaal.
Op deze manier is alles een 'afgeleid werk' te noemen.
Er is een groot verschil tussen een lesboek dat zegt "je moet wachtwoorden salten en hashen voordat je ze opslaat" en het overnemen (en enigszins aanpassen) van daadwerkelijke code die die acties uitvoert. Bij mijn beste weten valt alleen het tweede onder "afgeleid werk".
Nee het is geen afgeleide, dat zou hetzelfde zijn als ik jou project doorneem daar wat van leer en vervolgens elk project waar ik die opgedane kennis (niet je code) voor gebruik ineens onder die licentie moet uitbrengen...

Vind het wel een goede vraag overigens, ik was het ook meteen met je eens tot ik er echt even over na ging denken wat de gevolgen zouden zijn als het is zoals je stelt.

De AI is getraind op alle open source projecten maar de suggesties die die doet zijn dat niet (tenminste dat staat nergens), die werken op basis van de code waar een ontwikkelaar aan werkt.

[Reactie gewijzigd door watercoolertje op 22 juli 2024 15:58]

Copyright gaat over auteursrechterlijk beschermde werken. En een getrainde AI valt daar simpelweg niet onder - het trainen van een neuraal netwerk is een geautomatiseerd proces.

De GPL geeft je toestemming om beschermde werken toch te kopieren, onder voorwaarden. Maar als die bescherming ontbreekt, is er dus ook geen noodzaak voor toestemming, en dus ook geen voorwaarden.
Mja, ik weet het niet hoor. Je kunt een neuraal netwerk bijv ook gebruiken om een API volledig in kaart te brengen en het achterliggende systeem van "geheime" code te emuleren. We zouden het nooit accepteren als een bedrijf dat zou doen bij een ander bedrijf. Maar deels doe je dat hier ook, met de collectieve kennis van een hoop vrijwilligers.

Hoe dan ook, co-pilot klinkt enorm interessant en is vernieuwend, maar de laatste woorden zijn waarschijnlijk nog niet gezegd over de juridische issues.

[Reactie gewijzigd door teek2 op 22 juli 2024 15:58]

Ik vermoed dat hier een nieuwe licentie voor gemaakt moet worden(GPLv4?). Ik ben het er mee eens dat technisch gezien dit is toegestaan, maar zou dat wel zo moeten zijn?
Als de GitHub Copilot getraind is op GPL code, die wordt weggegeven onder een expliciete copyleft licentie, is het dan toegestaan om deze tool closed-source te houden?
Ja. Net als dat je een AI kan trainen gebaseerd op open bronnen, zoals afbeeldingen. Als een mens het mag zien, dan mag een computer het ook zien. Zo kan ik jouw code ook gebruiken om les te geven over hoe programmeren (niet) moet, en aantonen hoe het beter kan om zo studenten slimmer te maken/beter te laten programmeren.

Verder hoef ik jouw GPL code ook niet te delen of jou geld te geven als ik het zelf wijzig, compileer en met het resultaat van het zelf uitvoeren van de code geld verdien. Zolang ik de code in wat voor vorm maar niet verder verspreid, kan ik ermee doen en laten wat ik wil.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 15:58]

Zo kan ik jouw code ook gebruiken om les te geven over hoe programmeren (niet) moet, en aantonen hoe het beter kan.
Maar dat gebeurt hier niet. Je creeert een afgeleid werk op basis van mijn code en dat is regel 1 van de GPL.
Verder hoef ik jouw GPL code ook niet te delen of jou geld te geven als ik het zelf wijzig, compileer en met het resultaat van het zelf uitvoeren van de code geld verdien. Zolang ik de code in wat voor vorm maar niet verder verspreid, kan ik ermee doen en laten wat ik wil.
Prima, maar wat Copilot doet is letterlijk de code verspreiden.
Maar dat gebeurt hier niet. Je creeert een afgeleid werk op basis van mijn code en dat is regel 1 van de GPL.
Dat doen studenten ook die iets leren. Immers kan je hetzelfde maar op zoveel manieren schrijven in code. Dat maakt het niet automatisch GPL, als het vanaf de grond af aan opnieuw opgebouwd wordt voor een nieuwe functie.
Prima, maar wat Copilot doet is letterlijk de code verspreiden.
Dat is niet wat ik lees in het artikel. Volgens het artikel leert Copilot van code, en doet daarop gebaseerd suggesties. Net als dat een docent leert met coden en gebaseerd op wat geleerd is suggesties doet naar studenten. Je zal daar ook veel overlap in zien van code die lijkt, maar niet hetzelfde is.

Schrijf als ontwikkelaar een stuk code uit je hoofd voor iets, en het is gegarandeerd dat het/een deel lijkt op een stuk GPL code dat ergens publiekelijk beschikbaar is. Dat maakt het geen afgeleid werk.
Maar je kunt helemaal niet identificeren dat dit jouw coderegel was. Jouw code 'lijkt' op de andere 1000-den regels code van anderen die ook dezelfde stub in dezelfde structuur of met zelfs dezelfde woorden gebruikten. Daarmee is de probability functie in de AI versterkt dat deze specifieke stub van de code op die manier geschreven kan worden en word als zodanig voorgesteld
Dus je zegt dat het een afgeleide is van mijn werk? Want dan geldt de GPL.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 15:58]

Het kernpunt is dat er maar een paar goede manieren zijn om de code te schrijven. Je kan geen auteursrecht nemen op iets dat logisch volgt uit een bepaald systeem, omdat je dan niet innoveert.

De innovatie hier is dat het systeem snapt welke code het moet genereren en welke patronen het moet toepassen om je op weg te helpen. De output is gemodelleerd op basis van eigen input en training via openbare datasets. Dus je kan stellen dat er een gehalte van afleiding is. Maar voordat je toekomt aan de vraag welk percentage van jouw werk erin zit moet je kunnen bewijzen dat jouw code uniek en innovatief genoeg is om door het auteursrecht beschermd te worden.

En dat gaat je (zo goed als) gegarandeerd niet lukken. Omdat de context waarin jouw code is geschreven misschien wel heel innovatief is. Maar de code regels zelf zijn dat niet.

Het scenario waaraan je bescherming verdient is wanneer iemand jouw tool probeert na te bouwen. En de CoPilot vrolijk die code oplepelt omdat het snapt wat je aan het nabootsten bent. En dan zeg ik het al: Dat is nabootsen. Maar ik haal niet uit dit artikel dat deze tool dat scenario ondersteunt.
Als ik iets uit mijn hoofd schrijf en het lijkt op jouw code omdat jij en ik in dezelfde klas programmeren hebben geleerd, dan is mijn code geen afgeleide van jouw code. Ook als jij mijn docent zou zijn geweest, zou in deze situatie mijn code geen afgeleide zijn van jouw code.

Deze discussie was al eens eerder gevoerd (SCO met Unix vs. Linux). Enkel omdat code lijkt op andere code, maakt het geen afgeleid werk.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 15:58]

Als jij leert programeren op basis van GPL code voorbeelden, ga je dan je programeur salaris aan de schrijvers van de code verdelen?

[Reactie gewijzigd door arnonymous op 22 juli 2024 15:58]

Maar dat is helemaal geen vereiste met GPL :). Wat @Verwijderd wel impliceert is dat alles wat die student in het vervolg schrijft automatisch ook GPL is.
Bijna alle code die 99% van de programmeurs dagelijks schrijft is al een keer geschreven, zeer waarschijnlijk in een meer efficiëntere vorm.
Data in een database stoppen, er weer uithalen, de data transformeren naar wat via een service aangeboden wordt, het consumeren van een service, het weergeven van de data in een scherm of website. etc.
Er zit ontzettend veel herhaling van truckjes in het dagelijks leven van een coder, en dan is de code vaak ook nog eens niet de best mogelijk variant.
Zeer handig als een co-pilot je daarbij helpt.

Klinkt als linters on steroids.
Geef jij een deel van jou inkomen aan stackoverflow? Aan de makers van de documentatie van jouw taal?
Je collega die je code reviewed, je mentor die jou hielp met coderen? Aan iedereen van wie je ooit hebt geleerd?
Als je GPL code leest om van te leren en vervolgens een eigen implementatie schrijft, bijvoorbeeld in een andere programmeertaal is die code niet automatisch GPL.
Zeker, want toen je het op GitHub zette ging je ook akkoord met de voorwaarden van GitHub. En die hebben ook deze er in staan:
[...] You grant us and our legal successors the right to store, archive, parse, and display Your Content, and make incidental copies, as necessary to provide the Service, including improving the Service over time. This license includes the right to do things like copy it to our database and make backups; show it to you and other users; parse it into a search index or otherwise analyze it on our servers; share it with other users;
Simpel: jouw code niet delen, probleem opgelost.
Ik neem aan dat ze geen GPL code gebruikt hebben maar MIT of Apache code.
En als ze straks geld vragen voor Copilot, mag ik dan gratis toegang omdat ik heb bijgedragen aan deze tool?
Ik verwacht dat MS dit net zo doet als met Active Directory: "dank jullie voor je werk aan LDAP en Kerberos, we'll take it from here."
Je hebt hier zeker een punt.

De voorwaarden die een partij stelt mogen niet tegen de wet ingaan, dan zijn die voorwaarden niet rechtsgeldig. Licenties zoals GPL zijn juridisch al vastgelegd.
Voorwaarden stellen als: "GPLs gelden niet voor ons.", zullen juridisch geen standhouden. De gene die het op GitHub heeft gezet, heeft natuurlijk niet per se alle code geschreven.

Mocht dit tot een rechtszaak komen, ga ik er vanuit dat Microsoft door het stof zal moeten gaan.
Gefeliciteerd. Je bent nu verantwoordelijk voor het onderhouden van code, geschreven door 'n robot.
Yup. Net zo goed als dat je verantwoordelijk bent voor hoe de auto door Autopilot of FSD bestuurd wordt....

Net als bij Tesla's idee van "Automatische piloot" is het hier nogsteeds de programmeur die verantwoordelijk is voor de afgeleverde code. De bot kan helpen die code sneller te genereren maar jij zult moeten controleren of die code ook juist is of niet.

Het is niet zo dat dit ding het werk van je over neemt. Net zo min als dat autocomplete dat doet. Het is een hulpmiddel. Niet meer en niet minder.
ach, er zijn al zat bots die ervoor kunnen zorgen dat security issues redelijk goed opgespoord en verholpen kunnen worden dus zoveel werk zal 't niet zijn :)
Tijdens het schrijven van code krijgt de ontwikkelaar suggesties voor hele lijnen code of zelfs complete functies die Copilot voorstelt op basis van de context tijdens het typen, dus op basis van de code waar een ontwikkelaar aan werkt.
Nee dus, de programmeur moet nog steeds de code schrijven en dit is in feite een soort van intelligente autocomplete/linting/.. in een verpakking.

Deze tools zijn juist ontzettend handig en maken meestal gebruikt van een set regels geschreven door een programmeur (ook wel mens genoemd) aangedreven door een stuk AI.

Het is jammer dat mensen dit weer uit de context halen. Een auto bestuur je ook niet helemaal alleen, daar zitten ook genoeg hulpmiddelen in zoals ABS, stuurbekrachtiging, etc. Zeggen we dan ook dat de auto rijdt en niet de bestuurder ervan?

[Reactie gewijzigd door HollowGamer op 22 juli 2024 15:58]

Nou ja, als er volledige functions gesuggereerd worden, wat leer je er zelf dan nog van? Ik zet zelf overal autocomplete uit omdat 1) ik die constante popups/overlays echt schijtirritant vind 2) het nooit 100% in mijn eigen coding style gedaan wordt 3) ik zelf wil bepalen hoe een bepaalde functie gedaan wordt.

Een autocomplete/suggestion voor function names en parameters is nog wel acceptabel, want je moet zelf nadenken welke function je moet hebben en welke parameters je moet passen. Net als mensen die alleen maar een beetje copypasten van StackOverflow et al. Leuk dat het werkt, maar begrijp je nu wat je gedaan hebt? Anders ben je geen programmeur (imo). Ik snap ook wel dat je nooit 100% van álle code kunt begrijpen, maar als je maar 1-10% begrijpt dan heb je iets niet goed gedaan.

Jouw vergelijking met auto's klopt niet, ABS en stuurbekrachtiging hebben geen effect op jouw skills als bestuurder. Het is ook niet alsof die suggereren van "en nu moet je hier rechts de bosjes in".

[Reactie gewijzigd door McBacon op 22 juli 2024 15:58]

Ben je vaak sowieso al; veel code wordt automatisch gegenereerd, en je bent ook verantwoordelijk voor de code in libraries die je gebruikt.
De verantwoording ligt natuurlijk bij de persoon die die door AI uitgespuugde code in productie neemt/gebruikt :) Of jij dat bent, een AI of een package die ik in mijn project gebruik doet er weinig aan af.

Tenzij die AI zelfstandig projecten mag maken en deployen en daar zelf een bedrijf voor is gestart (en dus niemand de genomen beslissingen controleert) is die AI niet zelf verantwoordelijk.

[Reactie gewijzigd door watercoolertje op 22 juli 2024 15:58]

Misschien ben ik te oud, maar ik vind dit geen goede ontwikkeling. Ik zie vaak programmeurs die aan “coding by coincidence” doen. Ze begrijpen de details niet, maar ze vinden wel iets dat werkt.

Ik vrees er voor dat AI generated code er nog meer voor gaat zorgen dat programmeurs niet alles lezen, 100% begrijpen en aan de edge cases denken.

In “hogere” programmeertalen, met frameworks en libraries is er weinig nood aan boilerplate. Daar zit niet veel repetitie in.

Misschien is dit wel handiger voor lower level talen waar wel meer boilerplate en repetitie is en zie ik het verkeerd?
Dat zou mij dus weerhouden om dit te gebruiken.
Coden is voor mij een leerproces. Ik moet leren hoe te testen, maar vooralsnog is het ‘run en kijk naar de log’. Als ik van half de code niet weet wat ik zou moeten zien, hoe kan ik dan debuggen? En hoe kan ik dan überhaupt plannen?
Mischien mis ik een deel van de puzzle?
Mischien mis ik een deel van de puzzle?
Ja en nee, heb je dit niet als je samen werkt met anderen? En is het daar een issue? Tuurlijk een AI kan je misschien (nog) niet vragen waarom ie bepaalde keuzes maakt, aan de andere kant doet ie gewoon voorstellen en geen hele projecten maar simpelweg werkt ie een beetje vooruit op jou en is het aan die code te verfijnen (of na doornemen/begrijpen te gebruiken in zijn geheel).

Anyway ik ben vooral huiverig dat ik straks vervangbaar ben door een AI :P Hoewel ik voorstander ben dat computers alles voor ons doen (mits dat net zo goed/beter gaat) moet ik daarin wel een modus zien te vinden waarin ik inkomen heb om bijv. mijn hypotheek te kunnen betalen.

[Reactie gewijzigd door watercoolertje op 22 juli 2024 15:58]

Anyway ik ben vooral huiverig dat ik straks vervangbaar ben door een AI :P Hoewel ik voorstander ben dat computers alles voor ons doen (mits dat net zo goed/beter gaat) moet ik daarin wel een modus zien te vinden waarin ik inkomen heb om bijv. mijn hypotheek te kunnen betalen.
Dat is de klassieke angst voor automatisering. Je beweegt mee of je raakt achter. Met code kloppen is vervanging natuurlijk al een tijd gaande. Voor jouw salaris 10 programmeurs in India (met brakkere kwaliteit code, veel meer overhead, etc... Maar dat zie je niet terug in rapportage!).

In jouw geval, waarom word je geen AI programmeur? :+

Hondenkarrenbestuurders hebben ook al +100 jaar geen baan meer. Daar hoor je ook niemand over klagen, behalve toen de voormalige hondenkarrenbestuurders die zich niet om lieten scholen naar koets- of autochauffeur.

Better start swimming now or you'll sink like a stone.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 15:58]

Vroeger werd ook alles met de hand gemaakt, totdat eerst de lopende band kwam en later alle robots. Er zijn meer baantjes nu dan ooit.
Solo dev dus de enige die me stokken in de wielen steekt is ikzelf van gisteren - al erg genoeg met zijn spaghetticode :/
Ben je je ervan bewust dat compilers al heel lang bestaan? Hoewel geen AI, maar een "klassiek" algoritme, genereert die ook code op basis van wat het ziet. Lees jij die assembly?

Zo'n AI genereert net zo goed code. Zijn mensen slechter gaan programmeren sinds ze niet meer in machine code programmeren?

Edit: Pre-koffie ramble weggehaald

[Reactie gewijzigd door Higaphix op 22 juli 2024 15:58]

Uiteraard.

Compilers vertalen higher level languages naar machine taal. Die doen dat wel binnen de boundaries van de higher level langauge. Een stuk C code heeft een (vrij strict) bepaalde behaviour. De assembly code uit de compiler gaat zich houden aan die behaviour. De compiler krijgt vrij spel in welke machine instructions het kiest, maar niet in de behavior.

Anders gezegd: de compiler gaat niet gokken welke logic je wilt. Het gaat gedefinieerde logic omzetten in assembly code. Deze AI gaat (business) logic gokken.. Dat vind ik heel anders.
eerste keer dat ik assembly écht las was toen ik gehacked werd door Chernobyl.. Dat stukje vakwerk heeft me wel ff bezig gehouden..

Maar je hebt gelijk; een compiler met brand specific assembly is levensgevaarlijk voor de staatsveiligheid en tevens voor de democratische waarden. Maakt de bit en alle talen by definition al biased, concurrentievoordeel, dus de impact van bv. politici op fakenews loopt richting de 99,9%.

Om je vraag te beantwoorden:
de moderne programmeurs hebben veel meer tools en mogelijkheden tot hun beschikking gekregen maar de blackbox tussen hun IDE en de finale integers die naar de hardware registers gaan, is onbereikbaar voor bijna alle programmeurs. En dat proces is een stuk waziger geworden, terwijl er bv. ook nog shaders zijn.
Maar bv. een Apple heeft hier altijd extreem goed zicht op gehad; ook Google kan er wat van.

En non ANSI devs hebben ook een zuiverdere kijk op IT, omdat die meer gedwongen worden om betekenissen te achterhalen en dus minder vanuit aannames werken. Vandaar ook mijn afkeer van die non coding platforms, hoewel ik, en andere liefhebbers van functionele talen, het eigenlijk de default vindt.

Kijk de grote en everlasting discussies uit de IT er maar op na:
* FreeSpeech
* FreePress
* Het ontstaan van Linux (RMS en Linus
* Het ontstaan van Internet en de evolutie naar decentralisatie
* Open Source (en de overheid
* GPLv2 vs. GPLv3
* NetNeutraliteit
* De macht van App stores en OS'es.
* enz. enz. enz.

Die hebben de blackbox flink opgerekt.. En Apple heeft de standaard daarin strak weggezet, met LLVM/Clang. Maar hackers nog iets scherper, met UTF8Everywhere. Unicode wars is wellicht een betere politieke benaming, om de chaos in de markten als IoT, 5G/WIFI6, Glasvezel, satellites te omschrijven.

Al met al een hoop engineering om General Purpose Computing flink onrecht aan te doen. Zeker nu de gehele infrastructuur verbouwd is, chrono als belangrijkse verandering. Ja, als programmeur moet je wel zicht hebben op de syscalls.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 15:58]

Compilers geen AI? Een typische component in compilers zijn de optimizers. Die passen vrij gebruikelijk Pattern Recognition toe, wat een belangrijk vakgebied binnen AI is.
"coding by copy and paste stackoverflow" bedoel je. :)
From the question or the answer section?

@AndrewF
Zo begint elke dev toch? Leren van voorbeelden is niets mis mee. Daarbij werk je toch ook vaak aan code geschreven door een ander? Het begrijpen van niet door jou geschreven code is een leerproces waar iedereen doorheen moet. Volgens mij verdwijnt het zelfs nooit.
Klopt. Absoluut. Ik leer ook van voorbeelden.

Ik spendeer nu meer tijd met het lezen en reviewen van code van anderen dan er zelf te schrijven. Ik ben blij dat die code geschreven is door een mens die het begrijpt. Developers die copy/pasten zonder te begrijpen haal je er best snel uit als je een paar vragen stelt.

Iets als dit lijkt me, op dit moment tenminste, die barrière te verlagen. Als je toch de code moet lezen en begrijpen en toetsen aan alle edge cases, win je dan nog veel tijd ten opzichte van het zelf te schrijven? vooral in high-level languages met libs en frameworks?

Als ik zelf iets schrijf dan spendeer ik 95% van mijn tijd met het nadenken en maar 5% met het uitschrijven. Het werk is in een grote volwassen bestaande codebase, dus dat is sowieso meer editen dan from-scratch.
Ik dacht dat de term "Voodo programming" was. Net zo lang prikken totdat het doet wat je wil.

Maar ik denkt dat juist een AI tool wel kan helpen om tests voor edge cases te genereren. Geen idee overigens of copilot dat doet. Overigens lijkt het door hun voorbeelden wel alsof er hele functies verzonnen worden, maar ik he real-world voorbeelden gezien die in iets kleinere stappen werken. Dan is het meer een co-pilot waarbij je zelf wel moet blijven nadenken.
Deze 'bot'/AI werkt niet zonder input van de programmeur, je moet daadwerkelijk iets van code ingeven en ik vermoed dat deze tool daarna je suggesties geeft/de code mogelijk compacter maakt/verbetert, eigenlijk zoals hetzelfde als een ESLint of andere code analyse tool.

Het voordeel is juist betere (leesbare) en compactere code. Voorheen gebruikte ik ook al zaken als linting, maar nu ik alles zoveel mogelijk 'streng' heb ingesteld, heb ik ook ontzettend veel geleerd waarom je bepaalde calls bijvoorbeeld op een bepaalde manier doet of hoe je code ook anders kunt schrijven.

In mijn ogen ligt het ook aan de mindset van de developer. Ik ben nogal gevoelig voor onleesbare of 'brakke' code (zoals geen typehints gebruiken), dus met zo'n bot doe ik mijzelf als ook andere in mijn team een groot plezier (hoop ik). :)
Deze Copilot maakt het wel heel makkelijk om de voorgestelde code te accepteren. Risico's zitten vooral bij beginnende en luie ontwikkelaars en in projecten waar veel druk op zit. Ik voorzie ook problemen bij de onderhoudbaarheid van de codebase op langere termijn bij veel Ai inbreng.
Voor een ervaren ontwikkelaar echter kan dit een fantastische tool zijn als de AI ineens een heel andere aanpak voorstelt wat tot nieuwe inzichten kan leiden voor de ontwikkelaar die al jaren hetzelfde trucje toepast en er ineens achter komt dat zijn aanpak met 10 regels vereenvoudigd kan worden.
Dus ja, behandel een geavanceerde tool als een geavanceerde tool en eis van de ontwikkelaar een actieve houding bij het inzetten ervan.

[Reactie gewijzigd door bvervelde op 22 juli 2024 15:58]

Ik ben ook een beetje bang voor veel herhalende code. AI is juist geschikt voor het herkennen van herhalende code, dus als die AI mij herhaaldelijk hetzelfde stukje code voorschotelt, zit ik uiteindelijk met een codebase waar veel bijna identieke codestukken in zitten. Ik zeg "bijna" want de context zal overal een beetje verschillen. Normaal gesproken zou je die code dan extraheren en in een meer generieke functie zetten. Bottom line: hoe onderhoudbaar is deze robot-code?
Ik ziet het meer als handige snippets, stukjes voorbeeldcode die voor je geschreven worden passend bij wat je wilt doen. Dit is super handig. Wanneer je met bijvoorbeeld een nieuwe taal werkt scheelt je dat heel veel googlen. Kanttekening is dat dit natuurlijk een voorbeeld is dat wel erg goed uitpakt, maar er zullen ook heel wat situaties zijn waarbij de voorgestelde code minder relevant is. Maar zeker erg veelbelovend voor de toekomst.
Zoiets beeld ik me nu ook in. Je wilt bijvoorbeeld een functie schrijven om datums op te maken en hebt al de hele functie in je hoofd zitten. De AI heeft ook door wat je wilt gaat doen en maakt die functie op enkele milliseconden.

Maar ja, tot je het zelf kan gebruiken en kan uittesten is het dus wat gokken ove hoe goed het werkt en wat het nu juist doet.
Hmm, het wordt getraint met code. Maar wordt het ook alleen maar getraint met goede, bugvrije code?
Of stelt hij straks nieuwe CVEs (etc) voor?
Maar wordt het ook alleen maar getraint met goede, bugvrije code?
Bestaat dat dan?
Of stelt hij straks nieuwe CVEs (etc) voor?
Mogelijk, net zoals elke menselijke programmeur dat kan doen.

[Reactie gewijzigd door watercoolertje op 22 juli 2024 15:58]

En over xx jaar praat je tegen een programma hoe je een nieuw programma wilt hebben, en dan programmeert dat programma je nieuwe programma. (En verbeterd het zichzelf op de weg naar wereld dominantie 😁)
Gewoon een voorbeeld van het belang van MS bij Github en Visual Code. Of dacht iemand dat ze Github overgenomen hebben uit liefdadigheid?
Github is voor MS erg belangrijk als een middel om de softwaremarkt meer te gaan overheersen. Grootste opponent? Google.
Is dit het begin van het einde van de menselijke programmeur?
Ik zal eens even een boude stelling neerzetten:

Het hele punt van programmeren is om mensen werkeloos te maken met steeds verdergaande automatisering. Programmeurs zullen op een gegeven moment ook hun eigen werk zo ver kunnen automatiseren dat ze geen baan meer hebben.

Dat zal de komende tien jaar niet gebeuren, en de decennia ook nog niet. Maar eens op een dag kunnen we allemaal genieten van het leven zonder ook maar iets te hoeven doen.
Oké, ik begrijp de eerder negatieve reacties hier boven.
Maar langs de andere kant lijkt dit me een super initiatief om open source te promoten en programmeren te vereenvoudigen.

Al is zo'n functie niet meteen voor beginnende programmeurs aan te raden, lijkt me.

Op dit item kan niet meer gereageerd worden.