Fallstudie
Eine Künstleragentur, gebaut wie ein System
Fallstudie zu berlintina.de — dem Projekt, das ihr allein gehört.
Diplom-Systemingenieurin mit KI-Schwerpunkt, im Terminal zu Hause, lange bevor es Sprachmodelle gab. Das ist der Unterschied, der sich in dieser Fallstudie zeigt: Sie lässt sich von KI-Werkzeugen nicht tragen, sie führt sie — mit der Disziplin, die eine Ingenieursausbildung übrig lässt. Architektur, Datenmodell und Randfälle stehen, bevor die erste Zeile fällt. Was folgt, ist an einem einzigen Projekt entlang erzählt, das sie allein gebaut hat.
15
SQL-Migrationen — Schema, Rechte, Suche
3
KI-Dienste angebunden (OpenAI, Gemini, eigener Layer)
2
Oberflächen: öffentliche Seite und Admin-Werkzeug
DE · EN
zweisprachig, mit Sprachumschaltung
Die Aufgabe
Eine Agentur ist kein Formular
Eine Künstlervermittlung sieht von außen aus wie eine Website mit schönen Fotos. Tatsächlich ist sie ein Betrieb mit zwei Seiten, die einander nie sehen dürfen: Künstlerinnen und Künstler wollen sich zeigen, Veranstalter wollen auswählen. Dazwischen steht jemand, der prüft — und genau diese Prüfung ist die Arbeit.
Die naheliegende Abkürzung wäre ein Kontaktformular gewesen, das Mails verschickt. Sie hat stattdessen das gebaut, was der Betrieb wirklich braucht: einen Weg für Bewerbungen, ein Werkzeug zum Prüfen, einen Katalog, der erst zeigt, was freigegeben ist.
Entscheidung 1
Die Sichtbarkeitsregel steht in der Datenbank, nicht im Frontend
Eine Einreichung darf erst öffentlich werden, wenn sie freigegeben ist. Man kann das im Frontend lösen — eine Bedingung, die ungeprüfte Einträge ausblendet. Das sieht richtig aus und ist es nicht: Wer die Schnittstelle direkt anspricht, bekommt trotzdem alles.
In ihrem Schema ist die Regel deshalb dort verankert, wo sie nicht zu umgehen ist. Eine eigene Migration setzt sie durch, eine weitere räumt die Zugriffsregeln nach. Das ist der Unterschied zwischen „sieht sicher aus" und „ist sicher" — und er fällt in einem Code-Review sofort auf.
Entscheidung 2
KI übernimmt das Gespräch, nicht die Entscheidung
Künstlerinnen und Künstler beschreiben sich ungern in Formularfeldern. Also führt ein Sprachmodell das Aufnahmegespräch: Es fragt nach, formuliert die Show-Beschreibung aus und übergibt einen fertigen Text — angebunden sind mehrere Anbieter, damit ein Ausfall oder eine Preisänderung nicht das Produkt kippt.
Entscheidend ist, was das Modell nicht darf. Es entscheidet nicht über die Aufnahme. Der Vorschlag landet im Prüf-Werkzeug, ein Mensch sieht die Seite genau so, wie sie später aussehen wird, korrigiert direkt darin und gibt frei. Die KI ist ein Werkzeug in einem Ablauf, kein Ersatz für ihn.
Entscheidung 3
Das Prüf-Werkzeug zeigt die echte Seite, keine Tabelle
Die meisten Verwaltungsoberflächen zeigen Datensätze in Zeilen. Wer freigibt, sieht dann Felder — und nicht das, was Besucher später sehen. Fehler fallen erst auf, wenn sie öffentlich sind.
Ihr Admin-Bereich dreht das um: Er startet in der Vorschau, zeigt die fertige Seite und legt die Bearbeitung als schmalen Streifen darüber. Korrigiert wird an Ort und Stelle, mit einem Stift direkt im Text. Das ist keine Design-Laune, sondern eine Fehlerbremse — man gibt frei, was man sieht.
Entscheidung 4
Suchen dürfen die finden, die zahlen
Ein Katalog ohne Suche ist eine Galerie. Veranstalter suchen aber nicht nach Namen, sie suchen nach dem, was sie brauchen — und beschreiben es mit ihren eigenen Worten.
Deshalb liegt in ihrem Schema eine Volltextsuche über die Shows, dazu eine eigene Zuordnungslogik zwischen Anfrage und Angebot. Beides sitzt in der Datenbank statt in einer Filterfunktion im Browser: Das bleibt schnell, wenn aus fünfzig Einträgen fünfhundert werden.
Was daran übertragbar ist
Kein Teil dieses Projekts ist exotisch. Übertragbar ist die Reihenfolge: erst verstehen, wer das System benutzt und wer dafür zahlt — dann das Datenmodell, dann die Rechte, dann die Oberfläche. Genau diese Reihenfolge hält, wenn ein Projekt größer wird als der Kopf, der es begonnen hat. Sie ist der Grund, warum eine Ingenieurin auch dort trägt, wo niemand vorher eine Spezifikation geschrieben hat.
Belegt am öffentlichen Repository · Stand August 2026
Fragen zur Architektur? info@berlintina.de