
Fünf Jahre KI im Alltag: von eigenen Python-Modellen zu Claude Opus 5
25.07.2026 - Sebastian Pech - ~7 Minuten
Gestern hat Anthropic Claude Opus 5 veröffentlicht. In der Ankündigung steckt ein Beispiel, das mich deutlich mehr beschäftigt hat als die Benchmark-Tabellen darunter. Es beschreibt in drei Sätzen ziemlich genau den Unterschied zwischen dem, woran ich vor fünf Jahren gesessen habe, und dem, was heute nebenbei passiert.
Das FreeCAD-Beispiel
Die Aufgabe: aus der Zeichnung eines Maschinenteils per Code ein 3D-Modell in FreeCAD rekonstruieren. Der Haken war, dass das Modell die Zeichnung nicht direkt ansehen konnte. Statt daran zu scheitern, schrieb es sich laut Anthropic
[…] its own computer vision pipeline to pull the geometry from the raw pixels
und baute aus dem Ergebnis das vollständige Bauteil nach. Reproduzierbar über mehrere Durchläufe, während andere Modelle auch nach fünf Anläufen nicht zum Ziel kamen.
Das Beeindruckende daran ist für mich nicht das CAD-Modell. Es ist der Zwischenschritt. Das Modell hat bemerkt, dass ihm ein Werkzeug fehlt, hat dieses Werkzeug gebaut und danach erst die eigentliche Aufgabe gelöst. Genau dieser Zwischenschritt war vor fünf Jahren mein kompletter Projektumfang.
Rückblick: als die Pipeline noch meine Aufgabe war
Angefangen habe ich mit eigenen Modellen in Python. pandas zum Aufräumen, scikit-learn für die Modelle, alles in Jupyter Notebooks, und der ehrliche Anteil an Machine Learning lag irgendwo bei zehn Prozent. Der Rest war Daten beschaffen, Daten säubern, Features bauen und Trainingsdaten labeln. Für die Auswertungen rund um meinen Knowledge Graph habe ich die Daten ebenfalls per Python aus den Datenbanken nach Neo4j geschoben. Auch hier steckte die Arbeit im Transport, nicht in der Analyse.
Bildverarbeitung war der Bereich, in dem ich am schnellsten an Grenzen kam. Kantenerkennung mit OpenCV, Schwellwerte, Konturen suchen, und am Ende hing das Ergebnis an Beleuchtung, Auflösung und Bildqualität. Eine belastbare Pipeline, die Geometrie aus einem Pixelbild zieht, war ein Projekt über Wochen – kein Zwischenschritt in einer größeren Aufgabe.
Parallel dazu bin ich früh auf vortrainierte Cloud-Dienste umgestiegen, weil der Aufwand-Nutzen-Vergleich eindeutig war. Die Gesichtserkennung mit Microsoft Cognitive Services auf dem Raspberry Pi lief nach einem Nachmittag, der Chatbot mit Watson ähnlich schnell. Der Preis dafür: Jeder Dienst konnte genau eine Sache. Gesichter erkennen. Sprache erkennen. Text klassifizieren. Wer etwas kombinieren wollte, schrieb den Klebstoff selbst.
So sah das auch noch 2023 aus. Mein Skript für WhatsApp-Sprachnachrichten mit Whisper sind rund 20 Zeilen Python um einen API-Aufruf herum – Dateiprüfung, Konvertierung, Aufruf, Ausgabe. Das Modell erledigte einen Teilschritt, die Ablaufsteuerung lag bei mir. GPT-3 gab es damals nur über eine Warteliste, und Copilot vervollständigte einzelne Zeilen.
Der Unterschied zu heute ist weniger die Qualität der Modelle als die Frage, wer die Pipeline baut.
Was im letzten Jahr passiert ist
Der Fortschritt der letzten zwölf Monate lässt sich an ein paar konkreten Punkten festmachen, die sich nicht mehr mit “besserer Autovervollständigung” abtun lassen.
Mathematische Beweise. Im Januar 2026 wurde das seit 1975 offene Erdős-Problem Nummer 728 zur Teilbarkeit von Binomialkoeffizienten gelöst. ChatGPT hat dabei keinen bekannten Beweis aus dem Netz reproduziert, sondern einen eigenen erarbeitet – zunächst nur für kleine Konstanten, nach angepasstem Prompt auch für große. Formalisiert und verifiziert wurde das Ergebnis anschließend als Lean-Code durch das System Aristotle. Im Mai 2026 folgte die Widerlegung einer Erdős-Vermutung zum Einheitsabstandsproblem aus dem Jahr 1946 durch ein internes Reasoning-Modell von OpenAI; der Princeton-Mathematiker Will Sawin verfeinerte den gefundenen Faktor danach auf rund n hoch 1,014. Google DeepMind meldete für sein System neun gelöste Erdős-Probleme.
Arbeit statt Aufgaben. Mit Claude Fable 5 im Juni 2026 kamen die Beispiele, bei denen es nicht mehr um einzelne Antworten geht. Stripe hat damit eine Ruby-Migration an einem Tag abgeschlossen, für die ein Team sonst zwei Monate gebraucht hätte. In der Molekularbiologie wurden die generierten Hypothesen in rund 80 Prozent der Fälle den bisherigen vorgezogen, im Proteindesign führten die Experimente bei 9 von 14 untersuchten Zielproteinen zu brauchbaren Kandidaten.
Ausdauer. Der aus meiner Sicht am meisten unterschätzte Wert: Zwischen Oktober 2025 und Januar 2026 hat sich die Dauer der längsten ununterbrochenen Claude-Code-Läufe (99,9-Perzentil) von unter 25 auf über 45 Minuten fast verdoppelt. Die Länge autonom bearbeitbarer Aufgaben verdoppelt sich derzeit ungefähr alle 200 Tage. Das ist der Grund, warum sich so ein FreeCAD-Umweg überhaupt lohnt – vor zwei Jahren wäre das Modell mitten in der eigenen Pipeline aus dem Kontext gelaufen.
Wofür ich das täglich nutze
Das klingt alles sehr nach Forschung. Der Alltag sieht unspektakulärer aus, hat sich aber genauso verschoben.
Code schreiben und reviewen
Der größte Block. Ich beschreibe das Ziel und den Rahmen, das Modell schreibt, ich prüfe. Deutlich wertvoller als das Schreiben ist inzwischen das Review: eigene Änderungen gegen einen zweiten Blick laufen lassen, bevor der Pull Request rausgeht. Vergessene Fehlerbehandlung, halb migrierte Aufrufe, Kleinigkeiten in Konfigurationen – das findet ein Modell zuverlässiger als ich am Freitagnachmittag.
Tägliches Review von Todos und Terminen
Morgens und abends lasse ich mir Aufgaben, Termine und offene Punkte zusammenfassen und gegeneinander prüfen. Nicht “was steht an”, sondern “was passt nicht zusammen”: Termine ohne Vorbereitungszeit, Aufgaben, die seit drei Wochen verschoben werden, Deadlines, für die der davor liegende Tag schon voll ist. Die Zusammenfassung ist in zwei Minuten da und ersetzt eine Viertelstunde Listenschieberei.
Second Brain in Obsidian
Mein Second Brain in Obsidian hat über die Jahre eine Größe erreicht, bei der ich nicht mehr alles kenne, was drinsteht. Genau da hilft es: Notizen ohne Verknüpfung finden, Dubletten zu einem Thema zusammenführen, Rohnotizen aus Meetings in eine saubere Struktur mit Tags und Links bringen. Die Verknüpfungsvorschläge sind das, was ich vorher manuell über den Graphen gesucht habe.
Basisübersicht für neue Themengebiete
Wenn ich in ein Thema einsteige, lasse ich mir zuerst eine Landkarte geben: zentrale Begriffe, die üblichen Werkzeuge, die typischen Fehler von Einsteigern und die Fragen, die ich mir stellen sollte. Das ersetzt keine Quelle, aber es ersetzt die ersten drei Stunden Orientierungslosigkeit. Danach lese ich gezielt weiter – und weiß immerhin, wonach ich suche.
Reiseplanung
Rahmen rein (Zeitraum, Budget, was wir sehen wollen, wie viel Fahrzeit pro Tag erträglich ist), Entwurf raus, dann iterieren. Was gut funktioniert, ist das Zerlegen: Routenlogik, Aufenthaltsdauer, sinnvolle Reihenfolge. Was ich grundsätzlich nachprüfe, sind harte Daten wie Öffnungszeiten, Preise und Verbindungen.
Tanzstunden vorbereiten und überarbeiten
Ein Anwendungsfall, den ich selbst nicht erwartet hätte. Ich gebe Niveau, verfügbare Zeit und Ziel der Stunde vor und lasse mir einen Ablauf entwerfen – Aufwärmen, Wiederholung, neue Figur, freies Tanzen. Der interessantere Teil kommt danach: Nach der Stunde schreibe ich auf, was nicht funktioniert hat, und lasse den Plan darauf umbauen. Über mehrere Wochen entsteht daraus eine Sammlung, die sich tatsächlich am Kurs orientiert und nicht an meiner Erinnerung von letzter Woche.
Grenzen
Bei aller Begeisterung sind ein paar Punkte unverändert.
Die Verifikation bleibt komplett bei mir. Je konkreter die Daten (Preise, Öffnungszeiten, Versionsnummern, API-Signaturen), desto häufiger sind Fehler, und desto überzeugender klingen sie. Bei Code ist das entspannt, weil Tests und Compiler widersprechen. Bei einer Reiseplanung widerspricht niemand.
Die Kosten sind gestiegen und sinken gleichzeitig pro Ergebnis. Opus 5 liegt bei 5 US-Dollar pro Million Eingabe- und 25 US-Dollar pro Million Ausgabe-Token, der schnellere Modus beim Doppelten. Wer Agenten stundenlang laufen lässt, sollte sich die Rechnung ansehen, bevor sie kommt.
Und der Punkt, der mich am meisten beschäftigt: Ich verlerne Dinge. Reguläre Ausdrücke schreibe ich nicht mehr selbst. Ein Bash-Skript zu debuggen dauert bei mir inzwischen länger als es zu ersetzen. Ob das ein Problem ist oder nur die nächste Abstraktionsebene, weiß ich ehrlich gesagt nicht – meine Assembler-Kenntnisse vermisse ich schließlich auch nicht.
Fazit
Vor fünf Jahren habe ich Pipelines gebaut, damit ein Modell einen Teilschritt erledigen kann. Heute beschreibe ich das Ziel, und die Pipeline entsteht unterwegs – notfalls inklusive eines selbst geschriebenen Computer-Vision-Schritts, wie im FreeCAD-Beispiel. Die Rolle hat sich von “Ich baue das Werkzeug” zu “Ich prüfe das Ergebnis” verschoben.
Was ich aus fünf Jahren mitnehme: Die Sprünge kommen nicht dort, wo die Benchmark-Tabellen sie ankündigen, sondern dort, wo plötzlich ein Umweg möglich wird, den vorher niemand eingeplant hatte.
Bildquelle: Erstellt mit Google Gemini