Connect with us

Entwicklung & Code

Zwischen Tempo und Tragfähigkeit: KI-Agenten in der Softwareentwicklung


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.


Portrait Marius Wichtner

Portrait Marius Wichtner

Marius Wichtner ist Software Engineer bei MaibornWolff und beschäftigt sich intensiv mit Softwarearchitektur, Clean Code und dem Einsatz generativer KI im Entwicklungsprozess. In verschiedenen Kundenprojekten entwickelt er Strategien, wie Agenten sinnvoll in bestehende Systeme integriert werden können, mit einem besonderen Fokus auf nachhaltige Codequalität und Entwicklererfahrung.


Portrait Venko Kisev

Portrait Venko Kisev

Venko Kisev leitet die Software-Health-Check- und Modernisierungsabteilung bei MaibornWolff. In den letzten 15 Jahren hat er zahlreiche Analyse- und Modernisierungsprojekte mit seinem Team geleitet und mit führenden Unternehmen aus diversen Branchen zusammengearbeitet – zunehmend mit Fokus auf den sinnvollen und verantwortungsvollen Einsatz von KI.

Agentic Coding ist zu einem festen Bestandteil des Entwicklungsalltags geworden. KI-Agenten planen, implementieren, testen und dokumentieren Code in kurzer Zeit. Teams orchestrieren spezialisierte Assistenten, statt jede Änderung von Hand zu schreiben. Neben KI-Assistenten wie GitHub Copilot und Chat-Modelle wie ChatGPT treten autonome Agenten, die ganze Entwicklungsschritte übernehmen.

Weiterlesen nach der Anzeige

Die Taktzahl steigt, doch der Bedarf an Leitplanken ebenso. Funktional korrekter Code reicht nicht, wenn Sicherheitsvorgaben, Latenzziele, Skalierbarkeit und Architekturkonventionen unbeachtet bleiben. Ohne ausreichendes Kontextwissen entfernen sich Systeme schleichend von ihrer ursprünglichen Architektur, Tests verlieren an Treffsicherheit und technische Schuld wächst.

Wie lassen sich Agenten in bestehende Softwarelandschaften integrieren, wo liegen ihre Grenzen bei nicht-funktionalen Anforderungen? Welche Rollen und Prozesse tragen sie in der Praxis und welche Prüfungen in Pipelines helfen, Tempo und Tragfähigkeit zusammenzubringen? Fragen wie diese beantwortet der vorliegende Artikel.

Agentic Coding bezeichnet die Entwicklung mit KI Agenten, einzeln oder im Zusammenspiel mehrerer spezialisierter Agenten, je nachdem, welche Aufgaben im Projekt anstehen, wie groß die Codebasis ist und welche Art von Änderung umgesetzt werden soll. Anders als assistierende Tools begleiten sie nicht nur punktuell, sondern setzen definierte Ziele weitgehend autonom um. Sie planen Aufgaben, ändern Code, erzeugen Tests, dokumentieren Entscheidungen und führen Korrekturschleifen selbstständig aus. Der Mensch definiert Ziele und Regeln, prüft die Ergebnisse und trifft Architekturentscheidungen.

Von Autovervollständigung zur Architekturverantwortung

Weiterlesen nach der Anzeige

Neben GitHub Copilot und den Chatmodellen von Anthropic und OpenAI (ChatGPT) gibt es inzwischen eine neue Klasse von Werkzeugen: autonome Agenten. Sie übernehmen ganze Entwicklungsschritte von der Planung bis zur Integration. Man findet sie heute als IDE-Integrationen, etwa in Visual-Studio-Code-Forks wie Windsurf und Cursor, als Terminal-integrierte Agenten wie Anthropics Claude Code oder OpenAIs Codex sowie als quelloffene Software wie OpenCode.

Diese Agenten entwerfen APIs, orchestrieren Tests-Suites, erkennen Sicherheitslücken oder strukturieren Legacy-Module um, ohne deren Verhalten zu ändern. Teilweise greifen sie dabei auf externe Wissensquellen zu, dokumentieren ihre Entscheidungen und führen selbstständig Korrekturschleifen durch. Dabei entsteht ein neues Arbeitsmodell: Entwicklerinnen und Entwickler interagieren nicht mehr mit einzelnen Tools, sondern orchestrieren ein Team spezialisierter Agenten. Dieser Wandel erfolgt nicht nur auf technischer Ebene, sondern auch in der Art, wie Projekte strukturiert und verantwortet werden.

Diese Entwicklung eröffnet viele Möglichkeiten, aber sie verschiebt auch die Verantwortung. Denn je mehr operative Aufgaben Agenten übernehmen, desto wichtiger wird die Fähigkeit, konzeptionelle Leitplanken zu setzen. Wer entscheidet, ob eine Lösung tragfähig ist? Wer kontrolliert, ob der erzeugte Code zur Zielarchitektur passt? Und was passiert, wenn Agenten sich widersprechen, nicht-funktionale Anforderungen ignorieren oder eigene Annahmen treffen, die fachlich nicht gewünscht sind?

Agentic Coding ist keine lineare Fortsetzung der Automatisierung, sondern eine neue Phase: Entscheidungen verlagern sich, Prozesse beschleunigen sich, Erwartungen verändern sich. Und genau deshalb braucht es einen reflektierten Umgang, und das nicht nur mit den Werkzeugen, sondern mit der Haltung zur Entwicklung selbst.

Wo Agenten an Grenzen stoßen: nicht-funktionale Anforderungen

Agentic Coding zeigt eindrucksvoll, wie weit KI-gestützte Automatisierung inzwischen reicht. KI-Agenten übernehmen funktionale Aufgaben zunehmend zuverlässig: Sie entwerfen eine API, validieren ein Formular, integrieren eine Datenbankabfrage oft schneller als ein Mensch es kann. Die Ergebnisse sind jedoch nicht immer technisch korrekt; erst mit Expertenwissen und der Kontrolle nicht-funktionaler Anforderungen werden sie verlässlich, gut dokumentiert, lauffähig und auch deploybar.

Denn funktional heißt nicht belastbar. Denn sobald Anforderungen ins Spiel kommen, die über das reine „Was soll die Software tun“ hinausgehen – etwa wie schnell sie reagieren muss, wie sicher oder wartbar sie sein soll – entstehen neue Lücken. Genau hier beginnt der Bereich der nicht-funktionalen Anforderungen und mit ihm die typischen Schwächen heutiger Agenten.

Nicht-funktionale Anforderungen beschreiben das „Wie“ eines Systems: Wie performant soll ein Service unter Last reagieren? Wie sicher sind Schnittstellen gegen Angriffe geschützt? Wie skalierbar ist ein neues Modul, wenn sich das Geschäftsmodell ändert? Welche Architekturkonventionen gilt es einzuhalten, um langfristig wartbare Systeme zu erhalten?

Solche Anforderungen sind selten direkt aus einem Prompt ableitbar. Sie sind oft implizit, kontextabhängig, unternehmensspezifisch und dynamisch. Viele Entscheidungen in einer Software haben kausale Abhängigkeiten, beispielsweise weil ein anderes Team Vorgaben gemacht oder eine bestimmte Lösung gewählt hat. Oft entstehen Anforderungen auch erst im Verlauf: Skalierbarkeit wird erst wichtig, wenn die Nutzerzahlen wachsen; Latenzanforderungen, wenn Echtzeitfunktionen kommen. Solche Zusammenhänge lassen sich kaum in einen kurzen Prompt pressen. Agenten, die nur lokal operieren (also auf einzelne Dateien oder Tasks fokussiert sind), haben keinen Blick für diese übergeordneten Aspekte.

Beispiel: Risiko statt Produktivität

Ein Beispiel: Ein Agent generiert eine neue REST-API in Rekordzeit, inklusive Tests und Dokumentation. Technisch korrekt, syntaktisch sauber, aber ohne Einbindung in bestehende Sicherheitsmechanismen, ohne Logging-Konzept und ohne Rücksicht auf Latenz oder Skalierbarkeit. Was auf den ersten Blick nach Produktivität aussieht, wird auf Systemebene schnell zum Risiko.

Ähnlich verhält es sich mit Architekturentscheidungen. Agenten arbeiten kontextbezogen, aber nur mit den Informationen, die sie zur Verfügung haben. Ob ein Modul in eine bestehende Schichtenarchitektur passt, ob bestehende Regeln verletzt werden oder ob zyklische Abhängigkeiten entstehen, bleibt ohne zusätzliche Kontrollmechanismen häufig unbemerkt. Fehlentscheidungen schleichen sich nicht ein, sondern sie skalieren sofort.

Ein Agent kann eine Methode korrekt implementieren, aber nicht erkennen, dass sie in einem sicherheitskritischen Pfad liegt. Er kann Tests schreiben, aber nicht bewerten, ob sie die geschäftskritische Logik tatsächlich absichern. Er kann den Code umstrukturieren, ohne zu wissen, dass er damit einen regulatorischen Rahmen berührt.

In der Praxis führt das zu einem paradoxen Effekt: Systeme entstehen schneller, wirken auf den ersten Blick vollständig und erzeugen dennoch technische Schuld, weil zentrale Qualitätsmerkmale fehlen.

Auch in puncto Testabdeckung zeigt sich ein wiederkehrendes Muster: Es entstehen zwar viele Tests, aber nicht zwingend die richtigen. Oft werden triviale Fälle abgedeckt, während Randbedingungen, Fehlerpfade oder geschäftskritische Logik unberücksichtigt bleiben. Die Illusion von Testabdeckung ersetzt keine belastbare Qualitätsstrategie.

Zusätzlich entstehen neue Herausforderungen auf der Metaebene: Wer kontrolliert den Output? Welche Rolle spielt menschliches Review, wenn Agenten Dutzende Commits pro Stunde erzeugen? Welche Metriken helfen bei der Bewertung? Und wie lässt sich verhindern, dass technische Schuld nicht nur bestehen bleibt, sondern automatisiert weiterwächst?



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

Sulu 3.0: CMS mit neuem Content-Speicher und klarerer Architektur


Sulu 3.0 ist erschienen. Mit dem Release vollzieht das quelloffene Content-Management-System (CMS) laut Blogbeitrag eine größere technische Umstrukturierung. Statt auf das bislang genutzte PHPCR‑Repository setzt das Projekt künftig vollständig auf Doctrine ORM und JSON‑Felder – eine Entscheidung, die nicht nur die Performance heben, sondern auch die Einstiegshürde für Symfony‑Entwickler senken soll. Nach Angaben des Teams kamen rund 150.000 Zeilen Code neu hinzu, mehr als 265.000 wurden entfernt.

Weiterlesen nach der Anzeige

Das Open-Source-CMS Sulu basiert auf dem PHP-Framework Symfony und dient als Headless‑ oder klassisches CMS für komplexe, mehrsprachige Webprojekte. Es richtet sich vor allem an Entwicklerinnen und Entwickler, die flexible Inhaltsmodelle mit vertrauten Symfony‑Werkzeugen umsetzen wollen. Für Symfony sind kürzlich die Versionen 7.4 und 8.0 erschienen.

Von PHPCR zu Doctrine ORM

Mit der Abkehr vom speicherintensiven PHPCR führt Sulu ein neues Modell zur Ablage von Inhalten ein: Seiten, Artikel oder Snippets werden jetzt als reguläre Doctrine‑Entitäten mit JSON‑Spalten verwaltet. Damit greifen Developer direkt auf bekannte Tools und SQL‑Abfragen zurück, statt eine eigene Query‑Sprache lernen zu müssen.

Das System nutzt sogenannte Dimensionen, um Sprach‑, Veröffentlichungs‑ und Versionszustände abzubilden. So lassen sich nicht übersetzbare Felder in mehreren Sprachvarianten weiterverwenden – ein Ansatz, der die vorherige, tiefer verschachtelte Struktur ersetzt und sich offenbar leichter debuggen lässt.

Bessere Performance und Vereinfachungen

Nach Angaben des Teams bringt der neue Speicheransatz spürbare Leistungsgewinne. Content‑Strukturen lassen sich nun direkt in der Datenbank nachvollziehen, während Konfigurationsdaten weiterhin als XML im Repository bleiben.

Weiterlesen nach der Anzeige

Auch das Update der PHP-Bibliothek Flysystem auf Version 3 soll zur Vereinfachung der Handhabung von Mediendateien beitragen. Diese können künftig über eine einheitliche Schnittstelle auf unterschiedlichen Backends abgelegt werden, beispielsweise auf Amazon S3, Microsoft Azure, WebDAV oder Dropbox.

Entfall der Elasticsearch‑Pflicht für Artikel

Neben der Speicherarchitektur wurde das Artikel‑Bundle neu geschrieben. Es lässt sich nun ohne die Suchmaschine und das Analytic-Tool Elasticsearch betreiben, wodurch kleineren Projekten die Installation eines separaten Suchdienstes erspart bleiben soll. Für große Installationen bleibt die Option durch ein ergänzendes Bundle erhalten, das Elasticsearch wieder einbindet.

Ebenfalls neu ist SEAL, der Search Engine Abstraction Layer. Er bündelt Anbindungen an Suchsysteme wie Loupe, Meilisearch, Solr oder Elasticsearch hinter einer gemeinsamen API. Standardmäßig kommt Loupe zum Einsatz – eine SQLite‑basierte, PHP‑interne Lösung, die für mittlere Datenmengen ausreichend schnell arbeitet.

Migration und Unterstützung

Sulu liefert ein eigenes Tool, um vorhandene PHPCR‑Daten zu konvertieren. Das Migration‑Bundle überführt Seiten, Artikel, Snippets und URLs in die neue Speicherstruktur und protokolliert detailliert, wo gegebenenfalls Nacharbeit nötig ist.

Wer die Umstellung nicht allein durchführen möchte, kann laut Entwicklerteam auf Community‑Hilfe via Slack und GitHub oder auf professionelle Unterstützung zurückgreifen. Weitere Informationen zur Hilfe sowie zum Release finden sich im Blogbeitrag.

Weiterer Fahrplan

Mit Version 3.0 endet die Pflege für Sulu 1.6, während Sulu 2.6 als LTS-Version (Long-term Support) erhalten bleibt. Die neue Architektur soll künftige Funktionen erleichtern und das CMS langfristig wartbarer machen. Näheres zum Release und zum CMS auch auf GitHub.


(mdo)



Source link

Weiterlesen

Entwicklung & Code

Drupal Canvas: Visueller Page Builder für Drupal veröffentlicht


Drupal hat mit Canvas einen visuellen Page Builder veröffentlicht, der die Erstellung individueller Websites ohne umfangreiche Programmierkenntnisse ermöglichen soll. Das Werkzeug richtet sich an Site-Builder und Content-Teams, die bisher zwischen vorgefertigten Templates und aufwendiger individueller Entwicklung wählen mussten.

Weiterlesen nach der Anzeige

Weniger komplizierte Technik für Anwender

Als Open-Source-CMS kommt Drupal zwar bei vielen Organisationen zum Einsatz, die Flexibilität des Systems erforderte jedoch bislang einiges an technischem Know-how. Wie Produktleiter Lauri Timmanee im Drupal-Blog erklärt, existiere in Drupal ein Trade-off: „Entweder man ist gezwungen, eine Art Cookie-Cutter-Website zu erstellen, oder man muss komplexen Code schreiben. Wir wollen diesen Trade-off aufbrechen, indem wir bessere Werkzeuge bereitstellen, damit man tatsächlich Websites erstellen kann, die auf die eigene Marke zugeschnitten sind, ohne komplexen Code kennen zu müssen.“

Drupal Canvas 1.0 basiert auf einem React-Frontend, das mit den Core-APIs von Drupal integriert ist. Die Hauptfunktionen umfassen komponentenbasiertes visuelles Page Building mit einem Drag-and-Drop-Interface, In-Browser-Code-Komponenten zum Hinzufügen neuer Bausteine sowie die Option, mehrere Seiten vor der Veröffentlichung zu erstellen und mit mehrstufigem Undo in der Vorschau zu betrachten. Das System soll Entwicklern mehr Zeit für tiefgreifende technische Arbeiten verschaffen, während nicht-technische Nutzer eigenständiger arbeiten können.

Canvas ist als Community-getriebenes Projekt angelegt, laut Drupal-Roadmap sollen künftig möglichst alle Module im kommenden Drupal CMS 2.0 mit Canvas kompatibel sein. Die Entwickler stellen eine Demo-Installation auf GitHub bereit und sammeln Feedback über den dedizierten Slack-Channel #drupal-canvas. Das Projekt positioniert sich damit in Konkurrenz zu etablierten Page Buildern wie WordPress Gutenberg oder Elementor, setzt aber auf die Stärken von Drupal in Enterprise-Umgebungen.

Ausblick auf Drupal CMS 2.0

Drupal CMS ist eine vorkonfigurierte Distribution auf Basis von Drupal Core, die für schnelle Website-Erstellung mit vorgefertigten Modulen und Workflows optimiert ist, während Drupal Core die minimale, flexible Grundlage für Entwickler bietet. Inzwischen steht Drupal CMS kurz vor der Veröffentlichung der Version 2.0, die laut mehreren Drupal-Experten einen großen Entwicklungssprung für Webentwickler und Nutzer bringen soll. Die neue Generation der Software soll eine verbesserte Performance, modernisierte Benutzeroberfläche und vereinfachte Integrationsmöglichkeiten für KI-gestützte Tools bieten.

Weiterlesen nach der Anzeige

Neben den technischen Verbesserungen soll Drupal CMS 2.0 besonderen Wert auf Barrierefreiheit, Sicherheit und modulare Erweiterbarkeit legen. Durch ein überarbeitetes Framework und optimierte Workflows sollen Entwickler Projekte schneller umsetzen können, während Redakteure von einer klareren Struktur und KI-gestützten Funktionen wie Content-Generierung und SEO-Optimierung profitieren sollen. Das offizielle Release ist aktuell für das erste Quartal 2026 anvisiert, ursprünglich war es für den Oktober 2025 geplant.


(fo)



Source link

Weiterlesen

Entwicklung & Code

Open-Source-Toolkit: KI-Unternehmen Anthropic übernimmt Bun


Bun wurde von Anthropic übernommen, wie der Bun-Erfinder Jarred Sumner auf dem Bun-Blog mitteilt. Das JavaScript-Toolkit, bestehend aus Runtime, Bundler, Test Runner und Paketmanager, soll die Infrastruktur für Anthropics KI-Coding-Technologien Claude Code und Claude Agent SDK sowie künftige KI-Coding-Projekte darstellen.

Weiterlesen nach der Anzeige

Bun bleibt Open Source

Laut Sumners Ausführungen wird Bun auch weiterhin Open Source und MIT-lizenziert bleiben. Auch soll das gleiche Team wie bisher an Bun arbeiten und die Entwicklung weiter öffentlich auf GitHub stattfinden. Die Roadmap soll den Fokus auf Performance und Node.js-Kompatibilität beibehalten – und darauf, Node.js als die standardmäßige serverseitige Runtime für JavaScript zu ersetzen.




(Bild: jaboy/123rf.com)

Die enterJS 2026 wird am 16. und 17. Juni in Mannheim stattfinden. Das Programm wird sich rund um JavaScript und TypeScript, Frameworks, Tools und Bibliotheken, Security, UX und mehr drehen. Vergünstigte Blind-Bird-Tickets sind bis zum Programmstart erhältlich.

Bun erschien erstmals im Juli 2022 und verfolgte bereits damals das Ziel, ein „Drop-in“-Ersatz für Node.js zu werden. Schon innerhalb der ersten Woche erzielte das Projekt 20.000 GitHub-Sterne, wie sich der Bun-Erfinder zurückerinnert. Inzwischen ist die Zahl auf über 83.000 Sterne angestiegen und präsentiert sich seit Version 1.3 als Full‑Stack-JavaScript-Runtime.

Übernahme durch Anthropic

Anthropics Claude Code, ein agentisches KI-Coding-Tool, läuft mit Bun, und bereits während der letzten Monate hat das Bun-Team die Issues des Claude-Code-Teams mit Priorität bearbeitet. Nach Gesprächen mit Anthropic folgt jetzt die Übernahme von Bun, das selbst keine Einnahmen hatte: Anthropic kauft Bun als essenzielle Infrastruktur für Claude Code, die Toolsammlung Claude Agent SDK und zukünftige KI-Coding-Produkte.

Weiterlesen nach der Anzeige

Wie Sumner betont, soll dieser Schritt Bun zu langfristiger Stabilität verhelfen. Außerdem will man nun zusätzliche Software Engineers einstellen. Laut Sumner passen die beiden Seiten auf natürliche Weise zusammen, denn: „Bun begann mit einem Fokus darauf, Developer schneller zu machen. KI-Coding-Tools tun etwas Ähnliches.“


(mai)



Source link

Weiterlesen

Beliebt