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
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.