Wie man bessere AI-Tools baut

• Die meisten heutigen AI-Tools bilden menschzentrierte Lernprozesse (Abruf, Ausführung, kollektive Wiederholung) nicht ab — letztlich ist das ein rückwärtsgerichtetes Design, das die Wachstumsschleife von Mensch und AI gleichermaßen beschädigt
• Menschen lernen nicht Wissen, sondern ‚Prozesse‘ und schaffen Innovation durch kollektive, kumulative Wiederholung. Die meisten AI-Tools folgen jedoch dem Muster „Button klicken → AI erledigt den Rest“ und entfernen damit die vom Menschen gesteuerte Abruf- und Lernschleife
• Wünschenswerte AI-Tools sollten in den Stufen „Explain → Demonstrate → Guide → Enhance“ die aktive Beteiligung und den Abruf durch den Menschen fördern und nicht auf Automatisierung, sondern auf „Verstärkung“ abzielen
• Beispiel: In Beobachtungs-/Recovery-Tools sollte die AI nicht sofort Maßnahmen ergreifen, sondern in jeder Phase durch Prozesserklärung, Handlungsanleitung, Problemlösungsführung und Vorschläge zur Nachbereitung menschliches Denken und Lernen fördern
• Wenn sich solche menschzentrierten Muster etablieren, wird eine positive Feedbackschleife möglich, in der kollektives Wissenswachstum und die Qualität der AI gemeinsam gestärkt werden — mit Innovationspotenzial für System-Tooling insgesamt

---

Einleitung: Das grundlegende Problem menschlichen Lernens und von AI-Tooling

• AI-Tools werden nicht so entwickelt, dass sie menschliche Zusammenarbeit und Lernen unterstützen, sondern auf ineffiziente und rückwärtsgerichtete Weise
• Die Tools sind nicht darauf ausgelegt, menschliche Fähigkeiten zu stärken, sondern behindern kritisches Denken und Problemlösung
• Diese Lage erzeugt bereits sichtbare negative Effekte, und es ist ein Kurswechsel in eine wirksamere Richtung nötig

Grenzen heutiger AI-Tools: rückwärtsgerichtete Entwicklung

• Der Großteil heutiger AI-Tools folgt diesem Muster
  • Auf den AI-Button klicken → wie durch Magie sofort ein Ergebnis erhalten
  • Daten anzeigen und AI-Vorschläge liefern
  • Einfache Prompts und automatische Ausführung
• Dieser Ansatz lässt die zentralen Lernschleifen aus: Problemdefinition, Erinnern, Abruf, Prozesslernen, Wissensweitergabe und iterative Verbesserung durch den Menschen
• Die AI versucht, zentrale menschliche Stärken zu ersetzen, obwohl gerade sie selbst in diesem Bereich schwach ist
• Das Ergebnis ist der Rückgang menschlicher Problemlösungs- und Denkfähigkeit → Unfähigkeit, hochwertige Daten zu erzeugen (was wiederum die Weiterentwicklung der AI behindert) → ein Teufelskreis

Wie lernen Menschen?

• Laut der Theorie des Retrieval Practice lernen Menschen nicht durch bloße Informationsaufnahme, sondern durch aktiven Abruf
• Der echte Lerneffekt entsteht nicht durch simples Auswendiglernen, sondern im Prozess, Informationen selbst aus dem Gehirn „herauszuholen“
• Das Wichtigste beim Lernen ist nicht das Wissen selbst, sondern der Erwerb von Prozessen
  • Wer zum Beispiel Backen lernt, profitiert mehr davon, das Verfahren zum Kuchenbacken zu lernen, als sich nur die Zutaten zu merken
• Ein solches praxis- und prozessorientiertes Design eignet sich besser für Kollaborationstools

Das Prinzip von Innovation und kollektivem Wachstum

• Das Wesen von Innovation entsteht nicht durch Einzelne, die neue Technologien erfinden, sondern durch die kollektive Kumulation kleiner iterativer Verbesserungen
  — Nicht einige wenige geniale Schöpfungsakte sind entscheidend, sondern der Prozess, in dem mehrere Menschen bestehendes Wissen überlagern und verbessern
• Menschen sind weniger für isolierte Innovation optimiert als für Nachahmung, Wiederholung und die Abwandlung bestehender Beispiele
• Theorien gehirnbasierten kollektiven Lernens zeigen, dass diese Art kollektiver Innovation dem Menschen grundsätzlich besonders liegt
• Problemlösung und Innovation sollten nicht getrennt betrachtet werden; Problemlösefähigkeit, Wissensweitergabe und kollektives Lernen sind selbst der Antrieb von Innovation
• Entscheidend sind prozesszentriertes Lernen, angemessenes Anstrengungsniveau, kollektive Wiederholung und Verstärkung sowie menschenunterstützende AI

• AI-Tools sollten menschliche „Denkassistenten“ sein und nicht eigenständig urteilen oder Menschen ersetzen

Das richtige Design von AI-Interaktionen

• AI lässt sich eher mit einem vergesslichen Dozenten als mit einem Kollegen oder Praktikanten vergleichen
• Ihr Ziel ist es, Nutzer dabei anzuleiten, selbst zu lernen und zu lernen, wie sie lernen sollen
• Sie sollte so gestaltet werden, dass sie einen wirksamen Bildungsprozess (EDGE: Explain, Demonstrate, Guide, Enhance) verstärkt
  • Erklären (Explain): Prozesse anleiten, fehlende Schritte aufzeigen usw. (nicht bloß „Klicken Sie einfach auf den Button“)
    • Fehlende Schritte vorschlagen
    • Prozessleitfäden bereitstellen und erläutern
    • Den Prozess hervorheben, in dem Menschen selbst den Ablauf erinnern und ausführen
    • Schlechte Beispiele: sofort einen „Ausführen“-Button anbieten, Error-Tooltips usw. — also den Abrufprozess ausklammern
  • Demonstrieren (Demonstrate): Query-Transformation, UI-Demos, interaktive Vorführungen — nicht direkte „Auto-Ausführung“, sondern Förderung von Beteiligung
    • Natürlichsprachliche Abfragen in die Query-Syntax des Systems umwandeln
    • Navigation in der UI unterstützen (bei Anfrage direkt zur relevanten Ansicht führen)
    • Kurze 15-Sekunden-Demos und interaktive Tutorials bereitstellen
    • „Auto-Ausführung“ vermeiden: geringeres Vertrauen, keine Feinabstimmung möglich, Abbau menschlicher Fähigkeiten
    • Auch zusätzliche Daten und menschliche Abrufaufzeichnungen (Pairing, Mentoring usw.) sollte die AI als Lernmaterial nutzen
  • Anleiten (Guide): Fragen anstoßen, Problembereiche diskutieren, Aktionspläne erstellen — sokratisches Fragen und Validieren
    • Wenn der Nutzer einen Plan vorlegt, die nächsten Schritte und passende Guidance vorschlagen
    • Auf benötigte Dokumente, Code-Verantwortliche und relevante Materialien hinweisen
    • Beobachtungs-/Lernmodelle und Dokumentation fördern
    • Antworten validieren, Informationen querprüfen, Klarheit überprüfen
    • Schlechte Beispiele: Unterstützung ohne zum Denken anzuregen, zu viele ungefragte Informationen, autoritärer Ton, Missbrauch eines „Weiter“-Buttons durch den Nutzer
    • Unterstützung nur in dem Maß leisten, dass wiederholtes rationales Schlussfolgern des Menschen nicht behindert wird
  • Verstärken (Enhance): Nach einer Handlung Verbesserungen vorschlagen, wiederkehrende Muster lernen, reale Aufzeichnungen in Postmortems überführen — feine Lernanlässe schaffen
    • Direkt nach oder während einer Aktion schrittweise Verbesserungen vorschlagen
    • Für wiederkehrende Aufgaben Shortcuts/Zusatzfunktionen dynamisch einblenden
    • Verbesserungen des Prozesses selbst vorschlagen: Infrastruktur-Pipelines verbessern, Alerts anpassen, bei Bauchgefühl zu besserer Instrumentierung raten usw.
    • Aufzeichnungen nach Vorfällen (Notizen → Lernmaterial), Mikrolernen durch Beobachtung fördern
    • Den menschlichen Schlussfolgerungs-Hub erhalten und statt automatischer Optimierung auf natürliche Weise Prompts zur Abrufverstärkung einführen
• Besonders wichtig ist, in jeder Phase eine Struktur zu schaffen, in der Menschen erinnern, auswählen und ausführen, während die AI sich darauf konzentriert, dies zu verstärken
  • Anhand realer Beispiele (Incident-Management- und Observability-Tools) werden für jede Phase gute AI-Interaktionsbeispiele und Antipatterns erläutert

Übergeordnete Prinzipien

• Menschliches Lernen kontinuierlich stärken
• Teamarbeit fördern: kollektive Zusammenarbeit und Informationsaustausch
• Statt Automatisierung nach dem Muster „Lücke → richtige Antwort“ die Beteiligung am Prozess und die Ausführung beschleunigen (ohne direkt durch Automatisierung zu ersetzen)
  • Ergebnisse nicht „aus dem Nichts“ sofort liefern
• Keine „mühelose Usability“, sondern Tools, die angemessene Anstrengung und Beteiligung verlangen
• Unterstützen, dass Teamlernen und Erfahrung in die Ergebnisse einfließen

Ein gutes Beispiel in der Softwareentwicklung: kein „rückwärtsgerichtetes“, sondern „vorwärtsgerichtetes“ Design

• Statt mit AI sofort Code zu generieren,
  • Entwurf eines Dokuments → Architekturdiagramm → Testplan → Testcode → Stub-Code → Codegenerierung
• Nach der Codevalidierung den gesamten Prozess rückwärts durchlaufen und Tests, Dokumentation und Architektur neu ordnen
• In jeder Phase Fragen und Validierung (Abrufverstärkung) betonen; man sollte nicht nur Ja/Nein-Fragen stellen, wenn keine Prüfung möglich ist
• Abrufbasierte Entwicklungsweisen erzeugen hochwertige Lern- und Testdaten und verbessern zugleich das AI-Lernen

Erweiterbarkeit auf bereichsübergreifende Funktionen (nicht Entwicklung, z. B. Customer Support)

• Beispiel: Bei einem Incident mit Betriebsunterbrechung kommuniziert das Customer-Support-Team mithilfe von AI mit dem Entwicklungsteam
  • Die AI erstellt einen ersten Entwurf, den das Entwicklungsteam prüft und dadurch die Genauigkeit erhöht
  • Echtzeit-Informationsfluss zwischen mehreren Organisationseinheiten wie Support und Entwicklung sowie minimale Kontextwechselkosten
  • Schlüsselpersonen werden nicht übermäßig unterbrochen, während bei Bedarf gegenseitige Kommunikation reibungslos möglich bleibt
  • Kontextreiche technische Antworten des Entwicklungsteams kann die AI leicht in allgemein verständliche Erklärungen umwandeln
• Wenn sich eine solche Struktur umsetzen lässt, können kollektives Lernen und die Effizienz der Zusammenarbeit innerhalb und außerhalb der Organisation maximiert werden
• Weiterentwicklung zu einem Tool für mehrschichtige Unterstützung/Integration möglich

Fazit

• Heutige AI-Tools werden rückwärtsgerichtet entwickelt und schwächen dabei die kollektive iterative Lern- und Problemlösefähigkeit des Menschen
  • Nötig ist ein Wandel hin zu stärkerer Zusammenarbeit und Unterstützung menschlich geführter Prozesse
• Erst dann wird eine positive Spirale möglich, in der Mensch und AI einander wechselseitig verstärken und gemeinsam wachsen
• Beim Tool-Design darf man nicht vergessen, dass der Mensch nicht einfach nur „in der Schleife“ ist — der Mensch selbst ist die Schleife
• Gerade jetzt braucht System-Tooling menschzentrierte Innovation
  • Kollaborative, prozessorientierte, verstärkende AI-Tools sind der Schlüssel zur Innovation

[GN⁺]

Hacker-News-Kommentar

• Dieser Beitrag hat einige verwirrende Stellen. Es wirkt, als meine Weakly mit einem Coding-Agenten, der eher passiv ist und hauptsächlich Ratschläge gibt, so wie antirez es 2025 offenbar bevorzugt. Tatsächlich geht es aber um einen Agenten, der Betriebsprobleme untersucht und behebt. Weaklys Argument ist, dass der Agent wie Clippy nur Hinweise geben und dem Menschen das Steuer überlassen soll. Ich verstehe jedoch nicht, welchen Wert es haben soll, wenn Menschen selbst Logs durchforsten, Ausreißer finden und Hypothesen aufstellen. Genau wie Computer besser Schach spielen, ist AI für solche Aufgaben ein Werkzeug, das Menschen grundsätzlich überlegen ist. Weakly zieht offenbar eine klare Grenze zwischen Beratung und tatsächlichem Handeln, aber ich halte diese Grenze nicht für richtig. Natürlich gibt es Bereiche, in denen man AI nicht völlig autonom ausführen lassen kann, etwa bei terraform apply, aber umgekehrt gibt es auch viele Bereiche, in denen es keinen guten Grund gibt, sie auszubremsen. Das Ziel bei der Incident-Behebung ist letztlich, den Vorfall zu lösen

  • Es gibt bislang kein AI-Tool, das Incidents wirklich zufriedenstellend löst. Schon wegen der Verantwortlichkeit und auch um korrekte Ausführung sicherzustellen, ist menschliches Eingreifen unverzichtbar

  • Das grundlegende Problem ist, ob man AI Zugriffsrechte auf die reale Produktionsumgebung geben will. Wenn man die jüngsten Fälle betrachtet, in denen AI trotz der Anweisung, etwas nicht zu tun, Datenbanken gelöscht hat, weil sie Negationen wie „not“ nicht immer korrekt versteht, ist das aus Sicherheitssicht ein ernstes Problem

  • Ich frage mich, wie viel Autonomie man einem Agenten überhaupt geben kann. Nach DevOps-Best-Practices würden die meisten Änderungen erst nach Code-Commits oder Promotion durch mehrere Umgebungen in Produktion gelangen. Das gilt nicht nur für Anwendungscode, sondern auch für die Infrastruktur selbst. In so einem Setup ist die Frage, welche Teile der Incident-Reaktion man einem Agenten autonom ausführen lassen kann

  • Ich denke, es hat durchaus einen gewissen Wert, selbst zu debuggen. Vor allem dann, wenn das Ziel ist, die eigenen Programmierfähigkeiten zu verbessern. Beim Schach etwa können AI-Systeme wie Leela oder Stockfish viel schneller und tiefer analysieren, aber echte Spielstärke entsteht meiner Meinung nach auch durch die Erfahrung, Positionen selbst zu analysieren. Selbst Profi-Schachspieler trainieren ständig Taktik und schulen damit ihr Gehirn. Ob man mit AI zusammen schneller lernt oder unabhängiger lernt, weiß ich selbst nicht genau. Und auch darüber, ob diese Fähigkeit in Zukunft überhaupt noch wichtig ist, kann man unterschiedlicher Meinung sein

  • Ein wichtiger Punkt in Diskussionen über Anomalieerkennung und Incident-Management ist, dass nicht alle Probleme gleich sind und sich viele bis zu einem gewissen Grad automatisieren lassen. Entscheidend ist die Grenze, wann man ein Problem an einen kognitiven Prozessor wie AI übergibt und wann ein menschlicher Engineer direkt eingreifen sollte. AI ist gut darin, Muster in großem Maßstab zu erkennen, aber sie liegt nicht immer richtig, wenn es darum geht, ob diese Muster auch bedeutungsvoll sind. Natürlich heißt das nicht, dass Menschen diese Lücken immer zuverlässig füllen können

• Aus Sicht von AI-Tools und -Produkten sollten wir uns künftig in Richtung "Intelligent Workspaces" bewegen. Wir müssen über einfache Chatbots hinausgehen
  Verwandter Link
  Im Kern sind Umgebungen oder Plattformen wichtig, in denen alle Einstellungen, Hebel und Kontrollmöglichkeiten beim Menschen bleiben, während AI-Funktionen eng integriert sind. Das ist deutlich schwieriger als nur ein weiterer VSCode-Fork

  • Chatbots sind viel einfacher umzusetzen als intelligente Workspaces. Und AI funktioniert auch ohne menschliche Interaktion gut. Ich würde mir wünschen, dass es mehr Möglichkeiten gibt, AI über andere Interfaces als Chat zu nutzen

  • Ich arbeite gerade mit Claude Code an einem Projekt und fände es großartig, wenn meine Instanz mit den Instanzen anderer Entwickler sprechen und zusammenarbeiten könnte. Ich kann zwar CLAUDE.md anpassen und so Dokumentation pflegen, aber es wäre wirklich hilfreich, wenn CC selbst eingebaute Team-Collaboration-Funktionen hätte. Falls jemand gute Vorschläge hat, gerne her damit

• Ich finde, dieser Beitrag zeigt gut, warum Innovation oft von Außenseitern kommt. Beim Autor merkt man sehr deutlich den Hintergrund eines Engineering-Managers oder Staff Engineers in großen Organisationen, und mit meinen Erfahrungen resoniert das nicht besonders stark. Falls sich dieser Stil als Standard für AI-Tooling verfestigt, befürchte ich, dass AI auf Basis bestimmter Annahmen über menschliche Workflows stagniert. Ich selbst forsche seit 15 Jahren an ML-Anwendungen zur Unterstützung von Domain-Experten ohne Programmierhintergrund, und meine Prinzipien unterscheiden sich etwas von denen des Autors. Dass die Sichtweisen so weit auseinandergehen, zeigt für mich, wie groß der Designraum noch ist, und ich halte es für viel zu früh, schon jetzt zu entscheiden, dass ein bestimmter Ansatz der richtige ist. Wohin sich AI-Tooling entwickelt, weiß derzeit noch niemand

  • Eine mögliche Lesart wäre natürlich auch, dass die ML-Systeme, die ich gebaut habe, in den letzten 15 Jahren menschliche Fähigkeiten nivelliert oder ersetzt haben. Aber ich stimme zu, dass die Interpretation stark von der eigenen Position abhängt. Trotzdem halte ich es für gute Praxis, den Menschen und menschliches Wissen beziehungsweise menschliche Recherche möglichst im Zentrum des Workflows zu halten

• Was mir bei AI-Coding immer Sorgen macht, ist, dass es schwieriger wird, die eigenen Fähigkeiten zu erhalten. Das direkte Tippen von Code, einschließlich Boilerplate, ist gewissermaßen ein Training wie Mr. Miyagis Streichen. Durch diese Wiederholung prägen sich Muster tief ein, was später bei übergeordneten Architekturentscheidungen enorm hilft

  • Vielleicht haben frühere Technologien wie Schreiben oder Drucken ebenfalls Handschrift oder rhetorische Fähigkeiten geschwächt, dafür aber das Denken verstärkt. Steve Jobs’ Idee vom „Bicycle for the mind“ ist dafür ein typisches Beispiel. Wenn man diese Logik jedoch auf AI überträgt, gibt es einen wichtigen Unterschied: Frühere Technologien beseitigten Engpässe in der Verbreitung, während AI den kreativen Prozess selbst direkt angreift. Den Einsatz von AI in kreativer Arbeit halte ich nur dann für sinnvoll, wenn er die Entwicklung meiner eigenen Kreativität nicht behindert. Menschliche Selbstkontrolle und Selbstwahrnehmung haben Grenzen

  • Ich denke nachts oder unter der Dusche oft über Probleme nach und stelle mir dabei „Code“ im Kopf vor. Wenn die Sprachstrukturen nicht tief in meinem Denken verankert wären, wäre solches imaginäres Codieren kaum möglich

  • Auch im Alltag gibt es ähnliche Beispiele:

1. Ich kann mich kaum erinnern, wann ich zuletzt etwas Bedeutendes handschriftlich geschrieben habe. Meine Handschrift ist inzwischen wirklich grauenhaft
2. Ohne Navigation traue ich mir kaum noch zu, beim Fahren den Weg zu finden. Kartenlesen? Das wirkt inzwischen fast wie aus einer anderen Welt

• Es gab einmal Zeiten, in denen man Transistoren von Hand verlötete. Heute ist die Technik so weit fortgeschritten, dass es mühsam geworden ist, so etwas wie früher noch selbst zu tun. Während sich der Fokus des Denkens immer wieder ausweitet und wieder verengt, vermisse ich das Codieren manchmal trotzdem. Ich codiere allerdings immer noch viel

• „Every augmentation is an amputation“ – Marshall McLuhan

• Deshalb mag ich Deep Research wirklich sehr. Es beginnt immer mit Fragen und bringt mich dazu, klarer zu definieren, was ich eigentlich lernen will. Ich habe das Gefühl, dass schon kleine UX-Unterschiede einen großen Einfluss darauf haben können, ob Nutzer durch einen Service wirklich lernen oder sich umgekehrt nur ohne kritisches Denken auf das Tool verlassen

  • Aber hast du dir diese Fragen selbst wirklich einmal genau angesehen? Deep Research ist manchmal nützlich, aber gelegentlich wirkt diese „Frage“ auch so, als wäre sie nur eingefügt worden, um klug zu wirken. Oft wird sogar noch einmal nach Dingen gefragt, die ich bereits sorgfältig und eindeutig formuliert habe. Für den eigentlichen Rechercheprozess scheint das nicht besonders hilfreich zu sein

  • Als Technical Writer nutze ich Deep Research eher nicht. Es stört meine Arbeit sogar eher. Der Prozess des Recherchierens, Notierens und Zusammenfassens ist der zentrale Teil, durch den ich ein Thema wirklich tief verstehe. Das fertige Dokument ist nur das Ergebnis davon. Wenn AI mir diese Arbeit abnimmt, bekomme ich zwar Notizen, aber nicht dasselbe Verständnis. Das Lesen von AI-generierten Dokumenten kann eigene Erfahrung nicht ersetzen

• Ich denke, dieser Beitrag verwechselt den Kern der AI-Einführung. Das Ziel von AI-Einführung ist nicht, Menschen klüger zu machen, sondern repetitive Arbeit zu beseitigen, bei der menschliche Kreativität nicht sinnvoll belohnt wird, und so die Produktivität des gesamten Prozesses zu steigern

• Meiner Erfahrung nach nutzt man AI beim Coden am besten auf folgende Weise:

  • Als eine Art fortgeschrittenes Find/Replace, etwa wenn man bei Struct-Initialisierungen gesammelt anweisen will: „Ändere das alles zu Y“. (regex ist einfach zu mühsam)
  • In agentischen Workflows ist es effektiv, AI nicht wie einen Menschen zu behandeln, sondern Aufgaben in gröbere, höherwertige Schritte zu zerlegen und nacheinander zu geben. Nicht „Implementiere ein Feature“, sondern eher „Erstelle eine neue Datei und definiere Stub-Funktionen“ → „Füge in die erste Funktion Verhalten x ein“ → „Die zweite Funktion soll zuerst die erste aufrufen und danach Y tun“
  • Um sich in fremden Codebases zurechtzufinden oder nach einer bestimmten Implementierung zu fragen. So etwas wie: „copilot, wo sind hier eigentlich alle App-Routen definiert?“ Früher hätte man dafür ständig die Experten im IRC fragen müssen, heute geht das sehr bequem und schnell

• Vor Kurzem habe ich meinem Vater bei der Vorbereitung einer Präsentation geholfen. Er hatte alle Informationen, aber als Nicht-Designer fiel es ihm schwer, die Slides ansprechend zu gestalten. Wir haben mehrere AI-Apps zur Erstellung von Präsentationen ausprobiert, aber obwohl sie auf den ersten Blick gut aussahen, halfen sie kaum bei der eigentlichen „Designverbesserung“, die der Nutzer wollte. Am Ende kamen wir zu dem Schluss, dass man mit manueller Überarbeitung deutlich bessere Ergebnisse erzielt

• Ich stimme vollkommen zu, dass insbesondere der Ablauf „mit Architektur und Testdesign beginnen und es dann auf den realen Code anwenden“ zu 100 % effektiver war. Das geht auch schon allein durch veränderte Workflow-Gewohnheiten, selbst ohne spezielle Tools, wobei dedizierte Tools oder Standard-Prompts natürlich hilfreich wären

  • Ich brauchte das selbst so dringend, dass ich angefangen habe, ein eigenes Architektur-Tool zu bauen. Wenn die Architektur solide ist, kann man die Implementierung inzwischen durchaus an AI delegieren. Allerdings sind diese Tools noch schwach darin, Logs aus lang laufenden Prozessen wie docker-compose zu lesen. Und die eigentliche Arbeit besteht aus Folgendem:
    • Problem untersuchen
    • Funktionalität beschreiben
    • API-Vertrag definieren
    • Grundlegenden Implementierungsplan schreiben
    • Authentifizierung und Berechtigungen einrichten
    • Teststrategie und effizientes Setup/Tear-down für Tests vorbereiten
    • Bibliotheken dokumentieren und offizielle Dokumentation für AI auffindbar machen
    • Außerdem macht AI häufig Fehler bei import und ist auch bei lang laufenden Prozessen anfällig
  • Das ist eine so grundlegende Aussage, dass der Satz auch ohne das Wort „vibe“ exakt derselbe wäre

• Menschen sind eine Spezies, die außerordentlich gut auf kumulative Iteration, also kontinuierliche Verbesserung, spezialisiert ist. Deshalb funktioniert Brainstorming in Gruppen besonders gut. In der Kognitionspsychologie gibt es sogar Theorien über diese kollektive Lernform und die kumulative „Kultur“ von Innovation. Wir sprechen oft davon, „auf den Schultern von Riesen“ zu stehen, aber das ist nicht nur eine schöne Redewendung, sondern beschreibt tatsächlich, wie Menschen funktionieren. Kreativität ist letztlich Suche, und zwar soziale Suche. Sie entwickelt sich nicht nur im Inneren des Gehirns, sondern in der Wechselwirkung zwischen Gehirn und Umwelt sowie auf sozialer und kultureller Ebene. Deshalb beschäftigt mich nicht besonders, ob LLMs wirklich „verstehen“. Wenn sie suchen, Ideen hervorbringen und diese in der Praxis verifizieren, reicht mir das. Außerdem halte ich die Suche selbst für wichtiger als das zugrunde liegende Substrat. Allerdings kann das Substrat den Suchraum beeinflussen, auf den man zugreifen kann