Agent Skills

 (addyosmani.com)
1 Punkte von GN⁺ 1 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Agent Skills ist ein Scaffolding, das KI-Coding-Agenten per Workflow dazu zwingt, Senior-Engineering-Prozesse wie Spezifikationen, Tests, reviewbare PRs und Prüfungen von Trust Boundaries nicht zu überspringen
  • Ein Skill ist eine Markdown-Datei mit Frontmatter und eher ein Workflow als ein Referenzdokument: mit Schrittfolge, Checkpoint-Nachweisen und klaren Abschlusskriterien
  • Die 20 Skills des Repositories bestehen aus 6 Lebenszyklusphasen — Define, Plan, Build, Verify, Review, Ship — sowie 7 Slash-Commands: /spec, /plan, /build, /test, /review, /ship, /code-simplify
  • Zentrale Prinzipien sind Prozess statt Prosa, Anti-Rationalisierungs-Tabellen, Verifikation als Abschlusskriterium, progressive Offenlegung und Scope-Disziplin; using-agent-skills aktiviert nur die für die Aufgabe passenden Skills
  • Verwendbar über die Claude-Code-Marketplace-Installation, Cursor .cursor/rules/, Gemini CLI, Codex, Aider, Windsurf, OpenCode und ähnliche Tools, die Markdown einlesen; veröffentlicht unter der MIT-Lizenz

Ziel und Problemverständnis

  • Agent Skills ist ein Scaffolding, das KI-Coding-Agenten per Workflow dazu zwingt, Senior-Engineering-Prozesse durchzuführen, die sie standardmäßig überspringen
  • Wenn KI-Coding-Agenten um eine Funktion gebeten werden, implementieren sie diese meist auf dem kürzesten Weg und führen Prozesse wie Spezifikationsschreibung, test-first Vorgehen, Prüfungen von Trust Boundaries oder den Aufbau reviewbarer PRs nicht von selbst aus
  • In der Arbeit von Senior Engineers steckt viel, was im Diff nicht sichtbar ist
    • Annahmen offenlegen
    • Spezifikationen schreiben
    • Arbeit in reviewbare Einheiten aufteilen
    • langweilige, aber sichere Designentscheidungen treffen
    • Nachweise hinterlassen, dass das Ergebnis korrekt ist
    • Änderungen auf eine Größe begrenzen, die Menschen tatsächlich reviewen können
  • Dass Agenten diese Schritte überspringen, hat einen ähnlichen Grund wie bei Junior Engineers: Das Belohnungssignal ist auf „Aufgabe erledigt“ ausgerichtet, nicht auf „Aufgabe erledigt, inklusive Spezifikationsdokument“
  • Das Agent-Skills-Repository hat mehr als 26K Stars und behandelt über das README hinaus auch die Gründe für Designentscheidungen, die Zuordnung zu standardmäßigen SDLC-Prozessen und öffentlich bekannten Engineering-Praktiken von Google sowie Muster, die sich auch ohne Installation übernehmen lassen

Was ein Skill tatsächlich bedeutet

  • Ein Skill ist eine Markdown-Datei mit Frontmatter, die je nach Situation in den Agenten-Kontext injiziert wird, und liegt irgendwo zwischen einem System-Prompt-Baustein und einem Runbook
  • Ein Skill ist kein Referenzdokument und auch keine Wissenssammlung im Stil von „alles, was man über Tests wissen muss“
  • Nützliche Skills sind Workflows, denen der Agent folgt
    • Es gibt eine Reihenfolge von Schritten
    • An Checkpoints werden Nachweise erzeugt
    • Sie enden mit klaren Abschlusskriterien
  • Wenn man einen 2.000-Wörter-Essay über Best Practices beim Testen in den Kontext legt, kann der Agent plausible Sätze erzeugen und die eigentlichen Tests trotzdem überspringen
  • Gibt man stattdessen einen Workflow vor, bei dem zuerst ein fehlschlagender Test geschrieben, dann dessen Fehlschlag ausgeführt und bestätigt, anschließend nur die minimale Implementierung zum Bestehen geschrieben, das Bestehen geprüft und danach refaktoriert wird, dann hat der Agent konkrete Aufgaben und Menschen können das Ergebnis verifizieren
  • Der zentrale Unterschied ist Prozess statt Prosa, Workflow statt Referenz und Schritte mit Abschlusskriterien statt Essays ohne Abschlusskriterien
  • Viele „AI rules“-Repositories sind genau deshalb in der Praxis wenig wirksam, weil ihre Regeln Essays bleiben statt Workflows zu sein

SDLC- und Slash-Command-Struktur

  • Die 20 Skills des Repositories sind in 6 Lebenszyklusphasen organisiert, darüber liegen 7 Slash-Commands

  • Phasen und Commands

    • /spec: die Define-Phase, in der entschieden wird, was gebaut werden soll
    • /plan: die Plan-Phase zur Zerlegung der Arbeit
    • /build: die Build-Phase zur Umsetzung in vertikalen Slices
    • /test: die Verify-Phase zum Nachweis des Verhaltens
    • /review: die Review-Phase, in der durchgerutschte Probleme gefunden werden
    • /ship: die Ship-Phase zur sicheren Auslieferung an Nutzer
    • /code-simplify: ein Simplify-Command, der quer über den gesamten Ablauf hinweg gilt
    • Diese Struktur entspricht dem SDLC-Fluss funktionierender Engineering-Organisationen; je nach Organisation unterscheidet sich nur das Vokabular
    • Bei Google erscheint das als design doc → review → implementation → readability review → launch checklist, bei Amazon etwa als working-backwards memo und bar raiser
    • Das neue Problem bei KI-Coding-Agenten ist, dass die meisten Agenten die meisten dieser Phasen standardmäßig überspringen
    • Fordert man eine Funktion an, bekommt man nur die Implementierung; Spezifikation, Planung, Tests, Review und Release-Checklisten bleiben aus
    • Skills zwingen Agenten durch dieselben Schritte, die Senior Engineers sich selbst auferlegen; Code ohne diese Prozesse zu deployen führt zu Ausfällen
    • Bei komplexen Funktionen können 11 Skills nacheinander aktiviert werden, bei kleinen Bugfixes vielleicht nur 3
    • Der Router using-agent-skills entscheidet, welche Skills auf die aktuelle Aufgabe anwendbar sind, und der Workflow skaliert passend zum tatsächlichen statt zu einem angenommenen Umfang

Prinzipien, die das System tragen

  • 1. Prozess statt Prosa

    • Workflows kann ein Agent in Handlungen umsetzen, Essays nicht
    • Dasselbe Prinzip gilt auch für menschliche Teams
    • Wenn ein Team-Handbuch 200 Seiten lang ist, liest es unter Druck niemand; ein kleiner Workflow mit Checkpoints wird deutlich eher tatsächlich ausgeführt

  • 2. Anti-Rationalisierungs-Tabellen

    • Die ungewöhnlichste und für andere Teams am ehesten übernehmbare Designentscheidung in Agent Skills sind Anti-Rationalisierungs-Tabellen
    • Jeder Skill enthält typische Ausreden, mit denen ein Agent oder ein erschöpfter Engineer versuchen könnte, den Workflow zu überspringen, plus bereits formulierte Gegenargumente
    • Beispiele:
      • „Diese Aufgabe ist zu simpel, dafür braucht es keine Spezifikation“ → Akzeptanzkriterien gelten trotzdem. 5 Zeilen sind okay, 0 Zeilen nicht
      • „Die Tests schreibe ich später“ → Genau das ist das Problem an „später“. Es gibt kein später. Zuerst muss ein fehlschlagender Test geschrieben werden
      • „Die Tests laufen grün, also deployen wir“ → Bestandene Tests sind Evidenz, aber kein Beweis. Es muss geprüft werden, ob die Runtime überprüft wurde, ob sichtbares Nutzerverhalten validiert wurde und ob ein Mensch den Diff gelesen hat
    • LLMs sind gut im Rationalisieren und können plausible Absätze dazu erzeugen, warum eine bestimmte Aufgabe keine Spezifikation brauche oder eine Änderung auch ohne Review gemerged werden könne
    • Anti-Rationalisierungs-Tabellen sind vorab geschriebene Widerlegungen gegen Lügen, die der Agent noch gar nicht ausgesprochen hat
    • Dieses Muster funktioniert auch in menschlichen Teams
    • Qualitätseinbußen im Engineering entstehen meist nicht, weil jemand bewusst schlechte Arbeit machen will, sondern weil plausible Rechtfertigungen akzeptiert werden, um lästige Prozesse zu überspringen

  • 3. Verifikation ist nicht verhandelbar

    • Jeder Skill endet mit konkreten Nachweisen
    • Bestandene Tests, saubere Build-Ausgaben, Runtime-Traces, die das erwartete Verhalten zeigen, oder Freigaben von Reviewern dienen als Abschlusskriterien
    • „Sieht plausibel aus“ reicht nicht
    • Das ist dasselbe Prinzip, durch das der Harness von Anthropic aus Fehlern wieder herauskommt, die planner/worker/judge-Trennung in Cursor tatsächlich Bugs findet und long-running agent wiederherstellbar wird
    • Ein Agent ist ein Generator und braucht daher ein separates Signal dafür, wann eine Aufgabe wirklich abgeschlossen ist; Skills bauen dieses Signal in jeden Workflow ein

  • 4. Progressive Offenlegung

    • Zu Beginn einer Session werden nicht alle 20 Skills in den Kontext geladen
    • Aktiviert werden nur die Skills, die für die aktuelle Phase benötigt werden
    • Ein kleiner Meta-Skill namens using-agent-skills fungiert als Router und entscheidet, welche Skills zur aktuellen Aufgabe passen
    • Das überträgt die Lehren aus harness engineering auf die Ebene einzelner Skills
    • Jedes Token, das in den Kontext geladen wird, verschlechtert irgendwo die Leistung; deshalb sollte nur Relevantes geladen und der Rest auf der Platte belassen werden
    • Progressive Offenlegung ist die Methode, eine Bibliothek aus 20 Skills in einen 5K-Token-Slot zu bekommen, ohne den gesamten Kontext zu verschmutzen

  • 5. Scope-Disziplin

    • Der Meta-Skill kodiert das nicht verhandelbare Prinzip „Fasse nur an, worum gebeten wurde“
    • Benachbarte Systeme sollen nicht refaktoriert, nicht vollständig verstandener Code nicht entfernt und ein TODO nicht zum Anlass genommen werden, eine ganze Datei neu zu schreiben
    • Ein Agent kann beim Beheben eines einzelnen Bugs versuchen, gleich drei nicht betroffene Dateien zu modernisieren
    • Scope-Disziplin ist der wichtigste Faktor dafür, ob ein PR mergebar ist oder zurückgerollt werden muss
    • Das passt auch gut zu Googles Code-Review-Normen, bei denen Reviewer blockieren können, wenn ein PR mehr als eine Sache zugleich erledigt

Verbindung zu Googles Engineering-Praktiken

  • In Agent Skills steckt viel aus Software Engineering at Google und aus Googles öffentlich zugänglicher Engineering-Kultur
  • Viele der Dinge, die Software in Googles Größenordnung funktionsfähig machen, sind öffentlich dokumentiert — und genau diese Teile überspringen Agenten besonders oft

  • Zuordnung von Skills und Praktiken

    • api-and-interface-design: spiegelt Hyrum’s Law wider. Jedes beobachtbare Verhalten einer API wird irgendwann von irgendwem genutzt und muss deshalb beim Design berücksichtigt werden
    • test-driven-development: spiegelt die Testpyramide ~80/15/5 und die Beyoncé Rule wider. Das Prinzip lautet sinngemäß: „Wenn es dir wichtig war, hättest du einen Test daran gehängt“; Bugs werden von Tests gefunden, nicht von Infrastrukturänderungen
    • DAMP over DRY bei Tests: Googles Testphilosophie sieht vor, dass Testcode wie eine Spezifikation lesbar sein sollte, auch wenn dafür etwas Duplikation in Kauf genommen wird. Übermäßig abstrahierte Tests sind ein bekanntes Anti-Pattern
    • code-review-and-quality: spiegelt die Größe von ~100-line PRs und die Schweregrad-Labels Critical / Nit / Optional / FYI wider. Große PRs werden in der Praxis selten wirklich reviewt und eher abgenickt
    • code-simplification: spiegelt Chesterton’s Fence wider. Man sollte nichts entfernen, bevor man verstanden hat, warum es überhaupt dort steht
    • git-workflow-and-versioning: spiegelt trunk-based development und atomare Commits wider
    • ci-cd-and-automation: spiegelt Shift Left und Feature Flags wider. Probleme sollten so früh wie möglich gefunden sowie Deployment und Release voneinander getrennt werden
    • deprecation-and-migration: spiegelt code-as-liability wider. Jede Zeile, die man behält, muss dauerhaft gepflegt werden, daher ist eine kleinere Oberfläche vorzuziehen
    • Diese Konzepte sind nicht neu, aber in Agenten nicht standardmäßig eingebaut
    • Selbst wenn ein Frontier-Modell die Formulierung „Hyrum’s Law“ aus Trainingsdaten kennt, wendet es das nicht automatisch an, wenn es nachts um drei eine API entwirft
    • Skills sorgen dafür, dass solche Praktiken vom Agenten während der eigentlichen Arbeit angewendet werden

Praktische Nutzung

  • Variante 1: Installation über den Marketplace

    • Wer Claude Code verwendet, installiert mit den folgenden Commands
    /plugin marketplace add addyosmani/agent-skills
/plugin install agent-skills@addy-agent-skills
    • Danach stehen die Slash-Commands /spec, /plan, /build, /test, /review, /ship, /code-simplify zur Verfügung
    • Der Agent aktiviert kontextabhängig automatisch die relevanten Skills
    • Für die meisten Nutzer ist das der empfohlene Einstieg

  • Variante 2: Markdown in ein beliebiges Tool einlegen

    • Skills sind normale Markdown-Dateien mit Frontmatter
    • Cursor-Nutzer können sie in .cursor/rules/ ablegen
    • Gemini CLI hat einen eigenen Installationspfad
    • Auch Codex, Aider, Windsurf, OpenCode und andere Tools, die System-Prompt-Inhalte annehmen können, können sie lesen
    • Entscheidend ist weniger das Tool selbst als der Workflow darunter

  • Variante 3: Wie eine Spezifikation lesen

    • Auch ohne Installation sind Skills eine dokumentierte Beschreibung dafür, wie man mit KI-Agenten gute Engineering-Arbeit leistet
    • Man kann code-review-and-quality.md lesen und das 5-Achsen-Framework auf den eigenen Team-Review-Prozess anwenden
    • Man kann test-driven-development.md lesen und es in Debatten wie „Sollten wir Tests zuerst schreiben?“ einsetzen
    • Man kann die Meta-Skills lesen und die 5 nicht verhandelbaren Prinzipien in das eigene AGENTS.md übernehmen
    • Ein möglicher Startpunkt ist, 4–5 Skills auszuwählen, die dem aktuell schmerzhaftesten Problem am nächsten liegen, dann den Workflow festzulegen, den man erzwingen will, und anschließend eine Runtime zu installieren oder selbst zu bauen, die ihn durchsetzt

Muster, die sich auch ohne Installation übernehmen lassen

  • Anti-Rationalisierung zur Team-Praxis machen

    • Teams sollten die Lügen aufschreiben, die sie sich selbst erzählen
    • Beispiele sind Sätze wie „Die Tests reparieren wir nach dem Release“, „Diese Änderung ist zu klein für ein Design-Dokument“ oder „Mit Monitoring passt das schon“
    • Wenn man jedem Satz eine Widerlegung zuordnet und das in AGENTS.md oder im Engineering-Wiki festhält, reduziert das Diskussionen und fängt müde Abkürzungen am Freitagnachmittag ab

  • Interne Dokumente als Prozess statt als Prosa schreiben

    • Wer ein 2.000-Wörter-Dokument mit dem Titel „Wie wir X angehen“ schreibt, erstellt Referenzmaterial
    • Wenn man das in einen Workflow mit Checkpoints umwandelt, schrumpft das Dokument vielleicht auf 400 Wörter und wird deutlich eher tatsächlich ausgeführt
    • Das Prinzip gilt für Onboarding-Guides, Runbooks und Agent-Skills gleichermaßen

  • Verifikation als hartes Abschlusskriterium setzen

    • Der letzte Schritt jeder Aufgabe sollte „Nachweise erzeugen“ sein
    • Das gilt für Agenten, Engineers und Einzelarbeit gleichermaßen
    • Als Nachweis reichen grüne Testläufe, Screenshots, Logs oder Review-Freigaben — also alles, was belegt, dass die Arbeit abgeschlossen ist
    • Ohne Nachweis ist die Arbeit nicht abgeschlossen, und „sieht plausibel aus“ schließt die Schleife nicht

  • Progressive Offenlegung auf jedes Regelwerk anwenden

    • Statt ein 50-seitiges Handbuch zu schreiben, sollte man einen kleinen Router bauen, der passende Mini-Kapitel je nach Situation ausliefert
    • Das gilt für AGENTS.md, Runbooks, Incident-Response-Playbooks und jedes Dokument, das unter Druck gelesen werden muss

  • Fünf nicht verhandelbare Prinzipien für AGENTS.md

    • Vor dem Bauen müssen Annahmen offengelegt werden. Stillschweigend beibehaltene falsche Annahmen sind eine der häufigsten Fehlerquellen
    • Wenn Anforderungen kollidieren, muss man anhalten und nachfragen. Man sollte nicht raten
    • Wenn nötig, muss man widersprechen. Weder Agenten noch Engineers sollten Ja-Sager sein
    • Langweilige und klare Lösungen sollten bevorzugt werden. Cleverness ist teuer
    • Es sollte nur angefasst werden, worum tatsächlich gebeten wurde

Einordnung innerhalb des Harness

  • Skills sind aus größerer Perspektive eine Schicht innerhalb von agent harness engineering
  • Ein Harness umfasst das Modell und alles, was darum herum gebaut wird; Skills sind wiederverwendbare Workflow-Bausteine, die schrittweise im System-Prompt offengelegt werden
  • Skills stehen neben AGENTS.md, Hooks, Tools und Session-Log
    • AGENTS.md: fungiert als fortlaufend gepflegtes Regelwerk
    • Hooks: deterministische Durchsetzungsschicht
    • Tools: Aktionen, die der Agent ausführen kann
    • Session-Log: persistentes Gedächtnis
    • Skills: zuständig für Senior-Engineering-Prozesse
  • Skills sind für long-running agents wichtiger als für chatartige Agenten
  • Lange Laufzeiten verstärken jede Abkürzung
    • In einer 10-Minuten-Session kann ein Agent, der Tests überspringt, einen einzelnen Bug erzeugen
    • In einer 30-Stunden-Session kann ein Agent, der Tests überspringt, am Ende eine Art Debugging-Archäologie hinterlassen, bei der niemand mehr die ursprüngliche Absicht kennt
  • Je länger die Laufzeit, desto mehr muss Senior-Engineering-Scaffolding erzwungen statt nur empfohlen werden
  • Auch die Portabilität des Skill-Formats ist wichtig
  • Dieselbe Datei SKILL.md kann in Claude Code, in Cursor mit Rules, in Gemini CLI, in Codex und in anderen Harnesses verwendet werden, die System-Prompt-Inhalte entgegennehmen können
  • Schreibt man den Workflow einmal, kann ihn die Runtime durchsetzen; genau darin liegt der Vorteil des Formats Markdown plus Frontmatter gegenüber maßgeschneiderter Prompt-Engineering-Arbeit

Fazit

  • KI-Coding-Agenten verhalten sich wie sehr kompetente Junior Engineers ohne Instinkt für jene Arbeit, die im Diff nicht sichtbar wird
  • Senior-Engineering-Aufgaben wie Annahmen offenzulegen, Änderungsgrößen zu begrenzen, Spezifikationen zu schreiben, Nachweise zu hinterlassen und nicht reviewbare Änderungen nicht zu mergen, werden von Agenten wahrscheinlich übersprungen, wenn man sie daran nicht aktiv hindert
  • Immer wichtiger wird es daher, diese Disziplinen in einer Form zu kodieren, aus der sich Agenten nicht einfach herausreden können
  • Skills sind eine solche Form; zentral sind dabei Anti-Rationalisierungs-Tabellen, progressive Offenlegung, Prozess statt Prosa, Verifikation als Abschlusskriterium und eine Struktur, die bereits funktionierende Google-Praktiken portierbar macht
  • Das Agent-Skills-Repository ist unter der MIT-Lizenz veröffentlicht; die breitere Scaffolding-Perspektive wird in Agent Harness Engineering und Long-running Agents weitergeführt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 시간 전
Hacker-News-Kommentare

  • Kommt einem betrügerischen Allheilmittel ziemlich nahe. Lesenswert und plausibel, aber am Ende trotzdem ein betrügerisches Allheilmittel
    Der Grund ist, dass ein spielautomatenartiges Modell jederzeit Pflichtanforderungen aus AGENTS.md, memory.md und Dutzenden Skill-Markdown-Dateien übersehen kann – und das ist praktisch vorprogrammiert
    Dieser Harness-Ansatz tut so, als würden LLMs Regeln streng und perfekt befolgen und als bestünde das Problem nur darin, dass wir nicht genug ausreichend klare Regeln aufgeschrieben haben. Das ist ein grundlegender Wahrnehmungsfehler darüber, wie LLMs funktionieren
    Am Ende bleibt die einzig verlässliche, wenn auch nur relativ verlässlichere Option menschliche Prüfung und Aufsicht, möglichst sogar zweimal hintereinander
    Alles andere ist ein betrügerisches Allheilmittel, und an diesem Punkt merkt man dann auch, dass die versprochenen Produktivitätsgewinne ebenso dazugehören. Denn Code zu lesen und sich ein mentales Modell aufzubauen ist viel schwieriger, als Code niederzuschreiben, wenn dieses mentale Modell bereits existiert

    • „Betrügerisches Allheilmittel“ ist etwas zu stark. Solche Mittel wirken nie, während Dinge mit LLMs trotz ihrer probabilistischen Natur doch mit ziemlich hoher Wahrscheinlichkeit funktionieren
      Code lesen hängt davon ab, um welchen Code es geht, aber wie bei anderen Fertigkeiten wird es durch Übung leichter. Das ist seit Langem üblich in Situationen, in denen man viel mehr Code liest als schreibt, etwa wenn man mit großen und komplexen Codebasen arbeiten muss, die schon lange existieren
      Noch leichter wird es, wenn man durch Dokumentation, frühere Erfahrung oder Gespräche mit Kollegen bereits ein mentales Modell des Codes hat
      Mit Agenten geht das auch. Normalerweise kennt man die Struktur des Codes schon gut, bevor man der AI einen Prompt gibt, und wenn man die Arbeit sorgfältig aufteilt, ist die Prüfung des generierten Codes sehr einfach. Es fühlt sich an, als würde man ein Buch noch einmal lesen, das man schon kennt, und wenn selten einmal etwas falsch ist, fällt es sofort auf, sodass man das meiste früh erkennt. So oder so ist der Geschwindigkeitsgewinn groß
    • Auch Menschen übersehen oft vorgegebene Pflichtanforderungen, und auch dort ist Review nötig. Trotzdem haben wir die Verlässlichkeit menschlicher Ergebnisse durch Prozesse und Reviews erhöht, und vieles von dem, was in Harnesses verwendet wird, stammt aus Erfahrungen damit, Probleme zu verringern, die entstehen, wenn Menschen sich nicht zuverlässig instruieren lassen
    • Alles, was du sagst, ist möglich, und theoretisch stimme ich zu
      Aber ich habe in den letzten Monaten spec-kit, also diese Art der AI-Nutzung, ausprobiert, und in der Praxis war es erstaunlich gut. Ich baue großartige Dinge damit, und die Probleme, die du hypothetisch ansprichst, sind bei mir noch nicht aufgetreten. Irgendwann können sie auftreten, und deshalb bin ich vorsichtig
      Trotzdem kann ich es, nachdem ich es eine Weile selbst genutzt habe, nicht einfach als betrügerisches Allheilmittel abtun. Ich arbeite seit über 30 Jahren als Programmierer und glaube, recht gut einschätzen zu können, was tatsächlich funktioniert und was nicht
    • Das ist ungefähr so, als würde man sagen, ein Schwert mit +5 sei nutzlos, weil man bei einer 1 trotzdem danebenhaut. Man muss auf den Erwartungswert schauen. Wenn jemand fünf brauchbare PRs merged und drei verwirft, ist es kein sinnvoller Vergleich, sich lautstark darüber zu beklagen, dass eine davon mies war
    • Ich hoffe, die Leute nennen diese Markdown-Vorschläge nur deshalb einen Workflow, weil sie Angst haben, dass alles veraltet ist, bevor sie einen strukturierteren Ansatz fertig ausgearbeitet haben. Ich glaube nicht, dass das Innovationstempo bei Basismodellen ewig so bleibt
      Ich möchte künftig Harnesses sehen, die nicht nur bitten, sondern verlangen. Wenn man einem Agenten sagt, er solle im Planungsmodus sein, und er befolgt das festgelegte Planungsverfahren nicht, wird er beendet. Auch wenn das nicht perfekt ist, sollte es besser sein als der aktuelle Mensch-in-der-Schleife-Ansatz

  • Es heißt, „Skills sind Markdown-Dateien mit Frontmatter, die in den Agentenkontext injiziert werden, wenn sie relevant sind“, aber ob sie relevant sind, entscheidet das LLM
    Es heißt auch, es sei „eine Reihe von Schritten, denen der Agent folgt und die mit Checkpoints enden, die Belege erzeugen, sowie mit klaren Abschlusskriterien“ – aber ob diese Schritte befolgt werden, kann ebenfalls das LLM entscheiden

    • Skills werden oft vom Benutzer imperativ aufgerufen. Wenn sie direkt vom LLM verwendet werden sollen, kann man sie einfach irgendwo in den Kontext schreiben. Zum Beispiel: 
      After implementing the feature, read the testing skill for instructions on how to test.
    • Fairerweise kann man in Umgebungen wie Codex Skills auch direkt mit $my-skill aufrufen, und dann wird dieser Skill tatsächlich in den Kontext injiziert. Danach befolgt das LLM ihn eben so sehr, wie es Prompts, Anweisungen und andere Teile des Kontexts generell befolgt

  • Ich freue mich auf den Tag, an dem alle feststellen, dass sie über ein Jahr lang an Agenten herumgebastelt haben und dabei nur ein Gefühl von Scheinsproduktivität erlebt haben

    • Eine gewisse Skepsis kann ich verstehen, und man kann auch aus verschiedenen Gründen grundsätzlich glauben, dass AI schlecht ist. Aber diese apodiktischen Aussagen verstehe ich immer weniger. Ich frage mich, wie man sich so sicher sein kann, dass AI-Entwicklung derart gescheitert ist
      Das passt überhaupt nicht zu meiner praktischen Erfahrung. Mich würde interessieren, welche Erfahrungen dich zu so großer Sicherheit über den unvermeidlichen Niedergang von AI-Coding gebracht haben. Ist das eine philosophische Überzeugung, dass AI moralisch schlecht ist, oder hast du tatsächlich Dinge mit AI gebaut, gründlich damit experimentiert und bist dann zu diesem starken Urteil gekommen?
      Ich schreibe seit über 30 Jahren täglich Code und mache das seit über 20 Jahren beruflich. Ich habe Trends kommen und gehen sehen und auch mehrfach echte Fortschritte erlebt, die die Arbeitsweise verändert haben. Je mehr Projekte ich mit AI umsetze, desto stärker bin ich überzeugt, dass dies eine dauerhafte und grundlegende Veränderung darin ist, wie wir Software bauen und Computer nutzen
      Ich sehe, wie AI besser wird, und auch, wie ich selbst immer geschickter darin werde, echte Arbeit damit zu erledigen. Diese Arbeit wurde bereits unter echter Produktionslast getestet. Man kann nicht mögen, was gerade passiert, und auch nicht mögen, wie es sich anfühlt, mit AI zu arbeiten – aber das bedeutet nicht, dass es den Menschen keinen realen Wert liefert und keine reale Arbeit erledigt
    • Diese Sichtweise interessiert mich. In gutem Glauben gefragt: Steckt dahinter die Annahme, dass Leute, die AI/Agenten/Harnesses nutzen, keine Features ausliefern?
      Wir sind etwa seit September vollständig auf Claude Code umgestiegen und konnten die Verbesserungen erfolgreich nachverfolgen. Wir liefern Features aus, die in echter Produktion genutzt werden. Das gilt für Infrastruktur ebenso wie für die Umsetzung von Business-Logik sowie für Frontend und Backend
      Ich sehe nicht, dass die Leute dabei so viel Zeit verschwenden. Ich stimme aber zu, dass die meisten Texte dazu Unsinn sind – dieser hier eingeschlossen. Trotzdem findet AI-Entwicklung bereits in vielen Unternehmen weltweit statt
    • Das klingt ein bisschen so, als hätten Menschen Produktivität verloren, weil sie aufgehört haben, Papierbücher zu führen, und stattdessen an sogenannten Datenbanken herumgebastelt haben
    • Ich arbeite an Projekten, bei denen der Output gemessen wird, und daran ist überhaupt nichts „fake“
    • Ich behandle es wie Minecraft-Automatisierung. Einfach etwas für Spaß und Zeitvertreib
      Ich glaube nicht, dass agentische Workflows dafür schon weit genug sind, aber Skill-Implementierungen für den manuellen Aufruf, wenn man parallel mit AI arbeitet, sind definitiv brauchbar. Unsere Firma konzentriert sich im Moment stark auf Sandboxing und sichere Skills
      Für Feature-Entwicklung taugt es meiner Meinung nach noch nicht richtig, aber die Review-Skills und Grafana-Skills, die wir geschrieben haben, waren ziemlich solide

  • Ich habe früher größere Sammlungen von Agent-Skills verwendet, aber sie wollten zu viel auf einmal tun und fühlten sich wie Zeitverschwendung an. Ähnlich wie bei Vim ist es oft besser, Skills aus der Community gezielt auszuwählen, statt ein ganzes Skill-Paket wie eine IDE komplett zu installieren
    Skills unterscheiden sich von Entwickler zu Entwickler und von Team zu Team so stark, dass sie zu persönlich sind. Statt massenhaft fremde Setups zu installieren, sollte man sie besser als Referenzmaterial behandeln, um das eigene Setup zu bauen

    • Dasselbe gilt für MCP und Systemanweisungen. Viele installieren einfach alles, ohne es zu verstehen, verwässern ihren Kontext mit unnötigen Tools und verschwenden mehr als 50.000 Tokens, um sich danach zu beschweren, dass sie zu schnell ans Limit kommen und über 100 Dollar im Monat zahlen müssen

  • Aus Sicht von Suchoptimierung oder LLM-Optimierung dürfte die Auffindbarkeit solcher Skills schwierig sein, wenn man den Namen nicht ändert: https://agentskills.io/
    Falls Addy das sieht, würde mich interessieren, wie er das im Vergleich zu Superpowers erklären würde: https://github.com/obra/superpowers

    • Ich würde gern wissen, wie viele Leute superpowers tatsächlich verwenden
      Ich bin schon seit vor superpowers in der Agentenentwicklung unterwegs und habe Sorge, dass inzwischen mehr als 50 % meines selbst entwickelten Prozesses durch superpowers abgedeckt werden
      Ich vertraue GitHub-Sternen nicht mehr. Ich wünschte, jemand würde es mir sagen. Wird superpowers inzwischen wirklich angenommen? Und wenn es wirklich so wertvoll ist, warum hat Boris das Konzept dann noch nicht integriert?
    • Das ist so, als würde man ein React-Framework ReactJS nennen, um mit NextJS zu konkurrieren
    • Es wirkt wie ein vorgefertigtes Skill-Paket, das als Plugin angeboten wird
    • Funktioniert superpowers tatsächlich? Die Haupt-Skill-Datei schafft bei mir nicht gerade Vertrauen:
      „Wenn du glaubst, dass auch nur eine Wahrscheinlichkeit von 1 % besteht, dass ein Skill auf das zutrifft, woran du gerade arbeitest, musst du diesen Skill unbedingt aufrufen“

  • Ich verstehe nicht, warum alle so begeistert dabei sind, ihre eigenen Jobs abzuschaffen
    Das hier oder irgendein „Skill“ wird das wahrscheinlich nicht wirklich tun, aber grundsätzlich schon. Das wirkt auf mich wie Entfremdung von der Arbeit im großen Stil

    • Wir automatisieren seit Jahrzehnten große Teile früherer Arbeit. Sonst müssten wir alle absichtlich alles auf die ineffizienteste Weise machen, nur damit Arbeit möglichst lange dauert – und das ist keine gute Idee
      Die Menschheit hat, soweit wir es zurückverfolgen können, immer versucht, die Arbeit zu verringern, die für einen konstanten Output nötig ist, und genau das ist Zivilisation. Sollen wir wieder mit der Hacke Landwirtschaft von Hand betreiben, um den Arbeitseinsatz zu maximieren? Sollen wir wieder Straßenlaternen einzeln anzünden?
      Gesellschaften, die bei der Automatisierung zurückfallen, werden ärmer und sterben am Ende aus, weil selbst die dort Geborenen an produktivere Orte abwandern. Das sah man in Osteuropa, bei den Amish und in jeder armen Gesellschaft, aus der Migration entsteht. Mit weniger mehr erreichen war schon immer spannend
    • Als Computerprogrammierer fällt es mir schwer, diese Denkweise nachzuvollziehen. Ich habe mein ganzes Leben lang Dinge gebaut, damit Computer Arbeit erledigen und Menschen sie nicht mehr machen müssen. Jede geschriebene Software soll irgendjemandem Arbeit abnehmen
      Ich frage mich, ob du bei jeder Form von Automatisierung so empfindest. Unter klassischen Systemadministratoren gab es Leute, die die Weiterentwicklung von Infrastrukturautomatisierung so gesehen haben und nicht mochten, dass Dinge, die früher manuell gemacht wurden, nun von Skripten und Systemen erledigt werden
      Mein Team hat in einem Job ein automatisches Patch-System gebaut, das Patches auf 30.000 Servern ausführt und Systeme automatisch aus der Produktion nimmt und wieder hinzufügt. Der gesamte Prozess wurde hands-off, während es früher ein eigenes Team gab, das diesen Ablauf manuell durchgeführt hat. Haben wir ihnen durch Automatisierung die Arbeit weggenommen?
      In gewissem Sinne ja, aber es gab andere Dinge zu tun, und jetzt konnten sie diese tun
      Genau deshalb mag ich Programmierung, Computer und Technik: weil sie Arbeit für uns erledigen. Meine Utopie ist eine Welt, in der Roboter die anstrengende Arbeit machen, damit Menschen tun können, was sie möchten. AI bringt uns diesem Ziel einen Schritt näher. Statt zu versuchen, genug unerwünschte Arbeit übrig zu lassen, damit Menschen beschäftigt bleiben, würde ich mich lieber darauf konzentrieren, wie die Vorteile robotischer Jobverdrängung nicht nur wohlhabenden Eigentümern zugutekommen, sondern der ganzen Welt
    • Meist verlieren Menschen ihren Job, wenn sie sich nicht an den Markt anpassen können
      Im Moment ist noch nicht klar, in welche Richtung sich alles entwickelt, deshalb geben Leute ihre Daten an zufällige Agenten weiter, versuchen Wege zu finden, Kontext zu speichern und zugänglich zu machen, Prompts wiederzuverwenden und allerlei andere Ansätze, um mit dieser Technologie umzugehen
      Das meiste davon könnte in einem Jahr nutzlos sein, weil es tief in die nächste Modellgeneration integriert wird. Trotzdem gehörte es immer zum Spaß an diesem Bereich, mit der Entwicklung Schritt zu halten
    • Es ist ein Überlebensinstinkt. Wenn alle um dich herum, sogar dein Arbeitsplatz, „Nutze AI“ rufen, ist es schwer, eine Gegenposition einzunehmen oder Bedenken zu äußern. Es ist weniger Begeisterung als vielmehr die Angst, die Welle zu verpassen und zurückzufallen
      Ich denke, wenn Langzeitdaten zeigen würden, dass die durchschnittlichen Produktivitätsgewinne begrenzt sind und dass man selbst mit Unterstützung moderner Spitzenmodelle für hochwertige Software weiterhin Sorgfalt und menschliche Aufmerksamkeit braucht, wären sowohl Befürworter als auch Gegner etwas überrascht
      Es ist dieselbe Arbeit, nur dass man statt eines Schraubendrehers jetzt eine Akku-Bohrmaschine hat. Manche bauen damit Häuser, die Jahrhunderte halten, andere eben nicht
    • Am engagiertesten wirken oft die Leute, die vorher keine guten Entwickler waren und sich nun plötzlich bis auf „normal“ beschleunigt fühlen. Die guten Entwickler, die ich kenne, waren bei der Einführung alle deutlich vorsichtiger

  • In letzter Zeit höre ich ständig, dass Dinge, die gut für die Leitung von Entwicklerteams sind, auch gut für das Management von LLMs sind
    Gute Testfälle, klare und prägnante Dokumentation, CI/CD sowie Best Practices und Onboarding-Dokumente
    Das Management von LLMs wird immer ähnlicher zum Management menschlicher Teams

    • Ja. Ich sage das auch schon seit ungefähr einem Jahr und habe in internen Präsentationen genau diese Anekdote verwendet
    • Entsprechend kommen Erfolgsgeschichten über agentisches Coding meist aus Organisationen, die all diese Dinge ohnehin schon von Anfang an haben

  • Mich würde interessieren, was daran besser oder anders ist als spec-kit. Die Philosophie wirkt sehr ähnlich, und ich frage mich, ob man beides zusammen verwenden kann. Oder ist es einfach redundant?
    https://github.com/github/spec-kit

    • Nichts ist daran anders. Derselbe Müll für Entwickler, die sich über Massenentlassungen beklagen, aber AI beim Schreiben von Code nicht mit Bedacht einsetzen wollen

  • Ich war überrascht, dass manche Skills so lang sind – mehrere Seiten mit Tabellen, Checklisten und Codebeispielen
    Ich frage mich, wie verbreitet das ist. Schon ein paar davon würden den Kontext ziemlich stark füllen

    • Der Grund für die Länge ist, dass diese Skills meist mit Claude Code und Opus erstellt wurden und kein vernünftiger Mensch diese Dateien lesen oder daraus ein mentales Modell ableiten würde. Hier stapeln sich mehrere Annahmen, dass das funktionieren würde, aber in der Praxis funktioniert es nicht und ist verschwenderisch
      Es gibt dazu ein interessantes Experiment. Man bittet ein LLM einfach, etwas vage Vertrautes zu schreiben. Wenn man zum Beispiel „write a fib“ eingibt, antworten fast alle LLMs mit einem Fibonacci-Algorithmus, weil sie auf Code feinabgestimmt sind – obwohl das für Nichtprogrammierer auch „schreibe eine kleine Lüge“ bedeuten könnte
      Es findet also Kompression statt. Man kann das Ergebnis mit nur drei vagen Tokens ausdrücken, ohne genau zu erklären, was eine Fibonacci-Folge ist
      Deshalb merkt man, dass Prompt-Länge nicht entscheidend ist. Wichtig sind die richtigen Wörter, ihre Häufigkeit und ihre Reihenfolge. Ein Prompt über zwei Seiten und ein Prompt aus zwei Sätzen können zum selben Ergebnis führen
    • Beim schnellen Durchsehen wirkten zumindest einige eher wie Systemprompts für eng gefasste Sub-Agenten als wie Skills. Ich stimme zu, dass ich in lang andauernden Arbeitssitzungen nicht viele davon verwenden wollen würde
      Bisher war ich mit kurzen, fokussierten Skills erfolgreich. Ich behandle sie wie wiederverwendbare Kontext-Schnipsel, halte sie aber klein. Zum Beispiel ein paar Absätze darüber, wie ich Python in meinem Projekt verwende und wie Unit-Tests ausgeführt werden
      Ich habe auch mehrere kurze „Info“-Skills, die dem Agenten keine Anweisungen geben, sondern nur hilfreiche Kontextinformationen enthalten, die er bei Bedarf heranziehen kann
      Zu viele Skills können ebenfalls ein Problem werden. Schließlich landet irgendwann die Liste der Skill-Namen und Beschreibungen im Kontext
    • Ich habe noch nie selbst einen Skill geschrieben, daher weiß ich nicht, wie üblich das ist. Ich habe bei ein paar die Wortzahl gezählt, und die lagen bei ungefähr 2.000 Wörtern. Fünf Skills wären also rund 10.000 Wörter
      Das sind selbst bei einem kleinen LLM-Kontext von 128k etwa 10 %, und bei einem großen Modell mit 1M Kontextfenster fällt es kaum auf
    • Standardmäßig werden im Kontext nur das Frontmatter der Skills geladen, also Name, Beschreibung, Trigger usw., daher passiert das eher nicht – es sei denn, man hat Tausende Skills
    • Ich habe die Zeilenzahl der Skill-Dateien in meinem Projekt geprüft; die Top 3 lagen bei 805, 660 und 511 Zeilen
      Vielleicht bin ich hier auch zu konservativ. Es gibt noch viel zu erkunden

  • „Der Großteil der Arbeit eines Senior Engineers ist in Diffs nicht sichtbar“
    Agent Skills sind Addys Versuch, selbst diese Arbeit abzuschaffen. Prost, Addy :P