Mit KI zum Star Trek-Traum?
In den letzten Wochen herrschte auf den gängigen Nachrichtenportalen reges Treiben. Der Grund: JetBrains hat die vergangenen Monate intensiv daran gearbeitet, seine KI-Funktionen in verschiedenen Produkten zu erweitern – so auch in IntelliJ. Dort findet sich nun eine neue KI namens „Junie“: ein Programmieragent, welcher in der Lage sein soll, Aufgaben autonom zu lösen. Dazu der vielversprechende Slogan: „Delegate your tasks, focus on the results.“
Diese Vision deckt sich weitgehend mit meiner Vorstellung von der zukünftigen Arbeitsweise. Als langjähriger „Trekkie“ habe ich Jordie La Forge und Data stets um ihre Zusammenarbeit am Computer beneidet, wo sie durch einfache Sprachbefehle Code und Daten analysierten und ganze Programme starten sowie stoppen konnten. Heute erscheint dieser Weg realistischer denn je. Zwar existieren verschiedene, noch experimentelle Ansätze wie „Vibe Coding“ mit erheblichen Defiziten, insbesondere bei der Fehlersuche. Doch die Entwicklung schreitet voran. Es stellt sich daher die Frage: Sind wir Entwickler:innen bereits verloren? Wie realistisch ist es, durch eine KI wie Junie ersetzt zu werden?
IntelliJ ist eine integrierte Entwicklungsumgebung des Unternehmens JetBrains. Entwickelt wurde es überwiegend für die Java-Entwicklung, jedoch unterstützt es auch andere Programmiersprachen. IntelliJ bietet Werkzeuge für Codebearbeitung, Debugging, Refactoring, Versionskontrolle und Build-Automatisierung.
Doch nun zum Wesentlichen! Nach dem Start von IntelliJ und der Installation des Junie-Plugins präsentiert sich folgender Willkommensbildschirm:
Mein Vorhaben - Die Entwicklung von "Spring Factory" mithilfe Junie
Um den Projektumfang kurz abzustecken: Ich plane die Entwicklung einer Spring Boot Backend- und Angular Frontend-Applikation namens „SpringFactory“. Dieses Tool soll die Administration agiler Softwareentwicklungsteams erleichtern und somit zwei Ziele gleichzeitig verfolgen:
Einerseits benötige ich ein solches Werkzeug für meine eigene Arbeit, um meine Teammitglieder nicht ständig im Detail kontrollieren zu müssen, beispielsweise hinsichtlich der Zeiterfassung und der Eintragung von Punkten aus dem letzten Sprint. Stattdessen möchte ich diese Prozesse über ein zentrales Tool steuern.
Das Projektteam soll sich einloggen und die Sprints unkompliziert bestätigen können. Nach Ablauf eines Sprints sollen alle Teammitglieder alle drei Tage eine Erinnerung erhalten. Sobald alle Aufgaben abgenommen wurden, soll automatisch eine E-Mail an die Abrechnungsabteilung versendet werden, die dann die Fakturierung mit den Kund:innen übernimmt.
Dieses Tool bietet umfangreiche Ausbaumöglichkeiten. Persönlich reizt mich beispielsweise die Idee einer sprachgesteuerten Zeiterfassung; dies ist jedoch ein Vorhaben für die Zukunft. Momentan konzentriere ich mich auf die genannten zwei Kernfunktionen. Wir können dann gemeinsam prüfen, welche weiteren Vorschläge sich ergeben.
Los geht's - Vom Prompt bis zur Umsetzung
Damit kommen wir zum Kernpunkt! Was geschieht, wenn wir diese Anforderungen ins Englische übersetzen und sie Junie AI zur Bearbeitung übergeben:
I want to develop a full-stack application called „SpringFactory“ using Spring Boot for the backend and Angular for the frontend. The app will assist with the administration of agile software development teams.
The application should use MariaDB as the database.
The Angular frontend should integrate PrimeNG for UI components.
The main goals of this tool are:
Reduce micromanagement by allowing team members to self-manage sprint data. I want to avoid checking manually whether time and story points were entered after each sprint.
Sprint confirmation: Team members should be able to log in and confirm completed sprints easily.
Automated reminders: Every team member should receive a reminder every 3 days if the sprint has ended and not all confirmations are done.
Automated invoicing: Once a sprint is fully approved, an automatic email should be sent to the billing department, so they can proceed with invoicing the customer.
Der für mich anfangs interessanteste Aspekt ist, wie Junie die Applikation strukturieren wird. Hier eine verkürzte Darstellung des von Junie entwickelten Gesamtplans:
Set up the Spring Boot backend project structure
Create a Maven/Gradle project configuration
Set up Spring Boot application with necessary dependencies
Create proper directory structure for the project
Configure MariaDB connection
Create domain models for sprints, team members, etc.
Implement REST controllers for the required functionality
Set up the Angular frontend project structure
Create Angular application structure
Create package.json with Angular and PrimeNG dependencies
Create Angular configuration files
Implement core features
User authentication and authorization
Sprint management (creation, updating, confirmation)
Connect frontend and backend
Configure CORS
Implement API calls from Angular to Spring Boot
Auf den ersten Blick sieht das durchaus vielversprechend aus. Daher gebe ich Junie das „Go“, um mit der Arbeit zu beginnen. Dieser Prozess dauert nun eine Weile, aber nicht übermäßig lange. Hätte ich all diese Schritte manuell ausgeführt, hätte dies wahrscheinlich Stunden in Anspruch genommen. Die einzelnen Arbeitsschritte lassen sich unkompliziert nachverfolgen.
Überall dort, wo das grüne Symbol erscheint, können Sie nachvollziehen, an welcher Aufgabe die KI gerade arbeitet. Gelegentlich, wenn Junie die Unterstützung des:der Nutzer:in benötigt, erscheint eine Benachrichtigung, die auf die erforderliche Aktion hinweist.
Das Ganze sieht dann etwa so aus:
Nach Abschluss dieser Aufgabe können weitere Folgeaufträge über den Prompt ausgeführt werden. Die resultierende Struktur nach der Bearbeitung durch Junie sieht folgendermaßen aus:
Die erste Aufgabe: Umbenennung des Packages
Mein erster Folgeauftrag besteht darin, das Package in ciit.at.springfactory umzubenennen. Dies erfordert, dass Junie sämtliche Package-Pfade anpasst. Es wird interessant zu sehen sein, wie diese Änderung in den Klassen umgesetzt wird.
Junie nimmt den:die Nutzer:in mit auf eine nachvollziehbare Reise ihrer geplanten Änderungen.
Das dauert schon ein paar Minuten. In diesem Fall wäre also ein einfaches Renaming wesentlich schneller gegangen.
Die Herangehensweise von Junie ist nämlich folgende:
- Erstelle den Ordner ciit.at.springfactory
- Dann erstelle alle subdirectories und kopiere den Content hinüber.
- Danach passe die Packages an und erstelle die einzelnen Files.
Dieser Zeit- und Ressourcenaufwand ist natürlich ineffizient, da der gesamte Prozess mehr als zehn Minuten in Anspruch nimmt.
Wie fehleranfällig ist die Anwendung?
Im Anschluss werde ich versuchen, die Applikation erstmalig zu starten. Dadurch überprüfen wir die Robustheit der von Junie KI erstellten Applikation.
Das Ergebnis entspricht nicht meinen Erwartungen. Obwohl die Aufgabe erfüllt wurde, erfolgte lediglich ein simples Kopieren der Dateien, was potenziell zu Fehlern führen kann.
Diesen Schritt habe ich nun manuell durchgeführt, um die gewünschte Ausgangssituation zu schaffen. Abschließend muss noch das Maven-Verzeichnis eingelesen werden, bevor es losgehen kann.
Zum Schluss analysieren wir den Code.
Code-Analyse und ein holpriger Start
Bei der ersten Betrachtung der Entity fällt sofort die Lombok-Annotation @Data auf. IntelliJ selbst kennzeichnet deren Verwendung hier nicht als ideal.
Der Grund dafür liegt in der potenziell fehlerhaften Anwendung der equals- und hashCode-Methoden, da diese eigentlich nur die ID berücksichtigen sollten. Dieses Problem lässt sich einfach beheben, indem wir die Generierung dieser beiden Methoden manuell über IntelliJ vornehmen.
Die übrigen Entitäten scheinen auf den ersten Blick in Ordnung zu sein. Beim anschließenden Versuch, die Applikation zu starten, stelle ich jedoch fest, dass dies nicht möglich war. Der integrierte KI-Assistent lieferte hierfür jedoch relativ schnell die Lösung: Es fehlte die NPM-Installation. Darüber hinaus sind noch zahlreiche weitere Module nicht vorhanden, deren Auflösung nun die Aufgabe des:der Programmierenden ist. Also meine Aufgabe!
Nachdem ich alle Module selbst bereinigt habe und auch ein paar andere Kleinigkeiten behoben habe, startet die Applikation! Was sofort auffällt, ist, dass das UI dringend verbessert werden muss, aber auch das liegt jetzt in meiner Hand.
Der Startscreen der Anwendung zeigt Folgendes:
Junie hilft, aber ersetzt nicht - Mein Fazit
Junie AI erweist sich als äußerst nützliches Werkzeug für kleinere Lernprojekte sowie für umfangreichere Vorhaben, bei denen eine hohe Produktivität angestrebt wird. Allerdings sehe ich auch potenzielle Probleme, insbesondere wenn diese KIs von unerfahrenen Programmierer:innen eingesetzt werden. Denn die Notwendigkeit, den Code zu kontrollieren und zu verstehen – beispielsweise im Falle von Fehlern oder bei der Durchführung von Performance-Optimierungen – bleibt weiterhin bestehen. Junior-Entwickler:innen könnten sich zu stark auf KI-Tools verlassen, um Code zu generieren, ohne die zugrundeliegenden Konzepte und Prinzipien wirklich zu verstehen.
Dies kann dazu führen, dass sie Schwierigkeiten haben, Probleme selbstständig zu lösen, Code zu debuggen oder fundierte Entscheidungen über Architektur und Design zu treffen. Diese Dinge ausnahmslos einer KI zu überlassen, kann später in der Entwicklung zu fatalen Problemen führen.
Die Fehlersuche und das Debuggen von Code sind entscheidende Lernprozesse in der Softwareentwicklung. Wenn KI-Tools Fehler automatisch korrigieren oder Lösungen vorschlagen, ohne dass Junior-Entwickler:innen den Fehler und seine Ursache verstehen, gehen wertvolle Lernmomente verloren.
Daher finde ich Junior-Entwickler:innen sollten KI als Werkzeug zur Unterstützung und Beschleunigung ihrer Arbeit nutzen, aber nicht als Ersatz für das Erlernen der Grundlagen und die Entwicklung ihrer eigenen Fähigkeiten sehen.
Senior-Entwickler:innen, die sich zu stark auf KI verlassen, könnten mit der Zeit ihre direkten Programmierkenntnisse und ihr tiefes Verständnis für Low-Level-Details vernachlässigen. In kritischen Situationen, in denen die KI keine adäquate Lösung bietet oder ein sehr spezifisches Problem auftritt, könnte dies zu Schwierigkeiten führen. Senior-Entwickler:innen tragen oft die Verantwortung für die Architektur und die langfristige Wartbarkeit von Systemen. KI-generierter Code muss nahtlos in bestehende Architekturen integriert werden und auch in Zukunft verständlich und wartbar bleiben.
