Öffnet in einem neuen Tab

Bricks Native AI im Visier

Lange war KI in Bricks Builder Sache von Drittanbietern. Mit Version 2.4 ändert sich das: Bricks 2.4 erschien am 16. September 2026 und bringt KI-gestützte Seitenbearbeitung direkt in den Builder. Wir haben uns die neue Schnittstelle genauer angesehen und sie gleich produktiv genutzt. Auch dieser Beitrag wurde als Entwurf von einem KI-Agenten über die MCP-Schnittstelle von orgabor.com angelegt.

Was Bricks unter „Native AI“ versteht

Bricks liefert kein eigenes Chatfenster und kein eigenes Sprachmodell. Stattdessen öffnet sich der Builder für externe KI-Werkzeuge: Die sogenannten Abilities sind Aktionen, die über die WordPress Abilities API registriert werden und die ein KI-Agent über einen MCP-kompatiblen Client ausführen kann. MCP, das Model Context Protocol, ist der Standard, über den Assistenten wie Claude, Codex oder Copilot mit anderer Software sprechen.

Der Funktionsumfang ist beachtlich. Die Abilities decken Seiten, Elemente, Templates, Komponenten, globale Klassen, Variablen, Farbpaletten, Queries, Navigationsmenüs, das WooCommerce-Setup sowie Import und Export ab. Zudem können Agenten HTML und CSS in bearbeitbare Bricks-Inhalte umwandeln und gezielte Änderungen an bestehenden Seiten vornehmen.

Ergänzend gibt es Bricks Skills. Das sind optionale Begleitanleitungen für KI-Clients, die Skills oder wiederverwendbare Projektvorgaben unterstützen. Neue Berechtigungen oder zusätzliche Aktionen fügen sie nicht hinzu.

Einrichtung in wenigen Schritten

Zentrale Anlaufstelle ist der neue Admin-Bereich unter Bricks → AI. Er enthält die MCP- und Ability-Konfiguration, Steuerungen für jede einzelne Ability, Anleitungen für die Client-Einrichtung sowie Verbindungs- und Statusprüfungen. Voraussetzung ist die Abilities API von WordPress. Fehlt sie, empfiehlt Bricks WordPress 6.9 oder neuer. Für die Anbindung eines Clients wird der WordPress MCP Adapter installiert. Danach zeigt Bricks die Endpoint-URL an, die meist auf /wp-json/mcp/mcp-adapter-default-server endet.

Unser Praxistest auf orgabor.com

Zuerst haben wir den Designkontext der Website ausgelesen. In einem einzigen Aufruf lieferte die Schnittstelle alle 74 globalen Klassen, die 22 Variablen samt fluider Typografie-Skala, die Farbpalette, die Komponenten und die Breakpoints. Nebenbei fiel dabei eine echte Unstimmigkeit auf: Unsere Breakpoint-Variablen (860 und 1150 px) passen nicht zu den in Bricks definierten Breakpoints. Ein schöner Beleg dafür, dass ein Agent mit Lesezugriff auch als Prüfwerkzeug taugt.

Anschließend sollte der Agent diesen Beitrag anlegen. Der erste Versuch scheiterte mit einer klaren Fehlermeldung: Bricks war für den Beitragstyp „Beiträge“ nicht aktiviert, erlaubt waren nur Seiten und Templates. Der Agent hat die Einstellung nicht eigenmächtig geändert, sondern den Weg über die Bricks-Einstellungen beschrieben. Nach der manuellen Freigabe klappte das Anlegen im ersten Anlauf. Genau so sollte sich ein Werkzeug mit Schreibzugriff verhalten.

Stärken und Grenzen

Erste unabhängige Tests zeichnen ein gemischtes Bild. Man sollte dabei wissen, dass der Anbieter Bricksfusion selbst ein konkurrierendes KI-Produkt entwickelt und das auch offenlegt. In seinem Test mit der Beta erzeugte Claude eine brauchbare Hero-Sektion mit sauberer Struktur und korrektem responsivem Verhalten. Das Designsystem der Website ignorierte der Agent jedoch vollständig: Farben waren fest codiert, Buttons ohne Links. Die verwendeten Farben entsprachen der Standardpalette von Tailwind, eine CSS-Variable kam im gesamten Ergebnis nicht vor.

Unsere Erfahrung legt nahe, dass das weniger an Bricks liegt als am Arbeitsablauf. Die Schnittstelle stellt Klassen und Variablen ausdrücklich bereit. Wer den Agenten anweist, zuerst den Designkontext zu lesen, verschafft ihm das nötige Gedächtnis. Zudem wurde seit der Beta nachgebessert: Mit Beta 3 benötigen Agenten für Designsysteme, Seitenimporte und gezielte Änderungen weniger Tool-Aufrufe, und die HTML/CSS-Konvertierung arbeitet genauer.

Sicherheit: mit Bedacht freischalten

Ein KI-Agent mit Schreibrechten ist ein mächtiges Werkzeug. Bricks setzt deshalb auf restriktive Voreinstellungen. Für gemeinsam genutzte lokale oder Staging-Umgebungen empfiehlt Bricks einen eigenen WordPress-Benutzer für den KI-Client, der nur die tatsächlich benötigten Rechte erhält. Die optionale PHP-Ausführung bleibt standardmäßig gesperrt. Sie wird erst über die Konstante BRICKS_ENABLE_PHP_ABILITIES aktiviert und sollte laut Bricks nur in vertrauenswürdigen Entwicklungs- oder Staging-Umgebungen genutzt werden. Außerdem gilt: Bricks bezeichnet die KI-Abilities in Version 2.4 selbst noch als experimentell.

Fazit

Bricks geht bei der KI einen offenen Weg. Statt einen eigenen Assistenten einzubauen, macht es den Builder für jeden MCP-fähigen Agenten zugänglich. Das Ergebnis überzeugt, wenn man es richtig einsetzt: Der Agent liest zuerst das Designsystem, arbeitet mit eigenem, eingeschränktem Benutzer und überlässt kritische Einstellungen dem Menschen. Für Agenturen und Freelancer, die mit Bricks arbeiten, lohnt sich ein Test auf einer Staging-Umgebung schon jetzt.

Quellen: Bricks 2.4 Changelog, Bricks Academy: AI Abilities and Skills, Bricks 2.4 Beta 3 Changelog, Bricksfusion: We Tested the Native AI in Bricks 2.4

Lass uns
reden.

Erzähl mir von deinem Projekt – unverbindlich, auf einen Kaffee (virtuell oder echt).

Termin vereinbarenÜber Whatsapp kotaktieren
Das könnte Sie auch interessieren: