Blog
Alle Artikel
Retry ohne Jitter ist halb gelöst
Ein Retry bei Fehlern oder Rate Limits braucht mehr als eine Schleife. Robustes Verhalten entsteht aus Backoff, Jitter, Retry-After, klaren Grenzen und Idempotenz.
Tool Calling: Das Modell kennt nur, was du beschreibst
Bei Tool Calling entscheidet ein Sprachmodell anhand von Name, Beschreibung und Parametern. Gute Verträge, verwertbare Fehler und minimale Rechte machen LLM Agents berechenbarer und sicherer.
Embeddings: Ähnlich heißt nicht relevant
Vektorsuche findet semantisch ähnliche Texte, aber nicht automatisch die Passage, die eine Frage beantwortet. Chunking, RAG Hybrid-Suche und Re-Ranking machen die Suche robuster.
Mehr Kontext macht die Antwort oft schlechter
Ein großes LLM Kontextfenster ist Kapazität, keine Qualitätsgarantie. Wer irrelevanten Text mitgibt, erhöht Kosten und kann genau die Information verdrängen, die für die Antwort entscheidend ist.
Structured Output ist keine Garantie: Nach dem Parsen selbst validieren
LLM Structured Output sorgt für ein verlässlicheres Format, nicht für fachlich korrekte Inhalte. JSON Schema ist der Anfang einer robusten Pipeline, nicht ihr Ende.
Prompt Injection: Warum dein LLM Anweisung und Daten nicht zuverlässig trennt
Prompt Injection entsteht, weil ein LLM Anweisungen und externe Inhalte im selben Kontext verarbeitet. Entscheidend ist daher nicht der perfekte Filter, sondern begrenzte Rechte, bestätigte Aktionen und validierte Ausgaben.
Rails find_each sortiert nach ID – nicht nach deinem order
Rails find_each und in_batches verarbeiten Datensätze in stabilen Primärschlüssel-Batches. Ein fachliches order im Scope wird dafür nicht übernommen – mit Folgen für Jobs, die vermeintlich nach Datum oder Aktualität laufen.
Dein Sidekiq-Job ist nicht idempotent. Beim Retry merkst du es.
Sidekiq führt Jobs mindestens einmal aus. Ohne Idempotenz kann ein Retry Mails, Buchungen oder andere Seiteneffekte doppelt auslösen.
`includes` löst N+1, kann aber zu viel laden
Rails `includes` verhindert N+1-Abfragen, ist aber keine pauschale Performance-Lösung. Entscheidend sind die Unterschiede zu `preload` und `eager_load` sowie der Speicherbedarf großer Assoziationen.
`update_all` überspringt Callbacks und Validierungen. Mit Absicht.
Rails `update_all` führt ein einzelnes SQL-UPDATE aus, ohne Modelle zu instanziieren. Das ist für gezielte Massenänderungen sinnvoll, umgeht aber bewusst Validierungen, Callbacks und automatische Zeitstempel.
Diese idiomatische Rails-Zeile löscht still deine Daten
Ein Scope auf einer has_many-through-Assoziation filtert den Lesepfad, nicht den Schreibpfad. Dadurch kann eine scheinbar harmlose Zuweisung Join-Datensätze ersetzen, die im Reader gar nicht sichtbar waren.
Impeccable: Warum deine KI-Oberflächen alle gleich aussehen
KI-Agenten liefern häufig dieselben bekannten SaaS-Muster: Karten in Karten, Symbolkacheln und austauschbare Überschriften. Impeccable gibt dem Agenten Design-Vokabular und erkennt typische KI-Spuren regelbasiert.
OpenSEO: SEO-Daten ohne Abo und direkt für KI-Agenten
OpenSEO ist eine Open-Source-Alternative zu Semrush und Ahrefs mit nutzungsbasierter Abrechnung über den eigenen DataForSEO-Schlüssel. Der integrierte MCP-Server macht die Daten auch für KI-Agenten nutzbar.
Deine sidekiq_options stehen noch da. Sie tun nur nichts mehr.
Beim Wechsel zu Sidekiq ActiveJob kann sidekiq_options queue still ignoriert werden, während retry weiter wirkt. Entscheidend ist nicht die Deklaration im Job, sondern die Payload, die tatsächlich in Redis landet.
Nach der Migration kann sich kein alter User mehr einloggen: Devise-Pepper prüfen
Ein falscher oder fehlender Devise-Pepper erzeugt keinen sichtbaren Fehler. Neue Accounts können funktionieren, während alle migrierten Passwörter wie bei einer Falscheingabe abgewiesen werden.
Prompt Caching: Die Reihenfolge im Prompt kostet Geld
Prompt Caching belohnt einen stabilen gemeinsamen Anfang. Wenn Zeitstempel, Nutzerdaten oder die aktuelle Frage am Anfang stehen, wird aus einem möglichen Cache-Treffer schnell ein Cache-Miss.
Wenn dein LLM sich weigert, ist das ein Signal – kein Fehler
Ein LLM Klassifikator braucht neben Urteil und technischem Fehler einen dritten Ausgang: die inhaltliche Verweigerung. Besonders über Router kann sie in mehreren HTTP- und Response-Formen auftreten.
Dein JSON-Schema ist valide. Die Antwort ist trotzdem falsch.
Structured Output und OpenAI strict mode sichern die Form einer Antwort ab, nicht ihre fachliche Bedeutung. Deshalb müssen semantische Regeln fail-closed im eigenen Code geprüft und mit echten Modellantworten getestet werden.
temperature: 0 heißt nicht deterministisch
LLM temperature 0 reduziert Zufall bei der Ausgabe, garantiert aber keine identischen Ergebnisse. Eine Messung mit OpenRouter zeigt, warum Provider-Routing, Hardware und MoE-Routing für kritische Urteile relevant sind.
Bedrock aus Rails: drei Fallen mit ruby_llm
OpenAI-kompatible Endpoints verhalten sich nicht automatisch wie OpenAI. Bei ruby_llm entscheiden System-Rolle, getrennte Timeouts, Context-Scoping und saubere VCR-Filter darüber, ob eine Rails-Integration zuverlässig und ohne Geheimnisse im Repository läuft.
„Nur beratend“, sagte der Review-Bot. 3 von 4 waren echte Bugs.
AI-Review-Bots priorisieren Hinweise, aber ihre Einstufung ist keine Kostenprognose. Warum auch beratende Funde eine bewusste Entscheidung brauchen – mit einer pragmatischen Triage-Regel für Teams.
S3 sagt 200 OK. Dein Upload ist trotzdem kaputt.
Bei einem S3 Multipart Upload kann CompleteMultipartUpload mit HTTP 200 antworten, obwohl der Fehler im Response-Body steht. Verlässlich ist ein Upload erst nach Body-Prüfung, HEAD-Abfrage und Größenvergleich.
Zwei grüne Deploys – und live läuft die alte Version
Zwei Merges, zwei erfolgreiche Pipelines, aber in Produktion landet der ältere Commit: Ein veränderbarer Docker-Tag und parallele Deploys erzeugen eine Deploy Race Condition. Die Gegenmittel sind Serialisierung und unveränderliche Image-Tags.
Rails war schon immer ein Produktivitäts-Framework – AI verstärkt genau diese Stärke
Rails optimiert auf kurze Wege von der Produktidee zum belastbaren Feature. Mit AI wird dieser Vorteil größer – sofern Domänengrenzen, Tests und technische Entscheidungen weiterhin beim Team liegen.
Warum ich bei AI-Reviews gezielt versuche, die eigene Lösung zu widerlegen
Plausible Antworten sind kein Qualitätsnachweis. Ein belastbarer AI-Review sucht aktiv nach Gegenbeispielen, Negativkontrollen und unabhängigen Messungen – also nach Fällen, in denen die eigene Erklärung scheitern müsste.
Die beste AI-API ist nutzlos, wenn dein Use Case nicht erlaubt ist
Modellqualität und Tokenpreis sind keine ausreichenden Auswahlkriterien. Provider-Policies, Datenresidenz, Rate Limits, Zahlungswege und Exit-Optionen entscheiden, ob eine AI-Lösung überhaupt gebaut und betrieben werden kann.
Wie beweist man, dass etwas Gefährliches nicht passiert?
Sicherheitsanforderungen beschreiben oft eine Abwesenheit: kein Datenabfluss, keine unberechtigte Freigabe, kein gefährlicher Tool-Aufruf. Ein grüner Happy Path beweist das nicht. Entscheidend sind verbotene Pfade, Negativtests und beobachtbare Guards.
Ein Rollback macht nicht automatisch alles wieder gut
Ein Deployment zurückzudrehen stellt häufig nur den alten Code wieder her. Daten, externe Systeme und fachliche Entscheidungen können bereits verändert sein. Wer Recovery plant, muss diese Zustände getrennt betrachten.
Was soll ein AI-System tun, wenn es etwas nicht weiß?
„Unbekannt“ ist weder Erfolg noch Fehler. Ob eine Automation bei fehlender Prüfung durchlässt oder blockiert, entscheidet über Risiko, Umsatz und Haftung. Fail-open und fail-closed gehören deshalb ins Prozessdesign – nicht in implizite Defaults.
Wenn AI mehr Code produziert, wird Architektur wichtiger – nicht unwichtiger
AI senkt die Kosten für Code. Damit werden auch doppelte Lösungen, falsche Abstraktionen und inkonsistente Schnittstellen billiger. Architektur bleibt der Mechanismus, der lokale Produktivität in ein dauerhaft wartbares System übersetzt.
Ein AI-Prototyp ist noch lange kein AI-Produkt
Eine Demo beweist, dass ein Modell im Idealfall helfen kann. Ein Produkt muss auch bei schlechten Eingaben, fehlenden Daten, hohen Lasten und falschen Antworten beherrschbar bleiben.
Die gefährlichsten Fehler in AI-Automatisierung sind die stillen
Ein grüner Pipeline-Status beweist nicht, dass ein Kontrollmechanismus wirkt. Wie Teams erkennen, dass Hooks, Checks, Evaluierungen oder Deployments den falschen Gegenstand prüfen – oder längst nur noch Kulisse sind.
Zwei grüne PRs können zusammen ein rotes System ergeben
Git erkennt kollidierende Zeilen, nicht kollidierende Bedeutungen. Warum parallele Worktrees und Agenten-Streams semantische Konflikte erzeugen – und welche Architektur-, Test- und Integrationsmechanismen dagegen helfen.
Warum ich AI-Agenten nicht mehr glaube, wenn sie sagen: „Alles ist grün“
Ein Agentenbericht ist ein Befund, kein Beweis. Für AI-gestützte Entwicklung braucht es Evidenzketten: Commit-SHA, Testartefakte, Logs und reproduzierbare Checks auf einem eindeutig identifizierten Stand.
Der Monolith ist nicht das Problem. Der schlechte Monolith ist es.
Viele Teams zerlegen Systeme zu früh. Ein modularer Rails-Monolith mit klaren Domänengrenzen ist oft günstiger, einfacher zu betreiben und robuster als eine verteilte Architektur.
Der größte Hebel bei Coding Agents ist nicht das Modell, sondern der Kontext
Ein leistungsfähiges Modell rettet keinen überladenen Prompt. Warum Kontextarchitektur über Qualität, Kosten und Verlässlichkeit von Coding Agents entscheidet – und wie Teams Wissen gezielt verteilen.
Wenn die Mutation überlebt: Warum nicht der Test fehlt, sondern der Code weg muss
Überlebt eine Mutation im Testlauf, lautet der Reflex meist: Test nachschärfen. Doch oft ist der Code selbst das Problem. Mutation Testing entlarvt wirkungslose Guards, tote Pfade und scheinbare Sicherheitsnetze, die Systeme nur verkomplizieren.
Warum Ruby on Rails durch AI nicht weniger, sondern interessanter wird
Wenn Code-Generierung billig wird, explodieren die Integrationskosten fragmentierter Stacks. Warum Ruby on Rails und Convention over Configuration gerade für AI-Agenten der ideale Unterbau sind.
AI-Agenten skalieren auch schlechte Prozesse
Mehr parallele Coding-Agents lösen keine Koordinationsprobleme. Ohne klare Schnittstellen, Review-Gates und deterministische Tests vervielfachen autonome Systeme nur eines: den Review-Overhead für erfahrene Engineers.
Bevor du eine Rails-Codebase übernimmst, miss diese fünf Dinge
Ob Projektübernahme, Teamwechsel oder Akquise: Wer eine fremde Rails-Codebase erbt, verlässt sich meistens auf einen ersten Eindruck. Diese fünf Messpunkte zeigen in wenigen Stunden, wie teuer die Übernahme wirklich wird.
Die teuerste Zeile Code in Rails ist die, die du nicht siehst
N+1-Queries entstehen nicht durch schlechten Code, sondern durch ActiveRecords größte Stärke: dass man Assoziationen laden kann, ohne über die Datenbank nachzudenken. Genau das macht sie so schwer zu finden – und so teuer im Betrieb.
Bevor du deine erste Kundin onboardest, triff diese Architekturentscheidung
Row-Level, Schema-per-Tenant oder Datenbank-per-Tenant: Die Multi-Tenancy-Strategie einer Rails-SaaS-Anwendung lässt sich am ersten Tag in einer Stunde entscheiden – oder Monate später mit einer riskanten Migration nachrüsten.
Jede Gem ist eine Wette auf die Zukunft eines fremden Repos
Rails lebt von seinem Gem-Ökosystem – das ist Stärke und Risiko zugleich. Wer eine Gem in eine Produktionsanwendung einbaut, importiert nicht nur Code, sondern auch dessen Wartungszustand, Maintainer-Verfügbarkeit und Lizenzlage.