Meine 7 Erfahrungen mit KI im Oktober 2026

Arbeitsplatz mit Laptop, Notizbuch und illustrierten Lernkarten im Herbstlicht.
Du betrachtest gerade Meine 7 Erfahrungen mit KI im Oktober 2026

Meine 7 Erfahrungen mit KI im Oktober 2026

Für eine Live-Demo mit KI im Oktober 2026 hatte ich fünf Minuten. Die Aufgabe, die ich zeigen wollte, dauerte bisher ungefähr zehn. Bei der Vorbereitung habe ich gemerkt, wie viel es bei KI im Entwickleralltag ausmacht, wenn ich sage, welches Ergebnis ich sehen will. Dazu kamen im Laufe des Monats ein gewachsener Prototyp, eine Lernidee und die Frage, wann ich eigentlich Feierabend mache.

Inhalt

Ich habe mir die Ergebnisse zu spät angeschaut

Anfang Oktober habe ich eine Erfahrung gemacht, die mich beim Blick in den Code ziemlich erschreckt hat. Ich hatte ein Kommandozeilenwerkzeug zur Designauswertung mit KI Schritt für Schritt verbessert. Die Ergebnisse bekamen schlechtes Feedback. Informationen fehlten, wurden missinterpretiert und waren teilweise einfach nutzlos.

Ich hatte immer wieder an einer Stelle nachgebessert, wenn ich während der Entwicklungs- und Testphase schnell ein besseres Ergebnis wollte. Dabei ist mir entgangen, wie viele Sonderfälle sich ansammelten. Als ich später in den Code schaute, dachte ich nur: „Um Gottes Willen, was passiert denn da eigentlich? Das macht ja gar keinen Sinn.“

Erst als ich genauer hinsah, merkte ich, wie eng die Auswertung inzwischen auf wenige bestimmte Designelemente zugeschnitten war. Fehlten diese Elemente, kam wenig Sinnvolles heraus. Die KI hat beim Nachbessern abgekürzt wo sie nur konnte. Typischer KI-Slop wenn man so will.

Ich hätte früher auf die tatsächlichen Ausgaben schauen können. Dafür hätte ich nicht jede Zeile Code verstehen müssen. Jetzt musste ich die vielen kleinen Einschränkungen erst einmal wieder aufräumen. Meine Faulheit, mich zurückzuziehen und alles möglichst der KI überlassen zu wollen wurde prompt bestraft.

Künftig will ich zwischendurch verschiedene Designs auswerten und mir die Ergebnisse genauer ansehen. Wenn die Antwort auffällig oft dieselben Elemente behandelt oder ein Design kaum etwas zurückliefert, ist das nun für mich ein Anlass, genauer nachzusehen.

Meine Maßnahme gegen auswuchernden KI-Slop: Immer wieder mal genauer auf das Ergebnis und den Weg dorthin schauen.

Tests brauchen eine Richtung

Ebenfalls Anfang Oktober habe ich gemerkt, dass ich einem Agenten zwar ein Testwerkzeug gegeben hatte, aber zu wenig darüber gesagt hatte, was ich prüfen wollte. Das Ergebnis war, naja, wieder mal ganz schön viel Aufräumarbeit.

Die Änderungswünsche kamen von außen und wurden zunächst mit mir eingeordnet. Wenn klar war, was umgesetzt werden sollte, gab ich die Aufgabe an die KI weiter. Mit dem Testwerkzeug konnte der Agent seine Änderungen anschließend selbst prüfen. So kamen wir schnell in die Umsetzung. Und ich dachte mir noch: „Toll, wir machen hier feinstes TDD! Was kann da schon schief gehen?“

Am Anfang wollte ich vor allem wissen, ob wir die Umsetzung mit KI überhaupt hinbekommen. Die schnellen Ergebnisse haben mich fasziniert, also habe ich den Agenten erst einmal machen lassen. Das Testwerkzeug konnte er bedienen. Welche Aussage mir ein Test liefern sollte, hatte ich aber nicht ausreichend erklärt. Ein Fehler wie sich schon bald zeigen würde.

Er schrieb sehr genaue Tests für Positionen, Radien und Farben. Was aber für mich gar nicht relevant war. Mich interessierte in diesem Fall nur, ob die Funktionen tun, was sie sollen. Also musste ich die Erwartung nachträglich klarstellen und die Tests aufräumen.

Für den nächsten Auftrag will ich vorab festhalten, welches Verhalten der Test absichern soll. Dann kann ich beim Gegenlesen beurteilen, ob er meine Frage beantwortet.

Meine Maßnahme gegen zukünftigen Test-Slop: Genauer festlegen was für Tests ich erwarte und welche nicht. Nicht nur: „Bitte alles testen“ als Anweisung.

KI im Entwickleralltag: Fünf Minuten für eine Live-Demo

Für meine Live-Demo hatte ich fünf Minuten. Bisher brauchte der Agent für die Aufgabe ungefähr zehn. Damit war er für die Vorführung zu langsam. Innerlich hatte ich mich also schon damit abgefunden: „Das wird nie was mit der Live-Demo“.

Die Gründlichkeit hatte ja ihren Sinn. Der Agent las Dokumentation, sah sich den betroffenen Code an und schaute auch in benachbarte Stellen. So wie man es sich für eine qualitative Umsetzung wünschen würde, kein zusammenhangsloser Fantasie-Code. Nur konnte ich das in einer fünfminütigen Vorführung nicht abwarten. Das beeindruckt bei einer Management-Demo am Ende niemanden.

Erst habe ich versucht, ihm nach und nach einzelne Schritte auszureden. Das half nur teilweise. Der Agent hat fleißig seine Schleifen zur Verifizierung gedreht. Getestet, kompiliert, alles langsam. Keine Chance auch nur an die fünf Minuten Marke ranzukommen.

Dann habe ich gesagt, worum es eigentlich geht: eine Live-Demo, drei Minuten Zeit und am Ende etwas Sichtbares. Kein Fluff, kein schöner Prozess. Gib mir was so schnell du kannst. Die Uhr tickt!!!

In diesem Versuch war der Agent nach ungefähr eineinhalb Minuten fertig. Ich dachte nur: „Wie ging das denn jetzt?“. Das war für mich ein echter Wow-Moment. Ich hatte endlich ausgesprochen, was ich eigentlich von ihm wollte. Und die Ergebnisse waren trotzdem gut!

Meine künftige Maßnahme gegen ungewünschte Schleifen des Agenten: Künftig klarer definieren was meine Erwartungen an das Ergebnis sind und was mir wichtig ist. In diesem Fall: Schnelle Erlebbarkeit.

Die Tickets waren da. Das Zielbild fehlte.

Bei einem Projekt lief der MVP bereits stabil und erste Benutzer hatten ihn zum Testen bekommen, um möglichst schnell und viel Feedback zu erhalten. Verbesserungstickets und Wünsche gab es auch bereits einige. Was mir fehlte, war eine klare Richtung für den weiteren Umbau. Wie soll sich die Anwendung langfristig entwickeln und was macht das mit der Code-Qualität?

Niemand hatte mir den Auftrag gegeben, jetzt eine Architekturdokumentation zu schreiben. Ich fing während einer anderen Aufgabe damit an, weil ich festhalten wollte, wohin das Projekt soll und was beim Ausbau wichtig bleibt. Die Tickets beschrieben einzelne Baustellen. Mir fehlte der Zusammenhang zwischen ihnen.

Ich ließ die KI einen ersten Entwurf der Architekturdokumentation nach arc42 erstellen. Alle Kapitel waren großzügig gefüllt. Prima, ordentlich Schreibarbeit gespart!

Beim Lesen merkte ich aber, dass einiges zu technisch oder zu schwammig war. Wo es an der Anzahl der Worte nicht mangelte, fehlte es an Klarheit und Präzision. Also gab ich meine fachliche Richtung vor und ließ mich anschließend von der KI in der Rolle als Architektin zu offenen Stellen interviewen.

Nach ungefähr einer Stunde stand eine Dokumentation, aus der sich Motivation und Richtung nachvollziehen ließen. Inhaltlich kam sie deutlich schneller und klarer auf den Punkt, so wie es sein soll. Wie gut sie den weiteren Umbau trägt, muss sich erst noch zeigen. In meinem Beitrag über eine Legacy-Portierung beschreibe ich eine weitere Entscheidung beim Umgang mit bestehendem Code.

Die einzelnen Nachfragen im Interview-Modus haben mir geholfen, Unschärfen zu erkennen und meine eigenen Antworten festzuhalten. Beim ersten Entwurf schaue ich künftig Kapitel für Kapitel, ob dort wirklich die Richtung des Projekts steht.

Meine Maßnahme für die Zukunft: Auch bei Dokumentation lohnt ein Blick auf das Ergebnis, ist das wirklich das was ich erwarte?

Ein Prototyp wächst und irgendwann verliere ich den Überblick

Ein Kommandozeilenwerkzeug war schnell gewachsen. Viele Funktionen hatte ich mit KI im Entwickleralltag erst einmal als Durchstiche gebaut. Als absehbar wurde, dass mehr Leute es nutzen würden, sah die Struktur für mich zunehmend unübersichtlich aus. Ich hatte schlichtweg keinen Plan mehr was ich da vor mir habe und mit der Zeit stellte sich bei mir ein „ungutes Gefühl“ für die Reife der Umsetzung ein.

Was ich bei einem kurzen Blick in den Code sah war ein Wildwuchs von Hunderten TypeScript Funktionen. Ein Albtraum wenn man als Entwickler doch noch etwas selbst nachvollziehen will.

Ich habe ein ausführliches Architektur-Review mit KI machen lassen. Dabei kamen konkrete Unterschiede zwischen Funktionen heraus, die eigentlich eine gemeinsame Grundlage haben sollten. Duplizierter Code, der mit der Zeit auseinander diffundiert ist. Ein Klassiker in jeder schnell gewachsenen Software.

Wir haben festgelegt, wie wir uns die Architektur und die Tests vorstellen, und die bestätigten Punkte in einzelne Aufgaben gepackt. Die arbeiten wir nach und nach ab. Mit jedem Schritt verstehe ich besser, welche Stelle was tut. Fertig war die Konsolidierung zu diesem Zeitpunkt noch nicht. Aber immerhin gab es nun ein Zielbild: „So soll es aussehen“, deutlich besser als vorher sinngemäß: „Mach mal, wird schon passen“.

Die einzelnen Aufgaben gaben mir einen Anfang. Bei jedem Schritt konnte ich prüfen, ob die Änderung zu der festgehaltenen Richtung passt. Bei einem ähnlich gewachsenen Projekt möchte ich die bestätigten Befunde wieder in einzeln prüfbare Aufgaben aufteilen.

Solche Aufräumarbeiten sind bei mir früher oft erst dann auf den Tisch gekommen, wenn bereits Probleme sichtbar wurden. Hier hatte ich schon vorher das Gefühl, dass ich den Überblick verliere.

Meine Maßnahme für die Zukunft: Zwischendurch immer mal wieder ein Review der Software Qualität machen. Das Review half mir, mein ungutes Gefühl an konkreten Abweichungen festzumachen.

Eine Lernidee wird zum Kartenset

Für meine iSAQB-Prüfung wollte ich Softwarequalitätsmerkmale besser lernen. Mein Problem war, dass ich beim Hören eines Merkmals im Nachhinein sofort dachte: „Ja klar, kenne ich. Bin nur gerade nicht drauf gekommen.“. Diesen Zustand wollte ich umkehren und selbst vor einer Entscheidung einen schnellen und vollständigen Überblick über alle möglichen Merkmale haben.

Der erste Vorschlag von Chat-GPT war eine klassische Lern-Karte zum Umdrehen. Die war mir aber zu langweilig. Ich wollte auf jeder Karte einen Begriff, ein Bild und ein Beispiel haben. Etwas greifbares und anschauliches war mir wichtig. Ich habe mit der Zeit über mich selbst gelernt, dass ich auf diesen Weg Dinge besser verinnerlichen kann.

Außerdem sollte auf der Karte stehen, woran ich das jeweilige Qualitätsmerkmal in der Praxis erkenne. Das dritte Bild von ChatGPT hat mich dann wirklich abgeholt. Auf einmal sah ich etwas vor mir wo ich dachte: „Das ist richtig gut! Da kann ich etwas draus machen.“

Anschließend habe ich selbst Hand angelegt und mit eigenen Farben und dem Layout weitergemacht, bis die erste Karte für mich gepasst hat. Auf dieser Grundlage entstanden mit Hilfe von Chat-GPT weitere rund 40 Karten. Ich habe die verfeinerte Schablone geliefert, KI hat sie mit passenden Inhalt gefüllt.

Irgendwann kam ich auf den Gedanken, wäre doch nett die Karten vor mir auf dem Tisch liegen zu haben. Welches Merkmal ist für ein Projekt gerade wichtig, und was kann erst einmal zur Seite? Ich fand einen Anbieter, bei dem ich ein einzelnes Set für knapp 20 Euro bestellen konnte. An die Druckvorgaben musste ich mich erst herantasten. Dafür gingen noch einmal eineinhalb bis zwei Stunden drauf. Rückseiten und die kleine Box kamen ebenfalls dazu. Am Ende habe ich das Set bestellt.

Gedruckte Lernkarten zu Qualitätsmerkmalen von Software.

Mich hat begeistert, dass aus der Idee an einem freien Tag etwas Bestellbares geworden ist. Ob mir das Set beim Lernen hilft und ob andere es haben wollen, war bei der Bestellung noch offen.

Mein Learning für künftige Produkt-Ideen: Es lohnt sich mit KI nach der passenden Richtung zu suchen. Verfeinerung der Idee und Umsetzung liegt aber weiterhin bei mir.

Feierabend, obwohl ich noch Lust habe

Was mich an KI im Entwickleralltag begeistert, macht es mir manchmal auch schwer, aufzuhören. Aus acht Stunden auf der Arbeit wurden zuletzt auch mal zehn, weil ich noch eine Idee ausprobieren oder eine Aufgabe erledigen wollte. Es fühlt sich an wie eine Sucht: „Was kann ich noch alles Cooles machen mit KI? Ich will nichts verpassen!“

An einem Tag im Homeoffice war draußen schönes Wetter und ich wollte wieder laufen gehen. Gefühlt hatte ich schon den ganzen Sommer verpasst, weil ich mich immerzu mit KI beschäftigt hatte. Ich habe noch eine Sache fertig gemacht, dann den Rechner zur Seite gelegt und bin los. Bamm, Klappe zu, Schluss für heute.

Das hat sich richtig gut angefühlt. Die anderen Ideen waren danach ja noch da. Eine Sache abschließen und dann bewusst aufhören möchte ich mir für ähnliche Tage wieder vornehmen.

Meine Erfahrung mit KI und Grenzen setzen: Es ist hart. Man denkt etwas zu verpassen, wenn man seine Ideen nicht sofort ausprobiert. Die Wahrheit ist: Es gibt wichtigeres. Man darf bei all der neuen zusätzlichen Produktivität durch KI nicht dem Drang verfallen die frei gewordene Zeit mir mehr Arbeit und mehr KI auszufüllen. Das kann nicht gut enden, das wird mir mehr und mehr bewusst.

WAS ES NICHT INS VIDEO SCHAFFT.

Echte Erfahrungen – regelmäßig per E-Mail.

Ich schicke dir keinen Spam! Lies meine Datenschutzhinweise für mehr Informationen.

MEHR AUS DEM ENTWICKLERALLTAG.

Double-Opt-In. Regelmäßig, aber ohne festen Kalender. Jederzeit abmeldbar.

Give me some feedback, suggestions or just leave a Reply