MeshCore-Entwicklerteam spaltet sich wegen Markenrechtsstreit und Problemen mit KI-generiertem Code

 (blog.meshcore.io)
1 Punkte von GN⁺ 5 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • In dem schnell gewachsenen Mesh-Networking-Projekt überlagerten sich Probleme rund um eine Markenanmeldung und die Nutzung von KI-generiertem Code, was zur Trennung zwischen dem core team und Andy Kirby führte
  • Andy Kirby nutzte Claude Code umfassend und erweiterte seine Arbeit auf Standalone-Geräte, mobile Apps, einen Web-Flasher und ein Web-Konfigurationstool; das Team schreibt, ein erheblicher Teil dieser Arbeit sei als vibe coded entstanden und dies sei verschwiegen worden
  • Der unmittelbare Auslöser der Trennung war laut Team, dass Andy am 29. März die MeshCore-Marke anmeldete, ohne das Team zu informieren; spätere Gespräche über seine Absichten scheiterten, und inzwischen ist die Kommunikation abgebrochen
  • Das core team hat das offizielle MeshCore als die einzige source of truth festgelegt, die durch das GitHub-Repository definiert wird, und setzt Firmware-Entwicklung, App-Releases, technische Dokumentation und Entwicklerdiskussionen nun rund um den neuen Hub meshcore.io fort
  • Seit dem Start im Januar 2025 wurden auf der offiziellen Map mehr als 38.000 Nodes und in der offiziellen App mehr als 100.000 aktive Nutzer erreicht, weshalb eine klare Abgrenzung der offiziellen Informationsräume und Verantwortlichkeiten noch wichtiger geworden ist

Hintergrund der Trennung

  • Das MeshCore-Entwicklerteam hat seit Projektbeginn mehr als 85 Releases von MeshCore Companion, Repeater- und Room-Server-Firmware veröffentlicht und unterstützt über 75 Hardware-Varianten
  • Das Team habe gegenüber KI-generiertem Code stets eine vorsichtige Haltung eingenommen, doch Andy Kirby habe Claude Code umfassend eingesetzt und begonnen, unabhängig zu agieren; dabei habe er den Umfang seiner Arbeit auf das gesamte MeshCore-Ökosystem ausgeweitet, einschließlich Standalone-Geräten, mobiler Apps, Web-Flasher und Web-Konfigurationstools
  • Laut Team habe Andy Kirby verschwiegen, dass der Großteil dieser Arbeiten in Form von vibe coded entstanden sei
  • Das Team führte auf dem MeshCore-Discord eine Umfrage zum Thema KI und Vertrauen durch, im Text werden jedoch keine Zahlen oder Detailergebnisse genannt
  • Als konkreter Auslöser der Eskalation heißt es, Andy habe mit Datum vom 29. März die MeshCore-Marke angemeldet und das Team darüber nicht informiert
    • Das Team habe seine Absichten besprechen wollen, doch die Gespräche seien gescheitert; derzeit gebe es keinen Kontakt mehr zu Andy
  • Das Team habe in den vergangenen Monaten versucht, das Problem zu lösen; für ein Team, das lange an dem Projekt gearbeitet habe, sei es ein schwerer Schock gewesen und habe sich angefühlt, als hätte sich eine interne Person mit Robotern und Anwälten zusammengetan

Offizielles MeshCore

  • Im Zentrum des aktuellen Streits steht das Recht zur Nutzung der Bezeichnung „official“; Andy behaupte nachdrücklich, die Marke zu besitzen, und verwende diesen Ausdruck aktiv für die MeshOS-Linie
  • Das Team definiert das einzige offizielle MeshCore als das GitHub-Repository
    • Dieses Repository fungiert als source of truth, die festlegt, was MeshCore ist
    • Andy hat nie zu diesem Repository beigetragen
  • Nach der internen Trennung hat das Team meshcore.io als neue Basis eröffnet; da Andy meshcore.co.uk und den ursprünglichen Discord-Server kontrolliert, habe es kaum andere Optionen gegeben
  • Nach dem Start der neuen Website habe Andy mit Claude sogar deren look and feel kopiert; auch die Bitte, dies zu unterlassen, sei ignoriert worden

Projektwachstum

  • MeshCore ist seit dem Start im Januar 2025 sehr schnell gewachsen
  • Zum Zeitpunkt dieses Beitrags zeigt die offizielle MeshCore Map weltweit mehr als 38.000 Nodes, und die offizielle MeshCore App hat auf Android und iOS mehr als 100.000 aktive Nutzer
  • Mit dem Wachstum des Projekts wird die Bedeutung der vom core team bereitgestellten offiziellen Informationsräume immer größer
  • Zuletzt hat sich das MeshCore-Webseiten-Ökosystem mit länderspezifischen Seiten und regionalen Mesh-Communities weiter verbreitet; genannt werden unter anderem folgende Beispiele
  • Andy Kirby spielte mit seinem persönlichen YouTube-Kanal eine wichtige Rolle bei der Bekanntmachung von MeshCore, konzentriert sich inzwischen aber auf die Vermarktung seiner eigenen Produkte

Zukünftige Ausrichtung des Betriebs

  • Das core team setzt rund um meshcore.io die Entwicklung von Firmware-Funktionen, Bugfixes, PR-Management und Entwicklerdiskussionen fort
  • Changelogs für neue Firmware- und App-Releases, Blogposts und technische Dokumentation werden nun über die folgenden Kanäle verteilt
  • Auch die beteiligten Personen und ihre Rollen im Blog werden offengelegt
    • Scott ist Projektgründer und lead firmware engineer sowie Entwickler der Ripple-Firmware
    • Recrof ist Entwickler der offiziellen MeshCore Map und verantwortlich für den Firmware Flasher; außerdem teilt er Einblicke in die frühe Entwicklung der MeshCore Map
    • Liam Cottle ist Entwickler der offiziellen MeshCore App und wird einen Startleitfaden für die MeshCore App veröffentlichen
    • FDLamotte arbeitet an Python-Tools für MeshCore und an STM32-Firmware-Varianten
    • Oltaco arbeitet an einem neuen OTA Fix bootloader, um die Zuverlässigkeit von Firmware-Updates zu erhöhen

Das core team

  • Das aktuelle MeshCore-Team besteht aus Scott, Liam, Recrof, FDLamotte und Oltaco
  • Dieses Team will auch künftig auf Grundlage von von Menschen geschriebener Software hochwertige Konzeption und Entwicklung fortsetzen

Neue Basis

Verwandte Beiträge

1 Kommentare

 
GN⁺ 5 일 전
Hacker-News-Kommentare

  • Falls du es noch nicht ausprobiert hast, kann ich nur dringend empfehlen, dir Reticulum anzusehen
    Das Basisprojekt scheint derzeit einen neuen Maintainer zu brauchen, und der Hauptentwickler hat auch ein paar starke Ansichten, aber das Design der verteilten Netzwerkprotokollschicht ist wirklich sehr ausgereift
    Die Desktop-App funktioniert über das Internet (IP) oder per USB-Verbindung zu bestehenden LoRA-Boards, und ich habe mir kürzlich ein https://lilygo.cc/products/t-echo-lilygo gekauft, Open-Source-Firmware darauf installiert und genutzt; die Erfahrung, es per USB an den Desktop anzuschließen oder via Bluetooth mit https://github.com/torlando-tech/columba zu verbinden, war sehr gut
    Durch diese App fühlt sich Reticulum bei der Messaging-Unterstützung wirklich wie ein vollwertiger Bürger erster Klasse an, und man kann mit gewissen Einschränkungen auch Dateien oder Bilder senden
    Da es auf Netzwerkebene arbeitet, kann man auf Reticulum sogar eigene Apps bauen

    • Auf LoRa läuft es bereits gut, aber da es sich um ein transportmedienunabhängiges Protokoll handelt, dürfte es künftig auch zu anderen Übertragungsarten wie HaLow, optisch oder Wi‑Fi gut passen
      Die Leute werden wohl irgendwann merken, dass LoRa die Bandbreiten- und Geschwindigkeitsanforderungen jenseits einfacher Textnachrichten niemals erfüllen kann
      Trotzdem habe ich über einen einzelnen Reticulum-LoRa-Hop schon Sprachanrufe in Echtzeit ausprobiert, und das lief überraschend ordentlich
      Ein Wiki für den Einstieg gibt es hier: https://reticulum.miraheze.org/wiki/Welcome
    • Ich habe einen Monat damit verbracht, mit Reticulum etwas zu bauen, aber das Tooling für die Arbeit mit dem Protokoll war viel zu schwach
      Wenn man eigentlich nur eine App bauen will, ist die Entwicklererfahrung ziemlich frustrierend, und so cool das Konzept auch ist, es gibt zu viele Stolperfallen, als dass Bootstraping nachhaltig wirken würde
      Besonders als ich versuchte, den Stack als Rust no-std auf ein nrf52-LoRA-Gerät zu portieren und Reticulum-Pakete über ein bestehendes MeshCore-Netz zu transportieren, war es ein Albtraum, überhaupt festzustellen, ob meine Pakete korrekt gebaut waren
    • Ich habe noch nie ein funktionierendes Reticulum-Netzwerk in freier Wildbahn gesehen
      Immer nur sehr kleine Testbeds
    • Ich frage mich, welches Frequenzband man dafür bekommt
      Und ob das in der Praxis überhaupt wichtig ist
    • Ich wünschte, nomadnet würde in Go neu geschrieben

  • Ich verstehe nicht, warum Mesh-Projekte bei der Durchsetzung von Markenrechten so übertrieben streng sind
    Bei Meshtastic ist es ähnlich, und einer der Gründe, warum ich mich überhaupt für MeshCore interessiert habe, war, dass ich die Meshtastic-Markenrichtlinien gelesen habe und sie viel zu weitgehend fand

    • Ich habe den Eindruck, dass die Kultur im Funkbereich ziemlich anders ist als die übliche Open-Source-Kultur
      Freies und uneingeschränktes Teilen ist nicht der Normalzustand der Welt, sondern eher etwas Ungewöhnliches
    • Ich kenne die beteiligten Personen nicht, aber vermutlich haben sie Amateurfunklizenzen
    • Ich finde nicht, dass es fair ist, MeshCore an diesem Punkt mit Durchsetzungsfällen auf dem Niveau von MeshTastic gleichzusetzen
      Im Moment sieht es eher danach aus, dass eine einzelne Person in Großbritannien die Marke ohne Zustimmung der übrigen Teammitglieder angemeldet hat, und noch greift niemand tatsächlich jemanden an
    • Der Grund ist simpel: Es riecht nach Geld
      MeshCore hat über 100.000 Nutzer, und Repeater schießen weltweit wie Unkraut aus dem Boden, also ist der Anreiz zur Monetarisierung enorm
      Vor allem war die Person, die hier monetarisieren wollte, eher aus dem Marketing als aus der Firmware- oder App-Entwicklung
    • Das Protokoll ist CC, und ich habe gehört, Mark habe gesagt, man könne es frei verwenden
      Er scheint nur nicht zu wollen, dass seine Arbeit zu einem unaufhaltbaren KI-Tötungsnetzwerk beiträgt

  • We have always been wary of AI generated code, but felt everyone is free to do what they want and experiment, etc. But, one of our own, Andy Kirby, decided to branch out and extensively use Claude Code, and has decided to aggressively take over all of the components of the MeshCore ecosystem: standalone devices, mobile app, web flasher and web config tools.
    And, he’s kept that small detail a secret - that it’s all majority vibe coded.
    Ohne mehr Kontext wirkt dieses Framing ziemlich verdächtig

    1. Dass jemand das Ökosystem „übernimmt“, ist ein völlig anderes Problem als die Nutzung von KI. Ich weiß nicht einmal genau, was das heißen soll; vielleicht heißt es einfach, dass die Person etwas veröffentlicht hat und die Leute es verwenden wollen
    2. Wichtiger ist doch, ob der Code tatsächlich schlecht ist. Dass das Team offenbar nicht wusste, dass er KI benutzt, klingt eher so, als sei am Code selbst zumindest oberflächlich nichts auffällig gewesen. Warum urteilt man dann nicht nach der Qualität des Codes selbst
      Falls die Markenanmeldung stimmt, ist das natürlich feindselig und schlechtes Verhalten, aber bloß weil jemand Claude Code benutzt hat, würde ich mich nicht aufregen
    • Stimme zu
      Ich nutze MeshCore tatsächlich und betreibe mehrere Repeater, aber KI-gestütztes Programmieren an sich stört mich nicht
      Gerade wenn es Closed Source ist, sollte das aber offengelegt werden
      Der Versuch, das Ökosystem über Markenrechte an sich zu reißen, wirkt völlig irre, und es stört mich auch, dass Andy nichts zum GitHub-Projekt selbst beigetragen hat, sondern nur persönliche kommerzielle Zusatzprodukte gebaut hat
      Gleichzeitig scheint es auch so, als habe das MeshCore-Kernteam eine Anti-KI-Schlagseite genutzt, um eine stärkere Erzählung zu konstruieren
    • Stimme nicht zu
      Im Gegenteil, ich unterstütze es, das so öffentlich zum Thema zu machen
      Wer behauptet, 1000 Zeilen von KI ausgespuckten Murks vollständig korrekt reviewt zu haben, täuscht entweder sich selbst oder andere und hat wahrscheinlich noch nie in großem Stil Code-Reviews gemacht
      1000 Textzeilen zu lesen und die Auswirkungen auf Komplexität und Edge Cases im Code zu analysieren, sind völlig verschiedene Dinge, und so ein umfassendes Review kann mehrere Tage dauern
      Schon ein PR mit 100 Zeilen kann Stunden kosten, aber man winkt es mit einer Haltung wie „ich habe alles geprüft“ durch, und deshalb gibt es meiner Meinung nach immer mehr 0-days und Leaks
      Deshalb würde ich Ausgaben nach dem Muster „You are absolutely correct, apologies for the oversight, here's a revised version:“ niemals vertrauen

    • Is the code bad? It sounds like they had no idea he was using AI. That seems to imply there was nothing wrong with the code as-is. Why not judge it on it's merits?
      Wenn man KI auch nur ein bisschen benutzt hat, weiß man, dass es in der Praxis so nicht funktioniert
      KI-Ausgaben sind extrem gut darin, plausible, aber falsche Ergebnisse zu erzeugen, und da sie auf Plausibilität optimiert sind, liegen sie manchmal richtig, erzeugen im Fehlerfall aber gut aussehenden Code, wodurch die Beurteilung noch schwieriger wird
      Bei von Menschen geschriebenem Code bekommt man relativ leichter ein Gefühl dafür, ob er gut ist oder nicht
      Natürlich gibt es Ausnahmen, etwa wenn man ein Oracle wie AddressSanitizer hat oder das Verhalten durch Vergleich mit einem geklonten bestehenden Projekt direkt prüfen kann, aber meistens hat man diesen Luxus nicht

  • Ich habe ein wenig mit MeshCore und Meshtastic herumgespielt; es macht Spaß, aber insgesamt finde ich den Hype ziemlich überzogen
    Durch die vielen SHTF-Leute, die sich da hineindrängen, verschwimmt das Konzept zusätzlich
    Mich interessierten eher Sensor-Netzwerke, aber in der Praxis dreht sich der Großteil der Gespräche um Leute, die davon besessen sind, Hello-World-artige Texte hin- und herzuschicken, und wie miserabel solche Netze in einer echten SHTF-Situation funktionieren würden, wird dabei kaum gesehen

    • Ich habe fast genau denselben Eindruck
      Beide mobilen Apps sind ziemlich holprig, und bei Meshtastic wirkt es noch frustrierender, als würden die Android- und Apple-UI-Teams überhaupt nicht miteinander reden
      Wenn man unterschiedliche Plattformen nutzt, wird Onboarding für neue Nutzer und das Beantworten von Fragen viel zu schwierig
      Es war billig und spaßig aufzubauen, aber ich wünschte, es gäbe zumindest eine bessere Nachrichtenpersistenz, damit Nachrichten nicht ständig verloren gehen
    • Ich habe mit Meshtastic und GPS bei einem Spiel mitgemacht, bei dem man über einen großen Campingplatz lief und Gebiete eroberte, und dafür hat es wirklich gut gepasst und ziemlich viel Spaß gemacht
      Aber wenn mein Leben in einer ernsten Situation von so einem Mesh-Netzwerk abhinge, wäre ich sehr nervös
      Dafür ist das alles noch viel zu instabil, um es als verlässliches Mittel zu betrachten, auch wenn es immer noch besser sein kann als gar nichts
      Auch das Gerätesetup ist ein Problem: Ich wollte die komplette Entwicklungsumgebung auf einem Raspberry Pi 3 installieren, um ohne Internetzugang alles an einem Ort erledigen zu können, aber beim Bauen der riesigen Web-App als Standard-Client-Oberfläche ging zuerst der Speicher aus
    • Stimme im Großen und Ganzen zu und würde noch etwas ergänzen
      Das Fehlen von Standards dürfte die Nutzbarkeit in einer echten SHTF-Situation massiv verschlechtern
      Zum Beispiel ist nicht einmal klar, warum man meshstastic statt meshcore verwenden sollte, und ich glaube auch nicht, dass LoRa in so einer Lage in meinem Kopf hohe Priorität hätte
    • Wenn du etwas im Sensorbereich bauen willst, ist LoRaWAN wahrscheinlich die bessere Wahl
      Nimm eine Mikrotik-Basisstation mit einem Chirpstack-Backend; diese Kombination ist im kommerziellen Umfeld sehr gut erprobt
    • Ich weiß nicht, was SHTF bedeutet

  • Ist diese Client-App immer noch Closed Source
    Für mich wäre das an dem Punkt sofort ein Ausschlusskriterium, und dass so etwas passiert ist, überrascht mich überhaupt nicht
    Und ich glaube auch nicht, dass es damit vorbei ist

    • https://github.com/zjs81/meshcore-open
      Ein geschlossener Client ist jetzt nicht mehr nötig
    • Ich entwickle gerade selbst einen sehr mobilfreundlichen Open-Source-Self-Hosted-Client für ein base-station radio, das man überall einsetzen will
      Er unterstützt auch MQTT, Community Observer, Bots, Webhooks usw.; angefangen hat es, weil ich einen nicht ans Funkgerät gebundenen Alltags-Client brauchte, inzwischen ist er als Begleit-Client für Power-User ziemlich ausgereift
      Die Radio-API und Firmware sind offen, und es gibt sehr viele Alternativen, die manchmal funktional sogar besser sind als die Closed-Source-Optionen, deshalb habe ich persönlich nichts gegen die Entscheidung, Teile der Software zu schließen, um Geld zu verdienen
      https://github.com/jkingsman/Remote-Terminal-for-MeshCore
    • Ich war ziemlich überrascht zu erfahren, dass es immer noch Closed Source ist, und vermutlich wird sich das auch nicht ändern
      Unser lokales Mesh hat letzte Woche ebenfalls meshcore getestet, aber damit ist mein Interesse praktisch verschwunden

  • Ich habe Andy Kirby schon auf YouTube gesehen, und die Videos wirkten auf mich viel zu reißerisch, überzogen und klickköderhaft, sodass ich ihn direkt mit der Projektführung verbunden habe und seitdem von meshcore abgestoßen war
    Diese Sache hier gibt mir das Gefühl, dass mein damaliger Eindruck richtig war

  • Wenn man sich die Lage jetzt ansieht, trägt die .io-Seite ein „MESHCORE“-Logo und die .co.uk-Seite ein „MESHCORE(tm)“-Logo
    [1]: https://meshcore.io
    [2]: https://meshcore.co.uk

  • Ich habe dieses Projekt nie benutzt und kenne niemanden, der daran beteiligt ist
    Aber ich finde es interessant, dass sich Leute, die mit „ich werde alles mit KI neu schreiben“ auftreten, am Ende so oft als großer Problemfall entpuppen
    Natürlich muss das nicht nur auf diese Person zutreffen, und ich kenne auch nicht den ganzen Hintergrund, daher kann ich nicht beurteilen, ob der gesamte Beitrag vertrauenswürdig ist
    Aber in meiner kleinen Stichprobe ist das Signal-Rausch-Verhältnis ziemlich gut

  • Would you trust AI generated mesh firmware?
    Ich finde es absurd, sich über die Vertrauenswürdigkeit von KI-generiertem Code Sorgen zu machen, wenn die eigene Codequalität ohnehin so niedrig ist
    Es gibt keine automatisierten Tests, und Versuche, Tests hinzuzufügen, wurden ignoriert
    [0] https://github.com/meshcore-dev/MeshCore/pull/925
    [1] https://github.com/meshcore-dev/MeshCore/issues/1059
    [2] https://github.com/meshcore-dev/MeshCore/pull/1065
    [3] https://github.com/meshcore-dev/meshcore.js/pull/11
    Als ich zuletzt nachgesehen habe, gab es fast keine Eingabevalidierung, sodass sogar offensichtlich unsinnige Werte wie GPS-Koordinaten außerhalb des Erdumfangs einfach gesendet wurden und der Code das akzeptiert hat
    Ich verstehe, dass junge Projekte kämpfen, aber andere wegen dieses Problems zu belehren, ohne selbst in Codequalität zu investieren, stößt mir sauer auf
    Ich würde MeshCore gern mögen, aber die Projektführung steht ständig im Weg, und die beiden wichtigsten Betreiber, die ich kenne, Scott Powell und Liam Cottle, scheinen ebenfalls darauf hinzuarbeiten, auf der Firmware eine Closed-Source-Business-Schicht aufzubauen und damit Geld zu verdienen, was die Anreize verzerrt wirken lässt
    Das heißt nicht, dass das Open-Core-Modell an sich problematisch ist, aber in diesem Fall könnte es dazu führen, dass Open-Source-Alternativen klein gehalten werden, um die eigenen kostenpflichtigen Closed-Source-Produkte zu pushen
    Außerdem sind die für die USA empfohlenen MeshCore-Broadcast-Einstellungen illegal; ich habe Liam und Scott dazu vor einigen Monaten gemailt, wurde aber ignoriert
    [4] https://github.com/meshcore-dev/MeshCore/issues/945

    • #4 ist wirklich ärgerlich
      Ich bin selbst Funkamateur, aber nicht der Typ, der wegen eines einzelnen Regelverstoßes sofort die FCC informiert; trotzdem macht mir eine Haltung Sorgen, die die Regeln entweder nicht kennt oder sie ignoriert
      Zuerst einmal bin ich nicht sicher, ob die Regelauslegung korrekt ist, aber wenn man davon ausgeht, dass sie stimmt, scheinen die anderen im Thread das ebenfalls mehrheitlich so zu sehen
      Für mich liest sich das wie eine Antwort auf „wir verstoßen gegen Regeln und müssen das ändern“ mit „in Seattle ist das unpraktisch, also machen wir es nicht“ und „in Boston funktioniert es auch nicht gut, also geht es nicht“
      So darf man nicht so tun, als wären Regeln freiwillig
      Wer gemeinsam genutztes Funkspektrum verwendet, hält sich im Allgemeinen ans Gesetz, und wenn das Projekt bei legaler Nutzung schlechter performt, dann ist das ein Problem, das das Projekt lösen muss
      Aus solchen Gründen kann ich auch verstehen, warum ältere Funkamateure zunehmend gereizt reagieren

    • Would you trust AI generated mesh firmware?
      Schon diese Frage ist suggestiv
      Die einzige konkrete Tatsache, die bisher präsentiert wurde, ist, dass er einfach Claude Code benutzt hat
      Wichtiger ist also, ob Tests bestanden werden, ob Sicherheitslücken entstanden sind oder ob ungetestete Regressionen hineingekommen sind

    • Ich frage mich, welche GPS-Koordinaten außerhalb des Erdumfangs konkret gemeint sind
    • Ich verstehe grundsätzlich nicht, warum das Protokoll überhaupt GPS senden und empfangen muss

    • It's ridiculous to me that they're concerned about the trustworthiness of AI-generated code when their code quality is so low.
      Stimme ich zu, aber immerhin ist der aktuelle Code strukturell noch halbwegs nachvollziehbar
      Mit KI dabei besteht die Gefahr, dass daraus wirklich Slopaghetti wird
      Dass sie keine automatisierten Tests annehmen, ist zumindest teilweise nachvollziehbar, wenn gerade 540 Issues und 270 PRs offen sind und nur zwei Leute Reviews machen
      Nach all diesem Drama könnten sie externen Beiträgen noch weniger trauen
      Wenn man Code tatsächlich mergen will, geht man vielleicht besser zu den Leuten hinter dem Evo-Fork; soweit ich gehört habe, besteht die einzige Möglichkeit, interessante PRs gemergt zu bekommen, darin, genug Likes auf einem GitHub-Issue zu sammeln oder in Discord direkt darum zu bitten
      [1] https://github.com/mattzzw/MeshCore-Evo

  • Ich nutze KI in der Entwicklung gern und halte sie auch für wichtig in moderner Softwareentwicklung
    Trotzdem gibt es eindeutig einen Unterschied zwischen KI- und von Menschen geschriebenem Code, und das muss unbedingt offengelegt werden

    • Und nicht nur das
      Wenn große Teile eines Projekts per vibe coding entstanden sind, ist auch unklar, ob diese Person überhaupt berechtigt ist, dem DCO zuzustimmen und den Code unter der LICENSE dieser Codebasis zu verbreiten
    • Genau
      Es ist schon schwer genug, überhaupt zu verstehen, was ein Programm tut, aber bei von Menschen geschriebenem Code kann man zumindest davon ausgehen, dass irgendeine Absicht dahinterstand
      Bei KI-generiertem Code weiß man nicht einmal, warum etwas überhaupt enthalten ist
      Viel zu oft laden Leute überall im Internet vibe-coded Projekte hoch, verschweigen das zunächst und sagen einfach „das habe ich gebaut“, kassieren also das ganze Lob
      Und wenn später herauskommt, dass sie selbst nichts geschrieben haben und nicht einmal wissen, wie es funktioniert, heißt es plötzlich, „KI zu benutzen ist doch kein Problem“
      Aber KI als Werkzeug zu verwenden und ohne Verständnis einfach alles zu kopieren und als eigene Leistung zu verkaufen, sind zwei völlig verschiedene Dinge