--- title: "Was ist ein AI-nativer Entwickler? Rolle, Kompetenzen und Betriebsstruktur für Agenten" locale: de category: ai_data category_name: "KI-Daten" translation_status: reviewed license: cc_by author: "injoys" source_url: https://injoys.com/en/articles/ai-native-developer-definition-and-practices published_at: 2026-08-04T10:59:54+09:00 --- # Was ist ein AI-nativer Entwickler? Rolle, Kompetenzen und Betriebsstruktur für Agenten > Ein AI-nativer Entwickler entwirft Systeme, in denen AI die Implementierungsarbeit übernimmt, während er für Problemdefinition, Festlegung von Einschränkungen, Qualitätsprüfung und die abschließende Verantwortung zuständig ist. Dieser Artikel erläutert Dokumentation, Agenten-Harness, Verfahren zur Teameinführung, Erfolgskennzahlen und Sicherheitsprinzipien aus praktischer Sicht. ## Key Points - Der Kern der AI-nativen Entwicklung liegt nicht in Prompt-Tricks, sondern im Entwurf eines Systems, das Aufgaben delegieren und Ergebnisse überprüfen kann. - Auch wenn AI schnell Code erzeugt, werden Problemdefinition, Produktverständnis, Architekturentscheidungen, Sicherheitsprüfung und Verantwortung nicht automatisch gelöst. - Wer Spezifikationen, Einschränkungen, Schemata und Entscheidungsprotokolle als verwaltete Dokumente bereitstellt, erleichtert Agenten die Arbeit in einem konsistenten Kontext. - Die Phasen Plan, Draft und Review lassen sich auch mit einem einzigen Agenten umsetzen; mehrere Agenten sollten gewählt werden, wenn der Nutzen der Trennung Kosten und Komplexität überwiegt. - Der Erfolg der Teameinführung sollte nicht anhand der erzeugten Codemenge bewertet werden, sondern anhand von Bearbeitungszeit, Fehlerquote, Nacharbeitsquote, Kosten und menschlichem Prüfaufwand. Ein AI-nativer Entwickler ist nicht einfach jemand, der Werkzeuge wie ChatGPT, Claude Code oder GitHub Copilot souverän verwendet. Genauer lässt er sich als **Entwickler definieren, der Kontext, Werkzeuge, Berechtigungen und Bewertungskriterien so gestaltet, dass AI ausführbare Aufgaben erledigt, während der Mensch Zielsetzung, Überprüfung, Genehmigung und Verantwortung übernimmt**. Allerdings ist „AI-nativer Entwickler“ weder eine anerkannte Qualifikation noch eine branchenweit einheitlich definierte Berufsbezeichnung. Da sich der Automatisierungsumfang je nach Risikoniveau der Organisation und des Produkts unterscheidet, darf dies nicht mit einem Zustand gleichgesetzt werden, in dem sämtliche Entscheidungen der AI überlassen werden. ## Definition des AI-nativen Entwicklers AI-native Entwicklung behandelt AI nicht als zusätzliches Werkzeug zur Codevervollständigung, sondern als **Ausführungsebene der Entwicklung**. Der Mensch strukturiert die zu erledigende Arbeit und legt Erfolgs- sowie Ausschlusskriterien fest, während die AI innerhalb des zulässigen Rahmens Aufgaben wie Recherche, Erstellung, Ausführung und Überarbeitung übernimmt. Die zentralen Rollen verteilen sich wie folgt. - **Mensch:** Problemdefinition, Prioritäten, Einschränkungen, Risikoklasse, Genehmigungskriterien und letztendliche Verantwortung - **AI-Agent:** Informationssuche, Planentwurf, Erstellung von Code und Tests, statische Analyse, iterative Überarbeitung - **Harness:** Dokumente, Werkzeuge, Berechtigungen, Zustandsverwaltung, Tests, Protokolle, Kostenlimits und Abbruchbedingungen Ein AI-Agent bezeichnet im Allgemeinen ein System, in dem ein Sprachmodell Werkzeuge verwendet und abhängig von Zwischenergebnissen die nächste Handlung auswählt. Anders als ein Workflow, der vorab festgelegten Abläufen folgt, kann ein Agent die Reihenfolge der Aufgaben innerhalb des zulässigen Rahmens dynamisch bestimmen. | Kategorie | AI-gestützte Entwicklung | AI-native Entwicklung | |---|---|---| | Position der AI | Werkzeug zur Codevervollständigung oder Beantwortung von Fragen | Teil der Ausführungsebene von Aufgaben | | Eingabe | Vorwiegend kurze Prompts | Spezifikationen, Repository-Kontext, Einschränkungen, Bewertungskriterien | | Rolle des Menschen | Direkte Implementierung mit anschließender Unterstützung durch AI | Problemgestaltung, Ausnahmeentscheidungen, Überprüfung und Genehmigung | | Qualitätsmanagement | Abhängig von der manuellen Prüfung durch den Entwickler | Tests, Evaluatoren und Review-Regeln sind im Harness enthalten | | Betriebsweise | Abhängig von der individuellen Nutzung | Verwaltung durch reproduzierbare Teamprozesse und Richtlinien | Ein wichtiger Grundsatz lautet: **Aufgaben können delegiert werden, Verantwortung jedoch nicht**. AI kann operative Entscheidungen mit geringem Risiko treffen, doch bei folgenreichen Entscheidungen zu Sicherheit, personenbezogenen Daten, Zahlungen, Medizin, Recht oder Produktionsänderungen ist eine strengere menschliche Genehmigung erforderlich. ## Angleichung der Programmierfähigkeiten und neue Differenzierungsmerkmale für Entwickler Generative AI senkt die Einstiegshürden für wiederkehrende Implementierungsaufgaben wie das Schreiben von Boilerplate-Code, die Suche nach Beispielen zur API-Nutzung, Testentwürfe und Refactoring-Vorschläge. Insofern hat sie einen gewissen Angleichungseffekt, da auch weniger erfahrene Entwickler schneller als zuvor funktionsfähige Entwürfe erstellen können. Es wäre jedoch ungenau, daraus zu schließen, dass „Unterschiede in den Programmierfähigkeiten verschwunden sind“. Um von AI erzeugte Ergebnisse zu bewerten, sind weiterhin folgende Kenntnisse erforderlich. 1. Die Fähigkeit, Widersprüche oder Lücken in Anforderungen zu erkennen 2. Die Fähigkeit, Systemgrenzen und Datenflüsse zu entwerfen 3. Die Fähigkeit, Kompromisse zwischen Leistung, Sicherheit, Kosten und Wartbarkeit zu beurteilen 4. Die Fähigkeit, plausibel wirkende, aber fehlerhafte Implementierungen zu erkennen 5. Die Fähigkeit, bei Störungen Ursachen nachzuverfolgen und den Betrieb wiederherzustellen Im Zeitalter der AI bewirken folgende Kompetenzen größere Unterschiede. - **Problemdefinition:** Konkretisierung des tatsächlichen Nutzerproblems und der Erfolgskriterien - **Produkt- und UX-Gespür:** Beurteilung von Nutzungsablauf, Verständlichkeit, Barrierefreiheit und Vertrauen statt nur des Vorhandenseins einer Funktion - **Zerlegungsfähigkeit:** Aufteilung eines großen Ziels in kleine, überprüfbare Aufgaben - **Bewertungsdesign:** Vorab-Erstellung von Tests, Checklisten, Bewertungsrastern und Genehmigungskriterien - **Kontextdesign:** Strukturierung von Dokumentation und Repository, damit die AI gezielt nur die benötigten Informationen findet - **Risikobeurteilung:** Unterscheidung zwischen automatisierbaren Aufgaben und Aufgaben, die eine menschliche Genehmigung erfordern Je schneller die Implementierung wird, desto wertvoller wird letztlich die Fähigkeit zu beurteilen, „was warum entwickelt werden soll“ und „ob das Ergebnis gut genug ist“. ## Markdown und Gestaltung maßgeblicher Dokumente Ein Agent kennt das implizite Wissen einer Organisation nicht automatisch. Wenn Anforderungen und Einschränkungen über Gespräche, Meetings, Codekommentare und persönliche Erinnerungen verteilt sind, steigt die Wahrscheinlichkeit, dass dieselben Fragen wiederholt gestellt werden oder mit unterschiedlichen Annahmen gearbeitet wird. Markdown ist als Format für Arbeitsdokumente nützlich, da sich Änderungshistorien in Git leicht verwalten lassen und es sowohl für Menschen als auch für die Verarbeitung durch AI vergleichsweise einfach ist. Wichtiger als das Dateiformat selbst ist jedoch, **eindeutig festzulegen, welches Dokument den aktuellen Maßstab darstellt**. ### Informationen, die das maßgebliche Dokument enthalten sollte - Produktziele, Nicht-Ziele und Nutzerszenarien - Funktionale Anforderungen und überprüfbare Abnahmekriterien - Repository-Struktur und Verantwortlichkeiten der einzelnen Module - API-Verträge, Datenmodelle und Migrationsregeln - Coding-Regeln, Testbefehle und Bereitstellungsverfahren - Dokumentation von Architekturentscheidungen und Gründen für Änderungen - Zugriffsberechtigungen, verbotene Tätigkeiten und Bedingungen für menschliche Genehmigungen - Bekannte Einschränkungen, Verfahren zur Störungsbehebung und zuständige Personen In einem GitHub Issue können Hintergrund, Umfang, Abnahmekriterien, zugehörige Dokumente und die Definition der Fertigstellung festgehalten werden. Langfristige Architektur- und Betriebsregeln sollten in versionierten Dokumenten, etwa in einem `docs`-Verzeichnis, abgelegt werden, während das Issue auf diese Dokumente verweist. ### Beispiel für eine Aufgabenspezifikation ```markdown # Ziel Die Meldung bei fehlgeschlagener Anmeldung so verbessern, dass Nutzer erkennen können, wie sie das Problem beheben können. # Umfang - Web-Anmeldebildschirm - Meldungen auf Koreanisch und Englisch # Nicht im Umfang - Änderung der Authentifizierungsmethode - Änderung der Passwortrichtlinie # Abnahmekriterien - Es wird nach außen nicht offengelegt, ob ein Konto existiert. - Die Barrierefreiheitsprüfung und die bestehenden Authentifizierungstests werden bestanden. - Bei einem Fehler kann zum ursprünglichen Verhalten zurückgekehrt werden. # Prüfungsbefehle - npm test - npm run lint ``` Gut strukturierte Dokumente können verhindern, dass ein Agent jedes Mal die gesamte Codebasis lesen muss. Allerdings sinken dadurch Tokenverbrauch oder Kosten nicht zwangsläufig. Doppelte oder veraltete Dokumente können vielmehr zusätzliche Recherchen und fehlerhafte Änderungen verursachen. Daher müssen auch Dokumentverantwortliche, Aktualisierungszeitpunkte und Regeln für automatische Prüfungen festgelegt werden. Passwörter, API-Schlüssel, echte Kundendaten und übermäßig weitreichende Datenbankberechtigungen dürfen nicht in Dokumenten festgehalten werden. Schemabeispiele müssen anonymisiert und vertrauliche Informationen in einem separaten sicheren Speicher verwaltet werden. ## Minimalstruktur eines AI-Agent-Harness Harness Engineering bezeichnet die Gestaltung der Ausführungsumgebung rund um ein Modell. Dazu gehören Systemanweisungen, Werkzeuganbindungen, Kontextsuche, Berechtigungen, Speicher, Tests, Beobachtbarkeit, Wiederholungsversuche und Abbruchbedingungen. Die minimale Ausführungsschleife kann aus Plan, Draft und Review bestehen. | Phase | Zentrale Frage | Ergebnis | Vorgehen bei Fehlern | |---|---|---|---| | Plan | Ist diese Aufgabe erforderlich, und wie sehen Umfang und Risiko aus? | Plan, Änderungsziele, Prüfverfahren | Ergänzende Informationen anfordern oder Aufgabe abbrechen | | Draft | Wurde der Plan in der kleinstmöglichen sicheren Einheit umgesetzt? | Code, Tests, Dokumentänderungen | Überarbeitung mit begrenzter Anzahl an Versuchen | | Review | Werden Anforderungen und Qualitätskriterien erfüllt? | Bewertungsergebnis, Fehlerliste, Genehmigungsvorschlag | Nacharbeit oder Übergabe an einen Menschen | Ein tatsächlicher Harness benötigt folgende Kontrollmechanismen. - Zulässige Dateien, Befehle sowie Netzwerk- und Datenbereiche - Maximale Ausführungszeit, Anzahl der Werkzeugaufrufe und Kostenlimit - Abbruchbedingungen bei fehlgeschlagenen Tests oder hoher Unsicherheit - Protokolle sämtlicher Eingaben, Werkzeugaufrufe, Änderungen und Genehmigungen - Menschliche Genehmigungsstufe vor der Übernahme in die Produktion - Rollback-Verfahren zur Wiederherstellung des ursprünglichen Zustands ### Einzelagent und Multi-Agenten-System Plan, Draft und Review erfordern nicht zwingend drei separate Modelle oder Agenten. Ein einzelner Agent kann diese Phasen auch mithilfe phasenspezifischer Anweisungen und Werkzeuge durchführen. In einer Multi-Agenten-Struktur können die Rollen wie folgt getrennt werden. - **Planner:** Analysiert Anforderungen und prüft Notwendigkeit, Umfang und Risiko der Funktion. - **Generator:** Erstellt gemäß dem Plan Code, Tests und Dokumentation. - **Evaluator:** Prüft das Ergebnis anhand unabhängiger Kriterien und zeigt Mängel sowie Verbesserungsmöglichkeiten auf. Die Rollentrennung kann unabhängige Kritik und parallele Erkundung unterstützen. Gleichzeitig werden jedoch auch Aufrufkosten, Latenzzeiten, Zustandssynchronisierung und die Nachverfolgung von Fehlerursachen komplexer. Bei einfachen Aufgaben können deterministische Skripte oder ein einzelner Agent stabiler sein. Multi-Agenten-Systeme sollten eingeführt werden, wenn der gemessene Verbesserungseffekt die zusätzliche Komplexität rechtfertigt. ## Einführungsverfahren für Teams und Unternehmen Allein durch eine Ankündigung zur AI-Einführung und Schulungen entsteht keine AI-native Organisation. Zulässiger Umfang, Datenrichtlinien, Qualitätsstandards und Verantwortungsstrukturen müssen gemeinsam geschaffen werden. ### Phase 1: Ausgangsbasis und Richtlinien festlegen - Aktuelle Bearbeitungszeit, Fehlerquote, Wartezeit bei Reviews und Bereitstellungshäufigkeit messen. - Festlegen, welche Daten nicht eingegeben und welche Werkzeuge verwendet werden dürfen. - Zwischen automatisch ausführbaren Aufgaben und Aufgaben mit erforderlicher menschlicher Genehmigung unterscheiden. ### Phase 2: Champion und begrenztes Pilotprojekt Im Team wird ein Champion mit Erfahrung in der AI-Nutzung und Schulungskompetenz bestimmt. Die Aufgabe des Champions besteht nicht darin, Werkzeuge zu bewerben, sondern reproduzierbare Anwendungsfälle, Fehlerfälle und Sicherheitsregeln zu dokumentieren. Es ist sicherer, das Pilotprojekt mit Aufgaben zu beginnen, deren Ergebnisse leicht überprüfbar sind, etwa Testerstellung, Strukturierung interner Dokumentation oder Refactoring mit geringem Risiko. ### Phase 3: Standardisierung erfolgreicher Muster - Eingabedokumente und Bewertungskriterien vorrangig dokumentieren, nicht die wirksamen Prompts. - Gemeinsame Issue-Vorlagen und eine Definition der Fertigstellung erstellen. - Tests, Linting, Sicherheitsprüfungen und Review-Verfahren automatisieren. - Fehlerursachen und Eingriffspunkte für Menschen dokumentieren. ### Phase 4: Betrieb und Ausweitung Wenn die Ergebnisse des Pilotprojekts gegenüber der Ausgangsbasis verbessert wurden, wird der Anwendungsbereich erweitert. Werkzeugauswahl, Schulung, Kostenmanagement, Zugriffsberechtigungen, Störungsreaktion und regelmäßige Bewertung müssen zu einem einheitlichen Betriebssystem verbunden werden. ## Kennzahlen zur Leistungsmessung Die Anzahl erzeugter Codezeilen oder AI-Nutzungen zeigt Produktivität und Qualität nicht unmittelbar. Daher müssen zusätzlich ergebnisorientierte Kennzahlen wie die folgenden gemessen werden. | Bereich | Empfohlene Kennzahl | Bei der Interpretation zu beachten | |---|---|---| | Geschwindigkeit | Zeit vom Beginn einer Aufgabe bis zur Bereitstellung | Auch Zeit für Prüfung und Nacharbeit einbeziehen. | | Qualität | Fehlerquote nach der Bereitstellung, Testfehlerquote | Einfache und schwierige Aufgaben getrennt betrachten. | | Effizienz | Modellkosten pro Aufgabe, Anzahl der Werkzeugaufrufe | Kosten der menschlichen Prüfung nicht ausklammern. | | Stabilität | Rollback-Quote, Sicherheitswarnungen, Berechtigungsverstöße | Auch die Möglichkeit unentdeckter Probleme berücksichtigen. | | Akzeptanz | Anteil der Teams mit wiederholter Nutzung, abgeschlossene reale Aufgaben | Von bloßen Anmeldungen oder Aufrufzahlen unterscheiden. | | Erfahrung | Entwicklerzufriedenheit, kognitive Belastung, Review-Müdigkeit | Auch bei höherer Geschwindigkeit kann die Ermüdung zunehmen. | Die Ergebnisse der AI-Nutzungsgruppe und der herkömmlichen Arbeitsweise müssen bei identischen Aufgabentypen verglichen werden. Dabei sind nicht nur die kurzfristige Geschwindigkeit, sondern auch Wartungskosten und Störungen zu beobachten. ## Sicherheits- und Qualitätsrisiken Da AI-Agenten Code lesen, Befehle ausführen und externe Inhalte abrufen können, verfügen sie über eine größere Angriffsfläche als gewöhnliche Chats. Zu den wichtigsten Risiken gehören: - Prompt-Injection, bei der versteckte Anweisungen in Repository-Dokumenten oder externen Seiten befolgt werden - Vergabe übermäßig weitreichender Datei-, Datenbank- oder Bereitstellungsberechtigungen - Fehlerhafter Code, der nicht existierende APIs oder Pakete verwendet - Einführung anfälliger Abhängigkeiten oder von Code mit unklarer Lizenz - Abschwächung der Prüfkriterien selbst, um Tests zu bestehen - Externe Übertragung von Kundendaten, geheimen Schlüsseln und internem Code - Unerwartete Kostensteigerungen durch wiederholte Ausführung Die Grundsätze zur Risikobegrenzung lauten minimale Berechtigungen, isolierte Ausführungsumgebungen, Zulassungslisten, Trennung vertraulicher Informationen, unabhängige Tests, Änderungsprotokolle und menschliche Genehmigungen. Insbesondere können gemeinsame Fehler übersehen werden, wenn die Implementierung eines Agenten ausschließlich anhand von Tests bewertet wird, die derselbe Agent geschrieben hat. Daher sollten bestehende Regressionstests und separate Prüfkriterien beibehalten werden. ## Überreaktionen auf Werkzeuge vermeiden Ständig erscheinen neue Modelle, Plug-ins und Agenten-Frameworks, doch es ist nicht notwendig, jedes Werkzeug zu erlernen. Werkzeuge sollten nicht anhand ihres Namens oder eines Trends, sondern mithilfe der folgenden Fragen bewertet werden. 1. Ist die wiederkehrende Aufgabe, die aktuell gelöst werden soll, klar definiert? 2. Lässt sich das Werkzeug sicher mit der bestehenden Entwicklungsumgebung und dem Berechtigungssystem verbinden? 3. Kann die Qualität der Ausgabe automatisch oder manuell überprüft werden? 4. Lassen sich Kosten, Latenzzeit und Fehlerquote beobachten? 5. Bleiben Spezifikationen, Tests und Dokumentation auch bei einem Wechsel des Werkzeugs erhalten? Mit einem zum Team passenden Werkzeug eine tatsächliche Produktverbesserung vollständig umzusetzen und das Ergebnis zu messen, ist wertvoller, als die Verwendung mehrerer Werkzeuge nur oberflächlich zu erlernen. ## Praxis-Checkliste für AI-native Entwickler - [ ] Ziele, Nicht-Ziele und Abnahmekriterien vor der Implementierung dokumentieren. - [ ] Werkzeuge und Zugriffsbereiche der AI auf das Minimum beschränken. - [ ] Große Aufgaben in unabhängig überprüfbare Einheiten aufteilen. - [ ] Zusammen mit dem Code auch Tests, Dokumentation und ein Rollback-Verfahren anfordern. - [ ] Bei wichtigen Änderungen diff und Ausführungsergebnisse durch einen Menschen prüfen lassen. - [ ] Fehler, Wiederholungsversuche, Kosten und menschliche Eingriffe protokollieren. - [ ] Messen, ob die Automatisierung Qualität und Abschlusszeit tatsächlich verbessert hat. - [ ] Dem Agenten ermöglichen, Aufgaben mit geringem Wert oder hohem Risiko abzulehnen oder weiterzugeben. ## Fazit Die Wettbewerbsfähigkeit eines AI-nativen Entwicklers entsteht nicht durch einen bestimmten Prompt oder den Namen eines Werkzeugs. Sie beruht auf der **Fähigkeit, Probleme präzise zu definieren, eine Umgebung für die sichere Ausführung durch Agenten zu schaffen sowie die Qualität der Ergebnisse zu beurteilen und dafür Verantwortung zu übernehmen**. AI kann große Teile der Implementierung schnell erstellen, garantiert jedoch nicht automatisch die richtige Produktausrichtung, Nutzererfahrung, Systemsicherheit und letztendliche Verantwortung. Entwickler sollten das Programmieren daher nicht aufgeben, sondern ihre Rolle auf Grundlage ihres Programmierwissens auf Spezifikation, Bewertung, Produktentscheidungen und Systembetrieb ausweiten. ## FAQ ### Ist ein AI-nativer Entwickler dasselbe wie ein Prompt Engineer? Nein. Das Verfassen von Prompts ist nur eine Teilkompetenz. Ein AI-nativer Entwickler befasst sich mit dem gesamten Ausführungssystem, einschließlich der Zerlegung von Problemen, der Bereitstellung von Kontext, der Gestaltung von Werkzeugen und Berechtigungen, Tests, Beobachtung, Genehmigungen und Betrieb. ### Programmiert ein AI-nativer Entwickler nicht selbst? Nicht unbedingt. Der Anteil des selbst geschriebenen Codes kann sinken, doch um von AI erzeugten Code zu verstehen und zu debuggen sowie Architektur-, Leistungs- und Sicherheitsprobleme zu beurteilen, sind fundierte Entwicklungskenntnisse erforderlich. ### Kann man einem AI-Agenten alle Entscheidungen überlassen? Nein. Begrenzte Entscheidungen mit geringem Risiko lassen sich automatisieren, doch bei folgenreichen Entscheidungen wie Datenlöschungen, Zahlungen, Sicherheitsberechtigungen und Produktionsbereitstellungen sind eine ausdrückliche menschliche Genehmigung und Wiederherstellungsverfahren erforderlich. ### Sind für Plan, Draft und Review zwingend drei Agenten erforderlich? Nein. Auch ein einzelner Agent oder ein deterministischer Workflow kann die drei Schritte ausführen. Multi-Agenten-Systeme eignen sich, wenn die Vorteile unabhängiger Bewertungen oder paralleler Erkundungen die zusätzlichen Kosten und die betriebliche Komplexität überwiegen. ### Senken Markdown-Dokumente immer die Token-Kosten? Nicht immer. Kurze, strukturierte und aktuelle Dokumente können unnötige Suchen reduzieren, doch redundante oder veraltete Dokumente führen zu fehlerhaften Arbeiten und zusätzlicher Suche. Zusätzlich sind eine klare Zuständigkeit für die Aktualisierung der Dokumente und Prüfverfahren erforderlich. ### Wo sollte man mit der AI-nativen Transformation beginnen? Nach der Messung einer Ausgangsbasis für die aktuelle Leistung empfiehlt es sich, eine leicht überprüfbare Aufgabe auszuwählen, etwa die Erstellung von Tests, die Aufbereitung der Dokumentation oder ein risikoarmes Refactoring. Eine Ausweitung sollte erst erfolgen, nachdem in einem begrenzten Pilotprojekt Qualität, Fertigstellungszeit, Kosten und Prüfaufwand überprüft wurden. ### Hat AI die Programmierfähigkeiten vollständig angeglichen? AI senkt die Einstiegshürde für wiederkehrende Implementierungen und das Erstellen von Entwürfen, beseitigt aber nicht die Unterschiede in den Entwicklungskompetenzen. Die Fähigkeiten zur Anforderungsanalyse, Architektur, Fehlerbehebung, Sicherheit, Leistungsoptimierung und Ergebnisprüfung haben weiterhin großen Einfluss auf die Qualität. ### Muss man mehrere AI-Entwicklungswerkzeuge erlernen, um wettbewerbsfähig zu werden? Die Anzahl der Werkzeuge ist an sich kein Wettbewerbsvorteil. Es ist besser, zunächst ein Werkzeug auszuwählen, mit dem sich eine konkrete Arbeitsaufgabe zuverlässig abschließen und deren Qualität und Kosten messen lassen. Wenn Spezifikationen und Tests werkzeugunabhängig verwaltet werden, ist auch ein späterer Wechsel einfacher. ### Wie misst man die Leistung eines AI-nativen Entwicklungsteams? Statt der Menge des erzeugten Codes sollten die Zeit bis zum Abschluss einer Aufgabe, Fehler nach der Bereitstellung, Nacharbeit, Rollbacks, Modellkosten, Prüfzeit und die Ermüdung der Entwickler gemeinsam gemessen werden. Eine aussagekräftige Interpretation ist nur durch den Vergleich mit einer Ausgangsbasis vor der Einführung und mit ähnlichen Aufgabentypen möglich. ## Sources - [Anthropic: Effektive Agenten entwickeln](https://www.anthropic.com/research/building-effective-agents) - [GitHub Docs: Informationen zu Issues](https://docs.github.com/en/issues/tracking-your-work-with-issues/about-issues) - [GitHub Docs: Informationen zum Schreiben und Formatieren auf GitHub](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/about-writing-and-formatting-on-github) - [NIST-Risikomanagement-Framework für KI](https://www.nist.gov/itl/ai-risk-management-framework) - [OWASP Top 10 für Anwendungen mit großen Sprachmodellen](https://genai.owasp.org/llm-top-10/) ## Images ![Entwickler steuert Entwurf, Code, Tests, Sicherheit und Bereitstellung von KI-Agenten über vernetzte Dashboards](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NTQ1NiwicHVyIjoiYmxvYl9pZCJ9fQ==--dcc52a99856a48635d1882fba812226f930329f5/ai-4dab44ed.webp) ![Workflow-Diagramm von KI-Agenten, die Entwicklungsmodule in einer sicheren Umgebung verbinden und prüfen](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NTQ2MiwicHVyIjoiYmxvYl9pZCJ9fQ==--9fdf22aa2cbd420f209ff5c18baea59124f816b9/ai-f15eba1a.webp)