CabloyJS: TypeScript-Framework erweitert seinen Fokus auf AI-Spec-Driven Development
CabloyJS positioniert das TypeScript-Fullstack-Framework für das KI-gestützte Entwickeln um. Statt nur per natural-language Code zu erzeugen, soll die Spezifikation selbst zur Schnittstelle zwischen Entwicklern und KI-Assistenten werden.
KI-Coding-Assistenten haben in den vergangenen zwei Jahren aus dem Thema "KI schreibt Code" ein.Mainstream-Gespräch gemacht. Von Cursors Tab-Vervollständigung über Claude Codes Agent-Modus bis hin zum radikaleren "Vibe Coding", bei dem man eine Idee in natürlicher Sprache beschreibt und die KI daraus eine lauffähige Anwendung machen lässt.
Die eigentliche Schwierigkeit zeigt sich jedoch, wenn ein Vibe-Coding-Projekt über das "Hello World"-Stadium hinauswächst und zu einem echten Geschäftssystem wird.
KI "halluziniert". Sie verändert Module, die sie nicht anfassen sollte, nimmt Interfaces und Datenstrukturen an, die nicht existieren, und macht ein gesamtes Repository zu einem Chaos. Das Problem liegt nicht darin, dass Prompts nicht präzise genug sind, sondern in etwas Grundsätzlicherem: Der KI fehlen explizite, maschinenlesbare globale Constraints. Sie kann nur aus dem Kontext raten, wo die korrekten Grenzen liegen, und gerät diese Schätzung einmal außerhalb des Geschäftsbereichs, wachsen die Reparaturkosten exponentiell.
Die Reihe entscheidender Iterationen, die CabloyJS in der zweiten Jahreshälfte 2026 vorgenommen hat, ist eine systematische Antwort auf genau diesen Schmerzpunkt. Nicht mehr damit zufrieden, ein TypeScript-Fullstack-Framework zu sein, das Entwicklern beim schnelleren Aufsetzen von CRUD hilft, baut sich CabloyJS aktiv zu einem AI Spec-Driven Development (AI-SDD) Framework um, das eigens für AI Vibe Coding konzipiert ist.
Diese Entwicklung lässt sich in drei klare Handlungsstränge gliedern.
Den meisten AI-Coding-Assistenten liegt dieses Modell zugrunde: Man gibt eine Beschreibung, und die KI erzeugt basierend auf dem Kontext einen Codeblock. Dieses Modell funktioniert bei lokalen Aufgaben gut, doch innerhalb komplexer Systeme, die sich über mehrere Module sowie Frontend und Backend erstrecken, steht die KI vor einem fundamentalen Dilemma: Sie kennt ihre eigenen Grenzen nicht.
CabloyJS antwortet darauf mit einem Satz integrierter Claude Code Skills, der den Entwicklungs-Workflow in zwei strenge Phasen unterteilt.
Der erste Skill, cabloy-spec-generation, schreibt keinen Code. Seine Aufgabe ist es, explizite Spezifikationsdateien im Repository zu etablieren, sodass KI und Mensch dieselbe maßgebliche Quelle lesen. Ein typisches Ergebnis ist ein Satz sich gegenseitig referenzierender Spec-Dateien, die Produktanforderungen, technische Verträge, Lieferpläne, Abnahmekriterien und Architekturentscheidungs-Aufzeichnungen abdecken.
Der entscheidende Punkt ist nicht bloß, "einen Stapel Dokumente auf der Platte zu haben". Es geht um getrennte Autorität: Jede Datei besitzt eine Art von Fakten, und andere Dateien verweisen über stabile IDs darauf. Produktanforderungen schreiben keine Tabellennamen vor; technische Verträge definieren keine Geschäftsregeln neu; Lieferpläne schreiben die vorgelagerte Autorität nicht um. Die KI muss nie raten, "wo liegt die Grenze dieses Moduls?", sondern liest einfach die bereits vorhandene Spec.
Erst nachdem die Spezifikation steht, beginnt der zweite Skill, cabloy-spec-execution, den Code anzufassen. Er schaut sich nicht einen Prompt an und ändert willkürlich Dinge, sondern folgt einer strikten Ausführungskette:
Read specs → confirm boundaries → generate execution dossier → make source changes → run verification → save evidence → update progress Enter fullscreen mode Exit fullscreen mode Jeder Schritt hat ein Bestätigungstor. Die KI erweitert den Aufgabenumfang nicht automatisch, überspringt keine Verifizierungsschritte und behauptet nicht, "fertig" zu sein, wenn die Verifizierung fehlschlägt. Das Ergebnis besteht nicht nur aus einem Codeblock, sondern aus Quellcodeänderungen plus einem auditierbaren Evidence-Eintrag plus aktualisiertem Fortschrittsstatus.
Betrachtet man diese beiden Phasen zusammen, tut CabloyJS etwas bewusst Einfaches: Es verhindert, dass die KI direkt von einem vagen Prompt zum Schreiben von Code springt. Stattdessen schiebt es eine auf Specs basierende Mittelschicht ein, die der KI innerhalb dieser Schicht klare Verhaltensgrenzen gibt.
Was dies vom traditionellen "Spec-Driven Development" unterscheidet: Dort sind Specs Dokumente, die für Menschen geschrieben wurden. Bei CabloyJS sind Specs maschinenlesbare Autorität, die sowohl für die KI als auch für Menschen geschrieben wurde. Die KI konsultiert die Spec nicht bloß; ihr gesamter Ausführungsfluss wird von ihr angetrieben.
Wenn jede KI-Operation durch die Specs eingeschränkt ist und dieselbe Fortschrittsdatei aktualisiert, entsteht eine naheliegende Frage: Lassen sich aus diesen strukturierten Daten direkt agile Visualisierungscharts ableiten?
Die Antwort lautet ja. CabloyJS' Spec-System wird mit einer kleinen Toolchain ausgeliefert, die aus der WBS (Work Breakdown Structure) und den Fortschrittsdateien automatisch zwei Charts ableitet:
Diese Charts sind keine handgezeichneten Bilder, sondern direkte Visualisierungen der Spec-Daten. Wenn die KI eine WBS-Aufgabe abschließt und die Fortschrittsdatei aktualisiert, genügt ein erneutes Ausführen des Generierungsskripts, um die Charts automatisch zu aktualisieren.
Auf den ersten Blick wirkt das wie ein "cooles kleines Feature", doch im Kontext von AI-SDD ist seine Bedeutung eine völlig andere. Es bedeutet: Während die KI Geschäftscode schreibt, pflegt sie gleichzeitig automatisch die agile Fortschrittsvisualisierung des gesamten Projekts.
Man bittet die KI, ein CRM-System zu bauen. Die KI hilft nicht nur beim Schreiben des Kundenmanagement-CRUD, sondern aktualisiert zugleich die Aufgabenabhängigkeiten im Gantt-Chart und markiert abgeschlossene Arbeitseinheiten im Burndown. Die gesamte Entwicklungspipeline wird zu einem kontinuierlichen Fluss statt zu dem getrennten Zustand, in dem "die KI Code schreibt und Menschen manuell Trello/Jira aktualisieren".
Eine nüchterne Erwartung sollte man sich bewahren: Automatisch generierte Charts sind strukturelle Ansichten, keine Kalenderpläne oder Velocity-Prognosen. Sie zeigen, welche Lieferpakete existieren, in welcher ungefähren Reihenfolge sie stehen und welche bereits verifiziert wurden, aber sie sagen nicht, ob bis nächsten Mittwoch alles ausgeliefert werden kann. Das ist Absicht. Die KI sollte nicht für Kalenderzusagen verantwortlich gemacht werden, solange sie kein echtes Geschäftsverständnis besitzt. Bis dahin ist es die pragmatischere Wahl, die Charts als "Echtzeit-Snapshots von Struktur und Zustand" zu behandeln.
Das Fundament von CabloyJS sind zwei unabhängig voneinander weiterentwickelte Engines: Vona für das Backend und Zova für das Frontend. Es handelt sich nicht um "einen Backend-Ordner und einen Frontend-Ordner innerhalb eines großen Projekts". Jede hat ihre eigenen IoC-Container, Bean-Systeme und eine eigene CLI. Verbunden sind sie über Build-Artefakte und eine bidirektionale Vertragsschleife.
Diese Architektur verleiht CabloyJS einen enormen natürlichen Vorteil bei AI-SDD: Backend-Wahrheit und Frontend-Wahrheit sind getrennt, sodass die KI nicht gleichzeitig wahllos auf beiden Seiten herumwirren kann.
Vonas Controller, DTOs und Zod-Schemas erzeugen über Decorator-Metadaten automatisch ein OpenAPI-Dokument. Dieses OpenAPI-Dokument ist die einzige maßgebliche Quelle für die Generierung des Frontend-SDKs. Wird ein Backend-Interface geändert, ist die korrekte Reihenfolge immer:
Change Vona's DTO/Controller/Zod → emit new OpenAPI → regenerate Zova's $api SDK and $apiSchema helper Enter fullscreen mode Exit fullscreen mode Die KI "erfindet" kein Backend-Interface im Frontend, weil sie weiß, dass die vertragliche Wahrheit auf der Vona-Seite liegt und das Frontend nur ein Konsument ist.
Umgekehrt sind Zovas Routes, Komponenten, Icons und Typdefinitionen die Frontend-Wahrheit. Nach dem Build fließen diese Metadaten über eine Rückwärtskette in Vonas Tooling zurück und geben dem Backend-Tooling perfekte IDE-Typhinweise. Auch hier wird die korrekte Reihenfolge erzwungen:
Change Zova's routes/components → build Zova (emit rest artifacts) → run deps:vona to sync into Vona Enter fullscreen mode Exit fullscreen mode Das Repository selbst verdrahtet ein contract-loop-gate in die Git-Hooks, das beim Commit automatisch prüft, ob diese Kette gebrochen wurde. Das bedeutet: Der "bidirektionale Vertrag" ist keine Dokumentationsfloskel, sondern ein Engineering-Schutznetz.
Wenn die KI weiß, dass die Backend-Wahrheit in Vona und die Frontend-Wahrheit in Zova liegt und dass ihre Synchronisation explizite Befehle und Schutzmechanismen hat, fügt sie nicht freiwillig auf beiden Seiten Felder hinzu, rät keine Interface-Namen und kopiert keine Schema-Definitionen. Die KI muss nur drei Fragen beantworten:
Alle drei Antworten sind vom Framework definiert. Die KI muss nicht raten.
Eine weitere wichtige Änderung im Jahr 2026 ist, dass CabloyJS' Open-Source-Editionen formell in zwei V5+-Architektur-MIT-Baselines aufgeteilt wurden.
Diese Aufteilung selbst ist eine Erweiterung der AI-SDD-Philosophie: Zuerst wählt man eine Baseline, die zum eigenen geschäftlichen Ausgangspunkt passt, und lässt dann die KI begrenzte Inkremente innerhalb dieser Grenze liefern, statt von einem leeren Projekt aus zu beginnen und die KI alles von Grund auf erraten zu lassen.
CabloyJS ist nicht mehr nur ein TypeScript-Fullstack-Framework, das hilft, Frontend und Backend schneller aufzusetzen. Es ist ein Arbeitssystem, das AI Vibe Coding nachvollziehbar, begrenzt und verifizierbar macht:
Sein Anspruch ist klar: das beste Fullstack-Vibe-Coding-Framework im KI-Zeitalter zu sein, nicht durch "draufgesetztes Prompt-Engineering", sondern durch strikte Typisierung, repository-interne Spezifikationsautorität und Engineering-Schutzmechanismen, die die bisher unkontrollierte "blinde KI-Codegenerierung" in eine industrielle Pipeline verwandeln, die spezifikationsgetrieben, evidenzbasiert und automatisch berichtsfähig ist.
Wenn man diesen Workflow selbst erleben möchte, beginnt man am besten mit dem öffentlichen Scaffolding:
npm create cabloy npm run dev npm run dev:zova:admin npm run dev:zova:web Wähle anschließend eine klar abgegrenzte Anforderung, etwa „füge einen Kategorie-Filter zu Produkten hinzu“, und durchlaufe den vollständigen Ablauf von cabloy-spec-generation bis cabloy-spec-execution. Du wirst feststellen, dass die Qualität des Verhaltens spürbar ansteigt, wenn die KI weder Grenzen noch Verträge oder die Definition von „fertig“ erraten muss.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
AI coding assistants have turned "having AI write code" into a mainstream conversation over the past two years. From Cursor's tab completion, to Claude Code's agent mode, to the more radical "Vibe Coding" — describing an idea in natural language and letting AI turn it into a running app.
But the real difficulty appears when a Vibe Coding project outgrows "hello world" and becomes an actual business system.
AI "hallucinates." It modifies modules you didn't ask it to touch, assumes interfaces and data structures that don't exist, and turns an entire repository into a mess. This is not about prompts being imprecise enough — it is a deeper problem: AI lacks explicit, machine-readable global constraints. It can only guess from context what the correct boundaries are, and once that guess drifts outside the business scope, the cost of repair grows exponentially.
The series of pivotal iterations CabloyJS made in the second half of 2026 is a systematic answer to exactly this pain point. No longer satisfied with being a TypeScript fullstack framework that helps developers scaffolding CRUD faster, CabloyJS has been proactively restructuring itself into an AI Spec-Driven Development (AI-SDD) framework purpose-built for AI Vibe Coding.
This evolution can be organized into three clear threads.
Most AI coding assistants follow this model: give a description, AI generates a chunk of code based on context. This model works well for local tasks, but inside complex systems that span multiple modules and both frontend and backend, AI faces a fundamental dilemma — it does not know where its boundaries are.
CabloyJS's answer is a set of built-in Claude Code Skills that splits the development workflow into two strict phases.
The first Skill, cabloy-spec-generation, does not write code. Its job is to establish explicit specification files inside the repository so that both AI and humans read the same source of truth. A typical output is a set of mutually referencing Spec files covering product requirements, technical contracts, delivery plans, acceptance criteria, and architecture decision records.
The key is not merely "having a pile of documents on disk." It is separated authority: each file owns one kind of fact, and other files refer to it through stable IDs. Product requirements do not prescribe table names; technical contracts do not redefine business rules; delivery plans do not rewrite upstream authority. AI never has to guess "what is the boundary of this module?" — it goes and reads the Spec that is already there.
Only after the specification is in place does the second Skill, cabloy-spec-execution, start touching code. It does not "look at a prompt and change things randomly." It follows a strict execution chain:
Read specs → confirm boundaries → generate execution dossier → make source changes → run verification → save evidence → update progress Enter fullscreen mode Exit fullscreen mode Every step has a confirmation gate. AI does not automatically expand the task scope, does not skip verification steps, and does not pretend "it's done" when verification fails. The final deliverable is not just a chunk of code — it is source changes plus an auditable Evidence record plus updated progress state.
Putting these two phases together, CabloyJS is doing something deliberately simple: it prevents AI from jumping straight from a vague prompt to writing code. Instead, it inserts a Spec-based middle layer that gives AI clear behavioral boundaries within that layer.
What distinguishes this from traditional "spec-driven development" is that in the traditional model, specs are documents written for humans. In CabloyJS, specs are machine-readable authority written for both AI and humans. AI does not merely "consult" the Spec — its entire execution flow is driven by it.
When every AI operation is constrained by the Specs and updating the same progress file, a natural question emerges: can we directly derive agile visualization charts from this structured data?
The answer is yes. CabloyJS's Spec system ships with a small toolchain that automatically derives two charts from the WBS (Work Breakdown Structure) and progress files:
These charts are not hand-drawn pictures — they are direct visualizations of the Spec data. When AI finishes a WBS task and updates the progress file, running the generation script once more updates the charts automatically.
On the surface this looks like a "cool small feature," but in the AI-SDD context its significance is completely different. It means: while AI is writing business code, it is also automatically maintaining the agile progress visualization of the entire project.
You ask AI to build a CRM system. AI is not just helping you write the customer-management CRUD — it is simultaneously updating task dependencies on the Gantt chart and marking completed work items on the Burndown. The entire development pipeline becomes one continuous flow instead of the split state where "AI writes code, humans manually update Trello/Jira."
One sober expectation is worth keeping: auto-generated charts are structural views, not calendar schedules or velocity forecasts. They tell you what delivery packages exist, their approximate ordering, and which ones have been verified — but they will not tell you whether everything can ship by next Wednesday. That is intentional. AI should not be held responsible for calendar commitments until it truly has business understanding. Until then, treating the charts as "real-time snapshots of structure and state" is the more pragmatic choice.
The foundation of CabloyJS is two independently evolving engines: Vona for the backend and Zova for the frontend. They are not "a backend folder and a frontend folder inside one big project." Each has its own IoC containers, Bean systems, and CLI. They mesh together through build artifacts and a bidirectional contract loop.
This architecture gives CabloyJS a tremendous natural advantage in AI-SDD: backend truth and frontend truth are separate, so AI cannot randomly mess with both sides at once.
Vona's Controllers, DTOs, and Zod schemas automatically produce an OpenAPI document through decorator metadata. That OpenAPI document is the single source of truth for frontend SDK generation. When changing a backend interface, the correct order is always:
Change Vona's DTO/Controller/Zod → emit new OpenAPI → regenerate Zova's $api SDK and $apiSchema helper Enter fullscreen mode Exit fullscreen mode AI will not "invent" a backend interface on the frontend, because it knows the contract truth lives on the Vona side — the frontend is only a consumer.
Conversely, Zova's routes, components, icons, and type definitions are the frontend truth. After building, this metadata flows back into Vona's tooling through a reverse chain, giving the backend tooling perfect IDE type hints. The correct order here is likewise enforced:
Change Zova's routes/components → build Zova (emit rest artifacts) → run deps:vona to sync into Vona Enter fullscreen mode Exit fullscreen mode The repository itself wires a contract-loop-gate into git hooks, which automatically checks whether this chain has been broken at commit time. That means "bidirectional contract" is not a documentation slogan — it is an engineering guardrail.
When AI knows that backend truth lives in Vona and frontend truth lives in Zova, and that syncing them has explicit commands and guardrails, it will not freely add fields on both sides, guess interface names, or copy-paste schema definitions. AI only needs to answer three questions:
All three answers are defined by the framework. AI does not have to guess.
Another important change in 2026 is that CabloyJS's open-source editions have been formally split into two V5+ architecture MIT baselines.
This split itself is an extension of the AI-SDD philosophy: choose a baseline that fits your business starting point first, then let AI deliver bounded increments within that boundary — instead of starting from an empty project and asking AI to guess everything from scratch.
It is no longer just a TypeScript fullstack framework that helps you scaffolding frontend and backend faster. It is a working system that makes AI Vibe Coding traceable, bounded, and verifiable:
Its ambition is clear: be the best fullstack Vibe Coding framework in the AI era — not by "layering prompt engineering on top," but by using strict typing, repository-internal specification authority, and engineering guardrails to turn the previously uncontrolled "blind AI code generation" into an industrial pipeline that is specification-driven, evidence-backed, and automatically reportable.
If you want to feel this workflow yourself, begin from the public scaffolding:
npm create cabloy npm run dev npm run dev:zova:admin npm run dev:zova:web Enter fullscreen mode Exit fullscreen mode Then pick a clearly bounded requirement — say, "add a category filter to products" — and run through the full cabloy-spec-generation → cabloy-spec-execution flow. You'll notice that when AI no longer has to guess boundaries, contracts, or the definition of done, its behavior quality jumps up visibly.