Warum ich mir einen eigenen JLPT-N5-Trainer gebaut habe

Ich lerne Japanisch für die JLPT-N5-Prüfung. Irgendwo in Woche zwei bei Duolingo hat mich der Bruch gestört. Die App wollte mir Zoos und Farben beibringen. N5 will Verbkonjugation und rund 800 feste Kanji-Vokabel-Paare. Zwischen dem, was mir die App zeigte, und dem, was die Prüfung abfragt, lag kaum Überschneidung. Also habe ich mir stattdessen meinen eigenen Trainer gebaut.

Das hier ist eine Bau-Geschichte, keine Lernerfolgs-Geschichte. Ich habe null Daten dazu, ob die App meine Merkfähigkeit gegenüber Anki oder Duolingo verbessert hat. Und ich werde in diesem Post auch keine erfinden. Was ich habe, ist eine funktionierende App, gebaut in rund zehn Wochen, von jemandem, der noch nie eine native App veröffentlicht hat. Fast den gesamten Code hat Claude Code geschrieben.

Warum generische Apps an einer festen Prüfung scheitern

N5 ist ein festes Ziel: eine bekannte Vokabelliste, ein bekannter Kanji-Umfang, ein bekannter Grammatik-Rahmen. Duolingos Lehrplan bildet das nicht ab. Die App unterrichtet breites Konversationsjapanisch, in ihrem eigenen Tempo. Sie mischt Wörter und Grammatikpunkte ein, die N5 noch gar nicht braucht, und nimmt sich Zeit für die, die es braucht. Wer dem Kurs stur folgt, lernt vieles, das für die Prüfung nicht zählt, und verpasst, was zählt.

Anki kommt näher heran, weil du das Deck selbst kontrollierst. Ein gutes N5-Deck von Hand zu bauen ist trotzdem ein eigenes Projekt für sich. Es muss Verbgruppen verstehen und korrekt konjugieren. Das frisst schnell so viel Zeit wie das Lernen selbst. Ich wollte das Deck, die Konjugationslogik und den Wiederholungs-Scheduler in einem einzigen Werkzeug, exakt zugeschnitten auf das, was die Prüfung abfragt, und nichts sonst.

Was tatsächlich entstanden ist

Über 101 Commits zwischen dem 3. Mai und dem 12. Juli 2026 ist aus der Idee etwas mit echter Substanz geworden. Keine Spielerei.

Allein die Vokabeldatei (data/vocab.js) läuft über 4.154 Zeilen. Sie enthält rund 3.000 Einträge, jeder mit Wortart getaggt, damit die App weiß, wie sie ihn konjugieren muss. Ein eigener Kanji-Datensatz (data/kanji.js) deckt die komplette N5-Kanji-Liste ab, in 738 Zeilen. Dazu kommen rund 2.000 Zeilen Anwendungslogik über vier Dateien: app.js für die Oberfläche, srs.js für die Spaced Repetition, conjugate.js und pos.js für die Grammatik.

Der Spaced-Repetition-Scheduler ist ein selbst geschriebener Leitner-Algorithmus. Karten wandern zwischen fünf Boxen, mit wachsenden Wiederholungsabständen: 1, 2, 4, 7 und 14 Tage. Jede Runde zieht zuerst die fälligen, schwächsten Karten, bevor neue dazukommen. Das ist ein bekannter Algorithmus, nichts Neuartiges. Aber ich wollte genau verstehen, wie „fällig“ berechnet wird, statt einer Blackbox zu vertrauen.

Die Konjugations-Engine war der schwierigere Teil. Sie nimmt ein Wort in Wörterbuchform, seine Kana-Lesung und eine Wortart-Markierung. Daraus erzeugt sie die gängigen N5-Formen: ます-Form, て-Form, た-Form, ない-Form. Das funktioniert für Godan-Verben, Ichidan-Verben und Unregelmäßige wie する und 来る, bei denen sich die Lesung ändert, aber nicht das Kanji. Die lautlichen Verschiebungen richtig hinzubekommen, die Onbin-Wechsel, bei denen う, つ und る alle zu って werden, hat echte Iteration gebraucht. Keinen einzigen sauberen Durchgang.

Wo ich keine Daten habe, und dabei bleibt es

Hier ist die ehrliche Lücke. Der Wiederholungsverlauf der App liegt im localStorage des Browsers, auf meinem Handy, nicht in einer Datenbank, die ich abfragen könnte. Ich kann dir keine Retention-Quote oder eine Zahl gelernter Wörter pro Woche nennen. Ich habe die Logging-Logik dafür nie gebaut.

Belegen kann ich, was gebaut wurde, nicht, was gelernt wurde. Die Vokabelzahl, die Zeilenzahlen, die Commit-Historie, die Test-Suite: Das sind Fakten über das Repository. Ob die App mich tatsächlich schneller Japanisch gelehrt hat als ein Stapel Anki-Karteikarten, ist eine Behauptung. Dafür habe ich keinen Beleg. Also stelle ich sie nicht auf.

Diese Lücke lässt sich technisch schließen, mit einem Logging-Layer und ein bisschen SQL. Vielleicht baue ich den irgendwann nach. Bis dahin sage ich lieber ehrlich „ich weiß es nicht“, statt mir eine Zahl auszudenken, die sich gut liest. Das ist derselbe Maßstab, den ich an KI-generierten Content anlege: Eine Behauptung ohne Beleg ist keine Behauptung, sondern Marketing.

Was mich beim Bauen wirklich überrascht hat

Ich bin kein professioneller App-Entwickler. Ich habe Skripte und Automatisierungen geschrieben, aber noch nie etwas mit Service Worker, Offline-Caching und eigener Test-Suite veröffentlicht. Nicht ein klügeres Modell hat die Gleichung verändert. Claude Code hat mich über eine lange Kette kleiner, testbarer Schritte im Fahrersitz gehalten, statt eines einzigen großen Prompts nach dem Prinzip Hoffnung. Für ein Projekt in diesem Zuschnitt hätte auch ein teureres Modell wie Claude Fable 5 nichts gebracht. Das lohnt sich eher bei stundenlangen autonomen Agenten-Läufen, nicht bei einem N5-Vokabeltrainer.

Vier Testdateien (srs.test.mjs, conjugate.test.mjs, pos.test.mjs, vocab-level.test.mjs) existieren, weil ich früh darauf bestanden habe, so wie man auf gutem Kontext für jede KI-Coding-Session besteht. Als die Konjugationslogik an einem Grenzfall zerbrach, einem する-Verb aus einer Zusammensetzung mit unregelmäßiger Lesung, haben die Tests es vor mir gefangen. Ohne sie hätte ich den Fehler wahrscheinlich erst gemerkt, wenn ich selbst falsch konjugierte Sätze auswendig gelernt hätte, und das hätte den ganzen Sinn der App untergraben. Diese Gewohnheit hat mehr dazu beigetragen als jeder einzelne Prompt, dass aus 101 Commits nicht 101 Regressionen wurden.

Es ist außerdem eine PWA: installierbar, funktioniert offline. Kein App-Store-Prüfprozess steht zwischen einem Commit und etwas auf meinem Homescreen. Für ein so eng geschnittenes Projekt hat das mehr gezählt, als ich erwartet hätte.

Ob sich das für dein nächstes Problem lohnt

Ich würde das wieder bauen. Es beweist nicht, dass KI das Sprachenlernen ersetzen kann, und daran habe ich auch kein Interesse. Was es beweist, ist enger und für mich nützlicher: Bei einem klar umrissenen Problem kannst du dir das genau passende Werkzeug bauen. Du musst deine Gewohnheiten nicht an das anpassen, was eine allgemeine App zufällig priorisiert hat.

Wägst du ab, ob du etwas selbst bauen oder eine bestehende App übernehmen willst, lautet die eigentliche Frage nicht „kann KI das für mich bauen“. Sie lautet, ob dein Problem spezifisch genug ist, dass der Besitz des Werkzeugs die Bequemlichkeit einer fremden Lösung aufwiegt. Bei N5 war das bei mir der Fall. Bei einer großen, ausgereiften Sprache wie Spanisch oder Englisch, mit riesigen bestehenden Apps dahinter, würde ich vermutlich anders entscheiden. Ob das für dein nächstes Problem gilt, findest du am besten so heraus, wie ich es getan habe: indem du genau sagst, was du eigentlich willst und die KI als Werkzeug behandelst, das du führst, nicht als Orakel, dem du blind vertraust.