KI Prototyping Workshop

Die Werkzeuge, mit denen sich heute in wenigen Stunden eine funktionierende Oberfläche bauen lässt, sind gut geworden. Was sie nicht liefern, ist eine Antwort auf die Frage, was passiert, wenn echte Nutzer, echte Kundendaten oder ein zweiter Entwickler dazukommen.

In diesem Workshop entsteht in zwei Tagen ein Prototyp, der läuft, und darunter eine Struktur, die man nicht wegwerfen muss, sobald es ernst wird. Sie sind dabei, wenn er entsteht, und Sie nehmen ihn mit.

Zwei Tage gemeinsam, remote oder vor Ort in Hamburg. Auf Wunsch bei Ihnen. 

3.000 EUR, inklusive Vorbereitung und Nachbereitung.

Termin vereinbaren

Wenn es um ein internes Werkzeug für eine kleine Anzahl an Kolleginnen und Kollegen geht, das keine personenbezogenen Daten anfasst, dann bauen Sie das vermutlich selbst an einem Nachmittag mit verfügbaren Coding-Tools. Das ist eine vertretbare Entscheidung, und wir würden Ihnen davon nicht abraten. 

Interessant wird es an drei Stellen. Wenn echte Nutzer damit arbeiten sollen. Wenn Kundendaten oder personenbezogene Daten hineinlaufen. Wenn jemand anderes als der Autor den Code später weiterentwickeln muss. Ab dann trägt das, was unter der Oberfläche liegt, plötzlich Gewicht.

Ein Kunde hatte über mehrere Wochen eine Anwendung gebaut, Feature für Feature, und jedes einzelne davon funktionierte. Was fehlte, war eine Entscheidung darüber, wie das Ganze aufgebaut sein sollte, bevor das erste Feature entstand.

Kein Framework, keine erkennbaren Konventionen, jede Funktion einzeln entwickelt, ohne zu prüfen, ob es dafür längst eine etablierte Bibliothek gibt. Jede Iteration hat gelöst, was gerade anlag, und dabei die Struktur weiter verschoben. Das geht eine Weile gut, weil das Modell auf jede Anfrage etwas Lauffähiges liefert. Nach einigen Wochen war eine Codebasis entstanden, die sich in angemessener Zeit weder lesen noch sinnvoll reviewen ließ, und ohne Tests ließ sich auch nicht feststellen, was eine Änderung an anderer Stelle kaputt macht. Der eigentliche Fehler lag dabei nicht im Code, sondern in dem, was vor der ersten Zeile nicht geklärt wurde. Ohne definierten Scope trifft das Modell die Architekturentscheidungen implizit, Prompt für Prompt, und niemand hat sie je bewusst getroffen.

Sicherheitsthemen kommen dazu. Ein Kunde hatte eine Anwendung mit Microsoft 365 Anbindung entwickelt. Anstatt einer eigenen in Microsoft Entra registrierten Anwendung griff er auf die Exchange Online API mit seinem Exchange-Admin-Account via Delegated Access zu. Damit hatte die Anwendung Zugriff auf sämtliche Postfächer der Organisation, ohne eingeschränkten Scope und ohne Trennung zwischen Lesen und Schreiben. Ein Fehler im Code hätte Inhalte verschieben oder löschen können, ohne dass es aufgefallen wäre. Dazu verarbeitet die Anwendung eingehende Nachrichten und reicht deren Inhalt an ein Sprachmodell weiter. Eine präparierte Mail, die Anweisungen enthält, passiert die Schutzmechanismen von Exchange, weil sie technisch kein Angriff ist, sondern erst im Modell als Anweisung wirkt.

Häufiger als solche Funde sind die unauffälligen Dinge, die sich erst im Betrieb zeigen. 

• API-Keys im Frontend, 
• Berechtigungen, die es nur in der Oberfläche gibt, 
• ein Datenmodell und eine Datenbank ohne Migrationsdateien (Stichwort: fehlende Datenintegrität),
• Logging, das personenbezogene Daten wegschreibt. 

Was dabei typischerweise auftaucht und wie Sie es selbst prüfen können, haben wir gesondert beschrieben.

Keiner dieser Punkte ist ein Argument gegen den Prototypen, sondern ein Argument dagegen, ihn ohne Prüfung an echte Nutzer zu geben.

Vorab klären wir in einem kurzen Gespräch, worum es geht und was Sie mitbringen.

Tag 1 vormittags klären wir den Scope. Was die Anwendung tut, wer sie benutzt, welche Daten hineinlaufen und was passieren muss, wenn sie in Betrieb geht. Das ist der Teil, den man am leichtesten überspringt und am teuersten nachholt, weil hier die Entscheidungen fallen, die sich später nur noch mit einem Neubau korrigieren lassen.

Tag 1 nachmittags entsteht der Prototyp. Wir bauen, Sie sind dabei, die Bildschirme sind geteilt. Am Ende des Tages läuft ein Ablauf, den Sie bedienen können.

Tag 2 geht es unter die Oberfläche. Authentifizierung und Autorisierung hinter den API-Routen statt in der Oberfläche. Secrets aus dem Frontend heraus. Ein Datenmodell mit Migrationen, das sich ändern lässt, ohne Produktivdaten anzufassen. Tests um das herum, was wirklich zählt. Logging, das keine personenbezogenen Daten wegschreibt.

Zum Abschluss gehen wir gemeinsam durch, was steht, was Gerüst ist und was noch fehlt, bevor die Anwendung an echte Nutzer geht, mit einer Einschätzung des Aufwands dafür.

Nach dem Workshop erhalten Sie die Dokumentation der Architekturentscheidungen und die Aufwandseinschätzung für weitere Schritte schriftlich.

Ein Repository, das Ihnen gehört, lauffähig in Ihrer Umgebung, nicht auf unserer Infrastruktur. Dazu die Dokumentation der Architekturentscheidungen aus Tag 1 und die Einschätzung aus dem Abschluss.

In zwei Tagen entsteht ein Ablauf, der funktioniert, nicht das fertige Produkt. Das ist keine Untertreibung, sondern die ehrliche Grenze des Formats. Was Sie mitnehmen, ist eine Basis, auf der sich weiterbauen lässt, und ein realistisches Bild davon, was der Weg in den Betrieb noch kostet.

Zwei Personen von Ihrer Seite.

Eine, die das Vorhaben fachlich verantwortet. Jemand, der die Domäne kennt, weiß, wie der Prozess wirklich läuft, und im Zweifel entscheiden kann, was die Anwendung tun soll und was nicht. Das ist der Teil, den wir Ihnen nicht abnehmen können.

Und eine, die den Code danach weiterträgt. Wer das ist, hängt von Ihnen ab. In manchen Unternehmen ist das ein Entwickler, in anderen der technisch versierte Gründer, in wieder anderen die Person, die den Prototypen bisher selbst gebaut hat. Es braucht keine formale Entwicklerrolle, es braucht jemanden, der nach dem Workshop mit dem Repository arbeiten wird.

Wenn beides in einer Person zusammenfällt, ist das kein Problem. Es kommt häufiger vor, als man denkt.

Und wenn diese zweite Person bei Ihnen schlicht nicht existiert, dann ist das ein Thema für sich. Wir übernehmen die Weiterentwicklung in solchen Fällen, aber das ist keine Entscheidung, die Sie vorab treffen müssen. Zwei Tage gemeinsam an einer echten Anwendung sagen mehr darüber aus, ob die Zusammenarbeit trägt, als jedes Vorgespräch.

Je nach Vorhaben ein Lead Developer mit Architekturschwerpunkt, ein Entwickler mit langjährigem Hintergrund im Requirements Engineering, oder einer unserer Geschäftsführer, der seit Jahren digitale Geschäftsmodelle aufbaut und verkauft. Alle drei arbeiten täglich mit KI-gestützter Entwicklung.

Wir arbeiten in Ihrem Stack. Am häufigsten bauen wir mit PHP und Symfony, gearbeitet haben wir in einer Reihe weiterer Umgebungen. Der Punkt dieses Workshops ist nicht die Technologiewahl.

Dann ist dieser Workshop womöglich nicht der richtige Einstieg. In einer Standortbestimmung sehen wir uns an einem halben Tag an, was Sie gebaut haben, und Sie bekommen eine belastbare Antwort auf die Frage, ob es tragfähig ist. Hier

Gern vereinbaren wir ein unverbindliches Kennlerngespräch.

Alternativ schreiben Sie uns kurz, woran Sie gerade arbeiten oder was Sie bauen wollen. Wir melden uns mit einer Einschätzung, ob der Workshop das richtige Format dafür ist.