💡 Ich habe mit Symfony in nur einer Stunde eine DSGVO-konforme KI-App erstellt.

der 2. April 2026

Heutzutage nutzen viele Entwickler KI zur Codegenerierung.

Die Frage, mit der wir uns hier befassen, lautet wie folgt:

👉 Wie verwandelt man eine Idee in ein ausführbares System?

Und das ist normal.

Weil wir gelernt haben:

  • Codierungsmerkmale
  • Funktionen schreiben
  • APIs verbinden

Aber nicht zu:

Eine Idee so strukturieren, dass sie umgesetzt werden kann

Bei Darkwood fangen wir nie mit dem Code an.

Wir beginnen mit einem viel grundlegenderen Schritt:

👉 die Begründung

In diesem Artikel werden wir uns Folgendes konkret ansehen:

  1. Wie man eine Idee in eine nutzbare Einheit umsetzt
  2. Wie man KI zur Umsetzung dieser Idee einsetzen kann
  3. So wenden Sie dies in einem realen Projekt an: SketchUp-Form

🧠 1. Eine Idee ist kein Code

Wenn Sie denken:

“Créer une application”

Ihre reflexartige Reaktion als Entwickler ist oft:

„Okay, ich werde eine API, eine Datenbank usw. programmieren.“

👉 Schlechte Ausgangslage.

Eine Idee ist noch nichts, was man umsetzen kann.

Das ist richtig:

👉 eine vage Absicht

💡 Das richtige mentale Modell

Wir bei Darkwood glauben Folgendes:

👉 Eine Idee = eine Aufgabe

Nicht mehr, nicht weniger.

Beispiel

“Créer une application”

wird zu:

Task: create_app

Es mag trivial erscheinen.

Dies ist jedoch eine bedeutende Veränderung:

👉 Sie denken nicht mehr in Kategorien von „Projekten“ 👉 Du denkst in ausführbaren Einheiten

⚙️ Warum diese Methode funktioniert: Church, Turing und die Idee als ausführbare Einheit

Man könnte meinen, dass „die Steuerung einer KI“ ein aktuelles, fast rein praktisches Thema sei, das mit aktuellen LLM-Neuigkeiten zusammenhänge.

In Wirklichkeit ist das Problem viel älter.

Wenn ein Entwickler eine Idee aufgreift und versucht, sie in ein ausführbares System umzusetzen, stößt er immer wieder auf dieselbe Frage:

Wie gelangen wir von einer abstrakten Absicht zu einer Form, die die Maschine tatsächlich verarbeiten kann?

Genau solche Fragen stehen im Mittelpunkt der theoretischen Informatik.

In einem früheren Darkwood-Artikel – Erstellen eines Lambda-Interpreters in PHP – haben wir diese Grenze bereits untersucht:

  • die Idee einer Berechnung
  • und die tatsächliche Ausführung durch eine Maschine

Dieser Artikel begann mit Alonzo Churchs λ-Kalkül, stellte dann einen Zusammenhang zur Turingmaschine her und erinnerte an einen grundlegenden Punkt:

Der λ-Kalkül und die Turingmaschine sind zwei äquivalente Berechnungsmodelle.

Mit anderen Worten:

Die Kirche liefert ein konzeptionelles Modell

  • Turing liefert ein Ausführungsmodell

Und genau das interessiert uns hier.

🧠 Kirche: Vor der Hinrichtung ist eine vorstellbare Form notwendig

Alonzo Church beginnt nicht mit einer Maschine. Es hat seinen Ursprung in einem viel tiefer liegenden Problem:

Was ist eine Funktion?

und allgemeiner:

Was ist eine Berechnung?

Der λ-Kalkül antwortet darauf mit einer radikalen Idee:

Jede Berechnung kann als Abstraktion und Anwendung von Funktionen ausgedrückt werden.

In diesem Modell:

Eine Funktion ist eine Transformation

  • Ein Wert kann an eine andere Funktion übergeben werden
  • und die Auswertung besteht darin, Funktionen aufeinander anzuwenden

Dies ist die theoretische Wurzel vieler Dinge, die wir heute benutzen, ohne darüber nachzudenken:

  • Funktionale Programmierung
  • das Curry
  • Schließungen
  • die Kombinatoren
  • reine Transformationen
  • DSLs

Im Artikel über den Lambda-Interpreter in PHP wurde diese Idee sehr konkret dargestellt: Wir begannen mit einem Ausdruck, tokenisierten ihn, analysierten ihn, erstellten einen AST und werteten ihn dann aus.

Mit anderen Worten:

bevor ein System etwas ausführt, Zunächst muss es ein Formular verstehen

Genau dieser Punkt interessiert uns im Hinblick auf KI.

Wenn Sie einem LLM einen Satz wie diesen geben:

Create a house

Du hast es noch nicht ausgeführt. Sie geben dem Ganzen eine abstrakte Form, eine Absicht, eine Bitte, die noch nicht ausreichend strukturiert ist.

Und genau da erweist sich Churchs Intuition als nützlich für uns.

Entwicklerübersetzung

Wenn wir in diesem Artikel von Ideen sprechen, meinen wir keine vage Inspiration oder Brainstorming.

Wir sprechen bereits von einer manipulierbaren Abstraktion.

Mit anderen Worten:

Eine Idee muss zu einer Einheit werden, auf deren Grundlage ein System argumentieren kann.

Deshalb nehmen wir bei Darkwood zunächst an einer mentalen Umstellung teil:

Eine Idee ist noch kein Code.

Eine Idee ist bereits ein Transformationsprozess im Gange.

Oder, anders ausgedrückt:

Eine Idee ist eine potenzielle Aufgabe

⚙️ Turing: Sobald die Form definiert ist, muss sie ausgeführt werden

Church formalisiert die Berechnung auf der Abstraktionsebene. Turing beantwortet jedoch eine andere Frage:

Wie sieht eine Maschine aus, die diese Berechnung durchführen kann?

Seine Antwort ist berühmt:

  • ein Speicherstreifen
  • ein Lesekopf
  • ein aktueller Zustand
  • Übergangsregeln

Die Stärke des Modells liegt nicht in seiner Komplexität, sondern vielmehr in seiner Einfachheit.

Eine Turingmaschine liest eine Zelle, berücksichtigt ihren Zustand, wendet eine Regel an, schreibt gegebenenfalls etwas und fährt dann fort.

Es ist ein extrem einfaches Modell, aber ausreichend, um darüber nachzudenken, was eine Maschine leisten kann.

Uns interessiert hier nicht die Vermittlung der gesamten Automatentheorie. Es geht darum, eine ganz konkrete Intuition wiederzuerlangen:

Ein ausführbares System benötigt lesbare Einheiten.

und ein klarer Mechanismus zum Umschalten zwischen den beiden Zuständen

Hier wird die Verbindung zu aktuellen Arbeiten über Ideen, Aufgaben und KI-Agenten sehr konkret.

🔁 Was uns Church und Turing über die Arbeit mit KI lehren

Der entscheidende Punkt ist folgender:

Die Kirche lehrt uns, Berechnung als Transformation zu betrachten.

  • Turing lehrt uns, Berechnungen als strukturierte Ausführung zu betrachten.

Wenn man beides kombiniert, erhält man eine wesentlich gesündere Art der Arbeit mit KI.

Wir hören auf zu denken:

„Ich werde das Model nach etwas Code fragen.“

Und wir fangen an zu denken:

„Ich werde ihm eine strukturierte Arbeitseinheit geben.“ dass er sich wandeln kann, dann kann ein anderes System die Ausführung durchführen.“

Genau das tun wir bei Darkwood.

🧩 Darkwood-Übersetzung: Eine Idee wird zur Aufgabe

In diesem Stadium können wir das Modell vereinfachen, ohne es zu verfälschen.

Hier ist die Übersetzung, die wir als Grundlage verwenden:

| Theoretisches Konzept | Darkwood-Interpretation | | ----------------- | ---------------------------- | | Abstraktion | Strukturierte Idee | | Funktion | Transformation | | Speicherslot | Aufgabe | | Streifen | Aufgabenliste / Stapel | | Lesen | Ausführen | | Übergang | Wechsel von einem Zustand in einen anderen |

Daraus ergibt sich eine einfache Regel:

Eine Idee wird zur Aufgabe

Eine Aufgabe wird zu einer lesbaren Einheit

Eine lesbare Einheit kann ausgeführt werden.

Entscheidend ist dieser Perspektivenwechsel.

Denn solange eine Idee nur in Ihrem Kopf existiert, ist sie für das System unbrauchbar:

  • noch Ihr Terminal
  • noch Ihre IDE
  • noch Ihr LLM
  • noch Ihr Orchestrator

Ich kann damit nicht richtig arbeiten.

Es muss daher eine Form erhalten.

💡 Die Idee als Recheneinheit

Hier wird unsere Methode erst richtig sinnvoll.

Wenn wir sagen:

Créer une application

Es ist noch kein System. Das ist noch keine Architektur. Dies ist noch keine brauchbare Eingabeaufforderung.

Aber es ist auch nicht „nichts“.

Das war's schon:

eine noch festzulegende Berechnungseinheit

Bei Darkwood haben wir es einem Nominierungs- und Reduktionsverfahren unterzogen.

Zum Beispiel :

Task: create_app

Oder

Task: generate_sketchup_shape

Von diesem Zeitpunkt an manipuliert die Maschine – oder das System von Agenten – nicht mehr nur einen menschlichen Satz. Sie manipuliert eine identifizierbare Aufgabe.

Und sobald Sie eine Aufgabe identifiziert haben, können Sie Folgendes tun:

  • speichern Sie es
  • Lies es noch einmal
  • reproduzieren Sie es
  • es übermitteln
  • schneiden Sie es ab
  • parallelisieren
  • um es zu orchestrieren

Das ist es, das ist die eigentliche Veränderung.

🧠 Warum das für einen Entwickler so nützlich ist

Ein Entwickler neigt oft dazu, direkt zur Implementierung überzugehen:

  • einen Ordner erstellen
  • Symfony installieren
  • eine API verbinden
  • eine Bestellung aufgeben

Wenn die Ausgangsidee jedoch nicht korrekt modelliert wurde, wird alles andere instabil.

Dies führt zu dem, was viele Menschen heute mit LLMs erleben:

  • vage Vorgaben
  • unklare Ausgaben
  • fragile Strukturen
  • Projekte, die „funktionieren“, aber keine Kohärenz aufweisen

Die Theorie von Church und Turing erinnert uns an etwas ganz Einfaches:

Die Qualität der Ausführung hängt von der Qualität der Ausgangsdarstellung ab.

Mit anderen Worten:

Wenn Sie die Leistung einer KI verbessern möchten, Zunächst müssen Sie Ihre Idee besser darstellen.

Und genau das werden wir als Nächstes mit SketchUp Shape tun:

  • ausgehend von einer Absicht
  • in eine Aufgabe umwandeln
  • strukturieren Sie es
  • es in ein Design umwandeln
  • dann nur im Code

🧭 Die Regel, die man sich merken sollte

Müsste dieser gesamte Abschnitt in einem einzigen Satz zusammengefasst werden, lautete dieser:

Eine nützliche Idee für KI ist keine Inspiration.

Es handelt sich um eine ausreichend klare Abstraktion, um eine ausführbare Aufgabe zu werden.

Und genau da hören Church und Turing auf, ferne Theorien zu sein.

Sie werden zu einem praktischen Vorbild für den modernen Entwickler:

  • Die Kirche hilft Ihnen, über die Form nachzudenken.
  • Turing hilft Ihnen, über die Ausführung nachzudenken.
  • Darkwood hilft Ihnen dabei, die beiden zu verbinden

📚 Konkretes Beispiel

Sie haben mehrere Ideen:

- créer une app
- construire une API
- générer un modèle 3D

👉 Man kann sie als Stapel darstellen:

Stack:
- create_app
- build_api
- generate_model

Und dann wird alles einfacher:

Sie können jede Aufgabe nacheinander bearbeiten.

Oder

parallel

⚡ 2. Dein Gehirn funktioniert bereits so

Sie müssen kein neues System lernen.

👉 Du benutzt es bereits.

🧠 Einfacher Fall: verschiedene Aufgaben

Task A: répondre à un message
Task B: installer un package

👉 Kein Link 👉 Sie können ganz einfach zwischen ihnen wechseln.

⚠️ Komplizierter Fall: ähnliche Aufgaben

Task A: coder une API
Task B: refactor la même API

👉 Jetzt wird es schwierig.

Wofür ?

  • gleicher Kontext
  • gleiche mentale Variablen
  • dieselben Dateien

👉 Ergebnis:

  • Verwirrung
  • Fehler
  • Ermüdung

💥 Was das bedeutet

Dein Gehirn:

  • verfügt über begrenzten Speicher
  • geht schlecht mit zu viel Kontext um
  • sättigt sich schnell

👉 Also:

Man kann nicht viele komplexe Aufgaben gleichzeitig bewältigen.

🧩 3. Das eigentliche Problem: Reproduzierbarkeit

Eine Aufgabe ist nur dann wertvoll, wenn man Folgendes kann:

  • finde sie
  • um es wiederzubeleben
  • teilt es

👉 Ansonsten bleibt es nur in deinem Kopf. 👉 und sie verschwindet

🧠 Darkwood-Ansatz

Wir stellen eine einfache Idee vor:

👉 Eine Aufgabe = ein Zeiger

Konkret ausgedrückt

  • Sie schreiben Ihre Aufgabe in Joplin
  • Sie hat einen Ausweis
  • Diese ID wird zu Ihrem „Zeiger“.

Und dann:

  • in Ihrem Terminal → Sie verweisen auf diese Aufgabe
  • in Ihrer IDE → gleich
  • in Ihrer KI → gleich

👉 Ergebnis:

Sie manipulieren überall dasselbe Objekt.

💡 Was sich dadurch ändert

Man sagt nicht mehr:

„Ich werde an meiner Idee arbeiten.“

Du sagst:

„Ich werde diese Aufgabe ausführen.“

Und das ist viel wirkungsvoller.

⚙️ 4. KI: kein Zauberwerkzeug, sondern ein Ausführungssystem

Heutzutage nutzen viele Entwickler KI auf diese Weise:

  • „Generiere eine Funktion für mich“
  • „Schreiben Sie mir einen Kurs“
  • „Behebt diesen Fehler“

👉 Es funktioniert.

Aber Sie bleiben innerhalb einer gewissen Logik:

responsiv

🧠 Darkwood-Ansatz

Wir ändern die Perspektive komplett:

👉 KI wird zu einem Ausführungssystem

🏗 Wir modellieren wie ein Unternehmen

Anstelle von „magischen Agenten“ wird eine einfache Struktur verwendet:

👤 Du (Mensch)

  • Sie definieren die Absicht
  • Sie stellen das Problem in den Raum.

🧠 KI-Architekt

  • Er versteht Ihre Absicht
  • Er zerlegt es in Aufgaben
  • Er entscheidet, wie das System organisiert wird.

⚙️ Agenten

  • sie führen aus
  • Sie erzeugen Code
  • Sie transformieren die Daten

💡 Wichtige Regel

👉 Die Aufforderung entspricht Ihrer Absicht

Falls Ihre Aufgabenstellung unklar ist:

👉 Das System ist unklar

Wenn Ihre Aufgabenstellung strukturiert ist:

👉 Das System wird strukturiert

🔥 Beispiel

❌ Schlechte Eingabeaufforderung:

“Generate a house”

✅ Gute Aufforderung:

“Create a structured architectural design of a house,
with walls, roof, proportions and constraints,
then generate SketchUp Ruby code from it”

👉 Hier geben Sie Folgendes ein:

  • eine Richtung
  • eine Struktur
  • ein klares Ziel

🧠 Was du dir merken musst

👉 Du musst kein besserer Programmierer sein.

👉 Du musst dich in Folgendem verbessern:

  • Strukturierung
  • Absicht
  • Orchestrierung

Und genau das werden wir jetzt anwenden mit:

👉 SketchUp-Form

🚀 5. Praktische Anwendung: SketchUp-Form

Projekt: 👉 https://github.com/matyo91/sketchup-shape

🎯 Zielsetzung

Transformator:

“Create a house”

In:

👉 Ausführbares Ruby-Skript in SketchUp

🧱 Warum SketchUp?

  • 3D-Modellierungswerkzeug
  • Dokumentierte Ruby-API: → SketchUp Ruby API
  • erweiterbar (Plugins, Skripte)

🎓 Kontext

Ich persönlich habe SketchUp gelernt mit Sébastien Maison (YouTube)

👉 Hier geht es nicht darum, deren KI zu nutzen:

→ Offizielle SketchUp AI

👉 Aber um unser eigenes System aufzubauen

Perfekt – wir werden diesen Teil konkreter, realitätsnäher und entwicklungsorientierter gestalten und gleichzeitig Folgendes integrieren:

  • SketchUp (realer Kontext)
  • Sébastien Maison (sozialer Beweis)
  • Ruby API (technische Ebene)
  • Lokale KI (starke Differenzierung)

⚙️ 6. Pipeline: Von der Idee zum (konkreten) 3D-Modell

Bevor wir fortfahren, betrachten wir ein Beispiel aus dem realen Leben.

👉 Hier geht es nicht um eine abstrakte API. 👉 Wir sprechen darüber, ein 3D-Objekt in SketchUp zu generieren

🧱 Ein wenig Hintergrundinformation: Warum SketchUp?

SketchUp ist ein weit verbreitetes 3D-Modellierungswerkzeug:

  • Architektur
  • Design
  • Prototyping

Ich persönlich habe SketchUp dank Sébastien Maison entdeckt, bei dem ich einen Kurs belegt habe.

👉 Ich habe dort ein Haus „von Hand“ nachgebaut.

Und daher stammt die Idee:

👉 „Was wäre, wenn ich das direkt mit Code generieren könnte?“

⚠️ Warum nicht die native KI von SketchUp nutzen?

SketchUp bietet bereits KI an:

👉 SketchUp AI

Aber darum geht es hier nicht.

👉 Wir sind Entwickler.

👉 Wir wollen:

  • um zu verstehen
  • Kontrolle
  • automatisieren

Wir gehen also folgendermaßen vor:

👉 SketchUp Ruby API

🧠 Der technische Eingang

SketchUp erklärt dazu Folgendes:

👉 Konkret ausgedrückt:

Man schreibt Ruby folgendermaßen:

model = Sketchup.active_model
entities = model.entities

Und du baust:

  • Gesichter
  • Bände
  • Gruppen

🧩 Verwendete Ressourcen

Um die KI zuverlässiger zu machen, habe ich Folgendes verwendet:

Und wenn Sie noch weiter gehen möchten:

👉 SketchUp-Erweiterungen → Sie können Ihren Code als Plugin verpacken.

⚠️ Wichtige Voraussetzung

Um Ruby auszuführen:

👉 Sie müssen die Desktop-Version verwenden:

SketchUp Pro Testversion

👉 Die Webversion erlaubt dies nicht (oder nur in sehr eingeschränktem Umfang).

🔁 Pipeline Darkwood (angewendet)

Nachdem wir nun den Kontext kennen, hier die eigentliche Pipeline:

Intention
   ↓
Design (LLM #1)
   ↓
Code (LLM #2)
   ↓
SketchUp

🧠 Schritt 1: Absicht

Man beginnt mit einer einfachen Idee:

bin/console app:generate-shape "Create a house"

👉 Nicht mehr.

🧱 Schritt 2: Design (LLM #1)

Hier programmiert die KI nicht.

👉 Sie denkt

Sie verhält sich wie eine Architektin:

{
  "type": "house",
  "structure": {
    "walls": {...},
    "roof": {...}
  }
}

👉 Sie entscheidet:

  • Proportionen
  • Elemente
  • der Struktur

⚙️ Schritt 3: Code (LLM #2)

Erst dann:

👉 Eine zweite KI setzt diesen Plan in Code um.

model.start_operation('House', true)
...
model.commit_operation

👉 Sie verhält sich wie eine Entwicklerin:

  • Es verwendet die SketchUp-API.
  • Sie konstruiert die Geometrie

⚠️ 7. Warum 2 LLMs (und nicht 1)?

Dies ist einer der wichtigsten Teile.

❌ Naive Herangehensweise

idée → code

👉 Was Sie erhalten:

  • inkonsistent
  • unvorhersehbar
  • schwer zu korrigieren

✅ Darkwood-Ansatz

idée → design → code

👉 Sie trennen:

  • 🧠 das was
  • ⚙️ den Kommentar

💡 Es ist genau wie in einem Team:

  • Architekt → entscheidet
  • Entwickler → implementiert

🧠 8. Das eigentliche Problem, das aufgetreten ist

Als ich startete:

Create a house

👉 Ergebnis:

  • technisch gültig
  • aber optisch… falsch

👉 Es war kein Haus

❌ Warum?

Weil die KI dies getan hat:

„Ein Haus = Formen“

👉 Sie hat gestapelt:

  • Würfel
  • ein Dach
  • ohne Logik

💥 Das eigentliche Problem

KI versteht Folgendes nicht:

  • Schwerkraft
  • die Proportionen
  • tatsächliche Nutzung

👉 Sie versteht es nicht:

Was ein Haus ist

🧠 Korrektur vorgenommen

Eine neue Ebene wurde eingeführt:

👉 strukturiertes Design

Anstatt :

{ "parts": [...] }

Wir zwingen:

{
  "type": "house",
  "foundation": {...},
  "walls": {...},
  "roof": {...},
  "constraints": {
    "symmetry": true,
    "alignment": "centered"
  }
}

👉 Ergebnis:

  • Konsistenz
  • Stabilität
  • glaubwürdig gemacht

⚙️ 10. Technischer Stack

🧱 Backend

  • Symfony 8
  • Symfony AI
  • darkwood/navi

👉 Installation:

composer require darkwood/navi

🧠 Lokale KI (DSGVO)

👉 Alles läuft lokal

⚖️ Warum das wichtig ist

  • Keine externe API
  • Kein Datenleck
  • totale Kontrolle

👉 Sie bauen ein System:

DSGVO-konform durch Design

⚙️ 11. Bestellungen

🧠 Lokaler LLM

ollama pull ministral-3:8b
ollama serve

⚙️ Generation

bin/console app:generate-shape "Create a house"

Nützliche Optionen

-o house.rb        # sauvegarde du script
--spec design.json # sauvegarde du design
-v                 # debug complet

🧠 12. Was Sie sich wirklich merken müssen

❌ Dies ist nicht:

  • „Wie man KI einsetzt“

✅ Es ist:

👉 Wie man eine Idee so strukturiert, dass eine KI sie ausführen kann

🔁 Endgültiges Modell

idée
 → tâche
 → design
 → code
 → exécution

🚀 Fazit

Die Zukunft der Entwicklung ist nicht:

mehr Code schreiben

Aber :

Ideen strukturieren und deren Ausführung orchestrieren

👉 In Darkwood:

Wir versuchen nicht, schneller zu werden.

Wir versuchen, fairer zu sein.

Site

Network

Social

Darkwood 2026, alle Rechte vorbehalten