{"content_id":"zuag1vtnf2","slug":"ai-native-developer-definition-and-practices","locale":"de","schema_type":"TechArticle","category":"ai_data","category_name":"KI-Daten","title":"Was ist ein AI-nativer Entwickler? Rolle, Kompetenzen und Betriebsstruktur für Agenten","summary":"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.","author":{"name":"injoys","url":"https://injoys.com/ko/about"},"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."],"content_markdown":"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**.\n\nAllerdings 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.\n\n## Definition des AI-nativen Entwicklers\n\nAI-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.\n\nDie zentralen Rollen verteilen sich wie folgt.\n\n- **Mensch:** Problemdefinition, Prioritäten, Einschränkungen, Risikoklasse, Genehmigungskriterien und letztendliche Verantwortung\n- **AI-Agent:** Informationssuche, Planentwurf, Erstellung von Code und Tests, statische Analyse, iterative Überarbeitung\n- **Harness:** Dokumente, Werkzeuge, Berechtigungen, Zustandsverwaltung, Tests, Protokolle, Kostenlimits und Abbruchbedingungen\n\nEin 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.\n\n| Kategorie | AI-gestützte Entwicklung | AI-native Entwicklung |\n|---|---|---|\n| Position der AI | Werkzeug zur Codevervollständigung oder Beantwortung von Fragen | Teil der Ausführungsebene von Aufgaben |\n| Eingabe | Vorwiegend kurze Prompts | Spezifikationen, Repository-Kontext, Einschränkungen, Bewertungskriterien |\n| Rolle des Menschen | Direkte Implementierung mit anschließender Unterstützung durch AI | Problemgestaltung, Ausnahmeentscheidungen, Überprüfung und Genehmigung |\n| Qualitätsmanagement | Abhängig von der manuellen Prüfung durch den Entwickler | Tests, Evaluatoren und Review-Regeln sind im Harness enthalten |\n| Betriebsweise | Abhängig von der individuellen Nutzung | Verwaltung durch reproduzierbare Teamprozesse und Richtlinien |\n\nEin 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.\n\n## Angleichung der Programmierfähigkeiten und neue Differenzierungsmerkmale für Entwickler\n\nGenerative 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.\n\nEs 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.\n\n1. Die Fähigkeit, Widersprüche oder Lücken in Anforderungen zu erkennen\n2. Die Fähigkeit, Systemgrenzen und Datenflüsse zu entwerfen\n3. Die Fähigkeit, Kompromisse zwischen Leistung, Sicherheit, Kosten und Wartbarkeit zu beurteilen\n4. Die Fähigkeit, plausibel wirkende, aber fehlerhafte Implementierungen zu erkennen\n5. Die Fähigkeit, bei Störungen Ursachen nachzuverfolgen und den Betrieb wiederherzustellen\n\nIm Zeitalter der AI bewirken folgende Kompetenzen größere Unterschiede.\n\n- **Problemdefinition:** Konkretisierung des tatsächlichen Nutzerproblems und der Erfolgskriterien\n- **Produkt- und UX-Gespür:** Beurteilung von Nutzungsablauf, Verständlichkeit, Barrierefreiheit und Vertrauen statt nur des Vorhandenseins einer Funktion\n- **Zerlegungsfähigkeit:** Aufteilung eines großen Ziels in kleine, überprüfbare Aufgaben\n- **Bewertungsdesign:** Vorab-Erstellung von Tests, Checklisten, Bewertungsrastern und Genehmigungskriterien\n- **Kontextdesign:** Strukturierung von Dokumentation und Repository, damit die AI gezielt nur die benötigten Informationen findet\n- **Risikobeurteilung:** Unterscheidung zwischen automatisierbaren Aufgaben und Aufgaben, die eine menschliche Genehmigung erfordern\n\nJe 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“.\n\n## Markdown und Gestaltung maßgeblicher Dokumente\n\nEin 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.\n\nMarkdown 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**.\n\n### Informationen, die das maßgebliche Dokument enthalten sollte\n\n- Produktziele, Nicht-Ziele und Nutzerszenarien\n- Funktionale Anforderungen und überprüfbare Abnahmekriterien\n- Repository-Struktur und Verantwortlichkeiten der einzelnen Module\n- API-Verträge, Datenmodelle und Migrationsregeln\n- Coding-Regeln, Testbefehle und Bereitstellungsverfahren\n- Dokumentation von Architekturentscheidungen und Gründen für Änderungen\n- Zugriffsberechtigungen, verbotene Tätigkeiten und Bedingungen für menschliche Genehmigungen\n- Bekannte Einschränkungen, Verfahren zur Störungsbehebung und zuständige Personen\n\nIn 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.\n\n### Beispiel für eine Aufgabenspezifikation\n\n```markdown\n# Ziel\nDie Meldung bei fehlgeschlagener Anmeldung so verbessern, dass Nutzer erkennen können, wie sie das Problem beheben können.\n\n# Umfang\n- Web-Anmeldebildschirm\n- Meldungen auf Koreanisch und Englisch\n\n# Nicht im Umfang\n- Änderung der Authentifizierungsmethode\n- Änderung der Passwortrichtlinie\n\n# Abnahmekriterien\n- Es wird nach außen nicht offengelegt, ob ein Konto existiert.\n- Die Barrierefreiheitsprüfung und die bestehenden Authentifizierungstests werden bestanden.\n- Bei einem Fehler kann zum ursprünglichen Verhalten zurückgekehrt werden.\n\n# Prüfungsbefehle\n- npm test\n- npm run lint\n```\n\nGut 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.\n\nPasswö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.\n\n## Minimalstruktur eines AI-Agent-Harness\n\nHarness Engineering bezeichnet die Gestaltung der Ausführungsumgebung rund um ein Modell. Dazu gehören Systemanweisungen, Werkzeuganbindungen, Kontextsuche, Berechtigungen, Speicher, Tests, Beobachtbarkeit, Wiederholungsversuche und Abbruchbedingungen.\n\nDie minimale Ausführungsschleife kann aus Plan, Draft und Review bestehen.\n\n| Phase | Zentrale Frage | Ergebnis | Vorgehen bei Fehlern |\n|---|---|---|---|\n| Plan | Ist diese Aufgabe erforderlich, und wie sehen Umfang und Risiko aus? | Plan, Änderungsziele, Prüfverfahren | Ergänzende Informationen anfordern oder Aufgabe abbrechen |\n| Draft | Wurde der Plan in der kleinstmöglichen sicheren Einheit umgesetzt? | Code, Tests, Dokumentänderungen | Überarbeitung mit begrenzter Anzahl an Versuchen |\n| Review | Werden Anforderungen und Qualitätskriterien erfüllt? | Bewertungsergebnis, Fehlerliste, Genehmigungsvorschlag | Nacharbeit oder Übergabe an einen Menschen |\n\nEin tatsächlicher Harness benötigt folgende Kontrollmechanismen.\n\n- Zulässige Dateien, Befehle sowie Netzwerk- und Datenbereiche\n- Maximale Ausführungszeit, Anzahl der Werkzeugaufrufe und Kostenlimit\n- Abbruchbedingungen bei fehlgeschlagenen Tests oder hoher Unsicherheit\n- Protokolle sämtlicher Eingaben, Werkzeugaufrufe, Änderungen und Genehmigungen\n- Menschliche Genehmigungsstufe vor der Übernahme in die Produktion\n- Rollback-Verfahren zur Wiederherstellung des ursprünglichen Zustands\n\n### Einzelagent und Multi-Agenten-System\n\nPlan, 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.\n\nIn einer Multi-Agenten-Struktur können die Rollen wie folgt getrennt werden.\n\n- **Planner:** Analysiert Anforderungen und prüft Notwendigkeit, Umfang und Risiko der Funktion.\n- **Generator:** Erstellt gemäß dem Plan Code, Tests und Dokumentation.\n- **Evaluator:** Prüft das Ergebnis anhand unabhängiger Kriterien und zeigt Mängel sowie Verbesserungsmöglichkeiten auf.\n\nDie 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.\n\n## Einführungsverfahren für Teams und Unternehmen\n\nAllein 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.\n\n### Phase 1: Ausgangsbasis und Richtlinien festlegen\n\n- Aktuelle Bearbeitungszeit, Fehlerquote, Wartezeit bei Reviews und Bereitstellungshäufigkeit messen.\n- Festlegen, welche Daten nicht eingegeben und welche Werkzeuge verwendet werden dürfen.\n- Zwischen automatisch ausführbaren Aufgaben und Aufgaben mit erforderlicher menschlicher Genehmigung unterscheiden.\n\n### Phase 2: Champion und begrenztes Pilotprojekt\n\nIm 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.\n\nEs ist sicherer, das Pilotprojekt mit Aufgaben zu beginnen, deren Ergebnisse leicht überprüfbar sind, etwa Testerstellung, Strukturierung interner Dokumentation oder Refactoring mit geringem Risiko.\n\n### Phase 3: Standardisierung erfolgreicher Muster\n\n- Eingabedokumente und Bewertungskriterien vorrangig dokumentieren, nicht die wirksamen Prompts.\n- Gemeinsame Issue-Vorlagen und eine Definition der Fertigstellung erstellen.\n- Tests, Linting, Sicherheitsprüfungen und Review-Verfahren automatisieren.\n- Fehlerursachen und Eingriffspunkte für Menschen dokumentieren.\n\n### Phase 4: Betrieb und Ausweitung\n\nWenn 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.\n\n## Kennzahlen zur Leistungsmessung\n\nDie 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.\n\n| Bereich | Empfohlene Kennzahl | Bei der Interpretation zu beachten |\n|---|---|---|\n| Geschwindigkeit | Zeit vom Beginn einer Aufgabe bis zur Bereitstellung | Auch Zeit für Prüfung und Nacharbeit einbeziehen. |\n| Qualität | Fehlerquote nach der Bereitstellung, Testfehlerquote | Einfache und schwierige Aufgaben getrennt betrachten. |\n| Effizienz | Modellkosten pro Aufgabe, Anzahl der Werkzeugaufrufe | Kosten der menschlichen Prüfung nicht ausklammern. |\n| Stabilität | Rollback-Quote, Sicherheitswarnungen, Berechtigungsverstöße | Auch die Möglichkeit unentdeckter Probleme berücksichtigen. |\n| Akzeptanz | Anteil der Teams mit wiederholter Nutzung, abgeschlossene reale Aufgaben | Von bloßen Anmeldungen oder Aufrufzahlen unterscheiden. |\n| Erfahrung | Entwicklerzufriedenheit, kognitive Belastung, Review-Müdigkeit | Auch bei höherer Geschwindigkeit kann die Ermüdung zunehmen. |\n\nDie 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.\n\n## Sicherheits- und Qualitätsrisiken\n\nDa 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.\n\nZu den wichtigsten Risiken gehören:\n\n- Prompt-Injection, bei der versteckte Anweisungen in Repository-Dokumenten oder externen Seiten befolgt werden\n- Vergabe übermäßig weitreichender Datei-, Datenbank- oder Bereitstellungsberechtigungen\n- Fehlerhafter Code, der nicht existierende APIs oder Pakete verwendet\n- Einführung anfälliger Abhängigkeiten oder von Code mit unklarer Lizenz\n- Abschwächung der Prüfkriterien selbst, um Tests zu bestehen\n- Externe Übertragung von Kundendaten, geheimen Schlüsseln und internem Code\n- Unerwartete Kostensteigerungen durch wiederholte Ausführung\n\nDie 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.\n\n## Überreaktionen auf Werkzeuge vermeiden\n\nStä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.\n\n1. Ist die wiederkehrende Aufgabe, die aktuell gelöst werden soll, klar definiert?\n2. Lässt sich das Werkzeug sicher mit der bestehenden Entwicklungsumgebung und dem Berechtigungssystem verbinden?\n3. Kann die Qualität der Ausgabe automatisch oder manuell überprüft werden?\n4. Lassen sich Kosten, Latenzzeit und Fehlerquote beobachten?\n5. Bleiben Spezifikationen, Tests und Dokumentation auch bei einem Wechsel des Werkzeugs erhalten?\n\nMit 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.\n\n## Praxis-Checkliste für AI-native Entwickler\n\n- [ ] Ziele, Nicht-Ziele und Abnahmekriterien vor der Implementierung dokumentieren.\n- [ ] Werkzeuge und Zugriffsbereiche der AI auf das Minimum beschränken.\n- [ ] Große Aufgaben in unabhängig überprüfbare Einheiten aufteilen.\n- [ ] Zusammen mit dem Code auch Tests, Dokumentation und ein Rollback-Verfahren anfordern.\n- [ ] Bei wichtigen Änderungen diff und Ausführungsergebnisse durch einen Menschen prüfen lassen.\n- [ ] Fehler, Wiederholungsversuche, Kosten und menschliche Eingriffe protokollieren.\n- [ ] Messen, ob die Automatisierung Qualität und Abschlusszeit tatsächlich verbessert hat.\n- [ ] Dem Agenten ermöglichen, Aufgaben mit geringem Wert oder hohem Risiko abzulehnen oder weiterzugeben.\n\n## Fazit\n\nDie 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**.\n\nAI 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.","content_html":"\u003cp\u003eEin 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 \u003cstrong\u003eEntwickler 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\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eAllerdings 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#definition-des-ai-nativen-entwicklers\" class=\"anchor\" id=\"definition-des-ai-nativen-entwicklers\"\u003e\u003c/a\u003eDefinition des AI-nativen Entwicklers\u003c/h2\u003e\n\u003cp\u003eAI-native Entwicklung behandelt AI nicht als zusätzliches Werkzeug zur Codevervollständigung, sondern als \u003cstrong\u003eAusführungsebene der Entwicklung\u003c/strong\u003e. 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.\u003c/p\u003e\n\u003cp\u003eDie zentralen Rollen verteilen sich wie folgt.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003eMensch:\u003c/strong\u003e Problemdefinition, Prioritäten, Einschränkungen, Risikoklasse, Genehmigungskriterien und letztendliche Verantwortung\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eAI-Agent:\u003c/strong\u003e Informationssuche, Planentwurf, Erstellung von Code und Tests, statische Analyse, iterative Überarbeitung\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eHarness:\u003c/strong\u003e Dokumente, Werkzeuge, Berechtigungen, Zustandsverwaltung, Tests, Protokolle, Kostenlimits und Abbruchbedingungen\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eEin 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eKategorie\u003c/th\u003e\n\u003cth\u003eAI-gestützte Entwicklung\u003c/th\u003e\n\u003cth\u003eAI-native Entwicklung\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Kategorie\"\u003ePosition der AI\u003c/td\u003e\n\u003ctd data-label=\"AI-gestützte Entwicklung\"\u003eWerkzeug zur Codevervollständigung oder Beantwortung von Fragen\u003c/td\u003e\n\u003ctd data-label=\"AI-native Entwicklung\"\u003eTeil der Ausführungsebene von Aufgaben\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Kategorie\"\u003eEingabe\u003c/td\u003e\n\u003ctd data-label=\"AI-gestützte Entwicklung\"\u003eVorwiegend kurze Prompts\u003c/td\u003e\n\u003ctd data-label=\"AI-native Entwicklung\"\u003eSpezifikationen, Repository-Kontext, Einschränkungen, Bewertungskriterien\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Kategorie\"\u003eRolle des Menschen\u003c/td\u003e\n\u003ctd data-label=\"AI-gestützte Entwicklung\"\u003eDirekte Implementierung mit anschließender Unterstützung durch AI\u003c/td\u003e\n\u003ctd data-label=\"AI-native Entwicklung\"\u003eProblemgestaltung, Ausnahmeentscheidungen, Überprüfung und Genehmigung\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Kategorie\"\u003eQualitätsmanagement\u003c/td\u003e\n\u003ctd data-label=\"AI-gestützte Entwicklung\"\u003eAbhängig von der manuellen Prüfung durch den Entwickler\u003c/td\u003e\n\u003ctd data-label=\"AI-native Entwicklung\"\u003eTests, Evaluatoren und Review-Regeln sind im Harness enthalten\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Kategorie\"\u003eBetriebsweise\u003c/td\u003e\n\u003ctd data-label=\"AI-gestützte Entwicklung\"\u003eAbhängig von der individuellen Nutzung\u003c/td\u003e\n\u003ctd data-label=\"AI-native Entwicklung\"\u003eVerwaltung durch reproduzierbare Teamprozesse und Richtlinien\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eEin wichtiger Grundsatz lautet: \u003cstrong\u003eAufgaben können delegiert werden, Verantwortung jedoch nicht\u003c/strong\u003e. 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#angleichung-der-programmierf%C3%A4higkeiten-und-neue-differenzierungsmerkmale-f%C3%BCr-entwickler\" class=\"anchor\" id=\"angleichung-der-programmierfähigkeiten-und-neue-differenzierungsmerkmale-für-entwickler\"\u003e\u003c/a\u003eAngleichung der Programmierfähigkeiten und neue Differenzierungsmerkmale für Entwickler\u003c/h2\u003e\n\u003cp\u003eGenerative 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.\u003c/p\u003e\n\u003cp\u003eEs 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.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eDie Fähigkeit, Widersprüche oder Lücken in Anforderungen zu erkennen\u003c/li\u003e\n\u003cli\u003eDie Fähigkeit, Systemgrenzen und Datenflüsse zu entwerfen\u003c/li\u003e\n\u003cli\u003eDie Fähigkeit, Kompromisse zwischen Leistung, Sicherheit, Kosten und Wartbarkeit zu beurteilen\u003c/li\u003e\n\u003cli\u003eDie Fähigkeit, plausibel wirkende, aber fehlerhafte Implementierungen zu erkennen\u003c/li\u003e\n\u003cli\u003eDie Fähigkeit, bei Störungen Ursachen nachzuverfolgen und den Betrieb wiederherzustellen\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eIm Zeitalter der AI bewirken folgende Kompetenzen größere Unterschiede.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003eProblemdefinition:\u003c/strong\u003e Konkretisierung des tatsächlichen Nutzerproblems und der Erfolgskriterien\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eProdukt- und UX-Gespür:\u003c/strong\u003e Beurteilung von Nutzungsablauf, Verständlichkeit, Barrierefreiheit und Vertrauen statt nur des Vorhandenseins einer Funktion\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eZerlegungsfähigkeit:\u003c/strong\u003e Aufteilung eines großen Ziels in kleine, überprüfbare Aufgaben\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eBewertungsdesign:\u003c/strong\u003e Vorab-Erstellung von Tests, Checklisten, Bewertungsrastern und Genehmigungskriterien\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eKontextdesign:\u003c/strong\u003e Strukturierung von Dokumentation und Repository, damit die AI gezielt nur die benötigten Informationen findet\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eRisikobeurteilung:\u003c/strong\u003e Unterscheidung zwischen automatisierbaren Aufgaben und Aufgaben, die eine menschliche Genehmigung erfordern\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eJe 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“.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#markdown-und-gestaltung-ma%C3%9Fgeblicher-dokumente\" class=\"anchor\" id=\"markdown-und-gestaltung-maßgeblicher-dokumente\"\u003e\u003c/a\u003eMarkdown und Gestaltung maßgeblicher Dokumente\u003c/h2\u003e\n\u003cp\u003eEin 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.\u003c/p\u003e\n\u003cp\u003eMarkdown 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, \u003cstrong\u003eeindeutig festzulegen, welches Dokument den aktuellen Maßstab darstellt\u003c/strong\u003e.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#informationen-die-das-ma%C3%9Fgebliche-dokument-enthalten-sollte\" class=\"anchor\" id=\"informationen-die-das-maßgebliche-dokument-enthalten-sollte\"\u003e\u003c/a\u003eInformationen, die das maßgebliche Dokument enthalten sollte\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eProduktziele, Nicht-Ziele und Nutzerszenarien\u003c/li\u003e\n\u003cli\u003eFunktionale Anforderungen und überprüfbare Abnahmekriterien\u003c/li\u003e\n\u003cli\u003eRepository-Struktur und Verantwortlichkeiten der einzelnen Module\u003c/li\u003e\n\u003cli\u003eAPI-Verträge, Datenmodelle und Migrationsregeln\u003c/li\u003e\n\u003cli\u003eCoding-Regeln, Testbefehle und Bereitstellungsverfahren\u003c/li\u003e\n\u003cli\u003eDokumentation von Architekturentscheidungen und Gründen für Änderungen\u003c/li\u003e\n\u003cli\u003eZugriffsberechtigungen, verbotene Tätigkeiten und Bedingungen für menschliche Genehmigungen\u003c/li\u003e\n\u003cli\u003eBekannte Einschränkungen, Verfahren zur Störungsbehebung und zuständige Personen\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eIn 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 \u003ccode\u003edocs\u003c/code\u003e-Verzeichnis, abgelegt werden, während das Issue auf diese Dokumente verweist.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#beispiel-f%C3%BCr-eine-aufgabenspezifikation\" class=\"anchor\" id=\"beispiel-für-eine-aufgabenspezifikation\"\u003e\u003c/a\u003eBeispiel für eine Aufgabenspezifikation\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e# Ziel\n\u003c/span\u003e\u003cspan\u003eDie Meldung bei fehlgeschlagener Anmeldung so verbessern, dass Nutzer erkennen können, wie sie das Problem beheben können.\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Umfang\n\u003c/span\u003e\u003cspan\u003e- Web-Anmeldebildschirm\n\u003c/span\u003e\u003cspan\u003e- Meldungen auf Koreanisch und Englisch\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Nicht im Umfang\n\u003c/span\u003e\u003cspan\u003e- Änderung der Authentifizierungsmethode\n\u003c/span\u003e\u003cspan\u003e- Änderung der Passwortrichtlinie\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Abnahmekriterien\n\u003c/span\u003e\u003cspan\u003e- Es wird nach außen nicht offengelegt, ob ein Konto existiert.\n\u003c/span\u003e\u003cspan\u003e- Die Barrierefreiheitsprüfung und die bestehenden Authentifizierungstests werden bestanden.\n\u003c/span\u003e\u003cspan\u003e- Bei einem Fehler kann zum ursprünglichen Verhalten zurückgekehrt werden.\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Prüfungsbefehle\n\u003c/span\u003e\u003cspan\u003e- npm test\n\u003c/span\u003e\u003cspan\u003e- npm run lint\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eGut 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.\u003c/p\u003e\n\u003cp\u003ePasswö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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#minimalstruktur-eines-ai-agent-harness\" class=\"anchor\" id=\"minimalstruktur-eines-ai-agent-harness\"\u003e\u003c/a\u003eMinimalstruktur eines AI-Agent-Harness\u003c/h2\u003e\n\u003cp\u003eHarness Engineering bezeichnet die Gestaltung der Ausführungsumgebung rund um ein Modell. Dazu gehören Systemanweisungen, Werkzeuganbindungen, Kontextsuche, Berechtigungen, Speicher, Tests, Beobachtbarkeit, Wiederholungsversuche und Abbruchbedingungen.\u003c/p\u003e\n\u003cp\u003eDie minimale Ausführungsschleife kann aus Plan, Draft und Review bestehen.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003ePhase\u003c/th\u003e\n\u003cth\u003eZentrale Frage\u003c/th\u003e\n\u003cth\u003eErgebnis\u003c/th\u003e\n\u003cth\u003eVorgehen bei Fehlern\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Phase\"\u003ePlan\u003c/td\u003e\n\u003ctd data-label=\"Zentrale Frage\"\u003eIst diese Aufgabe erforderlich, und wie sehen Umfang und Risiko aus?\u003c/td\u003e\n\u003ctd data-label=\"Ergebnis\"\u003ePlan, Änderungsziele, Prüfverfahren\u003c/td\u003e\n\u003ctd data-label=\"Vorgehen bei Fehlern\"\u003eErgänzende Informationen anfordern oder Aufgabe abbrechen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Phase\"\u003eDraft\u003c/td\u003e\n\u003ctd data-label=\"Zentrale Frage\"\u003eWurde der Plan in der kleinstmöglichen sicheren Einheit umgesetzt?\u003c/td\u003e\n\u003ctd data-label=\"Ergebnis\"\u003eCode, Tests, Dokumentänderungen\u003c/td\u003e\n\u003ctd data-label=\"Vorgehen bei Fehlern\"\u003eÜberarbeitung mit begrenzter Anzahl an Versuchen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Phase\"\u003eReview\u003c/td\u003e\n\u003ctd data-label=\"Zentrale Frage\"\u003eWerden Anforderungen und Qualitätskriterien erfüllt?\u003c/td\u003e\n\u003ctd data-label=\"Ergebnis\"\u003eBewertungsergebnis, Fehlerliste, Genehmigungsvorschlag\u003c/td\u003e\n\u003ctd data-label=\"Vorgehen bei Fehlern\"\u003eNacharbeit oder Übergabe an einen Menschen\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eEin tatsächlicher Harness benötigt folgende Kontrollmechanismen.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eZulässige Dateien, Befehle sowie Netzwerk- und Datenbereiche\u003c/li\u003e\n\u003cli\u003eMaximale Ausführungszeit, Anzahl der Werkzeugaufrufe und Kostenlimit\u003c/li\u003e\n\u003cli\u003eAbbruchbedingungen bei fehlgeschlagenen Tests oder hoher Unsicherheit\u003c/li\u003e\n\u003cli\u003eProtokolle sämtlicher Eingaben, Werkzeugaufrufe, Änderungen und Genehmigungen\u003c/li\u003e\n\u003cli\u003eMenschliche Genehmigungsstufe vor der Übernahme in die Produktion\u003c/li\u003e\n\u003cli\u003eRollback-Verfahren zur Wiederherstellung des ursprünglichen Zustands\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#einzelagent-und-multi-agenten-system\" class=\"anchor\" id=\"einzelagent-und-multi-agenten-system\"\u003e\u003c/a\u003eEinzelagent und Multi-Agenten-System\u003c/h3\u003e\n\u003cp\u003ePlan, 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.\u003c/p\u003e\n\u003cp\u003eIn einer Multi-Agenten-Struktur können die Rollen wie folgt getrennt werden.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003ePlanner:\u003c/strong\u003e Analysiert Anforderungen und prüft Notwendigkeit, Umfang und Risiko der Funktion.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eGenerator:\u003c/strong\u003e Erstellt gemäß dem Plan Code, Tests und Dokumentation.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eEvaluator:\u003c/strong\u003e Prüft das Ergebnis anhand unabhängiger Kriterien und zeigt Mängel sowie Verbesserungsmöglichkeiten auf.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eDie 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#einf%C3%BChrungsverfahren-f%C3%BCr-teams-und-unternehmen\" class=\"anchor\" id=\"einführungsverfahren-für-teams-und-unternehmen\"\u003e\u003c/a\u003eEinführungsverfahren für Teams und Unternehmen\u003c/h2\u003e\n\u003cp\u003eAllein 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#phase-1-ausgangsbasis-und-richtlinien-festlegen\" class=\"anchor\" id=\"phase-1-ausgangsbasis-und-richtlinien-festlegen\"\u003e\u003c/a\u003ePhase 1: Ausgangsbasis und Richtlinien festlegen\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eAktuelle Bearbeitungszeit, Fehlerquote, Wartezeit bei Reviews und Bereitstellungshäufigkeit messen.\u003c/li\u003e\n\u003cli\u003eFestlegen, welche Daten nicht eingegeben und welche Werkzeuge verwendet werden dürfen.\u003c/li\u003e\n\u003cli\u003eZwischen automatisch ausführbaren Aufgaben und Aufgaben mit erforderlicher menschlicher Genehmigung unterscheiden.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#phase-2-champion-und-begrenztes-pilotprojekt\" class=\"anchor\" id=\"phase-2-champion-und-begrenztes-pilotprojekt\"\u003e\u003c/a\u003ePhase 2: Champion und begrenztes Pilotprojekt\u003c/h3\u003e\n\u003cp\u003eIm 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.\u003c/p\u003e\n\u003cp\u003eEs ist sicherer, das Pilotprojekt mit Aufgaben zu beginnen, deren Ergebnisse leicht überprüfbar sind, etwa Testerstellung, Strukturierung interner Dokumentation oder Refactoring mit geringem Risiko.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#phase-3-standardisierung-erfolgreicher-muster\" class=\"anchor\" id=\"phase-3-standardisierung-erfolgreicher-muster\"\u003e\u003c/a\u003ePhase 3: Standardisierung erfolgreicher Muster\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eEingabedokumente und Bewertungskriterien vorrangig dokumentieren, nicht die wirksamen Prompts.\u003c/li\u003e\n\u003cli\u003eGemeinsame Issue-Vorlagen und eine Definition der Fertigstellung erstellen.\u003c/li\u003e\n\u003cli\u003eTests, Linting, Sicherheitsprüfungen und Review-Verfahren automatisieren.\u003c/li\u003e\n\u003cli\u003eFehlerursachen und Eingriffspunkte für Menschen dokumentieren.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#phase-4-betrieb-und-ausweitung\" class=\"anchor\" id=\"phase-4-betrieb-und-ausweitung\"\u003e\u003c/a\u003ePhase 4: Betrieb und Ausweitung\u003c/h3\u003e\n\u003cp\u003eWenn 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#kennzahlen-zur-leistungsmessung\" class=\"anchor\" id=\"kennzahlen-zur-leistungsmessung\"\u003e\u003c/a\u003eKennzahlen zur Leistungsmessung\u003c/h2\u003e\n\u003cp\u003eDie 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eBereich\u003c/th\u003e\n\u003cth\u003eEmpfohlene Kennzahl\u003c/th\u003e\n\u003cth\u003eBei der Interpretation zu beachten\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Bereich\"\u003eGeschwindigkeit\u003c/td\u003e\n\u003ctd data-label=\"Empfohlene Kennzahl\"\u003eZeit vom Beginn einer Aufgabe bis zur Bereitstellung\u003c/td\u003e\n\u003ctd data-label=\"Bei der Interpretation zu beachten\"\u003eAuch Zeit für Prüfung und Nacharbeit einbeziehen.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Bereich\"\u003eQualität\u003c/td\u003e\n\u003ctd data-label=\"Empfohlene Kennzahl\"\u003eFehlerquote nach der Bereitstellung, Testfehlerquote\u003c/td\u003e\n\u003ctd data-label=\"Bei der Interpretation zu beachten\"\u003eEinfache und schwierige Aufgaben getrennt betrachten.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Bereich\"\u003eEffizienz\u003c/td\u003e\n\u003ctd data-label=\"Empfohlene Kennzahl\"\u003eModellkosten pro Aufgabe, Anzahl der Werkzeugaufrufe\u003c/td\u003e\n\u003ctd data-label=\"Bei der Interpretation zu beachten\"\u003eKosten der menschlichen Prüfung nicht ausklammern.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Bereich\"\u003eStabilität\u003c/td\u003e\n\u003ctd data-label=\"Empfohlene Kennzahl\"\u003eRollback-Quote, Sicherheitswarnungen, Berechtigungsverstöße\u003c/td\u003e\n\u003ctd data-label=\"Bei der Interpretation zu beachten\"\u003eAuch die Möglichkeit unentdeckter Probleme berücksichtigen.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Bereich\"\u003eAkzeptanz\u003c/td\u003e\n\u003ctd data-label=\"Empfohlene Kennzahl\"\u003eAnteil der Teams mit wiederholter Nutzung, abgeschlossene reale Aufgaben\u003c/td\u003e\n\u003ctd data-label=\"Bei der Interpretation zu beachten\"\u003eVon bloßen Anmeldungen oder Aufrufzahlen unterscheiden.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Bereich\"\u003eErfahrung\u003c/td\u003e\n\u003ctd data-label=\"Empfohlene Kennzahl\"\u003eEntwicklerzufriedenheit, kognitive Belastung, Review-Müdigkeit\u003c/td\u003e\n\u003ctd data-label=\"Bei der Interpretation zu beachten\"\u003eAuch bei höherer Geschwindigkeit kann die Ermüdung zunehmen.\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eDie 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#sicherheits--und-qualit%C3%A4tsrisiken\" class=\"anchor\" id=\"sicherheits--und-qualitätsrisiken\"\u003e\u003c/a\u003eSicherheits- und Qualitätsrisiken\u003c/h2\u003e\n\u003cp\u003eDa 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.\u003c/p\u003e\n\u003cp\u003eZu den wichtigsten Risiken gehören:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ePrompt-Injection, bei der versteckte Anweisungen in Repository-Dokumenten oder externen Seiten befolgt werden\u003c/li\u003e\n\u003cli\u003eVergabe übermäßig weitreichender Datei-, Datenbank- oder Bereitstellungsberechtigungen\u003c/li\u003e\n\u003cli\u003eFehlerhafter Code, der nicht existierende APIs oder Pakete verwendet\u003c/li\u003e\n\u003cli\u003eEinführung anfälliger Abhängigkeiten oder von Code mit unklarer Lizenz\u003c/li\u003e\n\u003cli\u003eAbschwächung der Prüfkriterien selbst, um Tests zu bestehen\u003c/li\u003e\n\u003cli\u003eExterne Übertragung von Kundendaten, geheimen Schlüsseln und internem Code\u003c/li\u003e\n\u003cli\u003eUnerwartete Kostensteigerungen durch wiederholte Ausführung\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eDie 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%C3%BCberreaktionen-auf-werkzeuge-vermeiden\" class=\"anchor\" id=\"überreaktionen-auf-werkzeuge-vermeiden\"\u003e\u003c/a\u003eÜberreaktionen auf Werkzeuge vermeiden\u003c/h2\u003e\n\u003cp\u003eStä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.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eIst die wiederkehrende Aufgabe, die aktuell gelöst werden soll, klar definiert?\u003c/li\u003e\n\u003cli\u003eLässt sich das Werkzeug sicher mit der bestehenden Entwicklungsumgebung und dem Berechtigungssystem verbinden?\u003c/li\u003e\n\u003cli\u003eKann die Qualität der Ausgabe automatisch oder manuell überprüft werden?\u003c/li\u003e\n\u003cli\u003eLassen sich Kosten, Latenzzeit und Fehlerquote beobachten?\u003c/li\u003e\n\u003cli\u003eBleiben Spezifikationen, Tests und Dokumentation auch bei einem Wechsel des Werkzeugs erhalten?\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eMit 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#praxis-checkliste-f%C3%BCr-ai-native-entwickler\" class=\"anchor\" id=\"praxis-checkliste-für-ai-native-entwickler\"\u003e\u003c/a\u003ePraxis-Checkliste für AI-native Entwickler\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e Ziele, Nicht-Ziele und Abnahmekriterien vor der Implementierung dokumentieren.\u003c/li\u003e\n\u003cli\u003e Werkzeuge und Zugriffsbereiche der AI auf das Minimum beschränken.\u003c/li\u003e\n\u003cli\u003e Große Aufgaben in unabhängig überprüfbare Einheiten aufteilen.\u003c/li\u003e\n\u003cli\u003e Zusammen mit dem Code auch Tests, Dokumentation und ein Rollback-Verfahren anfordern.\u003c/li\u003e\n\u003cli\u003e Bei wichtigen Änderungen diff und Ausführungsergebnisse durch einen Menschen prüfen lassen.\u003c/li\u003e\n\u003cli\u003e Fehler, Wiederholungsversuche, Kosten und menschliche Eingriffe protokollieren.\u003c/li\u003e\n\u003cli\u003e Messen, ob die Automatisierung Qualität und Abschlusszeit tatsächlich verbessert hat.\u003c/li\u003e\n\u003cli\u003e Dem Agenten ermöglichen, Aufgaben mit geringem Wert oder hohem Risiko abzulehnen oder weiterzugeben.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#fazit\" class=\"anchor\" id=\"fazit\"\u003e\u003c/a\u003eFazit\u003c/h2\u003e\n\u003cp\u003eDie Wettbewerbsfähigkeit eines AI-nativen Entwicklers entsteht nicht durch einen bestimmten Prompt oder den Namen eines Werkzeugs. Sie beruht auf der \u003cstrong\u003eFä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\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eAI 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.\u003c/p\u003e\n","tags":["Harness Engineering","KI-Agent","AI Native","Softwareentwicklung","Dokumentation"],"faqs":[{"question":"Ist ein AI-nativer Entwickler dasselbe wie ein Prompt Engineer?","answer":"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."},{"question":"Programmiert ein AI-nativer Entwickler nicht selbst?","answer":"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."},{"question":"Kann man einem AI-Agenten alle Entscheidungen überlassen?","answer":"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."},{"question":"Sind für Plan, Draft und Review zwingend drei Agenten erforderlich?","answer":"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."},{"question":"Senken Markdown-Dokumente immer die Token-Kosten?","answer":"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."},{"question":"Wo sollte man mit der AI-nativen Transformation beginnen?","answer":"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."},{"question":"Hat AI die Programmierfähigkeiten vollständig angeglichen?","answer":"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."},{"question":"Muss man mehrere AI-Entwicklungswerkzeuge erlernen, um wettbewerbsfähig zu werden?","answer":"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."},{"question":"Wie misst man die Leistung eines AI-nativen Entwicklungsteams?","answer":"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":[{"url":"https://www.anthropic.com/research/building-effective-agents","title":"Anthropic: Effektive Agenten entwickeln","type":"source"},{"url":"https://docs.github.com/en/issues/tracking-your-work-with-issues/about-issues","title":"GitHub Docs: Informationen zu Issues","type":"source"},{"url":"https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/about-writing-and-formatting-on-github","title":"GitHub Docs: Informationen zum Schreiben und Formatieren auf GitHub","type":"source"},{"url":"https://www.nist.gov/itl/ai-risk-management-framework","title":"NIST-Risikomanagement-Framework für KI","type":"source"},{"url":"https://genai.owasp.org/llm-top-10/","title":"OWASP Top 10 für Anwendungen mit großen Sprachmodellen","type":"source"}],"images":[{"id":461,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NTQ1NiwicHVyIjoiYmxvYl9pZCJ9fQ==--dcc52a99856a48635d1882fba812226f930329f5/ai-4dab44ed.webp","is_representative":true,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"개발자가 여러 대시보드에서 AI 에이전트의 설계, 코딩, 검증, 배포 흐름을 관리하는 다이어그램","caption":"AI 네이티브 개발자가 연결된 에이전트와 도구를 운영하는 전체 개발 구조를 보여준다.","description":null},"en":{"alt":"Developer managing AI agent design, coding, testing, security, and deployment across connected dashboards","caption":"The diagram shows an AI-native developer orchestrating connected agents and tools throughout development.","description":null},"ja":{"alt":"開発者が複数の画面でAIエージェントの設計、実装、検証、展開を管理する図","caption":"AIネイティブ開発者が連携するエージェントとツールを運用する開発構造を示している。","description":null},"es":{"alt":"Desarrollador gestionando diseño, código, pruebas, seguridad y despliegue de agentes de IA en paneles conectados","caption":"El diagrama muestra a un desarrollador nativo de IA coordinando agentes y herramientas durante el desarrollo.","description":null},"id":{"alt":"Pengembang mengelola desain, kode, pengujian, keamanan, dan penerapan agen AI lewat dasbor terhubung","caption":"Diagram ini menunjukkan pengembang native AI yang mengorkestrasi agen dan alat dalam proses pengembangan.","description":null},"pt":{"alt":"Desenvolvedor gerenciando design, código, testes, segurança e implantação de agentes de IA em painéis conectados","caption":"O diagrama mostra um desenvolvedor nativo de IA orquestrando agentes e ferramentas ao longo do desenvolvimento.","description":null},"zh-hant":{"alt":"開發者透過多個互連儀表板管理 AI 代理的設計、編碼、測試、安全與部署","caption":"此圖呈現 AI 原生開發者在開發流程中協調代理與工具的整體架構。","description":null},"de":{"alt":"Entwickler steuert Entwurf, Code, Tests, Sicherheit und Bereitstellung von KI-Agenten über vernetzte Dashboards","caption":"Das Diagramm zeigt, wie ein KI-nativer Entwickler vernetzte Agenten und Werkzeuge im Entwicklungsprozess koordiniert.","description":null}}},{"id":462,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NTQ2MiwicHVyIjoiYmxvYl9pZCJ9fQ==--9fdf22aa2cbd420f209ff5c18baea59124f816b9/ai-f15eba1a.webp","is_representative":false,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"보안 장벽 안에서 여러 AI 에이전트가 개발 모듈을 연결하고 검증하는 워크플로 다이어그램","caption":"AI 에이전트들이 코딩, 도구, 설정, 배포 단계를 협업하며 보안과 성능 지표로 검증받는 구조를 보여준다.","description":null},"en":{"alt":"Workflow diagram of AI agents connecting and validating development modules inside a secure boundary","caption":"AI agents collaborate across coding, tooling, configuration, and deployment stages with security and performance checks.","description":null},"ja":{"alt":"安全な領域内で複数のAIエージェントが開発モジュールを連携・検証するワークフロー図","caption":"AIエージェントがコーディング、ツール、設定、デプロイを分担し、セキュリティと性能を確認する構造を示している。","description":null},"es":{"alt":"Diagrama de agentes de IA que conectan y validan módulos de desarrollo en un entorno seguro","caption":"Los agentes de IA colaboran en las fases de código, herramientas, configuración y despliegue con controles de seguridad y rendimiento.","description":null},"id":{"alt":"Diagram alur agen AI yang menghubungkan dan memvalidasi modul pengembangan dalam batas aman","caption":"Agen AI berkolaborasi pada tahap pengodean, alat, konfigurasi, dan penerapan dengan pemeriksaan keamanan serta kinerja.","description":null},"pt":{"alt":"Diagrama de agentes de IA conectando e validando módulos de desenvolvimento em um ambiente seguro","caption":"Agentes de IA colaboram nas etapas de código, ferramentas, configuração e implantação com verificações de segurança e desempenho.","description":null},"zh-hant":{"alt":"多個 AI 代理在安全邊界內連接並驗證開發模組的工作流程圖","caption":"AI 代理協作完成編碼、工具、設定與部署階段，並接受安全和效能檢查。","description":null},"de":{"alt":"Workflow-Diagramm von KI-Agenten, die Entwicklungsmodule in einer sicheren Umgebung verbinden und prüfen","caption":"KI-Agenten arbeiten bei Code, Werkzeugen, Konfiguration und Bereitstellung zusammen und durchlaufen Sicherheits- und Leistungsprüfungen.","description":null}}}],"published_at":"2026-08-04T10:59:54+09:00","updated_at":"2026-08-04T10:59:54+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant","de"],"url":"https://injoys.com/en/articles/ai-native-developer-definition-and-practices"}