← Zurück zu den Beiträgen
Beitrag #003

Es gibt gerade eine Bewegung in der Softwareentwicklung, die nennt sich “Specs-to-Code”:

Es gibt gerade eine Bewegung in der Softwareentwicklung, die nennt sich “Specs-to-Code”:

Du schreibst nur noch in normaler Sprache auf, was die Software tun soll. Die KI baut den Code. Fehler? Kein Blick in den Code, einfach die Beschreibung präziser machen und nochmal generieren lassen. Klingt nach der Zukunft.

Die Idee dahinter:

  1. Du schreibst eine Spezifikation in normaler Sprache (z.B. “Die App soll Nutzer registrieren können, Passwörter mindestens 8 Zeichen …”)
  2. Die KI “kompiliert” die Spec in eine echte Anwendung
  3. Bei Fehlern: nicht den Code anfassen, sondern die Spec präzisieren und neu generieren
  4. Den Code siehst du im Idealfall nie wieder, die Spec ist das einzige Quellmaterial

Der Vergleich: Früher Assembler, dann C, dann Python. Jedes Mal eine Abstraktionsebene höher. Die nächste Ebene soll natürliche Sprache sein – Code wird zum “Bytecode”, den nur die Maschine sieht.

Aber die Idee scheitert, wenn man der KI eine Beschreibung hinwirft und sie irgendwas generieren lässt. Damit es funktioniert, braucht es:

  1. Geteiltes Verständnis vor dem ersten Prompt. Edge Cases, Trade-offs, Architekturentscheidungen müssen klar sein. Tools wie GitHub Spec Kit (https://lnkd.in/dBf6EX59) erzwingen die Phasen /specify → /plan → /tasks → /implement
  2. Architektur-Leitplanken in der Spec. Welche Module? Welche Schnittstellen? Welche Abhängigkeiten sind tabu? Ohne das wird jeder Durchlauf eine andere Architektur.
  3. Kleine Iterationen. Feature für Feature mit Tests als Akzeptanzkriterium. So bleibt der Mensch im Loop.
  4. Gemeinsame Fachsprache. Spec, Code und Stakeholder müssen dieselben Begriffe verwenden (Domain-Driven Design). Sonst übersetzt die KI jedes Mal anders.
  5. Reviews durch erfahrene Entwickler. Nicht blind weiterklicken. Wer Architektur versteht, sieht früh, wenn es schief läuft.

Kurz: Spec-Driven Development funktioniert – aber nur mit einem Senior als Architekt im Hintergrund. Denn LLMs priorisieren funktionale Korrektheit, nicht Architektur und Sicherheit (https://lnkd.in/dpcMvPez).

Je mehr Code die KI produziert, desto wichtiger werden die alten Tugenden:

👉 Anforderungen ausdiskutieren statt erraten lassen. 👉 Eine gemeinsame Fachsprache für Code, KI und Stakeholder. 👉 Kleine, überprüfbare Schritte mit echten Tests – nicht 800 Zeilen am Stück generieren und hoffen. 👉 Tiefe Module mit klaren Schnittstellen. Innen darf die KI werkeln, außen behält der Mensch die Kontrolle.

Die KI ist ein extrem schneller Junior. Ohne Senior-Aufsicht baut sie dir in zwei Tagen >10.000 LOC und technische Schulden für Wochen. “Code ist billig” stimmt nur halb – wer ihn aufräumen muss, weiß, wie teuer billiger Code wird.