Branchen-Fachwissen SHK, Elektro, Maler
Sichtbarkeit Blog, Google-Profil, Audit
Beispiele aus dem Haus KI-Anwendungen, die wir selbst betreiben
Alle KI-Lösungen → Alles einzeln gebaut, nichts von der Stange.
Computer & Laptops PC, Mac, Kaufberatung
Mobilgeräte Smartphone, TV, Fotos
Peripherie & Netzwerk Drucker, WLAN, NAS
Smart Home & IoT Automation, PV, Homeoffice
Alle Hardware-Leistungen → Alles einzeln gebaut, nichts von der Stange.
Alle Unternehmens-Leistungen → Alles einzeln gebaut, nichts von der Stange.
linkx© Module II Karte, Wache, Wahl, .
Alle Submarken → Alles einzeln gebaut, nichts von der Stange.

KI & Softwareentwicklung

KI & SoftwareVeröffentlicht: · 11 Min. Lesezeit

intent.md: So wird aus KI-Code verlässliche Software

Drei Dokumente im Ablauf Von links nach rechts: intent.md für die Absicht, spec.md für das vereinbarte Verhalten, plan.md für die Umsetzung. intent.md spec.md plan.md Was wollen wirerreichen? Wie soll es sichverhalten? Wie setzen wires um?
Drei Dokumente, drei Aufgaben: Absicht, vereinbartes Verhalten, Umsetzung.

Das nehmen Sie mit

  • Was eine intent.md festhält: Problem, Betroffene, Ziel, Grenzen und überprüfbare Erfolgskriterien.
  • Wie daraus Anforderungen, Umsetzung und Prüfungen entstehen — und an welchen Stellen ein Mensch entscheidet.
  • Eine Vorlage zum Kopieren, die Sie noch heute an Ihrem eigenen Vorhaben ausprobieren können.

Eine KI baut ein Formular. Es sieht gut aus, funktioniert auf dem Smartphone und verschickt eine E-Mail. Nach der ersten echten Anfrage fällt auf: Es fehlt die Adresse. Nach der zweiten: Ein Doppelklick erzeugt zwei Einträge. Und beim ersten Versandfehler weiß niemand, ob die Anfrage überhaupt angekommen ist.

Der Code war schnell fertig. Die eigentliche Aufgabe war noch nicht ausreichend geklärt.

Genau hier wird eine unscheinbare Textdatei interessant: intent.md. Sie hält fest, welches Problem gelöst werden soll, für wen und unter welchen Bedingungen. Damit entsteht eine gemeinsame Grundlage für Menschen und KI-Agenten.

Anthropic beschreibt diesen Ansatz im AI-Native SDLC Playbook, veröffentlicht am 21. August 2026. Die Idee dahinter: KI soll über den gesamten Entwicklungsprozess sinnvoll eingebunden werden — von der ersten Anforderung bis zur Wartung.

Was das im Alltag bedeutet, lässt sich an einem kleinen Softwareprojekt zeigen.

Warum schneller Code ein Projekt noch nicht schnell macht

Softwareentwicklung besteht aus mehr als Programmieren. Jemand muss das Problem verstehen, Anforderungen festlegen, Entscheidungen treffen, das Ergebnis prüfen und die Anwendung betreiben.

Wird das Schreiben des Codes schneller, können andere Arbeitsschritte stärker ins Gewicht fallen:

  • Eine wichtige Rückfrage bleibt unbeantwortet.
  • Zwei Beteiligte verstehen unter derselben Funktion etwas Unterschiedliches.
  • Die Umsetzung wartet auf eine fachliche Prüfung.
  • Ein Fehler taucht erst im echten Betrieb auf.
  • Nach einem Wechsel des Entwicklers oder KI-Agenten fehlt der Zusammenhang.

Ein besseres Modell kann bei vielen Aufgaben helfen. Ungeklärte Anforderungen bleiben trotzdem ungeklärt. Anthropic beschreibt genau das als Kern des Problems: Der Engpass wandert von der Umsetzung zu den Schritten davor und danach, weil diese weiterhin im menschlichen Takt laufen.

Für Auftraggeber bedeutet das: Die entscheidende Frage ist, ob am Ende eine Lösung entsteht, die im eigenen Betrieb zuverlässig funktioniert. Die Menge des erzeugten Codes sagt darüber wenig aus.

Was ist eine intent.md?

Eine intent.md ist eine Markdown-Datei, die die Absicht hinter einer Änderung beschreibt. Markdown ist ein einfaches Textformat mit Überschriften, Absätzen und Listen — lesbar für Menschen und maschinell auswertbar.

Im Mittelpunkt stehen fünf Fragen:

  1. Welches Problem besteht?
  2. Wer ist davon betroffen?
  3. Was soll nach der Änderung besser funktionieren?
  4. Welche Bedingungen und Grenzen gelten?
  5. Woran erkennen wir ein brauchbares Ergebnis?

Im Anthropic-Playbook wird daraus zunächst eine kurze Vorstufe zur Spezifikation. Eine verantwortliche Person prüft und korrigiert den Inhalt, bevor er festgeschrieben wird und die weitere Ausarbeitung beginnt.

Die Datei bietet einen festen Bezugspunkt: Das wollten wir erreichen, aus diesen Gründen haben wir uns dafür entschieden.

Zur technischen Einordnung: intent.md ist eine vereinbarte Dokumentform in diesem Arbeitsablauf. Durch das bloße Anlegen startet keine automatische Entwicklung. Der KI-Agent muss das Dokument erhalten und den vorgesehenen Prozess ausführen.

Für dauerhafte Projektanweisungen dokumentiert Claude Code unter anderem CLAUDE.md. Darin stehen beispielsweise Arbeitsregeln, Befehle oder Hinweise zum Projektaufbau. Die intent.md beschreibt dagegen ein konkretes Vorhaben. Sie hat damit einen anderen Zweck. Dokumentation zu CLAUDE.md

Praxisbeispiel: Eine Terminanfrage für einen Handwerksbetrieb

Nehmen wir einen Handwerksbetrieb, den es so nicht gibt — das Beispiel ist für diesen Beitrag erfunden. Kunden melden sich per E-Mail oder über ein allgemeines Kontaktformular. Bei vielen Anfragen fehlen Angaben, die das Büro später nachfordern muss.

Der erste Wunsch lautet: „Wir brauchen eine Online-Terminbuchung." Das klingt eindeutig. Bei genauerem Hinsehen entstehen jedoch Fragen: Soll der Kunde wirklich einen verbindlichen Termin buchen? Oder soll er einen Terminwunsch abgeben, den das Büro anschließend bestätigt? Wie lange dauert ein Einsatz? Welche Mitarbeiter können welche Arbeiten übernehmen?

Erster Wunsch

„Wir brauchen eine Online-Terminbuchung."

Geklärte Aufgabe

„Kunden senden vollständige Terminanfragen. Das Büro prüft sie und bestätigt den Termin anschließend."

Eine frühe Entscheidung, die Funktionsumfang und Erwartungen verändert.

Diese Entscheidung verändert den Umfang erheblich. Ein Kalender mit automatischer Kapazitätsplanung wird zunächst überflüssig. Wichtig werden stattdessen vollständige Angaben, verständliche Rückmeldungen und eine zuverlässige Übergabe ans Büro.

Genau an dieser Stelle setzen wir an

Wir entwickeln Individualsoftware für einzelne Abläufe im Betrieb. Der erste Schritt ist immer derselbe: klären, was die Lösung können muss, bevor etwas gebaut wird.

So könnte die intent.md aussehen

Das folgende Muster ist unser eigenes Beispiel. Es ist keine offizielle Anthropic-Vorlage.

intent.md
# Vorhaben: Terminanfragen strukturiert erfassen

## Problem
Das Büro muss bei Kundenanfragen häufig Adresse,
Anliegen und Erreichbarkeit nachfordern.
Angaben verteilen sich auf mehrere Nachrichten.

## Betroffene
- Kunden, die einen Termin anfragen möchten
- Büromitarbeiter, die Anfragen bearbeiten

## Gewünschtes Ergebnis
Kunden übermitteln eine vollständige Terminanfrage.
Das Büro erhält die Angaben an einer zentralen Stelle
und kann anschließend einen Termin abstimmen.

## Umfang der ersten Version
- Name und mindestens eine Kontaktmöglichkeit
- Einsatzadresse
- Auswahl des Anliegens
- Freitext für ergänzende Angaben
- Terminwunsch ohne feste Zusage
- Bestätigung, dass die Anfrage eingegangen ist

## Abgrenzung
- Keine verbindliche Terminbuchung
- Keine automatische Einsatzplanung
- Keine Zahlung
- Kein Kundenkonto

## Rahmenbedingungen
- Auf Smartphones gut bedienbar
- Verständliche Feldbeschriftungen und Fehlermeldungen
- Bestehende Website und Gestaltung verwenden
- Nur für die Bearbeitung erforderliche Daten erheben

## Erfolgskriterien
- Gültige Anfragen werden zuverlässig gespeichert.
- Die Erfolgsanzeige erscheint erst nach der Speicherung.
- Fehlende Pflichtangaben werden verständlich erklärt.
- Ein wiederholter Versand derselben Anfrage erzeugt
  innerhalb des vorgesehenen Wiederholungsablaufs
  keinen zweiten Datensatz.
- Bei einem Benachrichtigungsfehler bleibt die Anfrage
  erhalten und ihr Bearbeitungsstatus nachvollziehbar.
- Kunden erkennen klar: Der Termin ist noch nicht bestätigt.

## Noch zu klären
- Wer bearbeitet neue Anfragen?
- Wo sieht das Büro den Eingang und Versandfehler?
- Welche Aufbewahrungsfrist gilt?
- Wer übernimmt die fachliche Abnahme?

Aus einem allgemeinen Wunsch ist eine überprüfbare Aufgabe geworden. Die offenen Fragen stehen sichtbar im Dokument und können gezielt beantwortet werden.

Drei Dokumente, drei unterschiedliche Aufgaben

Im vorgestellten Ablauf haben intent.md, spec.md und plan.md unterschiedliche Funktionen:

DokumentLeitfrageInhalt im Praxisbeispiel
intent.mdWas wollen wir erreichen und warum?Vollständige Terminanfragen, weniger Rückfragen, weiterhin manuelle Terminbestätigung
spec.mdWie soll sich die Lösung genau verhalten?Felder, Pflichtangaben, Abläufe, Fehlerfälle, Datenverarbeitung und Abnahmekriterien
plan.mdWie setzen wir das im vorhandenen Projekt um?Betroffene Dateien, Arbeitsschritte, technische Abhängigkeiten und Prüfungen

Die Absicht erklärt den Nutzen. Die Spezifikation beschreibt das vereinbarte Verhalten. Der Plan macht daraus umsetzbare Arbeit.

Bei einer kleinen Textkorrektur wäre diese Aufteilung unnötig aufwendig. Bei einer neuen Funktion mit Datenverarbeitung, mehreren Beteiligten oder Schnittstellen kann sie helfen, Entscheidungen nachvollziehbar festzuhalten. Der Umfang der Dokumentation sollte zur Aufgabe passen.

Wie KI über den ganzen Entwicklungsprozess helfen kann

SDLC steht für „Software Development Life Cycle", also den Lebenszyklus der Softwareentwicklung. Dazu gehören Planung, Entwurf, Umsetzung, Prüfung, Veröffentlichung und Wartung.

An unserem Beispiel wird deutlich, welche Aufgaben eine KI in diesen Phasen übernehmen kann.

01Das Problem durch gute Rückfragen klären

Die KI fragt nach dem heutigen Ablauf, fehlenden Informationen und Ausnahmen.

Beim Terminformular könnte sie nachfragen: „Darf der Kunde davon ausgehen, dass sein Wunschtermin reserviert ist?" Damit wird eine mögliche Fehlannahme sichtbar, bevor sie in der Oberfläche landet.

Die fachliche Entscheidung kommt weiterhin aus dem Betrieb. Eine KI kennt dessen tatsächliche Abläufe nur so weit, wie sie beschrieben oder aus zugänglichen Quellen nachvollziehbar werden.

02Anforderungen konkret ausarbeiten

Aus dem Ziel entstehen klare Regeln: Welche Felder sind Pflicht? Was passiert bei einer ungültigen E-Mail-Adresse? Was sieht der Kunde, wenn die Speicherung scheitert?

Die KI kann diese Fälle strukturieren und widersprüchliche Anforderungen markieren. Die zuständige Person prüft, ob die vorgeschlagene Lösung zum Arbeitsalltag passt.

03Die Umsetzung im bestehenden Projekt planen

Vor Änderungen untersucht der Agent, welche Funktionen bereits vorhanden sind. Vielleicht gibt es schon ein Formularsystem, einen Versanddienst oder eine Verwaltungsansicht.

Der Plan beschreibt die betroffenen Stellen und die Reihenfolge der Arbeiten. Er hält auch fest, welche bestehenden Funktionen durch die Änderung beeinträchtigt werden könnten. So lässt sich die technische Umsetzung beurteilen, bevor umfangreiche Änderungen entstehen.

04Das vereinbarte Verhalten prüfen

Beim Formular reicht es nicht, dass eine gültige Eingabe einmal funktioniert.

Zu prüfen sind auch fehlende Angaben, eine unterbrochene Verbindung, wiederholtes Absenden und Fehler beim E-Mail-Versand. Dazu kommt die Bedienung auf kleinen Bildschirmen und mit der Tastatur.

Automatisierte Tests können diese Prüfungen unterstützen. Ihre Aussagekraft hängt davon ab, ob sie die tatsächlichen Anforderungen und relevante Fehlerfälle abdecken. Wenn ein Agent sowohl den Code als auch die Tests schreibt, können beide dieselbe falsche Annahme enthalten. Deshalb bleibt der Abgleich mit den vereinbarten Erfolgskriterien wichtig.

05Die Änderung kontrolliert veröffentlichen

Zur Veröffentlichung gehört die Prüfung, ob die Anwendung in ihrer tatsächlichen Umgebung funktioniert. Außerdem muss klar sein, wie eine fehlerhafte Änderung zurückgenommen werden kann.

Eine KI kann Änderungshinweise, Prüfberichte und technische Schritte vorbereiten. Welche Änderungen automatisch veröffentlicht werden dürfen und wo eine zusätzliche Prüfung nötig ist, legt der eingerichtete Arbeitsablauf fest.

06Den Betrieb beobachten und Verbesserungen vorbereiten

Nach der Veröffentlichung entstehen neue Informationen. Vielleicht häufen sich Versandfehler. Vielleicht brechen Nutzer an einem bestimmten Feld ab.

Mit entsprechend eingerichteter Überwachung kann ein Agent Hinweise untersuchen und eine mögliche Korrektur vorbereiten. Dafür braucht er passende Datenquellen, Werkzeuge und Berechtigungen. Im Playbook schließt sich damit der Kreis: Was die Überwachung findet, wird wieder als neue intent.md aufgeschrieben. Ob die vermutete Ursache stimmt und welche Änderung sinnvoll ist, muss weiterhin geprüft werden.

Warum das beim Wechsel zwischen KI-Agenten hilft

Wer mit KI entwickelt, kennt den Moment: Ein neuer Chat beginnt, ein anderer Agent übernimmt und wichtige Entscheidungen müssen erneut erklärt werden.

Ein gemeinsam gepflegter Dokumentationsstand kann diese Übergabe erleichtern. Der nächste Bearbeiter findet das Ziel, die vereinbarte Lösung und den aktuellen Plan im Projekt. Was das für die Praxis bedeutet, haben wir im Beitrag zu einem gemeinsamen Wissensordner für alle KI-Werkzeuge ausführlicher beschrieben.

Das funktioniert nur, wenn die Dokumente aktuell bleiben. Ein veralteter Plan kann genauso irreführen wie eine alte mündliche Absprache.

Deshalb sollten Änderungen am vereinbarten Verhalten und an der Umsetzung zusammen dokumentiert werden. Eine Versionsverwaltung wie Git macht nachvollziehbar, wann sich etwas geändert hat.

Auch bei mehreren KI-Agenten ist Arbeitsteilung eine bewusste Entscheidung. Unabhängige Aufgaben lassen sich eher parallel bearbeiten. Bei eng verbundenen Änderungen kann eine klare Reihenfolge einfacher sein.

Was ein solcher Ablauf nicht automatisch löst

Eine gute Aufgabenbeschreibung ist eine wichtige Grundlage. Sie ersetzt jedoch keine funktionierende technische Absicherung. Drei Punkte verdienen besondere Aufmerksamkeit:

Geschriebene Regeln brauchen eine passende technische Umsetzung

Der Satz „keine Produktivdaten verändern" in einem Dokument entzieht einem Werkzeug noch keine Schreibrechte. Berechtigungen und Arbeitsumgebung müssen zur vorgesehenen Aufgabe passen.

Prüfungen brauchen aussagekräftige Kriterien

Eine grüne Testanzeige bedeutet, dass die vorhandenen Tests bestanden wurden. Ob die Anwendung den Bedarf des Betriebs erfüllt, hängt auch davon ab, was diese Tests überhaupt prüfen.

Automatisierung braucht einen erkennbaren Fehlerweg

Wenn eine Benachrichtigung scheitert, muss jemand das erkennen und bearbeiten können. Ein stiller Fehler bleibt auch dann problematisch, wenn der normale Ablauf vollständig automatisiert ist.

Mit diesen Fragen wird aus einem überzeugenden Prototyp eine besser betreibbare Lösung.

So können Sie mit einer kleinen Aufgabe anfangen

Wählen Sie eine überschaubare Verbesserung: ein Formular, einen Datenexport oder eine wiederkehrende manuelle Übertragung.

Beschreiben Sie zunächst den heutigen Ablauf. Halten Sie fest, was künftig anders funktionieren soll und welche Ausnahmen vorkommen. Lassen Sie eine KI daraus einen ersten Entwurf erstellen und prüfen Sie ihn anschließend.

Dieser Arbeitsauftrag eignet sich für den Einstieg:

Helfen Sie mir, eine konkrete Softwareänderung fachlich zu klären. Fragen Sie zunächst nach dem heutigen Ablauf, den betroffenen Nutzern, dem gewünschten Ergebnis und wichtigen Fehlerfällen. Stellen Sie nur Rückfragen, die für den Umfang oder die Umsetzung relevant sind. Fassen Sie die Ergebnisse anschließend als intent.md zusammen. Trennen Sie bestätigte Anforderungen, Annahmen und offene Fragen. Formulieren Sie überprüfbare Erfolgskriterien. Beginnen Sie noch nicht mit der Implementierung.

Werden dabei wichtige Unklarheiten sichtbar, hat sich dieser Schritt bereits gelohnt. Sie lassen sich jetzt klären, bevor sie in Code und Arbeitsabläufe eingebaut werden.

Was Unternehmen davon haben

Der praktische Nutzen liegt in einer klareren Zusammenarbeit.

Auftraggeber können nachvollziehen, was vereinbart wurde. Entwickler erhalten eine konkrete Grundlage. Prüfungen orientieren sich am gewünschten Verhalten. Spätere Änderungen lassen sich besser einordnen.

Ob dadurch Zeit und Kosten sinken, sollte am eigenen Projekt gemessen werden. Interessant sind beispielsweise die Dauer bis zur nutzbaren Veröffentlichung, der Umfang der Nacharbeit und Fehler im laufenden Betrieb.

Eine KI kann viele Arbeitsschritte beschleunigen. Ein gut organisierter Prozess hilft dabei, diesen Fortschritt in brauchbare Software zu übersetzen.

Häufige Fragen zu intent.md

Ist intent.md eine neue Programmiersprache?

Nein. Es handelt sich um eine Textdatei im Markdown-Format. Sie beschreibt das Ziel einer Softwareänderung und die dazugehörigen Rahmenbedingungen.

Muss die Datei genau intent.md heißen?

Für ein Team ist eine einheitliche Benennung hilfreich. Entscheidend ist, dass Menschen und Agenten das richtige Dokument finden und verwenden. Ein Dateiname allein stellt das nicht sicher.

Funktioniert die Idee auch mit anderen KI-Werkzeugen?

Ja. Die Dokumente sind gewöhnliche Textdateien und können unterschiedlichen Werkzeugen als Kontext bereitgestellt werden. Automatisches Laden, Regeln und weitere Arbeitsschritte müssen passend zum jeweiligen Werkzeug eingerichtet werden.

Braucht jede kleine Änderung drei Dokumente?

Nein. Der Aufwand sollte zur Aufgabe passen. Bei größeren oder wiederkehrenden Änderungen hilft eine ausführlichere Beschreibung. Für eine kleine, klar begrenzte Korrektur kann ein kurzer Arbeitsauftrag ausreichen.

Ersetzt der Ablauf einen Entwickler?

Die technische Verantwortung bleibt bestehen. Anforderungen müssen verstanden, Änderungen geprüft und Anwendungen betrieben werden. KI kann dabei viele Aufgaben übernehmen oder vorbereiten.

Kann eine KI damit Software selbstständig warten?

Eine eingerichtete Umgebung kann Agenten bei Fehlersuche und Korrekturvorschlägen unterstützen. Dafür sind Überwachung, Zugriffe, geeignete Werkzeuge und klare Zuständigkeiten erforderlich. Die intent.md allein richtet diese Fähigkeiten nicht ein.

Welche wiederkehrende Aufgabe würden Sie gern vereinfachen?

Vielleicht fehlen in Kundenanfragen regelmäßig Angaben. Vielleicht übertragen Sie jede Woche dieselben Daten zwischen zwei Programmen. Oder eine vorhandene Software passt an einer entscheidenden Stelle nicht zu Ihrem Ablauf.

Wir entwickeln individuelle Software und KI-Automatisierung für genau solche Aufgaben. Ausgangspunkt ist eine konkrete Beschreibung: Was funktioniert heute nicht gut, und wie soll der Ablauf künftig aussehen?

Quellen

Alle Angaben geprüft am 12.09.2026. Die technische Einordnung wurde gegen die verlinkten Anthropic-Quellen abgeglichen; das Handwerksbeispiel und die Vorlage sind eigene Beispiele für diesen Beitrag. Quellentexte in eigenen Worten zusammengefasst; maßgeblich ist das jeweils aktuelle Dokument der Quelle.

Weiterlesen

Ein Ablauf, der jede Woche Zeit frisst?

Beschreiben Sie uns, was heute nicht gut funktioniert. Wir klären gemeinsam, welche Lösung dazu passt.

Projekt beschreiben →

Beschreiben Sie Ihr Anliegen

Schreiben Sie uns kurz, worum es geht. Wir prüfen die Anfrage und melden uns per E-Mail mit dem nächsten Schritt.

Cookie-EinwilligungTechnisch notwendige Cookies sind immer aktiv. Externe Inhalte wie Terminbuchung und Kartenmaterial sowie Google Analytics laden wir erst nach Ihrer Zustimmung. Mehr erfahren