Ein Entwickler aus Berlin baut die Zukunft, eine Zeile Code nach der anderen.
Tobias baut seit 2018 Software, die Production-Traffic übersteht. Spezialisierung: low-latency Backends, AI-Integration, self-hosted Infrastruktur.
Tobias baut seit 2018 Software, die Production-Traffic übersteht. Spezialisierung: low-latency Backends, AI-Integration, self-hosted Infrastruktur.
Tobias Ludwig ist Full-Stack- und Systems-Engineer aus Berlin. Seit 2018 baut er Software, die unter realer Last gemessen, beobachtet und gewartet wird — keine Mocks, keine Workarounds, keine Magie. Sein Stack: Next.js, Postgres, Three.js, Rust und ein gut gepflegter Coolify-Cluster.
Eine kleine Enzyklopädie jener Sprachen, Bibliotheken und Werkzeuge, die in der Werkstatt Ludwig am häufigsten zur Hand liegen. Mit IPA-Aussprache, weil Aussprache zählt.
Container, in denen Software so reist, wie der Entwickler sie geschrieben hat — nicht so, wie der Server sie sich wünscht.
Werkzeug aus der Kategorie DEVOPS; in der Werkstatt Ludwig regelmäßig in Gebrauch.
Werkzeug aus der Kategorie DEVOPS; in der Werkstatt Ludwig regelmäßig in Gebrauch.
Werkzeug aus der Kategorie DEVOPS; in der Werkstatt Ludwig regelmäßig in Gebrauch.
Werkzeug aus der Kategorie DEVOPS; in der Werkstatt Ludwig regelmäßig in Gebrauch.
Werkzeug aus der Kategorie DEVOPS; in der Werkstatt Ludwig regelmäßig in Gebrauch.
Werkzeug aus der Kategorie DEVOPS; in der Werkstatt Ludwig regelmäßig in Gebrauch.
Werkzeug aus der Kategorie DEVOPS; in der Werkstatt Ludwig regelmäßig in Gebrauch.
Werkzeug aus der Kategorie DEVOPS; in der Werkstatt Ludwig regelmäßig in Gebrauch.
Werkzeug aus der Kategorie DEVOPS; in der Werkstatt Ludwig regelmäßig in Gebrauch.
Werkzeug aus der Kategorie DEVOPS; in der Werkstatt Ludwig regelmäßig in Gebrauch.
Werkzeug aus der Kategorie DEVOPS; in der Werkstatt Ludwig regelmäßig in Gebrauch.
Eine kleine Werkschau aus zwei Jahren Königswinter, DEer Schreibtisch-Realität, fotografiert mit den Mitteln der Software selbst.
Es gab eine Zeit, da hielt ich Mocks für ein Geschenk. Sie sind schnell, sie sind sauber, sie sagen immer Ja. Wer einmal eine Stunde mit einer launischen Drittanbieter-API verbracht hat, weiß: Ein Mock ist Stille im Gewitter. Ich habe ganze Test-Suiten auf ihnen gebaut. Ich habe sie geliebt, wie man eine Espressomaschine liebt, die immer funktioniert.
Dann kam die Produktion. Die echten Antworten waren langsamer, krummer, oft fehlerhaft. Felder, die in meinen Mocks fest verdrahtet waren, fehlten plötzlich oder enthielten den unerwartetsten Kandidaten überhaupt: null. Es gibt nichts Demütigenderes, als zu erkennen, dass man sich monatelang gegen ein Echo getestet hat.
Seitdem schreibe ich meine Tests anders. Ich verwende echte Endpoints in einer sauberen Staging-Umgebung. Ich nehme in Kauf, dass eine Test-Suite manchmal fünf statt fünfzehn Sekunden braucht, weil sie tatsächlich mit der Welt spricht. Ich behalte meine Mocks für die Stellen, an denen sie ehrlich sein können — etwa für Datum- und Zeitstempel oder zufällige UUIDs. Alles andere bekommt das Recht, zu scheitern, wo es scheitern wird.
Die zweite Lektion war noch unangenehmer: Wenn ich für meine eigene KI-Pipeline Mock-Antworten generiere, verschiebe ich nicht die Komplexität in die Zukunft — ich erfinde eine Welt, die nicht existiert. Modelle halluzinieren, sie sind inkonsistent, sie wechseln Tonart. Ein Mock, der das nicht abbildet, ist eine Postkarte aus einem Land, das es nicht gibt.
Heute frage ich mich vor jedem neuen Mock: Welche Lüge erzähle ich gerade meinem künftigen Ich? Manchmal lautet die Antwort: gar keine. Aber manchmal, und das ist der wichtige Teil, ist der ehrlichste Mock derjenige, den ich gar nicht schreibe.
— T. L., Königswinter, DE, im April 2026
Briefe, Anfragen, längere Gespräche bitte direkt an die Redaktion. Dieser Entwickler liest seine Mails täglich.
hello@tjl-it.de60 % produktiv, mit Aufklarungen am Nachmittag. Böen aus der Deadline-Richtung erreichen kurzzeitig Stärke 7. Lokale Espresso-Niederschläge.