Seite 1 von 1

Vibe-Coding Experience

Verfasst: 13.03.2026, 20:21
von Jonathan
Ich war ja immer sehr skeptisch was AI angeht, aber habe jetzt doch mal Zeit gefunden, eigene Erfahrungen zu sammeln. Hier ein kleiner Erfahrungsbericht. Meine Meinung hat sich übrigens tatsächlich geändert, aber anders als ich erwartet hätte.

Anwendungsfall war eine kleine GUI Anwendung um Mediendateien mit ffmpeg zu bearbeiten - stell ich irgendwann vlt. mal separat vor. Es gab davon eine alte Variante in Python (ein Skript das ffmpeg Commands generiert hat) mit einer Qt GUI obendrauf - was ein bisschen schrecklich war, weil es unglaublich umständlich auf anderen PCs zu installieren war. Nachdem ich es irgendwann mal über eine halbe Stunde nicht geschafft habe, ein Python Environment so einzurichten, dass Qt seine räudigen dlls findet, hatte ich die Schnauze voll und mir geschworen, nie wieder GUI mit Python zu machen.

Ich wollte mir eh Flutter anschauen, weil das halt Android sehr gut kann, aber eben auch nativ auf Windows laufen soll. Eine neue Sprache, für zwei neue Dinge die ich machen will, das klingt sinnvoll. Einstiegshürde ist natürlich dennoch hoch, wenn man nur eine kleine Anwendung schreiben, aber dafür macht man heute ja Vibe-Coding. Ich habe dann direkt das Claude-Pro Abo für 20€ im Monat genommen, es gibt auch kostenlose oder sogar OpenSource Alternativen, aber KI entwickelt sich schnell, da macht es schon einen echten Unterschied ob man die neusten und besten Tools benutzt oder nicht.

Ich hatte ja schonmal eine ganz ähnliche Anwendung gemacht, also konnte ich dem Agenten gut erklären, was wir brauchen und das wurde dann schrittweise umgesetzt und getestet. Super nützlich ist, dass man nicht nur Code schreiben lassen kann sondern auch brainstormen kann ("Welche Optionen fallen dir ein, folgendes Feature umzusetzen?" "Ich würde das gerne soundso machen, aber übersehe ich damit etwas?"). Und man kann auch einfach Verständnisfragen stellen. Statt permanent zu googeln bleibe ich die ganze Zeit in meinem IDE Chat.

Ich traue der KI natürlich nicht, also wurde nebenher git benutzt und nach jedem Entwicklungsschritt getestet und ein händischer commit gemacht. Wenn es mir das zerschießt hab ich so zumindest Zwischenschritte an denen ich immer weiter machen kann.

Kommen wir zu den überraschenden Erkenntnissen:

1. Der Agent denkt recht lange. Ich tippe nur noch sehr wenig und habe plötzlich sehr viel Zeit. Ich kann Videos in 2-5 Minuten Segmenten gucken während im Hintergrund Code erzeugt wird. Das ist irgendwie auf eine absurde Art entspannend. Das googeln entfällt komplett, und damit die Flut an nutzlosen Informationen (selbst mit Werbeblocker), die mein Gehirn durchfiltern muss. Beispielsweise, diese StackOverflow Antwort die vielversprechend aussieht, aber vlt. nutzlos und damit Zeitverschwendung ist - ich muss permanent entscheiden, ob sich weiterlesen wohl lohnt. Das Warten nervt zwar manchmal etwas, aber irgendwie ist es auch besser, als selber zu arbeiten. Ich habe den Kopf herrlich frei.

2. Es war ein Einstiegsprojekt in Dart und Flutter um eine neue Sprache zu lernen. Lustigerweise wurde dieses Ziel krachend verfehlt. Anfangs habe ich jeder Code-Änderung von Hand zugestimmt, schnell ließ ich aber ganze mehrstufige Arbeitsschritte autonom ausführen und habe nur noch das Gesamtergebnis überflogen. Das wurde mir dann auch schnell zu viel und ich fing an den Code überhaupt nicht mehr zu lesen. Dieser Wandel hat weniger als 2 Stunden gedauert, was mich doch sehr überrascht hat. Ich habe keine Ahnung, wie mein Code im Detail funktioniert, ich könnte nichtmal alle Dateien aufzählen. Und mich schockiert ein wenig, wie wenig mich das stört.

3. Claude denkt clever mit. Mein Problem wurde gut verstanden (ok, es ist auch irgendwie ziemlich simpel) und meine Anforderungen wurden oft über-erfüllt. Ich will eine Text-Anzeige in der UI und kriege automatisch ein passendes Icon dazu. Ich will eine Info abfragen und das passiert automatisch asynchron im Hintergrund inklusive Warte-Animation. Das kann wohl leicht nach hinten losgehen, wenn das Problem nicht komplett verstanden wurde, in meinem Fall wurde aber sehr viel nützliches automatisch hinzugefügt. Außerdem habe ich selber dutzende Features hinzugefügt, die eigentlich unnötig aber nett sind. Mir doch egal, wenn ich zum dritten mal die Codebase refactoren muss, dann schaue ich halt 10 Minuten länger Videos, bis es fertig ist. Von Hand hätte ich diesen Schnick-Schnack sicher niemals eingebaut. Jetzt hab ich ihn. Nice.

4. Die Qualität ist recht gut. Ja, einmal sollte ein Problem durch eine zusätzliche Abhängigkeit gelöst werden, später stellte sich heraus, dass diese das benötigte Feature nicht hat. Gut, gehen wir halt zurück. Eine handvoll Bugs gab es (es wurde vergessen die GUI zu aktualisieren, wenn sich an einer anderen Stelle etwas geändert hat), aber ehrlich gesagt hätte ich vermutlich mindestens genau so viele Bugs eingebaut. Man muss halt testen und debuggen. Man kann aber auch explizit sagen "Schau mal durch allen Code und suche nach möglichen Fehlern". Er hat dann auch welche gefunden und behoben, angeblich. Insgesamt glaube ich, dass alles robust läuft. Sicher kann ich mir da freilich nicht sein, ich hab den Code ja nichtmal gelesen. Vermutlich hat mein Programm Features von denen ich nichts weiß, weil sie automatisch eingebaut wurden. Die hab ich dann halt auch nie getestet, oh well. Insgesamt bin ich eh nach kurzer Zeit davon ausgegangen, dass alles eigentlich funktionieren sollte und habe sehr wenig von Hand getestet. Ich bin mir recht sicher, dass für simple Programme wie dieses die Code-Qualität viel mehr durch meinen schlampigen Umgang mit dem Agenten als durch KI-Denkfehler limitiert wird. Ich könnte das (mit KI Hilfe) mehr testen und robuster machen - aber selbst dafür bin ich jetzt zu faul geworden. Das ist irgendwie eine echt gruselige Erkenntnis.

5. Tokens kosten. Das 20€ Abo hat tägliche Limits (ansich irgendwie sinnvoll, damit man nicht alles direkt verbrät) und in die laufe ich regelmäßig rein. Irgendwo ist das eine lustige Art zu sagen "für heute haben wir genügend Features implementiert, Zeit für Feierabend". Ich könnte jetzt natürlich von Hand weiter programmieren. Das Problem ist nichtmal, dass ich dafür zu faul bin, sondern, dass ich keine Ahnung habe wie mein Code aufgebaut ist und nichtmal verstehe, wie diese neue Programmiersprache funktioniert. Ich habe also meine eigene Anwendung und volle Kontrolle über den Source, kann damit aber trotzdem nichts machen, wenn ich nicht permanent Münzen in den Automaten schmeiße. Und irgendwie ist das ok für mich, weil es nachvollziehbar ist: Strom ist teuer und ich könnte ja alles lernen, würde ich nur wollen. Dieses eine mal ist das tatsächlich kein "Kapitalismus ist so so böse"-Problem.

6. Natürlich ist das hier der Always-Online Privacy-Albtraum. All meine dummen Fragen und mein ganzer Code fließt an Drittanbieter, die damit werweißwas machen. Aber: Es gibt ja heute schon LM-Studio, und erste Projekte, die auch ähnliche Coding-Agenten in offen und offline umsetzen. Die Modelle sind natürlich nicht ganz mit den kommerziellen vergleichbar, aber das Feld ist ja super aktiv, und OpenSource hinkt den großen irgendwie so 6-12 Monate hinterher - es wird gar nicht mehr lange dauern, bis jeder offline und in privat seine einfachen Anwendungen selber viben kann. Das stimmt mich dann irgendwie recht happy. Die Kontrolle wird wohl zurück kommen.

Naja. Ich mache jetzt erstmal an meinen C++ Spielen, ohne AI weiter. Aber ich habe schon 5 neue Ideen für kleine Apps, sowohl für den PC als auch fürs Handy. Es gibt viele Probleme die eigentlich trivial sind, aber ein nettes Front-End dafür zu schreiben ist nervig. Die werde ich mir in Zukunft vermutlich einfach nebenbei zurechtviben. Ich habe schon immer viel an meinem System rumkonfiguriert, vielleicht hab ich dann bald einen ganzen Satz eigener Anwendungen die genau das machen, was ich brauche. Warum nicht, schreibt sich ja einfach so nebenbei im Hintergrund ;)

Re: Viber-Coding Experience

Verfasst: 13.03.2026, 21:20
von Schrompf
Spannend. Meine Erfahrungen mit KI sind katastophal, wie schon öfter erwähnt. Und ich glaube inzwischen, das liegt daran, dass ich wenig Greenfield und dafür sehr viel Brownfield mache. Und dass ich das bisher nur in Programmiersprachen gemacht habe, die ich wie meine Westentaste kenne. Wenn ich mal von 0 an was machen würde, wär's mir wahrscheinlich auch egal.

Wo soll das noch hinführen. Nicht die KI, die ist selbst in besten Momenten nur von übersichtlicher Kompetenz. Sondern mit der Menschheit, die hier gerade komplett davon entkoppelt wird, sich selbst ein Bild zu machen. Woher sollen in 20 Jahren die SeniorDevs her kommen, wenn jetzt niemand mehr mit dem eigenen Hirn durch die Wand muss. Ich weiß es nicht. Vielleicht findet das menschliche Hirn aber auch darum einen Weg, so wie es bisher alles irgendwie doch gemeistert hat.

Re: Viber-Coding Experience

Verfasst: 13.03.2026, 21:33
von Schrompf
Ich hatte der KI (Claude Code Mittelklasse) die Aufgabe gestellt, in einer C++-Klasse den atomic_shared_ptr durch einen profanen shared_ptr mit Mutex zu ersetzen, weil wir in nem Realtime-Thread dadurch nen Deadlock hatten. Die KI hat einen anderen Mutex dafür verwendet, anstatt einen neuen einzuführen - ok, kann passieren, nahezu alle, aber nicht alle Verwendungen gefunden und mit Lock geschützt. Und dann hatte sie sich selbst eine Checklist geschrieben, die aus Build, Smoketest und so bestand. Der Build starb bereits an der falschen CMake-CommandLine, aber das hat sie nicht davon abgehalten, alle Checkboxen abzuhaken und das Ganze zum Erfolg zu erklären.

Und gleichzeitig hat mir heute jemand von sogenannten Overnight Engineers erzählt, die abends einen Strauß KI-Agenten losschicken und am nächsten Morgen eine Zusammenfassung kriegen, was in der Nacht so geworden ist.

Zwischen diesen beiden Geschichten ist eine riesige Lücke, und ich krieg es nicht in meinen Kopf, wie beides gleichzeitig wahr sein soll.

Re: Viber-Coding Experience

Verfasst: 13.03.2026, 21:42
von Zudomon
Ich verwende bisher nur die freie ChatGPT Version. Für mich ist entscheidend, wie man es einsetzt. Um zu lernen, Schwachstellen zu finden, Speedups, Sprachoptimierungen usw., dafür ist es für mich super. Wie eine Horde Experten, die einem Tipps, Tricks, Codeschnipsel usw. geben kann. Aber immer wenn man etwas größeres Versucht, braucht es mehrere Anläufe, bis es dann auch fehlerfrei wird. Und da merke ich jedes mal, dass es einen großen Unterschied macht, den Code zu verstehen und Fehler darin zu erkennen. Dann kann man zur Not auch selbst ausbessern. Aber ich habe auch schon öfter Funktionen gehabt, die ich dann erstmal wieder entferne, vielleicht sogar wenn diese liefen. Und dafür dann wieder meinen alten Code nehme, der zwar schlechter ist, den ich aber dann auch wirklich verstehe. Darauf kann ich nämlich dann viel besser aufbauen.

Auch wenn ich mich auch leicht verleiten lasse, ich versuche es eher zum lernen zu nutzen... denn wie Jonathan denke ich, dass man schnell zu faul wird, da überhaupt noch was zu lesen. Vor allem, wenn einem die KI dann etliche Seiten um die Ohren haut, wo dann der Code minimal geändert ist. Mal abgesehen davon degeneriert man auch einfach sehr schnell dabei. Und das an der Stelle, wo man eigentlich trainieren sollte, um in Zukunft noch komplexere Probleme zu lösen.

Aber letztendlich ist auch irgendwo die Frage, was man will. Das Konzept, Software von Programmierern umsetzen zu lassen, ist ja nicht neu. Jetzt verschieben sich da ein wenig die Rollen. Wenn man da nur Apps entwickeln lassen möchte und gar kein Interesse hat, sich großartig selbst mit dem Code zu beschäftigen, dann ist das sicher eine Tolle Möglichkeit.
Und irgendwie auch das Äquivalent zu: Ich möchte ein Spiel machen und benutze deswegen eine fertige Engine, weil ich kein Interesse habe, da Zeit und Energie rein zu buttern.

Ein Punkt der noch zu bedenken wäre, ist die Abhängigkeit. Was ist, wenn die Modelle massiv teurer werden? Wenn man Probleme lösen will, die die KI einfach nicht zustande bekommt? Wenn das Unternehmen, was die KI anbietet, insolvent geht?
Aber vielleicht ist das auch gar nicht so gravierend, wenn man das dann lokal hostet.

Insgesamt ein sehr weitreichend und facettenreiches Thema. Ich lese auf jeden Fall sehr interessiert mit!

Re: Viber-Coding Experience

Verfasst: 13.03.2026, 22:54
von Jonathan
Schrompf hat geschrieben: 13.03.2026, 21:33 Und gleichzeitig hat mir heute jemand von sogenannten Overnight Engineers erzählt, die abends einen Strauß KI-Agenten losschicken und am nächsten Morgen eine Zusammenfassung kriegen, was in der Nacht so geworden ist.
Ich habe heute endlich mal folgenden Artikel gelesen, den ich seit längeren in meinen "muss man noch abarbeiten"-Tabs offen hatte: https://steipete.me/posts/2025/shipping ... ence-speed

Und ich muss sagen, ich kann das jetzt ein bisschen mehr nachvollziehen und glauben. Dieser Typ scheint sich ja vor wahnsinniger Produktivität gar nicht mehr retten zu können. Da bin ich sicherlich nicht, aber ich kann mir jetzt vorstellen, wovon er redet.
Schrompf hat geschrieben: 13.03.2026, 21:33 Zwischen diesen beiden Geschichten ist eine riesige Lücke, und ich krieg es nicht in meinen Kopf, wie beides gleichzeitig wahr sein soll.
Ich weiß es auch nicht. Ich glaub dir halt auch deine Erfahrungen direkt. Meine App war auf der einen Seite wirklich trivial, ein paar kleine GUI Buttons mit halbwegs simpler Logik. Funktioniert Vibe-Coding nur bei trivialen Probleme? Vielleicht. Aber auf der anderen Seite, gibt es davon halt wirklich, wirklich viele. Wenn wir die alle schonmal gelöst hätten, wäre es ja auch super.

Vielleicht ist C++ auch so kompliziert oder heutzutage zu nischig. Meine Erfahrung war, dass HTML+CSS super generiert wird, Typst aber komplett kaputt ist. Also letztendlich auch wieder ein Subset von Problemen die funktionieren, wenn andere scheitern.

Zu Greenfield vs. Brownfield: Versteht am Ende KI ihren eigenen Code besser als fremden? Das wäre ein bisschen gruselig, weil es irgendwie so extrem menschlich klingt. Ich finde es auch immernoch komplett absurd, dass "AI Reasoning" einfach nur Notizzettel mit Plain-Text sind. Das ist cool zum debuggen, aber nach meinem Verständnis ist es auch einfach genau, wie es intern funktioniert. Es hat vermutlich sogar Nachteile, weil es viele Tokens verbraucht (man könnte die selben Ideen gewiss auch kompakter kodieren, oder nicht??), aber scheinbar ist die "dumme" Lösung auch echt einfach die gute.
Schrompf hat geschrieben: 13.03.2026, 21:20 Wo soll das noch hinführen. Nicht die KI, die ist selbst in besten Momenten nur von übersichtlicher Kompetenz. Sondern mit der Menschheit, die hier gerade komplett davon entkoppelt wird, sich selbst ein Bild zu machen. Woher sollen in 20 Jahren die SeniorDevs her kommen, wenn jetzt niemand mehr mit dem eigenen Hirn durch die Wand muss. Ich weiß es nicht. Vielleicht findet das menschliche Hirn aber auch darum einen Weg, so wie es bisher alles irgendwie doch gemeistert hat.
Das macht mir auch massive Sorgen, ehrlich gesagt. Unsere Schüler sind ja scheinbar heute schon durchschnittlich viel dümmer, als einem lieb sein sollte, und das scheint in Zukunft nicht besser zu werden. Es geht ja nicht nur um Entwickeln und Arbeit. Wenn Kinder heute nichtmal mehr Aufsätze ohne Hilfe schreiben können, dann gehen ja ganz grundlegende Denkfähigkeiten verloren. So wie manche Menschen heute schon ohne GPS keine Strecken länger als 500m mehr navigieren können. Ufff.

"so wie es bisher alles irgendwie doch gemeistert hat" - ich möchte dazu anmerken, dass bisher noch jedes große Menschenreich zugrunde gegangen ist. In irgendeiner Form werden Menschen mit Sicherheit überleben - ob das aber auch für die Zivilisation gilt, ist eine andere Frage.


Zurück zur KI: Ein Problem könnte sein, dass Training einfach zu teuer wird. Es gibt zwar Reasoning, aber "in der Dokumentation" nachschlagen geht zwar für Details (eine obskure, aber kompakte neue Abhängigkeit), aber vor allen Dingen sind die Modelle gut, weil sie so viel gelerntes Wissen haben. Aber das ist halt vom Wissensstand des Trainings. Gerade ist ja alles gehypt, ob KI heute als kostendeckendes Geschäftsmodell betrieben werden kann, ist mir nicht ganz klar, manche Aussagen dazu sind recht widersprüchlich. Wenn man aber mindestens einmal im Jahr ein neues Großes Modell trainieren muss, und das auch einfach mit jedem mal immer teurer wird, dann wäre es vorstellbar, dass man da in eine Sackgasse läuft. Mal ganz davon abgesehen, dass wir bald keine Trainingsdaten mehr haben könnten, weil der Großteil des Internets KI generiert ist. Selbstständig lernende Modelle könnten ein Ausweg sein, Finetuning auch, aber ob das alles am Ende kostendeckend sein wird, ist eine andere Frage.

Re: Viber-Coding Experience

Verfasst: 13.03.2026, 23:24
von Alexander Kornrumpf
Schrompf hat geschrieben: 13.03.2026, 21:33 Ich hatte der KI (Claude Code Mittelklasse)
Unter der Annahme, dass du damit Sonnet meinst, vergiss es. Probier Opus 4.6 aus.

Ich versteh schon wie das von Außen aussieht ... über Jahre haben uns die entsprechenden Influencer erzählt dass "es" das nächste Modell "jetzt aber mal wirklich" sein würde und über Jahre war das nächste Modell dann irgendwie immer noch nicht so richtig gut.

Zwischen Sonnet und Opus liegen für Coding Welten.

Re: Viber-Coding Experience

Verfasst: 13.03.2026, 23:56
von xq
Jonathan hat geschrieben: 13.03.2026, 22:54 Ich weiß es auch nicht. Ich glaub dir halt auch deine Erfahrungen direkt. Meine App war auf der einen Seite wirklich trivial, ein paar kleine GUI Buttons mit halbwegs simpler Logik. Funktioniert Vibe-Coding nur bei trivialen Probleme? Vielleicht. Aber auf der anderen Seite, gibt es davon halt wirklich, wirklich viele. Wenn wir die alle schonmal gelöst hätten, wäre es ja auch super.

Vielleicht ist C++ auch so kompliziert oder heutzutage zu nischig. Meine Erfahrung war, dass HTML+CSS super generiert wird, Typst aber komplett kaputt ist. Also letztendlich auch wieder ein Subset von Problemen die funktionieren, wenn andere scheitern.
Ich melde mich auch nach langer Zeit mal wieder zu Wort:

Mein Vibe Coding ist grade sehr stark und ich embrace das. Mittwoch mit Kumpels Diskussion gehabt, dass es für den Propeller 2 ja gar keinen gscheiden Compiler gibt. Donnerstag morgen so: "Jo, ich hab doch noch Claude Pro, lass mal ausprobieren" und jetzt ist es Freitag Abend und mein Compiler spuckt mir optimierten Assembler-Code aus.

Klar, das Tool ist jetzt nicht fertig, aber WTF es geht. Wir reden da mittlerweile von 15000 Zeilen C# (ausgewählt weil statisch, hat codeanalyse und ist weit verbreitet, daher gut für LLMs).

Ich fahre so einen komischen hybriden Ansatz aus Claude Code (Opus), Codex (GPT 5.4), Test Driven Development und alle paar Stunden mal selber ein paar Zeilen tippen.

Trotzdem ist es für das, was ich tun will, sehr produktiv, nämlich: "Rumspielen und gucken obs geht."

Auf Arbeit haben wir jetzt auch GitHub Copilot und das tut erstaunlich gut, habe heute auch Multi-Track-Coding exerziert und einfach nen mittleres Ticket an einem Tag erschlagen.

Ich glaube Schrompfs Problem ist tatsächlich, dass er LLMs auf C++ werfen möchte, woran sich wahrscheinlich auch erfahrene Coder die Zähne ausbeissen können.

Ich hab auf jeden Fall Spaß, grade privat mixed mode zu entwickeln.

Dinge, auf die ich Bock habe, schreibe ich selbst. Dinge, die ich einfach nur brauche (irgendwelche Tools) lasse ich mir primär Vibe Coden, weil ich dann nebenher an meinem eigenen Kram arbeiten kann, und das Tool taucht halt eventually mal auf.

Dazu zählt übrigens auch ein RISC-V Emulator, welcher mein OS booten kann, und überraschend schnell ist (knappe 150 Mega-Instructions pro Sekunde auf meinem Laptop)

Bild

Re: Viber-Coding Experience

Verfasst: 14.03.2026, 15:20
von Lord Delvin
Schrompf hat geschrieben: 13.03.2026, 21:33 Zwischen diesen beiden Geschichten ist eine riesige Lücke, und ich krieg es nicht in meinen Kopf, wie beides gleichzeitig wahr sein soll.
Dein Problem hast du auch mit Menschen. Wenn du diesen Menschen jetzt KI als Werkzeug gibst ... ;)

Re: Viber-Coding Experience

Verfasst: 14.03.2026, 16:09
von Krishty
Alexander Kornrumpf hat geschrieben: 13.03.2026, 23:24Ich versteh schon wie das von Außen aussieht ... über Jahre haben uns die entsprechenden Influencer erzählt dass "es" das nächste Modell "jetzt aber mal wirklich" sein würde und über Jahre war das nächste Modell dann irgendwie immer noch nicht so richtig gut.

Zwischen Sonnet und Opus liegen für Coding Welten.
This. Die übliche Erklärung ist: KI-Skeptiker würden keinesfalls 120 €/Monat ausgeben, um ein wirklich starkes Modell zu testen. Darum kommen sie nur mit dem gratis-Modell-Grütz in Kontakt und sehen ihre Annahmen bestätigt. Die Fans genießen die guten Modelle und verstehen umgekehrt nicht, warum der Pöbel nicht begeistert sein kann.

Um das zu prüfen, hatte Astral Codex Ten letztens eine Aktion, bei der Skeptiker ihre Fragen gratis (und dafür öffentlich) den führenden Modellen stellen konnten. Ich muss mal lesen, wie die ausging.

Bild

Re: Vibe-Coding Experience

Verfasst: 14.03.2026, 22:48
von woodsmoke
Wenn man Code nicht versteht, kann man sich den erklären lassen von der KI, habe ich mir sagen lassen.
Man soll auch KI als art Lehrer/Mentor nutzen können. Von bestimmten Lösungen im Code erläutern lassen, bis kurze Zusammenfassung wie das Programm aufgebaut ist. Vielleicht sogar ein Programmlogik Schaubild erstellen lassen, geht das?

Bisjetzt komme ich persönlich mit Vibe-Coding nicht klar. Ich denke es würde mir auch die Freude am programmieren nehmen. Habe es aber nur ein Paar Mal kurz ausprobiert.

Re: Vibe-Coding Experience

Verfasst: 14.03.2026, 23:23
von Chromanoid
Vielleicht sogar ein Programmlogik Schaubild erstellen lassen, geht das?
jup, das geht. erstaunlich gut sogar. Ich würde aber um ein editierbares Format bitten. Sonst kann man (noch) nicht gut editieren.

Ich bin immer wieder sehr begeistert, was da so geht. Als "idea guy" ist KI eine sehr spannende Perspektive. Ich schaffe es seit KI endlich mal wieder hobbymäßig Projekte voran zu treiben. Einfach heftig, wenn man dann kleinere Tools oder Browser-Plugins um die ich sonst wochenlang rumschleichen würde "one shot'ten" kann.

Solange die KI besser wird und weniger lügt oder schmeichelt, sehe ich für die Zukunft der Menschen allgemein eigentlich nicht so ganz ein Problem (direkt durch KI, Geldfeudalismus und Co. sind riesige Probleme). Wissensgewinnung ist mit KI ziemlich cool und individuelle Schulbücher usw. sind plötzlich in greifbarer Nähe. Kreativität, "Taste" und Lust am Entwickeln (im allgemeinn Sinne) sind Eigenschaften, die jetzt gepflegt werden müssen. Das wirkt auf mich wie Utopie. Gruselig finde ich eher automatisierten Betrug und Desinformation sowie natürlich den Frust der Abgehängten. Für beides sehe ich aktuell wenig gute Perspektiven.

Re: Vibe-Coding Experience

Verfasst: 15.03.2026, 01:04
von Krishty
woodsmoke hat geschrieben: Gestern, 22:48Wenn man Code nicht versteht, kann man sich den erklären lassen von der KI, habe ich mir sagen lassen.
Jup. Wenn wir wieder vor einer Spaghetti-Funktion mit 10k Zeilen stehen, kann Claude ziemlich gut erkennen, welche Variable Einfluss auf welche Funktion nimmt und was ein Block Code tut (“diese 170 Zeilen sind ein Scheduler in FIFO-Art mit Anpassungen für XYZ”).

Wo erwähnt wurde, wie schnell KI Dinge implementieren kann: Das Hinzufügen von Code ist das eine, aber der meist overengineered oder einfach Overkill. Im Abspecken von Code (“Was kann hier vereinfacht werden?”) habe ich deutlich schlechtere Erfahrungen gemacht, da habe ich aber noch nicht die kommerziellen Produkte genutzt. (“Diese Anführungszeichen sind überflüssig weil a) b) c) …” – zack, Build kaputt, danke fürs Halluzinieren.)

Re: Vibe-Coding Experience

Verfasst: 15.03.2026, 09:05
von Jonathan
woodsmoke hat geschrieben: Gestern, 22:48 Wenn man Code nicht versteht, kann man sich den erklären lassen von der KI, habe ich mir sagen lassen.
Als mein Programm fertig war hab ich ihn dann gebeten, doch bitte eine Dokumentation zu schreiben. Alle Features auflisten, und erklären in welchen Dateien diese implementiert sind, inklusive Diskussion relevanter Designentscheidungen. Da kamen dann 2 Seiten ordentlich formatierter Markdown Text raus. Man könnte nach mehr Details fragen, aber dafür müsste ich die Dokumentation ja selbst erstmal lesen, was ich bisher noch nicht gemacht habe :D :D :D
Chromanoid hat geschrieben: Gestern, 23:23 Ich schaffe es seit KI endlich mal wieder hobbymäßig Projekte voran zu treiben. Einfach heftig, wenn man dann kleinere Tools oder Browser-Plugins um die ich sonst wochenlang rumschleichen würde "one shot'ten" kann.
Hab gestern mit dem Nullsoft Installer gekämpft. Der benutze eine Custom-Script-Language und, nun, sie ist richtig mies und kaputt. Man kann Ordner per Wildcard hinzufügen, aber die Implementierung ist so kaputt (auf Designseite, glaube ich, ist nichtmal ein Implementierungsproblem) das es nicht produktiv nutzbar ist. Und auf sowas hab ich heutzutage echt keinen Bock mehr. Es kann nicht sein, dass ich nach einer halben Stunde (und mit 20 Jahren Erfahrung) es nicht schaffe, alle Dateien aus einem Ordner zu nehmen, ein paar zu ignorieren, und aus einem anderen Ordner ein paar neue hinzuzufügen. Ich erwarte einfach, das so triviale Dinge nach 5 Minuten funktionieren. Ich will nicht tagelang eine mies designte Sprache lernen, ich hab genügend wichtigere Dinge zu tun.

Ja, aber Dank AI kann ich dann in 5 Minuten ein Python-Script schreiben, dass ein Installer-Script generiert, in dem alle Dateien explizit aufgelistet sind. Und schon kann ich die Auswahl-Logik in Python implementieren und alles ist sauber und tut. Und da ich jetzt die Dateiliste in Python habe, wird auch gleich eine ZIP-Datei erzeugt, für Leute die keine Installer mögen. Jetzt ist meine Pipeline automatisiert, ich habe schöne Installer (das Ergebnis vom Nullsoftinstaller mag ich durchaus, nur die Skriptsprache ist Grütze), und Dinge die simpel sein sollten, waren tatsächlich simpel.

Re: Vibe-Coding Experience

Verfasst: 15.03.2026, 09:51
von Jonathan
claude_m18eM3Jw6N.png
tja.

Re: Vibe-Coding Experience

Verfasst: 15.03.2026, 12:33
von Jonathan
Manchmal will ich QR Codes generieren, z.B. für Links in Präsentationen - die kann man dann bequem abscannen. Es gibt dafür tausend Tools, und noch mehr Webseiten. Ich kenne eine gute, die macht, was ich will. Die meisten anderen sind ja (leider verständlicherweise) kommerziell, zeigen Werbung an, wollen Accounts, bieten einen Softwaredownload an - ihr kennt das. Aber manchmal vergesse ich den Link zu der einen guten Seite. Und überhaupt, warum muss das in der Cloud sein, was geht wen anders an, was für Links ich erzeuge. Also doch lieber eine Offline App.

Jetzt könnte ich suchen, bis ich eine finde, die macht was ich brauche. Idealerweise Open Source, vertrauenswürdig, portable, usw.. Aber heute ist die Alternative dazu, die App selbst schnell zu viben. 2 Absätze tippen, welche Features ich brauche, dann Kaffeetrinken, während im Hintergrund die App baut. Wenn ich zurück komme, ist alles fertig. Ich brauche keine Angst vor Spyware zu haben, ich bin ja selber der "Autor". Ich muss auch nicht mehr 3 verschiedene Apps ausprobieren, bis ich eine finde, die mir passt. Ich entscheide ja alles selber und wenn mir was fehlt, bau ich es schnell ein.

Das ersetzt natürlich kein Programm wie Blender. Ich bin auch (noch) zu paranoid um mein Date-Backup-Tool damit zu schreiben. Aber trotzdem gibt es im Alltag doch viele kleine Problemchen, für die eine GUI-App irgendwie nett wäre. Und jetzt baue ich mir die halt eben schnell selber.

Re: Vibe-Coding Experience

Verfasst: 15.03.2026, 13:01
von Jonathan
Nach ein paar Iterationen ist jetzt alles fertig. Die Anweisungen soweit:
Let's write a new app:

I want an offline app, self contained, to generate Qr Codes. Mostly for URLs, but other types should also be supported.

First, the user selects the type. Then, required input fields are displayed. Finally, generation settings can be changed (e.g. code size etc.). all on one page, things should update automatically. after generation, there should be a save to button.

Currently the folder is a test project, remove everything not related to the QR code app. select a nice color theme for the app.
- UI color should not be pink. make it something more serious
- save button should ask for output folder
- drop foreground and background color selection - they are not needed
- default window size is awkward. the QR code is not even visible without scrolling
- when changing the output size, the QR preview does not change its size
- EMail and SMS options can be dropped
- lets make it 2 column. left side all the inputs, right side the generated QR code and the save button. make sure to adjust the window size accordingly. Can the widgets be packed tighter? There is a low of wasted space currently, making the window unnecessarily big.
- layout is ok, but the window is a bit to high now
- output should have a wide boarder (around 10%)
- save button should ask for filename as well, with reasonable default
write a documentation file. List all features of the program, explain design decisions, discuss dependencies and point to important functions / variables where things are implemented.

Hier ist die generierte Dokumentation (am besten in deinen Lieblings-Markdown-Viewer rüberkopieren):

Code: Alles auswählen

# QR Code Generator — Documentation

## Overview

A self-contained, fully offline desktop application for generating QR codes.
Built with Flutter (Windows primary target). No network access is required at
any point; all encoding and rendering happens in-process.

---

## Features

### QR Types

Six content types are supported. Selecting a type swaps the input fields
immediately; all field values are retained in memory while the app is open so
switching back does not erase previous input.

| Type | Fields | Encoded format |
|------|--------|----------------|
| **URL / Website** | URL | Raw URL string (`https://…`) |
| **Plain Text** | Multi-line text area | Raw string |
| **Phone** | Phone number | `tel:<number>` URI |
| **Wi-Fi** | SSID, Password, Security (WPA/WPA2, WEP, None) | `WIFI:T:<sec>;S:<ssid>;P:<pw>;;` |
| **Contact (vCard)** | First/Last name, Phone, Email, Organisation | vCard 3.0 block (`BEGIN:VCARD … END:VCARD`) |
| **Location** | Latitude, Longitude | `geo:<lat>,<lng>` URI |

### Live Preview

The QR code re-renders automatically on every keystroke — no generate button.
This is achieved by attaching an `addListener(() => setState(…))` callback to
every `TextEditingController` at initialisation time
(`_HomePageState._c`, `home_page.dart:48–51`). An empty-data guard in
`_qrData` (`home_page.dart:61–86`) returns an empty string when the minimum
required fields are blank, which causes the preview panel to show a placeholder
instead of an invalid QR code.

### Output Size

A slider (200 – 1000 px, 16 steps) controls the pixel dimensions of the saved
PNG. The preview scales proportionally: `_displaySize = (_saveSize * 0.38)
.clamp(160, 244)` (`home_page.dart:89`), so moving the slider visibly resizes
the preview as well.

### Error Correction Level

A four-segment button selects the Reed-Solomon error correction level passed
directly to `QrPainter` / `QrImageView`:

| Level | Data recovery |
|-------|---------------|
| L | ~7 % |
| M | ~15 % (default) |
| Q | ~25 % |
| H | ~30 % |

Higher levels produce denser codes. M is the default because it balances
scannability with damage tolerance for typical print use-cases.

### 10 % White Border

Every saved PNG includes a white quiet-zone border equal to 10 % of the output
dimension on each side (`home_page.dart:117–118`):

```
border  = saveSize × 0.1
qrArea  = saveSize − 2 × border   (= 80 % of saveSize)
```

The QR painter is translated by `(border, border)` before painting so the code
sits centred inside the margin. This quiet zone is part of the QR standard and
improves reliable scanning, particularly when the image is printed without
additional margins.

### Text Label Option

A checkbox ("Print content as text below code") appends the raw encoded string
as a human-readable caption. The feature affects both the live preview and the
saved file.

**Preview** (`_PreviewPanel.build`, `home_page.dart:642–654`): a `Text` widget
is conditionally inserted below the QR container; it wraps to three lines
maximum with ellipsis overflow.

**Saved PNG** (`_HomePageState._save`, `home_page.dart:120–141`): the text is
pre-laid-out with `dart:ui`'s `ParagraphBuilder` before the canvas is created,
so the required extra height is known upfront. The total image height becomes:

```
totalHeight = saveSize + textGap + paragraph.height + textGap
```

Font size scales with output size (`saveSize × 0.044`) and the text is
constrained to the same horizontal margins as the QR code itself (`qrArea`
width), ensuring alignment.

### Save as PNG

Clicking **Save as PNG** opens the platform's native *Save File* dialog
(`FilePicker.platform.saveFile`, `home_page.dart:96–101`). The dialog
pre-populates the filename with `qr_<type>.png` (e.g. `qr_url.png`,
`qr_wifi.png`) derived from the enum name. The folder picker is shown
**before** the spinner starts so a cancellation never triggers any rendering
work. A `.png` extension is appended defensively if the user removes it
(`home_page.dart:103`).

Rendering uses `dart:ui` directly rather than a screenshot widget:

1. `QrPainter` encodes the data and provides a `paint(Canvas, Size)` method.
2. A `ui.PictureRecorder` / `Canvas` pair captures all draw calls off-screen.
3. The white background, the QR code (translated into the border area), and
   optionally the text paragraph are all drawn onto this canvas.
4. `picture.toImage(w, h)` rasterises to a `ui.Image`.
5. `image.toByteData(format: png)` produces the final bytes written to disk.

---

## Design Decisions

### Single-page, no navigation

Everything lives on one screen. The separation between "input" and "output" is
handled spatially (left / right columns) rather than with tabs or navigation
routes. This matches the typical usage pattern: the user iterates on the
content while watching the code update.

### Two-column layout

The body is a `Row` with an `Expanded` scrollable left column and a fixed-width
(292 px) right column separated by a `VerticalDivider`
(`_HomePageState.build`, `home_page.dart:201–258`). The right column is not
inside a `ScrollView`, so the QR preview and Save button remain permanently
visible regardless of how tall the left column's content grows (e.g. vCard
with five fields).

### All state in one StatefulWidget

`_HomePageState` owns every piece of mutable state: selected type, all text
controllers, all settings. Child widgets (`_InputCard`, `_SettingsCard`,
`_PreviewPanel`) are `StatelessWidget`s that receive data and callbacks. This
keeps the data flow explicit and avoids the complexity of shared state
management packages for an app of this scale.

### Single flat controller map

All `TextEditingController` instances live in one `Map<String, TextEditingController>`
keyed by short string identifiers (`_keys` / `_c`, `home_page.dart:40–51`).
Controllers are created eagerly for all types at startup; unused ones simply
hold empty strings. This avoids creating/disposing controllers on type changes
and keeps the input state alive when the user switches types back and forth.

### Offline-first, no state persistence

No data is written to disk except when the user explicitly saves. There is no
preferences file, no history, and no auto-save. This keeps the app simple and
predictable — what you see is what you get.

### dart:ui canvas for PNG rendering

Flutter's widget tree cannot be trivially serialised to a PNG at arbitrary
resolution. Instead, `QrPainter` (the lower-level primitive exposed by
`qr_flutter`) is used directly with a `PictureRecorder` canvas. This gives
full control over image dimensions, border, and text placement without
depending on `RepaintBoundary` captures (which are tied to the display's device
pixel ratio) or screenshot packages.

### Preview size linked to output size

`_displaySize` is a linear function of `_saveSize` rather than a fixed
constant. This gives the user immediate visual feedback that moving the slider
changes the resolution — smaller slider value → smaller preview, larger slider
value → larger preview. The clamp (160 – 244 px) prevents the preview from
becoming uselessly tiny or overflowing the right column.

### No colour customisation

Foreground/background colour pickers were removed after initial prototyping.
The QR is always black on white. This is the combination with the highest
contrast and the most reliable scanning across lighting conditions and scanner
implementations. Offering colour options would add UI complexity with little
practical benefit for the core use-case.

---

## Dependencies

### `qr_flutter ^4.1.0`

QR encoding and rendering. Two components are used:

- **`QrImageView`** — Flutter widget used in the live preview. Handles
  encoding and painting internally; re-renders when its `data` property changes.
- **`QrPainter`** — Lower-level `CustomPainter` used during PNG export. Exposes
  a `paint(Canvas, Size)` method that integrates with the `dart:ui` recorder
  pipeline.
- **`QrErrorCorrectLevel`** — Integer constants (`L=1, M=0, Q=3, H=2`) that map
  to the segmented button values.
- **`QrVersions.auto`** — Lets the library choose the smallest QR version that
  fits the data.

No network access. The library is pure Dart with platform-native canvas
rendering.

### `file_picker ^8.1.7`

Native file system dialogs. Only one method is used:

- **`FilePicker.platform.saveFile(...)`** — Opens the OS *Save As* dialog,
  returning the full path chosen by the user, or `null` if cancelled.

On Windows this invokes the Win32 `GetSaveFileName` common dialog. The package
handles the platform channel plumbing; no additional Windows-specific setup is
required beyond the package registration that Flutter's build system handles
automatically.

### `flutter` (SDK)

- **`dart:ui`** — Low-level graphics primitives: `PictureRecorder`, `Canvas`,
  `ParagraphBuilder`, `ParagraphStyle`, `TextStyle`, `ImageByteFormat`. Used
  exclusively in `_save()` for off-screen PNG rendering.
- **`dart:io`** — `File.writeAsBytes()` for writing the final PNG to disk.
- **Material 3** widget library for all UI components.

### `cupertino_icons ^1.0.8`

Pulled in by the default Flutter template; not actively used (all icons come
from the Material icon font).

---

## File Structure

```
lib/
  main.dart        — App entry point, MaterialApp, theme configuration
  home_page.dart   — All application logic and UI widgets

windows/
  runner/
    main.cpp       — Win32 entry point; sets initial window size (800 × 580)

pubspec.yaml       — Dependencies and SDK constraints
```

---

## Key Identifiers Reference

| Identifier | File : line | Purpose |
|------------|-------------|---------|
| `QrType` enum | `home_page.dart:10` | Defines the six supported content types with display label and icon |
| `_HomePageState._type` | `home_page.dart:33` | Currently selected QR type |
| `_HomePageState._saveSize` | `home_page.dart:34` | Output PNG dimension in pixels (200–1000) |
| `_HomePageState._errorLevel` | `home_page.dart:35` | Reed-Solomon error correction level |
| `_HomePageState._wifiSecurity` | `home_page.dart:36` | Wi-Fi security protocol string (`WPA`, `WEP`, `nopass`) |
| `_HomePageState._showLabel` | `home_page.dart:37` | Whether to render the content string as text in the output |
| `_HomePageState._keys` | `home_page.dart:40` | All controller map keys; controllers are created for every key at startup |
| `_HomePageState._c` | `home_page.dart:48` | Flat map of all `TextEditingController`s; each triggers `setState` on change |
| `_HomePageState._qrData` | `home_page.dart:61` | Computed getter: assembles the type-appropriate QR payload string |
| `_HomePageState._displaySize` | `home_page.dart:89` | Preview render size derived from `_saveSize` |
| `_HomePageState._save()` | `home_page.dart:91` | Full save pipeline: dialog → encode → render → write |
| `_TypeSelector` | `home_page.dart:265` | Horizontal scrolling chip row for type selection |
| `_InputCard._fields()` | `home_page.dart:336` | Returns the correct set of input widgets for the active type |
| `_SettingsCard` | `home_page.dart:452` | Output size slider, error correction selector, label checkbox |
| `_PreviewPanel` | `home_page.dart:567` | Right-column widget: QR preview container, optional label text, Save button |
| `QrCodeGeneratorApp` | `main.dart:8` | Root widget; owns the `MaterialApp` and theme |
| Seed colour | `main.dart:18` | `Color(0xFF1565C0)` — Material Blue 800; drives the entire M3 colour scheme |
| Window size | `windows/runner/main.cpp:29` | `Win32Window::Size(800, 580)` |

Und so sieht das Ergebnis aus:
2026-03-15_14-55-10_qr_code_gen.png
Insgesamt hat alles so 40 Minuten gedauert.