Warum aSPARK
Was ein KI-Coding-Assistent nicht leistet, was aSPARK stattdessen tut — und was es ausdrücklich nicht sein will.
KI schreibt Code schneller, als irgendjemand ihn prüft.
Generieren ist billig geworden. Knapp geworden ist alles davor und danach: eine Idee, die jemand hinterfragt hat, ein Plan, der hält, ein Review, das jemand wirklich gemacht hat, und der Beweis, dass das Ding tatsächlich funktioniert.
Spec nach dem Code
Die Idee geht direkt in die Implementierung. Was unklar war, fällt erst im Review auf — oder in Produktion. Niemand hat gefragt, was „wöchentlich“ für einen Nutzer in einer anderen Zeitzone heißt.
Scope Creep aus Hilfsbereitschaft
Der Assistent baut mit, was nicht bestellt war: ein Refactoring hier, eine Abstraktion dort. Ohne Plan als Zaun ist jeder Task offen nach oben.
Review als Stempel
Sie reviewen Ihren eigenen generierten Code, abends, im Diff-Viewer. Findings werden nirgends festgehalten, Fixes nirgends gegengeprüft.
Grün heißt nicht: funktioniert
Tests laufen durch, aber niemand hat die App geöffnet und geklickt. Der Fehler, der auf Mobil das Diagramm nie lädt, steht in keinem Test.
Keine Spur
Eine Woche später weiß niemand mehr, warum eine Entscheidung so fiel. Der Chat-Verlauf ist weg, im Repo steht nur der Code.
Einzeln kleine Abkürzungen. Zusammen ein Prozess, der nur noch aus Bauen besteht.
aSPARK stellt die vier fehlenden Phasen um den Code zurück — mit Gates, die Sie freigeben, und einer Spur, die im Repository bleibt.
Ein Team im Plugin — nicht ein weiterer Assistent.
| Kategorie | Optimiert für | Es fehlt |
|---|---|---|
| KI-Coding-Assistenten Copilots, Chat im Editor |
Durchsatz beim Schreiben von Code | Jemand, der die Idee hinterfragt, den Plan fixiert, den Diff prüft und die App durchklickt |
| Ticket-Tools & Prozess-Suiten | Planung, Status, Reporting | Die Regeln dort, wo der Code entsteht — im Agenten selbst, an jedem Übergang |
| aSPARK | Die ganze Lieferung, nicht nur das Tippen: Specify · Plan · Act · Review · Keep — jeder Übergang ein Gate, jedes Gate Ihre Entscheidung | — ein Plugin, kein Dienst, kein Tracker |
Konsequenz: aSPARK ersetzt nie Git, CI/CD oder Ihren Issue-Tracker. Es ist Markdown im Plugin und Markdown in .spark/ — alles, was das Team weiß und entscheidet, steht in Dateien, die Sie lesen, diffen und committen.
Fünf Versprechen — jedes mit dem Mechanismus dahinter.
Bewusst als prüfbare Behauptungen formuliert. Der Beweis ist nicht diese Seite, sondern der .spark/-Ordner Ihres eigenen Projekts.
Weniger Fehlbauten
Der Product Owner hinterfragt die Idee und läuft eine Clarify-Runde über Grenzen, Daten, Randfälle und UX-Zustände, bevor eine Zeile Code entsteht.
Kein Scope Creep
Der Engineering Manager schneidet Tasks, jeder auf eine Story gemappt. Der Developer baut den Plan — und nichts sonst.
Bugs, die jemand gesucht hat
Ein Reviewer liest den Diff mit Staff-Engineer-Blick, dann klickt ein QA Tester die App im echten Browser durch — Akzeptanzkriterium für Akzeptanzkriterium.
Nachvollziehbarkeit als Nebenprodukt
US-, AC- und NFR-IDs laufen von der Spec über Plan und Review bis in den QA-Bericht. Der Trail entsteht beim Bauen, nicht beim Rekonstruieren.
Ehrliche Reife
Was geprüft wurde, steht als bestanden da. Was nicht geprüft werden konnte, steht als teilweise oder unbewiesen da — nie als stillschweigend grün.
Non-Goals halten aSPARK klein
Kein SCM. Keine CI/CD-Engine. Kein Issue-Tracker. Kein eigenes Modell, kein Dienst, kein Konto. Und kein Zwang zu Erweiterungen — Core allein ist vollständig.
Überzeugt? Dann fangen wir an.
Zwei Befehle in einer claude-Sitzung, Neustart, /spark. Kein Dienst, kein Konto, keine Datenbank — Core läuft in Ihrem Repository. Alles liegt offen auf GitHub.