Programming

Was wir bauen

Wir entwerfen und bauen die Software-Schicht, die KI-Modelle umgibt: maßgeschneiderte Anwendungen, interne Tools, Orchestrierungs-APIs und Review-Interfaces. Das Ziel ist immer ein System, das dein Team betreiben, erweitern und ohne implizites Wissen an den nächsten Entwickler übergeben kann.

Kernkompetenzen

Maßgeschneiderte KI-Anwendungen End-to-end Web-Anwendungen und interne Tools mit KI als Kern — von der Datenschicht bis zur Benutzeroberfläche. Framework-agnostisch; wir verwenden, was zum Anwendungsfall passt.

Orchestrierung & API-Design Saubere, versionierte APIs, die LLM-Fähigkeiten dem restlichen Stack zugänglich machen. Rate-Limiting, Authentifizierung, strukturiertes Fehlerhandling und OpenAPI-Dokumentation standardmäßig enthalten.

Human-in-the-Loop-Interfaces Review- und Freigabe-Oberflächen für KI-generierte Outputs — die Interface-Schicht zwischen Modell und Produktionsfreigabe. Auf Review-Geschwindigkeit ausgelegt, nicht nur auf Darstellung.

Workflow-Automatisierung Geplante Pipelines, event-gesteuerte Trigger und mehrstufige agentische Workflows — mit explizitem State-Management und Fehlerbehandlung, damit Betriebsteams ohne Entwickler-Eingriff diagnostizieren und wiederherstellen können.

Programmierstandards

• Alle APIs sind versioniert und beinhalten eine OpenAPI-Spezifikation
• Testabdeckung zielt auf den Vertrag, nicht auf Implementierungsdetails
• Abhängigkeiten sind gepinnt und werden regelmäßig geprüft
• Keine proprietären Laufzeit-Abhängigkeiten — ausschließlich Open-Source- oder portierbare Entscheidungen
• Code wird mit einem Runbook übergeben, der Deployment, Rollback und häufige Fehlerbilder abdeckt

Wann diese Arbeit sinnvoll ist

Programming ist die richtige Schicht, wenn eine KI-Fähigkeit eine echte Oberfläche, Berechtigungen, Zustände oder Integrationen braucht – nicht noch ein Notebook. Auslöser sind etwa eine manuelle Review-Queue, die Tabellen entwachsen ist, ein internes Tool ohne klare Verantwortung oder ein Agent, der sich von Teilfehlern nicht sicher erholt. Die Grenze der Anwendung wird vor der Framework-Auswahl festgelegt.

Delivery-Modell

Wir erfassen Nutzer- oder Betreiberweg, Datenverträge, Authentifizierungsgrenze und Fehlerzustände. Ein vertikaler Schnitt läuft dann durch echte UI, API, Modellaufruf, Validierung und Persistenz. So werden Integrationsgrenzen früh sichtbar. Danach kommen nur die nötigen Screens, Jobs, Berechtigungen, Tests und Deployment-Kontrollen hinzu. Deliverables können laufende Anwendung, OpenAPI-Vertrag, Zustandsmodell, Review-Interface, Tests, Deployment-Notizen und Runbook sein. Der Engineering-Service deckt die Reliability-Schicht ab; das Insight zu Multi-Agent-Systemen zeigt, wann Orchestrierung begrenzt bleiben sollte.

Abhängigkeiten, Risiken und Abnahme

Das Kundenteam stellt Prozess-Owner, Integrationsumgebung und Entscheidungen zu Zugriff und Aufbewahrung bereit. Individuelle Software kann einen schlechten Prozess verstärken, wenn das Zustandsmodell unklar ist. Die Abnahme prüft deshalb Vertragsverhalten, Berechtigungen, Wiederherstellbarkeit, repräsentative Journeys und Übergabe: Ein anderer Engineer sollte das System anhand der Dokumentation deployen, diagnostizieren und zurückrollen können. Einen begrenzten App-Bau besprechen.

Integrationshinweise

Die kleinste nützliche Anwendung stellt oft einen bestehenden Service bereit, statt ihn zu ersetzen. Klare Grenzen zwischen UI, Orchestrierung, Persistenz und Provider-Aufrufen machen spätere Änderungen sicherer. Wir dokumentieren, was bewusst nicht automatisiert wird, welche Aktionen Bestätigung brauchen und wie ein Ausfall einer Abhängigkeit behandelt wird. Diese Grenzen sind für Wartbarkeit ebenso wichtig wie der Code.