LLMs in der Softwareentwicklung pragmatisch nutzen: Prompting, Refactoring, Debugging und Custom GPTs nach „Leverage LLMs in Development“ von Fabian Riedlsperger (Kickscale)

Worum es ging – unser Recap der Session

In „Leverage LLMs in Development“ zeigte Fabian Riedlsperger (Kickscale), wie Entwicklerinnen und Entwickler große Sprachmodelle (LLMs) in ihren täglichen Workflow einbauen können – ohne Hype, mit Fokus auf praktische Effizienz. Wir bei DevJobs.at haben aufmerksam zugehört: Der Talk war keine Verkaufsfolie für „Magic AI“, sondern eine nüchterne Anleitung, was wirklich funktioniert, was häufig schiefgeht und wie Teams mit einfachen Leitlinien viel Nutzen aus Tools wie GPT, LLAMA, Gemini oder den von ihm erwähnten „Mystrium“-Modellen ziehen können.

Die Kernbotschaft: LLMs sind mächtige Sparringspartner – nicht mehr, aber auch nicht weniger. Ideen, Strukturierung und Qualitätskontrolle bleiben beim Menschen. Wer LLMs als probabilistische Text- und Code-Generatoren versteht, präzise Kontext liefert und iterativ arbeitet, spart Zeit, verbessert Codequalität und macht Wissen leichter zugänglich – vom Prompting über Refactoring bis hin zu Custom GPTs, die interne Standards „eingebacken“ haben.

Kurzer Technik-Background: Wie LLMs arbeiten

Fabian gab einen prägnanten Überblick, der die richtige Erwartungshaltung setzt:

• LLMs sind probabilistisch: Sie generieren Token für Token die wahrscheinlichste Fortsetzung. Es gibt kein eingebautes formales „Regelsystem“ oder gesicherte Wahrheit – nur Wahrscheinlichkeiten.
• Autoregressiv: Das Modell erzeugt das nächste Token auf Basis aller bisherigen Tokens; der Output wird wieder Input.
• Training auf natürlicher Sprache: Meist aus Internetquellen. Dadurch verstehen LLMs natürliche Sprache gut und erzeugen sie flüssig – inklusive Code-Snippets in gängigen Ökosystemen.
• Länge ist Risiko: „Je länger die Antwort, desto größer der Lösungsraum“ – und desto geringer die Chance, dass genau das gewünschte Ergebnis getroffen wird. Kürzere, gezielte Outputs sind häufig robuster.
• Kein implizites Projektwissen: Das Modell weiß nicht, wer wir sind, was unser Produkt macht oder welche Konventionen wir nutzen. Kontext muss explizit in die Eingabe.

Diese Punkte klingen basal, sind aber entscheidend, um die späteren Praxisempfehlungen zu verstehen.

Grenzen und typische Stolperfallen

Die Limitierungen nannte Fabian ohne Umschweife – wichtig, um Risiken zu beherrschen:

• Halluzinationen: Antworten können plausibel wirken und trotzdem falsch sein, weil Kontext oder Wissen fehlen. Gerade bei Code kann das zu subtilen Bugs führen.
• Keine garantierte Faktentreue: Weder Aussagen noch generierter Code sind „per se“ korrekt.
• Chaotisches Verhalten: Kleine Prompt-Änderungen können große Output-Sprünge verursachen.
• Eingeschränkte Einbettung in Software: Programmgesteuert stabile, zuverlässige Outputs zu integrieren ist anspruchsvoll – auch wenn es Workarounds gibt.
• Trial-and-Error in der Use-Case-Recherche: Wer neue Anwendungsfälle identifiziert, iteriert anfangs viel – Prompts, Format, Kontext.

Die Konsequenz: Ohne menschliche Prüfung und iterative Steuerung riskieren Teams Mehraufwand statt Zeitgewinn.

Arbeitsleitlinien: So denkt ein Team mit LLMs

Statt „One-shot“-Wunder empfiehlt Fabian robuste Gewohnheiten:

• LLM als Sparringspartner: „Die Idee kommt von mir; das Modell hilft beim Validieren, Blickwinkel wechseln, blinde Flecken erkennen.“
• Vor dem Prompt: „Welche Informationen braucht das Modell, um die Aufgabe gut zu lösen?“ Diese Metaperspektive verbessert die Ergebnisse spürbar.
• Um Vorschläge bitten: Nicht vorschnell „Lösung!“ fordern. Erst Optionen, Aspekte, Risiken anfordern – der Horizont wird größer.
• Konversation statt Einmal-Prompt: Nachsteuern, präzisieren, Zwischenergebnisse bewerten. So nähert man sich konsistent einem guten Resultat.
• Aufgaben zerlegen: Große Probleme in kleinere, klar abgegrenzte Schritte schneiden. Das erhöht die Zuverlässigkeit.
• Mensch löst das Problem: Die eigentliche Problemlösung – Architektur, Trade-offs, Verantwortlichkeit – bleibt beim Menschen.
• Immer Fakten prüfen: Besonders bei Code. Ein „schneller Paste“ kann teure Fehler nach sich ziehen.
• Output als Startpunkt: Generierte Ergebnisse sind Rohmaterial, das man weiterentwickelt.

Diese Regeln sind einfach, aber sie zeichnen die Teams aus, die LLMs produktiv bekommen – statt in Frust zu enden.

Prompt Engineering in der Praxis

Fabian reduzierte das Thema auf das Wesentliche – ohne Buzzwords, mit greifbaren Leitsätzen:

• Kontext liefern: Alle Informationen, die man selbst zur Lösung bräuchte, gehören in den Prompt. Vom Framework über Konventionen bis zu Randbedingungen.
• Persona setzen: „Agier als erfahrene/r TypeScript/React-Entwickler/in…“ – diese Rahmung kann die Qualität spürbar heben.
• Wörter zählen: Präzise, konkrete Aufgabenformulierung schlägt vage Begriffe. Erwartetes Output-Format explizit nennen.
• Fortgeschrittene Techniken: In-Context Learning, Chain-of-Thought, Retrieval Augmented Generation existieren – wer tiefer einsteigen will, findet dazu viele Ressourcen. In Fabians Praxisbeispielen genügte häufig gutes, klares Prompting.

Use Cases, die bei Kickscale tragen

Der Talk lebte von konkreten Anwendungsfällen – samt Einsparungen und Lerneffekten.

1) Coding: Completion, Generierung, lokal oder Cloud

• Code Completion in der IDE: GitHub Copilot hat Fabian über zwei Jahre so produktiv gemacht, dass er „ohne nicht mehr coden“ möchte. Die Vorschläge beschleunigen Routinearbeit spürbar.
• Code-Generierung: Neue React-Komponenten oder Funktionen lassen sich grob skizzieren und adaptieren.
• Alternativen: Neben Copilot existieren weitere Dienste (z. B. Tab9). Wer Datenschutz groß schreibt, kann lokale Open-Source-Modelle einsetzen.
• Lokal auf dem Mac: Mit MacBook Pro (mindestens M1, genügend RAM) laufen Modelle wie „StarCode“ oder „Codelama“ lokal. Für Teams, die nichts in die Cloud senden dürfen, ist das ein praktikabler Weg.

Praxisbeispiel: Fabian promptete einen Dialog mit Titel, Text, zwei Buttons („Close“ und „Analyze“) und Dummy-Funktionen. Das Ergebnis war direkt nutzbar, leicht anzupassen – und sparte real etwa zehn Minuten gegenüber „from scratch“ (1–2 Minuten Prompting statt 10–15 Minuten Implementierung). Genau dieses Muster – Grobgerüst generieren, dann gezielt nachschärfen – zeigt die Stärke von LLMs in UI- und Boilerplate-Aufgaben.

2) Refactoring: Vorschläge, Standards, Lesbarkeit

Der Workflow, den Fabian schilderte, ist angenehm robust:

1. Zuerst um Vorschläge bitten: Welche Verbesserungen sind sinnvoll? Welche Prinzipien (z. B. SOLID, Single Responsibility) sind nicht erfüllt?
2. Standards sichtbar machen: Namenskonventionen, Coding Standards und Lesbarkeitsanforderungen explizit in den Prompt.
3. Action Items erzeugen lassen: Das Modell listet konkrete Schritte zur Verbesserung.
4. Optional umsetzen lassen: Das Modell auf Basis der Action Items refaktorieren lassen – mit anschließender menschlicher Review.

Gerade bei zu großen React-Komponenten führt dieses Vorgehen zu stabilen Ergebnissen. Neben der Zeitersparnis (Fabian sprach von bis zu 30 Minuten) entsteht ein Lernmoment: Entwicklerinnen und Entwickler sehen alternative Strukturierungen und argumentierbare Verbesserungen, die man in den Teamstandard zurückspiegeln kann.

3) Debugging und Testing: Fehlersuche, Edge Cases, TDD-Starthilfe

• Code analysieren lassen: Mögliche Fehlerquellen aufdecken, die noch nicht abgedeckt sind.
• Fehlermeldungen deuten: Obskure Errors werden entschlüsselt – nützlich, wenn man auf unbekannte Umgebungsdetails trifft.
• Alternativlösungen vorschlagen: Komplexe Funktionen lassen sich vereinfachen; das Modell liefert Varianten zur Bewertung.
• Unit Tests generieren: System-/Integrationstests sind schwieriger (mehr Kontext nötig), aber Unit Tests funktionieren gut.
• Testdaten erzeugen: Dummy-Objekte, Edge Cases, Negativpfade – schnell abgedeckt.
• Test-Driven Development: Mit einer natürlichsprachlichen Beschreibung starten, zuerst Tests generieren lassen, dann die Funktion ableiten – TDD wird flüssiger.

Konkretes Beispiel: Bei Kickscale existiert ein Script zum Ver- und Entschlüsseln von Secrets. Beim Wechsel von Linux auf macOS trat ein Fehler in einem Shell-Kommando auf. Fabian beschrieb das Problem knapp („Linux-Command auf Mac anpassen“) samt Fehlermeldung – binnen ein bis zwei Minuten war die Lösung gefunden. Ohne LLM hätte die Recherche schnell 15 Minuten gedauert. Kein „schweres“ Problem, aber viele solcher Kleinigkeiten summieren sich.

4) Brainstorming: Entscheidungen, Epics, Standards, Tech-Stack

Fabians Lieblings-Use-Case: Ideen- und Entscheidungsarbeit. LLMs sind starke Gesprächspartner, um Optionen, Vor- und Nachteile und blinde Flecken schnell sichtbar zu machen:

• Feature-Design, UX-Aspekte (UI ist schwieriger, da visuelle Kompetenz beschränkt ist)
• DevOps-Themen und Teamstandards (z. B. „Was sollte ein professioneller Coding-Standard abdecken?“)
• Task-Splitting: Große Epics in handliche Tickets schneiden, inklusive sinnvollem Zuschnitt
• Holistische Entscheidungen: Optionen mit Pros/Cons strukturiert gegenüberstellen
• Tech-Stack-Bewertungen: Mögliche Ergänzungen identifizieren, Kriterien sortieren
• Meta-Prompting: „Das Modell kann beim Prompt Engineering helfen“ – ein produktiver Loop

Ein Beispiel: Beim Ausbau der Coding Standards ließ Fabian sich relevante Aspekte listen. Rund 20 % waren nicht relevant – aber ein paar wichtige Punkte, die er noch nicht bedacht hatte, kamen auf den Tisch. Das verbessert nicht primär die Geschwindigkeit, sondern die Professionalität.

5) Gesprächsaufzeichnungen analysieren: Zusammenfassung, Next Steps, Wissensmanagement

Ein Bereich nah am Kickscale-Produkt: Meetings aufzeichnen, transkribieren und mit LLMs auswerten.

Vorgehen:

1. Gespräch aufzeichnen
2. Transkription erzeugen
3. Mit der Transkription arbeiten: Zusammenfassungen, strukturierte Informationen, Next Steps/Action Items extrahieren

Konkreter Use Case: Sprint Planning Sync. Viele Themen, viel implizites Wissen – einiges geht verloren, wenn es nicht sofort im Ticket-System landet. Mit der Auswertung kann das Team später gezielt nachsehen: „Was waren die vereinbarten nächsten Schritte?“ Die Informationen werden für alle zugänglich und nachträglich nutzbar.

6) Custom GPTs: Eingebaute Standards und Teamwissen

Custom GPTs sind spezialisierte Modell-Instanzen mit vorab eingebettetem Wissen. Der Vorteil: Man muss nicht jedes Mal dieselben Standards und Kontexte in jeden Prompt kopieren.

Beispiele aus Fabians Praxis:

• Refactoring GPT: Coding Standards sind hinterlegt; man fügt Code ein und erhält Vorschläge oder Refactorings im gewünschten Stil.
• Feature Requirements GPT: Unterstützung bei der Anforderungsdefinition.
• Dev Tooling GPT: Dokumentierte manuelle Prozesse werden in einem Assistenten gebündelt. Neue Teammitglieder können Fragen stellen („Fehler X ist aufgetreten – wie behebe ich ihn?“) und erhalten Schritt-für-Schritt-Anleitungen.
• Systemarchitektur-Q&A: Tech-Stack hinterlegen und dazu zielgerichtete Fragen stellen.
• Über die Entwicklung hinaus: Auch in Sales oder Marketing kann eine spezialisierte Instanz helfen (z. B. Ideal Customer Profile, Produktinfo) – in Fabians Talk explizit als Nebenbemerkung.

Ein konkreter Kickscale-Case: Für typische Fehlersituationen – etwa „in einer Transkription wurden zu viele Teilnehmer erkannt“ – hinterlegte Fabian die manuellen Schritte im Dev Tooling GPT. Neue Kolleginnen und Kollegen fragen die Instanz und bekommen eine klare Anleitung: Meeting-ID identifizieren, manuell prüfen, Anzahl Teilnehmer korrigieren, Script ausführen. Das erspart „100 Seiten Dokumentation“ – und macht Supportaufgaben reproduzierbar.

Risiken und Überlegungen bei starker LLM-Nutzung

Fabian nannte die Stolpersteine, die wir in vielen Teams wiederfinden:

• Mentale Bequemlichkeit: Zu schnell zum LLM greifen, bevor man selbst nachgedacht hat. Besser: Erst eigene Hypothesen, dann das Modell challengen lassen.
• Überabhängigkeit: Für Mini-Aufgaben kann das Prompten länger dauern als die direkte Lösung.
• Keine Magie: LLMs können fehlendes Wissen nicht herbeizaubern und unlösbare Probleme nicht lösen.
• Sprachen-Bias: JavaScript/Python sind stark vertreten; exotischere Sprachen (z. B. Fortran) sind schwieriger abzudecken.
• Begrenzter Kontext: Immer die nötigen Informationen mitliefern – sonst baut das Modell auf Annahmen auf.
• Schlechte Prompts kosten Zeit: Vage Formulierungen führen zu Schleifen statt Ergebnissen.
• Niemals blind kopieren: Jede Ausgabe prüfen, insbesondere Code.
• Security, Privacy, Copyright: Sensible Daten schützen, rechtliche Aspekte klären, Quellenlage im Blick behalten.

Fazit nach „Leverage LLMs in Development“: Realistische Hebel, spürbarer Impact

Fabians Schlussfolgerungen sind klar und wirken durch die vielen Beispiele belastbar:

• LLMs erhöhen die Effizienz fast jeder Entwicklerin/jedes Entwicklers – wenn man sie als Sparringspartner nutzt.
• Unternehmen, die Software bauen, sollten in einem sinnvollen Rahmen LLMs einsetzen – sonst laufen sie Gefahr, hinter dem Standard zurückzufallen.
• Kleine Teams profitieren besonders: Leanere Setups können heute mit wenigen Personen hochwertige Produkte bauen.
• Weniger Boilerplate, mehr Wertschöpfung: Routinearbeit schrumpft, Raum für Problemlösung und Kreativität wächst.
• Transformative Dynamik: Die Fortschritte der letzten zwei Jahre waren enorm – die nächsten Jahre werden erneut große Veränderungen bringen.
• Zugang wird breiter: Programmieren wird zugänglicher. Mittelfristig könnte mehr natürlichsprachliche Steuerung Einzug halten.
• Agenten am Horizont: „Sag das Feature, das du willst – und es passiert“ ist nicht mehr Science-Fiction, sondern nähert sich.
• Kein Ersatz für Menschen: Rollenbilder ändern sich, aber es braucht Menschen, die Ziele setzen, bewerten, Verantwortung übernehmen.

Konkrete Takeaways für Engineering-Teams

Aus dem Talk leiten wir fünf praktische Handlungsmaximen ab, die sich sofort anwenden lassen – ohne zusätzliche Tools, allein durch Arbeitsweise:

1. Klarer Kontext, klare Outputs: Jeder Prompt enthält die relevanten Fakten und eine präzise Erwartung an Format und Ziel.
2. Iterative Konversation: In kleinen Schritten arbeiten, Zwischenergebnisse bewerten, nachjustieren.
3. Standards zuerst: Coding-Standards, Naming, Prinzipien (SOLID, Separation of Concerns) als erstes in den Prompt – oder als Custom GPT hinterlegen.
4. Human-in-the-loop: Refactorings, Tests, Debug-Hypothesen stets prüfen. LLMs liefern Entwürfe, Menschen entscheiden.
5. Wissensmanagement ernst nehmen: Meeting-Transkripte, Dev-Runbooks, Troubleshooting-Pfade mit LLMs zugänglich machen – besonders für Onboarding und Support.

Demos und Beispiele – was wir besonders lehrreich fanden

• Der „Dialog mit zwei Buttons“-Prompt zeigte exemplarisch, wie Boilerplate-Arbeit schrumpft. Schlüssel war der präzise Auftrag: Titel, Text, Buttons („Close“, „Analyze“), Dummy-Funktionen – fertig.
• Beim Refactoring überzeugte die Sequenz „erst Vorschläge, dann Umsetzung“. So entstehen klare Action Items statt Blackbox-Code.
• Debugging via Fehlermeldungskontext – vom Linux- zum macOS-Kommando – illustrierte, wie LLMs Recherchezeit bei kleinen, häufigen Problemen reduzieren.
• Das Dev Tooling GPT war für uns ein Highlight: Es zeigt, wie sich Runbooks in geführte, dialogische Hilfe verwandeln. Das ist Wissensmanagement, das im Alltag tatsächlich benutzt wird.

Schlusswort

„Leverage LLMs in Development“ von Fabian Riedlsperger (Kickscale) war ein praxisnaher Leitfaden für produktiven LLM-Einsatz im Engineering. Der Talk setzte die richtige Erwartung: probabilistische Modelle, keine Magie – aber hohe Hebelwirkung, wenn Menschen sie bewusst führen. Wer die vorgestellten Muster adaptiert, wird schneller, lernt Neues über den eigenen Code und macht Teamwissen nachhaltiger nutzbar. Genau so sieht für uns bei DevJobs.at der realistische, wirkungsvolle Weg aus, LLMs im Alltag der Softwareentwicklung zu verankern.

• 

  

  Fabian Riedlsperger, Co-Founder & CTO von Kickscale

  Co-Founder & CTO von Kickscale Fabian Riedlsperger gibt im Interview Einblicke wie das Team zusammenarbeitet um die KI Plattform des Unternehmens zu entwickeln und wie das Hiring abläuft.

  Jetzt ansehen

• 

  

  Gerson Joao, Lead Front End Developer bei Kickscale

  Gerson Joao von Kickscale spricht im Interview über seinen Weg beim Software Development – angefangen in der Schulzeit bis hin zu seiner aktuellen Arbeit als Lead Front End Development – und gibt Tipps für Beginner.

  Jetzt ansehen