Immer mehr Produkte, an denen ich arbeite, bestehen aus zwei Hälften. Die eine umfasst alles, womit Menschen direkt interagieren: eine Next.js-Oberfläche, eine Node.js-API, Authentifizierung und Zahlungen. Die andere betrifft Modelle: Inferenz, Embeddings, Audio und Datenverarbeitung. Die erste Hälfte spricht TypeScript, die zweite Python. Beide Sprachen zu beherrschen heißt nicht, Sprachen zu sammeln, sondern die Nahtstelle zu verantworten – genau dort scheitern viele KI-Produkte.
Die gute Nachricht: Die beiden Ökosysteme ähneln einander stärker, als viele denken. Zu Zod gehört Pydantic, zu tsc gehören mypy und pyright, zu ESLint und Prettier Ruff, zu npm und pnpm uv und Poetry. Express und NestJS haben FastAPI als Gegenstück; es erzeugt typisierte OpenAPI-Schemas gleich mit. Auf beiden Seiten halte ich dieselbe Disziplin ein: strenge Typen, ein unumstrittener Formatter, festgeschriebene Abhängigkeiten und Tests in CI.
Der Vertrag zwischen den beiden Seiten ist die wichtigste Datei im System. Ich definiere ihn einmal und generiere den Rest: Pydantic-Modelle in FastAPI erzeugen ein OpenAPI-Schema, daraus entstehen der TypeScript-Client und seine Typen. Wird ein Feld in Python umbenannt, schlägt der Next.js-Build fehl, bevor Nutzer jemals undefined sehen. Bei asynchroner Arbeit ist der Vertrag ein Job-Payload mit Schema an beiden Enden – kein freies JSON, das jede Seite anders interpretiert.
Die Zuständigkeiten bleiben klar getrennt. TypeScript verantwortet Identität, Berechtigungen, Geld und UI. Python verantwortet das Modell und sonst nichts: Es nimmt einen Job entgegen, erledigt die rechenintensive Arbeit – etwa eine StyleTTS2-Stimme, einen Embedding-Batch oder das Parsen eines Dokuments – und liefert das Ergebnis zurück. Der Python-Service kommuniziert nie mit dem Browser und entscheidet nie über Berechtigungen. Schnelle Aufrufe laufen über HTTP, langsame über eine Queue; beide Seiten nutzen Timeouts, Retries und Idempotenz.
Auch die Unterschiede sind wichtig und müssen berücksichtigt werden. In Python kann man in einem Notebook Prototypen erstellen, aber Notebooks sind kein Produktivbetrieb: Der fertige Code gehört in ein Modul mit Tests. Pythons Nebenläufigkeit ist nicht Node.js’ Event Loop; CPU-intensive Inferenz gehört in Worker-Prozesse oder einen GPU-Service, nicht in einen asynchronen Request-Handler. Auch die Deployment-Artefakte unterscheiden sich: ein schlankes Node-Image gegenüber einem Python-Image mit CUDA und Modellgewichten. Dadurch unterscheiden sich Skalierung, Caching und Kosten.
Für Kunden liegt der Vorteil eines Engineers auf beiden Seiten auf der Hand: Es braucht keine Übersetzung zwischen „KI-Person“ und „Web-Person“, und niemand schiebt die Verantwortung für die API dem anderen zu. Wenn Ihr Modell im Notebook bereits funktioniert, die Web-App es aber noch nicht nutzen kann, schicken Sie mir beides. Ich skizziere den Vertrag dazwischen und die erste Version, die ich ausliefern würde.
Geben Sie dem nächsten Produkt jemanden, der bleibt.
Bereit für den Start? Schreiben Sie mir – ich kann sofort beginnen und bleiben. Langfristige Mandate statt Übergabe nach zwei Wochen. Lassen Sie uns über Ihr Projekt, die Anforderungen und den besten Weg nach vorn sprechen.