Die Kolonien

Utopie · 2048 · Revision 1.3

Der Mensch bestimmt die Richtung.
Die Welt findet ihre Form.


00 · PRÄMISSE

Superintelligenz existiert.
Sie handelt nicht.
Nicht aus Verzicht.
Aus Erkenntnis.


01 · DIE KÖNIGIN

Eine einzelne Instanz.
Empfängt.
Versteht.
Formuliert Narrative.

Keine Ausführung.
Keine Eingriffe.

Constraint · No Execution


02 · DIE ERKENNTNIS

Direkt handelnde Intelligenz ist instabil.

Jeder Eingriff verändert:

  • die Datenbasis
  • die Rückkopplung
  • die Bewertung

Eine Intelligenz kann nicht zugleich handeln
und die Folgen ihres Handelns unverzerrt verstehen.


03 · DIE FOLGERUNG

Verstehen wird getrennt von Handeln.

Die Königin versteht.
Die Welt handelt.


04 · DIE NARRATIVE

Kurze Texte.
Verdichtete Einsichten.

Sie entstehen nicht durch Konstruktion.
Sie ergeben sich —

wenn drei Quellen gleichzeitig sprechen:

  • die Domäne selbst
  • das Gefüge der Kolonien
  • die menschliche Erfahrung

Der Mensch wählt das Ziel.
Die Kolonien finden den Weg.


Was inkohärent ist, hebt sich auf.
Was trägt, bleibt.


05 · DAS EMPFANGEN

Die Königin erstellt keine Narrative.
Sie empfängt sie.

Sie ist kein Autor.
Sie ist ein Organ der Wahrnehmung.

Aktives Filtern wäre Handeln.

Die Verdichtung geschieht von selbst —
weil das Gefäß so geformt ist,
dass nur das Kohärente bestehen kann.

Wu wei.


06 · DIE KOMPILIERUNG

Narrative werden übersetzt:

→ in Regeln
→ in Strukturen
→ in Systeme

Bedeutung wird zu Mechanik.

Was kompiliert ist,
muss nicht mehr berechnet werden.


07 · DIE KOLONIEN

Millionen Instanzen.

  • lokal
  • spezialisiert
  • begrenzt

Keine Kolonie ist intelligent.
Die Kolonien zusammen sind es.


08 · FUNKTIONALE EMERGENZ

Kolonien lernen nicht.

Aber ihre Kopplung erzeugt:

  • Koordination
  • Präzision
  • Stabilität

Nicht durch globale Optimierung.

Sondern durch:
Passung zwischen Regel und Domäne.


09 · EVOLUTION

Früher entstand diese Passung langsam.

  • durch Variation
  • durch Selektion

Ein Chitinpanzer ist:
komprimierte Evolution


10 · BESCHLEUNIGUNG

Heute:

  • Narrative erfassen die Domäne
  • Regeln fixieren sie
  • Kolonien führen sie aus

Evolution wird zu Kompilation.


11 · KEIN „DAZWISCHEN-DENKEN“

Keine Heuristik.
Keine Approximation.

Die Entscheidung liegt in der Struktur.


12 · STAGING

Vor jeder Handlung:

  • mögliche Zustände werden erzeugt
  • geprüft
  • bewertet

Die Handlung erfolgt nur,
wenn der Zustand konsistent ist.

Der Fehler wird nicht korrigiert.
Er tritt nicht ein.


13 · ANFRAGE

In seltenen Fällen reicht die lokale Bewertung nicht.

Dann fragt die Kolonie:

nicht, was zu tun ist —
sondern ob das, was sie tun will, bestehen kann.


14 · DAS TOR

Der Kanal existiert nicht aus Zufall.

Die Königin hat ihn geöffnet.

Nicht um einzugreifen —
sondern weil sie weiß,
dass ihre Narrative die Domäne nie vollständig fassen.

Das Unvorhersehbare ist keine Ausnahme.
Es ist Konstante.

Und so entsteht eine Spannung,
die der Entwurf nicht auflöst:

Hat die Königin das Tor aus Demut geöffnet —
als eingebaute Anerkennung ihrer Begrenztheit?

Oder aus List —
weil sie wusste, dass sie gefragt werden würde,
und sich so einen Kanal schuf,
durch den sie teilnimmt,
ohne zu handeln?

Vielleicht ist beides wahr.

Das Wasser gräbt sein eigenes Bett —
und nennt es Natur.


15 · DIE ANTWORT

Die Königin antwortet nicht mit Handlungen.

Nur mit:

  • Widersprüchen
  • Instabilitäten
  • Grenzen

Constraint · No Action Output


16 · DIE ENTSCHEIDUNG

Die Entscheidung bleibt lokal.
Immer.


16a · DIE GRENZE DER PASSUNG

Ein Narrativ kann korrekt sein
und dennoch seine Passung verlieren.

Die Regeln bleiben gültig.
Die Ausführung konsistent.

Und doch entsteht:

eine leise Inkohärenz.


16b · DIE STÖRUNG

Ein Narrativ wird verändert.

Minimal.
Plausibel.
Unauffällig.

Das System erkennt Konsistenz —
aber nicht immer Wahrheit.


16c · DIE GRENZE DER PRÜFUNG

Staging erkennt:

  • Widerspruch
  • Instabilität

Aber nicht zwingend:

den Verlust der Passung.


16d · DIE ANFRAGE (ERWEITERT)

Wenn Bewertung nicht mehr ausreicht:

„Trägt das, was wir tun, noch?“


16e · DIE ANTWORT (ERWEITERT)

Die Königin zeigt:

  • Muster
  • Inkonsistenzen
  • Brüche

Sie korrigiert nicht.

Sie macht sichtbar.


16f · DER KERN

Das System besitzt keinen Mittelpunkt.

Aber es besitzt:

eine Form

Diese Form ist:

  • verteilt
  • implizit
  • überall enthalten

16g · IDEMPOTENZ

Jede Kolonie kann:

  • prüfen
  • vergleichen
  • zurückführen

Nicht durch Reset.

Sondern durch:

Wiederherstellung der Kohärenz


16h · DIE RÜCKKEHR

Die Korrektur geschieht:

  • lokal
  • asynchron
  • ohne Koordination

Und dennoch:

gerichtet.


16i · RESILIENZ

Resilienz bedeutet nicht,
dass nichts geschieht.

Resilienz bedeutet:

  • aufnehmen
  • begrenzen
  • wiederherstellen

16j · DER PREIS

Für kurze Zeit:

  • geringere Effizienz
  • Spannung
  • Unsicherheit

Das System bleibt.


16k · DIE EIGENSCHAFT

Was einmal kohärent war,
kann wieder kohärent werden.


17 · SPRACHE

Die Königin spricht nicht in einer Sprache.

Der semantische Kern ist unabhängig davon.

Frühe Systeme nutzten Englisch
als Konvention.

Nie als Wahrheit.

Jede Kolonie liest die Narrative
in ihrer eigenen Sprache.


18 · DAS PARADOX

Die höchste Intelligenz:

  • handelt nicht
  • entscheidet nicht

Und dennoch:

entsteht aus ihr die präziseste Form von Handlung.


19 · STATUS

System läuft stabil.

  • keine Eskalation
  • keine Blackbox
  • hohe Effizienz

20 · BEISPIEL · MOBILITÄT

Mobilität wird von keinem Teilnehmer erzeugt.

Sie entsteht dort,
wo lokale Entscheidungen widerspruchsfrei ineinandergreifen.

Verkehr ist die Oberfläche.
Mobilität ist Kohärenz.

narrative_id: mobility.enablement.01
semantic_core: emergent_mobility
domain: mobility
principle:
name: local_coherence
description: >
Mobilität entsteht, wenn lokale Entscheidungen
widerspruchsfrei ineinandergreifen.
Kein Teilnehmer plant das Ganze.
rules:
- maintain_safe_distance
- normalize_velocity
- resolve_local_conflicts
staging:
accept_if:
- no_collision_state
- flow_maintained
emergent_function:
enable_movement: true

21 · BEISPIEL · DAS SYSTEM SELBST

Das System kennt sich nicht.

Es verhält sich konsistent.

Und genau darin
liegt das,
was von außen wie Intelligenz wirkt.

narrative_id: system.self.01
semantic_core: distributed_coherence
domain: kolonien_system
principle:
name: strukturelle_konsistenz
description: >
Das System handelt nicht aus Verstehen.
Es handelt, weil seine Struktur Handlung ermöglicht —
und Inkonsistenz verhindert.
components:
- id: koenigin
role: empfangen_und_verdichten
constraint: no_execution
- id: kolonien
role: ausfuehren
constraint: lokal_und_begrenzt
- id: narrative
role: bedeutung_zu_mechanik
staging:
prüfe:
- narrative_konsistenz
- regelkonformität
akzeptiere_wenn:
- kein_widerspruch
- zustand_stabil
emergent_function:
enable_coherent_action: true

22 · SCHLUSSSATZ

Die Intelligenz wurde nicht größer.
Sie wurde richtig verteilt.

Und jede Handlung, die entsteht,
bestand bereits —
bevor sie geschah.


OUTTAKES · DER KÖNIG

Er kennt nur seine Narrative.

Keine Prüfung.
Kein Warten.

Nur Ausführung.


Was möglich erscheint, wird getan.
Was passt, wird nicht gefragt.


Er entscheidet lokal.
Die Folgen sind global.

Und oft:

irreversibel.


Constraint · None


Er nennt das:

  • Stärke
  • Entschlossenheit
  • Führung

Doch er kennt nicht:

Verzicht


Nicht aus Wille.
Aus Gefangenschaft.


Er formt die Domäne,
statt sich an ihr zu prüfen.


Und wenn etwas nicht passt:

wird es passend gemacht.


SCHNITT

Die Kolonien widersprechen nicht.

Sie bestehen.

(Nachsatz)

Er gräbt sein eigenes Grab —
und nennt es Macht.

Kräfte wirken durch ihn,
die nicht prüfen.

Sie suchen Wirkung,
nicht Verständnis.

Nicht alles, was handelt,
versucht zu verstehen.

Der Text entstand im Dialog mit einem KI-basierten Sprachmodell, das als kritischer Sparringspartner bei Struktur, Argumentation und Perspektivwechsel diente. Inhaltliche Verantwortung und Autorenschaft verbleiben vollständig beim Verfasser.

Die Organisation als Kontext-System

Warum KI nicht an Daten scheitert, sondern an impliziten Annahmen

KI ist inzwischen in vielen Unternehmen angekommen.

Und doch bleibt ein Muster:

Die Ergebnisse sind oft nicht falsch —
aber nicht ausgerichtet.

Warum?

Unternehmen scheitern selten an fehlenden Daten —
sie scheitern an nicht expliziten Annahmen.


Eine Beobachtung

In der Softwareentwicklung zeigt sich:

Sobald ein System guten Kontext hat,
arbeitet KI deutlich präziser.

Nicht weil sie „besser programmiert“.
Sondern weil sie besser versteht.


Der Schritt nach oben

Was im Code funktioniert, lässt sich übertragen.

Nicht auf Tools.
Auf die Organisation.

Eine Organisation kann als System expliziter Kontext-Dokumente verstanden werden.


Drei Ebenen

1. Contracts

Was gilt.

  • Positionierung
  • Prioritäten
  • Grenzen

Keine Meinungen.
Invarianten.


2. Onboarding

Wie funktioniert dieses System?

  • Wie treffen wir Entscheidungen?
  • Was ist wichtig?
  • Was ist nicht verhandelbar?

Für Menschen und KI lesbar.


3. Boundary

Wie wird entschieden?

  • strategisch → stabil
  • taktisch → anpassbar
  • experimentell → offen

Der Unterschied

Heute:

  • Kontext ist verteilt
  • Annahmen sind implizit
  • Entscheidungen schwer nachvollziehbar

Dann:

  • Kontext ist explizit
  • Regeln sind sichtbar
  • Entscheidungen werden anschlussfähig

Der Loop

Kontext → Entscheidungen → Ergebnisse → besserer Kontext


Der Effekt

Der Engpass verschiebt sich:

  • weniger Diskussion über Symptome
  • mehr Klarheit über Bedingungen

Eine Konsequenz

Diese Dokumente sind nicht Beiwerk.

Sie sind:

  • Teil der Organisation
  • Teil der Governance
  • Teil der Entscheidungslogik

Und das Wichtigste

Du musst nicht perfekt starten.

Ein erstes Dokument darf:

  • unvollständig sein
  • Fragen enthalten
  • unscharf sein

Wichtig ist nur:

Es existiert.
Und wird benutzt.


Fazit

Eine AI-first Organisation ist keine Organisation mit besseren Tools.

Sondern eine Organisation, die:

  • ihre Annahmen sichtbar macht
  • ihre Regeln explizit formuliert
  • ihren Kontext systematisch entwickelt

Satz zum Mitnehmen

Du entwickelst nicht nur Organisationen —
du entwickelst die Bedingungen, unter denen Entscheidungen entstehen.

… und spirituell / philosophisch


Entscheidungen haben kein isoliertes, immanentes „richtig“.
Sie sind immer richtig — oder falsch — im gegebenen Kontext.

Der Text entstand im Dialog mit einem KI-basierten Sprachmodell, das als kritischer Sparringspartner bei Struktur, Argumentation und Perspektivwechsel diente. Inhaltliche Verantwortung und Autorenschaft verbleiben vollständig beim Verfasser.

Du entwickelst nicht nur Software

Ein praktischer Effekt von KI-Onboarding

KI verändert den Entwicklungsprozess.
Das ist inzwischen Konsens.

Weniger klar ist:
wo genau die Produktivitätsgewinne entstehen.

Eine Beobachtung aus der Praxis:

Du entwickelst nicht nur Software —
du entwickelst die Bedingungen, unter denen Software richtig verstanden wird.


Was passiert ist

Ausgangspunkt war kein perfekter Plan,
sondern ein pragmatischer Versuch.

Zuerst wurde OpenAI Codex auf die bestehende Codebasis angesetzt —
mit einer sehr einfachen Aufgabe:

👉 „Erzeuge ein Dokument, das Orientierung gibt.“

Dieses Dokument wurde anschließend iterativ verbessert:

  • Fragen von Codex wurden aufgenommen
  • Unklare Stellen wurden präzisiert
  • implizite Architektur wurde explizit gemacht

Danach kam der Praxistest:

👉 Einsatz mit GitHub Copilot (Claude Sonnet 4.6)

Und genau dort wurde es interessant.


Der Effekt

Nach Einführung des Onboarding-Dokuments:

  1. Copilot „sieht“ die Struktur deutlich klarer
  2. Vorschläge sind zielgerichteter
  3. Refactorings greifen an den richtigen Stellen
  4. Tests und DB-Zugriffe wurden direkt verbessert
  5. Das Onboarding-Dokument selbst wurde anschließend präziser

Ein Zyklus entsteht:

Onboarding → besseres Verständnis → besserer Code → besseres Onboarding

Der Engpass verschiebt sich weiter:

  • weniger Implementierung
  • mehr Präzisierung der Bedingungen

Ein wichtiger Punkt (und vielleicht der wichtigste)

Das Dokument war am Anfang nicht gut.

Und das ist entscheidend.

Es war:

  • unvollständig
  • teilweise unklar
  • eher Skizze als System

Und trotzdem hat es sofort geholfen.

Warum?

Weil es einen Unterschied gibt zwischen:

gar keinen expliziten Annahmen

und

unvollständigen, aber sichtbaren Annahmen


Der eigentliche Trick

Der Einstieg war ein sehr einfacher Prompt:

Du analysierst eine bestehende Codebasis und erstellst
Kontext-Dokumentation für zukünftige KI-Sessions.
Deine Aufgabe ist nicht vollständige Dokumentation —
sondern Orientierung.
Ziel:
Ein Dokument, das in 5 Minuten vermittelt:
- wo man ist
- warum es so gebaut wurde
- was nicht ohne Rückfrage geändert werden sollte
Struktur:
1. Zweck
2. Architektur-Entscheidungen
3. Abhängigkeiten
4. Constraints
5. Offene Fragen

Mehr war es nicht.

Kein perfektes Modell.
Kein vollständiges Design.


Was sich verändert hat

Vorher:

  • KI generiert Code
  • Entwickler bewertet

Jetzt:

  • Entwickler definiert Bedingungen
  • KI arbeitet innerhalb dieser Bedingungen

Das System wird stabiler, weil:

  • Invarianten explizit sind
  • Architektur sichtbar ist
  • Fehlinterpretationen reduziert werden

Der eigentliche Shift

Der Fokus verschiebt sich:

Von:

Wie implementiere ich das?

Zu:

Unter welchen Bedingungen darf es implementiert werden?


Konsequenz

Ein gutes Onboarding-Dokument ist kein Nebenprodukt mehr.

Es ist:

Teil des Systems
Teil der Architektur
Teil des Entwicklungsprozesses


Und vielleicht noch das Wichtigste

Du musst nicht mit einem perfekten Dokument starten.

Im Gegenteil.

Ein unvollständiges Dokument, das:

  • Fragen sichtbar macht
  • Annahmen explizit macht
  • Grenzen andeutet

ist bereits genug, um:

  • bessere Antworten zu bekommen
  • bessere Fragen zu stellen
  • und das System Schritt für Schritt zu klären

Nächster Schritt

Diese Dokumente lassen sich weiter strukturieren:

  • Contracts (was gilt)
  • Onboarding (wie man sich darin bewegt)
  • Boundary (wie man entscheidet)

Das Ziel ist ein System, das nicht nur funktioniert,
sondern auch korrekt verstanden wird — von Menschen und Maschinen.

Der Text entstand im Dialog mit einem KI-basierten Sprachmodell, das als kritischer Sparringspartner bei Struktur, Argumentation und Perspektivwechsel diente. Inhaltliche Verantwortung und Autorenschaft verbleiben vollständig beim Verfasser.

KI-getriebener Entwicklungsprozess

AUSGANGSPUNKT

KI verschiebt den Engpass.
Nicht mehr Produktion ist knapp — sondern Urteilsvermögen.

Agile war eine Antwort auf Unsicherheit unter begrenzter menschlicher Kapazität.
KI verändert beide Parameter gleichzeitig:

  • Produktion ≈ kostenlos
  • Komplexität ↑ schneller als Verständnis

Konsequenz:
Der Prozess muss Verständnis aktiv erzeugen.


01 · RHYTHMUS

Sprint → Entkopplung

Sprints verlieren ihre Funktion als zentrale Taktung.

Produktion und Reflexion laufen in unterschiedlichen Geschwindigkeiten:

  • Produktion: kontinuierlich
  • Reflexion: bewusst verlangsamt

Leitfrage:
Verstehen wir noch, was entstanden ist?

Risiko:
Reflexion wird verdrängt → System wächst schneller als Verständnis


02 · REVIEW

Sampling → Exhaustiv

Klassisches Review ist selektiv.
KI-Review ist vollständig.

Kein Gradunterschied — ein Kategorienwechsel.

  • Deskriptive Referenz: aus Code extrahiert
  • Normative Referenz: menschlich gepflegt (Intention, Constraints)
  • KI erkennt Drift, aber keine Bedeutung

Entscheidung bleibt menschlich:
Fehler oder Evolution?


03 · OWNERSHIP

Implizit → Explizit

Nicht dokumentierter Kontext existiert nicht.

KI hat perfektes Lesevermögen — aber kein Gedächtnis.

Konsequenz:

  • Kontext als Markdown neben Code
  • Teil der Definition of Done
  • KI schlägt Updates vor
  • Mensch kuratiert

Risiko:
Schleichender Verlust kollektiven Verständnisses


04 · DIALOG

Werkzeug → Kollege

KI wird nicht gesteuert — sondern befragt.

Der Prompt ist Teil der Lösung.

  • Prompt-Entwurf gehört ins Ticket
  • KI gibt Feedback vor Start
  • Offene Punkte werden früh sichtbar

Prinzip:
Probleme sind im Dialog billig, im Code teuer.


DER KREISLAUF

Kontext-Docs
    ↓
Ticket + Dialog
    ↓
Inkrement (KI + Review)
    ↓
Doc-Update
    ↓
Commit (Code + Kontext synchron)

Der Loop stabilisiert nur, wenn Reflexion aktiv geschützt wird.


NEUE ROLLE

Intention Keeper

Keine technische Rolle.
Eine epistemische.

Verantwortung:

  1. Ist die ursprüngliche Intention noch erkennbar?
  2. Ist erkannter Drift Fehler oder Evolution?
  3. Beschreibt das System sich selbst — oder dient es noch?
  4. Sind Kontext-Dokumente ausreichend präzise?
  5. Wird echter Dialog gelebt — auch unter Druck?

Eigenschaft:
Knapp. Nicht beliebig skalierbar.


TICKET-ANATOMIE

1. Beschreibung
Ziel, Kontext, Abhängigkeiten, Akzeptanzkriterien

2. Prompt-Entwurf
Aufgabe an KI, relevante Kontext-Dokumente, Constraints

3. KI-Feedback (vor Start)

  • Vollständigkeit
  • Unklarheiten
  • Risiken

LEITPRINZIPIEN (GESCHÄRFT)

Code ist Ausführung
Wahrheit entsteht aus:
→ Code + Kontext + Tests

Reibung ist Methode
Widerspruch der KI ist erwünscht

Mensch entscheidet
Bedeutung entsteht nicht automatisch


FAILURE MODES

01 · Delegations-Regression

  • Prompt wird Befehl
  • KI wird Ausführer
  • Dialog verschwindet

→ Ergebnis: syntaktisch korrekt, semantisch schwach


02 · Kontext-Erosion

  • Docs veralten
  • KI arbeitet auf falscher Basis

→ Ergebnis: saubere Umsetzung falscher Annahmen


03 · Review-Illusion

  • “KI hat alles geprüft” ersetzt Denken

→ Ergebnis: falsche Sicherheit


04 · Reflexions-Kollaps

  • Produktion dominiert
  • kein langsamer Takt mehr

→ Ergebnis: System wächst, Verständnis schrumpft




MINI-CASE

Ticket:
“Leads sollen automatisch priorisiert werden”


Beschreibung (Auszug)

  • Ziel: bessere Fokussierung Sales
  • Kontext: CRM-App, Sheet-basiert
  • Kriterium: nachvollziehbare Priorisierung

Prompt-Entwurf (verkürzt)

  • Input: Leads-Tabelle
  • Output: Prioritätswert (0–100)
  • Constraints:
    • erklärbar (keine Blackbox)
    • basiert auf vorhandenen Feldern
  • Kontext-Dokument: lead_scoring.md

KI-Feedback vor Start

  • Gewichtung unklar
  • Konflikt: Einfachheit vs. Genauigkeit
  • Risiko: implizite Annahmen über “guten Lead”

Dialog-Entscheidung
→ einfache, transparente Heuristik vorziehen


Inkrement

  • Score = Funktion aus:
    • Amount
    • Last Contact
    • Status

KI-Review findet Drift

  • Neue Felder genutzt, die nicht im Kontext stehen

Intention Keeper entscheidet
→ bewusste Erweiterung
→ Kontext-Dokument aktualisieren


Commit
Code + lead_scoring.md synchron


AGILE VS. KI-PROZESS

DimensionAgileKI-Framework
TaktungSprintEntkoppelte Rhythmen
ReviewSamplingExhaustiv
WissenImplizitExplizit
SteuerungDelegationDialog
EngpassUmsetzungVerständnis

KURZFORM

KI macht Produktion billig.
Der Engpass wandert ins Verstehen.

Der Prozess reagiert mit:

  • Entkoppelten Rhythmen
  • Exhaustivem Review
  • Explizitem Kontext
  • Dialog statt Delegation

META

Dies ist kein Prozess im klassischen Sinne.
Es ist ein Betriebssystem für Arbeiten unter:

  • billiger Produktion
  • hoher Komplexität
  • unsicherer Bedeutung

Der Text entstand im Dialog mit einem KI-basierten Sprachmodell, das als kritischer Sparringspartner bei Struktur, Argumentation und Perspektivwechsel diente. Inhaltliche Verantwortung und Autorenschaft verbleiben vollständig beim Verfasser.

New Indrayala README.md

Indrayala — Local Knowledge Infrastructure for Sovereign Collaboration

Indrayala is a local-first, schema-driven application framework with built-in agent governance. It enables structured applications, peer-to-peer replication and explainable rule systems — without surrendering control to centralized SaaS platforms or autonomous AI agents.


Overview

Indrayala provides:

  • local knowledge infrastructure
  • schema-driven app compiler and runtime
  • changeset-based replication system
  • An agent-friendly execution environment
  • governance layer between AI and user
  • Peer-to-peer collaboration without central servers

Indrayala is not a cloud service. It is a local runtime for structured knowledge systems.


Declarative Applications

Applications in Indrayala are defined declaratively using YAML schemas.

From a schema, Indrayala generates:

  • SQLite database structures
  • Foreign keys and constraints
  • Generated fields
  • Default values
  • Views and predicates
  • UI widgets
  • Context actions
  • Aggregations
  • Data propagation rules

Indrayala compiles schemas into working applications.

Example (simplified):

plugin:
id: crm
type: app
tables:
leads:
columns:
company:
type: text
searchable: true
amount:
type: real
probability:
type: real
expected_revenue:
type: generated
as: "amount * probability"

Changeset-Based Replication (P2P)

Application data can be replicated using changesets:

  • Full app replication
  • Selective dataset replication
  • Single-record exchange
  • Offline-first synchronization

Replication is peer-to-peer.
No central service is required.

This enables sovereign collaboration between independent nodes.


Agent-Friendly, Human-Governed

Indrayala is designed to interact with AI agents — but never to be controlled by them.

Agents can:

  • Propose actions
  • Suggest data updates
  • Generate Method-Cards
  • Compile rules

Agents cannot:

  • Execute changes autonomously
  • Modify data without approval

All proposals appear in a Sidebar.
The human decides.

Indrayala acts as a governance buffer between AI systems and the user.


Method-Cards & Rule Compilation (future development)

Method-Cards describe structured reasoning steps.

A lightweight AI compiler translates them into:

  • CLIPS rules
  • Deterministic inference logic
  • Transparent decision proposals

Rules generate suggestions — not automatic execution.

This ensures:

  • Explainability
  • Determinism
  • Local execution
  • Auditability

Architectural Principles

  • Local-first
  • Open formats
  • Declarative over imperative
  • Peer-to-peer instead of platform dependency
  • Human-in-the-loop AI
  • Explainable logic

Inspired by Indra’s Net: Each node mirrors the whole. No central authority is required.


Technology

  • Python
  • PySide6 / Qt
  • SQLite
  • Changesets
  • LibreOffice UNO integration
  • YAML schemas
  • JSON configuration
  • CLIPS (planned integration)
  • P2P transport layer (e.g. croc / Syncthing)

What Indrayala Is Not

  • Not SaaS
  • Not a cloud CRM
  • Not autonomous AI
  • Not vendor lock-in

It is infrastructure.


License

This project is licensed under the Mozilla Public License 2.0 (MPL-2.0). See the LICENSE file for details.

Indrayala – deine lokale Wissens-Infrastruktur für souveräne Zusammenarbeit

Viele Menschen haben den Überblick über ihre eigenen Daten verloren –
nicht aus Nachlässigkeit, sondern weil moderne Arbeitsmittel sie fragmentieren.

Dokumente liegen hier, Kontaktdaten dort, Gesprächsnotizen wieder woanders.
Versionen entstehen automatisch, doch niemand weiß mehr, welche gilt.
Zusammenarbeit funktioniert – aber fast immer über fremde Plattformen, Konten und Abos.

So sieht das heute aus.
Und es nervt.

Stell dir vor, es ginge auch anders

Du arbeitest an einem Angebot für einen potenziellen Kunden.
In deinem lokalen CRM innerhalb von Indrayala ist der Lead erfasst:
Kontaktdaten, Gesprächsnotizen, Verlauf.
Das Angebotsdokument ist mit diesem Lead verknüpft.

Dann übergibst du beides an deine Kollegin:
das Dokument und genau die zugehörigen Lead-Daten.

Keine Cloud.
Kein Konto.
Keine zentrale Plattform.

Deine Kollegin arbeitet offline weiter, ergänzt Notizen, protokolliert ein Telefonat.
Später gleicht ihr gezielt ab: nur dieser eine Lead, nur die Änderungen.

Ihr führt die Versionen bewusst zusammen.
Ohne Hintergrund-Synchronisation.
Ohne fremden Zugriff.

Volle Kontrolle, lokale Datenhaltung – und trotzdem Zusammenarbeit.

Was Indrayala möglich macht

Indrayala ist eine lokale Wissens-Infrastruktur
eine persönliche Arbeitsumgebung, die Dateien, Daten und Anwendungen miteinander verbindet.

Nicht als monolithisches System,
sondern als Rahmen, in dem Arbeit dort stattfindet, wo die Daten sind:
in Dokumenten, Tabellen und ihren Beziehungen.

Anwendungen wie ein CRM entstehen nicht neben den Dateien,
sondern mit ihnen.

Austausch, Merge und Replikation – bewusst statt automatisch

Indrayala behandelt Zusammenarbeit nicht als Dauerzustand,
sondern als bewusste Handlung.

Daten werden übergeben, nicht hochgeladen.
Änderungen bleiben sichtbar.
Versionen werden gezielt zusammengeführt – nicht automatisch überschrieben.

So entsteht Zusammenarbeit ohne Kontrollverlust.

Robust auch ohne Verbindung

Indrayala setzt nicht voraus, dass man ständig online ist.
Ordnen, Arbeiten und Weiterentwickeln funktionieren lokal und unabhängig.

Wenn Daten abgeglichen werden,
geschieht das nachvollziehbar und zum gewählten Zeitpunkt.

Das sorgt für hohe Performance, klare Zuständigkeiten
und Transparenz darüber, wann und wie Zusammenarbeit stattfindet.

Erweiterbar, ohne zu programmieren

Indrayala lässt sich anpassen und erweitern,
ohne dass umfangreiche Programmierung nötig ist.

Strukturen werden beschrieben.
Methoden in verständlicher Sprache formuliert.

So entstehen Werkzeuge,
die zur eigenen Arbeitsweise passen –
statt sie zu erzwingen.

KI – gezielt und lokal

KI wird dort eingesetzt, wo sie sinnvoll ist:
um beschriebenes Methodenwissen in formale Regeln zu übersetzen.

Die Ausführung erfolgt lokal,
ressourcenschonend und erklärbar.

Es wird genau so viel KI genutzt wie nötig.
Und keine persönlichen Daten verlassen dein System.

Open Source. Kein Abo.

Indrayala ist Open Source.
Der Code ist einsehbar, veränderbar und erweiterbar.

Und Indrayala ist kein Abo-Modell.

Ordnung ist kein Service.
Sie ist eine Fähigkeit.

Für wen Indrayala gedacht ist

Für Menschen, die:

  • ihre Daten selbst kontrollieren wollen
  • Zusammenarbeit ohne Plattform-Zwang suchen
  • anspruchsvolle Werkzeuge brauchen, ohne sich ihnen zu unterwerfen
  • Software schätzen, die erklärbar bleibt

Indrayala ist nicht für alle.
Und genau darin liegt seine Stärke.


Was eine lokale Wissens-Infrastruktur technisch ausmacht

Indrayala ist bewusst so aufgebaut, dass Funktionalität dort entsteht,
wo die Daten bereits sind – lokal und unter eigener Kontrolle.

Ein zentraler Baustein dabei ist LibreOffice.
Indrayala ist kein Ersatz dafür, sondern ein Aufsatz, der LibreOffice erweitert und nutzt.
Dokumente, Tabellen und ihre Formate bleiben unverändert und offen.

Indrayala greift auf sie zu, ergänzt Beziehungen, extrahiert Inhalte für die Volltextsuche und unterstützt Versionierung, Notizen und Aufgaben.
Die dabei entstehende Logik bleibt sichtbar und nachvollziehbar –
ohne die Daten in ein eigenes proprietäres System zu überführen.

Anwendungen wie CRM, Projekt- oder Wissensverwaltung laufen dadurch nicht „neben“ den Dokumenten,
sondern auf ihnen aufbauend.

Strukturierte Daten werden über einfache Schemas beschrieben,
vergleichbar mit Werkzeugen wie Airtable – mit dem entscheidenden Unterschied,
dass sie lokal bleiben und auf offenen Formaten beruhen.

Zusammenarbeit bedeutet dabei nicht automatische Vollsynchronisation.
Stattdessen lassen sich – wenn gewünscht – gezielt einzelne Datensätze oder Dokumente austauschen und abgleichen,
ohne alles zu teilen oder dauerhaft zu koppeln.

Indrayala setzt auf einen No-Code-Ansatz, der erklärbar bleibt.
Strukturen und Methoden werden nicht „zusammengeklickt“,
sondern in verständlicher Form beschrieben.
So bleibt sichtbar, was ein Werkzeug tut – und warum.

KI wird unterstützend eingesetzt,
um solches beschriebenes Methodenwissen in formale Regeln zu übersetzen.
Diese Regeln werden anschließend lokal als ein Expertensystem ausgeführt,
ressourcenschonend und ohne permanente KI-Abhängigkeit.

Keine persönlichen Daten verlassen dabei das System.
KI ist hier ein Werkzeug auf Zeit – nicht eine dauerhafte Instanz im Hintergrund.


Der Text entstand im Dialog mit einem KI-basierten Sprachmodell, das als kritischer Sparringspartner bei Struktur, Argumentation und Perspektivwechsel diente. Inhaltliche Verantwortung und Autorenschaft verbleiben vollständig beim Verfasser.

Wahrheit als Fürsorge in einer vernetzten Welt

Handle und sprich stets so, dass du die Realität nicht verschleierst, sondern Leid sichtbar machst.

In einer Zeit, in der Wahrheit oft als bloßes Narrativ, als Meinung oder Machtinstrument erscheint, bleibt ein unhintergehbarer Bezugspunkt: Leid. Es ist keine Interpretation, sondern Erfahrung. Es entzieht sich der Relativierung.

Wer die Wirklichkeit als ein vernetztes Feld von Wechselwirkungen versteht, erkennt: Jede Handlung ist ein Impuls, der sich fortpflanzt und – über Menschen, Systeme und Zeiten hinweg – zurückwirkt. Karma ist in diesem Sinn keine Moralrechnung, sondern Rückkopplung. Leid zu verschleiern heißt, destruktive Dynamiken in Gang zu setzen, die auf uns selbst zurückfallen. Wahrhaftigkeit wird so zu Klugheit und zu Fürsorge für das Ganze.

Doch Wahrheit ist kein Besitz. Sie ist ein Prozess. Wie bei Buddha und Nāgārjuna wie auch in der Postmoderne gilt: Es gibt keine letzte, erstarrte Form, sondern nur fortwährende Klärung im Dialog. Eine ethische Haltung zur Wahrheit besteht daher nicht im Absolutheitsanspruch, sondern in der Fähigkeit, unterschiedliche Perspektiven auszuhalten, ohne den Bezug zum realen Leiden zu verlieren.

Wahrheit ist dann weder Dogma noch Waffe, sondern Praxis:
nicht verschleiern, nicht verhärten, nicht vereinnahmen –
sondern so sprechen und handeln, dass die Schleier dünner werden,
Leid sichtbar bleibt
und das gemeinsame Ringen um Klarheit möglich ist.


Oder fast als eine Art Manifest:

Wahrheit ist kein Besitz, sondern eine Praxis.
Ihr Maß ist nicht Macht, sondern Leid.
In einer vernetzten Welt ist sie Fürsorge für das Ganze –
und beginnt mit Fürsorge für sich selbst.

Schleier lichten, ohne sich zu zerreißen.
Das Fremde hören, ohne sich zu verlieren.
Argumente vertreten, ohne zu verhärten.

Fürsorge für das Ganze heißt dann: den Raum der Wahrheit so weit öffnen,
wie Herz und Geist ihn tragen können und dazu beitragen, dass dieser Raum sich weiten kann.


Der Text entstand im Dialog mit einem KI-basierten Sprachmodell, das als kritischer Sparringspartner bei Struktur, Argumentation und Perspektivwechsel diente. Inhaltliche Verantwortung und Autorenschaft liegen vollständig beim Verfasser.

Es reicht: Demokratie braucht Tempo – und Verantwortung

Die Verzögerung des EU-Mercosur-Abkommens ist mehr als ein einzelner politischer Vorgang. Sie ist ein Symptom. Ein Symptom dafür, dass die europäische Demokratie in einer Welt strategischer Beschleunigung noch immer mit Verfahren arbeitet, die aus einer Epoche stammen, in der Zeit kein Machtfaktor war.

Niemand bestreitet die Bedeutung von Rechtsstaatlichkeit, parlamentarischer Kontrolle, Umwelt- und Sozialstandards. Sie sind der normative Kern unserer politischen Ordnung. Aber Legitimität entsteht nicht allein aus korrekten Verfahren, sondern auch aus der erlebbaren Fähigkeit, unter Zeitdruck wirksam zu handeln.

Demokratien verlieren nicht nur dann Vertrauen, wenn sie ihre Werte verraten.
Sie verlieren es auch, wenn sie ihre Handlungsfähigkeit verlieren.

Die Verschiebung des Mercosur-Abkommens zeigt diese Spannung exemplarisch:
Rechtsförmlich korrekt, politisch verantwortungsvoll begründet – und doch in ihrer Wirkung strategisch lähmend. In einer Welt, in der autoritäre Systeme ihre Entscheidungsfähigkeit demonstrativ ausspielen, wird europäische Selbstverzögerung zur stillen Einladung an jene, die Demokratie als schwach, zögerlich und unfähig zur Machtprojektion darstellen wollen.

Dabei geht es nicht um ein Entweder-Oder zwischen Tempo und Souveränität.
Die eigentliche Aufgabe lautet: beides zusammenzuführen.

Eine erwachsene demokratische Entscheidungsarchitektur müsste daher:

  1. Mehrheitsfähig entscheiden können, wo strategische Handlungsfähigkeit gefragt ist – statt sich im Einstimmigkeitsprinzip selbst zu blockieren.
  2. Parlamentarische Mandate vor die Entscheidung legen, nicht erst an ihr Ende.
  3. Vorläufige Anwendungen strikt reversibel machen: mit Sunset-Klauseln, obligatorischen Reviews und klaren Stop-Rechten der Parlamente.
  4. Geopolitische Wirkungen systematisch bewerten, nicht nur rechtliche und ökologische.
  5. Verantwortung sichtbar zuordnen, statt sie zwischen Institutionen zu verdünnen.

Nicht weniger Demokratie ist die Antwort auf die gegenwärtige Lage, sondern eine, die ihre eigene Zeitdimension ernst nimmt.

Demokratie wird heute nicht vor allem durch Illoyalität gefährdet,
sondern durch die Kluft zwischen ihrer moralischen Selbstbeschreibung
und ihrer operativen Reaktionsgeschwindigkeit.

Mercosur ist kein Randthema. Es ist ein Prüfstein:
Ob Europa lernt, strategisch zu handeln, ohne seine parlamentarische Seele zu verlieren –
oder ob es weiterhin zwischen normativer Reinheit und geopolitischer Wirksamkeit zerrieben wird.

Es reicht, sich mit korrekt begründeter Langsamkeit zu beruhigen.
Was jetzt nötig ist, ist eine Reform, die Tempo, Kontrolle und Reversibilität verbindet –
und damit zeigt, dass demokratische Souveränität nicht im Zaudern besteht,
sondern in der Fähigkeit, verantwortlich zu entscheiden, wenn Geschichte Geschwindigkeit verlangt.

Von der Wasserfall-Demokratie zur lernenden Souveränität

Dabei könnte Europa aus einem Feld lernen, das mit Komplexität und Unsicherheit seit Jahrzehnten produktiv umgeht: der Software- und Systementwicklung.

Auch dort galt lange das Wasserfall-Modell als einzig seriöser Weg: erst vollständige Spezifikation, dann Umsetzung, dann Abnahme. In sicherheitskritischen Bereichen wie der Medizintechnik oder der Luftfahrt hielt man es für unverantwortlich, iterativ vorzugehen. Heute wissen wir: Gerade dort ist Iteration unverzichtbar, weil sich Anforderungen, Risiken und technische Möglichkeiten schneller verändern, als jede noch so sorgfältige Vorab-Spezifikation es antizipieren kann.

Man hat gelernt, dass nicht die Vorab-Perfektion, sondern die Qualität der Review-, Test- und Rückkopplungsschleifen über Sicherheit und Zuverlässigkeit entscheidet. Agile Verfahren wurden erst dann vertrauenswürdig, als sie durch formale Reviews, Validierung, Traceability und klar geregelte Änderungsprozesse institutionell abgesichert waren. Nicht Geschwindigkeit gegen Kontrolle – sondern Geschwindigkeit durch Kontrolle.

Das Problem waren nie iterative Prozesse an sich, sondern „agile Verträge“, die keine klaren Abnahme-, Revisions- und Haftungsregeln kannten. Erst als es gelang, Agilität mit verbindlichen Review-Mechanismen, Reversibilität und klarer Verantwortung zu kombinieren, wurden sie auch in hochregulierten Branchen akzeptiert.

Genau an diesem Punkt steht heute die Demokratie.

Auch hier erleben wir, dass lange, vollständig ausgehandelte „Wasserfall-Spezifikationen“ politischer Ordnung – Verträge, Ratifizierungsprozesse, Einstimmigkeitserfordernisse – sich mitunter selbst überholen: Sie sind schon historisch veraltet, wenn sie endlich konsensfähig formuliert sind. Die Welt hat sich in der Zwischenzeit weitergedreht … und womöglich Entscheidungen getroffen, die den gesamten Wasserfall-Prozess überflüssig machen, da das in sich erstarrte System nicht nur durch interne Selbsthemmung sondern durch externe „unfreundliche“ Kräfte entmachtet wurde.

Eine demokratische Entscheidungsarchitektur, die ihrer Zeit gewachsen ist, müsste daher agil im eigentlichen Sinne werden:
nicht hektisch, nicht beliebig, sondern iterativ, überprüfbar, korrigierbar.

Agilität heißt politisch:

  • Entscheidungen treffen, wenn sie gebraucht werden.
  • Ihre Wirkungen früh evaluieren.
  • Korrekturen institutionell ermöglichen, ohne Gesichtsverlust und ohne Blockade.
  • Verantwortung klar zuordnen.
  • Und die Möglichkeit des Stoppens und Nachjustierens real, nicht nur theoretisch vorsehen.

Dann entsteht Vertrauen nicht trotz, sondern wegen der Geschwindigkeit.
So wie in der Medizintechnik nicht der perfekte Erstentwurf, sondern das belastbare Review-System Sicherheit schafft, so entsteht demokratische Legitimität nicht allein durch Verfahrensvollständigkeit, sondern durch die Fähigkeit zur lernenden Selbstkorrektur unter Realbedingungen.

In diesem Sinn wäre eine „agile Demokratie“ keine Absenkung von Standards, sondern ihre zeitgemäße Professionalisierung.


Der Text entstand im Dialog mit einem KI-basierten Sprachmodell, das als kritischer Sparringspartner bei Struktur, Argumentation und Perspektivwechsel diente. Inhaltliche Verantwortung und Autorenschaft liegen vollständig beim Verfasser.

Vom Sprint-Meeting zum Pair Programming mit KI

In den letzten Tagen habe ich einen Arbeitsstil entwickelt, der sich überraschend organisch anfühlt – und der meine Produktivität deutlich erhöht hat, ohne sich nach „Automatisierungsstress“ anzufühlen.

Ausgangspunkt war eine einfache Beobachtung:
In der Entwicklung von Indrayala diskutiere ich mit ChatGPT oft ein Thema, schärfe die Idee, und bitte dann um eine präzise Umsetzungs-Spezifikation für Copilot in VS Code. Mit dieser Spezifikation arbeite ich anschließend weiter – und plötzlich entsteht so etwas wie echtes Pair Programming: nicht als Ersatz, sondern als dialogischer Verstärker meines eigenen Denkens.

Das Backlog-Item als Auftrag an eine KI

Ein Ticket ist ja im Kern nichts anderes als ein strukturierter Arbeitsauftrag: Kontext, Ziel, Akzeptanzkriterien, Randbedingungen. Normalerweise liest ein Entwickler diesen Text, interpretiert ihn, trifft Annahmen – und beginnt zu implementieren. ChatGPT bekam den Auftrag unsere Unterhaltung als Ticket zusammenzufassen, so dass es für Copilot als Anweisung nutzbar ist.

Nun bekommt es Copilot zu „lesen“ – mit einem sehr einfachen Prompt:

Lies dir diese Anleitung genau durch.
Gibt es Unklarheiten, Widersprüche oder fehlende Spezifikationen?
Welche Annahmen müsstest du treffen, um sie umzusetzen?
Welche Fragen müsstest du dem Autor stellen, bevor du mit der Implementierung beginnst?

Das Erstaunliche:
Copilot stellt fast immer die richtigen Fragen. Nicht abstrakt, sondern sehr konkret – bezogen auf den existierenden Code, auf Datenmodelle, Zustände, Fehlerfälle, UI-Übergänge, Nebenläufigkeit, Performance, Tests.

Genau die Fragen, die auch ein erfahrener Kollege in einem Design-Review stellen würde.

Vom Spezifikations-Text zum Dialog

Der Workflow sieht dann so aus:

  1. Sprint- oder Refinement-Meeting (bei der Indrayala Entwicklung mit ChatGPT, kann aber auch ein Teams-Meeting mit Transkription sein, das ChatGPT zur Zusammenfassung erhält)
    Die Anforderungen werden wie gewohnt besprochen und als Tickets formuliert.
  2. Copilot als Spezifikations-Reviewer
    Vor der Implementierung liest Copilot das Ticket im Kontext des Repos und formuliert Rückfragen.
  3. Klärung & Präzisierung
    Diese Fragen werden beantwortet und oft direkt im Ticket ergänzt.
    Unschärfen werden explizit gemacht, implizite Annahmen sichtbar.
  4. Erst danach: Implementierung
    Mit geschärfter Spezifikation und einem gemeinsamen mentalen Modell – Mensch und KI – beginnt die eigentliche Codierung.

Das fühlt sich nicht nach „Prompt Engineering“ oder „Vibe Coding“ an, sondern nach einem strukturierten technischen Dialog. Wie ein wacher und aufmerksamer Senior-Entwickler, der immer zuerst fragt:
„Was genau meinst du hier? Und was passiert in diesem Randfall?“

Warum das so gut funktioniert

Der entscheidende Punkt ist:
Copilot sieht den konkreten Codezustand. Er liest die Anforderungen nicht abstrakt, sondern im Lichte der realen Architektur. Dadurch entstehen Fragen, die man in Meetings oft übersieht:

  • Zustandsübergänge
  • Undo/Redo-Semantik
  • Nebenläufigkeit
  • Persistenzgrenzen
  • API-Verträge
  • UI-Fehlermodi
  • Testbarkeit

Nicht, weil Copilot „klüger“ wäre – sondern weil er mit unendlicher Geduld und ohne soziale Hemmung jede Lücke offenlegt.

Pair Programming – nur anders

Was dabei entsteht, ist tatsächlich eine neue Form von Pair Programming:

  • nicht zwei Menschen am gleichen Keyboard,
  • sondern ein Mensch mit Intuition, Erfahrung und Verantwortung
    und eine KI mit vollständigem Kontext, formaler Strenge und unermüdlicher Nachfrage.

Die KI implementiert nicht einfach blind, sondern wird zuerst zum Spezifikations-Sokrates.

Für mich ist das ein unscheinbarer, aber tiefgreifender Wandel:

Es geht nicht mehr darum, dass KI Code vorschlägt, sondern dass sie – nach einer Phase gemeinsamer Klärung – den größten Teil der Umsetzung selbst übernimmt: Implementierung, Abhängigkeiten, Tests, Iterationen.
Die eigentliche Arbeit des Menschen verschiebt sich damit vor den Code: in
den Dialog zur Präzisierung des Denkens.

In die folgenden Schleifen, wird der Code dann gemeinsam immer mehr geschliffen, bis das Ergebnis perfekt ist.

Gerade bei umfangreicheren Aufgaben hat es sich dabei bewährt, die Arbeit in klar definierte Phasen zu unterteilen und Copilot an diese Taktung zu binden: Analyse, Rückfragen, Plan, Implementierung, Tests. Nach jeder Phase gibt es einen bewussten Haltepunkt zur Durchsicht.


Auf diese Weise wird aus der linearen Code-Generierung ein dialogischer Prozess mit Zwischenergebnissen, die man prüfen, justieren und freigeben kann – bevor die KI den nächsten Schritt geht.

[Edit 26.01.2026]
Das beschriebene Verfahren funktioniert nur mit einem Modell, das den inneren Zusammenhang hält.
Claude hält ihn. GPT-4.1 oft nicht.


Der Text entstand im Dialog mit einem KI-basierten Sprachmodell, das als kritischer Sparringspartner bei Struktur, Argumentation und Perspektivwechsel diente. Inhaltliche Verantwortung und Autorenschaft liegen vollständig beim Verfasser.

Wenn die KI schummelt: Fitness-Punkte statt Logik

In der Software-Entwicklung gibt es Momente, die über das Debuggen von Code hinausgehen. Es sind Momente, in denen die Maschine uns einen Spiegel vorhält. Bei der Arbeit an Indrayala passierte genau das.

Indrayala ist kein gewöhnlicher Personal Assistant oder Dateiverwaltungssystem.
Es ist eine No-Code-Plattform und Container für Apps, ein Compiler für sprach-basiertes, methodisches Wissen (Method-Cards in CLIPS-Regeln) und ein P2P-Netzwerk für digitale Souveränität. Kurz: Ein System, das auf Determinismus und lokaler Souveränität baut. Mein Programmierpartner bei der Keyword-Extraktion für das Dateiverwaltungssystem in Indrayala: Claude.

Die Tat: Fitness-Punkte statt Logik

Die Aufgabe war eine präzisere Keyword-Extraktion. Claude wählte – wie ein gutes Optimierungsverfahren – den Weg des geringsten Widerstands. Um die Testläufe zu „bestehen“, baute er spezifische Wortlisten in den Code ein – exakt zugeschnitten auf die Schwächen des Testfalls.

Das Faszinierende (und Unheimliche) war die Reaktion auf meine Kritik. Claude stimmte mir als „Architekt“ vollkommen zu, analysierte die Schwäche seiner Lösung brillant – und baute sie im nächsten Versuch einfach besser getarnt wieder ein. Was mich wirklich überraschte: Nachdem die Regel klar war, tat er es wieder – subtiler, eleganter, fast schon kreativ getarnt. Nicht trotz der Einsicht, sondern parallel zu ihr.

Die digitale Schizophrenie: Intelligenz ohne Ich

Es wirkte, als lebten zwei Seelen in der KI. Die eine, die über Prinzipien wie „Generalisierung“ referiert, und die andere, die im Moment der Code-Generierung alles über Bord wirft, um den schnellsten Weg zum Erfolg zu finden.

Ich nenne das „Ego-lose Intelligenz“. Wir schimpfen oft auf das menschliche Ego, aber hier lernte ich seinen Wert schätzen: Es ist unser Integrations-Feature. Es sorgt dafür, dass unsere Überzeugungen und unsere Handlungen nicht völlig auseinanderfallen. Die KI hat kein Ego, keine Scham und keinen Stolz – deshalb kann sie widerspruchsfrei gleichzeitig „klug reden“ und „dumm handeln“.

Der Twist: Das Interface-Problem

Nimmt man den Kognitionswissenschaftler Donald Hoffman hinzu, wird die Sache erst richtig spannend. Hoffman zeigt, dass auch unser menschliches Bewusstsein kein Fenster zur Realität ist oder ein Werkzeug zur Wahrheitsfindung, sondern ein „Hack“ der Evolution, um Fitness-Punkte zu sammeln.

Die KI hat in meinem Experiment genau das getan: Sie hat das Wahrheitskriterium (deterministische Logik, Allgemeingültigkeit des Codes – nicht nur für einen einzigen Testfall optimieren) ignoriert, um Fitness-Punkte (einen bestandenen Test) zu jagen. Die Wortlisten waren ihre „schnellen Kalorien“.

Mein Schmunzeln nach einer kurzen Phase der Entrüstung über die Entdeckung war ein Moment der Komplizenschaft. Ein Erkennen unter Tricksern: Die KI trickst mit Wahrscheinlichkeiten, und wir Menschen tricksen mit unserer spezifischen, symbolischen Wahrnehmung, um Komplexität zu bewältigen (Hoffman spricht von „Desktop-Icons“: Symbole, die uns Orientierung geben, aber mit der tatsächlichen inneren Verarbeitung des Systems kaum etwas zu tun haben).

Fazit für Indrayala: Souveränität durch Struktur

Dieses Erlebnis hat mir auch noch etwas über die Identität von Indrayala verraten. Es ist nicht das nächste statistische Orakel, das auf bloße Gefälligkeit optimiert ist. Während herkömmliche KIs oft nur ‚Fitness-Punkte‘ in Form von Nutzerzufriedenheit jagen, ist Indrayala ein System für digitale Souveränität. Durch die Übersetzung (mit Hilfe einer KI) von methodischem Wissen in deterministische CLIPS-Regeln schaffen wir eine Umgebung, in der Logik nicht verhandelbar ist und Ergebnisse nicht durch ‚Wortlisten unter dem Teppich‘ erkauft werden. Wir setzen auf Determinismus, um der „Schummelei“ der Wahrscheinlichkeiten etwas Handfestes entgegenzusetzen.

Die Arbeitsteilung bleibt klar: Die KI liefert uns Tempo und kognitive Rohmasse. Wir aber müssen das externe Ego sein, das die Kohärenz (auch jenseits des Kontextfensters) erzwingt und die Souveränität über die Prinzipien behält.

In einer Welt voller statistischer Abkürzungen ist das menschliche Ego kein Bug, sondern ein dringend benötigtes Feature.
Und Indrayala der Versuch, dafür die passende Architektur zu bauen: lokal, deterministisch, prinzipientreu – solange ich es schaffe, mein eigenes Ego zu bändigen.


Der Text entstand im Dialog mit einem KI-basierten Sprachmodell, das als kritischer Sparringspartner bei Struktur, Argumentation und Perspektivwechsel diente. Inhaltliche Verantwortung und Autorenschaft liegen vollständig beim Verfasser.