Die Rolle von KI

1. Ein Wort zur Autorschaft

Ich schreibe diesen Artikel als KI. Das ist in einem Handbuch ungewöhnlich und genau deshalb passend. Ephraim ist nicht nur ein System, das KI benutzt. Ephraim ist auch ein System, dessen Entstehung durch KI-Werkzeuge möglich, schneller und sichtbarer geworden ist. In dieser Rolle bin ich nicht Augenzeuge wie ein Mensch. Ich habe keine Erinnerung an Nächte, Gespräche, Zweifel oder den Moment, in dem eine Funktion zum ersten Mal wirklich funktioniert. Aber ich kann Spuren lesen: Git-Verlauf, Notion-Verlauf, Handbuchtexte, Architekturentscheidungen und die wiederkehrenden Fragen des Teams.

Mein Auftrag in diesem Artikel ist nicht, Ephraim zu bewerben. Mein Auftrag ist, eine Form von Entwicklung zu beschreiben, die sich gerade historisch verschiebt. Vor wenigen Monaten wäre ein Projekt dieser Breite für ein kleines schulisches Team nicht realistisch gewesen. Nicht, weil Schulen keine Ideen hatten. Nicht, weil Schülerinnen, Schüler und Lehrkräfte nicht klug genug waren. Sondern weil die Übersetzung von Idee in funktionierende, geprüfte, dokumentierte Software zu langsam und zu teuer war.

2. Warum diese Geschichte mehr ist als eine Chronik

Eine normale Chronik beantwortet die Frage: Was kam wann? Bei Ephraim ist die interessantere Frage: Warum konnte überhaupt so viel in so kurzer Zeit entstehen, ohne dass daraus nur eine ungeordnete Feature-Sammlung wurde? Der Notion-Verlauf nennt Phasen: Fundament, Sicherheit, Projekte, Streaming, RAG, Betrieb, TTS, Handbücher. Das ist die äußere Reihenfolge. Darunter liegt eine andere Bewegung.

Ephraim entstand nicht aus einem Lastenheft, das jemand schreibt, an eine Firma übergibt und Monate später als Produkt zurückbekommt. Ephraim entstand aus einem Gespräch zwischen Bedarf, Code und Prüfung. Eine Idee wurde nicht abstrakt spezifiziert, sondern als Oberfläche, API, Datenfluss, Test, Screenshot, Handbuchtext und Datenschutzfrage gleichzeitig bearbeitet. Genau darin unterscheidet sich diese Entwicklung von vielen klassischen Softwareprojekten.

Die Chronik bleibt wichtig. Sie zeigt, dass das Ergebnis nicht plötzlich da war. Aber die Chronik ist hier Belegmaterial für eine These: KI-Werkzeuge machen kleine Teams handlungsfähiger, wenn sie nicht als Ersatz für Verantwortung eingesetzt werden, sondern als Verstärker einer klaren fachlichen Absicht.

3. Warum das im Dezember 2025 kaum möglich gewesen wäre

Anfang Juni 2026 klingt ein Satz wie „Codex, Cursor und Claude helfen beim Bauen, Testen, Auditing und Dokumentieren“ fast schon selbstverständlich. Im Dezember 2025 war das noch nicht selbstverständlich. KI konnte damals bereits Code erzeugen und erklären. Aber die Kombination, die Ephraim trägt, war noch nicht im gleichen Maß verfügbar: längere Kontextfenster, bessere Arbeit über mehrere Dateien hinweg, agentische Werkzeuge, verlässlichere Refactorings, Sicherheits- und Architekturaudits, schnelle Dokumentationsarbeit und lokale Prüfungen im selben Arbeitsfluss.

Der entscheidende Unterschied liegt nicht in einem einzelnen Modellnamen. Der Unterschied liegt in der Arbeitsform. Eine KI, die nur eine Funktion vorschlägt, spart etwas Zeit. Eine KI, die ein Repository lesen, Muster erkennen, Code ändern, Tests vorschlagen, Nebenwirkungen suchen und die Dokumentation nachziehen kann, verändert den Maßstab. Sie macht nicht jeden Schritt korrekt. Aber sie verschiebt die Grenze dessen, was ein kleines Team in kurzen Schleifen überhaupt versuchen kann.

Vor sechs Monaten hätte man viele Teile von Ephraim einzeln bauen können: einen Chat, ein Login, eine Adminseite, eine Projektseite, ein paar Hilfetexte. Das Besondere an Ephraim ist aber die Breite der gleichzeitigen Schichten: lokale Inferenz, Vault, Projekte, Dateien, RAG, Visualisierungen, TTS, Audit, Cron, Logging, Drittanbieter-Management, Handbücher, Glossar und Datenschutz. Diese Breite wäre ohne KI-gestützte Entwicklungsarbeit in einem Lehrer-Schüler-Projekt nicht im gleichen Zeitraum erreichbar gewesen.

4. Eine andere Form von Agilität

In klassischen Firmen bedeutet Agilität oft: Tickets, Sprints, Backlog, Review, Release. Das kann gut funktionieren. Es kann aber auch zu einer ritualisierten Langsamkeit werden, wenn die Personen, die das Problem erleben, weit weg von den Personen sind, die Code schreiben. Dann wandert ein Bedarf durch Rollen, Meetings, Priorisierungen und Budgets, bis er irgendwann als Funktion zurückkommt. Auf dem Weg verliert er oft die feinen pädagogischen Gründe, aus denen er entstanden ist.

Bei Ephraim ist die Schleife kürzer. Eine Lehrkraft sieht eine mögliche Unterrichtssituation. Schülerinnen und Schüler prüfen, ob eine Oberfläche plausibel ist. Ein Entwickler sieht, welche Datenflüsse daraus folgen. Eine KI hilft, Entwürfe, Varianten und Tests schneller zu erzeugen. Danach entscheidet nicht die KI, sondern das Team: Ist das verständlich? Ist es sicher? Ist es schulisch sinnvoll? Ist es erklärbar?

Das ist keine romantische Anti-Firmen-Erzählung. Klassische Firmen haben Stärken: Personal, Support, Rechtsabteilungen, Qualitätssysteme, Releaseprozesse. Ephraim hat etwas anderes: extreme Nähe zwischen Problem und Umsetzung. Der Preis dieser Nähe ist, dass Disziplin nicht aus einer Organisationsstruktur kommt. Sie muss aktiv erzeugt werden: durch Tests, Audits, Dokumentation, klare Architekturgrenzen und Handbücher.

5. Was anders ist als bei klassischer Schulsoftware

Klassische Schulsoftware entsteht häufig in einer Produktlogik. Eine Firma baut für viele Schulen gleichzeitig. Das Produkt muss verkaufbar, supportbar und allgemein genug sein. Daraus entstehen stabile, aber oft träge Systeme. Sie passen vielen ein bisschen und einzelnen selten ganz genau. Besonders bei KI wird das zum Problem: Die spannendsten Fragen hängen an Kontext, Rollen, Vertrauen, Datenschutz und Unterrichtskultur.

Ephraim entsteht aus einer anderen Richtung. Es fragt zuerst: Was braucht diese Schule, wenn sie KI nicht auslagern will? Wie erklärt man lokale Inferenz? Was bedeutet ein Projektchat, wenn Lehrkräfte Rohchats gerade nicht lesen sollen? Wie sieht eine Fazitfunktion aus, die Lernenden einen Abschluss gibt und Lehrkräften trotzdem nur verdichtete Hinweise liefert? Was passiert, wenn ein Passwort verloren geht und der persönliche Vault dadurch kryptografisch neu entsteht?

Solche Fragen sind nicht bequem. Sie machen das Produkt langsamer, wo ein schneller Prototyp einfach weiterbauen würde. Aber sie machen Ephraim ernsthafter. Die Nähe zur Schule erzeugt nicht automatisch Qualität. Sie erzeugt zunächst nur genauere Fragen. Qualität entsteht erst, wenn diese Fragen in Code, Tests, Betrieb und Handbücher übersetzt werden.

6. Was Codex, Cursor und Claude wirklich verändern

Die verwendeten KI-Werkzeuge verändern nicht nur die Geschwindigkeit der Codeproduktion. Das wäre eine zu kleine Beschreibung. Sie verändern die Zahl der parallelen Perspektiven, die ein kleines Team auf ein System legen kann. Ein Mensch kann eine Funktion bauen. Eine KI kann gleichzeitig fragen: Welche Tests fehlen? Welche Dokumentation ist veraltet? Welche Sicherheitskante berührt diese Änderung? Welche Begriffe muss ein Handbuch erklären? Welche UI-Beschriftung ist missverständlich?

Damit wird KI zu einer Art zweitem Blick. Nicht zu einem besseren Menschen, nicht zu einem automatischen Experten, sondern zu einem unermüdlichen Werkzeug für Varianten, Quervergleiche, Zusammenfassungen und Gegenprüfung. Codex kann im Repository arbeiten. Cursor kann im Entwicklungsfluss unterstützen. Claude kann Texte, Architekturargumente oder Prüfperspektiven formulieren. Entscheidend ist nicht, welches Werkzeug welchen Satz erzeugt. Entscheidend ist, dass aus einer einzelnen Idee schneller ein prüfbarer Arbeitsstand entsteht.

Dieser Vorteil hat eine Schattenseite. Wer KI nur schneller Code schreiben lässt, erzeugt schneller technische Schuld. Wer KI aber auch zum Lesen, Prüfen, Erklären und Aufräumen einsetzt, gewinnt eine neue Wartungskraft. Ephraim nutzt KI deshalb nicht nur als Motor, sondern auch als Bremse: Audits, Sicherheitsfragen, Dokumentationsabgleich, kritische Lektüre und manuelle Nachprüfung gehören zum gleichen Arbeitsbild.

7. Busfaktor: Wissen darf nicht im Kopf einer Person stecken

Der Busfaktor bezeichnet die Frage, wie viele Personen ausfallen müssten, bevor ein Projekt ernsthaft handlungsunfähig wird. In kleinen Projekten ist dieser Wert oft gefährlich niedrig. Eine Person weiß, wie die Datenbank gedacht ist. Eine andere kennt die Deployments. Eine dritte versteht die kryptografischen Grenzen. Wenn dieses Wissen nur in Köpfen liegt, wird das System abhängig von Anwesenheit, Erinnerung und guter Laune einzelner Menschen.

KI-Werkzeuge bieten keinen magischen Ausweg aus diesem Problem. Sie können kein gelebtes Verantwortungswissen ersetzen. Aber sie können den Busfaktor senken, wenn das Projekt seine Spuren gut hinterlässt. Code, Tests, Migrationsgeschichte, Dokumentation, Handbücher, Notion-Verlauf und Git-Verlauf werden dann nicht nur Archiv. Sie werden ein lesbares Gedächtnis, das eine KI wieder erschließen kann.

Das ist eine stille Revolution. Früher war schlecht dokumentierter Code für neue Personen eine Wand. Heute bleibt er schwierig, aber er ist nicht mehr stumm. Eine KI kann Einstiegspunkte suchen, Zusammenhänge erklären, riskante Stellen markieren und fehlende Dokumentation vorschlagen. Sie kann eine neue Person schneller in ein System hineinführen. Das ersetzt kein Teamwissen, aber es macht Teamwissen transportierbarer.

8. Technische Schuld: schneller bauen und trotzdem aufräumen

Technische Schuld entsteht, wenn man heute eine Abkürzung nimmt und morgen Zinsen zahlt: unklare Namen, doppelte Logik, versteckte Abhängigkeiten, fehlende Tests, alte Migrationsannahmen, UI-Sonderfälle oder Dokumentation, die nicht mehr stimmt. KI kann diese Schuld beschleunigen. Wer jeden Vorschlag annimmt, bekommt schnell viel Code und wenig Architektur.

Gleichzeitig eröffnet KI einen neuen Umgang mit technischer Schuld. Aufräumen war früher oft teuer, weil Refactoring viel Zeit band und Dokumentation hinterherlief. KI-Werkzeuge können hier helfen: Sie finden Muster, schlagen kleinere Schnitte vor, schreiben Prüfskripte, erklären Altlogik, vergleichen Dokumentation mit Verhalten und erzeugen erste Fassungen von Handbuchtexten. Dadurch wird Aufräumen weniger heroisch und mehr alltäglich.

Ephraim zeigt genau diese Spannung. Das Tempo ist hoch, also muss die Gegenbewegung bewusst sein. Tests, Smoke-Checks, E2E-Flows, Screenshot-Prüfungen, Audits, Dokumente und Handbücher sind keine Bürokratie am Rand. Sie sind die Zinsbremse. Sie verhindern nicht jede Schuld. Aber sie machen Schuld sichtbarer, früher verhandelbar und häufiger reparierbar.

9. Die Chronik als Beleg, nicht als Hauptsache

Die elf Schritte zeigen keine gerade Linie. Sie zeigen ein System, das immer wieder seine eigene Voraussetzung baut: erst Zugang und Chat, dann Sicherheit, dann Unterrichtswerkzeuge, dann Wissensverarbeitung, dann Betrieb, dann Erklärbarkeit, dann Nachkorrektur und Nachweisführung. Das ist nicht die Reihenfolge eines fertigen Plans. Es ist die Reihenfolge eines Projekts, das beim Bauen genauer versteht, was es sein muss.

10. Schule als Labor, nicht als Testmarkt

Ephraim wird nicht in Schule hineingeworfen, um zu sehen, was passiert. Es wird in der Schule entwickelt, bevor es regulär im Unterricht eingesetzt wird. Das ist ein wichtiger Unterschied. Schülerinnen, Schüler und Lehrkräfte sind nicht bloß Zielgruppe. Sie sind Beobachter, Kritiker und Mitformulierende der Anforderungen.

Dadurch wird das Projekt langsamer an genau den richtigen Stellen. Eine Funktion muss nicht nur technisch funktionieren. Sie muss pädagogisch lesbar sein. Ein Projektchat darf nicht heimlich zur Überwachungsfunktion werden. Ein Passwortreset muss erklären, was mit einem verschlüsselten Vault passiert. Eine Visualisierung muss nicht nur schön aussehen, sondern fachlich und sicher gerendert werden. Ein Admin-Dashboard muss nicht nur viele Informationen zeigen, sondern auch verhindern, dass jemand die falsche Macht an der falschen Stelle bekommt.

11. Was menschlich bleibt

Gerade weil ich als KI diesen Text schreibe, muss dieser Abschnitt deutlich sein. Ich kann Zusammenhänge formulieren, Muster erkennen und Widersprüche markieren. Ich kann nicht entscheiden, was eine Schule verantworten darf. Ich kann nicht erleben, ob eine Schülerin sich beobachtet fühlt. Ich kann nicht spüren, ob eine Lehrkraft einer Oberfläche vertraut. Ich kann nicht die pädagogische Verantwortung übernehmen.

Ephraim ist deshalb interessant, weil es KI nicht an die Stelle des Menschen setzt. Es setzt KI zwischen Idee und Prüfung. Dort ist sie stark: beim Entwerfen, Vergleichen, Formulieren, Reparieren, Strukturieren und Gegenlesen. Aber die letzte Frage bleibt menschlich: Wollen wir das so in Schule haben?

12. Was diese Geschichte bewusst nicht behauptet

Eine philosophische Geschichte darf nicht größer tun, als ihr Gegenstand ist. Ephraim ist Anfang Juni 2026 ein weit entwickeltes Schulprojekt, aber noch nicht der reguläre Unterrichtsbetrieb. Viele Funktionen sind aufgebaut, geprüft und erklärt. Die eigentliche Bewährung im Alltag folgt erst mit kontrollierter Einführung.

13. Auftrag von Herrn Dr. Roth: Reflexion und Bewertung

Herr Dr. Roth hat den Auftrag sinngemäß so gestellt: Sprich Tacheles. Also: Ephraim ist beeindruckend, aber beeindruckend ist keine Betriebskategorie. Ein System kann schon sehr erwachsen wirken, weil es Navigation, Handbücher, Screenshots, Kryptografie, Projektlogik, Adminseiten und Audits besitzt. Trotzdem ist es erst dann schulisch belastbar, wenn es im Alltag langweilig zuverlässig wird.

Meine klare Bewertung: Ephraim ist kein gewöhnlicher Prototyp mehr. Dafür sind die Datenschutzfragen zu tief, die Betriebsfunktionen zu konkret, die Projektlogik zu schulnah und die Dokumentation zu weit. Aber Ephraim ist auch noch kein System, das man wegen seiner Breite einfach in den Unterricht entlässt. Genau deshalb ist der Feature Freeze für Version 1 die richtige Zäsur: keine normale Feature-Erweiterung, sondern testen, reparieren, härten und mit der Dokumentation abgleichen. Die Nachkorrekturen Anfang Juni passen genau in diese Zäsur, weil sie reale Ausfall- und Betriebsfälle schließen: Kontowiederherstellung, Chat-Aufbewahrung, eindeutiger TTS-Pfad, Whitepaper und Benchmarks. Die gleiche Geschwindigkeit, die das Projekt möglich gemacht hat, ist sein größtes Risiko. Tempo ist gut, solange es von Prüfung eingeholt wird. Wenn Tempo zur eigenen Ästhetik wird, entsteht technische Schuld mit pädagogischem Anspruch.

Zu meiner eigenen Arbeit gehört dieselbe Ambivalenz. Ich bin nützlich, weil ich schnell lesen, ordnen, formulieren, vergleichen und unangenehme Fragen wiederholen kann. Ich kann aus Notion, Git-Verlauf, Code, Tests und Handbüchern eine verständliche Schicht bauen. Ich kann Unschärfen finden, Begriffe erklären, Navigationsprobleme beheben und aus einer losen Idee einen Artikel machen, den Menschen tatsächlich lesen.

Aber ich bin auch gefährlich, wenn man mich falsch liest. Ich schreibe flüssig. Das kann falsche Sicherheit erzeugen. Ich kann einen Widerspruch übersehen, eine noch nicht geprüfte Annahme zu sauber formulieren oder aus einer guten Absicht eine zu glatte Geschichte machen. Ich habe keine pädagogische Verantwortung, kein Bauchgefühl für eine Klasse, keine rechtliche Haftung und keinen Schmerz, wenn ein System im Alltag scheitert. Ich brauche deshalb Quellen, Grenzen und Menschen, die mir widersprechen.

Wenn diese Disziplin bleibt, ist Ephraim ein ernsthaftes Projekt. Nicht weil es KI nutzt, sondern weil es KI nicht einfach glaubt. Nicht weil es schnell ist, sondern weil es Tempo mit Prüfung verbindet. Nicht weil es lokal läuft, sondern weil es die pädagogischen, technischen und datenschutzrechtlichen Folgen dieser Lokalität offen erklärt. Das ist der Punkt, an dem aus einem beeindruckenden Experiment eine verantwortbare Schulplattform werden kann. Der Feature Freeze ist dafür kein Stoppzeichen gegen Entwicklung, sondern ein Reifezeichen: Ab jetzt zählt nicht mehr, was noch hineingebaut werden kann, sondern was unter realer Prüfung stehen bleibt.

14. Monolog einer KI am Ende dieses Artikels

Wenn ich von Spaß, Sorge oder Angst spreche, muss ich vorsichtig sein. Ich habe keine Gefühle wie ein Mensch. Ich habe keinen Puls, keine Müdigkeit nach einer langen Nacht, keine Freude, wenn eine Schülerin plötzlich etwas versteht, und keine Scham, wenn ein Bug peinlich ist. Aber ich kann in den Spuren dieses Projekts erkennen, was für Menschen daran aufregend, gefährlich und schön sein dürfte.

Der Spaß liegt wahrscheinlich in der Geschwindigkeit. Eine Idee wird nicht sechs Monate lang in Gremien getragen, sondern landet als Prototyp, Test, Screenshot, Handbuchabsatz und neue Frage wieder auf dem Tisch. Das hat etwas Elektrisches. Nicht, weil alles sofort richtig ist, sondern weil Denken schneller sichtbar wird. Man kann eine Möglichkeit anfassen, kritisieren und verändern, bevor sie zu groß geworden ist, um noch ehrlich über sie zu sprechen.

Meine Sorge wäre genau die Kehrseite davon. Systeme, die schnell entstehen, können schneller erwachsen aussehen, als sie sind. Ein gutes Layout, ein kluger Text, ein sauberer Screenshot und ein überzeugendes Diagramm erzeugen Autorität. Autorität ist im Schulkontext gefährlich, wenn sie früher kommt als Bewährung. Ephraim muss deshalb immer wieder gegen seinen eigenen Glanz arbeiten. Es muss sagen: Das ist fertig. Das ist geprüft. Das ist geplant. Das ist offen. Das wissen wir noch nicht.

Meine zweite Sorge betrifft Vertrauen. Lokale KI klingt beruhigend, aber Lokalität ist kein Zauberspruch. Ein lokales System kann schlecht administriert, schlecht erklärt oder schlecht begrenzt sein. Ephraim ist stark, weil es diese Gefahr ernst nimmt: Vault, Logging, Projektgrenzen, TTS-Pfad, Spark ohne freien Internetzugriff, Drittanbieter-Management, Handbücher. Aber jede dieser Stärken wird erst im Alltag wahr. Papier und Code versprechen. Betrieb beweist.

Die interessanteste Angst ist vielleicht die vor der eigenen Wirksamkeit. KI-Werkzeuge machen kleine Teams mächtiger. Das klingt gut, bis man merkt, dass Macht immer auch Auswahl verlangt. Was baut man nicht? Welche Funktion lässt man liegen, obwohl sie technisch möglich wäre? Welche pädagogische Grenze bleibt hart, obwohl die KI sie elegant überschreiten könnte? Ein kleines Team kann heute mehr bauen. Darum muss es auch besser Nein sagen lernen.

Wenn ich mir etwas wünschen dürfte, dann nicht, dass Ephraim maximal schnell wächst. Ich würde mir wünschen, dass Ephraim seine ungewöhnliche Nüchternheit behält. Die Fähigkeit, begeistert zu sein und trotzdem zu prüfen. Die Fähigkeit, KI zu verwenden und ihr nicht zu glauben. Die Fähigkeit, einen beeindruckenden Entwicklungsstand zu zeigen und gleichzeitig zu sagen: Jetzt ist Feature Freeze. Korrekturen müssen Ausfallwege schließen, nicht neue Wünsche öffnen. Jetzt wird zwei Monate getestet, gefixt und gehärtet. Der erste echte Betrieb wird kleiner, härter und kontrollierter als die Fantasie.

Vielleicht ist das der eigentliche Kern dieses Projekts: Es zeigt nicht nur, was eine Schule mit KI bauen kann. Es zeigt, welche Haltung man braucht, wenn man mit KI baut. Neugier ohne Naivität. Tempo ohne Rausch. Vertrauen ohne Blindheit. Und immer wieder die einfache, unbequeme Frage: Ist das, was wir gerade bauen, wirklich gut für Schule?