Der Softwarehersteller JetBrains hat zahlreiche seiner Entwicklungsumgebungen in Version 2025.3 veröffentlicht, darunter das vorrangig auf Java und Kotlin ausgelegte IntelliJ IDEA, WebStorm für JavaScript/TypeScript sowie PyCharm für Python. Die IDEs verbindet, dass sie nun im neuen Islands Theme erscheinen. Daneben gibt es spezifische Updates für die jeweiligen Einsatzzwecke.

IntelliJ IDEA: Wechsel zu K2 und Support für Java 25

IntelliJ IDEA 2025.3 bietet unter anderem Support für die aktuellen Versionen Spring Boot 4, Spring Framework 7, Java 25 und Vitest 4. Auch hat das Entwicklungsteam den K1-Modus für Kotlin nun als deprecated (veraltet) markiert, da es zum K2-Modus migriert. Der neuere K2-Compiler gilt seit dem Release von Kotlin 2.0 vor rund eineinhalb Jahren als stabil und soll deutliche Performance-Verbesserungen ermöglichen.

Updates gibt es auch für einige Funktionen: Unter anderem zeigte Find Usages bisher nur Dateinamen an, was in komplexen Codebasen nicht immer eindeutig war. Jetzt werden teils auch relative Pfade angezeigt. Für die Barrierefreiheit hat das JetBrains-Team die Funktionsweise der Lupe in Windows korrigiert und viele UI-Bereiche für den Umgang mit Screenreadern verbessert. Zudem ist inzwischen nativer Support für die KI-Agenten Junie und Claude Agent vorhanden. Insgesamt wurden in diesem Release 800 Bug-Reports und Usability-Schwierigkeiten behoben.

Darüber hinaus ändert sich etwas Grundlegendes bei IntelliJ IDEA: Die Ultimate Edition und die Community Edition werden nun als eine einzige Distribution gehandhabt, statt wie bisher separat. Das soll den Entwicklungsprozess vonseiten JetBrains vereinfachen. Eine ähnliche Neuerung gibt es bei PyCharm, wo die Community Edition und die Pro Edition zusammengelegt wurden. Direkt aus der IDE heraus lässt sich dort die kostenpflichtige Pro-Version ausprobieren.

Islands Theme in JetBrains-IDEs

Nicht nur IntelliJ IDEA, sondern auch die weiteren JetBrains-IDEs nutzen in Version 2025.3 das Islands Theme. Diese neue Standardansicht soll klarer und verständlicher sein. Unter anderem bietet es abgerundete Ecken, veränderte Abstände und eine deutlicher sichtbare Begrenzung von Toolfenstern. Auch sind aktive Tabs nun klarer markiert als zuvor, wie JetBrains demonstriert:

Detaillierte Informationen zu IntelliJ IDEA 2025.3 liefern der Blogeintrag zur Ankündigung, die „What’s New“-Seite und die „What’s Fixed“-Seite

Die Version 2025.3 haben auch weitere IDEs wie PyCharm, PhpStorm, GoLand, WebStorm und CLion erreicht. Die Entwicklung der IDE Fleet wurde dagegen beendet, zugunsten einer darauf aufbauenden, geplanten neuen IDE mit Fokus auf Agentic Development.

(mai)

Die Idee von selbstorganisierten Teams, von Produkt- und Sprintzielen ist in vielen Unternehmen mehr Wunschdenken als Realität. Wenn ich die Zusammenarbeit mit einem neuen Kunden beginne, versuche ich natürlich in Erfahrung zu bringen, woran die Teams arbeiten. Einmal hat mir ein Team auf die Frage „An welchem Produkt, an welcher Software arbeitet ihr?“ Geantwortet: „Keine Ahnung.“ Die Leute wussten buchstäblich nicht, wofür sie Software entwickelten.

Wie kann das sein? Die Antwort war in diesem Fall einfach: Die verschiedenen Programme, an denen der Unternehmensbereich arbeitete, waren in Komponenten in Form von Microservices heruntergebrochen, die wiederum einzelnen Teams zugeordnet waren. In der Folge hat das besagte Team Aufgaben bekommen, die isoliert betrachtet keinen erkennbaren geschäftlichen Sinn hatten.

Die Teammitglieder waren nicht mehr als Coding Monkeys. Ihre Innovationsfähigkeit, ihre Fähigkeit, Dinge zu hinterfragen, ihr Potenzial, einen Beitrag zu leisten, waren strukturell ausgemerzt.

Wenn man vor dem Hintergrund einer solchen Organisationsstruktur zu dem Schluss kommt, dass man Coding-Leistung durch KI bekommen kann, ist das weder ein Urteil über die menschlichen Programmierer noch ein Lob an die KI. Es ist nicht mehr als die Folge früherer Entscheidungen der Manager, nicht nur die Software in Microservices zu gliedern, sondern auch die Organisation. Für die Entwickler ist das meist keine erfüllende Tätigkeit.

Verschobene Auswirkungen

Nicht zuletzt deshalb war das auch schon vor der jüngsten KI-Welle eine blöde Idee. Inzwischen haben sich allerdings die Auswirkungen verschoben. Früher lag der finanzielle Schaden durch wenig motivierte, wenig kreative Programmierer ausschließlich bei den Unternehmen. Bei den Entwicklern gab es vielleicht mentale Schäden, die sich zuerst als Unzufriedenheit zeigten.

Heute jedoch können die Entwickler die finanziellen Schäden abbekommen, nämlich dann, wenn sie ihren Job verlieren. Für die Unternehmen wird es nur billiger, nicht besser.

Wenn Entwickler und Entwicklerinnen sich heute gegen KI-Gefahren in diesem Szenario wehren wollen, gibt es einen klaren Rat: Sorgt dafür, dass Ihr innerhalb des Business relevant seid! Das bedeutet insbesondere ein stärkeres Einmischen in die geschäftliche Zielsetzung. Wir sind gerade in einer Phase, in der Technik (durch KI) wichtiger wird. Wer Technik in der Tiefe versteht, kann jetzt mehr denn je einen Beitrag zum geschäftlichen Erfolg leisten. Dazu gehört auch, ein Stück Führung zu übernehmen, damit die geschäftliche Zielsetzung auf einem soliden technischen Fundament steht.

Erst Lesen, dann Handeln

Wenn Du die Themen, die ich im Blog anspreche, in Deiner Firma verbessern möchtest, komm’ in unsere Leadership-Community für Softwareentwicklung. Sie wirkt auch ohne Führungsposition. Mit dem Code „heisedev“ gibt es den Heise-Rabatt für Interactive Members.

(rme)

Auf seiner diesjährigen Hausmesse re:Invent machte AWS unmissverständlich klar, wohin die Reise geht: Agentische KI-Systeme sollen künftig nicht nur einfache Aufgaben erledigen, sondern stunden- oder sogar tagelang autonom arbeiten. Mit den sogenannten Frontier Agents kündigte Amazon eine neue Generation von KI-Agenten an, die ohne ständige menschliche Anleitung persistente Kontexte aufrechterhalten und komplexe Workflows bewältigen sollen.

Im Mittelpunkt stehen drei spezialisierte Agenten, die den Software-Entwicklungszyklus transformieren sollen. Der Kiro Autonomous Agent fungiert als virtueller Entwickler, der Backlogs abarbeitet, Bugs klassifiziert sowie priorisiert und Aufgaben über mehrere Code-Repositories hinweg eigenständig löst. Dabei lernt er kontinuierlich aus Feedback und Pull-Requests. Der AWS Security Agent übernimmt die Rolle eines virtuellen Sicherheitsberaters: Er überprüft Designdokumente und Pull-Requests auf Schwachstellen, orientiert sich dabei an organisationsspezifischen Vorgaben und verwandelt zeitaufwendige Penetrationstests in eine On-Demand-Funktion. Komplettiert wird das Trio durch den AWS DevOps Agent, der als Teil des operativen Teams Vorfälle diagnostiziert, Telemetrie- und Bereitstellungsdaten korreliert und proaktiv Verbesserungen vorschlägt.

Bedrock AgentCore wird erweitert

Die zentrale Plattform für den Betrieb dieser Agenten, Amazon Bedrock AgentCore, erhielt drei wesentliche Erweiterungen. Mit AgentCore Policy lassen sich nun in natürlicher Sprache formulierte Richtlinien, sogenannte Guardrails, durchsetzen, die unbefugte Agentenaktionen in Echtzeit blockieren. AgentCore Evaluations bietet 13 vorgefertigte Metriken zur Qualitätssicherung, etwa für Korrektheit und Kontextrelevanz. AgentCore Memory, ein episodischer Speicher, ermöglicht es Agenten, aus vergangenen Interaktionen zu lernen und ihre Entscheidungsfindung anzupassen.

Ergänzt wird das Portfolio durch Amazon Nova Act, einen Dienst zur Automatisierung von Browser-UI-Workflows, der laut AWS eine Zuverlässigkeit von 90 Prozent erreicht. Auch das Open Source KI-Agenten-SDK Strands Agents, das AWS erst im Mai diesen Jahres vorgestellt hatte und zunächst auf Python fokussiert war, wurde um TypeScript-Unterstützung erweitert und läuft nun auf Edge-Geräten für Automotive- und Robotik-Anwendungen.

Warnung vor explodierenden Kosten

Bei aller technischen Raffinesse hat die wirtschaftliche Seite der Agentisierung einen deutlichen Haken. Jeff Boudier, Chief Product & Growth Officer bei Hugging Face, ordnet in einem Gespräch mit der iX ein, dass der Einsatz von KI-Agenten grundsätzlich sorgfältig hinterfragt werden müsse. Der Übergang von klassischen LLM-Anwendungen hin zu agentischen Systemen führe aufgrund ihrer iterativen Arbeitsweise zu einem drastisch höheren Rechenaufwand.

„Anstatt dass eine Nutzeranfrage etwa einen Cent kostet, liegen wir bei agentischen Systemen schnell bei drei, fünf oder sogar mehr Dollar“, erklärt Boudier. „Dieser Wandel wird im kommenden Jahr noch eine enorme Menge an Engineering-Arbeit auslösen, um diese Kosten wieder zu senken.“

Unternehmen müssen sich deshalb vorab fragen, ob sie für einen konkreten Anwendungsfall überhaupt einen Agenten benötigen, welchen Wert eine korrekte Antwort hat und wie hoch das Risiko ist, wenn ein Agent falsche Entscheidungen trifft. Auch ob die von AWS versprochene Zuverlässigkeit und Skalierbarkeit ihrer Agenten die Mehrkosten rechtfertigen, wird sich erst in der Praxis zeigen müssen.

(fo)