Claude Code trifft AVR-Assembler: vom Chip in den Browser mit einem Prompt

Sehr schön geschrieben. Das Problem bei meinen Hobbyprogrammierprojekten ist die Zeit. Ich habe Ideen, da müsste ich wohl mehrere Jahre einplanen, um neben der Arbeit und Familie das schön fertig zu programmieren. Deshalb bleibt es oft halbfertig liegen.

Mit KI macht das wieder Spaß. Da kann man Hobbyprojekte umsetzen, wo man sonst ein ganzes Team gebraucht hätte :-)

PS: Wichtig ist, dass man die guten KIs nimmt. Also z.B. für ca. 20 € Claude Opus oder Codex Sol. Das ist ein riesiger Unterschied zu den kostenlosen alten Modellen.

Randbemerkung: Allgemein ist ein Bessel-Filter keine gute Wahl für DDS, da passt Butterworth besser. Mglw. empfehlen sich unterschiedliche Filter-Charakteristika je nach generierter Signalform, Bessel wird üblicherweise für (Rechteck/Nadel)-Pulse eingesetzt.

Zur Frage mit Hardware-In-The-Loop, dazu habe ich vor einiger Zeit ein Video von Andreas Spiess gesehen, welches mich sehr beeindruckt hat: https://www.youtube.com/watch?v=nmGEedloQ6E

Darin zeigt er, wie ein Agent gefühlt selbständig den ESP32 programmiert, testet und die gefundenen Fehler gleich korrigiert. Das Prompten beschränkt sich auf eine hohe Ebene der Programmierung, in der es um Funktionsanforderungen und Testabdeckungen geht und nicht mehr in das WIE der Implementierung.

Hardware in the loop habe ich bisher nur virtuell durch. Der "Agent" spricht dabei via eine virtualisierte JTAG-Schnittstelle mit der virtuellen Hardware per Python-Kommandos und macht die Regresstests quasi automatisiert. Das ganze koennte man theoretisch auch per gdb machen, da hat es aber teilweise etwas mit den Kenntnissen der AI gehapert. Wo es eklig wird, ist asynchrones Debugging, da spinnt GDB auch einfach oft (je nach Version) gewaltig rum, da muesste die AI erst mal die Arbeit leisten, gdb zu fixen :-)

Interessant, allerdings ist es im Prinzip ein Konversionsprojekt einer bereits vorhandenen Software, welche auf einer bekannten Hardware läuft. Die Peripherie ist auch nicht so schwierig nachzustellen, zumal man dafür Simulationsboxen hat, u.a. von den Herstellern. Beispiel DAC-Modelle. Was ich cool finde ist das Display. Dürfte eher seltener sein.

Die Frage ist, wie es mit einer HW ausieht, die der Generator nicht kennt für die er keine Doko ziehen kann, wie bei einem Fertiggerät. Auch die Abtasraten sind schnell ein Problem, wenn man Dinge in SW nachstellt.

Ich wage auch, infragezustellen um der Klang genau so ist, wie bei dem Original.

Und da es hier um Musikgeräte geht: Einen älteren Synthesizer nur aufgrund seiner SW nachzustellen, ist nicht so einfach. Da muss man die bestehende HW analysieren. Dazu gibt es bekanntlich Projekte, die das leisten wie zuletzt die Roland 8080.

Bradward B. schrieb:

Allgemein ist ein Bessel-Filter keine gute Wahl für DDS, da passt Butterworth besser.

Kommt drauf an wie man vorfiltern möchte und was am Ende die analoge Elektronik kann. Eine DIY Elektronik wäre mit einem Linkwitz-Riley-Filter am Besten bedient, das man entsprechend vorentzerrt. Da das die echten DACs aber machen, braucht man intern in der SW eher einen FIR. Der ist auch leichter zu berechnen als ein (gleichwertiger) Bessel.

Ich will das Filterthema nicht ausdehen, erwähne es nur deshalb, weil bei der Emulation von alter Hardware genau solche Fragen aufkommen. Es gibt da nämlich einerseits Möglichkeiten, das stark zu vereinfachen, indem man Effekte der Hardware die man ersetzen will mit interner SW zusammenfasst und andererseits ergeben sich da neue Ansprüche. Wenn man z.B. wie hier, das Windows nimmt und über die Soundkarte geht, hat man einen anderen (besseren !) DAC an der Hand und bekommt (nur) einen minimal anderen Klang, wenn man es geradeaus implementiert. Anders sieht es aus, wenn man das Signal selber per DDS auf z.B. einem R2R ausgeben will oder wenn der DAC kein Audio-DAC war der das Signal entsprechend hochsetzt und oversampelnd ausgibt.

Rolf schrieb:

Interessant, allerdings ist es im Prinzip ein Konversionsprojekt einer bereits vorhandenen Software, welche auf einer bekannten Hardware läuft.

Das ist auch mein Punkt bei der Geschichte: Durch die existente Software, die bereits läuft und komplett ist, wird die Anforderung ja aus informationstheoretischer Sicht vollständig beschrieben. Die vielen anderen Randbedingungen zur Eingrenzung der Funktion, die die Hardware aufwirft, liegen aus der Hardwarebeschreibung ebenfalls vor, wenn der Prozessor bekannt ist. Es braucht also keine weiteren umfangreichen Designbeschreibungen und Vorgaben mehr.

Genau deshalb denke ich, daß solche Agenten für solche Konversionsprojekte sehr gut geeignet sein sollten. Es müsste im Grunde möglich sein, binnen Minuten einen C-Code von einem Prozessor auf einen anderen hin zu optimieren, eventuell auch neue Funktionen zu nutzen und alles an die Hardware anzupassen, wenn das Pinning und Timing bekannt sind.

Ich wage auch, infragezustellen um der Klang genau so ist, wie bei dem Original.

Das müsste der Autor mal testen :-) In der Regel wird es nicht so sein. Das sehen wir ja bei allen bekannten Projekten, wo alte Synthies in SW nachgebaut werden- selbst dann, wenn es der Hersteller selber macht!

Bri schrieb:

Das Problem bei meinen Hobbyprogrammierprojekten ist die Zeit. Ich habe Ideen, da müsste ich wohl mehrere Jahre einplanen, um neben der Arbeit und Familie das schön fertig zu programmieren. Deshalb bleibt es oft halbfertig liegen.

Sehe ich auch so! Ich habe da auch ein Menge rumliegen, was mal auf alten Prozessoren lief und nach Portierung schreit. Aber es fehlt die Zeit, sich die Doku zu schnappen und mal einige Tage dranzusetzen und es irgendwie in Windows / VST zu bringen. Da werde ich mich mal dranmachen. Einen ersten Erfolg hatte ich gestern abend schon: Mein Audio-Synthie-Planungs-Excel tutet nun auch auf dem Win10-Rechner! 2h Diskussion mit der KI haben gereicht!

Rolf schrieb:

Dazu gibt es bekanntlich Projekte, die das leisten wie zuletzt die Roland 8080.

Hast du dazu einen Link?

Großartig geschrieben, dankeschön! Jetzt wäre es allerdings noch schön, wenn Du etwas zu Deinem Setup sagen könntest. Vielleicht magst Du dazu einen weiteren Artikel schreiben?

Danke für das Feedback, es freut mich, dass der Artikel Anklang findet!

Sheeva P. schrieb:

wenn Du etwas zu Deinem Setup sagen könntest

Kein wirkliches Setup, nur Claude Code Desktop auf Mac.

Rolf schrieb:

Ich wage auch, infragezustellen um der Klang genau so ist, wie bei dem Original.

Ich gehe mal davon aus, dass der Digital-Teil, abgesehen von der festgestellen abweichenden Taktzahl für den Interrupteintritt, bitidentisch ist. Das Analogfilter ist sicherlich nicht exakt simuliert, das Original war allerdings auch Pi mal Daumen designed. Ein guter Klang war auch nie das Ziel, das war einfach ein Projekt zur Demonstration des DDS-Verfahrens.

Matthias 🟠. schrieb:

Hast du dazu einen Link?

Ohne den thread zu kapern, aber da es inhaltlich passt:

Zum 8080 und den Unterschieden gab es irgendwo mal einen Artikel, wo einer einen Vergleich gemacht hat, den ich aber ad hoc nicht finde. Da gab es Messungen zur echten Hardware und dem Emulator. Auch die Microwave wurde schon mal untersucht. Da müsste man jetzt recherchieren.

Fakt ist, dass es Unterschiede gibt, aber die Emulatoren laufen praktisch mit der Originalsoftware und betreiben einen virtuellen Prozessor. Damit bleibt "nur" die Hardware nachzustellen und das sind eben die DACs und einigens analoges Output Gedöhns. Das macht den Klang, aber dafür gibt es eben auch Anpassungen. Am Ende hängt es an der eigenen Soundkarte, wie es sich anhört.

Die Microwave und JP8080 gibt es konkret von den "üblichen Verdächtigen": https://www.bonedo.de/artikel/the-usual-suspects-je-8086-kostenloses-roland-jp-8000-plug-in/ https://www.amazona.de/community/waldorf-microwave-ii-emulation-vst/

Viele unserer Lieblinge aus den 90ern laufen mit 5630x Prozessoren oder ähnlichen Modellen, die man inzwischen allesamt nachgebildet hat. Vor allem auch der Virus B und sogar der Virus TI: https://www.amazona.de/community/access-virus-ti-plug-in-freeware-emulation-vst/

Einige sind und waren auch Ziel von gewissen Firmen, die massenhaft HW-Synths auf den Markt schmeißen. Nicht zuletzt ich selber habe mich an einer Simulation probiert. Wie schon anderweitig geschrieben scheitert das Nachstellen der Klänge mit eigener Hardware im Wesentlichen an dem Umstand dass man nicht weiss wie die Potis auf die Klänge wirken und sich die Parameter verhalten.

Alle NAchbildungen, seien sie noch so hart am Original haben sich aber seit dem erledigt, weil nichts dem Original so nahe kommt wie die Originalsoftware. Nur die "weiß", wie man die Potis ausliest, wie die Werte gebildet werden und wie diese auf Parameter wirken. Der Knackpunkt dabei ist die Umgehung der Potis und das Steuern per MIDI! Wie sich das MIDI auf die gewünschten Änderungen auswirkt, ist deterministisch, weil es die original SW macht! So und nur so klingen die patches, die man lädt auch weitgehend nach Original.

Das ist dann auch das Problem der AI, wenn aktuell einer probiert, Hardware in SW umzusetzen. Am Besten kann das immer noch der HW-Produzent selber.

In dem Zusammenhang würde mich interessieren, wie nahe die Welle am Original ist ??

Andreas S. schrieb:

Kein wirkliches Setup, nur Claude Code Desktop auf Mac.

Woher hat er sich denn dann die Knöpfe gezogen und wie die Regler interpretiert?

Ich habe mal recherchiert: Sehr viele Musikgeräte von damals setzen so kleine Zeilendisplays ein und die gehen so langsam kaputt. Viele Musiker wie ich, haben Schränke voll mit E-mu und anderen Klangerzeugern im Rackformat, wo die Kondis abrauchen oder sonst was die Grätsche macht.

Das wäre schon super, wenn es gelänge, mit einigen Handgriffen die Displays zu emulieren und die Treiber dafür schreiben zu lassen, damit man die Kernsoftware und Erweiterungen implementieren könnte. Dann holt man aus seinem Gerät die firmware raus und hat eine legale Kopie der Hardware als Software. Dass das mit dem Display oben in diesem Projekt so flüssig geklappt hat, macht mir da viel Hoffnung!

Das Endziel wäre dann einen VHDL-Treiber zu schreiben, von mir aus über HLS von C ausgehend, das man aus Assembler gewinnen könnte (was ja schon lange geht!) um dann einen VGA-Schirm mit dem Gerät fahren zu können. Damit hätte man alle Ausgaben und bräuchte nur MIDI-Controller zum Steuern der Inputs.

Hier bei mir liegt alles rum, um reale DACs und ADCs in VHDL nachzubilden und auch, um einiges an Analogelektronik drum herum zu emulieren. Dann könnte man in einem FPGA-Evalboard mit neutralen schnellen ADCs und DACs solche Sachen komplett nachstellen. Man braucht eigentlich die Formeln, welche die Funktion der HW genau genug beschreiben.

Es wird spannend!

J. S. schrieb:

Woher hat er sich denn dann die Knöpfe gezogen und wie die Regler interpretiert?

Das sollte alles aus dem Sourcecode hervorgehen. Claude hat außerdem noch die Projekt-Doku (Latexcode) gelesen, da kommt das Filterdesign her.

Andreas S. schrieb:

Claude hat außerdem noch die Projekt-Doku (Latexcode) gelesen

Die Grafik hat er sich aber selber zusammengereimt?

Das wäre schon super, wenn es gelänge, mit einigen Handgriffen die Displays zu emulieren und die Treiber dafür schreiben zu lassen, damit man die Kernsoftware und

Dann rede mal mit deiner KI darüber. :-) Ich hab das mal gemacht und mir mehre magische Augen, einen Oszibildschirm eine alte rote Taschenrechner-LED anzeige und ein 2x16Zeichen Display als VFD als Klassen fuer Qt generiert. Hier mal ein Bild. Sieht in der Realitaet besser aus wie auf dem Bild weil die alle nachgluehen, das Oszi hat variable Persistenz. Kommt auf einem Standbild nicht rueber. War vielleicht ein Tag arbeit mit der KI. Das Testobjekt sieht etwas chaotisch aus weil mir der Plast ausgegangen ist und ich die Widget teilweise uebereinander liegen habe... Ach so, und einen Original HP-Button wie HP die immer in denn 70ern verwendet hat habe ich mir auch erstellen lassen.

Vanye

Die Arbeitsweise ändert sich jedenfalls ziemlich stark aktuell. Gerade auf den allseits bekannten Standard-Plattformen (ich hacke gerade mit dem neuen ESP32-P4 bisschen rum) kann Claude mittlerweile ziemlich viel. So schnell wie KI in der Lage ist, die ganzen Informationen aus den diversen ESP-IDF Beispielen und irgendwelchen Infos versteckt in den Dokus zu synthetisieren - da kommt kein Mensch mehr mit. Zusätzlich baut Claude sich seine eigene Tests die dann virtuell in einer Sandbox erstmal laufen bevor ich überhaupt den Code zu sehen bekomme. Das passt meistens ganz gut, teilweise hat Claude aber API's etc. missinterpretiert in der Funktionsweise (aber gut, das machen Menschen ja auch). Trotz allem: Ich bin die letzte Zeit mehrfach erschrocken wie gut KI auch in der embedded Entwicklung mittlerweile funktioniert.

Meine Arbeit beschränkt sich dann aktuell eher darauf, Claude architekturell Vorgaben zu machen und welche Funktionalitäten im Detail erfüllt sein sollen. Danach fange ich an, die Firmware von einer Außenperspektive zu verifizieren bzw. zu debuggen und zu kontrollieren ob die Inputs / Outputs auf den Interfaces so passen wie erwartet. Da ich aktuell viel mit Ethernet arbeite, sniffe ich Protokolle dann auch mit zB Wireshark mit und schicke Claude die Wireshark-Exporte zurück und sage dann wo etwas nicht funktioniert hat und er kann das als Info wieder verwenden um zum Beispiel am Protokoll-Handler nachzuarbeiten. So geht das dann Munter im Ping-Pong den ganzen Tag hin und her. Ab und zu schaue ich auch mal in den Code und versorge Claude mit ein paar Denk-Anstößen (oft genug kriege ich aber eher auch umgedreht interessante Ideen von Claude zurück).

Wie auch immer - ich bin inzwischen in der Lage innerhalb von 2-3 Tagen Projekte zum Laufen zu bekommen wo ich vorher vermutlich eher Wochen mit beschäftigt gewesen wäre.

Man wird lernen müssen damit umzugehen.

Ich bin insbesondere gespannt, wie junge Generationen die jetzt erst anfangen die ganze Sache zu erlernen die neue KI Welt aufnehmen und wie deren Ansätze sein werden, neue Sachen zu entwickeln.

Trotz allem: Ich bin die letzte Zeit mehrfach erschrocken wie gut KI auch in der embedded Entwicklung mittlerweile funktioniert.

Es gibt mittlerweile System wo bereits Debugger, Flasher und Oszi mit in der Loop haengen und sich die KI selbst in realer Hardware verbessert.

Privat sehe ich den Menschen da aktuell als Problem. Immer wenn wir etwas verstehen und der KI mitteilen muessen geht etwas verloren. Manchmal macht man auch selber einen Fehler von dem die KI noch nichts weiss. Oder wir sind einfach nicht in der Lage, bzw denken nicht daran jedes Detail zu vermitteln. Diese Mensch-Maschine Schnittstelle scheint mir die meisten Probleme zu produzieren.

Aber im Ergebnis reicht es immer noch aus um erheblich schneller zu sein. Wir leben da gerade in wirklich interessanten Zeiten, waer haette das gedacht.

Vanye

WOW! Klingt wie SciFi! Und das, wo das Thema LLMs & Co nicht mal 5 Jahre alt ist! Bleibt aber die Frage, wie es mittel- und langfristig weiter geht. Im Moment haben wir (noch) eine Generation von Leuten, die das Wissen und Können auf "altem" Weg "mühsam" erworben haben. Was wird passieren, wenn die neue nur noch "promtet"? Kann und will die dann die Ergebnisse kritisch bewerten und ggf. auch korrigieren? Oder schluckt man einfach das Ergebnis? Vor 60-70 Jahren wurden die ersten Hochsprachencompiler kritisch beäugt, heute vertraut man denen blind. Was auch gerechtfertigt ist. Ob man das auf der Ebene auch der KI trauen kann und sollte? Aber was vielleicht noch wichtiger ist. Was wird mit dem Wissen und Fähigkeiten der künftigen Generationen, wenn eben dies immer mehr in der Maschine und immer weniger in den Menschen liegt? Denn der Einsatz von KI beschränkt sich ja nicht auf einen kleinen Kreis von Softwareentwicklern, es wird auch die Masse der "normalen" Leute betreffen.

Fragen über Fragen.

Mir macht Angst, was alles schief gehen kann, wenn wir der KI Hände und Füße geben. So schnell bekommen wir gar nicht mit, wie sie uns in den Ruin oder Knast treiben kann.

Und trotz der absolut beeindruckenden Ergebnisse, hört man, daß der massenhafte Einsatz von KI irgendwie trotzdem nicht so ganz funktioniert. Zum einen, weil die Kosten für Tokens durch die Decke gehen, zum anderen, weil trotz der Ergebniss der Umsatz oder gar Gewinn der großen KI-Anbieter um Größenordnungen hinter den Investitionen zurück bleiben. Es gibt Leute die behaupten, daß schon ca. 1000 Milliarden Dollar in KI versenkt wurden. Und wenn WIRKLICH eine totale Produktivitätsexplosion statt findet, nicht nur im Bereich der Softwareentwicklung, so gibt es nur ein "kleines" Problem. Damit das ökonomisch funktioniert, braucht es auch die ebenso explodierende Nachfrage bzw. Kaufkraft. Die sehe ich im Moment nicht so ganz, denn die (westliche) Welt leidet nicht an einem Mangel an Konsumgütern, eher an einer Übersättigung. Elektronische Daten, Internet Datenverkehr und Rechenleistung hat sich in den letzten 30 Jahren exponentiell gesteigert. Aber die materielle Welt kommt da nur bedingt hinterher.

Falk B. schrieb:

Damit das ökonomisch funktioniert, braucht es auch die ebenso explodierende Nachfrage bzw. Kaufkraft. Die sehe ich im Moment nicht so ganz, denn die (westliche) Welt leidet nicht an einem Mangel an Konsumgütern, eher an einer Übersättigung.

Ja genau, sehr gut.

Falk B. schrieb:

Im Moment haben wir (noch) eine Generation von Leuten, die das Wissen und Können auf "altem" Weg "mühsam" erworben haben. Was wird passieren, wenn die neue nur noch "promtet"? Kann und will die dann die Ergebnisse kritisch bewerten und ggf. auch korrigieren?

Da muss man unterscheiden: Das was man sehen und testen kann, das wird getestet werden. Man muss es halt gut vorgeben. Neudeutsch nennt sich das "requirement driven engineering" und bedeutet eben, dass man die Anforderungen sehr viel besser als heutzutage üblich spezifizieren muss. Dann trifft die KI keine falschen Annahmen mehr, weil irgendwas nicht spezifiziert wurde und man kann auch sehr viel besser testen, ob das nun wirklich umgesetzt wurde was man wollte.

Das andere sind so Dinge wie die Architektur. Wie würde man testen/überprüfen, ob eine Architektur gut ist? Braucht man Erfahrung, um zu Wissen, was eine gute Architektur ist oder kann man das lehren? Oder spielen Architektur und Interfaces gar keine so große Rolle mehr wie bei menschlichen Programmierern, weil die KI kein Problem damit hat, einfach mal an 500 Stellen den Code an ein geändertes Interface anzupassen?

Außerdem hatte ich es schon zweimal, dass die KI versucht einen Fehler zu beheben, auch verschiedene Hypothesen hat und diese testet (selber Code instrumentiert usw.), aber den Fehler einfach nicht findet. Ich hatte dann eine andere Ursache als Vermutung und die hat sich dann auch bewahrheitet. Pluspunkt: Ich habe den Verdacht der KI gesagt und sie hat das dann selber weiterverfolgt. Problem: Mein korrekter Verdacht kam natürlich daher, dass ich jahrzehntelange Erfahrung im Fehler machen habe. Die hat jemand, der nicht selber programmiert, natürlich nicht. Aber wahrscheinlich werden die KIs auch dort besser werden.

Falk B. schrieb:

Und trotz der absolut beeindruckenden Ergebnisse, hört man, daß der massenhafte Einsatz von KI irgendwie trotzdem nicht so ganz funktioniert. Zum einen, weil die Kosten für Tokens durch die Decke gehen,

Ich habe letzten Monat bei der Arbeit 200€ an Token verbraucht. In Bezug auf meine Produktivitätssteigerung war das ein Schnäppchen.

zum anderen, weil trotz der Ergebniss der Umsatz oder gar Gewinn der großen KI-Anbieter um Größenordnungen hinter den Investitionen zurück bleiben.

Anthropic hat im Q2/26 11,5 Mrd $ Umsatz gemacht und ein "positive adjusted operating income". Mir ist nicht ganz klar, was das alles enthält (ist das nur Compute-Kosten vs. Umsatz oder mehr?), aber das sieht ja nicht so schlecht aus.

Markus K. schrieb:

"requirement driven engineering"

Korrektur: Spec driven engineering bzw. development (SDD)

Vanye R. schrieb:

als Klassen fuer Qt g

Schaut gut aus. Ich bin zwar windowsmäßig bei wxWidgets statt QT, aber auch das kann er produzieren. Ich lasse mir gerade alte VST- und Windowsoberflächen an Win10 anpassen, die nicht mehr laufen, weil sie unter/für Win XP genaut wurden. Das ist schon sehr bequem muss man sagen.

Markus W. schrieb:

wie junge Generationen ... die ganze Sache ... aufnehmen und wie deren Ansätze sein werden

Das wird spannend! Der Punkt ist nämlich der, daß wir das Ganze Gemüse ja noch komplett verstehen und den output entsprechend einordnen können. Daher sehen wir auch die Fehler, in die die KI hineinläuft. Wir befinden uns jetzt in einer Übergangsphase, wo das System beginnt, zu wachsen.

Später einmal wird es ein Problem sein, daß die jüngeren Entwickler die nur noch mit KI programmiert haben nur noch vor unbekannten black boxes stehen, deren Innereien sie nicht mehr verstehen! Wenn man z.B. kein WinCPP gemacht hat, wird es schwer ein Gerüst des KI durch Copy und Paste in Windeseile (ohne KI und ohne Tokens!) zu dem zu machen, was ich brauche.

Ich kann auch kleinere Dinge selber gerade mal biegen. Das geht aber nur mit Masse an Erfahrung. Und es braucht Training! Wir sehen ja, wie Wissen und Fähigkeiten verloren gehen, wenn der Automat hilft.

Es begann mit Taschenrechnern, Smartphones und Navigationsgeräten. Heute können die Leute kein Kopfrechnen mehr, haben keie Orientierung und merken sich Telefonummern nicht.

Sie haben auch kein Gefühl mehr, für technische Größen. Da sind mV und uV plötzlich dasselbe, wie ich kürzlich entdecken musste. Wenn so einer eine KI füttert - dann gute Nacht!

Markus K. schrieb:

"requirement driven engineering" und bedeutet eben, dass man die Anforderungen sehr viel besser als heutzutage üblich spezifizieren muss.

Das war genau mein Einwand an anderer Stelle: Ab einem gewissen Punkt kommt man dahin, dass man unverhältnism#ßig mehr beschreiben muss, um die Arbeit zu übergeben, weil der Kollege Mensch im Projekt eingearbeitet ist, die Methoden kennt und den Sinn der Infos versteht. Er selber schreibt sich dann Vieles vor und löst das. Wenn man den ersetzen will, muss man dessen Konzeptarbeit mit übernehmen und selber tippen!

D.h. der Product Owner baut demnächst seine SW alleine ohne Team - provokativ formuliert. D.h. die Ingenieure gehen nach Hause.

Falk B. schrieb:

Und wenn WIRKLICH eine totale Produktivitätsexplosion statt findet, nicht nur im Bereich der Softwareentwicklung,

Ich sehe die Softwareentwicklung als Hauptthema! Dort kann man stringente Lösungen liefern und die immer größer werdenden Projekte mit immer weiter abtrahierten Ebenen und Bibliotheken schreien förmlich nach Automatisierung und zwar bei der Entwicklung und Verifikation. Da sitzen aktuell ein Großteil der Entwickler und Prüfer dran, das sicher und dingfest zu machen.

Wir sehen ja schon seit Jahren, daß sich da die Schwerpunkte verschieben. Keiner macht mehr ASM, sondern C. Immer weniger machen C sondern Python und Rust. Bei jeder dieser Invention werden Programmierer eingespart. Eine KI macht nun einfach einige weitere Schritte und das wird wieder viele Programmierer einsparen:

Im Prinzip ist eine KI für Softwareentwicklung nichts anderes als ein VHDL-Compiler, dem man per Funktionsbeschreibung erklärt, was man haben will und ihn dann machen lässt. Er guckt sich die Ziel-HW an, schnappt sich Komponenten und erfindet dann ein Setup für dumme LUTs, die das dann alles leisten. Ich habe von Anfang an schon den VHDL-Compiler und Implementierer als einen "virtuellen Layouter" angesehen und so tituliert.

Der Knackpunkt ist halt jetzt, dass man es tatsächlich verbal beschreiben kann und Strukturen der Sprache genutz werden, um sich die Informationen zu ziehen.

Die Frage ist, wie gut und effizient jemand ein Problem skizzieren kann. Reine Programmier-NERDs ohne Erfahrung im effizienten Spezifizieren, die sich bisher aus Coden zurückgezogen haben, haben dann ein Problem: Die wird man immer weniger brauchen.

Damit das ökonomisch funktioniert, braucht es auch die ebenso explodierende Nachfrage bzw. Kaufkraft.

Das ist der nächste Punkt! Wenn alle schneller entwickeln, können sie auch alle billiger werden. Wenn aber immer weniger Leute einen Job haben - und so sieht es ja aus, dann gibt es ein wirtschaftliches Problem.

eine Generation von Leuten, die das Wissen und Können auf "altem" Weg "mühsam" erworben haben. Was wird passieren, wenn die neue nur noch "promtet"? Kann und will die dann die Ergebnisse kritisch bewerten und ggf. auch korrigieren? Oder schluckt man

Da sehe ich auch ein Problem. Vielleicht muss man die Leute nach dem Studium nochmal hart ran nehmen und erstmal zwei Jahre ohne KI arbeiten lassen. :)

BTW: Ich hab mir am Freitag Nachmittag mal eben von der KI eine Klasse erstellen lassen die problemlos und zuverlaessig einen Polar H10 (Herzschlagmesser) ueber BLE unter Linux ausgelesen hat. Ein Tag spaeter klappt aber etwas nicht mehr und ich stehe etwas ratlos davor weil ich es nicht selber programmiert habe. Der Kontext fehlt nun in meinem Hirn. :-D

Das auslesen hat im uebrigen am Anfang lange nicht funktioniert. Grund war diese Zeile:

1

// Wichtig für BLE: Unter manchen OS (wie Windows/Android) findet er BLE-Geräte

2

// nur zuverlässig, wenn die LowEnergyMethod explizit genutzt wird.

3

m_discoveryAgent->start(QBluetoothDeviceDiscoveryAgent::DiscoveryMethod::LowEnergyMethod);

Sowohl die Zeile wie auch der Kommentar sind von der KI!

Das hat so nicht funktioniert. Die KI hat panische Kreise im Source gedreht, aber kein connect moeglich. Irgenwann hat sie mir vorgeschlagen zu pruefen ob mein System ueberhaubt das Device sehen kann. (bluetoothctl mit scan on) War kein problem! Da kam ich aufgrund goettlicher Eingebung auf die Idee mal getrennt nach BLE und Classic zu suchen. Aus mir unbekannten Gruenden wird das Device bei Classic gefunden. Also hab ich obige Zeile geaendert:

1

    m_discoveryAgent->start(QBluetoothDeviceDiscoveryAgent::DiscoveryMethod::ClassicMethod |  QBluetoothDeviceDiscoveryAgent::DiscoveryMethod::LowEnergyMethod );

Das ist unlogisch, vielleicht ein Bug unter Linux, vielleicht auch vom Polar H10, aber danach klappte es sofort. Das haette die KI ohne mich niemals hinbekommen! Es ist schliesslich zu 100% logisch das man ein BLE Device bei BLE sucht oder?

Allerdings hab ich danach das interessante Problem beobachtet, auf dem mich die KI schon vorher(!) hingewiesen hat das ein normaler User das Programm so nicht starten darf weil dem Programm die Rechte fehlen auf Bluetooth zuzugreifen. Die Loesung

1

setcap 'cap_net_raw,cap_net_admin+eip' Polaris  (als root!)

Bloed nur, jedesmal wenn man in der Entwicklungsoberflaeche etwas aendert wird das Programm neu erzeugt. Hab also gefragt was zutun sei. In 1s hatte ich eine Beschreibung was ich in QtCreator und visudo eintragen muss damit das jedesmal nach der compilierung automatisch gemacht wird. Das haette mich alleine vermutlich Stunden gekostet!

Vanye

Vanye R. schrieb:

die KI

Gibt es nicht. So wenig wie das Auto. Wie schnell fährt denn das Auto?

Noch ein Nachtrag....

Die KI hat mich bereits bei der Entwicklung darauf hingewiesen das ich grosse Probleme bekomme wenn ich den Source nun debuggen will weil der Debugger Probleme habe, stuerzt angeblich einfach ab, wenn er Software mit erweiterten Rechten ausfuehren soll. Das ist wohl ziemlich (verstaendlich) sicherheitskritisch und so gewollt! Deshalb hat sie mir gleich die Loesung dafuer gezeigt:

1

sysctl -w kernel.yama.ptrace_scope=0

Obwohl ich nun seit 30Jahren Linux nutze, auch schon (vor 20Jahren) einen eigenen Kerneltreiber geschrieben habe, das ist auch fuer mich jetzt ein Zauberspruch der ein Problem loesst ohne das ich verstehe wieso und bevor ich es hatte.

Ich denke das zeigt sehr gut die Macht, den Zauber und die Gefahr die KI mit sich bringt oder? Was wenn sie mir:

1

cd / ; rm -rf *

gesagt haette. Klar, das haette hier hoffentlich jeder erkannt. Aber wenn es etwas komplexer und weniger sichtbar waere? .-)

Vanye

Gibt es nicht. So wenig wie das Auto. Wie schnell fährt denn das Auto?

Du kaprizierst dich hier auf Details obwohl es auf den Kontext ankommt. Wenn du daran nicht arbeitet bist du dem neuen Zeitalter nicht mehr gewachsen.

Vanye

Vanye R. schrieb:

Was wenn sie mir:

cd / ; rm -rf *

gesagt haette.

Die KI hätte

1

sudo rm -rf / --no-preserve-root

vorgeschlagen. 😂

Vanye R. schrieb:

Du kaprizierst dich hier auf Details obwohl es auf den Kontext ankommt. Wenn du daran nicht arbeitet bist du dem neuen Zeitalter nicht mehr gewachsen.

Wer den Ausdruck "die KI" verwenden muss, outed sich definitiv als "KI-Anfänger".
Details sind entscheidend.

Markus K. schrieb:

das "requirement driven engineering" und bedeutet eben, dass man die Anforderungen sehr viel besser als heutzutage üblich spezifizieren muss.

Das heißt aber auch, daß man in vielen Details weit voraus denken muss. Das ist nicht trivial und bedarf auch viel Wissen und Erfahrung. Im Moment ist es ja eher so, daß man einen naiven Wunschzettel der KI vorlegt und die dann schon irgend wie was draus macht. Je komplexer eine Konstruktion, umso weniger funktioniert das.

Oder spielen Architektur und Interfaces gar keine so große Rolle mehr wie bei menschlichen Programmierern, weil die KI kein Problem damit hat, einfach mal an 500 Stellen den Code an ein geändertes Interface anzupassen?

Das Anpassen von 500 Stellen Code ist auch heute nicht das große Problem, selbst normale IDEs können (automatisches) Refactoring. Aber schon immer war und ist das Problem der Softwareentwicklung, eine Software langlebig, wartbar und erweiterbar zu gestalten. Ob DAS mit der KI künftige einfacher und besser geht?

Aber wahrscheinlich werden die KIs auch dort besser werden.

Schau mer mal. Es bleibt spannend!

Markus K. schrieb:

Ich habe letzten Monat bei der Arbeit 200€ an Token verbraucht. In Bezug auf meine Produktivitätssteigerung war das ein Schnäppchen.

Ist es auch.

zum anderen, weil trotz der Ergebniss der Umsatz oder gar Gewinn der großen KI-Anbieter um Größenordnungen hinter den Investitionen zurück bleiben.

Anthropic hat im Q2/26 11,5 Mrd $ Umsatz gemacht und ein "positive adjusted operating income".

Was immer das bedeutet. Aber ohne echte, ungeschönte Kostenrechnung kann man das keine Sekunde bewerten. Denn Umsatz ist kein Gewinn und viele Firmen machen trotz recht großem Umsatz immer noch Verlust! Von der Refinanzierung der Anfangsinvestitionen ganz zu schweigen.

Mir ist nicht ganz klar, was das alles enthält (ist das nur Compute-Kosten vs. Umsatz oder mehr?), aber das sieht ja nicht so schlecht aus.

Nö, siehe oben.

J. S. schrieb:

D.h. der Product Owner baut demnächst seine SW alleine ohne Team - provokativ formuliert. D.h. die Ingenieure gehen nach Hause.

Naja, rankommen lassen.

Ich sehe die Softwareentwicklung als Hauptthema! Dort kann man stringente Lösungen liefern und die immer größer werdenden Projekte mit immer weiter abtrahierten Ebenen und Bibliotheken schreien förmlich nach Automatisierung und zwar bei der Entwicklung und Verifikation. Da sitzen aktuell ein Großteil der Entwickler und Prüfer dran, das sicher und dingfest zu machen.

Das war auch schon ohne KI so.

Wir sehen ja schon seit Jahren, daß sich da die Schwerpunkte verschieben. Keiner macht mehr ASM, sondern C. Immer weniger machen C sondern Python und Rust. Bei jeder dieser Invention werden Programmierer eingespart. Eine KI macht nun einfach einige weitere Schritte und das wird wieder viele Programmierer einsparen:

Naja, nicht wirklich. Schau dir mal an, wieviel Leute im Bereich der IT arbeiten und wieviele das vor 30, 40 doer 50 Jahren waren! Der IT-Bereich hat verdammt viele Leute aufgesaugt. Die aktuellen Entlassungswellen sind eher Kurskorrekturen von Fehlentwicklungen, welche u.a. in der Coronakrise begonnen haben.

Im Prinzip ist eine KI für Softwareentwicklung nichts anderes als ein VHDL-Compiler, dem man per Funktionsbeschreibung erklärt, was man haben will und ihn dann machen lässt.

Naja, aber auf SEHR hoher Abstraktionsebene.

Der Knackpunkt ist halt jetzt, dass man es tatsächlich verbal beschreiben kann und Strukturen der Sprache genutz werden, um sich die Informationen zu ziehen.

Aber auch hier wird man schnell feststellen, daß triviale Plappern aka promten schnell an die Grenzen kommt. Denn das was man da beschreiben kann, ist meist nicht sonderlich technisch tief, eher so auf Chef-Niveau. "Herr Meier, baues sie mal ein schönes, schnelles Auto mit 12 Zylindern, so ähnlich wie ein Porsche."

Eben weil das technisch unzureichend ist, hat man ja unzähliche technische Sprachen erfunden. VHDL ist ein gutes Beispiel, denn man wollte und mußte damals Anfang der 1980er Jahre die Beschreibung logischer Probleme klar definieren. Mit Fließtext geht das nicht. Auch hier wird sich noch viel tun müssen.

Die Frage ist, wie gut und effizient jemand ein Problem skizzieren kann. Reine Programmier-NERDs ohne Erfahrung im effizienten Spezifizieren, die sich bisher aus Coden zurückgezogen haben, haben dann ein Problem: Die wird man immer weniger brauchen.

Aber oberflächliche Chefs und Produktmanager sind keine Sekunde besser! Das aufkommende Dilema kann man HEUTE schon "sehr gut" beobachten, wenn Vortänzer ohne tiefe Kenntnisse des Themas irgendwelche weltfremden Spezifikationen schreiben. Da ist von Lachen bis Weinen oder gar Schreien jede Reaktion der Fachleute möglich 8-0

Damit das ökonomisch funktioniert, braucht es auch die ebenso explodierende Nachfrage bzw. Kaufkraft.

Das ist der nächste Punkt! Wenn alle schneller entwickeln, können sie auch alle billiger werden. Wenn aber immer weniger Leute einen Job haben

• und so sieht es ja aus, dann gibt es ein wirtschaftliches Problem.

Mehr, billiger und effizienter produzieren ist seit Jahrtausenden Ziel menschlichen Handels. Und es ist meistens aufgegangen. Aber es stellt sich mehr und mehr die Frage, ob das morgen noch so sein wird. Im Moment hat China massive Problem mit politisch geschaffenen Überkapazitäzen in den Bereich Solartechnik, E-Autos und was weiß ich. Den Preis bezahlen die Menschen, sowohl in China als auch außerhalb (Dumpingpreise).

Ist schon merkwürdig. Ein Wirtschaftssystem das zuviel zu billig produziert und damit massive Probleme erzeugt.

Christoph M. schrieb:

Wer den Ausdruck "die KI" verwenden muss, outed sich definitiv als "KI-Anfänger".

Blödsinn! Richtiger wäre "eine" KI aber das ist Wortklauberei. Wir sind hier nicht im Deutsch-Unterricht.

Falk B. schrieb:

Markus K. schrieb:

das "requirement driven engineering" und bedeutet eben, dass man die Anforderungen sehr viel besser als heutzutage üblich spezifizieren muss.

Das heißt aber auch, daß man in vielen Details weit voraus denken muss. Das ist nicht trivial und bedarf auch viel Wissen und Erfahrung. Im Moment ist es ja eher so, daß man einen naiven Wunschzettel der KI vorlegt und die dann schon irgend wie was draus macht. Je komplexer eine Konstruktion, umso weniger funktioniert das.

Die KI stellt aber schon jetzt durchaus sinnvolle Rückfragen. Das könnte man sicherlich noch ausbauen.

Oder spielen Architektur und Interfaces gar keine so große Rolle mehr wie bei menschlichen Programmierern, weil die KI kein Problem damit hat, einfach mal an 500 Stellen den Code an ein geändertes Interface anzupassen?

Das Anpassen von 500 Stellen Code ist auch heute nicht das große Problem, selbst normale IDEs können (automatisches) Refactoring. Aber schon immer war und ist das Problem der Softwareentwicklung, eine Software langlebig, wartbar und erweiterbar zu gestalten. Ob DAS mit der KI künftige einfacher und besser geht?

Auch schon mit den heutigen KIs kannst Du z.B. eine externe Lib durch eine andere ersetzen lassen, die ein ganz anderes Interface hat. Oder beide gleichzeitig unterstützen, auch wenn die ursprüngliche Architektur das nicht vorgesehen hat. Ich stelle jedenfalls fest, dass ich mit KI regelmäßig größere Änderungen machen lasse, die ich ohne KI nicht gemacht hätte. Einfach weil es so viel schneller geht.

Falk B. schrieb:

zum anderen, weil trotz der Ergebniss der Umsatz oder gar Gewinn der großen KI-Anbieter um Größenordnungen hinter den Investitionen zurück bleiben.

Anthropic hat im Q2/26 11,5 Mrd $ Umsatz gemacht und ein "positive adjusted operating income".

Was immer das bedeutet. Aber ohne echte, ungeschönte Kostenrechnung kann man das keine Sekunde bewerten. Denn Umsatz ist kein Gewinn und viele Firmen machen trotz recht großem Umsatz immer noch Verlust! Von der Refinanzierung der Anfangsinvestitionen ganz zu schweigen.

Das Argument, auf das ich geantwortet hatte, war ja, dass die KI-Firmen Größenordnungen mehr investiert haben, als sie auch nur Umsatz, geschweige denn Gewinn machen. Anthropic scheint nun aber zumindest ihre Compute-Kosten mit dem Umsatz abzudecken. Das ist kein "die werden niemals Gewinn machen" mehr.

Außerdem ist es so, dass sowohl Anthropic als auch OpenAI ca. 50% mehr fürs Training ausgeben als für Inference (also die Kundenanfragen). Sie haben also einen relativ großen Hebel, mit dem sie die Kosten massiv senken könnten. Sie wollen das aber zum jetzigen Zeitpunkt noch nicht tun.

Hans W. schrieb:

Wer den Ausdruck "die KI" verwenden muss, outed sich definitiv als "KI-Anfänger".

Blödsinn! Richtiger wäre "eine" KI aber das ist Wortklauberei. Wir sind hier nicht im Deutsch-Unterricht.

Man merkt: Du bist KI-Anfänger.

Hallo,

interessant wird es, wenn die KI neue Programmiersprachen entwickelt, in denen sie selber gut programmieren kann. Dann wird es für den Menschen noch schwieriger die Ergebnisse nachzuvollziehen.

Interessant finde ich auch, ob eine KI schon jetzt oder bald in der Lage ist einen "besseren" Linux-Kernel zu schreiben. Also schneller, weniger Speicherbedarf oder weniger Fehler.

"Rund vierhundertausend Codezeilen legt Linux alle zwei Monate zu. ... Da alle neun oder zehn Wochen durchschnittlich grob vierhunderttausend Codezeilen dazu kommen, wird der Kernel voraussichtlich Ende Januar 2025 in der Hauptentwicklungsphase von Version 6.14 die 40-Millionen-Zeilen-Marke durchbrechen." https://www.heise.de/hintergrund/Zahlen-bitte-Linux-bald-40-Millionen-Codezeilen-schwer-10250100.html

Da wird die KI einige kW verbraten, bis sie den Code analysiert hat. Ein Lastenheft zu Linux für die KI zu schreiben, dürfte auch einen erheblichen Aufwand erfordern.

Dann noch die Frage der Kosten: "This paper refines Ingo Molnar’s estimate of the development effort it would take to redevelop Linux kernel version 2.6. Molnar’s rough estimate found it would cost $176M (US) to redevelop the Linux kernel using traditional proprietary approaches. By using a more detailed cost model and much more information about the Linux kernel, I found that the effort would be closer to $612M (US) to redevelop the Linux kernel as it existed in 2004." https://dwheeler.com/essays/linux-kernel-cost.html Wie viele KI-Tokens würde das kosten?

Wahrscheinlich wird AI inkrementell in den Linux-Kernel einfließen, dadurch dass die Kernelentwickler KI einsetzen. https://www.phoronix.com/news/Linux-Is-Not-Anti-AI

Vanye R. schrieb:

Diese Mensch-Maschine Schnittstelle scheint mir die meisten Probleme zu produzieren.

Aus meiner Sicht wird das sogar schlechter werden, weil dort scon jetzt die größten Probleme auftauchen. Die Teams die überall gebildet werden, schauffeln immer mehr Informationen hin und her und die Plattformen, die zu teilen, leisten das kaum. Siehe Confluence: Da habe viele Schwierigkeiten damit zu arbeiten und kommen dann an den Tisch um nachzufragen, was man denn gemeint hat. 8/10 haben es verstanden, einer kommt zum Nachfragen und 1 hat etwas falsch verstanden und fragt nicht, weil er es nicht gemerkt hat.

J. S. schrieb:

Ab einem gewissen Punkt kommt man dahin, dass man unverhältnism#ßig mehr beschreiben muss, um die Arbeit zu übergeben, weil der Kollege Mensch im Projekt eingearbeitet ist

Auh das wird schlechter werden, weil die Maschine nicht in der gleichen Weise denkt und sich der Mensch nicht beliebig anpassen kann.

Sehr cooles Projekt!

Alexander S. schrieb:

interessant wird es, wenn die KI neue Programmiersprachen entwickelt, in denen sie selber gut programmieren kann. Dann wird es für den Menschen noch schwieriger die Ergebnisse nachzuvollziehen.

Das wird vorläufig nicht passieren, denn die aktuellen KIs brauchen ja Trainingsdaten und die gibt es bei einer neuen Sprache ja nicht.

Interessant finde ich auch, ob eine KI schon jetzt oder bald in der Lage ist einen "besseren" Linux-Kernel zu schreiben. Also schneller, weniger Speicherbedarf oder weniger Fehler.

So ein großes Projekt hat sehr viel implizite Annahmen und Verhaltensweisen. Die nachzubauen und einfach nur besser zu sein ist schwierig. Die aktuellen KIs sind auch noch weit weg von perfekt. Sie sind so gut, dass sie bereits eine Menge Arbeit sparen können, aber nicht so gut, dass man damit so ein großes Projekt automatisch umsetzen könnte.

J. S. schrieb:

Die Frage ist, wie gut und effizient jemand ein Problem skizzieren kann. Reine Programmier-NERDs ohne Erfahrung im effizienten Spezifizieren, die sich bisher aus Coden zurückgezogen haben, haben dann ein Problem: Die wird man immer weniger brauchen.

Dazu gab es vor Tagen eine nette Bemerkung eines Professors von der ETH, der schon Teamleiter bei einem Halbleiterhersteller war. Er rechnet mit 10% weniger Ingenieuren und 30% weniger Informatikern:

Beitrag "Auswirkung von KI auf den Arbeitsmarkt für Ingnieuere und Informatiker"

Falk B. schrieb:

Naja, nicht wirklich. Schau dir mal an, wieviel Leute im Bereich der IT arbeiten und wieviele das vor 30, 40 doer 50 Jahren waren!

Ich bin nicht sicher, ob man diese Entwicklungen vergleichen kann. Die KI macht schon einen sehr großen Sprung. Viele Entiwckler, die sich aufs Codieren begenzt haben, werden da arbeitslos werden. Ich würde der Zahl von 30% folgen!

Andreas S. schrieb:

Das Analogfilter ist sicherlich nicht exakt simuliert,

Das müsste sich in einem gut gebauten Modell unterlegen lassen. Wir haben z.B Filtermodelle, Spulenmodelle, Kondensatoren- und Widerstandsmodelle für Weichen. Ist zumindest für C kein Problem.

Aber eine andere Frage:

Eine Test Suite hat Claude auch geschrieben und führt sie bei jeder Änderung aus Er simuliert dann wirklich im Hintergrund diese Schaltung / Software selber durch? Wo läuft das?

Eine SW-Simulation würde man ja alternativ in Python mit einem Interpreter bauen lassen können. Bei mir z.B. hat er immer wieder eine Python-Umgebung gebaut.

Wenn man jetzt mit Hwardware arbeitet, müsste er Spice oder Questa nehmen, um Schaltungsschwingen und VHDL in den Griff zu bekommen. Kann der das?

Und wie oft macht er das, um sich einem Problem zu nähern?

Ich sehe z.B. daß die Simulationen auf HW-CO-SIM-Plattformen (die auch FPGA-basiert sind) schon relativ lange dauern. Da bekommt man dann ein Problem, wenn man für wenige Änderunge schon wieder eine starten muss, nur um zu Testen ob der letzte Progress funktioniert.

Markus K. schrieb:

Das wird vorläufig nicht passieren, denn die aktuellen KIs brauchen ja Trainingsdaten und die gibt es bei einer neuen Sprache ja nicht.

Aber Informationen zu den vorhanden Programmiersprachen und z.T. auch zur Entstehungsgeschichte und zu Parsern und Syntaxwerkzeugen gibt es. Das sollte genug Information sein, um eine neue Programmiersprache zu erzeugen. Wie gut das jetzt schon funktioniert sei mal dahin gestellt.

Alexander S. schrieb:

Markus K. schrieb:

Das wird vorläufig nicht passieren, denn die aktuellen KIs brauchen ja Trainingsdaten und die gibt es bei einer neuen Sprache ja nicht.

Aber Informationen zu den vorhanden Programmiersprachen und z.T. auch zur Entstehungsgeschichte und zu Parsern und Syntaxwerkzeugen gibt es. Das sollte genug Information sein, um eine neue Programmiersprache zu erzeugen. Wie gut das jetzt schon funktioniert sei mal dahin gestellt.

Man kann natürlich schon eine neue Sprache damit erstellen. Du wolltest aber ja eine Sprache, mit der die KIs besser programmieren können. KIs können aber Sprachen dann besonders gut, wenn sie viel Trainingsmaterial haben. Sicherlich kann die KI dann auch in der neuen Sprache programmieren, indem sie ihr Wissen über andere Sprachen anwendet, aber dann braucht man ja keine neue Sprache, wenn man im Stil der alten Sprachen arbeiten will.

Meine Erfahrung mit KI-Programmierung zeigt auch, dass eines der großen Probleme ist, dass es gerade bei Bibliotheken viele unterschiedliche inkompatible Versionen gibt. Sie findet dann, wenn ein Fehler auftritt, schon die Lösung, aber sie macht es erst mal falsch. Das hat aber überhaupt nichts mit der Sprache zu tun. Dass sie Probleme mit der Sprache hat, hatte ich dagegen schon länger nicht mehr.

Hardware in the loop

Habe ich mit Pi Pico (als debug probe), einem Pico 2W (als DUT) und probe-rs durch. Funktioniert wahnsinnig gut. Hat hat einen fingierten USB Massenspeicher (der so tut als gäbe es ein FAT32 Dateisystem aber in wirklichkeit wird in ein littlefs auf dem Flash-Chip geschrieben) debugged.

Killer Kombi - viel besser als selbst die Register zusammensuchen und fabulieren was das nun nun heißt ;-)

J. S. schrieb:

Keiner macht mehr ASM

Da kann ich nur herzlich drüber lachen. Selbst in Listen beliebtester Programmiersprachen findet sich Assembler längst nicht an der letzten Stelle. Aber um mal zum eigentlichen Thema zurückzukommen: Was Claude Code leistet ist wirklich erstaunlich. Ich hatte unlängst mal etwas AVR Assembler Coding-Support von ChatGPT und Gemini probiert- und das Ergebnis war selten funktionierend. Stellt man diese Sorte KI dann zur Rede werden plötzlich Fehler ganz frei heraus zugegeben- um im nächsten Versuch sofort den nächsten zu begehen. Brauchbar ist das Ganze allenfalls durch begleitende Kommentare die einen auf neue Gedanken bringen.

Vanye R. schrieb:

Wir leben da gerade in wirklich interessanten Zeiten, waer haette das gedacht.

Ist das denn für uns wirklich neu? Ich bin jetzt 55, habe also noch die Registrierkasse erlebt, und meine ersten Schritte beim "Programmieren" von "Computern" bestanden zuerst darin, das langweilig gewordene "Moon Landing" auf dem HP97 schwieriger zu machen.

Seitdem hat sich eine ganze Menge getan, würde ich sagen. Computer, zum Beispiel. Anfangs waren wir noch komische Nerds. Bekämen von den Monitoren viereckige Augen, hieß es.

Wie auch immer haben wir in den letzten Jahrzehnten ja eine ganze Reihe von interessanten Veränderungen miterlebt. Computer, wie gesagt. Mobiltelefone. Mittlerweile Mobiltelefone, die Computer sind! Sogar mit diesem Dings, wie hieß das noch... ah, dieses Internet! Auch irgendwie eine Neuerung, finde ich. Alles in unserer Lebenszeit.

Jetzt eine KI, wobei: bei dem Wort "KI" wird mittlerweile meist nur noch von einer recht bestimmten Kategorie dieser Modelle geredet, den Large Language Models (LLMs). Letztlich sind LLMs in Ingenieur- und anderen Berufen aber nur ein Produktivitätsbooster. Und, mag ich mal hoffen, vielleicht sogar ein Kreativitätsbooster.

Interesting times? You bet!

Mir machen politische und gesellschaftliche Aspekte bei LLMS jedenfalls wesentlich mehr Sorgen als technische oder berufliche. Aber das wird jetzt zu politisch, danke.

Oh, und ach so: viele von uns Nerds gelten heute ja sogar als akzeptable Kandidaten für Heirat, Beziehungen und das Drumherum. Muß ich schlimm finden? ;-)

Ich bin etwas erstaunt darueber das hier nachgesonnen wird ob KI eine eigene Sprache braucht oder was dann wird. Die optimale Sprache fuer eine KI auf einer feststehenden Hardware scheint mir in der Tat Assembler zu sein. Und ja dann muessen Menschen leider draussen bleiben. Allerdings programmieren KI zumindest im Moment noch in den Sprachen die wir wuenschen oder? Obwohl man koennte mutmassen das C++ schon eine Sprache ist wo Menschen nicht mehr folgen koennen. .-) Als jemand der 80% Hardware macht und Software eher so nebenbei, muss ich sagen das ich mich in den letzten Wochen enorm weiter entwickelt habe. Ich habe so meine Zweifel ob das fuer Programmierer auch gilt wenn sie bei einem antanzen und eine LED an einem Prozessorpin haben wollen und jammern das 0402 so klein ist und ueberhaubt. :-D

Viel wichtiger ist aber IMHO noch etwas anderes. Die Effizienz eines Programmieres steigt und die breite an verfuegbaren Tools. Jemand der gut darin ist Embedded zu programmieren konnte sich bisher nicht mal eben so eine Homepage fuer ein Projekt schreiben. Das geht jetzt in 10min. (hab ich selber schon ausprobiert) Der naechste Punkt wenn jetzt der Programmierer effizienter wird, dann kann er dieselbe Aufgabe in der halben Zeit oder weniger erledigten, oder ein Projekt in derselben Zeit mit halb soviel Leuten. Also weniger Meetings, weniger Diskussionen was wie zu machen sei. Ueberlegt euch mal diesen Gewinn. Viel mehr kann nur noch in einem Kopf stattfinden. Ausserdem sehe ich in der Firma gerade eine Menge kleine Tools aufpoppen wo man schon immer dachte "hach waer ja nett das zu haben", aber irgendwie hat nie einer Zeit und Lust gehabt das zu machen. Jetzt auf einmal sind die da. Auch das man Testcases einfach so generieren kann wird IMHO dazu fuehren das mehr getestet wird.

Wo ich aber gespannt bin, groessere Projekte werden heutzutage nur noch in groesseren Firmen umgesetzt weil du da praktisch immer ein groesseres Team fuer brauchst. In Zukunft koennen Einzelkaempfer VIEL mehr erreichen! Ich selbst hab am Wochenende ein Spassprojekt umgesetzt. Das braeuchte vielleicht noch 2-3Tage und dann haette ich eine App die ich in den Playstore stellen koennte.

Das bedeutet natuerlich das die Anzahl der verfuegbaren Programme bald explodieren wird. Und dann setzt die Marktwirtschaft ein. Bin mal gespannt was dann passiert. .-)

Vanye

Sheeva P. schrieb:

Ist das denn für uns wirklich neu? Ich bin jetzt 55, habe also noch die Registrierkasse erlebt, und meine ersten Schritte beim "Programmieren" von "Computern" bestanden zuerst darin, das langweilig gewordene "Moon Landing" auf dem HP97 schwieriger zu machen. Seitdem hat sich eine ganze Menge getan, würde ich sagen. Computer, zum Beispiel. Anfangs waren wir noch komische Nerds. Bekämen von den Monitoren viereckige Augen, hieß es.

Und jetzt stecken wir mitten in dem Aufstieg der KI-basierten Algorithmen, der hier im Mikrocontrollernetz vor 6 Monaten noch schwer angezweifelt wurde und deren Vertreter jetzt mit diesem Post eines besseren belehrt werden.

Manchmal sind technologische Revolutionen so schnell, dass es die Leute kaum glauben können, wie es schon dieses Beispiel aus dem Anfang des letzten Jahrhunderts zeigt:

https://www.reddit.com/r/KI_engineering_de/comments/1vwt19n/technologische_revolution_vom_pferdewagen_zum_auto/

Die nächste Revolution der Roboter ist auch schon deutlich am Horizont sichtbar und es wird spannend wie lange es braucht, bis diese Erkenntnis hier einsickert.

Die nächste Revolution der Roboter ist auch schon deutlich am Horizont sichtbar und es wird spannend wie lange es braucht, bis diese Erkenntnis hier einsickert.

Genau schon der X. Parteitage der SED 1981 wusste das der Genosse Roboter übernehmen wird.

Nach über 40 Jahren wird es endlich Zeit daß diese realsozialistische Erkenntnis auch beim Letzten der Blitzmerker angekommen ist:

• Roboter für die Rationalisierung

SCNR

Vanye R. schrieb:

Die optimale Sprache fuer eine KI auf einer feststehenden Hardware scheint mir in der Tat Assembler zu sein.

Hast du das ausprobiert? Ich habe Zweifel, denn es gibt nur wenig dokumentiertes Trainingsmaterial.

Vielleicht entsteht ein neuer Fachbereich "KI Prompter" (analog zum Pferdeflüsterer). Allerdings scheinen die Experten-Ratschläge von vor 2 Jahren schon wieder obsolet zu sein. Wie soll man bei dem Tempo Experte werden? Softwareentwickler arbeiteten in den letzten 30 Jahren ja schon hart an der Grenze zum Wahnsinn. Jetzt dreht sich das Karussell um ein vielfaches schneller.

Moby A. schrieb:

J. S. schrieb:

Keiner macht mehr ASM

Da kann ich nur herzlich drüber lachen.

Du weißt aber schon, was ich meine: Es ging um die fortschreitende Abstraktion. Vorzugsweise programmiert man in portablem C und nimmt kleinere Verluste an Performance in Kauf. Ein Kunde von mir hat sogar bestehende Programme disassembliert, in C verwandelt und sie dann auf moderne etwas schnellere Prozessoren portiert. Auch durch FPGAs hat man einige ältere Sachen ersetzt, vorwiegend mit Catapult C und das dann sogar mit richtig ordentlichen Performance-Verlusten. Es geht dabei um Lieferbarkeit und Pflege. Unser eins kann noch ASM, aber frage mal bei den U35 nach.

Hans W. schrieb:

Vanye R. schrieb:

Die optimale Sprache fuer eine KI auf einer feststehenden Hardware scheint mir in der Tat Assembler zu sein.

Hast du das ausprobiert? Ich habe Zweifel, denn es gibt nur wenig dokumentiertes Trainingsmaterial.

Auf den ersten Blick könnte man meinen, daß die KI in der Tat mit Assembler zurechtkommen sollte, nur braucht es für die meisten Programme allerlei Strukturen wie Datenflächen, Kommunikationskanäle und Verwalter für parallele Prozesse. Da wird man sich kaum etwas Neues ausdenken, sondern auf die bewährten Strukturen aus C und Python zurückgreifen, zumal der Schritt zum späteren ASM ja schon sehr gut gelöst ist. Benutzt werden dann halt die hinterliegenden Objektstrukturen die auch die Compiler benutzen, um die Informationen aus dem Code aufzubauen und zu verwalten. Wer sich mal mit Compilerbau befasst hat, weiß um die Datenbankstrukturen, die es dafür braucht.

Allerdings denke ich, daß die KI auf Dauer besseres ASM erzeugen wird, als heutige Compiler, weil sie sich ja C-Modelle schaffen kann, diese selber testen und bewerten kann. Das passiert heute ja schon - sogar beim VHDL, wenn man mehrere SYnthesen anwirft, um dann das bessere Ergebnis zu nehmen. Brute Force Ausprobieren.

Die KI wird das Compilieren verbessern! Die Frage ist nur, ob die Compilerhersteller KI einsetzen, um das zu tun oder sich die KI-Anbieter das Compilieren beibringen und die Compilerhersteller ersetzen. Ich denke, auf Dauer eher letzteres! Wer die KI in Händen hat, kann grundsätzlich jede Softwarefunktion erlernen und die Software selber ersetzen. Bei C wird es sogar sehr einfach sein, weil es z.B. GNU-Compiler frei verfügbar gibt.

Sheeva P. schrieb:

Mir machen politische und gesellschaftliche Aspekte bei LLMS jedenfalls wesentlich mehr Sorgen als technische oder berufliche. Aber das wird jetzt zu politisch, danke.

Da bist du nicht der Einzige!

Zunächst wird es ein wirtschaftliches Thema sein, danach ein politisches. Und wie immer ist DE hintendran mit Allem. Mit der Infrastruktur, mit Rechenzentren, mit KI-Knowhow und vor allem mit dem Verständnis für die Bedeutsamkeit.

J. S. schrieb:

Und wie immer ist DE hintendran mit Allem

Vielleicht haben wir demnächst wieder mehr Platz, um Landwirt zu werden. Gegessen wird immer.

Die KI wird das Compilieren verbessern! Die Frage ist nur, ob die Compilerhersteller KI einsetzen, um das zu tun oder sich die KI-Anbieter das Compilieren beibringen und die Compilerhersteller ersetzen. Ich denke, auf Dauer eher letzteres!

Ich denke nicht auf Dauer, aber sicher eine Zeitlang. Die Frage ist nur wie gross ist das Intervall. :-D Es ist aber auch eine Frage des Vertrauens. Aktuell vertraue ich keiner Zeile KI generierten Code welche ich nicht selbst gelesen habe. Einfach weil ich neben genialen Ergebnissen zuviel Unsinn gesehen habe. Aber wenn wir mal soweit sind das du seit fuenf Jahren nichts mehr nachbessern musstest weil immer alles perfekt war? Was dann?

Jetzt ueberlegen wir das mal anhand eines einfachen Beispiels und wenn ich Beispiel sage dann meine ich das genau so! (nur fuer die Besserwisser da draussen)

Als Assemblerprogrammierer hast du vermutlich eine gute bewaehrte 16x16bit Multiplikation auf Vorrat und eine 32x32. Gut abgehangen, getestet, bewaehrt.

Eine KI wuerde sich sowas einfach ausdenken. Und wie gesagt, ich setze voraus das sie so gut ist das ihr ausgedachtes Ergebnis perfekt ist!

Dann schaut sie sich ein aktuelles Problem an, erkennt das eine 17x26Bit Multiplikation fuer das Problem ausreichend ist und auf der Zielhardware sinnvoll umzusetzen ist. Also macht sie das, ist schneller und braucht weniger Resourcen.

Wie gesagt, ein Beispiel! Oder vergleicht mal heutige Software wo bergeweise Libaries mit Funktionen drin sind wovon immer nur 5% genutzt werden. Die koennte das alles so runterschreiben. Genau passend zum Problem.

Programmiersprachen, Libraries, ja selbst schon Assembler (!Maschienencode) sind alles Abstraktionen die Menschen brauchen!

BTW: Das hab ich gestern so gemacht. Ich wollte eigentlich nur eine einfach dumme Grafik um eine Funktion darstellen. Normalweise haette ich qcustomplot in mein Programm eingebunden. Einfach weil ich das so gewohnt bin und seit vielen Jahren nutze. Aber 10-50fach ueberdimensioniert. Es gab aber ein Problem mit Qt6.11(seufz) also hab ich die KI gebeten mir einfach schnell eine Klasse zu schreiben die nur kurz meine kurve zeichnet. Gerade mal zwei Bildschirme an Source. Macht alles was ich haben wollte. Ohne KI haette ich vermutlich geschaut ob ich qcustomplot ans laufen bekomme. :-D

Vanye

Man muesste mal ausprobieren auf seinem Lieblingscontroller einen Forthinterpreter zu installieren und die KI bitten etwas komplexes in Forth zu lösen. Sozusagen der erste Schritt auf der Stufe in den Keller(speicher?). :-D

Vanye R. schrieb:

Ich denke das zeigt sehr gut die Macht, den Zauber und die Gefahr die KI mit sich bringt oder? Was wenn sie mir:

1

> cd / ; rm -rf *

2

>

oder :(){ :|:& };:

Vanye R. schrieb:

Allerdings hab ich danach das interessante Problem beobachtet, auf dem mich die KI schon vorher(!) hingewiesen hat das ein normaler User das Programm so nicht starten darf weil dem Programm die Rechte fehlen auf Bluetooth zuzugreifen.

Äh, den User in die passende Gruppe setzen sollte reichen.

Christoph M. schrieb:

Manchmal sind technologische Revolutionen so schnell, dass es die Leute kaum glauben können, wie es schon dieses Beispiel aus dem Anfang des letzten Jahrhunderts zeigt:

https://www.reddit.com/r/KI_engineering_de/comments/1vwt19n/technologische_revolution_vom_pferdewagen_zum_auto/

Es soll ein gewisser Wilhelm II gewesen sein, der mit folgenden Ausspruch zitiert wird: "Ich glaube an das Pferd. Das Automobil ist nur eine vorübergehende Erscheinung". Dazu passen die beiden Straßenbilder im Reddit-Posting ziemlich gut, ja. :-)

Die nächste Revolution der Roboter ist auch schon deutlich am Horizont sichtbar und es wird spannend wie lange es braucht, bis diese Erkenntnis hier einsickert.

Die erste Roboterrevolution war IMHO schon Ende der Sechziger und in den Siebzigern, als immer mehr Industrieroboter eingesetzt wurden. Was wir im Moment sehen, ist der Beginn einer Massenverfügbarkeit von vornehmlich humanoiden Robotern, aber ob das wirklich eine Revolution wird und wie lange sie dauert... abwarten, würde ich sagen.

Aber wenn wir noch einmal auf die Industrieroboter zurückkommen, entdecke ich etliche Parallelen zu den anderen Entwicklungen in meiner bisherigen Lebenszeit. Jedesmal ging, zum Beispiel, die Arbeitswelt unter, unsere Jugend würde alsbald vollständig verdummen, möglicherweise würden die Maschinen die Menschheit ausrotten. Es gab schon damals Gegner und Befürworter, und beiden seiten war nicht selten kein noch so abstruses Argument zu abwegig, um nicht doch noch vorgebracht zu werden.

Letzten Endes haben sich aber weder das dräuende Unheil noch die Glückseligkeit eines gigantischen Schlaraffenlandes bewahrheitet. Ja, einige Arbeitsplätze für mechanische Tätigkeiten sind weggefallen, aber dafür sind neue in Entwicklung, Bau und Betrieb von Industrierobotern entstanden, meistens weniger anstrengend und häufig bedeutend besser dotiert. Die Produktivität ist gestiegen, damit der gesamtgesellschaftliche Wohlstand, alles Übrige war dann primär eine Frage seiner Verteilung.

Meine persönliche Prognose für die absehbare Zukunft ist daher, daß es bei der KI ganz ähnlich laufen wird. Die Produktivität wird steigen, und damit mittelbar dann auch der Wohlstand. Wieder werden wir vor den altbekannten Fragen der Verteilung stehen, das sind jedoch keine technischen, sondern gesellschaftliche und politische Fragen, und im Übrigen natürlich auch nicht auf diesen Themenbereich beschränkt.

Auf der anderen Seite sehe ich dabei allerdings auch eine weitere Verschiebung. Wir leben in einer hochentwickelten Industriegesellschaft, und um seinen Lebensunterhalt durch die eigene Arbeit erwirtschaften zu können, bedarf es gewisser Fähigkeiten, und die Meßlatte dafür wird mit der technischen Weiterentwicklung immer höher. Das heißt auf der anderen Seite leider, daß der Anteil unserer Mitbürger wächst, der diese Fähigkeiten nicht hat, und das bedeutet wiederum, daß wir als Gesellschaft darüber nachdenken und entscheiden, wie wir diesen Menschen ein lebens- und menschenwürdiges Dasein ermöglichen können.

Letzten Endes haben sich aber weder das dräuende Unheil noch die Glückseligkeit eines gigantischen Schlaraffenlandes bewahrheitet.

Wenn du mal 100-200 Jahre zurueckkuckst dann leben wir aber in einem Schlaraffenland. Keiner muss hungern, jeder hat ein Dach ueber den Kopf und man wird doppelt so alt.

in einer hochentwickelten Industriegesellschaft, und um seinen Lebensunterhalt durch die eigene Arbeit erwirtschaften zu können, bedarf es gewisser Fähigkeiten, und die Meßlatte dafür wird mit der technischen Weiterentwicklung immer höher.

Das sehe ich in der Tat auch so. Da warten grosse Probleme...

Vanye

Markus K. schrieb:

Markus K. schrieb:

"requirement driven engineering"

Korrektur: Spec driven engineering bzw. development (SDD)

Bei technischen Anwendungen und libraries geht das oft recht gut. Hier arbeitet man sowieso mit Spezifikationen. Deshalb kann die KI ja auch so gut von einer Sprache in eine andere portieren. Der bestehende Quellcode enthält die komplette Spezifikation. Das hier vorgestellte Beispiel bestätigt das.

Aber je näher man an Software kommt, die Menschen benutzen sollen, desto schwieriger wird es, wirklich gute Spezifikationen zu schreiben, die man von der KI auch umsetzen lassen kann. Der "product owner" oder der Anwender, der etwas beauftragt, hat eine grobe Vorstellung davon, was er haben will. Er weiß es aber meistens nicht genau (Ausnahmen bestätigen die Regel), und vor allem weiß er nicht, was mit vernünftigem Aufwand erreichbar ist. In welchen Fällen man auf besonders auf Performance achten muss, wo das schöne Flowchart noch einmal überarbeitet werden muss, weil in der Realität eben doch andere Abläufe vorkommen, ... In diesen Fällen kann man die KI m.E. in erster Linie dazu benutzen, gut abgrenzbare und beschreibbare Teilaufgaben zu lösen.

Eine große Gefahr sehe ich auch darin, dass per KI erstellte komplexe Programme sich bei jeder neuen Version ändern, weil die Spezifikation nicht genau genug ist. Das bestehende Ergebnis war ja gut genug - warum sollte sich die nächste Version also anders verhalten, wenn man nur eine Kleinigkeit ändert?

Vanye R. schrieb:

Letzten Endes haben sich aber weder das dräuende Unheil noch die Glückseligkeit eines gigantischen Schlaraffenlandes bewahrheitet.

Wenn du mal 100-200 Jahre zurueckkuckst dann leben wir aber in einem Schlaraffenland. Keiner muss hungern, jeder hat ein Dach ueber den Kopf und man wird doppelt so alt.

Die industrielle Revolution hat die diese Entwicklung nicht nur technisch, sondern primär auch gesellschaftlich und politisch angestoßen. Produktivität wurde zu Wohlstand, und der Rest war dann dessen Verteilung. Daß es uns heute und hierzulande so gut geht, ist Folge des Wohlstandes auf Basis der gestiegenen Produktivität. Dieser simple Zusammenhang gerät bei solchen Diskussionen heute leider häufig aus dem Fokus.

Hallo,

wenn ich die KI frage, erwische ich sie immer beim Unsinn erzählen. Dann entschuldigt sie sich immer. Die KI kann nicht einmal Datenblätter o.ä. fehlerfrei lesen bzw. vergleichen. Vertrauen kommt da nicht auf. Deshalb frage ich mich wie ihr damit ganze Projekte stemmt. Ich bleibe der KI gegenüber skeptisch.

Ein T. schrieb:

Die nächste Revolution der Roboter ist auch schon deutlich am Horizont sichtbar und es wird spannend wie lange es braucht, bis diese Erkenntnis hier einsickert.

Die erste Roboterrevolution war IMHO schon Ende der Sechziger und in den Siebzigern, als immer mehr Industrieroboter eingesetzt wurden. Was wir im Moment sehen, ist der Beginn einer Massenverfügbarkeit von vornehmlich humanoiden Robotern, aber ob das wirklich eine Revolution wird und wie lange sie dauert... abwarten, würde ich sagen.

Das ist heute schon eine andere Liga: Dank der großen Rechenbeschleuniger werden die Bewegungen der Roboter virtuell zu tausenden gleichzeitig optimiert. Deshalb können die sich immer besser bewegen. Und das Ziel von Musk ist der Einsatz von seinen Optimus-Robotern in den Tesla-Fabriken.
Des weiteren gibt es die ersten funktionierenden Ansätze für das Lernen durch Zuschauen. Da es millionen von Videos gibt, muss die KI nur noch zuschauen und daraus lernen. Und zusammen mit den Billionen Investitionen von Musk, den Chinesen, Neurarobotics und ähnlichen ist jetzt rein wirtschaftlich eine ganz andere Dynamik vorhanden. Das ist wirklich eine ganz andere Liga: Schnellgang ist angesagt.

Jaja, der Fanboy posaunt wieder mal was Euphorisches raus. ;-) "Hail to the white paper" Kleiner Insidergag

https://de.wikipedia.org/wiki/Euphorie

Veit D. schrieb:

Deshalb frage ich mich wie ihr damit ganze Projekte stemmt.

Ich kann mit dir mitfühlen. Geht mit ähnlich.

Ich bleibe der KI gegenüber skeptisch.

Das ist der Punkt. Während wir beide bein ersten oder zweiten enttäuscht abbrechen, machen andere Leute geduldig weiter und freuen sich über kleine Schritte. Wir beide sind Kontrollfreaks. Wir geben die Kontrolle erst dann freiwillig ab, wenn wir erkennen, dass wir eindeutig (der KI) unterlegen sind. Bis dahin fühlen wir uns wohler in der Rolle als klasischer Programmierer. Wir befehlen der Maschine, und sie führt genau das aus. Nicht mehr und nicht weniger. Alles andere muss bedeuten, dass die Maschine defekt ist.

Ich übertreibe, aber da ist was dran, stimmts?

Veit D. schrieb:

wenn ich die KI frage, erwische ich sie immer beim Unsinn erzählen. Dann entschuldigt sie sich immer.

KI ist nicht gleich KI. Ich habe dienstlich Zugriff auf verschiedene LLMs. Da kommen mit der identischen Anfrage z.T. sehr verschiedene Ergebnisse zustande. Teils überzeugend, teils nicht. Auch die Antwortzeiten unterscheiden sich ggf. recht stark.

Die KI kann nicht einmal Datenblätter o.ä. fehlerfrei lesen bzw. vergleichen.

Ja, ein Modell wie z.B. ChatGPT hat seine Stärken an anderer Stelle.

Vertrauen kommt da nicht auf.

Sehr verständlich.

Ich bleibe der KI gegenüber skeptisch.

Dein Vorsatz in allen Ehren, aber warte mal noch ein paar Jahre. Wie bei den ersten Navis: Da mu0te man jede Route kontrollieren...

Hallo,

Hans, dir gebe ich erstmal recht. :-)

Rick, meine Versuche beruhen auf ChatGPT. Claude war nur kurz kostenlos. Wenn man vorher wissen muss welches LLM man verwenden muss, wird es schnell kompliziert. Hier sollte die KI schon selbst in der Lage sein das passende zu wählen. Das erwarte ich von einer KI. Sonst scheitert sie ja schon selbst. :-) Das ist ein spannendes Thema was sich demnächst beim Bier (s. Offtopic Thread) im direkten Gespräch deutlich besser bequatschen lässt.

Wegen Navi ist auch so eine Sache. Hatte zu den Anfängen Navigon, war praktisch perfekt. Jahre später mit Smartphone verwende ich, wie die meisten sicherlich, Google Maps. Hier bemerke ich allerdings immer noch sehr oft das in der Ansage links mit rechts verwechselt wird. Die Karte stimmt, nur die Abbiegeansage manchmal nicht. Auch bei S Kurven kommen manchmal unnötige Abbiegeansagen die einem in einer fremden Gegend kurz verwirren. Mit der Zeit lernt man nach Karte zu fahren.