Es war ein ganz normaler Morgen. Ich bin früh am Schreibtisch, Kaffee noch heiß, und schaue kurz ins Kundenportal meines Stromanbieters. Irgendwas mit einer Umstellung. Ich klicke mich durch, lande bei den Einstellungen und sehe dort einen Bereich, den ich noch nie bewusst wahrgenommen hatte: API-Zugang. Mit einem bereits generierten API-Key.
Ich starre auf den Bildschirm.
Ein API-Key. Vom Stromanbieter. Für mich. Kostenlos. Einfach so da.
Wer mich kennt, weiß, was dann passiert. Ich öffne Claude und tippe: „Ich habe gerade im Portal meines Stromanbieters einen API-Key gefunden. Was kann ich damit anstellen?“
Was folgte, waren mehrere Stunden intensivem Gespräch, Planung, Codegenerierung, Fehlersuche, Sicherheitsüberlegungen und am Ende ein fertiges Projekt, das tatsächlich läuft. Unter meiner eigenen Domain. Mit Live-Daten. Mit iOS-Widget. Mit allem Drum und Dran.
Das ist die Geschichte davon.
Was die API überhaupt liefert
Bevor wir ins eigentliche Coding einsteigen, kurz zum Kontext: Mein Stromanbieter bietet für Smartmeter-Kunden eine API an, über die man den eigenen Stromverbrauch abfragen kann. In 15-Minuten-Intervallen. Mit Bezug und Einspeisung (wenn man eine PV-Anlage hat). Das klingt trocken, ist aber eigentlich ziemlich bemerkenswert, weil die meisten Leute gar nicht wissen, dass ihre Energieversorger solche Schnittstellen überhaupt anbieten.
Ich gehöre auch zu diesen Leuten. Bis zu dem Morgen.
Die API liefert Rohdaten: Zeitstempel, Kilowattstunden Bezug, Kilowattstunden Einspeisung, alles in 15-Minuten-Blöcken. Daraus alleine kann man noch nichts Sinnvolles anzeigen. Man braucht Aggregation, also Zusammenfassung über Tage, Monate, aktuelle Werte. Man braucht eine Datenbank. Man braucht ein Frontend. Man braucht eine sichere Art, den API-Key zu verwahren, ohne ihn einfach in den Code zu schreiben.
Kurz gesagt: Man braucht ein Projekt.
Und genau da kam Claude ins Spiel.
Das erste Gespräch: Von der Idee zur Architektur
„Was kannst du damit anstellen?“ Das ist natürlich keine technische Frage. Das ist eine Einladung zum Brainstormen. Claude hat sie angenommen.
Wir haben relativ schnell festgelegt, was das Ding können soll: aktuellen Verbrauch anzeigen, Tagesverbrauch, Monatsvergleich, Einspeisung vs. Bezug. Nicht zu kompliziert, aber nützlich genug, dass es sich lohnt, es zu bauen.
Dann kam die Frage, wo das Ganze läuft. Ich habe zwei Server-Setups: Mittwald für klassisches PHP/MySQL ohne Docker, Hetzner mit Coolify für alles Containerisierte. Das Dashboard passt perfekt auf Mittwald. Kein Overkill, kein Node.js, kein Docker. Einfach PHP, MySQL, ein paar sauber strukturierte Dateien.
Claude hat die Datenbankstruktur vorgeschlagen. Eine Tabelle für die Rohdaten direkt aus der API, mit Timestamp, Bezug-kWh und Einspeise-kWh pro 15-Minuten-Intervall. Indexes auf den Timestamp, damit spätere Abfragen nicht ewig dauern. Das klingt selbstverständlich, aber genau das ist der Unterschied zwischen „Code der funktioniert“ und „Code der auch in drei Monaten noch funktioniert, wenn 50.000 Datensätze in der Tabelle stehen.“
Ein Detail, das mir Claude ohne besonderes Nachfragen erklärt hat: Duplicate-Handling. Die API kann manchmal den gleichen Zeitraum zweimal liefern, wenn man sie zu kurz hintereinander abfragt. INSERT IGNORE mit einem Unique-Index auf den Timestamp verhindert, dass die Datenbank dabei Müll schreibt. So etwas vergisst man gerne, wenn man es selbst baut. Ich hätte es vergessen.
Vibe Coding: Was das wirklich bedeutet
Ich sollte kurz erklären, was ich unter „Vibe Coding“ verstehe, weil der Begriff gerade überall auftaucht und manchmal als Synonym für „KI hat irgendwas zusammengewürfelt“ verwendet wird.
Das ist nicht, was ich meine.
Vibe Coding bedeutet für mich: Du bringst die Idee, das Verständnis für das Problem und die Fähigkeit, Ergebnisse zu bewerten. Die KI, in meinem Fall Claude Code, bringt das technische Handwerk. Der entscheidende Punkt ist, dass du als Mensch weißt, was du willst, und gut genug einschätzen kannst, ob das, was du bekommst, tatsächlich das ist, was du willst.
Das erfordert keine Programmierkenntnisse im klassischen Sinne. Es erfordert aber Urteilsvermögen. Und es erfordert, dass du bereit bist, Fragen zu stellen, wenn dir etwas unklar ist.
Bei meinem Strom-Dashboard-Projekt habe ich genau das getan. Wenn Claude einen Code-Block vorgeschlagen hat, den ich nicht vollständig verstanden habe, habe ich gefragt: „Warum machst du das so? Was wäre die Alternative?“ Die Antworten waren meistens erhellend, manchmal haben sie die Richtung geändert.
Das ist der Unterschied zwischen „die KI macht für mich“ und „ich arbeite mit der KI.“
Datenbank, PHP und das ewige Thema Sicherheit
Der eigentliche Build war überraschend flüssig. Claude hat in mehreren Schritten geliefert: zuerst das SQL-Setup, dann ein PHP-Script für den API-Abruf und die Datenbankbefüllung, dann das Frontend mit den aggregierten Werten, dann die Absicherung.
Beim Thema Absicherung wurde es besonders interessant.
Mein erster Impuls war simpel: einfach die PHP-Datei mit den Daten passwortschützen. Claude hat das nicht sofort verworfen, aber erklärt, warum ein Secret-Parameter sinnvoller ist für meinen Use Case. Ein ?secret=xxx-Parameter in der API-URL, den nur berechtigte Clients kennen. Kein Login-Formular, keine Session-Verwaltung, trotzdem geschützt.
Der API-Key selbst liegt nicht im Code. Er liegt in einer .env-Datei außerhalb des Web-Root-Verzeichnisses. Das klingt nach einem kleinen Detail, ist aber der Unterschied zwischen einem API-Key, der in drei Wochen im Internet auftaucht, und einem, der es nie tut. Claude hat darauf hingewiesen, ohne dass ich danach gefragt hätte.
Ebenfalls proaktiv erklärt: Rate Limiting für den Cron-Job, der die API regelmäßig abfragt. Dass das über meinen n8n-Server läuft, ist dem treuen Leser meine Seite klar. Die API hat Limits, und wer zu häufig abfragt, riskiert eine temporäre Sperre. Ein simpler Sleep-Befehl zwischen den Batches löst das Problem komplett.
Ich hätte an keinen dieser Punkte alleine gedacht. Nicht weil ich sie nicht kennen würde, sondern weil man im Flow des Bauens dazu neigt, das Fertigstellen über das Absichern zu stellen.
Das Frontend: Daten, die man wirklich lesen kann
Das Dashboard ist bewusst schlicht gehalten. Aktuelle Verbrauchswerte, Tagesverbrauch, Gestern, Monat, letzter Monat zum Vergleich. Kein überfülltes Chart-Chaos, keine bunten Balken, die niemand versteht. Die Zahlen, die ich täglich wissen will, auf einen Blick.
Das Design orientiert sich an meinem Terminal Noir Ansatz: dunkler Hintergrund, Cyan als Akzentfarbe, Monospace-Font. Nicht weil es besonders originell ist, sondern weil es zu dem passt, was ich für meine Projekte konsistent halte.
Claude hat das Frontend auf Basis einer kurzen Beschreibung erstellt. Ich musste ein paarmal nachjustieren, weil mir die Proportionen nicht gepasst haben, und einmal, weil ein Zahlenwert falsch berechnet wurde. Der Debugging-Prozess dabei war ebenfalls aufschlussreich: Claude hat nicht einfach den Code neu geschrieben, sondern erklärt, was der Fehler war und warum er entstanden ist. Das ist langfristig wertvoller als eine schnelle Korrektur ohne Erklärung.
Bonus: Das iOS-Widget
Irgendwann während des Projekts kam mir die Idee, die Daten nicht nur im Browser zu sehen, sondern direkt auf dem iPhone-Homescreen. Ein kleines Scriptable-Widget, das meinen aktuellen Tagesverbrauch, den von gestern und den Monatsstand (aktuell und historisch) anzeigt.
Ich habe Claude nach einem Scriptable-Script gefragt. Was ich bekommen habe, war vollständig und sofort funktionsfähig: Datenabfrage über den abgesicherten data.php-Endpunkt, Terminal Noir Styling mit den gleichen Farben wie das Web-Dashboard, Fehler-Handling für den Fall, dass der Server nicht erreichbar ist.
Das Widget läuft seit Tagen stabil. Jeden Morgen, wenn ich das Telefon aufhebe, sehe ich meinen gestrigen Verbrauch und den bisherigen Monatsstand. Statt im Kundenportal nachzuschauen, statt die App zu öffnen.
Kleine Sache. Aber genau die Art von kleiner Sache, für die ich früher entweder einen Entwickler gebraucht hätte oder es einfach nicht gemacht hätte.
Was Claude Code hier eigentlich leistet
Ich möchte an dieser Stelle ehrlich sein, weil das Thema oft romantisiert wird.
Claude Code ersetzt keine Entwicklungskompetenz. Wenn du nicht verstehst, was eine Datenbank ist, wirst du auch mit Claude Code kein gutes Datenbankschema bauen. Du wirst es bauen lassen, ohne zu wissen ob es gut ist, und das rächt sich spätestens, wenn etwas schief geht.
Was Claude Code aber wirklich leistet, ist das Schließen der Lücke zwischen Verstehen und Können. Ich verstehe, wie Datenbankoptimierung funktioniert. Ich kann sie nicht mit der gleichen Geschwindigkeit und Fehlerfreiheit implementieren wie Claude. Ich verstehe, warum API-Keys nicht in den Code gehören. Ich hätte das Setup ohne Unterstützung in zwei Tagen gebaut, mit Unterstützung in zwei Stunden.
Dieser Unterschied ist für Einzelunternehmer und kleine Teams der eigentliche Mehrwert. Nicht „KI macht alles“, sondern „KI hebt meine Fähigkeiten auf das nächste Umsetzungslevel.“
Was du mitnehmen kannst
Vielleicht hast auch du irgendwo einen API-Key, der auf dich wartet. In deinem Banken-Portal. Im CRM deines Unternehmens. In der HR-Software. Bei deinem Hosting-Anbieter. Und vielleicht dachtest du bisher, dass du einen Entwickler bräuchtest, um daraus etwas Sinnvolles zu machen.
Brauchst du nicht zwingend. Aber du brauchst Neugier. Die Bereitschaft, zu fragen, nachzufragen, zu verstehen. Und du brauchst einen klaren Kopf für das, was das Tool am Ende können soll.
Das Strom Dashboard ist kein komplexes Projekt. Es ist ein nützliches Projekt. Und der Unterschied ist genau das, was beim Vibe Coding am Ende zählt: nicht wie beeindruckend der Code ist, sondern ob er das Problem löst, für das du ihn gebaut hast.
Meiner löst es. Jeden Morgen um 6:30 Uhr, direkt nach dem Aufwachen, sehe ich auf dem Widget, wie viel Strom wir gestern verbraucht haben. Und mein n8n-Server schickt mir das via Telegram auch gleich zum Frühstück.
Das ist mehr wert als jede Excel-Tabelle, die ich je manuell gepflegt habe.
