Die Spezifikation als alleinige Wahrheit, nicht als Nebendokument.
Spec-Driven Development ist eine dieser Ideen, auf die Softwareentwickler in der Vergangenheit zurückgegriffen und die sie dann wieder beiseitegelegt haben, als der Aufwand nicht mehr lohnenswert war.
Spezifikationen als Single Source of Truth oder langsame Zeremonie?
Spec-Driven Development trat 2026 als die ernsthafte Antwort der Entwickler auf den Drift des Vibe Codings in Erscheinung.
Halten Sie die Absicht nah am Code.
Entscheidungsdokumente sind die fehlende Speicherschicht in der KI-gestützten Softwareentwicklung. Sie erfassen nicht nur, was gebaut wurde, sondern auch warum – und diese Unterscheidung wird entscheidend, wenn KI-Tools Ihren Code schreiben.
Behandeln Sie Fehler an der richtigen Grenze.
Das Fehlerhandling in Go ist ein beliebter Kritikpunkt. Jeder Go-Entwickler hat diesen Code hunderte Male geschrieben:
Vermeiden Sie unnötiges Warten in parallelen Go-Tests.
Das Testen von parallelem Go-Code erforderte bisher stets eine gewisse Disziplin. Goroutinen sind günstig, Channels sind einfach und die Kontextabsage ist idiomatisch – Hintergrundarbeiter und Timer sind in echten Go-Diensten allgegenwärtig.
A2A ist nicht tot. Es ist einfach nicht universell.
Googles Agent2Agent-Protokoll, meist als A2A abgekürzt, hatte ein seltsames erstes Jahr.
Zuverlässige Polling-Muster für KI-Agenten.
Polling-Agenten gehören zu den wenig glamourösen Aspekten der Architektur von KI-Assistenten, sind jedoch gleichzeitig eine der nützlichsten Komponenten.
A2A macht Agents zu Netzwerkpeers.
Das A2A-Protokoll (Agent2Agent Protocol) ist ein offener Standard für die Kommunikation zwischen unabhängigen KI-Agenten-Systemen.
MCP gibt Agenten Werkzeuge. A2A gibt Agenten Peers.
Die Architektur von KI-Agenten beginnt sich in zwei Schichten zu gliedern.
CQRS in Go implementieren, ohne unnötigen Ballast
CQRS ist eines dieser Patterns, das überbeworben, überkompliziert und gelegentlich fälschlicherweise als Heilmittel gegen die langweilige CRUD-Alltagsarbeit dargestellt wird.
Diagrams as Code, ohne den Stress.
Mermaid ist ein textbasiertes Diagrammwerkzeug für Menschen, die Diagramme lieber schreiben, als Kästchen auf einer Leinwand zu verschieben. Es verwendet eine Markdown-ähnliche Syntax, um Flussdiagramme, Sequenzdiagramme, Klassendiagramme, Zustandsautomaten, Zeitachsen, Gantt-Diagramme, Entity-Relationship-Diagramme und mehr zu beschreiben.
Organisieren Sie Notizen nach Aktionen, nicht nach Themen.
Die Organisation von Notizen nach Themen klingt logisch, bis man Notizen zu PostgreSQL in fünf verschiedenen Ordnern hat und diejenige, die für das aktuelle Problem relevant ist, nicht findet.
Notizen, die sich verbessern, anstatt zu veralten.
Die meisten Engineering-Notizen werden einmal geschrieben und dann vergessen. Man fasst etwas während einer Debugging-Sitzung zusammen, kopiert es irgendwohin und findet es zwei Jahre später, ohne Kontext dafür zu haben, warum es damals wichtig war.
Verbreiten Sie wachsendes Wissen, nicht nur Beiträge.
Das vorherrschende Modell zur Veröffentlichung von Wissen im Internet hat sich seit den frühen 2000er Jahren kaum verändert: Etwas schreiben, polieren, veröffentlichen und dann weiterziehen.
Das richtige Modell für die richtige Aufgabe.
Das Ausführen eines Modells mit 70 Milliarden Parametern, um eine 200-Wörter-E-Mail zusammenzufassen, ist verschwenderisch. Das Ausführen eines 3-Milliarden-Parameter-Modells zur Überprüfung von Produktionscode ist fahrlässig. Die meisten Systeme liegen irgendwo dazwischen – und genau hier kommt das Modell-Routing ins Spiel.
Kontrollieren Sie das Risiko, nicht nur das Modell.
LLMs sind unvorhersehbar. Sie halluzinieren, lecken Daten, generieren schädliche Inhalte oder lehnen legitime Anfragen ab. Guardrails (Schutzmechanismen) begrenzen das Modellverhalten, ohne die Fähigkeiten einzuschränken.
Neue Beiträge zu Systemen, Infrastruktur und KI-Engineering.
