- GenAI (LLM) steigert die Produktivität von Entwickler:innen durch Funktionen zur automatischen Code-Generierung und Assistenz
- Schon früher gab es „No-Coding-Tools“, doch im eigentlichen Software-Engineering-Prozess gibt es weiterhin eine eigene, inhärente Komplexität
- Seit dem Start von ChatGPT ist die rasante Entwicklung von KI-Tools deutlich sichtbar, aber statt den gesamten Prozess grundlegend umzuwälzen, verkürzen sie vor allem einzelne Schritte bei gegebenen Problemen erheblich
Die tatsächliche Nutzung durch Entwickler teilt sich in zwei Richtungen
- Bootstrappers
- Nutzen Tools wie Bolt, v0 oder Screenshot-to-code, um neue Projekte oder MVPs schnell umzusetzen
- Ausgehend von Designs (z. B. Figma) oder groben Konzepten erzeugt die KI eine vollständige initiale Codebasis
- Erstellen funktionsfähige Prototypen in Tagen oder sogar in wenigen Stunden
- Auch wenn es für Produktionsniveau unvollständig ist, ist es stark bei der Validierung von Ideen
- Legen Wert auf schnelle Validierung und Iteration
- Iterators
- Nutzen Cursor, Cline, Copilot, WindSurf usw. im täglichen Entwicklungsprozess
- Verwenden KI für Code-Autovervollständigung, komplexes Refactoring sowie die Erstellung von Tests und Dokumentation
- Überlassen der KI komplexe Tests, Dokumentation und Refactoring, prüfen die Ergebnisse aber fortlaufend
- Nutzen sie wie einen „Pair Programmer“, der bei der Problemlösung mitarbeitet
- Entwickeln den Code iterativ zur optimalen Lösung weiter, indem Entwickler KI-Vorschläge auswählen, anpassen und ergänzen
Das 70%-Problem: die Schwierigkeit der „letzten 30 %“ – das Paradox der KI-Lernkurve
- KI erzeugt schnell Code bis etwa 70 %, aber die letzten 30 % werden oft zum großen Engpass
- Es entsteht leicht ein Teufelskreis, in dem ein kleiner Bug behoben wird und dafür an anderer Stelle etwas kaputtgeht
- Besonders Nicht-Informatiker:innen oder Juniors neigen dazu, den von der KI vorgeschlagenen Code vollständig zu übernehmen und dadurch Folgeprobleme auszulösen
- Ihnen fällt es schwer zu erkennen, warum die vorgeschlagenen Änderungen Probleme verursachen
- Erfahrene Senior-Entwickler:innen leiten die Ursache von Bugs schnell her, strukturieren Code neu und berücksichtigen zusätzlich Sicherheit und Performance, um Lücken der KI auszugleichen
- Sie nutzen KI aktiv, reviewen und refaktorieren aber ständig weiter, bis „wartbarer Code“ entsteht
- Wenn Juniors oder Nicht-Entwickler KI-generierten Code unbedacht übernehmen, entsteht das Risiko von „Kartenhaus-Code“, der in realen Produktionsumgebungen leicht zusammenbricht
- Wissensparadox
- Seniors können Probleme, die sie bereits verstehen, gemeinsam mit KI schnell umsetzen
- Juniors sollen zwar mit KI lernen, stoßen aber ohne Grundlagenwissen beim Debugging und bei der Validierung auf große Schwierigkeiten
Effektive Nutzungsmuster
- KI-Entwurf, dann Verfeinerung
- Wenn die KI eine erste Implementierung liefert, wird diese von Menschen direkt geprüft, refaktoriert und getestet
- Fehlerbehandlung und Ausnahmefälle werden manuell ergänzt, automatisierte Tests und Review-Prozesse werden verstärkt, um die Zuverlässigkeit zu erhöhen
- Modularität, Fehlerbehandlung, Typdefinitionen und Architektur werden verbessert, damit der Code wartbar bleibt
- Gespräche pro Arbeitseinheit getrennt halten
- Statt auf einmal einen großen Kontext zu übergeben, werden für kleine Probleme jeweils eigenständige Prompts verwendet, um fokussierte Antworten zu erhalten
- Änderungen werden häufig geprüft und committed, Feedback wird in kurzen Zyklen eingearbeitet
- „Vertrauen, aber prüfen“
- Die KI erstellt Entwürfe, doch wichtige Logik, Fehlerbehandlung und Sicherheitsfragen werden von Menschen direkt verantwortet
- Testfälle werden immer geschrieben, Performance, Sicherheit und strukturelle Plausibilität werden sorgfältig überprüft
Was das für Entwickler bedeutet
- Klein anfangen
- KI zuerst bei gut definierten kleinen Aufgaben und Problemen mit klarem Umfang einsetzen und den generierten Code sorgfältig prüfen
- Bevor zu größeren Features übergegangen wird, Tests und Dokumentation gründlich absichern und den Umfang dann schrittweise erweitern
- Modularität beibehalten
- Die Codebasis passend aufteilen, damit von KI erzeugter Code nicht strukturell vermischt wird
- Dateien und Funktionen in kleine Einheiten zerlegen und Schnittstellen sowie Abhängigkeitsflüsse klar definieren
- Der eigenen Erfahrung vertrauen
- KI als Hilfsmittel nutzen, die endgültige Entscheidung aber an der eigenen Erfahrung ausrichten
- Verdächtigen Code oder fragwürdige Architektur hinterfragen und lieber Engineering-Standards einhalten
Der Aufstieg des agentischen (agentic) Software Engineerings
- Bisher reagierten KI-Tools vor allem auf Anweisungen und erzeugten Code; künftig entwickeln sie sich weiter in Richtung Agentic
- Agentische KI plant, führt aus und überprüft Ziele selbst und arbeitet dadurch autonomer
- Claude (Anthropic), Cline und andere gehen bereits über einfache Autovervollständigung hinaus, starten automatisch Browser und führen Tests aus
- Auch der Debugging-Prozess verändert sich
- Ein Agent kann selbstständig potenzielle Probleme finden, Test-Suites ausführen und sogar den UI-Zustand prüfen, um Korrekturvorschläge zu machen
- Künftige Tools werden nicht nur Code behandeln
- Sie können mehrere Eingabekanäle wie UI-Screenshots, Diagramme oder Sprachdialoge verstehen und integrieren
- Was Entwickler in diesem Wandel tun müssen
- KI kreativ arbeiten lassen, dabei aber mit menschlicher Anleitung und innerhalb einer gesunden Architektur halten
- Eine starke Feedback-Schleife zwischen Mensch und KI aufbauen
- Erwartet wird ein Kollaborationsmodell, in dem Menschen den groben Rahmen und die Ziele setzen, während Agenten Detailarbeit übernehmen
- So wie es heißt, „die wichtigste Programmiersprache ist Englisch“, wird die Fähigkeit wichtiger, Anforderungen klar und präzise in natürlicher Sprache auszudrücken
Kehrt die Software-Handwerkskunst zurück?
- Dank KI lassen sich Prototypen und Demos schnell erstellen
- Doch sobald reale Nutzer Software in unterschiedlichen Umgebungen und Edge Cases verwenden, treten Probleme auf
- Fehlermeldungen, die für Nutzer unverständlich sind
- Spezielle Umgebungen, die Abstürze verursachen (Edge Cases)
- Designs, die Accessibility überhaupt nicht berücksichtigen
- Performance-Probleme auf langsamen Geräten
- Details wie UI/UX entscheiden über die Qualität
- Aus Verbrauchersicht braucht ein gut „polished“ Produkt Feingefühl und menschliche Sorgfalt
- Wenn KI Routinearbeit reduziert, können Entwickler sich stärker auf genau diese Details konzentrieren
- Sie können mehr Zeit in User Experience, Edge Cases und sinnvolle Fehlerbehandlung investieren – also in menschliche und zugleich professionelle Bereiche
Weitere Gedanken
- Der Software-Engineering-Prozess umfasst Planung, Design, Implementierung, Validierung, Monitoring, Wartung und weitere Bereiche; derzeit steigert KI vor allem den Bereich „Code schreiben“ deutlich in der Effizienz
- Schon früher gab es mit COBOL, Visual Basic oder No-code-Plattformen Versuche nach dem Motto „Auch Nicht-Entwickler können leicht Software bauen“, doch mit wachsender Komplexität wurden am Ende trotzdem erfahrene Entwickler gebraucht
- Je stärker LLM-Tools die Code-Menge explodieren lassen, desto mehr Senior Engineers werden in komplexen Projekten voraussichtlich benötigt
- Erfahrene Entwickler, die KI effektiv einsetzen können, werden ihren eigenen Wert weiter steigern können
- Insgesamt deutet vieles darauf hin, dass KI-Tools Entwickler nicht vollständig ersetzen, sondern eher Entwickler mit Einsicht und Erfahrung noch leistungsfähiger machen werden
Weitere Gedanken (inklusive Gergelys Kommentar)
- Der Anteil des eigentlichen Codings am Software Engineering war schon immer nicht besonders groß
- Fred Brooks teilte die Zeit in Softwareprojekten früher ungefähr so ein:
- ⅓ Planung
- ⅙ Coding
- ¼ Komponenten- und Systemtests
- ¼ Systemtest (alle Komponenten von Hand)
- Aus heutiger Sicht ist der Anteil für Coding (inklusive Tests) zwar gestiegen, aber Planung, Code Review, Monitoring und Rollout nehmen weiterhin einen wichtigen Teil ein
- 20 % Planung
- 40 % Coding (Code + Tests)
- 20 % Code Review (Code anderer)
- 20 % Produktionsvorbereitung + Rollout + kleine Korrekturen in dieser Phase + Monitoring + Alerts
- Der Prozess, gute Software zu bauen
- 1. What: Entscheiden, was gebaut werden soll
- Umfasst Brainstorming, Design, User-Tests sowie Zusammenarbeit mit Produktmanager:innen und Business-Stakeholdern
- In Startups kann diese Phase sehr kurz sein („erst bauen und dann Reaktionen sehen“)
- In etablierten Unternehmen kann die Entscheidung, was gebaut wird, mehr Zeit brauchen, damit bestehende Kunden nicht verwirrt werden
- 2. How: Planen, wie es gebaut werden soll
- Konkret ausarbeiten, wie Produkt, Feature oder Service implementiert werden sollen
- Architektur-Auswirkungen, Abhängigkeiten und Teststrategie berücksichtigen
- Startups können diesen Schritt überspringen und direkt loslegen, aber in großen Organisationen kann ignoriertes Vorab-Design später große Probleme verursachen
- Die meisten Teams durchlaufen einen gewissen Planungsprozess mit Design doc, RFC, ADR usw.
- 3. Build: Tatsächliche Implementierung
- Das gewünschte Feature oder Produkt in Code umsetzen und prüfen, ob es korrekt funktioniert
- 4. Verify: Verifizieren
- Vor dem Deployment in Produktion sorgfältig prüfen, ob alles wie erwartet funktioniert
- Besonders bei Finanzdienstleistungen, wo Fehlfunktionen gravierende Folgen haben können, wird der QA-Prozess sehr gründlich durchgeführt
- 5. Ship it: Ausliefern
- Änderungen mergen und an Kunden releasen
- Es gibt viele unterschiedliche Wege, in Produktion auszurollen
- 6. Monitoring and oncall: Monitoring und On-call
- Probleme im Produkt sofort erkennen und beheben
- Gleichzeitig Nachmaßnahmen treffen, damit derselbe Ausfall nicht erneut auftritt
- 7. Maintain: Warten
- Nutzerbeschwerden und Feedback sammeln und entscheiden, welche Bugs behoben und welche Verbesserungen priorisiert werden
- Dazu gehört auch, Feedback herauszufiltern, das ignoriert werden kann
- 8. Migrate: Migrieren
- Wenn sich das Produkt stark verändert oder der Tech-Stack wechselt, können große Migrationen nötig werden
- KI-Tools helfen derzeit stark in der Phase „Build“, aber es lohnt sich zu überlegen, wie nützlich sie auch in den übrigen sieben Bereichen sein können
- Seit den 1960er Jahren lebt der Traum weiter, dass Nicht-Entwickler ohne Entwickler Software bauen können
- Beispiele dafür sind COBOL, Visual Basic und No-code
- Einfache Websites lassen sich zwar ganz ohne Coding erstellen, aber bei komplexen Produkten ist Engineering weiterhin nötig
- Je ausdrucksstärker die Werkzeuge werden, desto detaillierter muss der KI beschrieben werden, „wie genau etwas funktionieren soll“ – und damit steigt die Komplexität
- Je mehr Code KI erzeugt, desto größer wird womöglich sogar der Bedarf an spezialisierten Engineers, die diesen Code warten und die Architektur beherrschen
- Senior-Entwickler, die heute lernen, mit LLMs zu arbeiten, werden produktiver und können in Unternehmen größeren Wert schaffen
KI-Agenten: ein großes Versprechen, aber 2025 auch noch „unbekanntes Terrain“
- Zwei Jahre nach dem Start der LLMs haben viele Entwickler gelernt, wie man LLMs für Coding und Software Engineering einsetzt
- LLMs leisten viel beim Prototyping, beim Wechsel in unbekannte Sprachen sowie bei der Prüfung der Ergebnisgenauigkeit und dem Erkennen falscher Antworten (Halluzinationen)
- KI-Agenten befinden sich jedoch noch in einem frühen Stadium
- Derzeit ist Devin praktisch der einzige breit verfügbare Agent, kostet mit 500 US-Dollar pro Monat aber viel, und die Bewertungen gehen auseinander
- Da viel Venture Capital in den Bereich fließt, werden voraussichtlich mehr KI-Coding-Agenten auf den Markt kommen
- Auch die Preise dürften nach und nach sinken
- GitHub Copilot wird 2025 voraussichtlich das agentenbasierte Copilot Workspace allgemein verfügbar machen
- Auch /dev/agents, gegründet vom ehemaligen Stripe-CTO, soll erscheinen
- KI-Agenten nehmen langsamere Antworten (einen „Denkprozess“) und höhere Kosten in Kauf, um bessere Genauigkeit zu erreichen
- Wie stark dieser Ansatz die Genauigkeit tatsächlich erhöht und in welchen Engineering-Szenarien er große Produktivitätsgewinne bringt, ist noch offen
Möglicherweise steigende Nachfrage nach erfahrenen Software Engineers
- Erfahrene Software Engineers (Senior und darüber) könnten noch stärker gefragt sein als heute
- Sie können KI-Tools effektiver einsetzen, wissen, wie „exzellente Ergebnisse“ aussehen, und können entsprechend präzise „anweisen“
- Wenn fehlerhafte Code-Generierung erkannt wird, können sie entscheiden, wann der Generierungsprozess gestoppt und der Source Code direkt manuell korrigiert werden sollte
- Mit Hilfe von KI-Tools wird voraussichtlich viel mehr Code geschrieben, und mehr Einzelpersonen und Unternehmen werden eigene Lösungen bauen
- Doch je größer die Komplexität wird, desto mehr braucht es erfahrene Engineers, die sie kontrollieren können
- Auch bestehende Tech-Unternehmen werden wahrscheinlich Personal brauchen, das die durch KI wachsende Komplexität bewältigt
- Software Engineers, die ihre Fähigkeit ausbauen, mit KI zusammenzuarbeiten, können produktiver und wertvoller werden
- Es braucht Zeit, Tools wirklich zu „zähmen“; deshalb ist es wichtig, in der sich schnell verändernden Tool-Landschaft aktiv zu experimentieren und zu lernen
11 Kommentare
Das ist wirklich ein sehr guter Beitrag.
Ich kann dem letzten Absatz über die „möglicherweise steigende Nachfrage nach erfahrenen Softwareingenieuren“ sehr zustimmen. Wahrscheinlich gilt eben: Man schreibt nur so gut, wie man es versteht, oder? ^^
Wie bei Expo 52 war selbst das clevere Claude in Bereichen, in denen es in letzter Zeit große Veränderungen gab, nicht besonders hilfreich.
Es schlug ständig veralteten oder bereits verschwundenen Code vor und war dadurch eher hinderlich.
Am Ende scheint man AI doch nur dann richtig nutzen zu können, wenn man selbst den geschulten Blick dafür hat.
Kleine Randbemerkung, aber soweit ich weiß, ist
/dev/agentskein Coding-Agent. Es ist noch nicht veröffentlicht, bezeichnet sich aber selbst als „OS für AI-Agenten“.Ich persönlich denke und setze darauf, dass in Zukunft (oder je nach Sichtweise mittelfristig) bei allen Ingenieurinnen und Ingenieuren die Rolle des Coders kleiner und die Rolle des TPM größer werden wird.
Da Cursor den Code besser schreibt, wird man das delegieren, und Menschen werden den Großteil der Arbeit eher auf der darüberliegenden abstrahierten Ebene erledigen.
Danke fürs Teilen. Ich habe dazu vor Kurzem ebenfalls einen Artikel geschrieben, und es gibt einige Ähnlichkeiten. https://www.stdy.blog/can-junior-beat-coding-agent/
Zusammenfassung: Die Zukunft der Entwickler im Zeitalter von AI (optimistische Version)
?? : Jetzt braucht man keine Entwickler mehr (KMU-Edition)
Meine Güte, hahaha
1+ haha
Haha, volle 100 Punkte