Habe gehört das Github so etwas hat, was automatisch Code schreiben kann, aber nicht gut genutzt werden kann, wegen dem Urheberrecht, weil dieses Tool die?
Datenbank von Github oder so nutzt und es dort auch geschützten Code gibt oder so.
Schön, dass du das gehört hast.
Wie lautet deine Frage dazu?
wie das heißt.
2 Antworten
Das ist Github Copilot.
Wurde zwar schon vor Monaten zur Preview eingeladen, anscheinend wollen die mich aber doch nicht.
Wie auch immer: Ich bevorzuge es trotzdem, meinen Code selber zu schreiben.
Was Urheberecht angeht: Das ist bisher eine Grauzone. Nur, weil ein Stück Code öffentlich auf Github einsehbar ist, heisst das längst nicht, dass der auch einfach so genommen werden darf. Möglicherweise wurde gar keine Lizenz definiert, dann liegen alle Rechte beim Autor. Andere Parteien haben erstmal keine Rechte daran.
Bei GPL-lizenziertem Material müsste man das Ergebnis (ja, auch das trainierte KI-Modell) dann ebenfalls wieder unter der GPL veröffentlichen. Die verschiedenen Codesnippets werden ja miteinander vermischt und somit modifiziert. Das ist zumindest meine Meinung dazu, die rechtliche Lage ist unklar.
Naja, er wird genommen und auf Basis davon irgendwas neues zusammengewürfelt. Meiner Ansicht nach fällt dies unter das Copyleft.
Das muss dann wohl ein Gericht entscheiden - sollte das ein Problem werden.
GitHub Copilot
Ich bezweifle, dass das auf private Projekte zugreift.
Und alles was öffentlich ist, darf auch öffentlich genutzt werden.
Und ich finde, dieses Tool taugt höchstens zu einem lustigen Gag, wenn ich darüber entscheiden dürfte und jemand würde es nutzen - ich würde es verbieten. Und wenn nicht - ich würde den Entscheidern sehr ausführlich erklären, warum sie es verbieten sollten ^^
ich würde den Entscheidern sehr ausführlich erklären, warum sie es verbieten sollten
Dann füge dies bitte deiner Antwort bei, dein Standpunkt bestückt mit Argumenten würde mich sehr interessieren. Was ist deiner Meinung nach so schlecht daran?
Der Code trifft in den seltensten Fällen wirklich das, was man braucht, sondern kommt nur in die Nähe - wenn man Glück hat. Und es verleitet dazu, den erzeugten Code als Arbeitsersparnis zu sehen, was aber nicht der Fall ist.
Ich habe schon viele Leute gesehen, die ohne nachzudenken fremden Code kopieren und übernehmen. Beim GitHub Copilot ist das nicht anders, es wird nur noch einfacher.
Jeder Entwickler sollte den Code, den er eincheckt, Punkt für Punkt verstanden haben, er sollte den Code der eigenen/vorgegebenen Guideline und den eigenen/vorgegebenen Qualitätsanforderungen anpassen. Vor allem sollte der Code aber exakt das widerspiegeln, was das Ziel ist und nicht nur etwas Ähnliches, das nur das gleiche Ergebnis liefert.
Der Entwickler sollte sich den Code also nochmal anschauen, ihn überarbeiten und für das eigene Ziel anpassen, das frisst allerdings wiederum die Zeitersparnis auf und der Entwickler hat keinen Lerneffekt vom selber Erarbeiten der Lösung. Und es bleiben wahrscheinlich immer noch Einflüsse vom Original, die in dem Projekt aber unter Umständen gar nicht gewollt oder notwendig, vielleicht sogar schädlich, sind.
Meiner Erfahrung nach enden solche Zeitersparnisse immer darin, dass sie hinterher mehr Zeit kosten, als man anfangs gespart hat.
Außerdem ist Erfahrung alles, der eben angeschnittene Lerneffekt ist sehr viel wert, aber genau den nimmt man sich damit. Ist wie mit allen kreativen Tätigkeiten, Du wirst selber nicht besser, wenn Du die Werke von Anderen nachmachst. Du wirst besser im Nachmachen, aber die meiste Zeit wirst Du eben nicht nachmachen können.
Vielleicht gibt es ein paar Fälle, wo das nützlich ist, aber dann sind die paar Fälle entweder so klein und einfach, dass der Vorteil über die Laufzeit des Projektes kaum auffällt, oder es wäre besser, nach explizit dafür entwickelten Frameworks zu suchen, die bewusst für die Verwendung in fremder Software entwickelt wurden und im Idealfall auch noch gut dokumentiert und getestet sind.
Wenn es extra dafür geschriebene Frameworks nicht gibt, würde ich eher dazu raten, fremde Lösungen zu suchen und durchzuarbeiten, aber nicht blind zu übernehmen. Stattdessen sollte man das dadurch Gelernte in eine eigene Implementierung fließen lassen, das das dauert vielleicht etwas länger, aber man lernt dabei mehr, als wenn man es nur abschreiben würde.
Oder, wenn es nicht zu komplex ist, man übernimmt sie, aber überarbeitet sie entsprechend.
Also ja, vielleicht ist "verbieten" das falsche Wort, aber "abraten" würde ich für produktive Projekte in jedem Fall.
Danke für dein ausführliches Feedback, aber dem bleibt entgegenzuhalten:
Ist das Lernen mittels Büchern mit Codebeispielen nicht genauso? Welcher Entwickler hat noch nie einen Lösungsansatz "ergooglet", kopiert und schlicht für seine Zwecke angepasst? Welcher Entwickler hat noch nie eine Funktionalität aus einem seiner vorherigen Projekte übernommen und entsprechend den Spezifikationen für das neue Projekt modelliert?
Wo genau ist da der Unterschied? Ja, die Lösungen mögen sehr selten das treffen, was man wirklich braucht, von vielleicht absoluten Basics mal abgesehen, aber wer greift heute nicht mehr zum Buch oder recherchiert online und arbeitet mit dem was er findet, statt das Rad jedes mal gänzlich neu zu erfinden?
Es geht nicht darum, dass man nichts nachliest oder "ergooglet", sondern dass dabei das mMn. absolut notwendige Anpassen für die eigene Situation zu kurz kommt. Und dass das sehr oft so abläuft, weiß ich aus eigener Erfahrung und ich befürchte, dass das mit dem GitHub Copilot nur noch schlimmer (weil einfacher) wird.
Ich habe auch schon fremden oder alten eigenen Code kopiert, aber ich habe ihn immer (!) überarbeitet, manchmal sogar regelrecht neu geschrieben, damit er am Ende auch genau das widerspiegelt, was ich brauche.
Und bei alten eigenem Code bleibt der Lerneffekt ja nicht auf der Strecke.
Der Name "Co Pilot" wurde nicht umsonst gewählt. Es soll nur unterstützen und nicht ersetzen. Ich sehe hierbei keinen Unterschied, als wenn ich eine Lösung ergoogle oder aus einem Buch abschreibe.
So lange ich den Code verstehe und entsprechend meiner Bedürfnisse anpassen kann, sehe ich darin nichts schlechtes.
Ich verstehe deine Befürchtung, aber die bleibt ja mit oder ohne diesem Tool bestehen. Script Kiddies wird es immer geben, die sich mehr schlecht als recht einen Code zusammenschustern und sich dann als Entwickler oder gar "Hacker" darstellen.
Ich persönlich habe aber nichts dagegen einzuwenden, wenn ein Programm einem Entwickler Vorschläge für eine Funktion/Methode liefert. Genauso wenig, als wenn eine KI neben dem Arzt mein Röntgen-Bild auswertet und dadurch ggf. viel schneller etwas entdeckt wird, was sonst zur tödlichen Krankheit mutiert wäre.
Der Name "Co Pilot" wurde nicht umsonst gewählt. Es soll nur unterstützen und nicht ersetzen.
Was es soll und was es am Ende ist, ist nicht unbedingt das gleiche ;)
Ich habe eben schon viele gesehen, denen ich genau das zutraue, dass sie es eben nicht als Unterstützung verwenden, sondern den Code so weit wie möglich übernehmen, ohne ihn anzupassen. Meiner Erfahrung nach ist das nicht Mal eine Ausnahme.
Natürlich hat man das Problem bei einem Buch auch, aber aus einem Buch kann man den Code nicht einfach kopieren.
Und ja, auch bei einem Forum hat man dieses Problem, aber Foren kann und will ich nicht verbieten.
Also nein, es ist nicht mehr oder weniger schlecht, als andere Quellen, aber es ist eine weitere Quelle, die noch einfacher ist und noch stärker "Hier, ich nehme dir deine Arbeit ab" schreit, als ein Forum oder ein Buch es je sein könnten.
Ich persönlich habe aber nichts dagegen einzuwenden, wenn ein Programm einem Entwickler Vorschläge für eine Funktion/Methode liefert.
Ich auch nicht - solange der Code am Ende die gleiche Qualität hat, wie ohne diesen Vorschlag. Oder die Qualität ist besser, aber davon gehe ich nicht aus.
Und wie gesagt: Meiner Erfahrung nach ist das nicht der Fall und dieses Tool macht das unbedachte Übernehmen von fremden Code nur noch einfacher, als es sowieso schon ist.
Vorschläge findet man auch in Foren und da sind dann im besten Fall auch noch Erklärungen, Erfahrungen und potentielle Probleme aufgeführt, die man beim einfachen Übernehmen des Codes (macht das Tool ja automatisch) nicht hat.
Meiner Erfahrung nach ist das nicht Mal eine Ausnahme.
Das mag ja durchaus sein. Es gibt auch Leute, die benutzen ihren Computer für kriminelle Machenschaften! Wenn wir Mobbing, Hate-Spread und sonstige äußerst fragwürdige Online-Aktivitäten hinzuzählen, vermutlich sogar die Mehrheit - oftmals ohne sich dessen bewusst zu sein.
Deswegen sollten wir den Computer, oder das Internet aber doch nicht schlecht reden. Wenn wir jede Entwicklung stoppen würde, nur weil man es auch für schlechtes nutzen kann, gäbe es keinerlei Fortschritt mehr!
Ich verstehe deinen Gedanken dahinter, denke aber nicht, dass es ein Problem ist, was nur durch bzw. erst durch den Co Pilot entsteht bzw. entstanden ist.
Es ist ein generelles Problem der Benutzer, nicht des Tools.
Du vergleichst hier Äpfel mit Birnen.
Um auf dem "Radikalitäts-Level" (PC verbieten > Tool verbieten - verstehst Du, was ich meine) zu bleiben, müsste ich den Entwicklern ebenfalls den Computer verbieten, nicht nur das Tool, und das ergibt natürlich keinen Sinn.
Bei deinem Beispiel würde eher passen, wenn ich ein Verbot von bereits entwickelten Hacking-Tools fordern würde und dann sieht das gleich deutlich weniger "radikal" aus.
Es ist ein generelles Problem der Benutzer, nicht des Tools.
Natürlich, aber das Tool bietet für ein produktives Projekt mMn. keinen relevanten Nutzen, es fördert nur das generelle Problem der Benutzer und das macht das Tool mMn. ablehnenswert.
Ob man das nun verbieten, oder lieber den Benutzern das nötige Wissen beibringen sollte, ist ein anderes Thema, aber daher habe ich eingangs schon geschrieben:
Also ja, vielleicht ist "verbieten" das falsche Wort, aber "abraten" würde ich für produktive Projekte in jedem Fall.
Ich persönlich würde lieber das Tool erlauben, thematisieren und den Leuten das nötige KnowHow beibringen, aber das kostet viel Zeit, die meiner Erfahrung nach irgendwie immer fehlt, aus den verschiedensten Gründen.
Da die bessere Option (außerhalb meiner Kontrolle) nicht in Frage kommt, bleibt also nur noch das Verbot. Verbote sind unschön, aber zumindest in der Softwareentwicklung durchaus anzutreffen.
Z.B. habe ich Mal in einer Firma gearbeitet, da war es verboten ohne ReSharper zu arbeiten, nicht weil der Entwickler sonst schlechteren Code produziert hätte, sondern weil es einfach häufiger vorkam, dass Guidelines nicht eingehalten wurden, während man es mit ReSharper erzwingen konnte.
Das mag man nicht exakt vergleichen können, aber auch hier gibt es keinen technischen Grund für oder gegen ReSharper (man kann die Guidelines ja auch ohne ReSharper einhalten), sondern Erfahrungswerte, die gezeigt haben: Die Vorschrift sorgt für ein langfristig besseres Team-Ergebnis.
wenn ich ein Verbot von bereits entwickelten Hacking-Tools fordern würde und dann sieht das gleich deutlich weniger "radikal" aus.
Okay, wenn du einen besseren Vergleich suchst, dann denke an die Anfänge von z. B. IDEs zurück. Ich kann mich noch an den Aufschrei einiger Entwickler erinnern, die meinten die Qualität von Software würde nachlassen, weil damit zu viel Automatisierung einhergeht.
Und während ich natürlich jedem nahelegen würde, das Programmieren ohne IDEs zu lernen, so vermisse ich nicht die Zeiten, als ich quasi alles noch selbst von Hand machen musste, du etwa?
So muss man dieses Tool ansehen. Und nur weil es genügend Leute gibt, die ohne ausreichende Coding Skills sich eine IDE zur Hilfe nehmen, sollte man diese doch nicht aus den Programmier-Schmieden verbannen oder auf irgendwelche schwarze Listen setzen, oder?
Natürlich, aber das Tool bietet für ein produktives Projekt mMn. keinen relevanten Nutzen,
Wenn das deine Meinung diesbezüglich ist, ist das ja auch okay. Gibt vermutlich auch noch eine Hand voll anderer Entwickler, die das ähnlich sehen. Es gibt aber auch ausreichend Befürworter, denen man keine mangelnde Kompetenz oder ähnliches vorwerfen könnte.
Danke für die Diskussion.
Okay, wenn du einen besseren Vergleich suchst, dann denke an die Anfänge von z. B. IDEs zurück.
So alt bin ich nicht ^^
So muss man dieses Tool ansehen. Und nur weil es genügend Leute gibt, die ohne ausreichende Coding Skills sich eine IDE zur Hilfe nehmen, sollte man diese doch nicht aus den Programmier-Schmieden verbannen oder auf irgendwelche schwarze Listen setzen, oder?
Natürlich nicht, aber die IDE bietet noch eine Menge andere Vorteile.
Es gibt aber auch ausreichend Befürworter, denen man keine mangelnde Kompetenz oder ähnliches vorwerfen könnte.
Ich meine das nicht auf mangelnde Kompetenz bezogen, sondern auf den tatsächlichen Nutzen:
- Zeitersparnis
- Unterstützung durch z.B. Hinweise oder Ideen
Die Zeitersparnis geht flöten, da man - da scheinen wir uns ja einig zu sein - den Code sowieso nochmal überarbeiten muss. Ob das nun länger dauert, als selber zu schreiben, oder nicht, ist vermutlich je Situation verschieden, aber generell dürfte die Ersparnis deutlich geschmälert werden.
Und Unterstützung durch Hinweise oder Ideen erlangt man mit genug Übung im Umgang mit Suchmaschinen auch relativ schnell. Außerdem erhält man zusätzlich noch weitere schriftliche Ergänzungen, Warnungen, Erklärungen, Kommentare, etc. - in Summe als mehr, als so ein Tool (aktuell) bieten kann.
Oder haben ich einen dritten Vorteil übersehen?
Ich meine das nicht auf mangelnde Kompetenz bezogen, sondern auf den tatsächlichen Nutzen:
Die Zeitersparnis und der potentielle Nutzen von IDEs hielt sich am Anfang auch stark in Grenzen. Es hat sich erst im Laufe der Jahre und Jahrzehnte so weit entwickelt. Und gerade als professioneller Entwickler müssen dir doch die zwei folgenden Tatsachen vollkommen klar sein:
- Programmieren mit KI Support war nur eine Frage der Zeit und eine logische Konsequenz der technischen Entwicklung
- Alles braucht Zeit und konsequenten Support um sich zu rentieren. KI noch mehr als als Menschen, da es eben auf Deep Learning angewiesen ist und keine Intuition kennt.
Wenn wir an das erste Auto zurückdenken, hatte das auch kaum einen nennenswerten Vorteil gegenüber Pferden. Es gab keine sinnvollen Straßen, man kam nicht früher an, es gab keine Tankstellen, usw. Es war nicht wirklich effektiv!!
Trotzdem würde heute kaum noch jemand die Revolution bestreiten, welche die motorisierte Mobilität ausgelöst hat oder deren Nutzen in unsere heutigen Gesellschaft in Frage stellen.
Ich denke, es ist nur noch eine Frage von 10-15 Jahren, bis man quasi nur noch mit KI programmiert und nur eingreift, wo es nötig ist.
Ich denke, es ist nur noch eine Frage von 10-15 Jahren, bis man quasi nur noch mit KI programmiert und nur eingreift, wo es nötig ist.
So betrachtet - ok.
Aus wirtschaftlicher Sicht ist der Nutzen aktuell extrem weit entfernt und Firmen, die nicht aktiv in dem Bereich arbeiten, können weder aktiv daran arbeiten oder auf andere Weise davon profitieren.
Daher sehe ich darin als Entwickler aktuell nur Nachteile, die den aktuell sehr beschränkten Nutzen überwiegen. Die Projekte haben Deadlines und die Kunden bezahlen für die Software und für gute Qualität (naja, sie erwarten es zumindest), nicht für Experimente, die vielleicht in 10-15 Jahren die Arbeit vereinfachen könnte.
Also wenn tatsächlich jemand das Geld dafür bietet, dass ich diesem Tool Zeit einräume und dann in dieser Zeit auch alle negativen Auswirkungen beseitige, dann bin ich bereit, ihm eine Chance zu geben. Bis dahin ist es ein potentielles Problem, das kaum Vorteile bietet.
Oder die Entwicklung wird in den nächsten Jahren besser, dann denke ich gerne nochmal darüber nach.
Und bevor Du jetzt argumentierst, dass nach dieser Denkweise gar keine Entwicklung stattfinden würde:
Doch, würde es.
Es wird Firmen oder Privatpersonen geben, die daran arbeiten (gibt es ja heute schon), aber es muss nicht jeder aktiv daran teilhaben.
Und was die Leute privat tun, ist immer noch jedem selbst überlassen.
aber es muss nicht jeder aktiv daran teilhaben.
Behaupte ich auch nicht, ich bin nur weit davon entfernt zu sagen, dass man es verbieten sollte!
Ich sehe derzeit auch noch zu viele Baustellen, als dass man es professionell einsetzen könnte, aber wie gesagt: Nur eine Frage der Zeit, bis es in diesem Bereich einzieht und die zukünftige Entwicklerarbeit vereinfacht und verkürzt, potentiell sogar die Qualität ggf. verbessert.
dass man es verbieten sollte!
Du glaubst, ich würde es generell verbieten wollen?
Das natürlich nicht, nicht generell.
Aber in einem Team, das damit nicht umgehen kann, kann ein Verbot durchaus eine Option sein.
Soweit ich das verstanden habe, wird der Code doch nicht "einfach so" übernommen, eher Bruchstücke mit Anpassungen je Situation?
Genau geprüft, wie das Ding arbeitet, habe ich allerdings nicht, ist also nur meine bescheidene Interpretation.