Werkstattbericht#
Der Workshop#
Ende Februar 2025 fand an der TU Darmstadt der Workshop “KI Konkret” statt Post auf LinkedIn.
Im Rahmen dieser Veranstaltung des ZKI Arbeitskreises Strategie und Organisation wurde auch diskutiert, ob die bisherigen Brainstormingformate zur Sammlung von Ideen und Meinungen in Form von analogen oder digitalen Zettelsammlungen weiterentwickelt werden könnten. Zudem wurde ein größerer Bedarf deutlich, die bestehenden KI-Aktivitäten, insbesondere die bereits angebotenen Dienste und Dienstleistungen im Bereich generativer KI, zusammenzutragen und zu kartieren.
Auf der Rückfahrt wurde dann mit einem Aufwand von etwa zwei Stunden ein klickbarer Prototyp mittels einer LLM implementiert. Prototyp im Browser starten
Interessant fand ich dabei die Fragestellung, wie viel Zeit man mittels KI für eine vollständige Umsetzung benötigen würde und ob diese Komplexität der Anwendung bereits mit LLM-Coding erreichbar ist.
Die Antwort auf diese Frage soll in diesem Werkstattbericht beleuchtet werden.
Gleich vorweg: Sie besuchen diese Website und das Vorhaben konnte erfolgreich umgesetzt werden. Die Anwendung funktioniert am Ende so wie gedacht. Hierfür war jedoch mehr eigene Arbeit notwendig, als anfänglich erhofft. Ohne LLMs wäre eine Umsetzung jedoch auf keinen Fall möglich gewesen.
Zahlen zu den Ergebnissen:#
| Dateiendung | Anzahl Dateien | Anzahl Zeilen |
|---|---|---|
| Python | 29 | 8.542 |
| HTML | 15 | 6.249 |
| CSS | 4 | 1.660 |
| Javascript | 4 | 716 |
| Konfigurationsdateien | 9 | 365 |
| GESAMT | 61 | 17.532 |
Angaben zum Zeiteinsatz:#
| Aufgabe | Zeiteinsatz [h] |
|---|---|
| Abstimmung der Anforderungen | 1 |
| Diskussion zur technischen Architektur | 1 |
| Testumsetzung des technischen Gesamtansatzes | 1 |
| Datenbankschemata | 1 |
| OpenAPI - CRUD | 2 |
| Crawler und Webseiteninterpretation | 2 |
| Template-System und statischer Site-Generator | 2 |
| LLM-Client | 2 |
| Erarbeitung Designkonzept und UI | 1 |
| Umsetzung und Problembehebung UI | 2 |
| Prompts und Steckbriefableitung | 2 |
| Admin-Redaktionsbereich, Workflows | 2 |
| Übersichtsseite und Schlagwort-Wolke zu Projekten | 2 |
| Diskussion zu Sicherheitsaspekten des Deployments | 1 |
| CORS, CSRF | 1 |
| Deployment 2 nginx-Konfigurationen, Datenbank, Uvicorn | 3 |
| Docker, Docker compose, API-Routing und Fehlerbehebungen | 2 |
| Einbindung Certbot | 2 |
| Netzwerkkonfiguration, Ports, Domainfilter, Rate-Limits | 1 |
| Planung und Umsetzung Dokumentationslösung | 1 |
| SUMME | 32 |
Die Abschätzung der LLMs zum möglichen Umsetzungsaufwand durch eine klassische Agentur lag bei 180-200 Stunden.
Was waren die größten Hürden:#
Das Projekt ist für heutige Large Language Models (LLMs) zu umfangreich, da immer nur ein kleiner Teil des gesamten Codes bearbeitet werden kann. Der inhaltliche Kontext, der Zusammenhang auf Dateiebene, das Zusammenspiel der eingesetzten Technologien und der grundlegende Aufbau der Anwendung müssen dabei von der entwickelnden Person vollständig im Kopf behalten werden. Dies bedeutet auch, dass ohne zumindest grundlegende Kenntnisse von aktuellen Technologien und deren Zusammenhängen solche Entwicklungen nicht möglich sind.
Die LLMs erzeugen nicht nur häufig fehlerhaften Code, sondern, um es mit menschlichen Begriffen auszudrücken, schummeln, versuchen sich um schwierige Aufgaben zu drücken, nehmen Abkürzungen, die niemals funktionieren können, oder faken einfach einzelne Teile des Codes, damit es auf den ersten Blick als korrekte Lösung erscheint. Diese Abkürzungen sind nicht immer sofort zu erkennen, wenn der Code komplexer wird, und so muss jede Ausgabe der LLMs immer genau geprüft werden.
Die LLMs verrennen sich häufig in falsche Fährten bzw. Lösungen, die entweder zu komplex für die LLMs sind oder von den LLMs nicht zu einer lauffähigen Gesamtlösung abgeschlossen werden können. In diesen Fällen muss der gesamte Teilansatz wieder zurückabgewickelt werden, um einen anderen Ansatz zu implementieren.
Die LLMs neigen dazu, bei zu schwierigen Aufgaben Tricklösungen zu implementieren, z.B. mit Mock-Daten, wodurch das Gesamtsystem kurzfristig lauffähig scheinen kann.
Teilweise wählen LLMs Technologien zur Problembewältigung, die unnötig komplex, für das spezifische Problem nicht geeignet oder schlicht veraltet sind. Erkennt man diese ungünstige Technologiewahl zur Problemlösung nicht, wird das Programmiervorhaben nicht erfolgreich sein.
Die Bereitstellung der Anwendung auf Servern stellt einen großen Zusatzaufwand dar, bei dem die LLMs nur bedingt unterstützen können.
Welche LLMs wurden für das Projekt eingesetzt:#
Anthropic Claude Sonnet 3.7 und 4.0 OpenAi GPT-4o und GPT-4o mini Mistral Large2 GLM-4-0414 Model Series Cohere Command-R