Genau das ist der Kern, wenn du Anforderungen mit KI erheben willst: nicht schneller tippen, sondern besser denken. Die KI schreibt die Story nicht für mich – sie führt mich durch ein Gespräch, an dessen Ende ich selbst klarer bin als vorher.

Das klingt banal. Ist aber das genaue Gegenteil von dem, was die meisten mit KI machen.

Der Fragebogen-Reflex

Der erste Reflex – bei Menschen wie bei KI – ist: alles auf einmal. Ein großes Template, zwanzig Felder, „bitte vollständig ausfüllen“. Oder du kippst der KI in einem Absatz deine halbe Idee hin und sie spuckt eine fertig aussehende Story aus.

Das Problem: So entsteht eine Scheinvollständigkeit. Du füllst Felder, weil sie da sind, nicht weil du die Antwort wirklich durchdacht hast. Und die KI ergänzt den Rest mit plausiblen Annahmen. Am Ende steht ein Dokument, das fertig aussieht – und auf Vermutungen gebaut ist.

Anforderungsarbeit ist aber kein Formular. Sie ist Denkarbeit. Und Denken erzwingt man nicht mit mehr Feldern, sondern mit den richtigen Fragen zur richtigen Zeit.

Anforderungen mit KI erheben heißt: eine Frage nach der anderen

Deshalb läuft es bei mir als echtes Gespräch. Eine Frage. Ich antworte. Die KI hört zu, hakt nach, stellt die nächste. Kein Fragebogen, ein Dialog.

Die Reihenfolge ist bewusst gewählt: Erst was genau, dann warum (der eigentliche Wert), dann für wen, dann – die unbequeme – was explizit nicht, und zum Schluss der Kern der Akzeptanzkriterien.

Der Unterschied zum Fragebogen ist der gleiche wie zwischen einem guten Interviewer und einem Formular: Der Interviewer merkt, wenn eine Antwort schwammig ist, und bohrt nach. Das Formular nimmt jede Antwort, auch die faule. Genau dieses Nachbohren – „für wen genau?“, „was passiert, wenn nicht?“ – ist die Arbeit, die eine Story trägt oder scheitern lässt. (Über den Interview-Ansatz selbst habe ich hier schon ausführlicher geschrieben.)

Während wir reden, prüft die KI schon

Und jetzt kommt der Teil, der mir das Gespräch erst richtig wertvoll macht: Während ich rede, arbeitet die KI im Hintergrund.

Sie gleicht meine Idee live gegen die bestehenden Tickets ab – gibt es das schon, unter anderem Titel, in einem anderen Epic? Sie schaut in die Wissensbasis aus Teil 2: Widerspricht die Idee einer Architekturentscheidung? Steht sie im Konflikt mit etwas, das wir bewusst verworfen haben? Gibt es Abhängigkeiten zu anderen Stories?

Das ist der Moment aus Teil 1, nur von innen betrachtet: „Das gibt es schon. Zweimal.“ Ich muss dafür nicht 200 Tickets im Kopf haben – die KI hat sie parat, während ich mich aufs Denken konzentriere. Vor einem Live-Abgleich fragt sie mich übrigens kurz, ob sie loslegen soll. Auch hier bleibe ich der, der entscheidet.

Am Ende steht ein Draft – nicht das Ticket

Wichtig: Was aus dem Interview herausfällt, ist ein Draft. Ein strukturierter Entwurf mit Titel, dem eigentlichen „als wer will ich was und warum“, ersten Akzeptanzkriterien, einer klaren Abgrenzung und den gefundenen Abhängigkeiten. Dazu ein schneller INVEST-Check – und wenn die Sache zu groß ist, ein Vorschlag, sie zu splitten.

Es ist ausdrücklich nicht das fertige Ticket. Es ist mein Rohmaterial – sauber vorbereitet, aber noch nicht entschieden. Und es ist eine simple Markdown-Datei, die ich lesen und ändern kann, ganz gleich, ob die KI gerade mitspielt oder nicht.

Der Draft geht als Nächstes durch die Mangel. Und zwar nicht durch eine Perspektive, sondern durch ein ganzes Gremium.

Was das im Alltag verändert

Die größte Wirkung hat nicht die Zeitersparnis – die gibt es, ist aber nicht der Punkt. Die größte Wirkung ist, dass ich gezwungen werde, meine eigene Idee zu Ende zu denken, bevor sie irgendwer anders sieht. Die unbequemen Fragen kommen jetzt von der KI, an meinem Schreibtisch, und nicht später im Refinement vom halben Team.

Die Exportfunktion von neulich? Die sieht heute anders aus als die Idee, mit der ich reingegangen bin. Besser. Weil mir jemand die eine unbequeme Frage gestellt hat, bevor ich losgelaufen bin.

Das ist Teil 3 der Serie „Requirements Engineering mit KI-Agenten“. Im nächsten Teil geht der Draft durch die Mangel: sechs Perspektiven schauen gleichzeitig drauf – Security, UX, Architektur, Compliance, Story-Qualität – und ein Advocatus Diaboli, der mich vor mir selbst schützt.

Alle Teile der Serie: Zur Themenseite „Requirements Engineering Pipeline“

Der Beitrag Anforderungen mit KI erheben: ein Interview statt eines Fragebogens erschien zuerst auf Das ist die Welt von Thomas.

Kurz zum Hintergrund, denn der ist mir wichtig: Die Intruder ist keine Maschine, die ich mir gekauft habe — sie ist das Motorrad meines Vaters. Er hat den Chopper 1996 neu in Wiesbaden abgeholt und ihn gehütet wie seinen Augapfel. Nachdem er von uns gegangen ist, habe ich mich entschieden, seine große Leidenschaft zu übernehmen und zu erhalten. Wie ich dazu stehe, habe ich damals schon aufgeschrieben: Suzuki VS 800 Intruder — der Nachlass meines Papas. Der Kern daraus gilt bis heute: Motorräder verkauft man nicht. Ich fahre sie mit seinem Kennzeichen weiter, aus sentimentalen Gründen, und sie soll es gut haben.

Ehrlich gesagt hatte ich sie genau das aber schon einmal werden lassen: ein Standmodell. Ich hatte die Intruder damals wieder hergerichtet, bin sie zum TÜV gefahren — und danach kaum noch bewegt. Seitdem stand sie fast nur in der Garage. Das wurmt mich, denn genau das wollte ich eigentlich nie.

Was den Ausschlag gegeben hat, sie jetzt wirklich wieder fit zu machen: Meine Tochter ist acht und entdeckt gerade ihr Interesse fürs Motorradfahren — sie möchte mit mir fahren. Und aus emotionalen Gründen ist ausgerechnet die Intruder dafür das richtige Motorrad. Das Motorrad war ein Traum meines Vaters, er hütete es wie seinen Augapfel. Hier und da bin ich mitgefahren, für Ihn war es immer etwas besonders – Sie ist einfach eine bestehende Verbindung zu ihm.Wenn jetzt meine Tochter hinten mitfährt, schließt sich dieser Kreis über drei Generationen auf genau dieser Maschine. Also nicht mehr verstauben lassen, sondern wieder auf die Straße.

Batterie war schnell gemacht, sie läuft. Nur: Die Reifen waren zehn bis zwölf Jahre alt und beim letzten TÜV schon bemängelt. Also der Plan: neue Reifen, neuer TÜV, wieder fahren. Klingt simpel. War es nicht.

Das Video, das mich erst richtig verunsichert hat

Das saß erstmal. Denn genau in diese Kategorie fällt meine Intruder: Baujahr 1996, nationale ABE, keine EU-Typgenehmigung. Und im Fahrzeugschein steht dieser schöne Satz: „Reifenfabrikatsbindung gem. Betriebserlaubnis beachten.“ Da denkst du natürlich sofort: Aha, ich bin gebunden. An eine bestimmte Marke, einen bestimmten Typ — und bei einem 96er Moped kriegst du den originalen Reifen von damals schlicht nicht mehr.

Warum die Gesetzeslage das Ganze zum Wirrwarr macht

Jetzt kommt der Teil, der die Sache erst so richtig unübersichtlich macht — die Neuregelung seit dem 01.01.2025.

Früher war das entspannt: Wolltest du von den Papieren abweichen, hast du dir eine Unbedenklichkeitsbescheinigung bzw. Reifenfreigabe des Herstellers besorgt, ausgedruckt, ins Handschuhfach gelegt — fertig. Bei Polizeikontrolle, HU oder im Versicherungsfall hat das gereicht.

Seit Anfang 2025 ist genau diese Herstellerfreigabe nicht mehr gültig, um von den Eintragungen abzuweichen. Für Fahrzeuge mit EU-Typgenehmigung ist die Fabrikatsbindung im Gegenzug komplett entfallen — die dürfen also frei wählen. Nur: Das gilt eben nur für die EU-typgenehmigten Fahrzeuge. Für die Oldies mit nationaler Betriebserlaubnis — so wie meine Intruder — blieb angeblich alles beim Alten, nur ohne den bequemen Ausweg über die Herstellerfreigabe.

Übersetzt hieß das für mich: Entweder den (nicht mehr lieferbaren) Originalreifen auftreiben oder die Bindung per Änderungsabnahme austragen lassen. Also genau der Papierkram, vor dem das Video gewarnt hatte. Herzlichen Glückwunsch.

Mein Spezialfall: die VS 52B

Ich habe mich also reingekniet. Modell-Recherche, Foren, Datenblätter. Meine Intruder ist intern die VS 52B (die bis 1999 gebaute Variante), und die läuft tatsächlich über eine nationale ABE mit der Nummer F948 — keine EU-Typgenehmigung. Damit war für mich der Fall klar: Herstellerfreigabe zählt seit 2025 nicht mehr, also muss die Bindung raus.

Die eingetragenen Serien-Reifengrößen sind:

Ich hatte mir sogar schon die passenden Reifen rausgesucht — eine Bridgestone-Kombi, weil Bridgestone die OEM-Marke ist, also nah am Original. Und ich hatte den ersten Prüfer an der Angel.

Die Odyssee: 180 Euro für nichts?

Der erste Prüfer — ein Ingenieurbüro in Mainz — hat mir die Austragung der Fabrikatsbindung angeboten: Hüllkurvenberechnung, Maße kontrollieren, Eintragung. Kostenpunkt: 180 Euro. In den Foren lag der Preisrahmen zwischen 90 und 180 Euro, ich war also am oberen Ende, aber gut, dachte ich — dann ist wenigstens Ruhe.

Bevor ich den Termin gemacht habe, habe ich aber noch zwei weitere Prüfstellen angeschrieben. Reiner Reflex, ich hole gern mehrere Meinungen ein. Und das war die beste Entscheidung in der ganzen Geschichte.

Denn Prüfstelle Nummer zwei — das Ingenieurbüro Orschau in Alzey — hat nicht einfach ein Angebot rausgeschickt. Der Prüfer hat sich die ABE F948 tatsächlich angeschaut. Und dann kam die Wende: Meine Intruder hat gar keine Reifenfabrikatsbindung. Nirgends. Was im Fahrzeugschein wie eine Bindung aussieht, ist in Wahrheit nur die Größenangabe — der Satz „Reifenfabrikatsbindung beachten“ verweist auf die eingetragenen Maße, nicht auf eine bestimmte Marke.

Zur Sicherheit habe ich mir beim TÜV die komplette Betriebserlaubnis ausdrucken lassen. Schwarz auf weiß, keine Markenbindung. Die 180 Euro für die Austragung? Nicht nötig. Termin abgesagt.

Der Beweis: ein Blick in die Betriebserlaubnis

Weil mir das anderen mit dem gleichen Problem hoffentlich hilft, hänge ich das entscheidende Dokument hier direkt an — die Typbeschreibung zum Gutachten (ABE nach §20 StVZO, Nummer F948) für den Typ VS52B:

Interessant ist der Abschnitt 6.3 „Räder und Bereifung“. Dort steht genau das, worum es geht:

• 6.3.10 Größenbezeichnung der Bereifung: vorne 80/90-21 48H, hinten 140/90-15 M/C 70H
• 6.3.11 Art der Bereifung: „einfach, Luftreifen“

Und jetzt der Punkt, an dem viele in die Falle tappen: Unter 6.3.2 „Hersteller“ steht zwar ein Name — Takasago — aber das ist der Felgenhersteller (Abschnitt „Räder“), nicht eine Reifenmarke. Eine Bindung an ein bestimmtes Reifenfabrikat taucht im ganzen Dokument nirgends auf. Es sind ausschließlich Größen, Bauart und Index festgeschrieben. Genau das meinte der Prüfer aus Alzey: Der Schein-Eintrag „Reifenfabrikatsbindung beachten“ verweist auf diese eingetragenen Maße — er verlangt keine bestimmte Marke.

Wenn du also selbst so ein altes Moped fährst: Lass dir genau dieses Blatt aus der ABE zeigen. Steht da unter „Bereifung“ kein Reifenhersteller mit Typ, hast du keine Fabrikatsbindung.

Was das konkret heißt

Ohne Fabrikatsbindung ist die Sache plötzlich herrlich einfach: Ich darf jeden ECE-geprüften Reifen montieren, solange Größe, Bauart, Last- und Geschwindigkeitsindex zu den eingetragenen Werten passen — also mindestens 48 H vorn und 70 H hinten. Keine Abnahme, keine Eintragung, keine Hüllkurve, kein Gutachten.

Ich bin trotzdem bei der Bridgestone-Kombi geblieben, weil sie eben die OEM-Marke ist:

• Vorn: Bridgestone H50F, 80/90-21 in 54 H (Index über der Serie, also passt)
• Hinten: Bridgestone Exedra Max, 140/90-15 in 70 H

Zusammen 397 Euro inklusive Montage. Ein Detail, das man bei so einem alten Moped nicht vergessen darf: Beide Reifen laufen mit Schlauch — hinten ist das bei der TT-Bauart Pflicht, vorn bei der 21-Zoll-Speichenfelge sowieso. Also gleich mitbestellt.

Neue Reifen und TÜV an einem Tag

Montiert habe ich die Reifen bei Vuidar in Biebelnheim — und da kam der eigentliche Glücksgriff: Dort ist zweimal die Woche ein TÜV-Prüfer vor Ort. Das heißt, ich bin hin, habe die neuen Reifen aufziehen lassen, und direkt im Anschluss wurde die HU vor Ort abgenommen. Kein zweiter Termin, keine Fahrt zur Prüfstelle mit frisch montierten, aber noch nicht abgenommenen Reifen. Alles an einem Tag.

Und damit ist die Intruder wieder da, wo sie hingehört: neue Reifen, frischer TÜV, verkehrssicher auf der Straße. Nach Wochen Papierkram und Zweifel ein richtig gutes Gefühl. Jetzt muss sie nur noch bewegt werden — und das habe ich in den nächsten Wochen und Monaten fest vor.

Fazit: erst die ABE prüfen, dann das Portemonnaie zücken

Das große Learning aus der ganzen Sache: Viele glauben, sie hätten eine Reifenfabrikatsbindung — dabei ist es oft nur die Größenangabe im Schein. Der Eintrag „Reifenfabrikatsbindung beachten“ klingt dramatischer, als er in vielen Fällen ist.

Bevor du also Geld für eine Austragung ausgibst, einen Prüfer für die Hüllkurve bezahlst oder verzweifelt nach einem 30 Jahre alten Originalreifen suchst: Lass dir die Betriebserlaubnis (ABE) anschauen. Ein Prüfer, der sich das Datenblatt wirklich ansieht, sagt dir in fünf Minuten, ob überhaupt eine Bindung existiert. Bei mir war die Antwort: nein. Und das hat mir 180 Euro und einen unnötigen Termin gespart.

Die Neuregelung seit 2025 ist real und für viele Oldtimer-Fahrer relevant — aber sie betrifft dich nur, wenn tatsächlich eine Fabrikatsbindung eingetragen ist. Nicht raten, nicht in Panik verfallen, sondern nachschauen lassen. Das ist die ganze Kunst.

Und meine Intruder? Steht mit frischen Reifen und neuem TÜV wieder verkehrssicher da — bereit, endlich wieder bewegt zu werden. Für einen Chopper, mit dem ich als bekennender Sportfahrer eigentlich nie gerechnet hätte, ist das ein überraschend gutes Gefühl. Aber es ist eben das Motorrad meines Vaters. Und die soll es gut haben — auf der Straße, nicht in der Ecke. Papa hätte das gefallen.

Vor allem aber steht jetzt der Motorradtour mit meiner Tochter nichts mehr im Weg. Ihr Helm ist schon gekauft, und demnächst kann es losgehen. Ich freue mich riesig auf die ersten Runden und hoffe, dass ihr das Motorradfahren genauso viel Spaß macht, wie es mir immer gemacht hat.

Und ehrlich: Wenn ich daran denke, dass ich früher mit meinem Vater auf dieser Maschine saß und bald meine Tochter mit mir — dann werde selbst ich, der eher gefühlskalte Typ, an dieser Stelle noch mal ein bisschen emotional. Kann und will ich gar nicht abstreiten.

Der Beitrag Reifenfabrikatsbindung bei der Suzuki Intruder: warum meine VS 800 am Ende gar keine hatte erschien zuerst auf Das ist die Welt von Thomas.

Der Fehler war nicht die KI. Der Fehler war, dass ich keine Wissensbasis für KI aufgebaut hatte, bevor ich sie arbeiten ließ. Kein Rahmen, kein „so arbeiten wir hier“. Sie musste raten. Und raten kann sie beeindruckend gut – nur eben nicht zuverlässig richtig.

Das war der Moment, in dem ich mein Vorgehen umgedreht habe: erst das Fundament, dann die Agenten.

Was passiert, wenn die KI raten muss

Eine KI ohne Kontext ist wie ein neuer Kollege am ersten Tag, den du sofort eine Anforderung schreiben lässt. Er ist klug, motiviert, formuliert schöne Sätze – aber er kennt eure Historie nicht, eure Entscheidungen nicht, eure Grenzen nicht.

Also füllt er die Lücken mit Annahmen. Die klingen plausibel, weil er gut klingt. Und genau das ist die Falle: Das Ergebnis sieht fertig aus, obwohl es auf Vermutungen steht.

Bei Anforderungen ist das teuer. Eine Story, die eine bestehende Architekturentscheidung ignoriert. Ein Feature, das gegen eine Datenschutzvorgabe läuft, die es längst gibt. Ein Vorschlag, den ihr vor einem Jahr aus gutem Grund verworfen habt. Nicht, weil die KI dumm ist – sondern weil ihr niemand gesagt hat, was gilt.

Eine Wissensbasis für KI schlägt jeden cleveren Prompt

Die meisten versuchen, dieses Problem mit besseren Prompts zu lösen. Immer längere Anweisungen, immer mehr „beachte bitte auch…“. Das skaliert nicht. Du kannst nicht vor jeder Frage die halbe Firmenhistorie ins Chatfenster tippen.

Der bessere Hebel ist eine Wissensbasis für KI: strukturiertes, kuratiertes Wissen, auf das jeder Agent bei jeder Aufgabe automatisch zugreift. Nicht im Prompt, sondern als fester Kontext im Hintergrund. Die KI rät dann nicht mehr – sie liest nach.

Der Unterschied ist derselbe wie zwischen einem Berater, der dein Unternehmen zum ersten Mal sieht, und einem, der seit Jahren dabei ist. Gleiche Intelligenz, völlig andere Qualität der Antwort. Nicht weil der eine schlauer ist, sondern weil er den Kontext hat.

Zwei Schichten: was für alle gilt, was nur fürs Produkt

Bei mir liegt diese Wissensbasis in zwei Schichten – und diese Trennung ist der eigentliche Trick.

Schicht 1 – Organisation. Alles, was immer gilt, egal woran ich arbeite: Compliance und Datenschutz, Security-Baselines, Architektur-Guidelines, die grobe Strategie, das Stakeholder-Verzeichnis. Diese Schicht ist bei jeder Analyse aktiv.

Schicht 2 – Produkt. Alles, was nur ein bestimmtes Produkt betrifft: Personas, Architekturentscheidungen (inklusive der wichtigen Frage „Was haben wir bewusst nicht gebaut – und warum“), bestehende Stories, Roadmap, nicht-funktionale Anforderungen.

Warum die Trennung? Weil Compliance für alles gilt – die will ich nicht bei jedem Produkt neu erfinden. Und weil Produktwissen isoliert bleiben muss – eine Entscheidung aus Produkt A darf die Analyse für Produkt B nicht verfälschen. Schicht 1 gilt überall, Schicht 2 wird passend zum aktuellen Produkt dazugeladen. So hat jeder Agent denselben, sauberen Informationsstand.

Das Fundament gehört zuerst mir, dann der KI

Jetzt kommt der Teil, der mir besonders wichtig ist: Diese Wissensbasis ist keine „KI-Konfiguration“. Es sind einfache Markdown-Dateien in Obsidian – Klartext, den ich lese, pflege und verstehe.

Das heißt: Das Fundament nützt zuerst mir. Es ist mein Zweitgehirn, meine dokumentierten Entscheidungen, mein „so arbeiten wir hier“. Dass die KI dieselben Dateien liest, ist ein Nebeneffekt – ein sehr nützlicher, aber eben nur ein Nebeneffekt.

Damit bleibt der Ansatz genau das, was ich in Teil 1 beschrieben habe: KI-basiert, aber nicht KI-abhängig. Fällt die KI aus, habe ich immer noch ein sauber gepflegtes, lesbares Wissenssystem. Ich verliere Tempo, nicht das Fundament. Genau das meine ich mit Guidelines-First – ein Prinzip, über das ich schon im Dompteur-Modell geschrieben habe.

Was ich dabei gelernt habe

Die wichtigste Lektion: Die Qualität der KI-Arbeit hängt weniger am Modell und am cleveren Prompt, als man denkt – und viel mehr an dem, was die KI lesen darf. Wer vorne beim Kontext spart, zahlt hinten bei den Ergebnissen.

spielmit.eu läuft heute anders. Erst das Fundament, dann die Agenten. Der Jenga-Turm steht nicht mehr auf Vermutungen, sondern auf einer Wissensbasis, die ich selbst geschrieben habe.

Das ist Teil 2 der Serie „Requirements Engineering mit KI-Agenten“. Im nächsten Teil wird es konkret: das Interview – wie aus einer rohen Idee ein Story-Draft wird, ganz ohne Fragebogen, und wie die KI dabei nebenbei merkt, dass es eine Idee vielleicht schon gibt.

Alle Teile der Serie: Zur Themenseite „Requirements Engineering Pipeline“

Der Beitrag Guidelines-First: Warum eine KI ohne Wissensbasis am Jenga-Turm baut erschien zuerst auf Das ist die Welt von Thomas.

Ich saß da und wusste kurz nicht, ob ich mich ärgern oder freuen soll. Geärgert, weil ich gerade dabei war, Arbeit zu doppeln, die längst getan war. Gefreut, weil mir das jemand jetzt sagt. Und genau an diesem Punkt hängt das Thema, über das gerade alle streiten: KI-generierte User Stories.

Die will nämlich kaum jemand lesen. Und ehrlich gesagt: ich auch nicht.

Dass es mir jetzt auffällt – an meinem Schreibtisch und nicht erst im Refinement, wo so eine Diskussion die Zeit des ganzen Teams frisst und die Velocity drückt – ist kein Zufall. Genau das ist mein Job: solche Dinge früh erkennen und im Zweifel vorab mit mir selbst und meinen Agenten klären.

Erst der ehrliche Teil: der Schmerz

Die Story von neulich war der harmlose Fall. Da hat es jemand – die KI – rechtzeitig gemerkt. Meistens merkt es keiner. Und dann passiert genau das, was Anforderungsarbeit seit Jahren zäh macht:

Du legst eine Story an, die es längst gibt – nur unter anderem Titel, im falschen Epic, von jemand anderem geschrieben. Du findest sie nicht, weil du gar nicht weißt, dass du suchen müsstest. Zwei Teams bauen dieselbe Sache.

Oder jemand bringt eine Idee auf, die vor zwei Jahren schon einmal auf dem Tisch lag und bewusst verworfen wurde. Die Story liegt irgendwo in Jira – mit Glück archiviert, im schlimmsten Fall längst gelöscht. Mit genug Recherche fände man sie wieder. Aber genau das ist der Punkt: Als PO will ich das Backlog nach vorne bringen, nicht vor jeder Idee zum Detektiv werden und ständig hinterfragen, ob es das nicht schon gab. Diese Sucharbeit brauche ich – und genau die kann mir eine KI abnehmen.

Oder die Story ist sauber formuliert, klingt rund – und im Sprint fällt auf, dass sie am Datenschutz vorbeigeht, ein Sicherheitsloch aufreißt oder einer Architekturentscheidung widerspricht. Jetzt ist es teuer.

Und selbst wenn alles gut läuft: Kaum hast du das Ticket ans Team übergeben, entwickelt es sich in Jira weiter – neu geschnitten, ergänzt, umpriorisiert. Deine Planung steht derweil auf altem Stand. Du merkst es nicht. Bis es kracht.

Das ist der Schmerz. Nichts davon ist spektakulär. Aber es summiert sich – zu doppelter Arbeit, vergessenen Entscheidungen und Stories, die im luftleeren Raum entstehen.

„Keine KI-generierten User Stories“ – und sie haben recht

Wenn ich davon erzähle, kommt oft der Reflex: „Dann lass doch die KI die Stories schreiben.“ Und genauso oft kommt von guten Entwicklern der Gegenreflex: „Bitte nicht. KI-generierte User Stories merke ich sofort – und dann lese ich sie nicht gern.“

Der Frust dahinter ist berechtigt. Nichts ist ermüdender als glatter Text, der so tut, als hätte jemand nachgedacht, aber niemand hat. Gleichzeitig erwarten dieselben Leute, dass ein Product Owner 2026 KI nutzt. Kein Werkzeug in der Hand zu haben, das alle anderen längst haben, wirkt eben auch nicht souverän.

Das klingt nach Widerspruch. Ist es aber nicht. Beide Seiten reden nur über zwei verschiedene Dinge. Das Problem ist nicht, dass KI im Spiel ist. Das Problem ist, was sie tut.

Warum Prüfen das Schreiben schlägt

Eine Story zu schreiben heißt: eine Absicht zu formulieren. Warum bauen wir das? Für wen? Was lassen wir bewusst weg? Das hängt an Kontext, an Historie, an Verantwortung – an Dingen, die in meinem Kopf und in den Köpfen meiner Kollegen stecken, nicht im Trainingsdatensatz eines Modells. Wenn ich das an eine KI abgebe, kommt genau der Text heraus, den keiner lesen will: plausibel und hohl.

Eine Story zu prüfen ist das genaue Gegenteil.

Prüfen heißt: alles gegen alles abgleichen. Gibt es das schon? Widerspricht es einer Entscheidung von damals? Was sagt der Datenschutz, was der Sicherheitsblick, was der Nutzer? Das ist stumpfe, vollständige, ausdauernde Arbeit – und genau da bin ich als Mensch schwach. Ich vergesse Tickets. Ich habe nicht alle Architekturentscheidungen im Kopf. Ich kann nicht gleichzeitig die Security-, die Datenschutz- und die Nutzerbrille tragen.

Eine Maschine kann das. Unermüdlich, bei jedem einzelnen Ticket.

Deshalb schreibt bei mir die KI nicht – sie prüft. Ich behalte den Teil, den nur ich kann: entscheiden, was wir bauen und warum. Sie übernimmt den Teil, den ich alleine nie so gründlich hinbekäme. Das ist keine Bequemlichkeit. Das ist Arbeitsteilung nach Stärken.

Die These, auf der alles aufbaut

Der Mensch besitzt die Absicht. Die Agenten besitzen die Prüfung.

Was am Ende im Ticket steht, wurde nicht geschrieben. Es wurde geprüft – und von mir entschieden. Deshalb sind meine Stories besser durchdacht, seit KI im Spiel ist, nicht schlechter.

Zwei Bausteine davon habe ich hier schon beschrieben: den Interview-Ansatz statt Fragebogen und das Dompteur-Modell mit Guidelines-First. In dieser Serie setze ich sie zu einem kompletten Vorgehen zusammen.

KI ist eine Ergänzung – kein Allheilmittel

Damit das nicht falsch ankommt: Die KI ist bei mir nicht der Chef. Wir Product Owner sind die Profis, die entscheiden – die KI unterstützt. Und Unterstützung heißt für mich ausdrücklich, dass ich auch dann arbeiten kann, wenn sie mal nicht da ist.

Deshalb liegt meine gesamte Wissensbasis – alle Guidelines, alle Stories, alle Entscheidungen – als einfache Markdown-Dateien in Obsidian. Klartext, den jeder Mensch lesen und selbst bearbeiten kann, ohne Spezialwerkzeug, versioniert in Git. Die KI liest genau dieselben Dateien wie ich, kein verstecktes Format dazwischen.

Der Workflow ist KI-basiert, aber nicht KI-abhängig. Ist das Modell mal nicht erreichbar, bin ich offline oder fällt der Dienst aus, verliere ich Tempo – nicht meine Daten und nicht die Kontrolle. Dann mache ich eben von Hand weiter. Genau das ist der Unterschied zwischen einem Werkzeug, das dich stärker macht, und einem, von dem du abhängig wirst.

Was ich dabei gelernt habe

Der wichtigste Perspektivwechsel war, die KI nicht als schnelleren Texter zu sehen, sondern als etwas, das ich alleine nie leisten könnte: Hunderte Tickets vor jeder neuen Idee durchsehen, jede alte Entscheidung parat haben, gleichzeitig aus fünf Blickwinkeln auf dieselbe Anforderung schauen.

Das nimmt mir die Fleißarbeit ab – und lässt mir den Kopf frei für das, was wirklich meine Aufgabe ist.

KI-generierte User Stories im eigentlichen Sinn entstehen bei mir also nicht. Was am Ende rausgeht, ist geprüft – und von mir verantwortet.

Und die Story von neulich? Die habe ich nicht angelegt. Die gab es ja schon.

Das ist der erste Teil einer Serie über mein Vorgehen im Requirements Engineering mit KI-Agenten. Im nächsten Teil geht es ums Fundament: warum eine KI ohne Wissensbasis am Jenga-Turm baut – und was sich ändert, sobald sie kuratierten Kontext bekommt.

Alle Teile der Serie: Zur Themenseite „Requirements Engineering Pipeline“

Der Beitrag Warum ich keine KI-generierten User Stories schreibe – und KI trotzdem überall einsetze erschien zuerst auf Das ist die Welt von Thomas.

Ich möchte kurz aufschreiben, wie es dazu gekommen ist — nicht weil ich das der Welt schulde, sondern weil es sich richtig anfühlt, das zu reflektieren.

Was assistent.ai ist — und was ich dazu beigetragen habe

assistent.ai ist ein KI-basierter Telefonassistent für die Gastronomie. Das System übernimmt eingehende Anrufe, wenn das Serviceteam eines Restaurants nicht erreichbar ist: nimmt Reservierungen entgegen, trägt sie direkt ins Reservierungssystem ein, beantwortet Fragen zu Öffnungszeiten, Speisekarte und Parkmöglichkeiten — und das vollständig autonom.

Gegründet haben wir das Ganze zu zweit: Jannik Oberlies und ich. Die Aufgabenteilung war von Anfang an klar: Jannik übernimmt 100 % Business, ich 100 % Technik. So ziemlich jede Zeile Code ist irgendwann mal durch meine Finger gelaufen. Wir haben eine eigene Conversational-AI-Plattform im Backend aufgebaut, ein eigenes Frontend entwickelt und eine generische Lösung konzipiert, die es ermöglicht, Restaurant-APIs in wenigen Stunden anzubinden — egal wie unterschiedlich die jeweiligen Logiken darunter auch sein mögen.

Warum ich raus bin

Ich bin ein technikverliebter Mensch. Ich mag es, neue Dinge auszuprobieren, sie zu verstehen, zu einem sauberen Produkt zu führen. Aber genau da liegt auch das Problem: Ab dem Moment, wo etwas wirklich ein Produkt ist — wo ich die Technik verstanden habe, die Frameworks kenne, die Architektur sitzt — verliert es für mich langsam seinen Reiz. Das ist keine Kritik an assistent.ai, das ist einfach, wie ich ticke.

Dazu kommt: Ein eigenes Startup neben dem Hauptberuf kostet wirklich viel Zeit. Es ist Lebenszeit. Und Lebenszeit, die ich nicht mit meiner Familie verbringe. Ich habe keine intrinsische Motivation, ein Unternehmen zu führen oder zu skalieren. Was mich antreibt, ist die Technik — das Bauen, das Lösen, das Verstehen. Nicht das Verwalten.

Und schließlich: Seit dem 1. November bin ich als Chief Product Owner bei der Syna GmbH tätig. Eine anspruchsvolle Rolle, die viel kognitive Kapazität fordert. Eine Ablenkung durch ein Startup wollte und konnte ich mir dort nicht mehr leisten.

Die Entscheidung ist also keine einzelne Entscheidung gewesen. Sie war die logische Konsequenz aus mehreren Dingen gleichzeitig.

Der Prozess

Wer glaubt, sowas passiert von heute auf morgen, irrt sich. Wir diskutieren seit über einem Jahr über meinen möglichen Ausstieg und das nicht zum ersten mal. Haben verschiedene Szenarien durchgespielt, Lösungen abgewogen. Jannik hat sich intensiv auf die Suche nach einem neuen technischen Mitgründer gemacht — Jasper war nicht der erste Kandidat, den wir in Betracht gezogen haben. Es gab eine längere Einarbeitungsphase, Aufgaben wurden verteilt, die Zusammenarbeit zwischen Jannik und Jasper wurde erprobt.

Und jetzt ist es so weit. Der Notarvertrag ist unterzeichnet.

Startup des Jahres — ein Moment, den ich nicht vergesse

Bevor ich zum Valentinstag komme, noch ein anderer Moment, der mir in Erinnerung geblieben ist.

2022 hat das Branchenmagazin falstaff PROFI assistent.ai als bestes Startup des Jahres in der Kategorie „Innovation“ ausgezeichnet. Wir haben uns im Elevator-Pitch vor einer unabhängigen Jury gegen die Konkurrenz durchgesetzt — auf der Sterne-Nacht der Gastronomie in Graz, vor echtem Fachpublikum.

Für ein kleines, junges Startup, das mit wenig Ressourcen und einem klaren Fokus gestartet ist, war das ein echter Vertrauensbeweis. Nicht nur von außen, sondern auch für uns intern: Scheinbar machen wir nicht alles falsch.

Der Valentinstag-Moment

Bevor ich zum emotionalen Teil komme, möchte ich kurz von einem Moment berichten, der mir gezeigt hat, dass das, was wir gebaut haben, wirklich funktioniert.

Es war der 15. oder 16. Februar. Ich schaue auf das Dashboard — und die Anrufzahlen sind explodiert. Ich meine: wirklich explodiert. Ein absolut vielfaches des normalen Tagesvolumens. Mein erster Gedanke: Haben wir einen Hack? Ist etwas schiefgelaufen? Irgendwas stimmt hier nicht.

In der Realität war es ganz einfach der 14. Februar. Valentinstag. Viele Menschen haben Tische reserviert, viele Restaurants hatten volle Leitungen — und das System hat es einfach weggesteckt. Kein einziger Alarm im Monitoring, keine Performance-Probleme, nichts. Die Last hat sämtliche Lasttests gesprengt, die wir je durchgeführt hatten. Und das System hat es nicht mal bemerkt.

Das war für mich der Moment, wo ich gedacht habe: Okay. Was wir da gebaut haben, ist solide. Wirklich solide.

Wehmut und Erleichterung

Natürlich ist es nicht nur Erleichterung. Ich habe viel Energie in dieses Startup gesteckt. Man baut etwas auf, kämpft mit den Herausforderungen, und irgendwann läuft es — und dann gibt man es ab.

Die letzten Tage vor der Unterzeichnung waren ehrlich gesagt auch von Zweifeln begleitet. Ist das jetzt wirklich der richtige Schritt? Bin ich sicher? Aber am Ende war die Antwort immer die gleiche: Ja. Es ist der richtige Schritt. Jetzt.

Was bleibt, ist ein gutes Gefühl: Ich habe ein Stück Software zum Leben erweckt, das in Produktion läuft, von echten Menschen genutzt wird und weiter wächst. Das ist keine Kleinigkeit. Das ist genau das, was ich am Anfang wollte.

Jannik und ich

Die Zusammenarbeit mit Jannik war gut — aber natürlich nicht immer reibungslos. Wir sind unterschiedliche Menschen.

Ich bin jemand, der sagt: Funktion geht vor Perfektion. Erst verproben, dann skalieren. Lieber eine kleine, stabile Lösung als eine große, die wackelt. Jannik strebt nach der 100 %-Lösung, denkt von Anfang an größer, denkt marketingseitig weiter. Das sind legitime Unterschiede zwischen einem Techniker und einem Business-Mann — aber sie erzeugen hier und da Reibung.

Schwierig wurde es für mich persönlich, als die Grenze zwischen Business und Technik anfing zu verwischen. Als Einfluss auf technische Entscheidungen kam, wo ich ihn nicht erwartet hatte. Das war der Punkt, wo ich gemerkt habe: Meine Motivation bröckelt.

Jasper, der neue CTO

Ich habe Jasper erst beim Notar persönlich kennengelernt. Vorher kannten wir uns nur aus Remote-Sessions und einigen gemeinsamen Coding-Runden.

Mein ehrliches Urteil: Er ist noch jung in seiner Karriere aber mit Sicherheit dafür schon recht weit. Er scheint schon einen gewissen Weitblick mit zu bringen und trifft sinnvolle Entscheidungen. Auch er wird, so wie ich es auch getan habe, hier und da aus Fehlern lernen … Aber wir sind im Startup-Bereich. Das gehört dazu. Was zählt: Jannik und Jasper kommen miteinander aus, sie können zusammenarbeiten. Das ist das Wichtigste. Den Rest lernt man.

Was jetzt kommt

Ehrlich gesagt: erstmal nichts Neues. Ich beschäftige mich intensiv mit KI / LLMs / SLMs, mit Vibe Coding, mit der Frage, wie Agenten im täglichen Arbeitsalltag sinnvoll unterstützen können. Mich interessiert gerade sehr, wie sich die Rolle von Softwareentwicklern und Business-Analysten in Zukunft verändern wird — wie KI hilft, Anforderungen zu erfassen und daraus sinnvolle Lösungen zu bauen.

Aber ein neues Projekt? Noch nicht. Die Rolle bei der Syna fordert mich, meine Familie will Zeit — und die bekommt sie jetzt auch. Wer weiß, vielleicht kommt in einem Jahr wieder eine Idee. Vielleicht auch nicht. Im Moment ist das völlig in Ordnung so.

Noch da — aber anders

Verkauft heißt nicht verschwunden. Ich stehe Jannik und Jasper weiterhin zur Verfügung — als externer Coach, wenn es Fragen gibt, wenn technische Entscheidungen anstehen oder einfach mal ein zweites Paar Augen gefragt ist. Aber eben nur dann, wenn ich Zeit habe. Und nicht mehr als Inhaber, der irgendwie mitverantwortlich ist.

Wie das im Extremfall aussieht — also wenn es mal ein Produktionsproblem gibt und um 2 Uhr nachts jemand eine Idee braucht — das werden wir dann sehen. Ich bin zuversichtlich, dass wir auch da eine Lösung finden.

Das Kapitel assistent.ai ist abgeschlossen. Es war gut. Und jetzt ist es vorbei.

Der Beitrag Kapitel abgeschlossen: Mein Ausstieg aus assistent.ai erschien zuerst auf Das ist die Welt von Thomas.

Was am Ende rausgekommen ist: ein Dashboard, das mir zu jeder Zeit zeigt, wo der Pool steht — und auf einen Blick verrät, ob ich Chlor nachwerfen oder pH-Minus dazugeben soll. Komplett lokal, ohne Cloud-Abo, ohne App-Klickerei.

Hier ist der ganze Weg, den ich gegangen bin. Inklusive eines hässlichen Stolpersteins, an dem ich fast einen halben Tag verloren habe.

Was die Blue Connect GO eigentlich macht

Die Blue Connect GO* ist eine kleine, weiße Boje, die du einfach ins Poolwasser wirfst. Sie schwimmt da rum und misst kontinuierlich drei Werte, die für die Wasserqualität relevant sind:

• Temperatur — was du eh schon weißt, aber im Tagesverlauf interessant für die Solarheizung
• pH-Wert — entscheidend dafür, ob das Chlor seine Arbeit machen kann
• ORP (Oxidations-Reduktions-Potential) — der eigentliche Indikator dafür, ob die Desinfektion (Chlor) ausreicht

Statt einzelnen Teststreifen oder Photometer-Messungen bekommst du also dauerhaft frische Werte ohne Aufwand. Die Boje hat einen kleinen Akku (per USB ladbar), einen Bewegungssensor (Schütteln weckt sie aus dem Schlaf) und eine Bluetooth-Low-Energy-Schnittstelle zum Auslesen.

Klingt erstmal nach einem klaren Win — und das ist es auch. Aber: Der Hersteller verkauft das Ding als Teil seines App-Ökosystems. Du installierst die BlueRiiot-App, hältst dein Handy einmal pro Tag in die Nähe der Boje, und die App synchronisiert die Werte in eine Cloud.

Und genau da fängt es an, mich zu stören.

Warum ich es nicht bei der App lassen wollte

Drei Gründe, warum das App-Setup für mich nicht funktioniert:

1. Manuelles Auslesen. Ich muss aktiv mit dem Handy hinrennen. Macht in der Praxis vielleicht zweimal die Woche jemand. Eigentlich will ich aber wissen, ob heute Morgen um 8 Uhr der pH-Wert nach dem nächtlichen Regen abgesoffen ist.
2. Daten liegen in der Cloud. Wer die Werte sehen will, braucht Account, App, Verbindung. Wenn ich in Home Assistant ein Dashboard für meine Frau bauen will, geht das nicht ohne Umwege.
3. Keine Automatisierungen. Ich kann keinen Alarm bauen, der mir bei ORP unter 600 mV eine Push-Notification schickt. Ich kann nichts mit den Daten machen, was über Anzeigen hinausgeht.

Mein Anspruch: Werte sollen automatisch und ohne Cloud in Home Assistant landen, da kann ich dann alles damit machen, was ich will.

Die Lösung in einem Satz

Ein ESP32* sitzt im Pool-Häuschen, hört per Bluetooth die Boje ab und schiebt die Werte per WLAN in Home Assistant.

Funktional sieht das so aus:

[Blue Connect GO im Pool] --BLE--> [ESP32 im Pool-Häuschen] --WLAN--> [Home Assistant]

Der ESP32* läuft mit der ESPHome-Firmware. ESPHome ist ein Framework, mit dem du den ESP per YAML-Datei konfigurierst, statt selbst Firmware-Code zu schreiben. Du legst fest, welche Sensoren der ESP haben soll, welche Daten er aufnimmt, was er damit macht — fertig.

Der entscheidende Trick: ESPHome hat eine fertige Komponente, die per BLE Geräte in der Umgebung scannen und auslesen kann. Du sagst ihr „verbinde dich mit MAC XX:XX:XX:XX:XX:XX und lies UUID f3300003-… aus“, und sie macht das.

Die Bedienung der Boje (Aufwecken zur Messung) läuft per BLE-Write, das geht auch über ESPHome — sodass Home Assistant via Button die Boje aktiv zu einer Messung zwingen kann.

Hardware-Stückliste

Was du brauchst:

• ESP32 — ich habe das AZDelivery NodeMCU Dev Kit C 3er-Pack bei Amazon* genommen, ca. 20 Euro. Drei Stück, damit du Ersatz hast. Modell ohne externe Antenne reicht, wenn der ESP nicht weiter als ein paar Meter von Pool und WLAN entfernt steht.
• Gehäuse — ich habe ein passendes 3D-Druck-Modell von Printables genommen. Falls du keinen Drucker hast: ein normales Universal-Plastikgehäuse für 3-4 Euro tut es auch.
• Micro-USB-Kabel + 5V-Netzteil — hast du wahrscheinlich rumliegen.
• Eine bereits eingerichtete Home-Assistant-Instanz.

Gesamtinvestition: rund 20 Euro plus etwas Zeit. Verglichen mit anderen Pool-Smarthome-Lösungen ist das ein Witz.

Phase 1: ESPHome installieren

In Home Assistant musst du das ESPHome Device Builder Add-on installieren. Achtung — nicht zu verwechseln mit der ESPHome-Integration (die brauchst du erst später, automatisch). Pfad:

Einstellungen → Add-ons → Add-on Store → "ESPHome Device Builder" → Installieren → Starten → "Im Sidebar anzeigen"

Danach hast du in der Seitenleiste einen ESPHome-Menüpunkt. Da arbeitest du jetzt.

Phase 2: Secrets pflegen

Bevor du das erste Gerät anlegst, im ESPHome-Dashboard oben rechts auf Secrets klicken und folgende Einträge ergänzen:

wifi_ssid: "DEIN_WLAN_NAME"
wifi_password: "DEIN_WLAN_PASSWORT"
ota_password: "selbst-gewähltes-Passwort-für-OTA-Updates"
pool_proxy_pool_api_key: "32-Byte-Base64-String"

Den API-Key kannst du dir generieren lassen, indem du ein Dummy-Gerät anlegst — ESPHome erzeugt da automatisch einen, den du dann kopierst.

Das Vorgehen in zwei Schritten — warum nicht direkt die große Config

Bevor wir in die YAMLs einsteigen, kurz das Vorgehen, damit du nicht in dieselbe Falle läufst wie ich am Anfang:

Du flashst den ESP zweimal. Erstmal mit einer reduzierten Discovery-Konfiguration, deren einziger Zweck es ist, die MAC-Adresse der Boje rauszufinden. Dann packst du den ESP ans Pool-Häuschen, sammelst die MAC, kommst zurück und flashst noch einmal — diesmal mit der finalen Konfiguration, die alles macht: BLE-Verbindung zur Boje, Auslesen der Werte, Button zum manuellen Triggern, alles.

Warum nicht direkt die große Config? Weil ohne MAC-Adresse die Hälfte davon ohnehin nicht funktioniert. Und weil der Discovery-Schritt ein zeitlich begrenzter Hack ist (das on_ble_advertise-Lambda aus dem nächsten Abschnitt), den du danach wieder rauswerfen willst.

Konkret:

1. Discovery-Flash per USB am Schreibtisch — ESP mit der reduzierten YAML beschreiben
2. ESP ans Pool-Häuschen bringen — Strom dran, WLAN-Reichweite zur Boje sicherstellen
3. MAC im Log auslesen — der Discovery-Lambda macht’s sichtbar
4. Zurück zum Rechner — MAC in die finale YAML eintragen
5. Finaler OTA-Flash — über WLAN, kein Kabel mehr nötig
6. ESP wieder zurück ans Pool — Werte tropfen rein

Punkte 2 und 6 fallen weg, wenn dein Schreibtisch sowieso in Reichweite des Pools ist. Bei mir liegen ca. 15 Meter dazwischen, also zwei Wege.

Phase 3: Discovery-Flash per USB

Im ESPHome-Dashboard auf New Device klicken, Namen vergeben (bei mir: pool-proxy-pool), Board ESP32 Generic auswählen. ESPHome generiert eine minimale YAML — die ersetzt du komplett durch das hier:

substitutions:
  device_name: pool-proxy-pool
  friendly_name: "Pool Proxy – Pool"

esphome:
  name: ${device_name}
  friendly_name: ${friendly_name}

esp32:
  board: esp32dev
  framework:
    type: esp-idf

logger:
  level: DEBUG
  logs:
    esp32_ble_tracker: DEBUG

api:
  encryption:
    key: !secret pool_proxy_pool_api_key

ota:
  - platform: esphome
    password: !secret ota_password

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  power_save_mode: none

captive_portal:

esp32_ble_tracker:
  scan_parameters:
    interval: 320ms
    window: 300ms
    active: true
  on_ble_advertise:
    then:
      - lambda: |-
          for (auto uuid : x.get_service_uuids()) {
            if (uuid.to_string().find("f3300001") != std::string::npos) {
              ESP_LOGI("ble_scan", "BOJE: %s RSSI=%d", x.address_str().c_str(), x.get_rssi());
            }
          }

Diese Konfig macht nur ein einziges Ding: BLE-Pakete scannen und immer dann eine Log-Zeile schreiben, wenn ein Gerät mit der Blue-Connect-Service-UUID f3300001-… empfangen wurde. Mehr nicht. Keine Sensoren, keine Buttons, keine Logik — der ESP ist hier nur Lauscher.

Den ESP per USB anschließen, im ESPHome-Dashboard Install → Plug into computer running ESPHome dashboard. Beim ersten Build dauert das ein paar Minuten, weil ESPHome erstmal die Toolchain runterzieht. Danach hast du eine funktionierende Firmware drauf.

USB wieder abziehen, ESP ins Gehäuse, Netzteil dran, ab ins Pool-Häuschen.

Phase 4: Die MAC-Adresse der Boje finden

Wenn du jetzt im ESPHome-Dashboard auf Logs klickst, siehst du den Live-Log des ESP. Mit etwas Geduld (und einer aufgeweckten Boje — dazu gleich) tauchen Zeilen auf wie:

[I][ble_scan]: BOJE: 00:A0:xx:D0:xx:xx RSSI=-67
[I][ble_scan]: BOJE: 00:A0:xx:D0:xx:xx RSSI=-69

Die hexadezimale Zahl vor dem RSSI ist die MAC-Adresse deiner Boje. Notieren, kopieren, fertig. Falls nichts kommt: Boje einmal kräftig schütteln (der Beschleunigungssensor weckt sie aus dem Schlaf), wieder reinwerfen — und sicherstellen, dass die BlueRiiot-App komplett geschlossen ist. Die Boje erlaubt nämlich nur eine BLE-Verbindung gleichzeitig, eine offene App-Verbindung blockt den ESP.

Und damit zur Frage, die du dir vermutlich gerade stellst: Warum sieht die Discovery-Konfig oben so seltsam aus? Warum der ungewöhnliche on_ble_advertise-Lambda? Warum window: 300ms statt der überall im Netz herumliegenden window: 30ms?

Antwort: weil mich das einen halben Tag gekostet hat herauszufinden.

Mein Log mit der naiven Standard-Konfig aus dem Forum-Tutorial sah anfangs so aus:

[esp32_ble_tracker]: Scanner State: RUNNING
[esp32_ble_tracker]: Connecting: 0, discovered: 0

Und danach: nichts. Stundenlang. Weder die Boje, noch mein Handy welches direkt daneben lag noch sonst irgend ein Bluetooth-Device. Komplette Funkstille trotz aktivem Scanner.

Ich habe alles durchgekärrt, was man durchkärren kann: Log-Level von INFO auf DEBUG, dann auf VERBOSE. Verschiedene BLE-Submodule auf VERBOSE gesetzt. Framework von esp-idf auf arduino umgestellt. Build-Cache geleert. USB-Flash mit Erase. Alles ohne Erfolg.

Erst nach Stunden bin ich auf zwei Probleme gestoßen, die niemand in den Tutorials und Forenbeiträgen erwähnt — und die deshalb fest in die Discovery-Config oben eingebaut sind:

Problem 1: Das Default-Scan-Window ist zu kurz.

Die meisten Beispiele aus dem Netz haben window: 30ms bei interval: 320ms. Das bedeutet: Der ESP horcht 30 Millisekunden, schweigt dann 290 Millisekunden, horcht wieder. Das sind 9 Prozent aktive Hörzeit. Für ständig sendende Geräte (Beacons, Tags) reicht das. Für die Blue Connect GO, die nur sporadisch im Aufweck-Modus Pakete sendet, ist das viel zu wenig — du verpasst die meisten Sendeimpulse.

Mit window: 300ms horcht der ESP zu 94 Prozent der Zeit. Akku-Verbrauch interessiert hier nicht, der ESP hängt eh am Netzteil.

Problem 2: ESPHome verschluckt die „Found device“-Logs.

Das war der wirklich gemeine Teil. Selbst nachdem das Scan-Window vergrößert war, kam im Log immer noch nichts. Erst nach langem Recherchieren bin ich draufgekommen: In der ESPHome-Version, die ich genutzt habe (2026.6.0-dev), werden die Standard-Found device-Logs vom esp32_ble_tracker schlicht nicht mehr ausgegeben. Der Stack arbeitet, der Scanner findet Geräte — aber im Log siehst du nichts davon.

Lösung: eigene Log-Zeile per Lambda erzwingen. Genau das ist der on_ble_advertise-Block in der Discovery-Config. Er sagt: „Bei jedem empfangenen BLE-Advertising-Paket schau, ob das Gerät die Service-UUID f3300001-… mitsendet. Wenn ja, schreib mir eine Zeile ins Log mit MAC und Signalstärke.“ Die UUID f3300001-… ist der eindeutige Marker für die Blue Connect GO — andere BLE-Geräte werden also ignoriert.

Mit beiden Fixes drin fand mein ESP die Boje innerhalb von zwei Sekunden. Ohne die Fixes hätte ich vermutlich noch den nächsten Tag gesucht und wäre überzeugt gewesen, dass mein ESP einen kaputten Bluetooth-Chip hat. Hatte er nicht. Software-Problem.

Phase 5: Die finale Konfiguration aufspielen

Jetzt ersetzt du im ESPHome-Dashboard die Discovery-Konfig durch die finale. Die ist deutlich länger, weil sie alles macht, was du wirklich brauchst:

• BLE-Verbindung zur Boje aufbauen (mit deiner MAC)
• Beim Empfang von Werten die Rohdaten dekodieren (Temperatur in °C, pH, ORP in mV)
• Einen Button bereitstellen, mit dem du die Boje manuell zu einer Messung triggern kannst
• Diagnostik-Sensoren (WLAN-Signal, BLE-Signal zur Boje, Laufzeit)

Hier der komplette YAML-Block zum Copy-Paste — du musst nur an drei Stellen ran: die beiden MAC_DER_BOJE-Platzhalter durch deine echte MAC ersetzen, und die device_name-/friendly_name-Substitutionen an deinen Pool anpassen, falls du einen anderen Namen willst.

substitutions:
  device_name: pool-proxy-pool
  friendly_name: "Pool Proxy – Pool"

esphome:
  name: ${device_name}
  friendly_name: ${friendly_name}
  on_boot:
    priority: -100           # läuft ganz am Ende, wenn WiFi/BLE-Stack initialisiert sind
    then:
      - delay: 5min
      - logger.log: "Initiale Messung 5 min nach Boot wird ausgelöst"
      - button.press: btn_measure

esp32:
  board: esp32dev
  framework:
    type: esp-idf

logger:
  level: DEBUG
  logs:
    esp32_ble: DEBUG
    esp32_ble_tracker: DEBUG
    esp32_ble_client: DEBUG
    ble_client: DEBUG

api:
  encryption:
    key: !secret pool_proxy_pool_api_key

ota:
  - platform: esphome
    password: !secret ota_password

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  power_save_mode: none

captive_portal:

esp32_ble_tracker:
  scan_parameters:
    interval: 320ms
    window: 300ms          # ⚠ NICHT 30ms — sonst werden Advertising-Pakete verpasst (siehe Troubleshooting)
    active: true

globals:
  # Flag für "Messung wurde angefordert, aber BLE war nicht verbunden" — wird beim
  # nächsten on_connect abgearbeitet. Kein restore_value, damit nach Reboot kein
  # Geister-Trigger hängenbleibt.
  - id: pool_measure_pending
    type: bool
    restore_value: no
    initial_value: 'false'

interval:
  # Turnusmäßige Messung alle 4h. Feuert erstmals 4h nach Boot — die erste Messung
  # kurz nach dem Start übernimmt der on_boot-Trigger (siehe esphome:-Block).
  - interval: 4h
    then:
      - logger.log: "Turnusmäßige Messung (alle 4h) wird ausgelöst"
      - button.press: btn_measure

ble_client:
  - mac_address: "00:A0:50:D0:53:0F"   # MAC der Blue Connect GO Boje
    id: ble_client_pool
    on_connect:
      then:
        - logger.log: "BLE verbunden"
        - if:
            condition:
              lambda: 'return id(pool_measure_pending);'
            then:
              - logger.log: "Gequeuter Messung-Trigger wird jetzt gesendet"
              - delay: 500ms   # GATT braucht kurz nach Connect, sonst evtl. "not connected"-Race
              - ble_client.ble_write:
                  id: ble_client_pool
                  service_uuid: 'F3300001-F0A2-9B06-0C59-1BC4763B5C00'
                  characteristic_uuid: 'F3300002-F0A2-9B06-0C59-1BC4763B5C00'
                  value: [0x01]
              - lambda: 'id(pool_measure_pending) = false;'
    on_disconnect:
      then:
        - logger.log: "BLE getrennt"

button:
  - platform: template
    name: "${friendly_name} Messung auslösen"
    id: btn_measure   # von on_boot + interval angesprochen für Auto-Messungen
    on_press:
      then:
        # Pending-Flag-Logik: wenn BLE gerade verbunden → sofort schreiben.
        # Sonst Flag setzen, ble_client erledigt es beim nächsten on_connect.
        - if:
            condition:
              lambda: 'return id(ble_client_pool).connected();'
            then:
              - logger.log: "BLE verbunden — Messung sofort triggern"
              - ble_client.ble_write:
                  id: ble_client_pool
                  service_uuid: 'F3300001-F0A2-9B06-0C59-1BC4763B5C00'
                  characteristic_uuid: 'F3300002-F0A2-9B06-0C59-1BC4763B5C00'
                  value: [0x01]
            else:
              - logger.log: "BLE nicht verbunden — Messung wird beim nächsten Connect ausgeführt"
              - lambda: 'id(pool_measure_pending) = true;'
  - platform: restart
    name: "${friendly_name} Neustart"
    entity_category: diagnostic
  - platform: safe_mode
    name: "${friendly_name} Safe Mode"
    entity_category: diagnostic

sensor:
  - platform: template
    name: "${friendly_name} Temperatur"
    id: sensor_pool_temperature
    unit_of_measurement: "°C"
    state_class: measurement
    device_class: temperature
    accuracy_decimals: 2
  - platform: template
    name: "${friendly_name} pH"
    id: sensor_pool_ph
    state_class: measurement
    accuracy_decimals: 2
  - platform: template
    name: "${friendly_name} ORP"
    id: sensor_pool_orp
    unit_of_measurement: "mV"
    state_class: measurement
    accuracy_decimals: 0
  - platform: wifi_signal
    name: "${friendly_name} WLAN Signal"
    update_interval: 60s
    entity_category: diagnostic
  - platform: uptime
    name: "${friendly_name} Laufzeit"
    entity_category: diagnostic
  - platform: ble_rssi
    mac_address: "00:A0:xx:D0:xx:xx"   # gleiche MAC wie ble_client oben
    name: "${friendly_name} Boje BLE Signal"
    icon: mdi:signal-variant
    filters:
      - sliding_window_moving_average:   # glättet Ausreißer, ruhigerer Dashboard-Wert
          window_size: 5
          send_every: 1
      - heartbeat: 30s                    # mind. alle 30s einen Wert publizieren, auch ohne neues Paket

binary_sensor:
  - platform: template
    name: "${friendly_name} Boje verbunden"
    icon: mdi:bluetooth-connect
    lambda: 'return id(ble_client_pool).connected();'

text_sensor:
  - platform: wifi_info
    ip_address:
      name: "${friendly_name} IP"
      entity_category: diagnostic
  - platform: ble_client
    id: pool_reading_data
    name: "${friendly_name} raw data"
    internal: true
    ble_client_id: ble_client_pool
    service_uuid: 'F3300001-F0A2-9B06-0C59-1BC4763B5C00'
    characteristic_uuid: 'F3300003-F0A2-9B06-0C59-1BC4763B5C00'
    notify: true
    update_interval: never
    on_notify:
      then:
        - lambda: |-
            std::string rawhex = format_hex_pretty((uint8_t *) x.c_str(), x.size()).c_str();
            ESP_LOGD("raw_hex", "Rohdaten der Boje: %s", rawhex.c_str());

            float temperature = (float)((int16_t)(x[2]<< 8) + x[1])/100;
            id(sensor_pool_temperature).publish_state(temperature);

            float raw_ph = (float)( (int16_t) (x[4]<< 8) + x[3]);
            float ph = (float)( (int16_t) (2048 - raw_ph)) / 232  + 7;
            id(sensor_pool_ph).publish_state(ph);

            float orp = (float)( (int16_t) (x[6]<< 8) + x[5]);
            id(sensor_pool_orp).publish_state(orp/4);

Was hat sich gegenüber der Discovery-Konfig geändert?

• Der on_ble_advertise-Lambda ist weg — der war nur für die MAC-Suche da, jetzt würde er nur noch das Log spammen.
• Ein ble_client-Block sagt dem ESP: „Verbinde dich aktiv mit dieser MAC.“
• Drei sensor-Templates für Temperatur, pH und ORP — die werden vom Lambda am Ende mit den dekodierten Werten gefüttert.
• Ein button-Block, der per BLE-Write die Boje zu einer Messung triggert (das ist die UUID F3300002, „Schreibe [0x01] rein“ = „Wach auf und miss“).
• Eine initiale Messung direkt nach dem Start des ESPs wurde hinzugefügt
• Der ESP initiiert alle 4 Stunden automatisiert eine Messung so dass wir in jedem Fall Tagesverlaufswerte haben
• Ein text_sensor mit ble_client-Platform, der auf die UUID F3300003 lauscht (das ist die „Messwerte-Charakteristik“ der Boje) und beim Eintreffen neuer Daten die Roh-Bytes per Lambda in °C, pH und mV umrechnet. Die Formel im Lambda ist nicht von mir, sondern aus dem Forumsbeitrag von community.simon42.com, wo jemand die Boje reverse-engineered hat.

Flashen ab jetzt drahtlos. Da der ESP schon im Netz hängt (von der Discovery-Konfig), brauchst du kein USB-Kabel mehr. Install → Wirelessly im ESPHome-Dashboard reicht. Der Flash läuft über die OTA-Verbindung, dauert ca. 30 Sekunden.

Werte landen in Home Assistant

Nach dem finalen Flash erscheint dein Gerät automatisch in Home Assistant unter Einstellungen → Geräte & Dienste. Die Sensoren sind angelegt, allerdings noch leer — die Boje muss erstmal eine Messung machen.

Dafür hat ESPHome dir aus dem YAML einen Button gebaut: button.pool_proxy_pool_messung_auslosen. Wenn du den drückst, sendet der ESP einen BLE-Write an die Boje, die daraufhin eine Messung startet und die frischen Werte zurücksendet. Sekunden später hast du Temperatur, pH und ORP in Home Assistant.

Damit kannst du dir jetzt auch eine Automatisierung bauen, die den Button alle paar Stunden automatisch drückt — bei mir alle 2 Stunden zwischen 8 und 22 Uhr.

Phase 6: Das Dashboard

Reine Sensoren in der Geräte-Übersicht sind unsexy. Was du willst, ist ein Dashboard mit Gauges, die sofort zeigen, ob alles im grünen Bereich ist.

Drei Gauges nebeneinander für die schnelle Übersicht. Das Spannende dabei: pH und ORP sind keine „je höher desto besser“-Werte, sondern haben einen Optimum-Bereich in der Mitte — drunter ist schlecht (zu wenig Chlor / saurer Pool), drüber ist auch schlecht (zu viel Chlor / basischer Pool). Eine klassische Glockenkurve.

In Home Assistant kannst du das mit der segments-Eigenschaft einer Gauge-Karte abbilden:

- type: gauge
  entity: sensor.pool_proxy_pool_orp
  name: Chlor (ORP)
  unit: mV
  min: 400
  max: 1000
  needle: true
  segments:
    - from: 400
      color: '#db4437'   # rot - zu wenig
    - from: 600
      color: '#ffa600'   # gelb - niedrig
    - from: 650
      color: '#43a047'   # grün - optimal
    - from: 750
      color: '#ffa600'   # gelb - hoch
    - from: 900
      color: '#db4437'   # rot - zu viel

So bekommst du auf einen Blick eine Ampel — wenn der Zeiger im grünen Mittelteil steht, ist alles gut. Wenn er nach links oder rechts wandert, sehe ich sofort, was zu tun ist.

Das Gleiche für pH (Optimum 7,0 bis 7,4) und ein einfacheres Gauge für Temperatur (wo höher zwar nicht „schlecht“ ist, aber irgendwann unangenehm warm wird). Dazu noch ein History-Graph für die Werte der letzten 24 Stunden und ein Button-Block für die manuelle Messung — fertig ist die Übersicht.

Phase 7: Dosier-Empfehlungen aus den Werten ableiten

Das eigentliche Killer-Feature, dass mir spätestens nach drei Tagen klargemacht hat, dass sich der ganze Aufwand gelohnt hat: Eine dynamische Markdown-Karte, die mir basierend auf den aktuellen Werten konkret sagt, was ich nachdosieren muss.

Bei mir steht da dann zum Beispiel:

Chlor — Zu niedrig (635 mV) — ~50 g Calciumhypochlorit (65%) nachdosieren

pH — Im Sollbereich (7,21) — keine Korrektur nötig

Funktioniert über inline Jinja-Templates in der Markdown-Card, die die aktuellen Sensorwerte lesen und stufenbasiert eine Empfehlung ausspucken. Wichtig: ORP ist kein direkter Chlorwert, sondern ein Indikator — die Mengenempfehlungen sind also Schätzungen, basierend auf Faustregeln für mein Pool-Volumen (32 Kubikmeter). Lieber konservativ dosieren und nochmal messen, als überdosieren.

Die Logik in Kurzform:

Analog für pH mit pH-Plus (Soda) und pH-Minus (Natriumhydrogensulfat).

Die Karte zeigt mir genau das, was ich brauche, in genau dem Moment, in dem ich aufs Dashboard schaue. Statt jedes Mal selbst zu überlegen, welche Mengen für meinen Pool passen.

Was ich gelernt habe

Drei Dinge, die ich beim nächsten ESPHome-BLE-Projekt vom ersten Moment an mitnehmen werde:

Das Scan-Window großzügig auslegen. Die 30-Millisekunden-Defaults aus den Foren sind für ständig sendende Beacons gedacht — für sporadisch sendende Messgeräte brauchst du 200 bis 300 Millisekunden, sonst verpasst du sie schlicht.

Beim Debugging immer ein eigenes Log-Statement reinhauen. Wenn der ESPHome-eigene Log dir gar keine Geräte zeigt, baust du einen Lambda mit ESP_LOGI rein. Das ist 30 Sekunden Aufwand, gibt dir aber Gewissheit, dass der Stack läuft. Ohne diesen Schritt hätte ich noch deutlich länger gesucht.

Vor dem Hardware-Tausch zweimal nachprüfen. Ich war zwei Stunden lang überzeugt, dass mein ESP32 einen defekten BLE-Chip hat, und wollte schon ein anderes Board aus dem Karton holen. War alles Software. Hardware ist seltener kaputt, als man denkt.

Fazit

Die Blue Connect GO in Home Assistant zu integrieren ist machbar an einem Nachmittag — wenn man die zwei Stolpersteine kennt, die ich oben beschrieben habe. Wenn nicht, kann es schnell ein Tag werden.

Was du am Ende hast, ist aber genau das, was die Hersteller-App nicht bietet: Werte ohne Cloud, jederzeit verfügbar, kombinierbar mit anderen Home-Assistant-Daten (PV-Überschuss-Steuerung der Pumpe, Solarheizungs-Logik, Push-Notifications bei kritischen Werten). Die rund 20 Euro für den ESP32 sind verglichen mit dem Nutzen ein Witz.

Und ehrlich: Das Beste an dem Setup ist nicht die Technik, sondern das morgendliche Ritual. Kaffee in der Hand, kurzer Blick aufs Tablet — alles grün, schwimmen kann gleich losgehen. Statt früher: App aufmachen, mit dem Handy zum Pool, warten bis sich was synct, lesen, zurückgehen. Das nervt schon nach drei Tagen.

Der komplette YAML-Code steht oben in den Phasen 3 und 5 als Copy-Paste-Vorlage drin. Wer Fragen hat, einen Tipp loswerden oder eine andere Boje am Start hat — schreib mir gerne, ich freu mich über Erfahrungsaustausch.

Der Beitrag Blue Connect GO in Home Assistant integrieren — Pool-Werte komplett lokal überwachen erschien zuerst auf Das ist die Welt von Thomas.

Ein Kollege hat mich letzte Woche zu einem Termin mitgenommen. Eine Gruppe Menschen, die über eine Kooperation mit dem Arbeitsmarkt zu uns gekommen sind. Menschen, die viele Bewerbungen schreiben. Die wenige oder gar keine Antworten bekommen. Die sich schwertun — manche, weil Deutsch nicht ihre erste Sprache ist, manche, weil die Bewerbung einfach nicht rund ist, manche, weil sie schlicht nicht wissen, wie das heute alles funktioniert.

Und dann fiel das Thema KI.

Die Reaktion hat mich ehrlich gesagt überrascht. Nicht, weil ich keine Ahnung hatte, dass da Skepsis herrscht. Aber wie weit weg das alles von meiner eigenen Realität ist — das hat mich dann doch getroffen.

Wir reden aneinander vorbei

In meiner Welt ist KI Alltag. Ich nutze sie täglich: Anforderungserhebung, Code-Reviews, Texte, Planung. Meine Frau Sarah hat auch angefangen damit — ein bisschen zögerlich noch, aber sie nutzt es. Bei uns ist KI längst kein Thema mehr, das man groß erklären muss.

Und dann sitzt du da, mit Menschen, die noch nie ChatGPT aufgemacht haben. Die KI kennen als Schlagzeile, als Bedrohung, als das Ding, das irgendwann kommt und alles verändert.

Das Ding ist aber: es ist schon da.

Was mich wirklich nachdenklich gemacht hat — wir ITler denken über Dinge nach wie: Welches Modell ist besser? Wie prompted man richtig? Welche Aufgaben delegiere ich an KI, welche nicht? Das sind unsere Probleme. Und das ist natürlich meilenweit entfernt von jemandem, der sich fragt: „Werde ich beim nächsten Bewerbungsgespräch überhaupt noch von einem Menschen gelesen?“

Der Akkuschrauber

Ich habe versucht, das runterzubrechen. Mein Standardvergleich für solche Momente: der Akkuschrauber.

Kein Handwerker dreht heute tausend Schrauben von Hand. Jeder greift zum Akkuschrauber. Nicht weil er muss, sondern weil es einfach sinnvoll ist. Und trotzdem hat nicht der Akkuschrauber das Haus gebaut — der Handwerker hat es gebaut. Das Werkzeug hat ihm nur geholfen.

KI ist nichts anderes. Ein Werkzeug. Kein Teufelswerkzeug, kein Jobkiller, kein Alleskönner. Ein Werkzeug, das man einsetzen kann — oder auch nicht. Aber wer es nicht einsetzt, macht es sich unnötig schwer.

Das gilt übrigens nicht nur für ITler.

Die Sache mit dem Bewerbungsscreening

Ein Punkt, der in der Runde aufkam, hat mich nicht losgelassen. Wenn KI schon heute Bewerbungen voraussortiert — und das tut sie in vielen Unternehmen bereits — dann sind Menschen, deren Bewerbung nicht passt, raus. Ohne dass ein Mensch draufgeschaut hat. Ohne zweite Chance.

Das ist hart. Ich will das nicht schönreden.

Aber die Konsequenz daraus ist nicht, KI abzulehnen. Die Konsequenz ist, das Spiel zu verstehen und mitzuspielen. Keine generische Bewerbung an hundert Unternehmen schicken. Sich mit der Stelle beschäftigen. Die eigene Bewerbung prüfen lassen — von KI, von Freunden, von wem auch immer. Und dann nochmal prüfen.

Lass dir deine Bewerbung von ChatGPT durchlesen. Dann von Gemini. Schau, was beide sagen. Und dann entscheide selbst, was davon zu dir passt — denn wenn eine KI plötzlich hochgestochenes Kanzleideutsch aus dir macht, du aber eigentlich bodenständiger Handwerker bist, dann klingt das nicht nach dir. Und das hilft niemandem.

Wie fängt man an?

Das war die praktischste Frage des Abends, und sie verdient eine praktische Antwort:

Schritt 1: Öffne chat.openai.com oder gemini.google.com. Schreib rein, was dich beschäftigt. Stell eine Frage. Schau, was passiert. Kein Tutorial, kein Kurs — einfach machen.

Schritt 2: Nimm ein konkretes Problem, das dir gerade im Kopf rumgeht — deine Bewerbung, ein Anschreiben, eine schwierige E-Mail. Und unterhalte dich mit der KI darüber wie mit einem Freund. Nicht als Suchmaschine, sondern als Gesprächspartner.

Schritt 3: Gib der KI eine Rolle. Sag ihr: „Du bist HR-Mitarbeiter bei Firma X. Hier ist meine Bewerbung. Was würdest du daran bemängeln?“ Du wirst überrascht sein, wie anders die Antwort wird — und wie viel konkreter.

Die Angst vor KI verliert man nicht durch Nachdenken. Man verliert sie durch Benutzen.

Ein Tipp noch — für alle, die gerade bei null anfangen

Der KI-Podcast der ARD hat vor Kurzem eine Folge rausgebracht zum Thema: Wie fange ich 2026 mit KI an? Ist es zu spät? Was mache ich zuerst? Wirklich empfehlenswert — kein Tech-Insider-Geraune, sondern ehrlich für Einsteiger gemacht.

Was ich mitgenommen habe

Ich sehe mich nicht als KI-Missionar. Das ist nicht mein Ding.

Aber dieser Termin hat mir gezeigt, dass wir in der IT sehr schnell vergessen, wie weit wir von der Realität anderer Menschen entfernt sind. Wir diskutieren über Kontextfenster und Modellvergleiche, während andere noch nicht mal wissen, dass man KI kostenlos nutzen kann.

Das ist keine Kritik an irgendjemandem — das ist einfach so. Aber ab und zu aus der eigenen Bubble rausgucken und sich fragen: Was beschäftigt eigentlich die Menschen, die nicht täglich mit diesem Thema arbeiten? Das tut gut. Mir jedenfalls.

Und das Schönste daran: Was heute noch nicht funktioniert, funktioniert in einem halben Jahr. Ich hab das selbst erlebt — spielmit.eu hätte ich vor einem Jahr mit KI nicht so bauen können wie Anfang dieses Jahres. Die Entwicklung geht schneller als jeder Kurs hinterherkommt.

Also: Gebt KI eine Chance. Probiert Dinge nochmal aus, die vor einem Jahr nicht geklappt haben. Und verliert die Angst — nicht durch Reden darüber, sondern durch Machen.

Der Beitrag Angst vor KI überwinden — und der Moment, in dem mir klar wurde, wie weit wir in der Bubble sind erschien zuerst auf Das ist die Welt von Thomas.

Ich bin Softwarearchitekt. Seit vielen Jahren. Und ich habe mich vor einiger Zeit auch mal in Richtung Business Analyse bewegt — bewusst, mit einem klaren Grund. Aus dieser Kombination heraus habe ich eine ziemlich konkrete Meinung zu der Frage. Hier ist sie.

Warum ich überhaupt in Richtung Business Analyse gegangen bin

Projekte scheitern nicht, weil Entwickler schlecht sind. Das ist meine feste Überzeugung. Sie scheitern, weil zwei Welten aneinander vorbeireden: der Fachbereich und die IT. Beide sprechen unterschiedliche Sprachen, beide meinen es gut, und am Ende entsteht Software, die niemanden wirklich glücklich macht.

Ich glaube, ich kann einem Fachbereich komplexe Dinge einfach erklären. Und ich kann durch die richtigen Fragen helfen, die richtige Lösung zu finden — oder zumindest die Basis dafür. Das wollte ich mit der Business Analyse nutzen. Raus aus dem reinen Entwicklerdenken, rein in die fachliche Welt, um genau an dieser Schnittstelle besser zu werden.

Das ist eine Fähigkeit, die — so viel sei vorweggenommen — in einer KI-Welt nicht weniger wichtig wird. Im Gegenteil.

Was sich gerade wirklich verändert

AI leistet heute schon Erstaunliches. Das ist keine Frage mehr. Wer das bezweifelt, hat vermutlich noch keinen echten Entwicklungsalltag mit einem LLM verbracht.

Aber: AI nutzt die Freiheiten, die man ihr gibt. Vollständig. Und das ist genau das Problem.

In meinen eigenen Projekten habe ich erlebt, wie AI plötzlich veraltete Libraries eingesetzt hat, ohne mit der Wimper zu zucken. Ich habe gesehen, wie Security-Themen einfach ignoriert wurden — Software offen wie ein Scheunenohr. Dokumentation? Fehlanzeige, wenn man nicht explizit danach fragt. Und Architekturentscheidungen trifft die AI eben auch selbst, wenn man ihr keinen Rahmen vorgibt.

Das bedeutet nicht, dass AI schlecht ist. Das bedeutet, dass man wissen muss, was man ihr übergibt — und was nicht.

Der Softwareentwickler als Dompteur

Mein Bild für die Zukunft des Entwicklers ist das des Dompteurs. Nicht der, der die Tiere besiegt. Sondern der, der weiß, wie sie ticken, und der die Richtung vorgibt.

Was braucht es dafür konkret?

Fachlichkeit. Der zukünftige Entwickler muss verstehen, was ein Fachbereich wirklich braucht. Nicht um es selbst zu bauen, sondern um es der AI so aufzubereiten, dass die AI es sauber umsetzen kann. Wer nur Code schreibt, aber keine Anforderungen versteht, hat ein Problem.

Architekturkompetenz. Welches Framework? Welche Architektur? Wie wird das System betrieben? Diese Entscheidungen kann die AI nicht alleine treffen — zumindest nicht sinnvoll. Hier braucht es Erfahrung.

Review und Qualitätssicherung. Prüfen, ob das was die AI gebaut hat, auch wirklich zur Fachlichkeit passt. Ob es sicher ist. Ob es wartbar ist. Das ist kein Nice-to-have, das ist Kernaufgabe.

Guidelines setzen. Rahmenbedingungen für AI-Entwicklung definieren: Security-Standards, Coding-Guidelines, Testabdeckung. Wer das nicht einfordert, bekommt einen Jenga-Turm — von außen stabil, innen wackelig.

Macht mir das Angst?

Ehrlich gesagt: Nein.

Ich sehe AI als Werkzeug. Wie den Akkuschrauber. Als der auf den Markt kam, ist kein einziger Handwerker pleite gegangen. Sie wurden schneller, effizienter, konnten mehr liefern. Nur weil man jetzt einen Hammer hat, ist ja nicht alles gleich ein Nagel.

Wir müssen wissen, welches Werkzeug wir wann einsetzen. Wir müssen lernen, wie es funktioniert. Wer heute sagt „KI macht mich arbeitslos, also ignoriere ich sie“ — der hat das falsch verstanden. Wer heute sagt „KI macht alles, ich muss nichts mehr können“ — der auch.

Die Industrie hat das schon einmal erlebt. Neue Maschinen, neue Techniken, neue Produktivität. Die Arbeitswelt hat sich verschoben, nicht aufgehört.

Was heute schon klar ist

Einen Junior-Entwickler zu beraten, was er in Zukunft tun soll? Ehrlich — ich hab da keine perfekte Antwort. Die Welt verändert sich gerade schnell genug, dass langfristige Karriereratschläge mit Vorsicht zu genießen sind.

Was ich sagen kann: Fachlichkeit, Kommunikationsfähigkeit und der Wille, neue Werkzeuge zu verstehen und zu nutzen — das wird nicht weniger gefragt sein. Wer diese Kombination mitbringt, hat auch in einer KI-getriebenen Entwicklungswelt seinen Platz.

Und wer jetzt anfängt, mit AI zu entwickeln, zu experimentieren und zu lernen wo die Grenzen liegen — der ist schlicht besser aufgestellt als jemand, der abwartet.

Wie seht ihr das? Ich bin gespannt auf eure Perspektive — schreibt’s in die Kommentare.

Der Beitrag Softwareentwickler und KI – wer hat morgen noch einen Job? erschien zuerst auf Das ist die Welt von Thomas.

War es nicht.

Was mich dabei mehr beschäftigt als das Produkt selbst: Was KI-getriebene Produktentwicklung wirklich bedeutet – und warum das größte Risiko nicht der Code ist, sondern der Moment, in dem man der AI einfach antwortet.

Das Grundproblem: Die AI will alles. Sofort. Vollständig.

Stell dir vor, du engagierst einen hochmotivierten Architekten für dein neues Haus. Noch bevor du „Hallo“ gesagt hast, fragt er: Wie viele Stockwerke? Welche Heizung? Soll die Küche offen oder geschlossen sein? Kellergarage oder nicht? Welche Fensterfront gen Süden?

Genau so verhält sich eine AI in der Anforderungserhebung.

Claude – mein Entwicklungspartner in diesem Projekt – stellte von Anfang an präzise, durchdachte Fragen. Die zielten auf eine vollständige, ganzheitliche Lösung ab. Architektonisch macht das Sinn. Produktentwicklungstechnisch ist es eine Falle.

Denn: Wer von Anfang an alles entscheidet, entwickelt am Ende perfekt an den echten Bedürfnissen vorbei.

Das klassische Wasserfallproblem – nur mit KI-Turbo.

Wasserfall 2.0: Schneller in die falsche Richtung

Das Wasserfallmodell ist nicht deshalb gescheitert, weil Menschen zu dumm waren, es umzusetzen. Es ist gescheitert, weil sich Anforderungen verändern, sobald man anfängt, sie zu konkretisieren. Weil der erste echte Nutzer immer Dinge sieht, die kein Workshop-Teilnehmer vorhergesehen hat. Weil Lernen durch Tun nicht durch Planen ersetzt werden kann.

KI-getriebene Entwicklung löst dieses Problem nicht automatisch. Im Gegenteil: Sie beschleunigt es. Man kann in wenigen Stunden ein vollständiges Konzept durchdenken, dokumentieren und in Code überführen – und dabei systematisch an den echten Nutzerbedürfnissen vorbeientwickeln.

Bei spielmit.eu hatte ich genau diesen Moment. Früh wurden UI-Entscheidungen getroffen: Welche Buttons gibt es? Welche Aktionen sind auf welchem Screen verfügbar? Das Ergebnis war ein Interface voller Funktionen – technisch korrekt umgesetzt, aber praktisch eine Zumutung. Tausend Buttons, überladene Screens, keine klare Führung. Erst nach echten Tests und vielen Iterationen kam man auf eine schlanke Lösung.

Wäre man iterativer vorgegangen, hätte das nach dem ersten echten Klick auffallen müssen. Nicht nach zwanzig Entwicklungsrunden.

Die Lösung: Aktiv bremsen, iterativ lernen

Das Gegenmittel klingt einfach. Es ist es nicht.

Als die AI begann, Fragen zu stellen, die ich noch gar nicht beantworten konnte – oder sollte –, musste ich aktiv eingreifen. Meine Standardantwort wurde:

„Damit beschäftigen wir uns später. Lass uns iterativ vorgehen und gemeinsam lernen.“

Das klingt banal. In der Praxis erfordert es diszipliniertes Zurückhalten. Die AI bietet immer eine Antwort an, die sich vollständig und plausibel anfühlt. Die Versuchung, einfach mitzumachen, ist groß.

Was konkret geholfen hat:

Interview statt Fragebogen. Statt alle Fragen auf einmal zu beantworten, habe ich Claude gebeten, sie einzeln zu stellen. Eine Frage. Meine Antwort. Nächste Frage. Das reduziert die Gefahr, sich in frühen Annahmen zu verlieren, dramatisch.

Fachlichkeit vor Technik. Bevor auch nur eine Zeile Code geschrieben wurde, haben wir stundenlang nur die fachliche Logik durchdrungen. Was ist das eigentliche Problem? Wer hat es? Was ist der kleinstmögliche Schritt, der echten Wert liefert?

Kleine, dokumentierte MD-Files statt einem Monolith. Alles landet im Projektverzeichnis – aber verteilt auf kleine, fachlich fokussierte Markdown-Dateien. Eine pro Thema, nicht eine für alles. Das hält das Kontextfenster handhabbar und vermeidet, dass die AI wichtige Anforderungen aus dem Blick verliert.

Prioritäten setzen, nicht alles gleichzeitig. Bei spielmit.eu war von Anfang an klar: Datenschutz und Security sind nicht verhandelbar, alles andere ist nachrangig. Dieses Primat musste ich aktiv verteidigen – nicht einmal, sondern immer wieder.

Nicht-Determinismus: Das unterschätzte Risiko

Eine AI ist kein deterministisches System. Das klingt technisch. Die praktischen Konsequenzen sind handfest.

Derselbe Fehler kann in zwei aufeinanderfolgenden Sessions unterschiedlich interpretiert werden. Einmal findet die AI ihn. Beim nächsten Anlauf übersieht sie ihn – weil sie zwischendurch andere Anforderungen priorisiert hat, weil der Kontext gewachsen ist, weil… nun ja, weil sie eben nicht deterministisch ist.

Man dreht sich im Kreis, ohne es zu merken.

Das erfordert eine Qualität, die kein Prompt ersetzen kann: eigene Wachheit. Als PO oder Architekt muss man verstehen, was gerade wirklich passiert. Wer das vollständig abgibt, verliert die Kontrolle – leise, ohne Drama, und oft erst dann sichtbar, wenn es teuer wird.

Was die AI einfach nicht mitdenkt

Irgendwann habe ich in den Code geschaut. Veraltete Vue-Libraries, fast überall outdated minor versions. Der anschließende Update-Marathon kostete unnötig Zeit – und funktioniert hat er nur, weil wir eine hohe Testabdeckung hatten.

Das Ärgerliche: vollständig vermeidbar. Ein einfacher Check zu Projektbeginn hätte das verhindert. Die AI denkt nicht von alleine an Library-Hygiene, Security-Checks oder Dependency-Management.

Das sind keine Kleinigkeiten. Es sind genau die Dinge, die erfahrene Entwickler im Schlaf prüfen – und die beim KI-getriebenen Entwickeln aktiv eingefordert werden müssen. Am Anfang. Nicht nach zwanzig Iterationen.

Dasselbe gilt fürs Refactoring. Bei größeren Umstrukturierungen wurden Anforderungen vergessen, „zentralisierter“ Code tauchte trotzdem noch an alter Stelle auf. Clean Code und Testabdeckung sind keine akademischen Tugenden. Sie sind das Einzige, was einen vor dem Jenga-Turm rettet – dem Produkt, das von außen funktioniert, das man aber nicht mehr anfassen möchte.

Was AI in der Anforderungserhebung wirklich gut kann

Was KI in der Anforderungserhebung wirklich gut kann? Blinde Flecken aufdecken. Sie stellt Fragen die man selbst nicht stellt – einfach weil man zu nah am Problem dran ist. Genauso gut kann sie Perspektivwechsel erzwingen. „Wie würde ein datenschutzbewusstes Elternteil darauf reagieren?“ – solche Fragen lassen sich schnell und konsequent durchspielen. Was sie dabei aber nicht kann: entscheiden. Die Konsequenzen durchdenken ja, die Entscheidung treffen nein. Das bleibt beim Menschen – weil nur der weiß was er noch nicht weiß.

Der Trick ist, die AI aktiv zum Mitdenken anzuregen. Sie tut das nicht von alleine. Man muss fragen: „Welche Annahme, die wir gerade treffen, könnte sich als falsch herausstellen?“ Oder: „Was spricht dagegen?“

Fazit: AI First ist (noch) keine Option

KI-getriebene Entwicklung funktioniert. Mit Spielregeln, mit Disziplin, mit dem Willen, klein anzufangen und lieber öfter zu lernen als schnell zu skalieren.

AI First – also vollständige Entwicklung ohne menschliche Architektur-Entscheidungen, ohne Review, ohne iteratives Korrektiv – ist heute noch nicht möglich. Wer es trotzdem versucht, bekommt entweder ein Produkt, das die fachlichen Anforderungen nicht erfüllt. Oder, schlimmer, eines, bei dem man das glauben könnte – darunter aber ein Fundament aus technischen Schulden, das nur durch Zufall noch steht.

Die gute Nachricht: Die Kombination aus menschlicher Erfahrung und AI-Geschwindigkeit ist mächtig. Alleine hätte ich spielmit.eu nie gebaut – der Aufwand wäre zu groß gewesen für ein kostenloses Freizeitprojekt. Mit AI als Entwicklungspartner war es möglich.

AI First – also vollständig ohne menschliches Korrektiv – funktioniert heute noch nicht. Wer es trotzdem versucht, merkt das früher oder später. Ich bin froh, dass ich es in der Freizeit gelernt habe.

Der Beitrag KI-getriebene Anforderungserhebung: Warum du die AI bremsen musst, bevor du startest erschien zuerst auf Das ist die Welt von Thomas.

Kurz zur Einordnung: Im Juni 2025 habe ich mein Selbstexperiment „Bitcoin Mining mit PV-Überschuss“ gestartet. Ein Antminer S19j Pro, gesteuert über Home Assistant, betrieben mit dem Überschuss meiner 14,4 kWp PV-Anlage. Nach einem Jahr ist es Zeit für ein ehrliches Fazit. Spoiler: Es wird kein Jubelartikel.

Der Rückblick – was ist passiert?

Wer die bisherigen Artikel verfolgt hat, kennt das Setup: Antminer S19j Pro mit Braiins OS, gesteuert über Home Assistant, angeschlossen über einen SONOFF POW320D Smart Schalter. Die Fronius Wechselrichter liefern die PV-Daten, Home Assistant berechnet den Überschuss und regelt den Miner automatisch hoch und runter. Das Ganze steht in der Garage – im Haus wäre es schlicht nicht auszuhalten, sowohl von der Lautstärke als auch von der Abwärme.

Über den Sommer 2025 lief das System richtig gut. An sonnigen Tagen sprang der Miner morgens an, wurde je nach Überschuss zwischen 1.000 und 2.800 Watt geregelt und ging abends wieder in den Standby. Die Automatisierung funktionierte zuverlässig und brauchte nach der initialen Einrichtung kaum noch Pflege.

Dann kam der Herbst. Und mit ihm die ernüchternde Erkenntnis: keine Sonne, kein Mining. Im Winter ging praktisch gar nichts – die PV-Anlage lieferte gerade genug für den Eigenverbrauch, an Überschuss für den Miner war nicht zu denken. Der Antminer stand also monatelang still.

Die Technik – läuft wie eine Eins

Das muss man klar sagen: technisch ist das Projekt ein voller Erfolg. Der Antminer S19j Pro läuft seit einem Jahr ohne einen einzigen Ausfall. Das Braiins OS macht seinen Job, die Home Assistant Automatisierung regelt zuverlässig und die gesamte Kette von PV-Wechselrichter über die Automatisierung bis zum Miner funktioniert problemlos.

Ich betreibe den Miner bewusst nicht auf Volllast, sondern maximal bei 2.800 Watt. Das schont die Hardware – die Chip-Temperatur bleibt entspannt bei rund 66 Grad – und bringt ein gutes Verhältnis aus Hashrate und Effizienz. Der Sprung auf die vollen 3.250 Watt bringt nur marginal mehr Hashrate bei deutlich höherer Temperatur und schlechterer Effizienz.

Pool-Mining – die ernüchternde Rechnung

Im Sommer 2025 lief der Miner über verschiedene Mining-Pools. Ich habe einige ausprobiert – Antpool, Braiins Pool, F2Pool, CloverPool – und die Erträge verglichen. Ein realistischer Tagesertrag lag bei rund 0,00003 BTC, wenn der Miner etwa 8 Stunden bei gutem Sonnenschein laufen konnte.

Klingt erstmal nach „immerhin etwas“. Aber rechnen wir das mal durch:

Selbst bei der durch das Solarspitzengesetz reduzierten Einspeisevergütung ist der direkte Vergleich ernüchternd. Ja, an manchen Stunden gibt es gar keine Vergütung wegen negativer Börsenpreise – da macht Mining Sinn. Aber in der Gesamtbetrachtung über den Tag ist der Vorteil gegenüber dem Einspeisen minimal bis nicht vorhanden. Und das bei einem BTC-Kurs, der seit letztem Jahr von rund 95.000 € auf aktuell rund 60.000 € gefallen ist.

Die bittere Wahrheit: Der BTC-Kurs ist im Vergleich zum Vorjahr deutlich gefallen. Was letztes Jahr schon knapp war, rechnet sich heute noch weniger. Die wenigen Satoshi, die über Pool-Mining zusammenkommen, sind in Euro umgerechnet weniger wert als die entgangene Einspeisevergütung – selbst bei den durch das Solarspitzengesetz gedrückten Sätzen.

Der Wechsel zum Solo-Mining – Lotto mit Sonnenstrom

Ende der Saison 2025 habe ich die Konsequenz gezogen und vom Pool- auf Solo-Mining umgestellt. Der Miner läuft jetzt über den CK Pool im Solo-Modus.

Die Überlegung dahinter ist simpel: Wenn sich Pool-Mining finanziell nicht rechnet, kann ich auch gleich auf das große Los setzen. Die Chance, mit meiner Hashrate einen eigenen Block zu finden, ist extrem gering – aber der Gewinn wäre mit der aktuellen Block-Belohnung von 3,125 BTC (also knapp 190.000 €) ein absoluter Gamechanger.

Wo stehe ich aktuell? Mein Miner hat bisher 40,02 Gigashares berechnet. Mein bester Share lag bei 1,56 Terashares – das klingt beeindruckend, ist aber noch ungefähr Faktor 40 vom Ziel entfernt. Es ist Lotto. Vielleicht habe ich morgen Glück, vielleicht nie. Aber der Strom ist da, der Miner steht in der Garage, und die Kosten für den Betrieb sind quasi null.

Solo-Mining mit PV-Überschuss ist im Grunde ein Lotterielos, das man mit Sonnenstrom bezahlt. Der Einsatz ist virtuell, der mögliche Gewinn real.

Würde ich den Miner nochmal kaufen?

Klare Antwort: Nein.

Die rund 700 Euro Anschaffungskosten lassen sich über Pool-Mining nur über viele Jahre wieder reinholen – wenn überhaupt. Ich hatte auch kurz überlegt, auf einen moderneren Antminer S21 Pro umzusteigen, der bei gleicher Leistungsaufnahme fast die doppelte Hashrate liefert. Aber die Anschaffungskosten sind so viel höher, dass sich die Rechnung erneut nicht aufgeht.

Mein Miner ist jetzt da, also läuft er weiter. Die Preise für gebrauchte S19-Modelle sind mittlerweile auch ziemlich am Boden – teilweise unter 600 Euro. Das sagt einiges über den Markt aus.

Mein Fazit nach einem Jahr

Was gut funktioniert: Die Technik ist absolut solide. Home Assistant mit dem Miner-Plugin, Braiins OS und die PV-Anbindung über Fronius – alles läuft stabil und wartungsfrei. Wer Spaß an Heimautomatisierung und Technik hat, bekommt hier ein tolles Projekt. Die Automatisierung des Miners über PV-Überschuss funktioniert zuverlässig und man lernt extrem viel über Mining, Hashrates, Pools und das Bitcoin-Netzwerk.

Was nicht funktioniert: Die wirtschaftliche Seite. Pool-Mining rechnet sich bei einem einzelnen S19j Pro mit PV-Überschuss nicht – schon gar nicht bei einem BTC-Kurs von 60.000 €. Der Miner steht im Winter still, und selbst im Sommer sind die Erträge in Euro geringer als das, was man über die Einspeisevergütung bekommen hätte. Solo-Mining ist ein reines Glücksspiel.

Meine Empfehlung

Wenn mich heute jemand fragt, ob er sich einen Miner für den PV-Überschuss kaufen soll, ist meine analytische Antwort klar: Nein, tu es nicht. Die Chancen sind zu gering und die Rechnung geht in den allermeisten Fällen nicht auf.

Aber – und das ist das große Aber – wenn du es als Hobby betrachtest, Spaß an der Technik hast und den Miner als eine Art Lotterielos mit Sonnenstrom siehst: why not? Der Strom ist da, die laufenden Kosten sind quasi null, und die kleine Chance auf einen Solo-Block macht das Ganze zumindest spannend.

Sollte ich morgen einen Block finden, sieht die Welt natürlich komplett anders aus. Dann schreibe ich hier einen ganz anderen Artikel. Bis dahin bleibt es bei dem, was es ist: ein spannendes Technikprojekt mit einer ernüchternden wirtschaftlichen Bilanz.

TL;DR: Nach einem Jahr Bitcoin Mining mit PV-Überschuss ist das Fazit klar: technisch top, wirtschaftlich flop. Pool-Mining bringt weniger als die Einspeisevergütung, Solo-Mining ist Lotto. Ich würde mir keinen Miner mehr kaufen – lasse meinen aber weiterlaufen, weil der Strom ohnehin da ist. Wer es als Hobby sieht und die ~700 € investieren will: kann man machen. Wer Geld verdienen will: Finger weg.

Wie sind Deine Erfahrungen nach einem Jahr Bitcoin Mining? Hast Du ähnliche Erfahrungen gemacht oder siehst Du das komplett anders? Ich freue mich auf den Austausch in den Kommentaren!

Der Beitrag 1 Jahr Bitcoin Mining mit Solarstrom – eine ehrliche Bilanz erschien zuerst auf Das ist die Welt von Thomas.