Mit KI-Agenten entstehen Power BI Custom Visuals in Tagen statt Wochen – wenn der Plan stimmt. Michael Wetzel zeigt an einem Radar-Chart aus einem Kundenprojekt, warum die Spezifikation die halbe Arbeit ist und wie der Performance Analyzer Fehler eingrenzt.
Können Time-Series-Foundation-Models die Wärmebedarfsprognose in Fernwärmenetzen verbessern? In unserer Offline-Studie vergleichen wir Chronos-2, TimesFM-2.5 und Moirai-2 mit AutoARIMA, XGBoost und weiteren Baselines auf der Grundlage realer Daten aus vier Fernwärmenetzen. Chronos-2 erzielte die besten Ergebnisse, sogar im Zero-Shot-Einsatz ohne Trainingsdaten aus dem Zielnetz. Der Beitrag untersucht die Dateneffizienz, das Fine-Tuning, die Robustheit bei fehlerhaften Sensordaten und die Zuverlässigkeit im Betrieb.
Rund 30 Teilnehmende aus den Bereichen Wohlfahrtsverbände, Entwicklungszusammenarbeit, Digitalpolitik, Wissenschaft und lokale Zivilgesellschaft nahmen an unserem kostenlosen RAG-Workshop mit dem Civic Data Lab teil. Zwei Stunden lang ging es um die Grundlagen von Retrieval-Augmented Generation, eine Hands-on-Session und die Frage, wann RAG das passende Werkzeug ist. Den Rückblick mit den Folien zum Download finden Sie hier.
Beim scieneers Herbstevent 2026 kamen Kolleg:innen aus fünf Standorten in Hamburg zusammen. Zwei Tage lang standen fachliche Sessions, Teamarbeit, persönliche Lightning Talks und gemeinsamer Austausch im Mittelpunkt.
Der Data Product Owner spielt eine zentrale Rolle bei der Entwicklung erfolgreicher Datenprodukte. Neben den Aspekten Desirability, Viability und Feasibility muss er zusätzlich die Perspektive „Datability” managen, denn Unsicherheit, Datenqualität und iterative Weiterentwicklung prägen jedes Datenprojekt. Der Beitrag zeigt, welche Aufgaben und Kompetenzen einen guten Data Product Owner ausmachen und wie sich diese Rolle von der des Data Scientists abgrenzt.
Die Verlockung von Large Language Models (LLMs) im Entwicklungsalltag ist riesig: Ein kurzer Prompt im Chat, und Sekunden später steht eine lauffähige Ad-hoc-Lösung bereit. Doch dieser Fokus auf die schnelle Umsetzung hat seinen Preis. Was kurzfristig wie ein massiver Produktivitätsschub aussieht, rächt sich schnell durch mangelnde Wartbarkeit, fehlende Stabilität und das Fehlen einer klaren architektonischen Richtung.
An dieser Stelle setzt das Paradigma des Spec-Driven Developments (SDD) an. Specs waren schon immer mehr als nur staubige Dokumentation: Sie definieren die Anforderungen. Im Zeitalter der KI-gestützten Entwicklung werden sie nun zu einer dynamischen Denkschicht und dem zentralen, geteilten Kontext zwischen Entwickler und Modell.
Dieser Beitrag basiert auf einem unserer internen Share-Knowledges. Gerne schicken wir den Link zum Video an deine E-Mail Adresse.
Wer komplexe Features ausschließlich über interaktive Prompts in einer spontanen Chat-Session entwickelt, baut unbewusst technische Schulden auf. Das liegt nicht an einer generellen Schwäche der LLMs – mit dem passenden Kontext arbeiten diese extrem präzise. Das Problem ist vielmehr das unstrukturierte „Vibe Coding“ ohne festen Rahmen. Ohne ein klares, konsistentes Gerüst wird das Modell mit zersplitterten Informationen gefüttert, wodurch der Blick für das große Ganze und die langfristige Stabilität des Gesamtsystems verloren geht.
Beim intuitiven „Vibe Coding“ im Chat stolpert man meist über drei typische Probleme:
Spec-Driven Development löst dieses Problem, indem es die Spezifikation der Anforderungen zeitlich vor die eigentliche Code-Generierung stellt. Sie dient als expliziter, versionierter und geteilter Kontext (Shared Context) zwischen dem Software Engineer und dem LLM, bevor auch nur eine Zeile Code geschrieben wird.
Was zeichnet eine effektive Spec im SDD-Umfeld aus?
Wie tief die Anforderungen in den KI-gestützten Entwicklungszyklus integriert werden, lässt sich hervorragend anhand der Taxonomie von Martin Fowler (2025) verdeutlichen:
Die methodischen Ansätze sind das eine, doch wie sieht das Ganze in der Praxis aus? Für die Umsetzung des Spec-Driven Development Workflows existieren mittlerweile mehrere Frameworks – etwa OpenSpec oder SpecKit – die jeweils eigene Schwerpunkte setzen. Ich greife hier exemplarisch das Command-Line-Tool SpecKit heraus, das genau diesen Workflow über strukturierte Befehle für deinen KI-Coding-Assistenten erzwingt. Die vorgestellten Prinzipien lassen sich aber genauso auf die anderen Tools übertragen.
Der Workflow von SpecKit gliedert sich in fünf aufeinander aufbauende Phasen, die den Entwicklungsprozess leiten und jeweils reviewbare Artefakte erzeugen:
Hier werden High-Level-User-Stories in eine standardisierte und maschinenlesbare Anforderungsliste (spec.md) überführt.
Lücken in den User Stories werden nicht stillschweigend von der KI interpretiert. Stattdessen triggert dieser Befehl eine strukturierte Q&A-Runde, um ungesagte Annahmen und Edge-Cases vorab zu klären.
Es wird ein detaillierter technischer Umsetzungsplan generiert. Das Ergebnis sind zwei wesentliche Dokumente:
research.md: Eine strukturierte Analyse komplexerer Probleme (z. B. Chunking-Strategien bei langen osTicket-Verläufen).contracts/: Festgelegte Daten- und API-Schnittstellenspezifikationen, die im Vorfeld wie ein starres Schema definiert werden.
Der Plan wird in eine konkrete, schrittweise Task-Liste (tasks.md) überführt. Aufgaben, die parallel gelöst werden können, erhalten einen Marker ([P]), was die Arbeitsteilung unter verschiedenen Sub-Agenten ermöglicht.
Erst nach dieser lückenlosen Vorbereitung wird der eigentliche Code generiert. Das LLM arbeitet nun nicht mehr im luftleeren Raum, sondern baut den Code entlang der exakt definierten Tasks und Verträge.
| Der Mehrwert (Value) | Die Investition (Investment) |
|---|---|
| Klare Trennung der Absichten (Separated Intent): Logik und Anforderungen (Was) werden sauber von der reinen Code-Syntax (Wie) getrennt. | Standardisierungs-Hürden: Es gibt noch keinen allgemeingültigen Industriestandard für KI-Spezifikationen. |
| Lebendige Dokumentation: Da Anforderungen und Schnittstellen-Spezifikationen im Repository leben, spiegeln sie immer den echten Systemzustand wider. | Initialer Mehraufwand (Setup Overhead): Das Einrichten strukturierter Prozesse und das Formulieren der Specs benötigt anfangs mehr Zeit als ein schneller Chat-Prompt. |
| Konsistenter Kontext: Prompt Drift und das Verzetteln in langen, unübersichtlichen Chat-Verläufen gehören der Vergangenheit an. | Pflegeaufwand (Maintenance Debt): Nimmt man Abkürzungen und ändert Code direkt, veraltet die Spec und verliert ihren Wert. |
| Perfekt für die Kommunikation: Da die fachliche Logik textbasiert festgehalten ist, lässt sie sich hervorragend mit nicht-technischen Stakeholdern besprechen. | Höherer Token-Verbrauch: Das ständige Übergeben des gesamten Spec-Kontexts an das LLM sowie die Generierung der Specs erhöht die API-Kosten. |
Spec-Driven Development bedeutet nicht, dass man für jede kleine Änderung ein riesiges Framework anwerfen muss. Wichtig ist, die Tiefe des Toolings an die Komplexität anzupassen:
Am Ende des Tages ist das exakte Format zweitrangig. Wichtig ist nur der mentale Shift: Erst explizit denken und spezifizieren, dann generieren lassen.
Gerne schicken wir den Video-Link an deine E-Mail Adresse.
Alina Dallmann
Data Scieneer bei scieneers GmbH
alina.dallmann@scieneers.de
Eine einzelne Mutation im HBB-Gen verursacht die Sichelzellkrankheit, indem sie Form und Funktion der roten Blutkörperchen verändert. Dieser Artikel beleuchtet die Biologie hinter der Krankheit, ihren Zusammenhang mit Malaria und wie CRISPR-Gentherapien wie Casgevy und Indiens Birsa-101 die Mutation an ihrem Ursprung korrigieren wollen.
Jedes menschliche Genom enthält Millionen genetischer Varianten. Die meisten sind harmlos, doch manchmal kann schon eine einzige Veränderung eine schwere Krankheit verursachen. Diese eine Variante zu finden gleicht der Suche nach der Nadel im Heuhaufen – eine Herausforderung, die zunehmend mit Machine Learning angegangen wird.
Wenn der Linienbetrieb endet, beginnt im Straßenbahndepot ein komplexes Optimierungsproblem. Gemeinsam mit der Firma IVU Traffic Technologies haben wir untersucht, wie Deep Reinforcement Learning die dynamische Disposition im Depot unterstützen kann.
Beim diesjährigen Frühlingsevent in Köln kamen Kolleg:innen aus allen Standorten zusammen, darunter erstmals auch welche aus Berlin und München. Zwei Tage lang standen Austausch, Teamkultur und spannende interne Themen im Mittelpunkt – von Leistungsbeurteilung und Feedback über KI-Ethik bis hin zu Diversity, Co-Design und gemeinsamen Aktivitäten in Köln. Der Rückblick zeigt, wie wertvoll persönliche Begegnungen sind, wenn ein Team weiter wächst und zugleich eng verbunden bleiben möchte.