Neue Entwickler-Patterns im Zeitalter der KI

xguru · 2025-05-26T11:03:01+09:00

Es bildet sich eine Entwicklungskultur heraus, die AI nicht nur als einfaches Tool, sondern als Basistechnologie behandelt Bestehende Ansätze für Versionsverwaltung, Dashboards, Templates, Dokumentation und Secret-Management verändern sich passend zum AI-Zeitalter Git wird nicht länger primär als Statusverwaltung auf Basis von Prompts und Testergebnissen statt zeilenweiser Code-Änderungen interpretiert Agenten werden zu Verfassern und Konsumenten von Code, wodurch der Bedarf wächst, die Tools selbst neu zu entwerfen Dashboards und UIs wandeln sich zu natürlichsprachlichen Interfaces und entwickeln sich zu Formen weiter, die von Menschen und AI-Agenten gemeinsam genutzt werden Dokumentation verändert sich zu einer Wissensbasis für Menschen und AI zugleich und wird in Formate umstrukturiert, die Agenten verstehen können 1. AI-Native Git: Neudefinition der Versionsverwaltung für AI-Agenten Git wurde ursprünglich dafür entwickelt, die zeilenweisen Änderungshistorien von direkt von Menschen geschriebenem Code zu verfolgen Doch in einer Situation, in der AI große Teile des Codes automatisch erzeugt und verändert, wird diese feingranulare Nachverfolgung weniger wichtig Entwickler richten ihre Aufmerksamkeit nicht mehr auf die Änderung selbst, sondern auf die Angemessenheit des resultierenden Verhaltens (z. B. ob Tests bestehen oder alles korrekt funktioniert) Ein SHA zeigt, dass es eine Änderung gab, enthält aber keine Information darüber, warum sie erfolgte oder ob sie gültig ist Gerade bei großen Änderungen oder automatisch generiertem Code prüfen Entwickler Diff-Ansichten oft nicht mehr einzeln In einem AI-first-Workflow wird die Kombination der folgenden Elemente zu einer nützlicheren Einheit Prompt: die Eingabe, die die Code-Erzeugung angestoßen hat Test: Tests zur Verifikation des erwarteten Verhaltens Spec und Constraints: Designanforderungen und Einschränkungen Diese werden als ein versionierbares Bundle betrachtet, verwaltet und nachverfolgt Denkt man das einen Schritt weiter, kann sich in einem agentengesteuerten Workflow die Source of Truth Upstream in Richtung Prompts, Datenschemata, API-Contracts und architektonischer Intent verschieben Dadurch wird Code wie ein kompiliertes Artefakt behandelt und nicht als Quelle, sondern als Nebenprodukt dieser Eingaben verstanden Git funktioniert dann nicht als Code-Workspace, sondern als Artifact Log wer mit welchem Modell und welchem Prompt den Code erzeugt hat welche Tests bestanden wurden welche Bereiche von Menschen überprüft werden müssen, zusammen mit solcher Metadaten Die Änderungshistorie enthält Prompts und Zweck, zugehörige Tests sowie Informationen über das erzeugende Modell In Verbindung mit AI-Review-Tools wie Diamond werden automatisierte Review-Abläufe möglich Es lassen sich reichhaltigere Metadaten schichten, etwa Strukturen zur Trennung von agentengeneriertem Code und von Menschen verwalteten Schutzbereichen Ein möglicher AI-Native-Git-Workflow könnte so aussehen Es könnte eine neue Form von Git-Dashboard entstehen, in der Prompts und darauf basierende Änderungsflüsse, Testergebnisse, Informationen über die aktiven Agenten und Bundle-Informationen gemeinsam sichtbar sind 2. Dashboards → Synthesis: Entwicklung hin zu dynamischen AI-basierten Interfaces Über Jahre hinweg waren Dashboards das zentrale Interface zur Interaktion mit komplexen Systemen wie Observability-Systemen, Analyse-Tools und Cloud-Konsolen (AWS usw.) Durch zu viele Bedienelemente, Charts und Tabs entstand jedoch UX-Überlastung, und Nutzer verloren leicht den Überblick zwischen Informationssuche und Aktion Besonders für Nicht-Spezialisten oder in Situationen, in denen mehrere Teams zusammenarbeiten, können solche Dashboards als abschreckende und ineffiziente Tools wahrgenommen werden Nutzer wissen zwar, was sie erreichen wollen, wissen aber oft nicht, wo sie suchen oder welche Filter sie anwenden müssen Die neueste Generation von AI-Modellen zeigt das Potenzial, dieses Problem zu lösen Dashboards lassen sich nicht mehr als statische Leinwand, sondern als Raum für Exploration und Interaktion neu denken LLMs können Nutzer auf folgende Weise unterstützen: Auffinden von Steuerungsorten wie bei „Wo ändere ich die Rate-Limit-Einstellungen dieser API?“ Zusammenfassungen über integrierte Daten wie bei „Fasse die Error-Trends aller Services in der Staging-Umgebung der letzten 24 Stunden zusammen“ Vorschläge für verborgene Insights wie bei „Empfiehl mir auf Basis meiner Geschäftslage Kennzahlen, auf die ich dieses Quartal achten sollte“ Technologien wie Assistant UI unterstützen schon heute, dass Agenten React-Komponenten wie Tools nutzen können So wie Inhalte dynamisch und personalisiert werden, wird auch die UI selbst abhängig von der Nutzerintention neu zusammengesetzt und entwickelt sich in Richtung Dialog Statische Dashboards könnten schon bald als veraltet gelten Beispiele: Wenn ein Nutzer sagt: „Zeig mir die Anomalien vom letzten Wochenende in Europa“, werden zusammengefasste Logs und Trends automatisch bereitgestellt, ohne dass Filter manuell bedient werden müssen Auf die Frage „Warum ist der NPS-Score letzte Woche gefallen?“ liefert die AI Sentiment-Analyse von Umfragen, Korrelationsanalysen mit Produkt-Releases und eine diagnostische Zusammenfassung Aus einer breiteren Perspektive muss schon der Begriff „Dashboard“ neu entworfen werden, wenn Agenten zu Konsumenten von Software werden Ein Dashboard könnte zum Beispiel eine für Agent Experience optimierte Ansicht rendern mit einem strukturierten und programmatisch zugänglichen Interface, das Systemzustände erfassbar macht und Entscheidungen sowie Handlungen ermöglicht Daraus könnte letztlich eine duale Interface-Struktur entstehen, in der UI für menschliche Nutzer und UI für Agenten nebeneinander bestehen Beide UIs teilen denselben Zustand, sind aber je nach Art des Konsums unterschiedlich aufgebaut Agenten übernehmen die Rolle bestehender Alerts, Cronjobs und bedingungsbasierter Automatisierung, werden dabei aber zu Akteuren mit deutlich mehr Kontext und Flexibilität Beispiel: Bisher: if error rate > threshold then send alert Agentenbasiert: „Die Error-Rate steigt. Die Ursache liegt in diesem Service, und dies sind die betroffenen Komponenten sowie die empfohlenen Maßnahmen“ So werden Dashboards nicht länger nur als Ort der Beobachtung verstanden, sondern neu definiert als Raum, in dem Menschen und AI zusammenarbeiten, Informationen integrieren und Handlungen ausführen 3. Dokumentation entwickelt sich zur Verbindung aus Tool, Index und interaktiver Wissensbasis Die Art, wie Entwickler Dokumentation nutzen, verändert sich Früher las man entlang des Inhaltsverzeichnisses oder arbeitete sich Spezifikationen von oben nach unten durch, heute wird jedoch die „Frage zuerst“-Methode zum Standard Statt „Ich sollte diese Spezifikation durcharbeiten“ setzt sich ein Denkwechsel durch hin zu „Strukturiere mir die Informationen so um, wie ich sie brauche“ Dieser Wandel beeinflusst auch die Form der Dokumentation: Sie entwickelt sich weg von statischem HTML oder Markdown hin zu interaktiven Wissenssystemen, die von Indizes, Embeddings und toolbewussten Agenten gestützt werden Entsprechend entstehen Tools wie Mintlify Mintlify organisiert Dokumentation nicht nur als semantisch durchsuchbare Datenbank, sondern wird auf verschiedenen Plattformen auch als Kontextquelle für Agenten genutzt Beispiel: In AI-IDEs, VS Code-Erweiterungen oder Terminal-Agenten wird Mintlify-Dokumentation als Referenzmaterial in Echtzeit verwendet Der Grund ist, dass Code-Generierungsagenten aktuelle Dokumentation als lernbasierte Kontextquelle nutzen Dadurch verändert sich der Zweck von Dokumentation selbst Dokumentation dient nicht mehr nur der Informationsvermittlung für menschliche Leser, sondern muss nun als Struktur für agentische Konsumenten entworfen werden In dieser neuen Dynamik übernimmt Dokumentation die Rolle einer Gebrauchsanweisung für AI-Agenten Es geht dabei nicht einfach um das Bereitstellen von Inhalten, sondern um ein Format, das erklärt, wie ein System korrekt genutzt werden kann 4. Von Templates zu Generierung: Vibe Coding ersetzt create-react-app Früher war es üblich, beim Start eines Projekts statische Templates wie create-react-app, next init oder rails new auszuwählen Solche Templates liefern zwar eine konsistente App-Struktur, aber Anpassungen an die Absicht des Entwicklers oder den gewählten Stack waren schwierig, und man musste den Standards des Frameworks folgen Dadurch war oft viel manuelles Refactoring nötig, wenn man von den Voreinstellungen abweichen wollte Jetzt verändert sich dieser Ablauf durch das Aufkommen von Text-to-App-Plattformen wie Replit, Same.dev, Loveable, Chef by Convex, Bolt sowie AI IDEs wie Cursor Entwickler können zum Beispiel „ein TypeScript-API-Server mit Supabase, Clerk und Stripe“ beschreiben, und die KI konfiguriert daraus in wenigen Sekunden automatisch ein maßgeschneidertes Projekt Der erzeugte Starter ist kein allgemeines Template, sondern eine auf die Absicht des Entwicklers und den Stack optimierte Struktur Dieser Wandel verändert auch die Distributionsstruktur des Ökosystems Statt dass wie früher einige wenige Frameworks das Zentrum des Ökosystems bilden, verbreiten sich maßgeschneiderte Generierungs-Workflows, die verschiedene Tools und Architekturen kombinieren Im Kern geht es nun weniger darum, ein Framework auszuwählen, sondern zu beschreiben, was man bauen will Ob ein Entwickler die Kombination Next.js + tRPC wählt und ein anderer Vite + React, beides kann jeweils direkt als lauffähiges Projekt erzeugt werden Natürlich haben Standard-Stacks weiterhin Vorteile: höhere Teamproduktivität, effizienteres Onboarding, einfacheres Debugging usw. Aber Refactoring zwischen Frameworks ist nicht nur ein technisches Problem, sondern mit Produkt, Infrastruktur und organisatorischen Fähigkeiten verflochten Der Wendepunkt ist, dass die Kosten eines Framework-Wechsels gesunken sind AI-Agenten verstehen die Absicht eines Projekts und können groß angelegtes Refactoring halbautomatisch durchführen Dadurch werden Experimente einfacher, und in frühen Phasen entsteht Spielraum, verschiedene Stacks auszuprobieren oder wieder zurückzuwechseln Infolgedessen wird die Framework-Auswahl reversibel (decision reversible) Beispiel: Man startet mit Next.js, wechselt dann zu Remix + Vite, und der Agent übernimmt das komplette Refactoring Da der Framework-Lock-in abnimmt, lassen sich auch opinionated Stacks ohne große Hürde ausprobieren 5. Jenseits von .env: Secret-Management in agentenzentrierten Umgebungen Über Jahrzehnte hinweg war die .env-Datei der Standardweg, mit dem Entwickler Secrets wie API-Keys, Datenbank-URLs und Service-Tokens lokal einfach verwalten Dieser Ansatz ist simpel, portabel und entwicklerfreundlich, aber in Situationen, in denen AI IDEs oder Agenten Code schreiben, Services deployen und Umgebungen orchestrieren, entstehen Probleme Denn dadurch wird unklar, wem die .env-Datei eigentlich gehört Es zeichnen sich Strömungen ab, die dieses Problem lösen sollen So enthält die aktuelle MCP-Spezifikation zum Beispiel ein auf OAuth 2.1 basierendes Authentifizierungs-Framework Diese Struktur deutet auf einen Ansatz hin, bei dem AI-Agenten anstelle roher Secrets eingeschränkte Tokens mit definiertem Scope (scope-based, revocable tokens) erhalten Beispiel: Statt dem Agenten vollständige AWS-Keys zu geben, erhält er kurzlebige Credentials, die nur begrenzte Aktionen wie „Datei nach S3 hochladen“ erlauben Eine weitere Entwicklung ist das Aufkommen lokaler Secret-Broker Diese laufen lokal oder neben der App und fungieren als Dienst, der zwischen Agenten und sensiblen Secrets vermittelt Der Agent greift nicht direkt auf .env zu und hardcodiert auch nichts; stattdessen bewertet der Broker konkrete Arbeitsanfragen in Echtzeit und erteilt die nötigen Berechtigungen Zum Beispiel Anfragen wie „auf Staging deployen“ oder „Logs an Sentry senden“ Der Broker verarbeitet dies Just-in-time, und jeder Zugriff lässt sich auditieren Dieser Ansatz verlagert den Secret-Zugriff von einem Dateisystemmodell zu einem API-basierten Berechtigungsmodell Damit entwickelt sich Secret-Management von einer .env-Konfiguration hin zu einer OAuth-basierten Struktur für Zugriffskontrolle 6. Barrierefreiheit als universelle Schnittstelle: Apps aus Sicht von LLMs Apps wie Granola oder Highlight verlangen in letzter Zeit Zugriff auf die Bedienungshilfen von macOS, aber das dient nicht dem traditionellen Zweck der Unterstützung von Menschen mit Behinderungen, sondern dazu, dass AI-Agenten die UI beobachten und mit ihr interagieren können Das ist kein vorübergehender Hack, sondern lässt sich als Vorzeichen eines grundlegenderen Interface-Wandels verstehen Accessibility-APIs wurden ursprünglich geschaffen, um die digitale Zugänglichkeit für Nutzer mit Seh- oder motorischen Einschränkungen zu verbessern Wenn man diese APIs erweitert, können sie jedoch als universelle Interface-Schicht für AI-Agenten dienen Statt auf Pixelpositionen zu klicken oder das DOM zu scrapen, können Agenten Apps semantisch beobachten und bedienen, ähnlich wie Hilfstechnologien eine UI interpretieren Der Accessibility-Tree stellt bereits strukturierte UI-Elemente wie Buttons, Überschriften und Eingabefelder bereit Ergänzt man ihn um Metadaten wie Intent, Rolle und Affordance, können Agenten präzise entsprechend Ziel und Kontext operieren Diese Richtung könnte sich zu folgenden Funktionen erweitern: Context extraction: Über Accessibility-/semantische APIs lassen sich sichtbare Elemente auf dem Bildschirm, interaktive Objekte und die aktuelle Nutzeraktion abfragen Intentful execution: Statt mehrere API-Aufrufe manuell zu verketten, wird ein übergeordnetes Ziel deklariert, etwa „einen Artikel in den Warenkorb legen und die schnellste Lieferung auswählen“, und das Backend stellt den Ausführungsablauf zusammen Fallback UI for LLMs: Accessibility-Funktionen bieten eine Ausweichschnittstelle, über die Agenten auch Apps ohne öffentliche API nutzen können Entwickler können zusätzlich zu visueller UI oder DOM eine für Agenten erkennbare Renderfläche (render surface) mit strukturierten Annotationen oder accessibility-zentrierten Komponenten definieren Kurz gesagt: Accessibility-APIs entwickeln sich von einer Funktion nur für Menschen zu einer zentralen Interface-Schicht für die Interaktion von KI und Systemen 7. Der Aufstieg asynchroner Agentenarbeit Da Entwickler zunehmend natürlich mit Code-Write-Agents zusammenarbeiten, beschleunigt sich der Übergang zu asynchronen Workflows Agents arbeiten parallel im Hintergrund und melden Ergebnisse, sobald ein bestimmter Fortschrittsgrad erreicht ist Diese Interaktion ähnelt zunehmend weniger Pair Programming als vielmehr Task-Orchestrierung (task orchestration) Das heißt: Der Entwickler gibt das Ziel vor, der Agent führt es aus, und später wird das Ergebnis geprüft Wichtig ist nicht nur, dass Arbeit abgenommen wird, sondern dass die Zusammenarbeit selbst komprimiert wird Statt zum Beispiel ein anderes Team um ein Update von Konfigurationsdateien, Error-Triage oder Component-Refactoring zu bitten, kann der Entwickler seine Absicht direkt an den Agent übermitteln und ihn die Aufgabe im Hintergrund erledigen lassen Früher waren dafür synchrone Meetings, teamübergreifende Handoffs und lange Review-Zyklen nötig, heute entsteht ganz natürlich eine Schleife aus Request → Generate → Validate (request → generate → validate) Auch die Art, wie mit Agents interagiert wird, erweitert sich Es bleibt nicht beim Eingeben von Prompts in IDE oder CLI, sondern es sind auch folgende Wege möglich: Aufgaben per Slack-Nachricht anfordern Kommentare in Figma-Mockups schreiben Inline-Kommentare in Code-Diffs oder PRs hinterlassen (z. B. Graphite Review Assistant) Feedback zu einer bereitgestellten App-Vorschau hinzufügen Änderungen mündlich über Sprach- oder Anruf-basierte Interfaces erklären Diese Veränderung führt dazu, dass Agents über den gesamten Entwicklungslebenszyklus hinweg präsent sind Nicht nur beim Schreiben von Code, sondern auch bei Design-Interpretation, Einbau von Feedback und Bug-Triage über die gesamte Plattform hinweg Entwickler übernehmen dabei die Rolle eines Orchestrators, der entscheidet, welche Arbeits-Threads fortgeführt, ausgeschlossen oder zusammengeführt werden Dieser Trend deutet letztlich darauf hin, dass agentenbasierte Arbeits-Threads zu einem neuen Konzept von „Git-Branch“ werden könnten Nicht mehr als statischer Code-Fork, sondern als dynamischer, zweckorientierter Thread, der asynchron läuft und nach Fertigstellung integriert wird 8. MCP: Einen Schritt näher an einem universellen Standard mit dem Model Context Protocol Seit der Veröffentlichung der tiefgehenden Analyse zu MCP beschleunigt sich die Einführung von MCP OpenAI hat MCP offiziell übernommen, mehrere neue Funktionen wurden in die Spezifikation aufgenommen, und immer mehr Tool-Anbieter akzeptieren MCP als Basisschnittstelle zwischen Agents und der realen Welt MCP löst im Kern zwei wichtige Probleme: Es liefert den nötigen Kontext, damit LLMs auch Aufgaben ausführen können, auf die sie zum ersten Mal treffen Es ersetzt maßgeschneiderte N×M-Integrationen durch eine Struktur, in der Tools eine Standardschnittstelle (Server) bereitstellen, die von allen Agents (Clients) genutzt werden kann Es ist zu erwarten, dass sich die MCP-Einführung weiter ausweitet, und falls Remote-MCP sowie ein De-facto-MCP-Registry entstehen, könnten viele Apps standardmäßig mit einer MCP-Schnittstelle ausgeliefert werden So wie APIs in der Vergangenheit SaaS-Tools verbunden und Workflows zusammengesetzt haben, könnte MCP ein Ökosystem interoperabler Bausteine für AI-Agents schaffen Plattformen mit eingebautem MCP-Client sind dann nicht nur „AI-unterstützt“, sondern Teil eines Ökosystems, das direkt an ein für Agents zugängliches Funktionsnetzwerk angeschlossen ist MCP-Clients und -Server sind nur logische Konzepte und physisch nicht getrennt Das bedeutet, dass jeder MCP-Client auch ein Server sein kann und umgekehrt Dadurch entstehen hochgradige Composability-Möglichkeiten: Beispiel: Ein Coding-Agent kann als Client GitHub-Issues abrufen und gleichzeitig als Server anderen Agents Test-Coverage oder Ergebnisse der Code-Analyse bereitstellen MCP etabliert sich als grundlegende Interface-Schicht für ein Ökosystem, in dem Tools und Agents organisch miteinander interagieren 9. Abstrahierte Primitive: Authentifizierung, Zahlung und Storage, die jeder AI-Agent braucht Je leistungsfähiger Vibe-Coding-Agents werden, desto klarer wird, dass Agents zwar viel Code generieren können, dieser Code aber eine vertrauenswürdige Grundlage braucht, an die er angebunden wird So wie menschliche Entwickler sich bei Zahlungen auf Stripe, bei Authentifizierung auf Clerk und bei Datenbanken auf Supabase verlassen, brauchen auch Agents verlässliche und kombinierbare Service-Primitive Diese Services bieten klare API-Grenzen, leicht nutzbare SDKs und sinnvolle Default-Einstellungen und übernehmen zunehmend die Rolle eines Runtime-Interfaces für Agents Baut man zum Beispiel ein Tool zur Erstellung von SaaS-Apps, implementiert der Agent nicht selbst ein Authentifizierungssystem oder Zahlungslogik, sondern integriert Clerk und Stripe schnell und sicher Wenn dieses Muster reift, könnten Services über reine APIs hinaus Folgendes veröffentlichen: Schemas: strukturierte Datendefinitionen Capability Metadata: Spezifikationen ausführbarer Aktionen Example Flows: Beispiele dafür, wie eine Integration umgesetzt wird → dadurch können Agents Integrationen deutlich zuverlässiger umsetzen Einige Services könnten sogar direkt mit eingebautem MCP-Server auf den Markt kommen Beispiel: Clerk stellt über einen MCP-Server Funktionen wie das Abrufen verfügbarer Produkte, das Erstellen neuer Preispläne oder das Ändern von Subscriptions bereit Agents stellen dann natürliche Sprachbefehle, statt in API-Spezifikationen oder Dokumentation zu suchen, und der MCP-Server validiert und verarbeitet die Anfrage innerhalb von Berechtigungsgrenzen und Einschränkungen Beispiel: > „Erstelle einen Pro-Tarif für 49 $ pro Monat und richte nutzungsbasierte Zusatzabrechnung ein“ → Der MCP-Server von Clerk interpretiert und führt diese Anfrage aus So wie rails new im frühen Web-Zeitalter schnelle Entwicklung möglich gemacht hat, braucht das Agent-Zeitalter vertrauenswürdige Primitive (drop-in identity, Zahlungen, Zugriffskontrolle usw.) Diese müssen ausreichend abstrahiert sein, damit Agents sie zur Generierung nutzen können, und zugleich eine Struktur bieten, die mit dem Wachstum der App skaliert Fazit Diese 9 Patterns zeigen nicht einfach, dass AI auf bestehende Entwicklungsweisen aufgesetzt wird, sondern dass die Art, wie Software erstellt wird, selbst entlang von Agents, Kontext und Intention neu definiert wird Entsprechend verändern sich auch bestehende Verhaltensmuster von Entwicklern, und neue Toolchains und Protokolle (wie MCP) entstehen rasant, um dies zu unterstützen Bestehende Kernwerkzeugschichten wie Git, Templates, Dashboards und Dokumentationsformen werden zusammen mit AI grundlegend neu gestaltet In dieser Übergangsphase ist zu erwarten, dass Aufbau und Investitionen in Tools und Infrastruktur der nächsten Generation, die das neue Entwickler-Ökosystem prägen, deutlich zunehmen werden

(a16z.com)

48 Punkte von xguru 2025-05-26 | 8 Kommentare | Auf WhatsApp teilen

Es bildet sich eine Entwicklungskultur heraus, die AI nicht nur als einfaches Tool, sondern als Basistechnologie behandelt
Bestehende Ansätze für Versionsverwaltung, Dashboards, Templates, Dokumentation und Secret-Management verändern sich passend zum AI-Zeitalter
- Git wird nicht länger primär als Statusverwaltung auf Basis von Prompts und Testergebnissen statt zeilenweiser Code-Änderungen interpretiert
- Agenten werden zu Verfassern und Konsumenten von Code, wodurch der Bedarf wächst, die Tools selbst neu zu entwerfen
- Dashboards und UIs wandeln sich zu natürlichsprachlichen Interfaces und entwickeln sich zu Formen weiter, die von Menschen und AI-Agenten gemeinsam genutzt werden
- Dokumentation verändert sich zu einer Wissensbasis für Menschen und AI zugleich und wird in Formate umstrukturiert, die Agenten verstehen können

1. AI-Native Git: Neudefinition der Versionsverwaltung für AI-Agenten

Git wurde ursprünglich dafür entwickelt, die zeilenweisen Änderungshistorien von direkt von Menschen geschriebenem Code zu verfolgen
- Doch in einer Situation, in der AI große Teile des Codes automatisch erzeugt und verändert, wird diese feingranulare Nachverfolgung weniger wichtig
- Entwickler richten ihre Aufmerksamkeit nicht mehr auf die Änderung selbst, sondern auf die Angemessenheit des resultierenden Verhaltens (z. B. ob Tests bestehen oder alles korrekt funktioniert)
- Ein SHA zeigt, dass es eine Änderung gab, enthält aber keine Information darüber, warum sie erfolgte oder ob sie gültig ist
- Gerade bei großen Änderungen oder automatisch generiertem Code prüfen Entwickler Diff-Ansichten oft nicht mehr einzeln
In einem AI-first-Workflow wird die Kombination der folgenden Elemente zu einer nützlicheren Einheit
- Prompt: die Eingabe, die die Code-Erzeugung angestoßen hat
- Test: Tests zur Verifikation des erwarteten Verhaltens
- Spec und Constraints: Designanforderungen und Einschränkungen
- Diese werden als ein versionierbares Bundle betrachtet, verwaltet und nachverfolgt
Denkt man das einen Schritt weiter, kann sich in einem agentengesteuerten Workflow die Source of Truth Upstream in Richtung Prompts, Datenschemata, API-Contracts und architektonischer Intent verschieben
- Dadurch wird Code wie ein kompiliertes Artefakt behandelt und nicht als Quelle, sondern als Nebenprodukt dieser Eingaben verstanden
- Git funktioniert dann nicht als Code-Workspace, sondern als Artifact Log
  - wer mit welchem Modell und welchem Prompt den Code erzeugt hat
  - welche Tests bestanden wurden
  - welche Bereiche von Menschen überprüft werden müssen, zusammen mit solcher Metadaten
Die Änderungshistorie enthält Prompts und Zweck, zugehörige Tests sowie Informationen über das erzeugende Modell
- In Verbindung mit AI-Review-Tools wie Diamond werden automatisierte Review-Abläufe möglich
- Es lassen sich reichhaltigere Metadaten schichten, etwa Strukturen zur Trennung von agentengeneriertem Code und von Menschen verwalteten Schutzbereichen
Ein möglicher AI-Native-Git-Workflow könnte so aussehen
- Es könnte eine neue Form von Git-Dashboard entstehen, in der Prompts und darauf basierende Änderungsflüsse, Testergebnisse, Informationen über die aktiven Agenten und Bundle-Informationen gemeinsam sichtbar sind

2. Dashboards → Synthesis: Entwicklung hin zu dynamischen AI-basierten Interfaces

Über Jahre hinweg waren Dashboards das zentrale Interface zur Interaktion mit komplexen Systemen wie Observability-Systemen, Analyse-Tools und Cloud-Konsolen (AWS usw.)
- Durch zu viele Bedienelemente, Charts und Tabs entstand jedoch UX-Überlastung, und Nutzer verloren leicht den Überblick zwischen Informationssuche und Aktion
- Besonders für Nicht-Spezialisten oder in Situationen, in denen mehrere Teams zusammenarbeiten, können solche Dashboards als abschreckende und ineffiziente Tools wahrgenommen werden
- Nutzer wissen zwar, was sie erreichen wollen, wissen aber oft nicht, wo sie suchen oder welche Filter sie anwenden müssen
Die neueste Generation von AI-Modellen zeigt das Potenzial, dieses Problem zu lösen
- Dashboards lassen sich nicht mehr als statische Leinwand, sondern als Raum für Exploration und Interaktion neu denken
LLMs können Nutzer auf folgende Weise unterstützen:
- Auffinden von Steuerungsorten wie bei „Wo ändere ich die Rate-Limit-Einstellungen dieser API?“
- Zusammenfassungen über integrierte Daten wie bei „Fasse die Error-Trends aller Services in der Staging-Umgebung der letzten 24 Stunden zusammen“
- Vorschläge für verborgene Insights wie bei „Empfiehl mir auf Basis meiner Geschäftslage Kennzahlen, auf die ich dieses Quartal achten sollte“
Technologien wie Assistant UI unterstützen schon heute, dass Agenten React-Komponenten wie Tools nutzen können
- So wie Inhalte dynamisch und personalisiert werden, wird auch die UI selbst abhängig von der Nutzerintention neu zusammengesetzt und entwickelt sich in Richtung Dialog
- Statische Dashboards könnten schon bald als veraltet gelten
- Beispiele:
  - Wenn ein Nutzer sagt: „Zeig mir die Anomalien vom letzten Wochenende in Europa“, werden zusammengefasste Logs und Trends automatisch bereitgestellt, ohne dass Filter manuell bedient werden müssen
  - Auf die Frage „Warum ist der NPS-Score letzte Woche gefallen?“ liefert die AI Sentiment-Analyse von Umfragen, Korrelationsanalysen mit Produkt-Releases und eine diagnostische Zusammenfassung
Aus einer breiteren Perspektive muss schon der Begriff „Dashboard“ neu entworfen werden, wenn Agenten zu Konsumenten von Software werden
- Ein Dashboard könnte zum Beispiel eine für Agent Experience optimierte Ansicht rendern
  - mit einem strukturierten und programmatisch zugänglichen Interface, das Systemzustände erfassbar macht und Entscheidungen sowie Handlungen ermöglicht
- Daraus könnte letztlich eine duale Interface-Struktur entstehen, in der UI für menschliche Nutzer und UI für Agenten nebeneinander bestehen
  - Beide UIs teilen denselben Zustand, sind aber je nach Art des Konsums unterschiedlich aufgebaut
Agenten übernehmen die Rolle bestehender Alerts, Cronjobs und bedingungsbasierter Automatisierung, werden dabei aber zu Akteuren mit deutlich mehr Kontext und Flexibilität
Beispiel:
- Bisher: if error rate > threshold then send alert
- Agentenbasiert: „Die Error-Rate steigt. Die Ursache liegt in diesem Service, und dies sind die betroffenen Komponenten sowie die empfohlenen Maßnahmen“
So werden Dashboards nicht länger nur als Ort der Beobachtung verstanden, sondern neu definiert als Raum, in dem Menschen und AI zusammenarbeiten, Informationen integrieren und Handlungen ausführen

3. Dokumentation entwickelt sich zur Verbindung aus Tool, Index und interaktiver Wissensbasis

Die Art, wie Entwickler Dokumentation nutzen, verändert sich
- Früher las man entlang des Inhaltsverzeichnisses oder arbeitete sich Spezifikationen von oben nach unten durch, heute wird jedoch die „Frage zuerst“-Methode zum Standard
- Statt „Ich sollte diese Spezifikation durcharbeiten“ setzt sich ein Denkwechsel durch hin zu „Strukturiere mir die Informationen so um, wie ich sie brauche“
- Dieser Wandel beeinflusst auch die Form der Dokumentation: Sie entwickelt sich weg von statischem HTML oder Markdown hin zu interaktiven Wissenssystemen, die von Indizes, Embeddings und toolbewussten Agenten gestützt werden
Entsprechend entstehen Tools wie Mintlify
- Mintlify organisiert Dokumentation nicht nur als semantisch durchsuchbare Datenbank, sondern wird auf verschiedenen Plattformen auch als Kontextquelle für Agenten genutzt
  - Beispiel: In AI-IDEs, VS Code-Erweiterungen oder Terminal-Agenten wird Mintlify-Dokumentation als Referenzmaterial in Echtzeit verwendet
- Der Grund ist, dass Code-Generierungsagenten aktuelle Dokumentation als lernbasierte Kontextquelle nutzen
Dadurch verändert sich der Zweck von Dokumentation selbst
- Dokumentation dient nicht mehr nur der Informationsvermittlung für menschliche Leser, sondern muss nun als Struktur für agentische Konsumenten entworfen werden
- In dieser neuen Dynamik übernimmt Dokumentation die Rolle einer Gebrauchsanweisung für AI-Agenten
- Es geht dabei nicht einfach um das Bereitstellen von Inhalten, sondern um ein Format, das erklärt, wie ein System korrekt genutzt werden kann

4. Von Templates zu Generierung: Vibe Coding ersetzt create-react-app

Früher war es üblich, beim Start eines Projekts statische Templates wie create-react-app, next init oder rails new auszuwählen
- Solche Templates liefern zwar eine konsistente App-Struktur, aber Anpassungen an die Absicht des Entwicklers oder den gewählten Stack waren schwierig, und man musste den Standards des Frameworks folgen
- Dadurch war oft viel manuelles Refactoring nötig, wenn man von den Voreinstellungen abweichen wollte
Jetzt verändert sich dieser Ablauf durch das Aufkommen von Text-to-App-Plattformen wie Replit, Same.dev, Loveable, Chef by Convex, Bolt sowie AI IDEs wie Cursor
- Entwickler können zum Beispiel „ein TypeScript-API-Server mit Supabase, Clerk und Stripe“ beschreiben, und die KI konfiguriert daraus in wenigen Sekunden automatisch ein maßgeschneidertes Projekt
- Der erzeugte Starter ist kein allgemeines Template, sondern eine auf die Absicht des Entwicklers und den Stack optimierte Struktur
Dieser Wandel verändert auch die Distributionsstruktur des Ökosystems
- Statt dass wie früher einige wenige Frameworks das Zentrum des Ökosystems bilden, verbreiten sich maßgeschneiderte Generierungs-Workflows, die verschiedene Tools und Architekturen kombinieren
- Im Kern geht es nun weniger darum, ein Framework auszuwählen, sondern zu beschreiben, was man bauen will
- Ob ein Entwickler die Kombination Next.js + tRPC wählt und ein anderer Vite + React, beides kann jeweils direkt als lauffähiges Projekt erzeugt werden
Natürlich haben Standard-Stacks weiterhin Vorteile:
- höhere Teamproduktivität, effizienteres Onboarding, einfacheres Debugging usw.
- Aber Refactoring zwischen Frameworks ist nicht nur ein technisches Problem, sondern mit Produkt, Infrastruktur und organisatorischen Fähigkeiten verflochten
Der Wendepunkt ist, dass die Kosten eines Framework-Wechsels gesunken sind
- AI-Agenten verstehen die Absicht eines Projekts und können groß angelegtes Refactoring halbautomatisch durchführen
- Dadurch werden Experimente einfacher, und in frühen Phasen entsteht Spielraum, verschiedene Stacks auszuprobieren oder wieder zurückzuwechseln
Infolgedessen wird die Framework-Auswahl reversibel (decision reversible)
- Beispiel: Man startet mit Next.js, wechselt dann zu Remix + Vite, und der Agent übernimmt das komplette Refactoring
Da der Framework-Lock-in abnimmt, lassen sich auch opinionated Stacks ohne große Hürde ausprobieren

5. Jenseits von .env: Secret-Management in agentenzentrierten Umgebungen

Über Jahrzehnte hinweg war die .env-Datei der Standardweg, mit dem Entwickler Secrets wie API-Keys, Datenbank-URLs und Service-Tokens lokal einfach verwalten
- Dieser Ansatz ist simpel, portabel und entwicklerfreundlich, aber in Situationen, in denen AI IDEs oder Agenten Code schreiben, Services deployen und Umgebungen orchestrieren, entstehen Probleme
- Denn dadurch wird unklar, wem die .env-Datei eigentlich gehört
Es zeichnen sich Strömungen ab, die dieses Problem lösen sollen
- So enthält die aktuelle MCP-Spezifikation zum Beispiel ein auf OAuth 2.1 basierendes Authentifizierungs-Framework
- Diese Struktur deutet auf einen Ansatz hin, bei dem AI-Agenten anstelle roher Secrets eingeschränkte Tokens mit definiertem Scope (scope-based, revocable tokens) erhalten
- Beispiel: Statt dem Agenten vollständige AWS-Keys zu geben, erhält er kurzlebige Credentials, die nur begrenzte Aktionen wie „Datei nach S3 hochladen“ erlauben
Eine weitere Entwicklung ist das Aufkommen lokaler Secret-Broker
- Diese laufen lokal oder neben der App und fungieren als Dienst, der zwischen Agenten und sensiblen Secrets vermittelt
- Der Agent greift nicht direkt auf .env zu und hardcodiert auch nichts; stattdessen bewertet der Broker konkrete Arbeitsanfragen in Echtzeit und erteilt die nötigen Berechtigungen
  - Zum Beispiel Anfragen wie „auf Staging deployen“ oder „Logs an Sentry senden“
  - Der Broker verarbeitet dies Just-in-time, und jeder Zugriff lässt sich auditieren
Dieser Ansatz verlagert den Secret-Zugriff von einem Dateisystemmodell zu einem API-basierten Berechtigungsmodell
- Damit entwickelt sich Secret-Management von einer .env-Konfiguration hin zu einer OAuth-basierten Struktur für Zugriffskontrolle

6. Barrierefreiheit als universelle Schnittstelle: Apps aus Sicht von LLMs

Apps wie Granola oder Highlight verlangen in letzter Zeit Zugriff auf die Bedienungshilfen von macOS, aber das dient nicht dem traditionellen Zweck der Unterstützung von Menschen mit Behinderungen, sondern dazu, dass AI-Agenten die UI beobachten und mit ihr interagieren können
- Das ist kein vorübergehender Hack, sondern lässt sich als Vorzeichen eines grundlegenderen Interface-Wandels verstehen
Accessibility-APIs wurden ursprünglich geschaffen, um die digitale Zugänglichkeit für Nutzer mit Seh- oder motorischen Einschränkungen zu verbessern
- Wenn man diese APIs erweitert, können sie jedoch als universelle Interface-Schicht für AI-Agenten dienen
- Statt auf Pixelpositionen zu klicken oder das DOM zu scrapen, können Agenten Apps semantisch beobachten und bedienen, ähnlich wie Hilfstechnologien eine UI interpretieren
- Der Accessibility-Tree stellt bereits strukturierte UI-Elemente wie Buttons, Überschriften und Eingabefelder bereit
- Ergänzt man ihn um Metadaten wie Intent, Rolle und Affordance, können Agenten präzise entsprechend Ziel und Kontext operieren
Diese Richtung könnte sich zu folgenden Funktionen erweitern:
- Context extraction: Über Accessibility-/semantische APIs lassen sich sichtbare Elemente auf dem Bildschirm, interaktive Objekte und die aktuelle Nutzeraktion abfragen
- Intentful execution: Statt mehrere API-Aufrufe manuell zu verketten, wird ein übergeordnetes Ziel deklariert, etwa „einen Artikel in den Warenkorb legen und die schnellste Lieferung auswählen“, und das Backend stellt den Ausführungsablauf zusammen
- Fallback UI for LLMs: Accessibility-Funktionen bieten eine Ausweichschnittstelle, über die Agenten auch Apps ohne öffentliche API nutzen können
  - Entwickler können zusätzlich zu visueller UI oder DOM eine für Agenten erkennbare Renderfläche (render surface) mit strukturierten Annotationen oder accessibility-zentrierten Komponenten definieren
Kurz gesagt: Accessibility-APIs entwickeln sich von einer Funktion nur für Menschen zu einer zentralen Interface-Schicht für die Interaktion von KI und Systemen

7. Der Aufstieg asynchroner Agentenarbeit

Da Entwickler zunehmend natürlich mit Code-Write-Agents zusammenarbeiten, beschleunigt sich der Übergang zu asynchronen Workflows
- Agents arbeiten parallel im Hintergrund und melden Ergebnisse, sobald ein bestimmter Fortschrittsgrad erreicht ist
- Diese Interaktion ähnelt zunehmend weniger Pair Programming als vielmehr Task-Orchestrierung (task orchestration)
- Das heißt: Der Entwickler gibt das Ziel vor, der Agent führt es aus, und später wird das Ergebnis geprüft
Wichtig ist nicht nur, dass Arbeit abgenommen wird, sondern dass die Zusammenarbeit selbst komprimiert wird
- Statt zum Beispiel ein anderes Team um ein Update von Konfigurationsdateien, Error-Triage oder Component-Refactoring zu bitten,
  kann der Entwickler seine Absicht direkt an den Agent übermitteln und ihn die Aufgabe im Hintergrund erledigen lassen
- Früher waren dafür synchrone Meetings, teamübergreifende Handoffs und lange Review-Zyklen nötig,
  heute entsteht ganz natürlich eine Schleife aus Request → Generate → Validate (request → generate → validate)
Auch die Art, wie mit Agents interagiert wird, erweitert sich
- Es bleibt nicht beim Eingeben von Prompts in IDE oder CLI, sondern es sind auch folgende Wege möglich:
  - Aufgaben per Slack-Nachricht anfordern
  - Kommentare in Figma-Mockups schreiben
  - Inline-Kommentare in Code-Diffs oder PRs hinterlassen (z. B. Graphite Review Assistant)
  - Feedback zu einer bereitgestellten App-Vorschau hinzufügen
  - Änderungen mündlich über Sprach- oder Anruf-basierte Interfaces erklären
Diese Veränderung führt dazu, dass Agents über den gesamten Entwicklungslebenszyklus hinweg präsent sind
- Nicht nur beim Schreiben von Code, sondern auch bei Design-Interpretation, Einbau von Feedback und Bug-Triage über die gesamte Plattform hinweg
- Entwickler übernehmen dabei die Rolle eines Orchestrators, der entscheidet, welche Arbeits-Threads fortgeführt, ausgeschlossen oder zusammengeführt werden
Dieser Trend deutet letztlich darauf hin, dass agentenbasierte Arbeits-Threads zu einem neuen Konzept von „Git-Branch“ werden könnten
- Nicht mehr als statischer Code-Fork, sondern als dynamischer, zweckorientierter Thread, der asynchron läuft und nach Fertigstellung integriert wird

8. MCP: Einen Schritt näher an einem universellen Standard mit dem Model Context Protocol

Seit der Veröffentlichung der tiefgehenden Analyse zu MCP beschleunigt sich die Einführung von MCP
OpenAI hat MCP offiziell übernommen, mehrere neue Funktionen wurden in die Spezifikation aufgenommen,
und immer mehr Tool-Anbieter akzeptieren MCP als Basisschnittstelle zwischen Agents und der realen Welt
MCP löst im Kern zwei wichtige Probleme:
- Es liefert den nötigen Kontext, damit LLMs auch Aufgaben ausführen können, auf die sie zum ersten Mal treffen
- Es ersetzt maßgeschneiderte N×M-Integrationen durch eine Struktur, in der Tools eine Standardschnittstelle (Server) bereitstellen, die von allen Agents (Clients) genutzt werden kann
Es ist zu erwarten, dass sich die MCP-Einführung weiter ausweitet,
und falls Remote-MCP sowie ein De-facto-MCP-Registry entstehen,
könnten viele Apps standardmäßig mit einer MCP-Schnittstelle ausgeliefert werden
So wie APIs in der Vergangenheit SaaS-Tools verbunden und Workflows zusammengesetzt haben,
könnte MCP ein Ökosystem interoperabler Bausteine für AI-Agents schaffen
Plattformen mit eingebautem MCP-Client sind dann nicht nur „AI-unterstützt“,
sondern Teil eines Ökosystems, das direkt an ein für Agents zugängliches Funktionsnetzwerk angeschlossen ist
MCP-Clients und -Server sind nur logische Konzepte und physisch nicht getrennt
- Das bedeutet, dass jeder MCP-Client auch ein Server sein kann und umgekehrt
- Dadurch entstehen hochgradige Composability-Möglichkeiten:
  - Beispiel: Ein Coding-Agent kann als Client GitHub-Issues abrufen und gleichzeitig als Server anderen Agents Test-Coverage oder Ergebnisse der Code-Analyse bereitstellen
MCP etabliert sich als grundlegende Interface-Schicht für ein Ökosystem, in dem Tools und Agents organisch miteinander interagieren

9. Abstrahierte Primitive: Authentifizierung, Zahlung und Storage, die jeder AI-Agent braucht

Je leistungsfähiger Vibe-Coding-Agents werden, desto klarer wird,
dass Agents zwar viel Code generieren können, dieser Code aber eine vertrauenswürdige Grundlage braucht, an die er angebunden wird
So wie menschliche Entwickler sich bei Zahlungen auf Stripe, bei Authentifizierung auf Clerk und bei Datenbanken auf Supabase verlassen,
brauchen auch Agents verlässliche und kombinierbare Service-Primitive
Diese Services bieten klare API-Grenzen, leicht nutzbare SDKs und sinnvolle Default-Einstellungen
und übernehmen zunehmend die Rolle eines Runtime-Interfaces für Agents
Baut man zum Beispiel ein Tool zur Erstellung von SaaS-Apps, implementiert der Agent nicht selbst ein Authentifizierungssystem oder Zahlungslogik,
sondern integriert Clerk und Stripe schnell und sicher
Wenn dieses Muster reift, könnten Services über reine APIs hinaus Folgendes veröffentlichen:
- Schemas: strukturierte Datendefinitionen
- Capability Metadata: Spezifikationen ausführbarer Aktionen
- Example Flows: Beispiele dafür, wie eine Integration umgesetzt wird
  → dadurch können Agents Integrationen deutlich zuverlässiger umsetzen
Einige Services könnten sogar direkt mit eingebautem MCP-Server auf den Markt kommen
- Beispiel: Clerk stellt über einen MCP-Server Funktionen wie das Abrufen verfügbarer Produkte, das Erstellen neuer Preispläne oder das Ändern von Subscriptions bereit
- Agents stellen dann natürliche Sprachbefehle, statt in API-Spezifikationen oder Dokumentation zu suchen,
  und der MCP-Server validiert und verarbeitet die Anfrage innerhalb von Berechtigungsgrenzen und Einschränkungen
- Beispiel:
  > „Erstelle einen Pro-Tarif für 49 $ pro Monat und richte nutzungsbasierte Zusatzabrechnung ein“
  → Der MCP-Server von Clerk interpretiert und führt diese Anfrage aus
So wie rails new im frühen Web-Zeitalter schnelle Entwicklung möglich gemacht hat,
braucht das Agent-Zeitalter vertrauenswürdige Primitive (drop-in identity, Zahlungen, Zugriffskontrolle usw.)
- Diese müssen ausreichend abstrahiert sein, damit Agents sie zur Generierung nutzen können,
  und zugleich eine Struktur bieten, die mit dem Wachstum der App skaliert

Fazit

Diese 9 Patterns zeigen nicht einfach, dass AI auf bestehende Entwicklungsweisen aufgesetzt wird, sondern dass die Art, wie Software erstellt wird, selbst entlang von Agents, Kontext und Intention neu definiert wird
Entsprechend verändern sich auch bestehende Verhaltensmuster von Entwicklern, und neue Toolchains und Protokolle (wie MCP) entstehen rasant, um dies zu unterstützen
Bestehende Kernwerkzeugschichten wie Git, Templates, Dashboards und Dokumentationsformen werden zusammen mit AI grundlegend neu gestaltet
In dieser Übergangsphase ist zu erwarten, dass Aufbau und Investitionen in Tools und Infrastruktur der nächsten Generation, die das neue Entwickler-Ökosystem prägen, deutlich zunehmen werden

8 Kommentare

aa1567 2025-05-28

Es gibt tatsächlich Leute, die Nummer 1 wirklich machen..?

hhcrux 2025-05-27

LLMs garantieren bei derselben Eingabe nicht dieselbe Ausgabe – funktioniert so eine Art von Konfigurationsmanagement dann überhaupt ...
Nutze ich das bisher einfach noch viel zu eindimensional?

beoks 2025-05-27

Soweit ich weiß, garantiert das Setzen der temperature-Option auf 0 bei derselben Eingabe dieselbe Ausgabe.

fanotify 2025-05-28

Ist das nicht ohnehin bedeutungslos, weil sich schon in ein paar Monaten wieder das Modell selbst geändert haben wird?

beoks 2025-05-27

Davon abgesehen ist es schon sehr kategorisch, menschliches Eingreifen überhaupt nicht zu berücksichtigen,
bei einfachen Zahlen- oder Nachrichtenänderungen wäre menschliches Eingreifen doch effizienter als ein LLM.

nicewook 2025-05-26

Ein Text mit tiefen Einsichten. Wie erwartet von a16z.

ruinnel 2025-05-26

https://de.news.hada.io/topic?id=21091
Wenn man das nach der Lektüre dieses Artikels liest, fragt man sich, ob das wirklich so stimmt.

ahwjdekf 2025-05-26

Nummer 1 ist wirklich eine albtraumhafte Veränderung, die ich auf keinen Fall akzeptieren möchte. Dass die Nachverfolgung der Quellcode-Historie bedeutungslos wird.