GitHubs AI-gestuurde programmer kost 10 dollar per maand

Github heeft Copilot, een AI-gestuurde pair programmer die ontwikkelaars helpt bij het schrijven van code, uitgebracht voor het brede publiek. De tool kost 10 dollar per maand of 100 dollar per jaar. Studenten en medewerkers van populaire opensourceprojecten hoeven niet te betalen.

GitHub bracht een jaar geleden een preview uit van Copilot en die werd volgens Github op twaalf maanden tijd door meer dan 1,2 miljoen ontwikkelaars gebruikt. In projecten waarbij de AI-gestuurde pair programmer werd ingeschakeld, werd bijna 40 procent van de code door Copilot geschreven.

Copilot is ontwikkeld in samenwerking met OpenAI en maakt gebruik van de OpenAI Codex. De AI-toepassing geeft tijdens het programmeren suggesties voor nieuwe regels code, maar ook voor complete functies. De tool analyseert hiervoor de huidige code van het project. Copilot kan ook opmerkingen omzetten in code, repetitieve code aanvullen en functies uittesten tijdens het schrijven. Gebruikers kunnen suggesties die aangereikt werden door de tool, toevoegen aan hun project of gewoonweg negeren. Voorgestelde code kan ook manueel aangepast worden.

Copilot is volgens Github meer dan een autocomplete. De tool leert bijvoorbeeld van de context, maar ook uit vooraf geschreven code. Het begrijpt wanneer er een docstring wordt getypt, een opmerking, een functienaam of een reguliere regel code. De tool is als een extensie te downloaden voor Microsoft Visual Studio Code, Neovim en verschillende JetBrains IDE's.

GitHubs Copilot

Reacties (146)

[Akamatsu]

Heb een tijd lang Copilot gedraaid en geprobeerd en wow wat is dat een mooi ding.

Ik gebruikte het onder andere toen ik wat onbekende talen beter wilde kennen, gaf copilot hele leerzame results en maakte het, het leren eigenlijk veel sneller dan constant googlen

Ook waren de String aanvullingen verassend goed, je zou verwachten dat hij alleen Engelse Strings kan aanvullen, maar nederlandse String vult hij ook gewoon in perfect Nederlands aan en geeft goede vervolg suggesties.

Ook bij het parsen van data, als je een kleine sample van de data al in het project hebt staan geeft hij solid suggesties.

Ongelofelijk knappe AI hebben ze getraint, ik denk dat het de 10 eur per maand zeker waard is.

[Jerie]

Deel van wat je zegt (aanvullen strings) kan een LSP ook.

Wordt je voor die 10 EUR/maand ook onderdeel van de dataset of koop je dat daar mee af?

[Mmaaikel]

Je kan bij het registreren voor co-pilot aangeven of je onderdeel wilt worden door dat aan te vinken. Standaard staat dit uit.

[Oon]

Bij mij stond het vinkje in het formulier standaard aan, dus wel iets om op te letten bij het aanmelden

[Rhydium]

Bij mij stond dat vinkje ook standaard aan, ik had alleen een helemaal blanco keuze m.b.t. het gebruik van code snippets uit publieke repositories.

[YopY]

Als je het voor een bedrijf gebruikt MOET je het uitzetten ivm eigendomsrecht en geheimhoudingsplicht en dergelijke.

[Oon]

Moet van Github('s ToS), of moet van je werkgever?

De meeste werkgevers zullen er inderdaad niet mee akkoord gaan als je gegevens wil delen, maar het kan in theorie wel

[AlRoke]

Blijft interessant hoe we duidelijk hetzelfde ding hebben gebruikt en zijn weggelopen met compleet verschillende indrukken. Mijn impressie was dat het prima werkte voor extreem simpele zaken, maar dat 1) prompt based code generatie bizar slecht en buggy was en 2) de autocompletes die redelijk werkte nauwelijks beter waren dan de autocompletes van m'n editor.

Ook code gezien van een junior die het gebruikte... En dat was ergens nog zorgwekkender, want hij deed plotseling dingen die al 10 jaar not done zijn in de taal waarin we werken en z'n code kwaliteit ging merkbaar omlaag, alhoewel de verlaging in kwaliteit ongeveer in lijn liep met een kleine verhoging in productiviteit mogelijk. Hoe dan ook, toen ik vroeg in een code review waar hij een wel heel bizar stuk code vandaan haalde kwam ik erachter dat dat dus CoPilot was en heb ik hem maar geadviseerd het niet te gebruiken.

Maar goed, haalt allemaal niet weg dat het super super leuk is om mee te spelen, maar had totaal niet verwacht dat er mensen zijn die er geld voor over hebben.

[Oon]

Mijn impressie was dat het prima werkte voor extreem simpele zaken, maar dat 1) prompt based code generatie bizar slecht en buggy was en 2) de autocompletes die redelijk werkte nauwelijks beter waren dan de autocompletes van m'n editor.

Het is ook erg afhankelijk van wat je gebruikt. Als je bijvoorbeeld in PHP met Laravel werkt dan is er zoveel informatie beschikbaar dat de suggesties prima zijn, maar als je in een of ander obscuur python framework werkt dan zal je IDE nuttigere aanvullingen doen.
Andere dingen zoals wanneer je een lege functie schrijft met een duidelijke naam en comments (inclusief een docblock met daarin de parameters en output die je verwacht) lijken bij mij prima te werken, maar daar is het ook vaak de vraag hoe nuttig de aanvulling is t.o.v. wat je IDE tegenwoordig zelf al kan.

Ook code gezien van een junior die het gebruikte... En dat was ergens nog zorgwekkender, want hij deed plotseling dingen die al 10 jaar not done zijn in de taal waarin we werken en z'n code kwaliteit ging merkbaar omlaag, alhoewel de verlaging in kwaliteit ongeveer in lijn liep met een kleine verhoging in productiviteit mogelijk. Hoe dan ook, toen ik vroeg in een code review waar hij een wel heel bizar stuk code vandaan haalde kwam ik erachter dat dat dus CoPilot was en heb ik hem maar geadviseerd het niet te gebruiken.

Dit is het grote probleem waar we tegenaan gaan lopen. Datzelfde speelt al een tijdje in de wereld van vertalers (voor gewone tekst), daar zijn nu ook ML-engines die eigenlijk precies hetzelfde doen, maar waarvan het resultaat ronduit amateuristisch is.
In development zijn er zoveel mogelijkheden dat je echt moet kunnen afwegen of de suggestie nuttig is, dus iemand die nog op junior niveau zit doet er beter aan om bijv. TabNine te gebruiken, die een iets minder experimenteel model hebben dat zich vooral richt op je eigen code, en ook expliciet een dataset kan genereren op basis van je GitHub of GitLab repositories.

Ik merk dat ik zelf wel vele malen sneller door sommige projectjes heen loop, maar dat het bij productiecode (dus niet een intern projectje) vaak nog echt wat knutselen is om het resultaat weer op niveau te krijgen. Ook daar speelt diezelfde vergelijking met de vertaalwereld; je krijgt een voorzetje, maar moet het wel echt zelf nog nalezen en even de 'grammatica' fixen, ondanks dat de 'spelling' (syntax aan onze kant) prima is. Het resultaat zal niet gauw niet werken of functioneel gezien echt niet kloppen, maar is vaak gewoon niet zoals je het zelf zou 'zeggen'.

Ben ook wel benieuwd hoe dit qua overeenkomst zit als je dit gebruikt icm code van je werkgever, want ik kan me niet voorstellen dat met die opt-out er helemaal geen data meer wordt verzameld.. Ze zullen op z'n minst jouw afweging tussen de resultaten weer terugsturen om daar een score aan te hangen voor de volgende suggestie.

[Maurits van Baerle]

Ik heb te weinig ervaring met zelf code kloppen om hier heel veel over te kunnen zeggen maar zou het niet kunnen dat op termijn dit juist de goede kant op buigt?

Je zou bij uitstek AI kunnen trainen om de meest recente Best Practices te adviseren en zelfs modernere methoden voor te stellen als een menselijke developer nog een verouderde methode gebuikt. Lijkt me ook ideaal voor refactoring. Uitgerekend AI zou goed moeten zijn in herkennen hoe men iets tien jaar geleden aanpakte en hoe we dat tegenwoordig liever anders aanpakken.

Wat ik wel als een risico zie is dat, juist als AI érg goed is geworden in programmeren, mensen veel eerder geneigd zijn om op die code te vertrouwen waardoor AI fouten makkelijker blijven zitten. Nu zijn mensen natuurlijk nog veel wantrouwender.

[detrukurke]

maar nederlandse String vult hij ook gewoon in perfect Nederlands aan

getraint

Ik zie mogelijkheden.

[MarkSdS]

Die zag ik ook

[city17]

Vond de preview goed werken, maar je moet wel bewust zijn van de beperkingen. Je krijgt soms ook slechte of irrelevante code, dus je moet nog steeds wel in detail controleren wat je voorgeschoteld krijgt.

Vind eigenlijk het handigste als een soort slimme voorspeller van repetitieve situaties, waar je meerdere keren dezelfde code schrijft maar net met een aantal kleine variaties. Bij meer dan 2 regels wordt de kwaliteit aanzienlijk minder.

[Reactie gewijzigd door city17 op 23 juli 2024 00:24]

[air2]

En repeterende code is sowieso vaak al niet wenselijk. Duid er toch vaak op dat je er nog een refactor slag overheen moet halen.

Dat gezegd hebbende. Ik heb nooit met deze tool gewerkt, maar kan me wel voorstellen dat het goed kan helpen.

We gebruiken geen github maar lijkt me toch wel leuk om eens mee te werken

[familyman]

Je hebt ook repeterende code als in code die in meerdere applicaties terug (kan) komen, zoals architectuur boiler plate.

Daarvoor kan het handig zijn, denk ik.

Ook heb je soms code die je per feature maakt, of soms verschillende teamleden in verschillende features.

Dan kan het juist best gaaf zijn als een AI voorstelt om andere code te hergebruiken, als die er erg op lijkt, danwel een refactoring voor te stellen van functies die hetzelfde lijken te doen.

[Oon]

Ik gebruik het nu al sinds het begin (ik kreeg toegang in een van de eerdere rondes) en het is wel echt steeds beter aan het worden, maar inderdaad vooral nuttig voor het herhalende werk.

Grote stukken code schrijft hij nog niet voor je, maar het is echt verbazingwekkend hoe goed hij herkent wat je bedoelt. Een voorbeeld is een stukje stylesheet voor een knopje, als je die een kleur geeft en dan een hover class maakt, gokt hij automatisch dat je de achtergrondkleur waarschijnlijk donkerder wil maken, en dat doet hij dan op basis van de standaardkleur.

Dat soort kleine slimme dingetjes kunnen heel veel tijd schelen.

Aan de andere kant heb ik ook wel eens gemerkt dat ik bijv. twee keer een loop over dezelfde array wil doen vanuit twee verschillende stukken code, en dat hij dan twee verschillende suggesties geeft. Dat vind ik dan weer jammer, want dat maakt dat je toch minder grip hebt op je code. Wel goed voor je herhalingspercentage (minder gekopiëerde code als overal een andere oplossing gebruikt wordt ), maar niet goed voor de leesbaarheid

[dieAndereGozer]

waar je meerdere keren dezelfde code schrijft

Voelt alsof je dit anders moet oplossen. Functies enzo.

[Remzi1993]

Functies, classes en methods. En niet de loops vergeten. Nooit code herhalen lol 😂

[dieAndereGozer]

Code is niets anders dan if's en else's. Change my mind

[Remzi1993]

Dat is grotendeels waar haha 😂🤣

[junkchaser]

En zo helpen we onszelf de wereld uit...

[Verwijderd]

Het enige waar OpenAI voor kan gebruikt worden is code uit te braken dat het elders gevonden heeft door de context van je vraag te matchen met de context van waar het de code vond.

M.a.w. dat is wat libraries ook al deden. Alleen in plaats van dat we dit momenteel met libraries doen, zullen de toekomstige OpenAI-gebruikers al die code-snippets opnieuw en opnieuw en opnieuw gebruiken zoals een soort van copy-paste brei die nooit meer geupdate zal worden. M.a.w. de nieuwe manier om malicious code in tienduizenden projecten te krijgen zal zijn om de OpenAI bot te verzieken met bugs in bepaalde algorithmes die junior developers achteloos zullen doorvoeren over geklik en geklak met hun OpenAI Visual Studio plugins. Recht in hun code. Duizenden keer gecopypaste. Overal bufferoverflows, SQL-injections, en zo verder. Die er niet uit-geupdate kunnen worden want nu zit het niet meer in geversioneerde libraries. Maar wel steeds opnieuw, overal, ad-random, in hun eigen code, gecopypaste.

Het was nog niet erg genoeg. Het kon nog erger. Dus gingen we dat ook doen ook.

Arme gebruikers want die weten niet beter en worden al maar meer afhankelijk van deze, onze, lage kwaliteit binnen onze sector van software ontwikkeling.

Maar! Nu is er AI en word ik nummer één. Dankzij AI word ik nummer één. Vreemde talen waren altijd mijn probleem. Dankzij dat ding worden zij nu mijn embleem. Nu word ik de man. Trililietatatataa.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:24]

[Thrizian]

Wat een getekend comment. Ik gebruik het om een soort assisted learning te krijgen in programmeren. Natuurlijk moet je er vanuit gaan dat AI niet feilloos is en moet je je blijven verdiepen in wat er achter de schermen gebeurt en bewaken dat je kwaliteit code oplevert. Maar diverse suggesties schelen mij uren aan documentatie doorspitten voor die ene tool die ik wel echt nodig had.

Als junior merk ik dat het niet altijd makkelijk is de tijd van een senior te bemachtigen en te sparren over welke schroevendraaier ik nou moet hebben voor mijn spijker, om te horen dat ik een hamer moet gebruiken. In documentatie vind ik vaak iets wat ook doet wat ik zou willen maar dat is dan niet een schroevendraaier maar een hamer, terwijl ik een schroef heb. Klopt die schroef gaat er toch wel in, maar het is niet de manier. Als ik een suggestie krijg waar ik op door kan lezen of die me een duw in de juiste richting van de docs duwt heb ik daar heel veel aan.

Maar kan me voorstellen dat je wanneer je meer bekwaam opgeleid en ervaren bent je minder snel tevreden bent met wat een copilot oplevert.

Voorbeeld, vanmorgen uitnodiging gekregen voor copilot, wilde ik gebruiken om wat webcomponents te bouwen, gaf suggesties over de diverse callbacks die beschikbaar zijn waarvan ik nog onbekend was met enkele. Of de :host css selector die de host van de shadowroot kan targetten. Hierdoor belandde ik bij de documentatie van deze dingen en heb ik toch veel geleerd.

Ook merkte ik dat wanneer je begint met een comment schrijven die het gedrag verwacht dat de ai al meer context aware gaat schrijven. Dat was wel leuk om te zien. Ik steun je oproep om kritisch te blijven en niet alles uit handen te moeten geven maar we programmeren ook niet zo veel meer in ruwe machine code dus op een bepaald punt is iets goed en moeten we een stap verder, en snap ik dat er partijen zijn die de uitdaging aan gaan.

M.a.w. de nieuwe manier om malicious code in tienduizenden projecten te krijgen zal zijn om de OpenAI bot te verzieken met bugs in bepaalde algorithmes die junior developers achteloos zullen doorvoeren over geklik en geklak met hun OpenAI Visual Studio plugins. Recht in hun code. Duizenden keer gecopypaste. Overal bufferoverflows, SQL-injections, en zo verder. Die er niet uit-geupdate kunnen worden want nu zit het niet meer in geversioneerde libraries. Maar wel steeds opnieuw, overal, ad-random, in hun eigen code, gecopypaste.

Lijkt me vanzelfsprekend dat we hier aandacht voor moeten blijven hebben en moeten beseffen dat wanneer we een dergelijke assistent gebruiken we dit risico introduceren en dat proberen te mitigeren.

[Whazor]

Hoewel ik persoonlijk een groot fan ben van Copilot, deel ik wel de conclusie dat het veel problemen gaat opleveren. Het geeft mensen de mogelijkheid om te programmeren terwijl ze niet kunnen valideren of de code van hoge kwaliteit is.

In mijn ervaring is Copilot heel goed in het voorspellen wat voorn code er gaat komen. Dit is handig wanneer je voorspelbare patronen aan het implementeren bent, zoals CRUD. Het mes snijdt daarmee twee kanten op, voor mensen die hoge kwaliteit code opleveren is Copilot een goede toevoeging. Maar mensen die afhankelijk zijn van knippen en plakken (zo ben ik twaalfde ook begonnen met bouwen van websites) kunnen dus problematische code opleveren, als ze dat ook al niet eerder deden.

Al met al denk ik de geest uit de fles is en is het belangrijk dat mensen meer gaan leren over beveiliging, testtechnieken en andere informatie hoe ze software professioneler kunnen maken.

[Verwijderd]

Al met al denk ik de geest uit de fles is en is het belangrijk dat mensen meer gaan leren over beveiliging, testtechnieken en andere informatie hoe ze software professioneler kunnen maken.

De geest was al langer uit de fles: codeexchange en daarvoor expert-exchange geven ons programmeurs al jaren lage kwaliteit oplossingen na drukken op de knop 'Zoek'.

Wat ik denk dat leerkrachten software ontwikkeling moeten aanbrengen voor nieuwe studenten is dezelfde kwaliteit die men de afgelopen jaren bij wetenschapsstudenten heeft moeten aanbrengen: brononderzoek is belangrijk. Als het van WikiPedia komt is dat niet voldoende. Misschien is het soms beter een library te gebruiken i.p.v. gegenereerde code? Vanaf wanneer zal OpenAI terugvallen op een reeds bestaande library? En waarom? Omdat de author van die library OpenAI daarvoor betaald heeft? Omdat OpenAI geld verdient aan die oplossing te presenteren? Hoe zal de student van morgen kunnen doorhebben dat de whole game rigged is? Want uiteraard is dat zo.

[monotype]

Duizenden keer gecopypaste. Overal bufferoverflows, SQL-injections, en zo verder. Die er niet uit-geupdate kunnen worden want nu zit het niet meer in geversioneerde libraries. Maar wel steeds opnieuw, overal, ad-random, in hun eigen code, gecopypaste.

Zou een AI vrij niet ook makkelijk getraind kunnen worden om slechte code-patronen op te sporen en te verhelpen? Sterker nog, zou dat niet makkelijker zijn dan wat copilot nu al doet? Zou het er mischien al in zitten? Of is dat alleen in de platinum versie van 14.99$?

Op zich ben ik voorstander van code re-use door bibliotheken te gebruiken, MAAR grotere projecten hebben nu vaak weinig zicht op welke dependencies van dependencies van dependencies ze binnenhalen, en ook externe dependencies kunnen problemen opleveren die niet 123 op te lossen zijn (.. zie log4j ..) als projecten zich er niet van bewust zijn. Daarnaast kan met externe afhankelijkheden, ook plotseling het vloerkleed onder je vandaan worden getrokken ( https://www.theregister.com/2016/03/23/npm_left_pad_chaos/ ), en dan kan het ook triviale code zijn die geen dependency waard is.

[EiT]

Ach, we hebben toch ook low code zoals OutSystems. Dit inc. met wat AI maakt alles over bodig

[Killemov]

Ach, we hebben toch ook low code zoals OutSystems. Dit inc. met wat AI maakt alles over bodig

Zolang je binnen het stramien van OutSystems blijft, prima. Maar wat als je er net wat buiten wil doen? Waarmee integreert OutSystems eigenlijk? C#, Java, ...?

[akooijman]

Twintig jaar geleden kwam er uit tekstverwerkers ook voornamelijk rommel. Echte schrijvers/zetters konden het veel beter. (Al was TeX er twintig jaar geleden ook al, maar daar zullen we het maar niet over hebben.)

[hahaha]

Itt Elon Musk en anderen ben ik niet bang voor de grote smart AI. Eerder voor de dumb AI die met incomplete of ondoordachte parameters de wereld ingeschopt is
https://becominghuman.ai/the-dangers-of-dumb-ai-cb23bfe276ac

[Jens VD]

Wat een kortzichtige reactie is dit, alsof programmeurs die 100% op die code gaan vertrouwen anders wel veiligere code zouden geschreven hebben, of het dan maar niet gedaan zouden hebben. Niet dus.

Als je gelooft dat wij mensen het beter kunnen doen dan robots wat betreft veilige code genereren in de toekomst, dan ben je denk ik toch een aantal trends aan het missen. Dit is een van de eerste stappen in het automatiseren van het programmatieproces. In toekomstige updates kunnen ze code gaan labelen als zijnde kwetsbaar, en dan ook automatisch waarschuwingen gaan geven aan iedereen die zo'n code gebruikt (of varianten ervan).
Een development team de naam waardig gaat trouwens nog steeds de nodige code scanning tools gebruiken om te controleren op kwetsbaarheden. Die halen zo'n bufferoverflows of SQL-injections die duizenden malen gecopy-paste zijn er echt wel uit.

[Wozmro]

Er is toch nu al geen enkele sector zo geautomatiseerd als de programmeersector? In het prille begin was programmeren met schakelaartjes bitregisters inputten om dan met lampjes een output te verkrijgen.

Waarmee ik niet wil zeggen dat programmeurs op een dag overbodig zullen worden.

[.oisyn]

Is dit een reactie specifiek op @Verwijderd of denk je dat developers in het algemeen zo werken?

[Verwijderd]

Ik denk zelf dat @freewayorange12 een beetje gemismodereerd wordt hier omdat het ergens wel klopt dat in het algemeen software ontwikkelaars zo werken. Maar dat is daarom niet slecht. Zelfs vaak goed.

Alleen is het zo dat software ontwikkelaars daarnaast iets toevoegen.

Dat noemt bv. ervaring. Strategie. Richting.

Men mag dat negeren. En dan zal men falen. Falen is niet erg. Er zijn veel bedrijven die falen. Dat maakt ruimte voor concurrentie. Uiteraard.

[.oisyn]

Ik denk zelf dat @freewayorange12 een beetje gemismodereerd wordt hier omdat het ergens wel klopt dat in het algemeen software ontwikkelaars zo werken.

Wow, waanzin. Ik verwacht dat van amateurs of slecht opgeleide devs. Misschien dan dat dat nogal afhangt van je vakgebied? Ik kan je eerlijk zeggen dat in de ongeveer 20 jaar tijd dat ik in de gamesindustrie actief ben, het aantal keren dat ik een stuk 3rd party code heb gecopypaste op 2 handen te tellen is. 99% van de code die ik geschreven heb is from scratch geschreven of zijn aanpassingen aan bestaande systemen. En ik durf wel te stellen dat dat voor vrijwel al mijn collega's geldt.

De keren dat je dan een keer wat code overneemt dan is dat meestal van code examples die interacteren met API's waar je nog niet eerder mee gewerkt hebt.

[Reactie gewijzigd door .oisyn op 23 juli 2024 00:24]

[Verwijderd]

Maar ik denk dat de manier waarop jij telt of je al dan niet gecopypaste hebt anders is dan mijn manier.

De variabele-namen wijzigen of de functie-namen wijzigen is niet voldoende om te praten over from scratch. Zelfs herstructureren is dat niet. Niet in mijn ogen.

In die zin, in die interpretatie, heeft de (naar mijn mening) gemismodereerde @freewayorange12 een punt. Wij, programmeurs, kopiëren veel en zelfs heel erg veel. Maar ik vind daar zelf weinig verkeerds aan. Het is zelfs zo dat ik als jongeling, zo'n twintig jaar geleden, bij de open source en free software movements toetreede opdat ik anderen hun code zou kunnen kopiëren. Maar ik zou hun code en hun ideeën ook verbeteren en ik zou mijn ideeën met hen ook bediscussiëren.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:24]

[.oisyn]

Maar ik denk dat de manier waarop jij telt of je al dan niet gecopypaste hebt anders is dan mijn manier.

Ik denk eerlijk gezegd dat wij er hetzelfde over denken, maar dat jij dus inderdaad werkelijk heel wat sourcecode kopiëert, en blijkbaar vindt dat dat een normale manier van werken is . Dat herken ik echt totaal niet.

De variabele-namen wijzigen of de functie-namen wijzigen is niet voldoende om te praten over from scratch. Zelfs herstructureren is dat niet. Niet in mijn ogen.

Nee natuurlijk niet. From scratch gaat sowieso niet samen met "wijzigen", want dat laatste impliceert dat er al iets was, en dus is het niet from scratch. From scratch code schrijven is op z'n allerminst een geheel nieuwe functie intypen, maar liever trek ik de scope wat groter dan dat en gaat het om een compleet nieuw (sub)systeem.

[Reactie gewijzigd door .oisyn op 23 juli 2024 00:24]

[Verwijderd]

Mijn kopieëren heeft meer te maken met een open source library te gebruiken dan dat ik code effectief copy-paste. Want heel vaak mag het copy-pasten niet van het bedrijf waarvoor ik code schrijf (zoals het geval bij mijn huidige klant).

Maar ik vind van dat kopieëen niet dat het zo vies is als wat jij er van maakt: code die werkt is code. Punt. Herken jij wat jij wil.

Wat veel belangrijker is, en ook de essentie van wat ik probeer te zeggen, is architectuur. Je reageert op dat ik aangeef dat een OpenAI nog niet zo snel een MVVM architectuur zal optrekken.

Dus waarom doorgaan over code snippets en code copy-pastes van een paar blokken code, die er doorgaans niet toe doen. Architectuur doet er toe. Zoals hoe Tiësto's's events niet over een halve minuut muziek gaan, maar wel over de hele avond. Hoewel zijn halve minuten ook gewoonweg belachelijk goed zijn (afhankelijk van je muziekvoorkeur, uiteraard)

[.oisyn]

Maar ik vind van dat kopieëen niet dat het zo vies is als wat jij er van maakt

Geen woorden in mijn mond leggen aub, ik zeg nergens dat ik het vies vind. Ik herken me gewoon niet in die werkwijze. Maar ik zit (zat, sinds kort is dat iets anders) dan ook zelden in open source code. Ik kan me er gewoon geen voorstelling van maken dat als er een specifieke taak gedaan moet worden, dat je dan gaat googlen op voorbeeldcode. Met name omdat die taak die je moet doen dermate project-specifiek is, dus je gaat daar sowieso niets over vinden.

En als jij dan zegt "de meeste developers werken zo", dan ben ik het daar niet mee eens, en denk ik dat dat heel erg afhangt van het soort programmeerwerk dat je doet.

[Reactie gewijzigd door .oisyn op 23 juli 2024 00:24]

[Verwijderd]

Geen woorden in mijn mond leggen aub, ik zeg nergens dat ik het vies vind.

Akkoord

En als jij dan zegt "de meeste developers werken zo", dan ben ik het daar niet mee eens

Deels omdat dat niet is wat ik zei. Ik zei. Dat was "Wij, programmeurs, kopiëren veel en zelfs heel erg veel". Ik had het niet over hoe bepaalde ontwikkelaars werken. Ik geef je wel gelijk dat het afhangt van het programmeerwerk of er veel gekopiërd wordt of niet. Maar dan gaan we dieper in op mijn algemenere indeling die "programmeurs" was (wat waarschijnlijk te ver gaat voor dit forum).

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:24]

[.oisyn]

Nou ja je zei dit:

quote: https://tweakers.net/nieu...ction=17642406#r_17642406

Ik denk zelf dat @freewayorange12 een beetje gemismodereerd wordt hier omdat het ergens wel klopt dat in het algemeen software ontwikkelaars zo werken.

Maar goed, ik denk dat we beiden alles wel gezegd hebben wat er te zeggen valt, dus laten we het hierbij houden

[Reactie gewijzigd door .oisyn op 23 juli 2024 00:24]

[freewayorange12]

Misgemodereerd zou ik niet zeggen, het was natuurlijk low effort en kort door de bocht. maar ik denk dat jij het punt duidelijk begrepen hebt, en dan maken een paar minnetjes niet zo veel uit. Het is als een taal leren, je leert door te kopiëren en na te doen. Tuurlijk zit er veel creativiteit in het proces, en moet je ook originele gedachten kunnen vormen, maar een goed deel van het werk valt naar mijn mening onder wat ik in de eerste plaats zei.

In ieder geval is er een mooie discussie ontstaan. En nee, ik ben geen collega van je.

[joker1977]

Ik zou het nog breder trekken: Het scenario is dat de programmeur een concreet probleem heeft waar ze tegenaan lopen. Laten we als voorbeeld het sorteren van een array nemen.

Natuurlijk kun jij dan als programmeur je eigen sorteer-algoritme "bedenken". Maar in de meeste gevallen val je toch terug op al bekende sorteer-algoritmes. Waarschijnlijk zijn er ook wel (code-)voorbeelden op internet of in je eigen project beschikbaar. Die pas je aan aan je use-case en klaar.

Nu is even de vraag: Ben je een betere programmeur omdat je je eigen sorteer-algoritme bedenkt? Vermoedelijk niet, d.w.z. de meeste mensen zijn daartoe helemaal niet in staat en zouden beter af zijn met het overnemen van bestaand werk in deze.

Dat laatste stapje is m.i. waar jij nu op focussed, maar ik denk dat het op een fundamenteel niveau al een stap eerder 'fout gaat'. En juist op dát niveau zou een AI veel beter kunnen zijn, maar niet in de huidige low-level implementatie.

Ik zie deze AI-driven programmer als een 'hulpje' die je misschien op weg helpt in het code kloppen proces, maar juist het beslissen 'welke' code je moet gebruiken gaat waarschijnlijk veel vaker fout en daar kan deze AI je niet in assisteren.

[Tintel]

from scratch geschreven

Op basis van API's / libraries / frameworks van anderen dan toch?

of zijn aanpassingen aan bestaande systemen

Dus nergens volledig je eigen code... dat kan ook niet meer en is ook niet gewenst (2 keer het wiel uitvinden en zo)

[.oisyn]

Volgens mij mis je het punt een beetje. Ik beweer nergens dat het volledig je eigen code is, het ging om het copypasten van code uit een andere bron.

[Tintel]

Maar daar mis je mijn punt dus - of het nu een copy-paste is of niet - we gebruiken code vanuit een andere bron.

[.oisyn]

Daar gaat het toch helemaal niet om? Je gaat echt volledig buiten de context van de oorspronkelijke discussie nu.

Het ging om deze AI feauture, die code voor je "verzint" op basis van wat je aan het typen bent, wat eigenlijk beschouwd kan worden als het copypasten van code van elders. Iemand maakte de opmerking dat developers sowieso al zo werken; dus code copypasten van elders. Dáár reageer ik op, omdat ik me daarin niet herken. Nergens heb ik het over louter je eigen code gebruiken, dat is iets wat jij er nu bijhaalt.

Als jij tegen een API aanpraat, dan "gebruik" je weliswaar code van anderen, maar de code die je schrijft is dan toch niet gekopieerd, of wel soms?

[koelpasta]

Ik denk dat het punt was dat als je je libraries niet gewoon helemaal reviewd het op hetzelfde neerkomt als copy-pasten, namelijk dat je geen idee hebt wat de code werkelijk doet. Een library is dan mischien wel veiliger te noemen omdat je er vanuit gaat dat het als los ding getest is door op zn minst de maker.

[Tintel]

Ik reageerde dan ook vooral op de opmerking 'coding from scratch'.

Maar ik ben het verder wel met je eens hoor. Ik denk dat we op verschillende dingen reageren.

[Verwijderd]

Met enige schrik dat jij een collega bent uit mijn +20 jaar ervaring kan ik zeggen dat dat vaak klopt. Maar ik voeg daar toch ook enkele levenservaringen aan toe en bovendien pas ik die ook nog eens toe op wat mijn opdrachtgever aangaf als specificaties. Ik verdedig en stuur structurele en strategische keuzes in meetings waarvan ik denk dat ze daarvoor waardevol zijn. Vaak zit daar mijn mening in en vaak was die dan ook gevraagd. Waar ik OpenAI nog niet in zie slagen is een goede architectuur op poten zetten, een structuur geven en zulke (strategische) keuzes maken. Als je een collega van me bent (geweest) dan weet je dat ik vaak aanstuur op MVVM (Model View ViewModel) en dat dit momenteel gebruikt wordt in een vrij groot project bij mijn huidige klant (wat gelukkig sinds kort geen geheim meer hoeft te zijn): ik zie OpenAI nog niet doen wat ik voor die klant de afgelopen jaren gedaan heb.

[Katanatje]

Ik denk ook niet dat het de bedoeling moet zijn om OpenAI te vergelijken/op het niveau te zetten van een architect. Dat kan OpenAI (voorlopig) nog niet. Ik zie het als een assistentie tool die je workflow kan versnellen, maar je blijft een goeie programmeur nodig hebben om de oplossingen te controleren/finetunen. Dat kan die OpenAI niet vervangen.

Ik geloof ook dat je "flaws" in een programmeertaal niet kunt opvangen met een slimme AI, die kan hoogstens -net als ons- code schrijven die zo veilig/correct is als mogelijk. Gelukkig zijn er talen zoals rust die je weinig/minder ruimte geven om bepaalde soorten fouten te maken 😃

[Verwijderd]

Ik denk ook niet dat het de bedoeling moet zijn om OpenAI te vergelijken/op het niveau te zetten van een architect. Dat kan OpenAI (voorlopig) nog niet.

Maar iedere jonge programmeur hoort de skill architect te ambiëren. Niet eens in titel maar in vaardigheid. Want misschien zullen we hen niet allemaal zo benoemen. Maar ze horen het allemaal wel te zijn. In vaardigheid.

Ik zie het als een assistentie tool die je workflow kan versnellen, maar je blijft een goeie programmeur nodig hebben om de oplossingen te controleren/finetunen. Dat kan die OpenAI niet vervangen.

Klopt en ik ben het daar mee eens.

[codex]

Klinkt interdaad als een auto copy paste op basis van een geavanceerde zoekterm op Stackoverflow

[Tim AtSharp]

Eigenbehoud is zeer menselijk, maar zelden een goede drijfveer voor technologie.
De geschiedenis staat vol met ontwikkelingen die 'de mens overbodig maakten' - toch op dat moment. Blijkt dat we vandaag zoveel vacatures niet ingevuld krijgen. Andere inderdaad dan 'telefoonoperator-die-de-draadjes-versteekt' maar 'overbodig' is 'de mens' niet geworden.

Langs de andere kant; je zou het ook kunnen zien naar een volgende stap naar 'basisinkomen'. Dat idee steunt heel hard op automatisatie...

[Cergorach]

Andere inderdaad dan 'telefoonoperator-die-de-draadjes-versteekt' maar 'overbodig' is 'de mens' niet geworden.

Maar ook niet echt gelukkiger... ;-)

[Tim AtSharp]

dat is een andere discussie - al wordt snel filosofisch, want wat is 'geluk', en hoe meet je dat dan...?
Maar mogelijks heb je - onderbuik-gevoels-gewijs - wel gelijk.

[dog4life]

Hij heeft inderdaad mogelijk gelijk, of mogelijk ongelijk.
Ik wilde eerst 'natuurlijk mogelijk gelijk ' neerzetten, maar vanzelfsprekend dat in dit geval niet.
Is het langs de andere weg toch nog filosofisch geworden

[thatent]

Dat betwijfel ik. De naam geeft het goed weer: co-pilot. Er moet een solide basis zijn voordat deze tool iets zinnigs toe kan voegen.

[SuperDre]

Tja, copilot is het nu nog, maar het leert meer en meer en wordt alleen maar geavanceerder totdat het gewoon op basis van wat suggesties 90 tot 100% van je applicatie schrijff. Ik zie dat nog wel gebeuren, binnen 10 jaar, waarschijnlijk zelfs al 5 jaar of nog eerder.

[ShadLink]

Feitelijk kan dat al met een visuele programmeertaal. Maar het heeft altijd beperkingen.

[Tintel]

Dat is wel een behoorlijke stap - software is lang niet altijd "one [way] fits all" en ook nogal een creatief proces.
Dus: aantal mogelijkheden/combinaties is oneindig en deze AI werkt op basis van eerder gebruikte patronen - dus niet nieuw. Wel een voordeel is de strakke definitie van een programmeertaal t.o.v. natuurlijke taal (veel minder dubbelzinnigheden).

[Cergorach]

En zo helpen we onszelf de wereld uit...

De wereld zou er imho heel anders uit zien als we bezighoud jobs konden overlaten aan geautomatiseerde systemen.

[mocean]

Maar we hebben nu nog steeds mensen te kort?

[Cergorach]

Zijn dat posities die kritisch zijn voor de samenleving? Of zijn we het wiel voor de triljoenste keer opnieuw aan het uitvinden?

[langestefan]

Ik hoop het. Dan ga ik lekker niksen en mogen AI en robots al het harde werk doen. Dat is mijn ideale toekomstbeeld, helaas is het nog ver weg

[-=bas=-]

Er was eens een engineer bij Yahoo die gewoon al zijn taken liet uitvoeren in lage lonen landen :
https://www.bbc.com/news/technology-21043693

[Zer0]

En zo helpen we onszelf de wereld uit...

Hoeveel banen zijn er niet "verloren" gegaan doordat zaken geautomatiseerd zijn door programmeurs? Karma

[jjjeck]

Hoeveel banen zijn er niet "verloren" gegaan doordat zaken geautomatiseerd zijn door programmeurs? Karma

Toen ik in 1983 informatica ging studeren voorspeld een van de docenten dat we rond het jaar 2000 zoveel geautomatiseerd zouden hebben dat we met dezelfde levenstandaard nog maar 20 uur zouden hoeven te werken.

Wat ik nu zie, is dat we het drukker hebben dan ooit, wel een hogere levenstandaard hebben dan in 1983. In die 17 jaar zijn er imho veel boelshitbanen bijgekomen; tegenwoordig is de werkdruk imho zoveel hoger.

Mijn verwachting is dat wat we aan efficiency winnen, ergens wel weer verloren gaat; nog meer banen die eigenlijk niets aan de productiviteit va het bedrijf toevoegen. Verwacht dat het nog drukker wordt…

[Reactie gewijzigd door jjjeck op 23 juli 2024 00:24]

[Jeroenneman]

De tool zal vooral suggesties geven om repetitieve taken uit handen te nemen.

Ik ga ervan uit dat daadwerkelijk nieuwe slimme features nog steeds door een mens moeten worden geschreven. Ik juich het aan, want bij bijna ieder bedrijf dat ik ken is "IT" nooit snel genoeg/is net die ene functie nog nodig/willen we iets wat totaal nieuw is en gebouwd moet worden. Dan kunnen de saaie taken hopelijk uitbesteed worden aan AI, en kunnen de IT'ers weer écht aan de belangrijkste projecten werken.

[latka]

Als je als programmeur inderdaad blijft hangen op "veldje op webscherm erbij, service uitbreiden met parameter en database kolom toevoegen" dan denk ik dat het inderdaad niet lang meer hoeft te duren.

[bwerg]

En zo helpen we onszelf de wereld uit...

Want deze co-pilot heeft weet van de wijzigingen in de user requirements die doorgevoerd moeten worden?

Dit soort opmerkingen werden al gemaakt toen de eerste compilers uitkwamen. Want daarvoor waren er mensen die in assembly handmatig CPU-registertjes zaten uit te zoeken, en dat werk kwam nu te vervallen, dus die mensen zouden daarna vast niks meer te doen hebben. Dat je met die compilers juist alleen maar meer programmeerwerk op de hals haalt omdat de grenzen van het programmeren gewoon verlegd worden, dat had men schijnbaar even niet voorzien.

Ja, als je programmeerwerk bestaat uit de hele dag op precies dezelfde wijze regels code copy-pasten naar een nieuwe plek, dan komt je baan misschien te vervallen, ja. Maar ik heb nog nooit een programmeur gezien die daarmee weg kwam.

[Reactie gewijzigd door bwerg op 23 juli 2024 00:24]

[ArremeR]

Alsof programmeren of werken het be-all en and-all is van het (menselijk) bestaan, het maar een minieme invulling van alle mogelijkheden; permutaties mocht je het zo willen noemen.

[Polderviking]

Prima toch.

Ik snap sowieso niet waarom we allemaal nog zo moeilijk veel moeten werken. Alles wat we nodig hebben om comfortabel te bestaan is er al lang maar 40 uur werken is nogsteeds de norm voor zelfs een bescheiden bestaan.

Hoe meer erg weggeautomatiseerd word hoe sneller we naar zaken als universeel basisinkomen ofzo moeten als mensheid.

Kunnen we misschien ooit nog eens beginnen met leven voordat je pensoensleeftijd aanbreekt en je heel veel dingen al gewoon niet meer kan omdat je gewoon versleten bent.

Tijd dat alles en iedereen weggeautomatiseerd is kan me niet snel genoeg aanbreken. Lekker doen wat je hart je ingeeft in plaats van een derde rijk maken voor een beetje vreten en je hypotheek.

[Reactie gewijzigd door Polderviking op 23 juli 2024 00:24]

[Tintel]

Klein nadeel: veel van ons entertainment hangt toch af van de inzet van mensen. Op z'n minst de creatieve uitspattingen van anderen, of dat nu film, muziek, schilderkunst is. Nu kun je stellen dat het dan geen werk is (lekker muziek maken). Maar om die muziek op een podium te laten horen moet nogal wat werk worden verzet.

Voor de rest ben ik het wel met je eens; we draaien nog steeds 40 uur terwijl de noodzakelijkheden als voedsel en onderdak al lang zijn geregeld.

[Polderviking]

Er zal altijd wel "werk" zijn in dat opzicht maar daar hoef je dus niet de totale bevolking full time voor aan het werk te hebben.

Als ik niet meer full time op een of ander kantoor hoef te zitten voor mijn vaste lasten ga ik vanzelf, allicht pro bono, andere dingen doen met mijn tijd. Voor zaken als podium opbouw worden al vaak vrijwilligers gechartered bij poppodia dus dat rolt wel door.

Rechts nederland denkt dat heel nederland alleen nog maar gaat netflixen als werk niet meer het leeuwendeel van hun tijd opzuigt maar daar geloof ik niks van. Als ik vakantie heb ben ik na 2 dagen echt wel klaar met Netflix en wil ik wat gaan doen.

[Tintel]

Ja dat is waar. Maar helaas is nu het werkvolk nog vooral werkkapitaal dus waar je X in pompt en waar X+Y of X*Y (en Y>0) uitkomt. Precies dus het effect van een kapitilastische maatschappij. Waarin dan ook nog dat zelfde volk wordt gestimuleerd tot overmatige consumptie.

[Troepje]

Dat heet automatisering, een goeie software engineer heeft als doel om alleen de dingen te doen die er toe doen, coderen is maar het laatste kleine detail van software bouwen.

[Sicco2]

Ja, Goed toch? Automatisering is per definitie werk overbodig / minder maken. Ik werk zo''n 15 jaar als Freelance programmeur, en 1 van de eerste dingen die ik altijd bij nieuwe klanten zeg is: ik hoop mezelf snel weer overbodig te maken.... Er komen altijd weer andere werkzaamheden voor terug (mits je iets kan natuurlijk ;-) )

Je hebt genoeg programmeurs die zichzelf onmisbaar willen maken, maar dat lijkt me juist niet in het belang van de klant.

[Polderviking]

Je hebt genoeg programmeurs die zichzelf onmisbaar willen maken, maar dat lijkt me juist niet in het belang van de klant.

Ook niet in het belang van jezelf als je verder kijkt dan baanzekerheid.
Als je nog jong bent snap ik wel dat je misschien belangrijk gevonden wil worden.
Maar voor elke scheve scheet wordt je op elk moment gebeld omdat je de enige bent die het antwoord heeft. Dat geeft een behoorlijke last op je (privé) leven als je bedrijf bredere draaiuren heeft dan je doorsnee kantoordag en je dus feitelijk op elk moment en in het weekend gebeld (kan) word(t)(en).
Dat wordt echt wel oud op den duur, en is een goed aangelegde, wel bereden weg richting een burn out.

[Reactie gewijzigd door Polderviking op 23 juli 2024 00:24]

[Enai]

Zo helpen we de nood om triviale code te schrijven de wereld uit. En dan is het beter dat de AI dit zou doen dan een of andere lowcode-oplossing.

[mmjjb]

Hebben ze de DMCA overtredingen al opgelost? Waarbij de AI code kopieerde van andere projecten...

[Verwijderd]

Ik heb coPilot best intensief gebruikt, en de code suggesties zijn eigenlijk nooit buiten de context van de bestanden in de IDE getreden. Natuurlijk heb je wel wat publieke boilerplate suggesties, maar daar is niets mis mee.

Nu management over zien te halen te betalen voor coPilot

Één van de meest briljante suggesties van coPilot vind ik de vertaling van een stukkie SQL in een comment naar de hele ORM structuur.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:24]

[MrHaas]

Één van de meest briljante suggesties van coPilot vind ik de vertaling van een stukkie SQL in een comment naar de hele ORM structuur.

Ja, ik ben ook nog dagelijks impressed met name over met name de testcases die hij genereert, hij is zo "aware" van de context, bijna eng.

[Draivun]

Ik heb wel een keer gehad dat ik iets wilde doen met het openen van een file in een bepaald pad, en toen kreeg ik van CoPilot de suggestie om het pad te openen vanuit C:/Users/RoelV. Ten eerste is mijn naam niet RoelV, en ten tweede zit ik op een Linux systeem

[Cergorach]

Eh... Dat is niet bewezen. Dat toevallig in een aantal gevallen de output gelijk is aan een input betekend niet dat deze code is gekopieerd van andere projecten.

Interessant artikel:
https://felixreda.eu/2021...nfringing-your-copyright/

Hoeveel optimale variaties van een stukje "Hello, World!" zullen er zijn voor een specifieke programmeer taal?

10 PRINT "Hello, World!"

Krijg jij een onvoldoende vanwege plagiaat wanneer je je eerste stukje code schrijft op dezelfde manier zoals ze je dat geleerd hebben?

[GertMenkel]

"Dat is niet bewezen"? Dat ding heeft de fast inverse square root exact overgenomen.

Er zijn andere algoritmes om dit getal te berekenen maar de variabelenamen zijn wel héél specifiek en de comments zijn onverdedigbaar.

Microsoft's verdediging is dat dit geen plagiaat is omdat een AI het verzonnen heeft en dat de AI geen afgeleid werk is.

Ik wil best wel eens zien wat er gebeurt als men zo'n AI traint op de gelekte Windows source code, het model aan een Wine-ontwikkelaar geeft en dan eindelijk implementatiebugs van Wine opeens razendsnel opgelost worden. Ik heb het vermoeden dat die verdediging dan ineens niet op gaat en de licentie dan ineens wel uitmaakt.

Edit: Microsoft's "oplossing" hiervoor was het blacklisten van de fast inverse square root functienaam dus ze weten donders goed dat dit gebeurd is.

[Reactie gewijzigd door GertMenkel op 23 juli 2024 00:24]

[Cergorach]

Ik vind het wel erg grappig, want het heeft het niet geheel overgenomen, het heeft er een andere licentie aan geplakt. Vergeet ook niet dat dit bijna een jaar oud is uit een test fase...

Hoeveel programmeurs hebben in de afgelopen 20 jaar de fast inverse square root gebruikt exact zoals deze uit de originele bron komt?

Maar het is niet 'bewezen' omdat persoon A claimt X en MS claimt Y, niemand heeft dat nog gewonnen in een rechtszaak. Een rechtszaak is wel iets wat ik verwacht hier omheen.

Maar net als recent is het verhaal over Ai dat zelf bewust zou zijn en iedereen roept, het werkt xyz, maar niemand die de code heeft ingezien... Met verwacht dat het werkt als xyz, dat is wat anders. Zo ook bij CoPilot.

Deel van het probleem is dat er over de laatste paar decennia hele hippe woorden uit het sci-fi domein gebruikt zijn en niet de originele dekking hebben meegenomen. Zoals bv. AI, alles is tegenwoordig 'AI' en er is niet veel intelligent aan. Machine learning, etc. Don't get me wrong, die materie is heel interessant en kan heel mooi worden toegepast, maar het creëert verwachtingen die niet altijd even reëel zijn...

[IJuanTM]

Je moet nu bij het subscriben aangeven of je wilt dat jouw repos worden gebruikt voor de AI code en of je ook wilt dat Copilot code geeft van anderen die daarop toestemming hebben gegeven.

[MeMoRy]

Maar dat haalt niet weg dat de bestaande AI al getraind is op basis van de openbare repositories op github zodat dat dat toestemming voor gevraagd of gegeven is. En wat vaak indruist tegen de licentie die in zijn repository staat.

[Mayonaise]

Ik vind het jammer dat een tool dat hevig gebruikt heeft gemaakt van open source repo's voor haar machine learning betalend wordt.

[pietje63]

Het bedrag valt toch best mee? En er zijn ook servers nodig om de AI / machine learning uit te voeren

[latka]

Het gaat hier niet om geld, maar het principe: Github heeft Copilot getrained op gratis data van open-source projecten zonder hier iets aan terug te geven. Dat het nu een gratis licentie is voor opensource projecten neemt niet weg dat kennis in de vorm van broncode die open-source was nu ineens een closed-source dataset is geworden. Dat is het probleem, niet dat tientje. Als ze de Windows broncode hadden gebruikt voor het trainen was het geen enkel probleem (behalve wellicht de ontzettende hoop hacks en workarounds die daar inzitten die je liever niet in je project wil).

[thePiett]

Ze geven zeker wat terug: namelijk een hosted git omgeving

[latka]

Dit soort diensten deed sourceforge al voor de CEO van Github geboren werd ;-) Dat maakt het niet ineens goed ofzo. Ze hebben niet vooraf om toestemming gevraagd voor het doel van het scannen maar puur juridisch gekeken of het mag. Er is geen ethische afweging te vinden in het geheel, maar dat is teveel gevraagd tegenwoordig.

[Soxx]

Ik zie je verschillende keren "ethisch" typen maar ik lees niet wat hier niet ethisch aan is. Gebruikers betalen voor de kennis en energie is gestoken in het ontwikkelen van een AI model dat het leven van developers net iets aangenamer maakt.

Dat AI model is getrained op publieke code, net zoals jij en ik onder andere zijn getrained door te kijken hoe code in de open source wereld is ontwikkeld. Daar verdienen we nu onze boterham mee. Is dit ook niet ethisch richting de ontwikkelaars van de open source code? Ik persoonlijk vind het alleen maar gaaf dat mijn open source code (wellicht) gebruikt wordt om dit model te trainen.

[latka]

Er zijn 2 verschillende ethischie dillema's aan copilot zoals ik het zie:
1) Copilot vult code aan op basis van een context. De informatie hiervoor is een dataset die getrained is met open-source projecten. Ergo: een deel van de code die copilot produceert is een afgeleide (derivative) van de originele bron. In hoevere is de originele licentie van toepassing op de geproduceerde code.
2) Het is niet bekend op welke code-base er precies getrained is alleen "public repositories on github". Als hier een project tussenzat met een restrictie op het gebruik in militaire toepassingen en defensie schaft co-pilot aan dan werkt de auteur van het project mee aan militaire toepassingen. Dat zal waarschijnlijk voor deze auteur niet wenselijk zijn.

Er zijn er vast nog wel meer als je nog wat invalshoeken neemt. Op punt 1 roept github dat het geen punt is op punt 2 zijn ze stil omdat ze niet vrijgeven op welke dataset er getrained is.

[wankel]

Er zijn 2 verschillende ethischie dillema's aan copilot zoals ik het zie:
....
Er zijn er vast nog wel meer als je nog wat invalshoeken neemt.

Er zijn zeker meer dilemma's!

Ik schrok wel van de titel, "Wat, gaat MS nu geld verdienen met de code die door F/LOSS-auteurs geschreven is?!"

Maargoed, zoals @Soxx ook aanvoert: een van de speerpunten van F/LOSS is juist kennisoverdracht.

De bijdrage die de copiloot levert, is het uit handen nemen van saaie stukjes werk; voor F/LOSS-programmeurs (voorlopig?) zonder kosten. Hopelijk stemt de copiloot in met de licentie die je zelf kiest...

Dat terzijde, het grotere dilemma is: verdwijnt onze (bij)baan nu? Is dit hoe kassieres zich dertig jaar geleden voelden toen streepjescodes ingevoerd werden? Of hoe tandpastatubedopjesschroevers zich zeventig jaar geleden voelden?

Voor 10 dollar per uur per maand kan ik geen code schrijven! Maar de tijd die ik overhoud door minder code te hoeven schrijven, kan ik wel aan andere dingen besteden. Nadenken over het feitelijke probleem waar ik aan werk, of een implementatie in een andere taal uitproberen.

En, aan de zonnige kant, net als met horloges, zal er vast een markt blijven voor handgemaakte code!

[langestefan]

Dat terzijde, het grotere dilemma is: verdwijnt onze (bij)baan nu? Is dit hoe kassieres zich dertig jaar geleden voelden toen streepjescodes ingevoerd werden? Of hoe tandpastatubedopjesschroevers zich zeventig jaar geleden voelden?

Je moet je gaan specialiseren, zoals dat altijd al zo is geweest. Het schrijven van code is niet moeilijk, het bedenken van écht nieuwe dingen is dat wel. Ik denk persoonlijk dat we niet ver weg zijn van een AI die volledige programma's kan schrijven. Maar iemand moet de boel aan elkaar knopen, overzicht houden, connecties maken tussen databases, software, hardware, cloud, AI etc. Dat zie ik een AI nog niet zo snel doen.

[walteij]

Daar heb je toch UML schema's voor. Dus jij en ik bedenken wat er geprogrammeerd moet worden, maken er een UML schema van, geven dit aan de AI en wensen deze veel succes.

[Soxx]

Wat betreft beide punten betwijfel ik of Copilot een nieuw probleem introduceert. Al jarenlang wordt nieuwe code gebaseerd op code die al geschreven is, in veel gevallen in open source. Het enige verschil is dat er nu een AI systeem is dat dit deels voor ons doet. Of moeten actiever zijn in nieuwe niet-co-pilot-code checken op het feit dat het al dan niet is afgeleid van bestaande code? Vergeet niet dat het hier om enkele regels tot snippets gaat, en dat er nooit volledige projecten, waar licenties op van toepassing zijn, worden overgenomen.

[langestefan]

Ik ben het niet eens met die redenering. Als ik mijn model train op 'gratis' data moet mijn model dan ook gratis zijn? En alle infrastructuur die ik als service aanbiedt eromheen ook? Zullen we dat argument eens doortrekken, Linux is gratis en opensource dus alles gebaseerd op linux moet ook gratis zijn?

[latka]

Normaal gesproken als je open-source code kopieert en het is GPL dan moet je teruggeven in de vorm van de verbeteringen die je doorvoert (Apache en MIT niet). Dat doet Github in dit model dus niet. Combineer dat met de closed-sourceness van de dataset en je weet niet eens waarop getrained is. In het verleden was er ook zoiets met de komst van internet: complete projecten die GPL waren werden achter een website gezet en dus was de GPL niet van toepassing. Gevolg: de AGPL werd gecreeerd om online diensten op basis van de GPL te verbieden. Copilot is een nieuwe wijze van hergebruik van source-code die niet voorzien werd toen de licentie bij het project gekozen werd. En de wijze waarop men copilot nu inzet betekent dus dat het geen toegevoegde waarde heeft voor de orignele projecten terwijl dat voor veel open-source projecten wel het uitgangspunt was.

En je Linux voorbeeld: zeker, als je regels kopieert uit de kernel in je eigen project dan verwacht ik wel dat je project ook GPL gelicenseerd zal zijn/worden of je moet een deal sluiten de originele auteurs.

[langestefan]

Normaal gesproken als je open-source code kopieert en het is GPL dan moet je teruggeven in de vorm van de verbeteringen die je doorvoert (Apache en MIT niet).

Welke verbeteringen? De code wordt enkel geanalyseerd. Ik durf zelfs de claim te maken dat de code niet gebruikt is, niet in de normale zin van 'code gebruiken' als in integreren in je project.

Dat doet Github in dit model dus niet.

Ze kunnen geen code 'teruggeven' want die is er niet. Wat ze wel teruggeven is het model en zelfs dat hoeven ze volgens mij niet te doen. Copilot is gratis te gebruiken voor maintainers van 'grote' open source projecten. De waarde van copilot die ze teruggeven (gratis) is de enorme productiviteitsboost. Ik werk er nu een tijdje mee en het is gewoon revolutionair, ik kan nooit meer zonder.

[.oisyn]

Ik durf zelfs de claim te maken dat de code niet gebruikt is, niet in de normale zin van 'code gebruiken' als in integreren in je project.

Ik durf die claim te pareren met een concreet tegenvoorbeeld die eerder hier al gedeeld werd, waarin een stuk GPL code verbatim (inclusief comments) wordt overgenomen, waar vervolgens de verkeerde licentie aan geplakt wordt.

[langestefan]

Ik zie het probleem niet. Die code is gesynthetiseerd, niet overgenomen.

[.oisyn]

De code is verbatim gekopiëerd. De naam die jij eraan koppelt is irrelevant. Het is niet dat als je een database maakt van allemaal stukken code, met een systeem eromheen dat kan raden welk stuk code jij nodig hebt op basis van wat je intypt, dat dat stuk code wat uit de database komt rollen dan ineens niet meer onder zijn oorspronkelijke licentie valt.

[Reactie gewijzigd door .oisyn op 23 juli 2024 00:24]

[langestefan]

Maar wat is hier nou precies het probleem, het 'kopiëren' van de code? Of het plakken van een nieuwe license? Dat van het license snap ik, maar dat is inherent aan hoe copilot werkt. Nu ik copilot een tijdje gebruikt heb denk ik dat copilot van de start regel naar boven kijkt, niet naar beneden. Dus als je een stuk code typt, wat letterlijk van alles kan zijn, dan gokt hij gewoon wat een mooie opening is op basis van de context naar boven. Die context is er niet, dan krijg je wat willekeurigs zoals hier nu te zien is.

[.oisyn]

Maar wat is hier nou precies het probleem

Dat er een stuk GPL code in je project zit zonder dat je het doorhebt, maar dat probleem erken je niet want de code is "gesynthetiseerd" (maar dat zeg je eigenlijk ook maar zonder de daadwerkelijke achterliggende implementatie van github's AI te kennen, of de exacte operaties die achter dit specifieke voorbeeld schuil gaan).

[langestefan]

(maar dat zeg je eigenlijk ook maar zonder de daadwerkelijke achterliggende implementatie van github's AI te kennen, of de exacte operaties die achter dit specifieke voorbeeld schuil gaan).

Ik werk zelf veel met AI dus ik heb wel een idee. Wat copilot doet is een vorm van generative modeling, oftwel de generatieve statistische distributie leren die de oorspronkelijke code gegenereerd heeft. Dat betekent dat we volledig nieuwe code kunnen schrijven met de kennis over de originele distributie.

Ik denk dat deze website alles goed samenvat:
https://fossa.com/blog/an...lications-github-copilot/

Dus het trainen van het model op publieke code die op GitHub staat is geen overtreding van welke licensie dan ook. Je kan echter wel een licensie overtreding begaan wanneer je hele stukken code gebruikt die duidelijk letterlijk gekopiëerd zijn. Maar ook dan blijft de grens vaag totdat een rechter hier een uitspraak over doet. We zijn inmiddels een jaar verder en er is nog geen rechtszaak geweest, goed teken

[.oisyn]

We zijn inmiddels een jaar verder en er is nog geen rechtszaak geweest, goed teken

Eerder omdat dat heel erg lastig is voor een licentiehouder om te herkennen dat een klein stukje van jouw code integraal is overgenomen. Van die fast inverse square root kun je aan de resulterende binary niet herkennen dat het origineel letterlijk een stuk GPL code was. Maar dat de overtredingen klein genoeg zijn om onder de radar te blijven impliceert natuurlijk niet dat het dan wel mag .

En wat betreft dit specifieke voorbeeld heeft Microsoft gewoon een stokje voor gestoken dat het nog een keer kon gebeuren, maar dat is natuurlijk puur pleisters plakken waar nodig.

[Reactie gewijzigd door .oisyn op 23 juli 2024 00:24]

[langestefan]

[...]
Maar dat de overtredingen klein genoeg zijn om onder de radar te blijven impliceert natuurlijk niet dat het dan wel mag

Dan hoop ik dat er snel een rechtszaak komt om meer duidelijkheid te scheppen. Tot die tijd gebruik ik gewoon m'n gezond verstand want (helaas) ben ik uiteindelijk zelf verantwoordelijk voor de code die ik deel.

[DRaakje]

Github onderhouden kost ook geld, en dat stellen ze toch ook beschikbaar voor de open source projecten?

[latka]

Als ze dat dan ook expliciet opgenomen hadden in de voorwaarden (alle source code die je publiceert zullen we gaan monetizen, we weten alleen nog niet hoe) dan was het ook geen issue. Nu is het ongevraagd gebeurt. Ik snap dat het licentietechnisch allemaal wel ok is (tenzij er een AGPL project gescanned is bijv.), maar of het nou erg netjes is. Imho niet heel erg in ieder geval. Het wordt helemaal een glijdende schaal als er projecten zijn gescanned met opensource waarbij de auteur het niet wenselijk vind dat zijn kennis ingezet wordt voor AI trainingen maar dat niet expliciet in zijn/haar licentie had staan. Dus formeel juridisch kan het, ethisch is het op zijn minst dubieus. Maar ja, het is dan ook een Amerikaans bedrijf en daar is ethiek een optie en geen onderdeel van de cultuur.

[tw_gotcha]

dat ligt helemaal aan de licentie. Ik heb zelf een opensource programma onder GPLV3. Een ander mag geld verdienen met mijn programma, maar mag het programma zelf niet verkopen of inbouwen in betaalde software, zonder dat mijn deel open blijft. Dus in die zin mag github dit best doen. Voor de kennis die nodig is om mijn programma te maken door de jaren heen kan ik niks rekenen, tenminste niet onder de licence die ik eraan gehangen heb (tenzij je me inhuurt). Sommige zullen een creative commons licence gebruiken daar zit wat meer intellectual property rights op (ik ben niet super thuis in alle vershcillen trouwens).

[YGDRASSIL]

Maar copilot in gebruik bij een closed source project zou dus flinke stukken van jou code kunnen pasten als suggestie zonder enige link met de bron of licenties.

[tw_gotcha]

formeel niet maar dat is natuurlijk niet te handhaven. De code moet een geheel blijven en als er iets aan veranderd wordt moet dat ook weer open source zijn. Uiteindelijk is het een principe waarvan je hoopt dat anderen dat in waarde laten. Ik werk bij een universiteit en heb dit (een integraal overstromings en erosie model) over de jaren ontwikkeld met gemeenschapsgeld en ik vind dat het opensource moet blijven. De wetenschappelijke principes zijn niet uniek, dat komt ook deels van wat anderen gevonden hebben dus er is ook eigenlijk niks geheims aan. En ik heb er zat aan verdiend (of in ieder geval mijn vagroep) aan het gebruik van die software in onderzoeks en consultancy projecten. Het verdienmodel is de software gebruiken, en niet de software verkopen (en moeten ondersteunen en dergelijke). Dat het opensource is draagt bij aan de goede reputatie. Dat bevalt me prima.

[Loller1]

Als die open source projecten niet wouden dat hun code daarvoor gebruikt werd dan hadden ze dat gewoon in hun licentie moeten opnemen.

Niks principe, wat Copilot hier doet met die data is gewoon wat die licenties toestaan. Dat je een open source project gebruikt wilt nog niet zeggen dat je er automatisch ook aan moet terug geven; opnieuw: dat had dan maar in de licentie moeten staan. Letterlijke forks moeten nog niet eens teruggeven aan een project, waarom zou iets dat het project gewoon leest dat wel moeten doen? Omdat het in een dataset wordt opgenomen? Laat me niet lachen.

Het is een beetje absurd als open source projecten altijd met hun licentie zitten te schermen - en terecht - en dat de "licentie wet is". Nu is er plots een gebruik van hun code die hun niet zint maar wel gewoon mag volgens de licentie en plots is het niet eerlijk want "principe". Principe zegt dat wat de licentie zegt wat wel en niet mag is wat wel en niet mag. En wat blijkt: copilot doet hier niets dat open source licenties verbieden.

[watercoolertje]

Zonder er iets aan terug te geven? Copilot is tot op heden iig nog gratis (of telt dat niet?) en blijft dat voor bijdragers aan grote open source projecten (telt dat ook niet?). En je kunt er gratis openbare en (in 99%) open source git-repositories hosten (telt dit ook al niet?) .

Je kan misschien stellen dat ze niet genoeg terug doen (waar ik het niet mee eens ben) maar dat je stelt dat ze niks terug doen is nogal vreemd voor een voor gemiddeld gebruik gratis platform.

[Reactie gewijzigd door watercoolertje op 23 juli 2024 00:24]

[latka]

Er is nogal een verschil tussen gratis en open. Open is imho belangrijker dan gratis. Dus alles wat ze gratis doen vind ik niet zo relevant en 1-op-1 vervangbaar. Open heb je op de lange termijn meer aan dan gratis.

[MeMoRy]

Achteraf gezien was het natuurlijk een grote rode vlag dat Microsoft github kocht.
Maar ze hadden op z'n minst vantevoren aan moeten geven wat hun intenties waren. Ethisch gezien, en eigelijk ook wettelijk, omdat de code licenties had. Fair use is natuurlijk onzin

[j1b2c3]

Een mens moet nog steeds de code schrijven bij houden updaten en supervisie houden. Voor het zelfde geld schrijft de sofware overal een back door in.. Dat wil je ook niet . of dat de Ai te slim sordt dat wil je ook niet. Computers kosten trouwens ook geld. Tevens voor contributors is het gratis. Alleen mensen van buiten af zullen moeten betalen en dat vind ik een prima iets. Ook vragen ze niet de hoofdprijs een tientje in de maand . peanuts .

[Cergorach]

Ik vind het jammer dat een tool dat hevig gebruikt heeft gemaakt van open source repo's voor haar machine learning betalend wordt.

Sinds wanneer betekend Open Source, niet betalen? Dat is vaak een misvatting van heel veel mensen als ze naar open source kijken, afhankelijk van de licentie, is iemand ook gewoon vrij om er geld voor te betalen.

Daarnaast mag het dan naar (voornamelijk) open source repo's hebben gekeken, maar dat is niets anders dan dat jij en ik wat leren uit een programmeer boek of YouTube filmpje. Wij kunnen en mogen ook gewoon naar de open source repo's kijken en daar van leren. In dit geval heeft dat helemaal niets met open source te maken.

[bones]

Zou pas gaaf zijn als je de AI een figma link zou kunnen geven, en dat die deze omzet in code.

[latka]

Je bedoelt case-tools. Dat was in de jaren 80 populair. Het probleem was steeds dat de expressiviteit van de tekentools te laag was om alle nuances weer te geven en het een drama is om in gegenereerde code te prutsen. Dat zal co-pilot niet oplossen: gegenereerde code blijft troep om te onderhouden.

[kris-kraslot]

Je bedoelt iets als Pygma?

[Henk1827]

Sinds een jaar heb ik ook meegedaan aan de preview. Heel cool wat het allemaal kan. Maar uiteindelijk moet je toch nog zelf controleren of de code klopt. Voor simpele algoritmes is het heel handig, maar met b.v. een custom stukje business logica zal Copilot je niet kunnen helpen. Na een tijdje gebruiken vond ik het alleen maar in de weg zitten. Het opschrijven van de code is vaak niet het lastige, maar het uitdenken wat je precies wil.

Voor nog-niet-zo ervaren ontwikkelaars heeft het evt. meerwaarde, omdat het snel voorbeeldcode genereert. Dat scheelt je een zoekopdracht op Stackoverflow.

[Ascathon]

Daarom vraag ik me af waar die 40% op gebaseerd is. Dat vind ik wel heel erg hoog. Ook als je kleine autcompletes meetelt. Sowieso was ik daar al typende de suggestie al lang voor, ik ga daar niet op wachten.

[KeesAlderlieste]

Ik werd er gestoord van... Elke keer als Resharper een suggestie deed die ik OK vond kwam net Copilot er net tussendoor en reageerde die dan op mn <Tab> ipv Resharper en kreeg ik een heel blok ongewenste code. Voor zover ik kon zien was die toets voor Copilot niet te wijzigen. Dus maar uitgezet..

[Ascathon]

Daarom had ik deze ook al uitgezet. Maar daarnaast zit de nieuwe Intellicode mij op dezelfde manier in de weg met suggesties.

[KeesAlderlieste]

Idd, die is er ook nog, maar op de e.o.a. manier minder hinderlijk.
Copilot kwam een aantal keer met een slim stuk code dat ik dacht, 'hoe 'weet' ie wat ik wil??', maar nu die uit staat mis ik 'm niet. De preview dus verwijderd, ga er niet voor betalen.

[RobinR_]

De tool heeft mij best vaak op weg geholpen. Denk dat het zeker waard is als het je werk is, en er dus de hele dag mee bezig bent. Gelukkig ben ik nog voor een jaartje student

[Sumerechny]

Is het nog relevant om te benoemen dat naast studenten ook medewerkers (docenten, onderzoekers) van onderwijsinstellingen toegang hebben tot de gratis versie?

https://education.github.com/ --> Benefits