Hat jemand von euch mit "Klaut Kot" schon positive Erfahrungen gemacht und kann es empfehlen? Ich meine fuer Hobbyprojekte.
Dscho schrieb: > Hat jemand von euch mit "Klaut Kot" schon positive Erfahrungen > gemacht > und kann es empfehlen? Ich meine fuer Hobbyprojekte. Josef soll da etwas mit Maria getestet haben. Einfach phänomenal, was da raus gekommen ist.
Wer schon "Klaut Kot" schreibt ist rein auf Trollen und Krawall aus - nicht auf eine sachliche Diskussion. Daher hab ich deinen Beitrag direkt mal gemeldet. Und ja, wenn du hier lesen würdest, würden dir einige Projekte bekannt sein. Eines gutes davon ist in Projekte und Code sogar komplett frei gegeben.
:
Bearbeitet durch User
Rene K. schrieb: > Eines gutes davon ist in Projekte und Code sogar > komplett frei gegeben. Welches soll das sein?
Möglicherweise meint er ein µPy Projekt welches schon allein dadurch auffällt, dass es genau die Fehler und Schlampereien*¹ eingebaut hat, die man so im Netz verstreut findet. Läuft möglw. zur Zeit noch, braucht aber nur etwas Wartezeit und Firmware Updates um dann Exceptions zu schmeißen. *1 Obschon in der offen zugänglichen Dokumentation davor gewarnt wird.
Mich hat kürzlich ein Kollege versucht, von "Claude" zu überzeugen. Er versuchte sich damit eines Problems anzunehmen, mit dem ich gerade zu tun habe. Die "Antwort" von "Claude" kam schnell, schön professionell aufbereitet und tatsächlich auch mit ein paar thematisch passenden Stichwörtern angereichert, die nicht im "Prompt" untergebracht waren. Mit etwas hin und her wurde das Resultat weiter verfeinert, "Claude" wirkte jeweils so, als ob es auf die Verfeinerungen eingehen würde. Das Resultat aber funktionierte nicht. Es enthielt formelle Fehler*, und (wenn man die korrigierte) bewirkte sonst nichts. Immerhin, abgesehen davon, daß es Zeit und Geld verschlungen hat, hat es in meinem Fall keinen relevanten Schaden angerichtet. Aber, und das muss man dem Ding lassen, 'ne schöne Show. Kostet ja auch 15 Euro im Monat ... *) hier gings um ein Bootproblem, für das einige Kernelmodule entfernt werden sollten - einerseits wurden nicht existierende Module erwähnt, andererseits wurde ein Modul entfernt, das eine zwingende Abhängigkeit eines anderen Moduls ist, das aber verwendet werden musste.
Ich hab's jetzt tatsächlich teilweise sinnvoll nutzen können auch für Embedded Projekte. Man braucht auf jeden Fall die Bezahlversion und (mindestens) das Modell Sonnet 4.6 . Das LLM nimmt einem nicht die Denkarbeit ab. Man muss sich die Architektur und Abläufe schon selber überlegen und dann im Prompt spezifizieren, ein bisschen wie bei Hausaufgaben. Das klappt nur bei abgeschlossenen Aufgaben gut bei denen schon alles absehbar ist. Interessanterweise ist es unglaublich gut im Erkennen und Anwenden von Techniken & Entwurfsmustern - wenn man in einer existierenden Codebase schon intensiv z.B. das State Pattern und dazugehörige Frameworks verwendet, wird Claude das selbstständig für neuen Code anwenden. Wenn man ein neues Modul implementieren möchte und es existiert bereits eines mit einer ähnlichen Funktion, benutzt Claude das sehr effektiv als Vorlage. Wenn es um Zahlen und Algorithmen geht die Nachdenken erfordern ist Claude weniger nützlich, da nutzt es meist den naivsten Ansatz der irgendwo aus dem Netz kopiert ist und nicht anwendbar ist. Claude ist auch sehr voreilig, wenn man z.B. erstmal nur ein leeres Gerüst definieren möchte muss man explizit angeben dass nichts ausgefüllt / implementiert werden soll. Es arbeitet sehr nach "Nicht fragen sondern machen"; auch wenn die Lösung eines Problems umständlich ist und viele Nachteile hat versucht es die auf Biegen und Brechen umzusetzen, statt zu überlegen/fragen ob nicht ein ganz anderer Ansatz das geringere Übel wäre. Ein wirklicher Zeitgewinn stellt sich eigentlich nur ein, wenn man mehrere solcher abgeschlossener wohldefinierter Aufgaben hat und gleichzeitig startet, also auf mehreren Instanzen. Sonst wäre man aufgrund der Wartezeiten und Overhead der Prompt-Eingabe manuell vermutlich schneller. Allerdings ist das "Multitasking" zwischen den Instanzen wirklich anstrengend...
:
Bearbeitet durch User
Also wir nutzen es auch intensiv auf der Arbeit. Allerdings darf man nicht glauben, man gibt ein paar gute Stichworte, wartet etwas und fertig ist das Softwareprojekt. Claude ist recht gut darin Fehler und unvollständige Spezifikationen zu finden, wenn man direkt danach suchen lässt. Danach schafft er es auch ziemlich gut dass dann umzusetzen. Aber wie immer bei Softwareprojekten: das Ergebnis ist nur so gut wie der Plan. Und ja, es stimmt, die Zeitersparnis ergibt sich hauptsächlich daraus, dass man in der Wartezeit andere Dinge tun kann - und sei es mit Claude an einem anderen Problem zu arbeiten. Auch muss man damit rechnen sich relativ lange einzuarbeiten. Man braucht ein Gefühl dafür, wo Claude Regeln braucht und wo man ihn machen lassen kann. Ein Kollege bezeichnete Claude mal als Junior Entwickler direkt von der Uni. Da ist auf jeden Fall was dran, im Guten, wie im Schlechten.
Poldy H. schrieb: > Also wir nutzen es auch intensiv auf der Arbeit. Allerdings darf man > nicht glauben, man gibt ein paar gute Stichworte, wartet etwas und > fertig ist das Softwareprojekt. Kennich. Aus "unserer" Software-Abteilung. Die Herren in der Führungsriege vertraten oft die Auffassung dass man vor der ersten Zeile Software erst mal alles gründlich per Dokument spezifizieren sollte. Die Erkenntnis und Erfahrunugen daraus waren, dass der Aufwand etwas wirklich gut zu spezifizieren, so groß und langwierig ist dass man die Aufgabe gleich direkt in Programmierung angehen kann und effizienter dabei ist. Dabei spart man dann die Kosten für die aufwendige Spezifizierung, auch wenn es bei der Software-Erstellung manch kleine Überraschung geben könnte.
Wastl schrieb: > Kennich. Aus "unserer" Software-Abteilung. Die Herren in der > Führungsriege vertraten oft die Auffassung dass man vor der > ersten Zeile Software erst mal alles gründlich per Dokument > spezifizieren sollte. Hat immerhin den Vorteil dass man dann sehr genau den Software-Entwicklungsaufwand abschätzen kann und nicht in Erklärungsnöte gerät wenn es doch mal unerwartet komplizierter wird. Mit einer klaren Spezifikation, die auch die Auftraggeber abgesegnet haben, kann man doch ziemlich entspannt arbeiten, und im Nachhinein hat man auch noch eine super Dokumentation. Viele wären froh darüber, auch die Zeit dafür zu bekommen ;-)
:
Bearbeitet durch User
Niklas G. schrieb: > Mit einer klaren > Spezifikation, die auch die Auftraggeber abgesegnet haben, kann man doch > ziemlich entspannt arbeiten. Das scheitert eben sehr oft daran dass die Spezifikation - wie in meinem Beitrag angedeuted - nicht ausreicht, viele Dinge schwammig oder gar nicht beschrieben sind. Dann ist halt die Ausführung "wie gewachsen", Reklamationen zur Ausführung werden damit gekontert: "da war ja nichts verlangt". Habe ich zu oft erlebt.
Wastl schrieb: > Das scheitert eben sehr oft daran dass die Spezifikation - wie > in meinem Beitrag angedeuted - nicht ausreicht, viele Dinge > schwammig oder gar nicht beschrieben sind. Ist es dann besser gar keine Spezifikation zu haben und alles im Wildwuchs zu haben? Ich hab doch ganz deutlich die Erfahrung gemacht dass die meisten Projekte eher deutlich *Unter*-Spezifiziert sind als umgekehrt. Anekdote: Bei der Beauftragung einer Datenbank für Kunstwerke hat ein Programmierer vorgeschlagen, die Werke nach Farbe zu sortieren - die Kunstexperten waren so amüsiert dass sie Jahre später noch darüber lachen 😁
Rene K. schrieb: > Wer schon "Klaut Kot" schreibt ist rein auf Trollen und Krawall aus - > nicht auf eine sachliche Diskussion. Daher hab ich deinen Beitrag direkt > mal gemeldet. Und ja, wenn du hier lesen würdest, würden dir einige > Projekte bekannt sein. Eines gutes davon ist in Projekte und Code sogar > komplett frei gegeben. Nicht meine Schuld, wenn du humorloser Misanthrop keine Wortspiele magst und auch nicht verstehst. Und gleich anlacken und melden was fremd ist und nicht verstanden wird, Da weiss man gleich aus welcher Ecke du kommst!
Jedem das Seine. Ich nutze als Unterstützung ChatGPT Go, für meine Zwecke reicht es mir vollkommen aus. Den vorgeschlagenen Code versuche ich auch zu verstehen und tue den nicht einfach nur per Copy & Paste einfügen. Für VS Code gibt es noch Copilot, der macht auch schon eine ganze Menge.
Wastl schrieb: > Die Erkenntnis und Erfahrunugen daraus > waren, dass der Aufwand etwas wirklich gut zu spezifizieren, > so groß und langwierig ist dass man die Aufgabe gleich direkt > in Programmierung angehen kann und effizienter dabei ist. Treffender kann man die Ursache für all die Probleme in der Softwareindustrie nicht beschreiben. Oliver
Oliver S. schrieb: > Treffender kann man die Ursache für all die Probleme in der > Softwareindustrie nicht beschreiben. Glaubst du wirklich Überspezifikation ist die Hauptursache dieser Probleme? Hast du mal in der normalen Softwareentwicklung, außerhalb von Embedded, gearbeitet?
Also über Spezifikation und deren Präzision kann man vortrefflich Streiten, da dies auch immer sehr vom individuellen Projekt abhängt. Interessant finde ich, dass anscheinend der Einsatz von Claude Code daran scheitert, dass es zu umständlich ist genau zu sagen, was man möchte. Im übrigen assistiert Claude Code auch gut beim Schreiben der Spezifikation. Nur es hilft alles nichts, man muss dem System schon klar machen, was man will, bzw. man muss es selber erstmal wissen.
Poldy H. schrieb: > Nur es hilft alles nichts, man muss dem System schon klar machen, was > man will, bzw. man muss es selber erstmal wissen. So ist es, und LLMs sind notorisch schlecht darin Entscheidungen zu treffen. Claude liefert zwar gern eine hübsche Liste von Lösungsansätzen, aber kann nicht den Besten herausfinden. Manchmal ist es so offensichtlich, dass der eine Ansatz viel besser als die anderen ist und Claude trotzdem einen anderen bevorzugt, dass es einem wie ein Test vorkommt ob man noch aufpasst...
Niklas G. schrieb: > Oliver S. schrieb: >> Treffender kann man die Ursache für all die Probleme in der >> Softwareindustrie nicht beschreiben. > > Glaubst du wirklich Überspezifikation ist die Hauptursache dieser > Probleme? Hast du mal in der normalen Softwareentwicklung, außerhalb von > Embedded, gearbeitet? Er schrieb was von guter Spezifikation, die sich nicht lohnen würde, nicht von Überspezifikation. Oliver
Oliver S. schrieb: > Er schrieb was von guter Spezifikation, die sich nicht lohnen würde, > nicht von Überspezifikation. Aha, und dieser Effizienzverlust soll das Hauptproblem sein?
Niklas G. schrieb: > Hat immerhin den Vorteil dass man dann sehr genau den > Software-Entwicklungsaufwand abschätzen kann und nicht in Erklärungsnöte > gerät wenn es doch mal unerwartet komplizierter wird. Das ist eine sehr schöne Theorie, die ihren ersten Kontakt mit der Praxis aber regelmäßig nicht besonders lange überlebt... Mitunter war und bin ich an der Ausarbeitung von Spezifikationen beteiligt, und weil ich die genannten Probleme mit dem Praxiskontakt kenne und deshalb gern vermeiden will, fehlerhafte oder interpretationsfähige Spezifikationen abzuliefern, schreibe ich dabei häufig schon kleine Prototypen. Häufig habe ich am Ende so viele Prototypen, daß diese nur noch zusammen gefügt werden müssen und schon funktionieren, noch bevor die Specs fertig sind.
Norbert schrieb: > Möglicherweise meint er ein µPy Projekt welches schon allein dadurch > auffällt, dass es genau die Fehler und Schlampereien*¹ eingebaut hat, > die man so im Netz verstreut findet. Läuft möglw. zur Zeit noch, braucht > aber nur etwas Wartezeit und Firmware Updates um dann Exceptions zu > schmeißen. > > *1 Obschon in der offen zugänglichen Dokumentation davor gewarnt wird. Harald K. schrieb: > Welches soll das sein? Das hier, obschon Norbert dort bereits "weitere Fehler" gefunden hat, weil es eben in KI generiert wurde, welche Fehler (bis auf ein Rundungsfehler) er genau meint, bleib er natürlich schuldig. "Das ganze Projekt ist halt in KI gemacht, da muss es ja völlig voller Fehler sein, für einen KI Hasser kann das ja nicht angehen! Somal das es noch so hohen Zuspruch findet... ;-) Beitrag "Wasserstandsmessung mit RaspberryPico und Drucksensor MPX2050DP"
Rene K. schrieb: > bleib er natürlich schuldig. "Das ganze > Projekt ist halt in KI gemacht, da muss es ja völlig voller Fehler sein, Und wieder demonstriert Rene seine Dummheit und stellt sie öffentlich zur Schau. Glaubst du allen Ernstes, ich wäre dafür zuständig KI Schlonz zu korrigieren und zu verbessern? Jeder der des Lesens mächtig ist und die vorhandene Dokumentation versteht, findet die Fehler auch selbst. Und zwar problemlos. (Na ja, vielleicht nur n-1 Personen) > für einen KI Hasser kann das ja nicht angehen! Somal (sic) das (sic) es > noch so hohen Zuspruch findet Von Hass kann keine Rede sein. Hier werden nur die offensichtlichen Fakten aufgezeigt. Scheint dir aber irgendwie gegen den Strich zu gehen. > (bis auf ein (sic) Rundungsfehler) Es sind vielfache Rundungsfehler, bzw. nach Klarstellung, vielfache unnötige, redundante Operationen. Zudem wird völlig unnötig Speicher verplempert, auch das könnte man in der Doku nachlesen. Und den anderen, größten Teil habe ich mir (ob der Code "Qualität") noch nicht einmal angeschaut. Das liegen vermutlich noch ganz andere Schätze vergraben. Im übrigen zitierst du verfälschend (Haralds Post lag zeitlich vor meiner Replik. Aber das hast du bestimmt nicht absichtlich gemacht.
:
Bearbeitet durch User
Norbert schrieb: > Glaubst du allen Ernstes, ich wäre dafür zuständig KI Schlonz zu > korrigieren und zu verbessern? Das ist kein "Schlonz". Und das ist das was dir auf den Sack geht, wenn du so gerne Zitate magst: Dann hier gerne Norbert schrieb: > Du verballerst unnötigerweise eine Menge RAM. > > Wenn du Koordinaten in float übergibst, solltest du über round() anstatt > int() nachdenken. > > (›0.99999‹ soll bestimmt eine ›1‹ werden und nicht eine ›0‹) Ein Float und ein ein Int sind in pyhton beide 4Byte groß. Also WO verballert er Ram? Wo siehst du im Code überhaupt eine Möglichkeit das ein der Koordinaten jemals 0,9999 annehmen kann? Das ist alles nur dummes gelaber von dir, mehr nicht! Mit round() würde er unnötigerweiße Rechenzeit "verschlonzen". Hier geht es nicht um Chat-GPT sondern um Claude... Denn das Projekt, nicht die Änderung des Users auf den du dich in deinem Beitrag beziehst ist: Tobias R. schrieb: > Der Code wurde > komplett mit Ki (Claude) ge-vibe-coded Und das Projekt ist gut und sauber, ob dir das nun gefällt oder nicht! Norbert schrieb: > Von Hass kann keine Rede sein. Hier werden nur die offensichtlichen > Fakten aufgezeigt. Scheint dir aber irgendwie gegen den Strich zu gehen. Nein, du zeigst keinerlei Fakten auf! Das ist es ja eben, von dir kommt nur Stammtisch-Gebluber. Mehr nicht!
Rene K. schrieb: > Ein Float und ein ein (sic) Int sind in pyhton (sic) beide 4Byte groß. > Also WO verballert er Ram (sic)? Dass sich das "RAM verballern" gar nicht darauf bezieht, kommt dir in deiner arg eingeschränkten Sichtweise und zudem gänzlich ohne Wissen, gar nicht in den Sinn. Und dass dir innerhalb der ersten Zeilen des "nachgebesserten" Moduls ein offensichtlicher Fehler förmlich ins Gesicht springt ohne von dir wahrgenommen zu werden, lässt schlimmes vermuten. Rene K. schrieb: > Nein, du zeigst keinerlei Fakten auf! Das ist es ja eben, von dir kommt > nur Stammtisch-Gebluber (sic) Mehr nicht! "keinerlei"? Du beweist noch einmal, dass du ein durch und durch dummer Mensch bist. Aber auch, dass du gerne herum pöbelst und es dir völlig egal ist dies beides öffentlich zur Schau zu stellen. Lies endlich die Dokumentation, damit du wenigstens mit rudimentären Grundlagen gewappnet bist um dich hier auszulassen. So wird das nämlich nichts.
:
Bearbeitet durch User
Norbert schrieb: > Lies endlich die Dokumentation Von welcher ominösen Dokumentation laberst du eigentlich die ganze Zeit?! Ich habe so strickt das Gefühl das du bereits weit über sechzig bist und irgendwo ganz tief in der Vergangenheit hängen geblieben bist - du scheinst neuere Strukturen, Techniken oder Grundlagen einfach nicht mehr verstehen wollen und können. Was anderes kann es ja gar nicht mehr sein!? Das würde auch deine geringe Auffassungsgabe beim Lesen der Beiträge erklären. Norbert schrieb: > Dass sich das "RAM verballern" gar nicht darauf bezieht, kommt dir in > deiner arg eingeschränkten Sichtweise und zudem gänzlich ohne Wissen, > gar nicht in den Sinn. Und dass dir innerhalb der ersten Zeilen des > "nachgebesserten" Moduls ein offensichtlicher Fehler förmlich ins > Gesicht springt ohne von dir wahrgenommen zu werden, lässt schlimmes > vermuten. NOCHMAL!: es ging in meinem Post nicht um das "nachgebesserter Modul" für das ePaper sondern um den HAUPTBEITRAG! Hier geht es nicht um ChatGPT sondern um Claude! Der einzige der her wahrlich ein phänomenales Problem mit Leseverständniss hat bist du, nur du! Norbert schrieb: > "keinerlei"? Ja keinerlei... Zeig mir nur ein Fakt den du aufgezeigt hast! Nur einen! Alles nur reine dumme Stammtischparolen von dir, Parolen eines alten verbitterten Mannes, der sein Leben lang programmieren gelernt hat und nun fest stellt das es eine Maschine tausendmal bessere arbeite leistet als er... Das typisch deutsche Neid-Gehabe ist das.
:
Bearbeitet durch User
Rene K. schrieb: > Wer schon "Klaut Kot" schreibt ist rein auf Trollen und Krawall aus - > nicht auf eine sachliche Diskussion. Genau so dürfte es sein! Aber um mal was sachliches Beizusteuern: Claude, ChatGPT und für andere Bereiche sogar Grok sind mittlerweile beeindruckende leistungsfähige Werkzeuge geworden. Aber wie bei allen Leistungsfähigen Werkzeugen, egal ob Software Tools oder echte Werkzeuge zum Anfassen für Metall- oder Holzbearbeitung, muss man sowohl die Grundlagen des Handwerks verstehen UND mit diesem speziellen Werkzeug auch gut umgehen können, dessen Stärken und Schwächen kennen, um gute Ergebnisse zu erhalten. Man kann einem Laien ohne Erfahrung noch so viele tolle Holzbearbeitungswerkzeuge zur Verfügung stellen, er wird zumindest in Annehmbarer Zeit ohne zig Korrekturversuche keinen stabilen Dachstuhl errichten können der sich mit einem von Profis gebauten Messen kann. Von einem kompletten Fachwerkhaus ganz zu schweigen. Hat man das wissen nicht, sowohl in der Art der Eingabe, wieviel Konkretisierung es braucht, wieviel man der KI überlassen darf und wieviel nicht, wie groß die Promphäppchen sein dürfen (Nicht zu viele Anpassungen in einem Schritt) und wo man ganz genau hinschauen muss, dann kommt nämlich genau das raus was der TO so abfällig beschrieb: KOT. Macht man es richtig kommt schon einiges Brauchbares raus. Aber es braucht Fachwissen. Es ist zumindest zum jetzigen Zeitpunkt und vermutlich noch auf lange Zeit ein riesen Irrglaube das man damit Qualifizierte Softwareentwickler vollständig ersetzen kann. Aber man kann schon viel an Arbeit automatisieren und so natürlich auch Stellen einsparen. Am ehesten sehe ich da natürlich die reinen "Codemonkeys" in Gefahr, diejenigen die wirklich den ganzen Tag nur vorgegebene ausformulierte Tikets abarbeiten. Wenn die Entwicklung so weiter geht, dann sind es vielleicht noch 1-2 Jahre und eine KI kann 95% der Arbeit problemlos ersetzen. Davon das man diejenigen die diese Tickets schreiben ersetzen kann sind wir aber noch erheblich weiter entfernt. Aber was sich alleine seit dem Jahreswechsel schon wieder in diesem und anderen (Bilderstellung, Videogenerierung) getan hat hat, das ist echt beeindruckend (oder erschreckend, je nach Sichtweise). Gruß Carsten
Aber um mal ein paar Beispiele zu nennen: Ich nutze diese Tools für einzelne Algorithmen oder auch mal eine Funktion oder Klasse in „richtigen“ großen Projekten (auch beruflich). Mit anschließender strenger Kontrolle und immer nur kleine, für mich gut überschaubare Happen. Die entsprechenden Projekte sind in C, C++ und immer mehr Rust. Das funktioniert für mich schon recht gut. Aber ich verwende es auch, und das viel häufiger, für kleine, abgeschlossene Test- oder Auswertetools. Insbesondere da, wo es nur auf die Funktion, aber nicht auf die Codequalität und Wartbarkeit ankommt. Also das, wo ich auch früher schon, um zu einem schnellen Ergebnis zu kommen, etwas in Python „hingeschmiert“ habe. Da lasse ich auch mal ein komplettes Tool schreiben. Ich hatte zu Jahresanfang Bedarf für einen kleinen Audiogenerator fürs Handy. Einstellbare Töne mit variabler Lautstärke, getrennt nach Kanal, dazu verschiedene Arten Rauschen sowie bestimmte Tonfolgen. Mit Timer für intermittierenden Betrieb. Mit Claude (Chat) war es nach drei Iterationen und vielleicht 10 Minuten Gesamtzeit (inkl. Anpassung daran, wie ich es haben wollte) komplett funktionsfähig. Die vorhergehenden Iterationen waren wegen Anpassungen am UI, weil ich es anders wollte, UND wegen Fehlern im Code/Nichtfunktion. Ein weiteres Beispiel ist eine Steuersoftware (PC) für eine mehrkanalige 4-Quadranten-Strom- und Spannungsquelle mit Messfunktion für Testzwecke. – Besondere Anforderungen, deshalb Selbstbau – Die PC-Software habe ich noch händisch mit KI-Unterstützung (Claude) geschrieben. Arbeitszeit etwa 20–30 % der Zeit, die ich benötigt hätte, wenn ich nur händisch geschrieben hätte. Dann kam die Idee auf, davon eine autarke Version zu erstellen, die gut tragbar ist, nicht viel Platz wegnimmt und ohne PC auskommt. Da es nur ein internes Testtool ist, in das nicht zu viel Zeit investiert werden sollte, habe ich einen µPi-Zero (RP2040), eines der typischen 128x64-TFT-Displays mit Controller und einen Drehgeber genommen. Rein spaßeshalber, nur um zu sehen, was für einen Blödsinn er daraus generiert, habe ich dann den Quellcode des PC-Programms (Python) in ChatGPT kopiert und folgenden Prompt dazu geschrieben: >Ich kann die Quelle nun per PC steuern. >Ich möchte ihn aber mit dem RP2040, >Drehgeber und ST7735-TFT-Display (breit 128 x hoch 64) steuern. >Die Pinbelegung ist: xxxxx >Ich möchte folgende 3 Ausgangswerte anpassen können: >Ich möchte folgende 6 Messwerte sehen: Zu meiner (tatsächlichen) Überraschung kam nicht nur eine lauffähige Version raus was bereits gezeigt hätte das er die Art der Kommunikation (UART) das Datenformat und die weiteren technischen Eigenschaften des Gerätes erkannt hätte, sondern eine, die tatsächlich die vielen Einstellmöglichkeiten der PC-Software auf eine mit einem Drehgeber in sinnvoller Weise zu bedienende Variante angepasst hatte und eine sinnvolle Displaydarstellung hatte. Oder anders gesagt: eine sofort lauffähige Variante. Alle von mir nachträglichen Anpassungen waren eher geschmacklicher Art und wären nicht notwendig gewesen. Das hat mich dann schon etwas sprachlos gemacht. Gruß Carsten
Rene K. schrieb: > Alles nur reine dumme Stammtischparolen von dir, Parolen eines alten > verbitterten Mannes, der sein Leben lang programmieren gelernt hat und > nun fest stellt das es eine Maschine tausendmal bessere arbeite leistet > als er... Das typisch deutsche Neid-Gehabe ist das. Ich habe nun keine Lust mehr mit so einem Trolläffchen wie dir zu konversieren. Da könnte man interessantere Konversationen mit einer Ziegelsteinwand führen. Die hätte auch ein besseres Benehmen.
Dscho schrieb: > Dscho (Gast) Wie ist es denn möglich das man als Gast hier kommentieren kann? Da ist doch der Moderator selbst ein Troll?
Jens K. schrieb: > Dscho schrieb: >> Dscho (Gast) > > Wie ist es denn möglich das man als Gast hier kommentieren kann? Da ist > doch der Moderator selbst ein Troll? Lese den Thread von Anfang an! Thread erstellt: von Dscho (Gast)24.05.2026 01:11 Dann Dampf abgelassen: von Dscho (Gast)24.05.2026 17:00 Danach sein Account gelöscht. Jetzt bleibt sein Rest als (Gast) stehen. Gruß D. T.
D. T. schrieb: > Danach sein Account gelöscht. > Jetzt bleibt sein Rest als (Gast) stehen. Das ist ja noch viel schlimmer! Also absichtlich getrollt mit Unterstützung der Mods! Alleine "Klaut Kot" würde bei mir den Löschtrigger auslösen! Aber marketingtechnisch brilliant!
Jens K. schrieb: > Also absichtlich getrollt mit > Unterstützung der Mods! Die "Unterstützung" halte ich für eine dreiste Unterstellung.
Dscho schrieb: > Klaut Kot Harald K. schrieb: > Jens K. schrieb: >> Also absichtlich getrollt mit >> Unterstützung der Mods! > > Die "Unterstützung" halte ich für eine dreiste Unterstellung. Wenn jemand absichtlich "Klaut Kot" schreibt und die Mods es stehen lassen, wie soll ich das dann verstehen?
Mir ist noch ein guter Use Case eingefallen: Schreiben von Unit-Tests und des dafür benötigten Mockings. Weil man ja typischerweise keine Zeit für Unit-Tests hat kann man sich so blitzschnell eine gute Zahl von Testcases erzeugen lassen; gibt zwar keine Garantie auf Vollständigkeit aber so ist es immerhin besser als gar keine Tests zu haben. Das Nachbilden+Simulieren von APIs (z.B. für Hardwarezugriff) klappt super, weil das LLM sich an dem gegebenen Interface entlanghangeln kann. Mit Claude klappt das tatsächlich auch mit C++ und CppUTest in einem CMake basierten STM32-Projekt wunderbar; frühere Coding-Agents konnten mit so "exotischen" Sprachen nicht viel anfangen.
Jens K. schrieb: > Wenn jemand absichtlich "Klaut Kot" schreibt und die Mods es stehen > lassen, wie soll ich das dann verstehen? Hätte er "Klaut Code" geschrieben, wäre es noch ein lustiges und womöglich sogar zutreffendes Wortspiel gewesen.
Sheeva P. schrieb: > Hätte er "Klaut Code" geschrieben, wäre es noch ein lustiges und > womöglich sogar zutreffendes Wortspiel gewesen. Habt ihr Kindsköpfe keine andere Sorgen?
Niklas G. schrieb: > Mir ist noch ein guter Use Case eingefallen: Schreiben von Unit-Tests Finde ich nicht gut. Mit so viel mühe hätte man die Unit Tests gleich sparen können. Hat eh keinen Mehrwert und bringt nichts. Außerdem gab es schon vor LLMs auch Tools die Unit Test generieren konnten. Nur hat man damals vermutlich noch verstanden worum es bei den Unit Test geht. Deswegen hat man die Tests nicht an Hand der Code generiert. Aber heute suchen die Managers verzweifelt nach Problemen wo man KI einsetzten könnte. Also es wird wohl kommen, dass Unit Test einfach von KI generiert wird. Da es nichts bringt, wird auch keiner so richtig rein gucken. So lange die Coverage 100% ist kann es ja nicht falsch sein. Oder doch?
Andras H. schrieb: > Finde ich nicht gut. Mit so viel mühe hätte man die Unit Tests gleich > sparen können. Hat eh keinen Mehrwert und bringt nichts. Die "Mühe" ist absolut minimal weil Claude die Tests mit einem ganz kurzen Prompt erzeugt. Und es bringt durchaus was, ich habe so schon Fehler gefunden. Man kann händisch immer noch Tests hinzufügen wenn ein Fall fehlt. Mindestens für die Implementierung der Mocks ist die KI kein Nachteil, denn ein fehlerhafter Mock wird die Tests eher fälschlicherweise fehlschlagen lassen, statt fälschlicherweise Erfolg zu melden. Letztlich also definitiv besser als überhaupt nicht zu testen.
Frank D. schrieb: > Sheeva P. schrieb: >> Hätte er "Klaut Code" geschrieben, wäre es noch ein lustiges und >> womöglich sogar zutreffendes Wortspiel gewesen. > > Habt ihr Kindsköpfe keine andere Sorgen? Nein. Gut, ne?
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.