Artikel
Die Obergrenze beim Einsatz von KI ist Ihr Ehrgeiz: Tempo, Höhe, Tiefe, Breite
Felix Rieseberg, Engineering-Leiter bei Anthropic, zerlegt „mehr Ehrgeiz im Umgang mit KI“ in vier Dimensionen: Tempo, Höhe, Tiefe und Breite. Dieser Beitrag fasst seine Vorgehensweise und Beispiele zusammen und ergänzt meine Praxisnotizen: zielorientierte Anweisungen geben und ein Expertenteam aus Multi-AI Agents für eine Kreuzprüfung aus mehreren Blickwinkeln einsetzen, um die Qualität der Ergebnisse zu steigern.
· 6 Min. Lesezeit
Felix Rieseberg, Engineering-Leiter bei Anthropic, schreibt in „How to be more ambitious: A tutorial for humans with models“, dass er und sein Umfeld oft dieselbe Reaktion haben, wenn sie sehen, wie jemand mit KI verblüffende Ergebnisse erzielt: „Wir sind nicht ehrgeizig genug.“
Meine Deutung: Die Obergrenze, bis zu der Menschen KI nutzen, liegt oft im eigenen Ehrgeiz und in der eigenen Vorstellungskraft – nicht im Modell.
Er zerlegt „Ehrgeiz“ in vier Dimensionen:
- Tempo (Speed): dieselbe Arbeit in kürzerer Zeit erledigen.
- Höhe (Altitude): die Abstraktionsebene anheben und auf das Endergebnis schauen statt auf eine einzelne Aufgabe.
- Tiefe (Depth): nach den Standards, mit den Werkzeugen und Methoden der besten Fachleute des Gebiets arbeiten.
- Breite (Range): über ein einzelnes Fachgebiet hinausgehen und disziplinübergreifend nach Lösungen suchen.
Das Fazit vorweg: Wer präzise, zielorientierte Anweisungen gibt und ein Expertenteam aus Multi-AI Agents für Zusammenarbeit und Kreuzprüfung aus mehreren Blickwinkeln einsetzt, hebt die Qualität der Ergebnisse insgesamt an.
I. Tempo: die einfachste Dimension, an der die wenigsten scheitern#
Dieselbe Arbeit in kürzerer Zeit erledigen. Felix hält das für allgemein vertraut, sein Artikel überspringt den Punkt deshalb direkt.
Meine Einschätzung: Tempo ist der naheliegendste Nutzen von KI, aber wer nur auf Tempo aus ist, ändert an der Art der Zusammenarbeit nicht viel. Den eigentlichen Unterschied machen die übrigen drei Dimensionen.
II. Höhe: nach dem „Ziel hinter dem Ziel“ fragen#
Die Kernfrage: Welches Ergebnis will ich als Nächstes wirklich? Was ist das Ziel hinter meinem Ziel?
Felix' Beispiele:
- Vom Beheben eines Crashs zu einer App, die nicht mehr abstürzt. Anfangs bat er Claude, einen einzelnen Crash zu beheben, später forderte er stattdessen, dass die App crashfrei bleibt. Damit das dauerhaft und automatisch läuft, musste er zuerst seinen eigenen Ablauf umbauen: Crash-Berichte leicht zugänglich machen, App-Versionen den Git-Commits zuordnen und Claude Windows-, macOS- und Linux-Rechner nutzen lassen, um Korrekturen zu reproduzieren und zu verifizieren.
- Eine Steigerung in drei Stufen für den Quarterly Business Review (QBR):
- Möglichst von Rohdaten ausgehen und erklären, was sich in diesem Quartal verändert hat, warum und was als Nächstes zu tun ist.
- Die 3 dringendsten Entscheidungen herausarbeiten und für jede Argumente dafür und dagegen formulieren.
- Einen Ersatzmechanismus entwerfen, der Probleme früher erkennt als die Quartalspräsentation, ihn mit historischen Daten testen und dann ein Quartal lang parallel zum bisherigen Verfahren laufen lassen.
Er weist auch auf eine Grenze hin: Im Jahr 2026 funktioniert ein vages Ziel wie „Claude, verdien Geld für mich“ noch nicht, doch er erwartet, dass die Abstraktionsebene, die Modelle bewältigen, weiter steigt.
III. Tiefe: sich an den Anforderungen der besten Fachleute messen#
Felix' Vorgehen:
- Die Werkzeuge nutzen, die diese Branche tatsächlich einsetzt. Modelle ändern oft nur die Wortwahl, nicht die Methode, und liefern zum Abfertigen eine Markdown-Tabelle. Bestehen Sie auf echten Analysewerkzeugen wie Datenbanken und statistischen Modellen.
- Ein scheinbar unvernünftiges Ziel setzen und dem Modell sagen, dass es lösbar ist. Sein Beispiel: Nachdem die Ladezeit einer Website von 10 auf 5 Sekunden gesenkt war, verlangte er 200 Millisekunden. Wenn das Modell zurückweicht, daran festhalten, dass das Ziel erreichbar ist.
- Annahmen infrage stellen, an die Sie glauben. Geben Sie dem Modell die Rohdaten und lassen Sie es aus kontradiktorischer Sicht prüfen. Zum Beispiel: „Wir glauben, dass die Abwanderung am Onboarding liegt; versuche, diese Schlussfolgerung aus den Rohdaten zu reproduzieren.“
- Neues Wissen erzeugen. Aus Logs eine Simulation aufbauen, das früheste Abwanderungssignal finden, das Sie noch nicht kannten, und es dann an ungesehenen Daten validieren.
- Einen externen Richter (Outside Judge) hinzuziehen. Lassen Sie das Modell sich nicht selbst bewerten. Am besten binden Sie ein Werkzeug an, das das Modell direkt ausführen kann und das sofort Rückmeldung zur Überprüfung gibt.
Seine Prompt-Regel: Sie wollen eine „tiefere Version“, keine „größere Version“. Bitten Sie das Modell zu sagen, was Spitzenfachleute zusätzlich tun würden, wo die rohesten Daten liegen, welche Methoden und Werkzeuge zu verwenden sind und was – abgesehen vom Modell oder Ihrem eigenen Urteil – belegen kann, dass das Ergebnis stimmt.
IV. Breite: Verben statt Substantive, und ein Expertenteam zusammenstellen#
- Verben statt Substantive. Dieses Konzept übernimmt Felix aus „The Art of Innovation“. Statt „einer Präsentation“ ist der QBR dann „in 30 Minuten vielbeschäftigten Menschen Ursache und Wirkung verständlich machen, damit sie unter Unsicherheit entscheiden können“. Wer das Ziel mit einem Verb definiert, erkennt, welche Fähigkeiten aus welchen Fachgebieten gebraucht werden.
- Ein Team zusammenstellen. Für eine gute Präsentation braucht es Analysten, Journalisten und Redakteure; für den Auftritt auf der Bühne kommen Motion- und Sounddesigner hinzu. Für die kontradiktorische Prüfung holt man Researcher eines Leerverkäufer-Fonds (Short Seller) und forensische Buchprüfer.
- Kein sinnloses Rollenspiel. Das Modell soll nicht „im Ton eines Leerverkäufer-Fonds“ schreiben, sondern tatsächlich eine Methode aus der Recherche eines solchen Fonds ausführen. Nur den Ton zu ändern, macht das Ergebnis nicht besser.
Voraussetzung ist, dass das Modell einen Computer hat, auf dem es Software installieren kann, und dass es etwa über MCP-Konnektoren Zugriff auf die relevanten Daten bekommt.
V. Meine Praxisnotizen: vom „Datentransfer“ zur „Zielerreichung“#
Das Folgende ist meine Weiterführung aus Softwarearchitektur und Engineering-Praxis, nicht der Inhalt des Originalartikels.
1. Jobs to be Done und Intent-Based#
- Fragen Sie nicht „Was tun?“, sondern „Was erreichen?“. Ein Entwurf sollte nicht bei einer passiven Datentransfer-Pipeline wie
generate_deck_pdf() stehen bleiben, sondern sich zur Absicht eines Zustandsübergangs wie resolve_leadership_uncertainty_and_commit_budget() erheben.
- Eine echte Verlustfunktion definieren. Wer nur ein Ergebnisdokument verlangt, bekommt vom Modell scheinbar perfekte Leerformeln; wer verlangt, die Unsicherheit der Entscheidung aufzulösen, bei dem schließen Modell und Sub-agent von sich aus logische Lücken und Risikogrenzen.
2. Beim Erkunden divergieren, beim Abnehmen konvergieren#
- Beim Erkunden zuerst divergieren, um Möglichkeiten zu finden, dann konvergieren.
- Beim Abnehmen nicht mehr divergieren. Vermeiden Sie grenzenlose Fragen wie „Wie ließe sich das noch machen?“, die nur Allgemeinplätze hervorbringen.
- Schreiben Sie Zielumfang, Randbedingungen und objektive Prüfwerkzeuge ausdrücklich auf (ein bestimmtes Testskript, Schwellenwerte für Geschäftskennzahlen), damit das Multi-Agent-Team in einem fokussierten Rahmen Belastungstests durchführt und ein hochwertiges Ergebnis liefert.
Zusammenfassung meiner Notizen#
- Zielorientierung: Verben statt Substantive. Ein Ergebnis liefern, das das Problem löst, und nicht bloß ein Arbeitsprodukt, um die Aufgabe abzuhaken.
- Erkunden und Konvergieren: Beim Erkunden divergieren, um Möglichkeiten zu finden; bei der Abnahme strikt konvergieren und die Grenzen prüfen.
- Abstraktion fokussieren: Von der Kernfrage ausgehen und den gesamten Aufgabenablauf neu aufbauen.
- Experten-Tiefe: Nicht nur den Ton von Experten nachahmen, sondern das Modell zwingen, das Problem mit den Werkzeugen und Methoden der Besten zu lösen.
Originalartikel: How to be more ambitious: A tutorial for humans with models (Felix Rieseberg, 2026-10-13)