Building AI builders: Playbook zum Schließen der Wissens-Kompetenz-Lücke bei KI

Die größte Hürde bei der KI-Adoption ist nicht mangelndes Bewusstsein. Es ist die Lücke zwischen dem Reden über KI und dem Bauen mit ihr.

Profis, deren Hauptaufgabe nicht das Schreiben von Code ist, deren tägliche Arbeit aber zunehmend von KI-Lösungen abhängt, brauchen keinen technischen Hintergrund, um mit dem Aufbau von KI-Kompetenz zu beginnen. Sie brauchen die richtigen Werkzeuge, strukturierte Unterstützung und die Erlaubnis zu scheitern. So haben wir es bewiesen – und so können Sie es nachbilden.

Das Problem, das Organisationen ignorieren

Ihre Teams führen bereits KI-Gespräche – ob sie Kundenfragen beantworten, Anbieterlösungen bewerten oder Automatisierungspotenziale in ihrem Tagesgeschäft identifizieren. Angesichts des Tempos, mit dem agentische KI-Tools allgemein verfügbar geworden sind, haben die meisten von ihnen noch nie etwas mit den Tools gebaut, über die sie sprechen.

Diese Teams – ob in Vertrieb, Betrieb, Finanzen oder Produkt – haben die Demos gesehen und die Zertifizierungen abgeschlossen. Aber wenn jemand fragt: „Wie funktioniert das eigentlich?“, haben sie nicht die Antwort, die daraus entsteht, selbst damit gebaut zu haben.

Die Kosten sind real: langsamere Adoption, verzögerte Produktivitätsgewinne, verpasste Chancen bei der Identifizierung von Use Cases und eine wachsende Diskrepanz zwischen dem, was Ihre Teams wissen über und was sie umsetzen können.

Wir haben berufliche Profis gefragt – Menschen, die täglich mit KI-Tools arbeiten, aber keinen Produktionscode schreiben –, was sie bei der KI-Adoption zurückhielt. Die Antwort war nicht „Ich will nicht lernen.“ 90 Prozent wollten praktische Erfahrung beim Bau von KI-Agenten sammeln. Ihnen fehlten das Bindegewebe und das Gerüst, um sicher zu bauen. Die folgende Abbildung veranschaulicht die häufigsten Hindernisse, mit denen Business-Teams beim Bauen mit KI konfrontiert sind.

Abbildung 1: Die häufigsten von Business-Teams genannten Hindernisse beim Bauen mit KI

Auf hoher Ebene konnten sie über Amazon Bedrock und Amazon Bedrock AgentCoresprechen, eine Plattform zum Erstellen, Verbinden und Optimieren von Agenten im großen Maßstab mit beliebigem Framework oder Modell (80 Prozent hatten es erkundet). Aber weniger als 1 von 5 hatte Strands Agents SDK ausprobiert oder AWS Lambda Agenten gebaut. Sie verzichteten auf Hackathons und Build-Events, weil sie nicht glaubten, dass ihr technisches Wissen ausreichte, um neben Ingenieuren zu bestehen.

Um das zu lösen, entwarfen wir ein sechswöchiges strukturiertes Programm, das berufliche Profis mit Mentoren und produktionsreifen Tools zusammenbringt, um funktionierende KI-Prototypen zu bauen, die über das Programm hinaus skalieren können. Das Ziel: die Lücke zwischen konzeptionellem Wissen und praktischer Kompetenz schließen.

Was ein Team gebaut hat: Der Beweis in sechs Wochen

Vier kundennahe Profis, die noch nie zusammengearbeitet hatten, nahmen an unserem Programm teil. Keiner hatte einen technischen Hintergrund. Sechs Wochen später präsentierten sie ihren Prototyp, WealthWise, ein Multi-Agenten-KI-Tool für Finanzberatung, das den ersten Platz gewann.

Was sie gebaut haben:

• Fünf spezialisierte KI-Agenten liefern intelligente Finanzberatung: Portfolioanalyse, Risikobewertung, Finanzplanung, Markteinblicke und personalisierte Anlageempfehlungen.
• Dual-Server-Architektur (Node.js + Python Flask) mit Amazon Nova-Modellen.*
• Strands Agents SDK für Multi-Agenten-Orchestrierung und Konversationsspeicher.
• Vier Amazon DynamoDB-Tabellen für die Echtzeit-Datenpersistenz.
• Live-Marktdaten-Integration für kontextbewusste Finanzempfehlungen.
• Antwortzeiten von unter 5 Sekunden für komplexe finanzielle Schlussfolgerungen.

Das System verfügt über koordinierte Entscheidungsfindung: Jeder Agent entscheidet unabhängig, welche Tools er aufruft, und verkettet mehrere Tools miteinander, indem er mehrstufige Schlussfolgerungen über Portfoliodaten, Marktdatenbanken und Finanzplanungsmodelle zieht.

Sie führten ihren Erfolg auf fünf Grundsätze zurück, die sie am ersten Tag festlegten:

1. Lernen statt Gewinnen – Die Wahl anspruchsvoller Ansätze gegenüber sicheren Abkürzungen befreite sie, ohne Angst zu experimentieren.
2. Regelmäßige Taktungen – Tägliche Standups verhinderten Isolation und erkannten Probleme früh.
3. Mit einem Minimum Viable Product (MVP) beginnen, dann verfeinern – Am Tag 2 ein funktionsfähiger End-to-End-Ablauf, danach Iteration.
4. An Sprechstunden teilnehmen – Aktiv Mentoring suchen, wenn man feststeckt.
5. Spaß haben – Psychologische Sicherheit vor technischem Output.

Die Teilnehmenden reflektierten, wie das praxisorientierte Format ihr Lernen beschleunigte:

„Das Timing des Hackathons war perfekt, und das praxisorientierte Format erwies sich als unschätzbar wertvoll für die AgentCore-Ermächtigung – es beschleunigte, was eine lange Lernkurve hätte sein können.“

„Tolles Teambuilding- und KI-Lernprojekt! Ich habe mir selbst vieles beigebracht und habe jetzt zusätzliche Empathie für Kundinnen und Kunden, die neu im Umgang mit KI-Lösungen sind.“

* Die Amazon-Nova-Modelle sind auf Amazon Bedrock in ausgewählten AWS-Regionen verfügbar. Informationen zur aktuellen Verfügbarkeit finden Sie auf der AWS-Seite zu regionalen Diensten.

Das Playbook: Wie wir das Programm gestaltet haben

Die folgenden Abschnitte erläutern die Programmstruktur, jede Phase und die Designentscheidungen, die das Programm erfolgreich machten.

Programmstruktur

Das Programm läuft über sechs Wochen, wobei die Teilnehmenden etwa vier Stunden pro Woche aufwenden. Wir haben es bewusst so strukturiert: Basierend auf unseren Programmdaten behielten Teilnehmende, die ein phasenweise aufgebautes Programm abschlossen, drei Mal mehr praktische Fähigkeiten als Teilnehmende in intensiven Zwei-Tage-Formaten. Berufstätige, die in ihren Hauptjobs keinen Code schreiben, brauchen Iterationszyklen: Zeit, um mit unbekannten Konzepten zu ringen, sich zu erholen und wieder aufzubauen, bevor Selbstvertrauchen Bestand hat.

Phase 0: Rekrutierung und Programmierung

Wir rekrutierten Teilnehmende über Manager-Nominierungen, Slack- und E-Mail-Kampagnen und richteten uns an Fachleute, die täglich mit KI-Lösungen arbeiten, diese aber nicht selbst entwickeln: Account Manager, Solutions Consultants, Operations Analysten, Programmmanager und ähnliche Rollen. Die Zustimmung des Managements kam zuerst. Wir informierten Teamleiter über den Zeitaufwand (vier Stunden pro Woche über sechs Wochen) und stellten es als Investition in Sprach- und Gesprächsqualität dar, nicht als Ablenkung von der täglichen Arbeit.

Das Programm wurde von vier Kernteammitgliedern plus Mentoren organisiert, die es neben ihrer täglichen Arbeit durchführten. Das ist ein entscheidender Punkt für die Reproduzierbarkeit: Es erfordert kein dediziertes Programmt Team, aber mindestens eine Person mit genügend organisatorischem Vertrauen, um die Zeit der Teilnehmenden zu schützen.

Phase 1: Teambildung und Auftakt

Was die Teilnehmenden tun: Teams aus 3–4 Personen mit bewusst gemischten Erfahrungsstufen bilden. Die Teams definieren eine Problemstellung, die an ein reales Szenario aus ihrer Rolle geknüpft ist.

Was dabei entsteht: Ein abgegrenztes Projekt­konzept, das demo­striert werden kann, und eine Teamverantwortlichkeitsstruktur.

Warum das wichtig ist, bevor es weitergeht: Ohne ein konkretes Problem, das es zu lösen gilt, werden Schulungen abstrakt. Teams, die zuerst ihren Zielanwendungsfall definieren, nehmen technische Inhalte zielgerichtet auf.

Phase 2: Befähigung

Was die Teilnehmenden tun: An Live-Trainingssitzungen zu agentischen KI-Konzepten und AWS-Tools teilnehmen. Dies sind keine Vorlesungen. Die Teilnehmenden arbeiten innerhalb der tatsächlichen Tools, die sie in der Bauphase verwenden werden, und absolvieren strukturierte Übungen, die ihre Projektarbeit widerspiegeln.

Was dabei entsteht: Grundlegende technische Kompetenz und eine funktionierende lokale Umgebung.

Warum das wichtig ist, bevor es weitergeht: Teams, die direkt mit dem Bauen beginnen, stoßen bei der Einrichtung der Umgebung und bei grundlegenden Konzepten an eine Wand. Diese Phase vermeidet den häufigsten Ausstiegspunkt.

Phase 3: Ideation, Bauen und Entwicklung

Was die Teilnehmenden tun: Funktionierende Prototypen über mehrere Wochen entwerfen und iterieren. Jedes Team erhält einen technisch versierten Mentor, der ein Sicherheitsnetz bietet, Infrastrukturprobleme löst und Architekturmuster vorschlägt, ohne die Arbeit für sie zu erledigen.

Was dabei entsteht: Ein funktionsfähiger Prototyp, der einem Stakeholder oder Kunden demonstriert werden könnte.

Warum das wichtig ist, bevor es weitergeht: Der verlängerte Zeitrahmen ermöglicht 2–3 Iterationszyklen. Teams, die in Woche 3 einen Prototypen gebaut hatten, hatten Zeit, ihr neues Wissen kontinuierlich anzuwenden, den Prototyp abzubauen und in Woche 5 besser neu aufzubauen. In dieser Iteration findet das echte Lernen statt.

Phase 4: Bewertung und Demos

Was die Teilnehmenden tun: Live-Demonstrationen liefern, die in fünf Kategorien bewertet werden: Business Impact, Technical Excellence, Reusability and Scalability, Innovation und Presentation Quality.

Was dabei entsteht: Peer-validierter Nachweis der Fähigkeiten und eine Bibliothek wiederverwendbarer Prototypen.

Warum das wichtig ist: Das Demo-Format spiegelt wider, was die Teilnehmenden in echten Gesprächen mit Kunden, Führungskräften und funktionsübergreifenden Partnern tun werden. Die Bewertungskriterien stellen sicher, dass funktionierend nicht ausreicht. Es muss wirkungsvoll, skalierbar und klar kommuniziert sein.

Kritische Designentscheidungen

Die Auswahl der Werkzeuge ist die wichtigste Entscheidung für Entwickler, die keine Ingenieure sind. Die falschen Werkzeuge erzeugen Reibung, die den Schwung zum Erliegen bringt. Die richtigen abstrahieren von der Infrastruktur und holen die Menschen auf ihrem aktuellen Niveau ab. Wir wählten:

• Kiro Eine integrierte Entwicklungsumgebung (IDE) für Natural-Language-Entwicklung: Man beschreibt, was man möchte, und sie erstellt das Architekturgerüst.
• Amazon Bedrock für API-zugängliche Foundation Models, die in dieser Region verfügbar sind: Es ist keine Machine-Learning-Expertise (ML) erforderlich, um eine funktionierende Antwort von einem Modell zu erhalten.
• Das Strands Agents SDK für komponierbare Agent-Muster: Agents lassen sich wie Bausteine kombinieren.
• AWS Model Context Protocol (MCP) Server und AWS Lambda Agents, um Teams in Richtung deploybarer, produktionsreifer Architekturen zu bringen – nicht nur lokale Notebooks.

Der Kerngrundsatz hat sich nie geändert: etwas Echtes bauen, das man auch kurzfristig demonstrieren könnte.

Umgang mit Störungen des Tagesgeschäfts

Wir haben das wöchentliche Zeitpensum bewusst auf vier Stunden begrenzt und den Teilnehmenden Flexibilität bei der zeitlichen Einteilung dieser Stunden eingeräumt. Das häufigste Feedback war, dass die Teilnehmenden das Gelernte innerhalb der ersten zwei Wochen direkt in ihre Arbeit einfließen ließen, wodurch sich der Zeitaufwand ergänzend anstatt konkurrierend anfühlte.

Die Ergebnisse

Die folgende Abbildung vergleicht die Selbsteinschätzungen der Teilnehmenden vor und nach dem Programm anhand von acht zentralen Kennzahlen, darunter AI-Kompetenz, Tool-Adoption und Bereitschaft, das Gelernte mit Kundinnen und Kunden anzuwenden.

Abbildung 2: Selbsteinschätzungen der Teilnehmenden vor und nach dem Programm

Zu Beginn nannten die Teilnehmenden „fehlende Beispiele aus der Praxis“ als größte Hürde beim Bauen mit AI. Am Ende stuften 23 Prozentpunkte (pp) mehr Teilnehmende ihre Zuversicht, AI auf praktische Anwendungsfälle anzuwenden, höher als zu Beginn erwartet. Die Teilnehmenden verließen das Programm mit einem funktionierenden Prototyp, einem Code-Repository und einer Referenzarchitektur, die sie sofort den Stakeholdern vorführen konnten.

Was sie gebaut haben und zu Kundinnen und Kunden bringen:

• Multi-Agenten-Pflegekoordination für Healthcare Independent Software Vendors (ISVs).
• Content-Modellierungs- und Triage-Systeme.
• Betrugsidentifikation und -prävention.
• Vorhersage und Vermeidung von Kundenabwanderung (Churn).
• Multi-Agenten-Orchestrierung für autonome Entscheidungsfindung.
• Kiro + Amazon Bedrock AgentCore-Demos für Kundinnen- und Kunden-Workshops.

Die Wirkung: Von Beobachterinnen und Beobachtern zu Builderinnen und Buildern

Als unsere Teilnehmenden praktischen Zugang zu AI-Tools erhielten, gingen sie vom Diskutieren von Möglichkeiten zum Bauen funktionierender Prototypen über. Die Zahlen erzählen die Geschichte:

• Selbsteingeschätztes Verständnis von agentic AI auf dem Niveau „Stark oder Experte“: gestiegen von 27 Prozent auf 82 Prozent (+55 pp).
• Gefühl, „gut oder äußerst vorbereitet“ zu sein, AI-Möglichkeiten zu erkennen: gestiegen von 41 Prozent auf 85 Prozent (+44 pp).
• Teilnehmende mit ausschließlich theoretischer oder begrenzter Erfahrung: gesunken von 34 Prozent auf 0 Prozent (beseitigt).

Das lässt sich durch diese Investition erreichen:

Für Ihre Teams: Sie hören auf, AI-Beobachter zu sein, und werden zu AI-Buildern. Sie wissen durch direktes Ausprobieren, was machbar ist, was teuer ist und was ein Wochenendprojekt ist. In unserem Kohortenprogramm identifizierten 52 Prozent konkrete Kundinnen und Kunden, die von dem, was sie gebaut hatten, profitieren könnten während des Programms, und 87 Prozent erwarteten, ihr Gelerntes innerhalb von 30 Tagen mit Kundinnen und Kunden anzuwenden. Das Programm hat bei den praktischen Anwendungsfällen mehr geliefert als versprochen, weil es die Teilnehmenden verpflichtete, die Beispiele selbst zu erstellen.

Für Ihre Engineering-Organisationen: Wenn geschäftliche Gegenüber prototypisieren und Architektur-Tradeoffs artikulieren können, verbringen Engineering-Teams weniger Zeit mit der Übersetzung von Anforderungen und mehr Zeit mit dem Bauen. Technische Builder erhalten klarere Anforderungen, weniger nicht abgestimmte Anfragen und Partner, die die Machbarkeit belastbarkeitstesten können, bevor auch nur ein einziger Sprint festgelegt wird. Bedenken Sie: 82 Prozent der Teilnehmenden verließen das Programm mit einem starken Verständnis der agentic-AI-Architektur. Die Tool-Kompetenz stieg über den gesamten Stack: Strands Agents SDK ging von 20 Prozent auf 80 Prozent Adoption (+60 pp) und AgentCore von 39 Prozent auf 85 Prozent, was die Messlatte für das technische Urteilsvermögen anhob.

Für Ihre Kundinnen und Kunden: Sie erhalten Partner, die dieselben Architektur-Tradeoffs, vor denen sie stehen, durch direkte praktische Erfahrung bereits durchlaufen haben. Gespräche gehen von „Ich melde mich bei Ihnen“ zu Live-Demonstrationen über. Vor dem Programm nannten 44 Prozent der Teilnehmenden Unsicherheit über Architekturmuster als Hürde. Nach dem Programm fühlten sich 90 Prozent gut oder besser vorbereitet, AI-Möglichkeiten in echten Kundengesprächen zu erkennen.

Für Ihre Organisation: Sie erhalten ein replizierbares Modell, das sich verstärkt. Die Ausweitung unseres Pilotprogramms von einem Team auf regionale und nun globale Einführung zeigt das Muster: praktische Kompetenz skaliert sich selbst. Das Programm erreichte eine Empfehlungsquote von 100 Prozent, wobei 95 Prozent der Teilnehmenden angaben, dass das Programm die Erwartungen erfüllt oder übertroffen habe.

Sieben Lektionen zur Replizierung in Ihrer Organisation

Diese sieben Lektionen erfassen, was das Programm erfolgreich machte und was Sie in Ihrer eigenen Organisation replizieren sollten.

1. Die Tool-Auswahl verändert alles

Low-Code- und agentische Erlebnisse beseitigen die Hürde „Ich bin nicht technisch genug“. Dies ist eine Designentscheidung des Programms, kein nachträglicher Beschaffungsgedanke. Wenn Ihre Tools Python-Kenntnisse erfordern, haben Sie vor der ersten Woche die Hälfte des Raums verloren.

2. Struktur schlägt Intensität

Ein phasenweise aufgebautes Programm (6 Wochen) mit klaren Meilensteinen übertrifft einen zweitägigen Sprint für nicht-technisches Publikum. Rechnen Sie damit, dass sich die erste Woche langsam anfühlt. Der Compoundierungseffekt kommt danach.

3. Mentoring ist der Multiplikator

Die Paarung nicht-technischer Teilnehmender mit technisch versierten Mentoren nimmt die Angst vor dem Scheitern und beschleunigt das Lernen. Der Mentor baut nicht für sie. Er bietet ein Sicherheitsnetz.

4. Etwas Reales bauen

Die Anforderung funktionierender Prototypen mit Code-Repositories und Referenzarchitekturen (keine Folien) erzwingt eine tiefe Auseinandersetzung mit den Werkzeugen. Bei einer Live-Demo kann man sich nicht durchschummeln. Genau das unterscheidet einen Hackathon von einem Schulungskurs.

5. Vorher und nachher messen

Kompetenzbewertungen vor und nach dem Event machen die Wirkung sichtbar und untermauern das Geschäftsszenario für eine Ausweitung. Selbst eingeschätztes Selbstvertrauen ist nützlich, aber der Wechsel von „begrenzter“ zu „umfassender“ Praxiserfahrung ist es, was zählt.

6. Mache es reproduzierbar

Ein gut dokumentiertes Playbook (Teilnehmerrichtlinien, Bewertungskriterien, Mentoring-Pairing-Frameworks, Anleitungen zur Einrichtung der Umgebung) macht aus einer einmaligen Veranstaltung ein skalierbares Programm.

7. Schaffe zuerst psychologische Sicherheit

Wenn Menschen keine Angst vorm Scheitern haben, bauen sie Dinge, die sie nie für möglich hielten. Das Gewinnerteam nannte „Lernen statt Gewinnen“ als ihr oberstes Prinzip. Jedes Team, das erfolgreich war, etablierte Vertrauen, bevor es Code schrieb.

Leg los

Das Playbook, die Bewertungskriterien und die Anleitungen zur Einrichtung der Umgebung stehen Teams zur Verfügung, die dieses Modell nachahmen möchten. Wende dich an eine der Autoren, um mehr darüber zu erfahren, wie du dieses Framework in deine Organisation bringen kannst.

Erfahre mehr über Amazon Bedrock | Kiro IDE | Strands Agents SDK

Über die Autoren