Ich hatte einen Blogpost eine Woche im Voraus terminiert. Die Post-Seite prüft das Datum und ruft notFound(), Sitemap und RSS filtern beide darauf — für mich war die Sache damit unsichtbar.

Dann habe ich den Build-Output nach einem Satz aus dem unveröffentlichten Post durchsucht und ihn auf /en/work gefunden.

Was tatsächlich passiert

next-intl schreibt den kompletten Message-Katalog in den RSC-Payload jeder Seite. Meine Blog-Inhalte liegen in messages/en.json und messages/de.json, also lieferte jede Seite den Volltext jedes Artikels aus, auch den des Posts, den es noch nicht geben sollte.

Die Routen-Sperre tut, was sie soll: 404. Nur hat sie nichts damit zu tun, ob der Text in der Antwort steht. Der kommt über den NextIntlClientProvider im Layout, nicht über die Seite.

Wer den Quelltext öffnet, liest alles. Jeder Crawler ebenfalls.

Der Fix

Die Messages in i18n/request.ts filtern, bevor sie bei getMessages() ankommen:

function withoutScheduledPosts(messages: Messages, now: Date): Messages {
  const scheduled = posts
    .filter((post) => new Date(`${post.publishDate}T00:00:00`) > now)
    .map((post) => post.translationKey);

  if (scheduled.length === 0) return messages;

  const articles = { ...messages.blog?.articles };
  for (const key of scheduled) delete articles[key];

  return { ...messages, blog: { ...messages.blog, articles } };
}

Danach enthielten 0 von 44 gebauten HTML-Dateien den geplanten Post. An den veröffentlichten Inhalten hat sich nichts geändert.

Zwei Dinge, die der Filter nicht abdeckt

Statische Dateien unter public/. Ich pflege eine llms-full.txt, in der jeder Post mit URL und Zusammenfassung steht. Da kommt der Filter nicht hin, das ist eine flache Datei. Den Eintrag habe ich von Hand entfernt; er kommt am Release-Tag zurück.

Static Generation. Der Filter läuft zur Render-Zeit, bei SSG fällt die Entscheidung also beim Build. Ein geplanter Post braucht einen Deploy am Termin oder danach, sonst erscheint er nicht. Das galt schon vorher für die Publish-Sperre — der Filter macht es nicht schlimmer, aber man sollte es wissen, bevor man darauf wartet, dass ein Post von allein auftaucht.

Warum ich das auch ohne geplante Posts prüfen würde

Die allgemeine Form: Eine Routen-Sperre versteckt eine Seite, aber die Daten, die diese Seite rendert, kommen über einen Provider, der von der Sperre nichts weiß. Alles, was in deinem i18n-Katalog liegt, liegt damit auf jeder Seite, dauerhaft — Entwürfe, interne Texte, Feature-Flag-Strings, unveröffentlichte Produktnamen.

Die Prüfung ist ein Befehl gegen den Build-Output. Grep nach einem Satz, der nicht öffentlich sein darf, und sieh nach, wie viele Dateien zurückkommen.

Gefunden habe ich das beim Terminieren eines Posts über bewertete Agenten-Loops. Die Ironie eines Lecks im Terminierungsmechanismus ist mir nicht entgangen.

1a:T1c1e,

Ich wollte eine eigene Schrift. Was ich nicht wollte, war ein Jahr Zeichnen. Also habe ich dort angefangen, wo die Lizenz es erlaubt: Geist steht unter der SIL Open Font License 1.1, und die OFL existiert genau dafür — Ableitungen sind ausdrücklich vorgesehen, solange die Herkunft mitgeliefert wird.

Das hier ist also keine Schrift, die ich gezeichnet habe. Es ist eine, die ich neu gebaut habe. Und das Interessante daran war am Ende nicht das Zeichnen.

Was tatsächlich geändert wurde

Ein Rebranding wäre gewesen: Familie umbenennen, ausliefern, fertig. So lief es nicht. Proportionen, x-Höhe, Zeichenbreiten, Laufweite und Kerning wurden neu kalibriert, und die Kombinationen, die als Erstes auffallen, gingen durch mehrere Runden:

O und o, wo eine Ableitung zuerst aus dem Gleichgewicht kippt
m, i und n, weil der Rhythmus in kleinen Graden genau daran hängt
Ziffern und die Zeichen, auf die Interfaces tatsächlich angewiesen sind

Jedes davon wurde visuell und technisch korrigiert, mehrfach. Was ausgeliefert wird:

Achse	Was drin ist
Schnitte	Regular 400, Medium 500, SemiBold 600, Bold 700
Formate	TTF, OTF, WOFF2, dazu kleinere Latin-Subsets fürs Web
Abdeckung	Erweitertes Latein, Vietnamesisch, Kyrillisch, UI-Symbole
OpenType	Ziffernfunktionen, inklusive tabellarisch
Abhängigkeiten	Keine, auch keine Peer Dependencies, seit 0.6.1

Der Teil, den niemand sieht, bis er kaputt ist

Wer Konturen ändert, macht alles ungültig, was daran ausgerichtet war. Das GPOS-Kerning musste neu gebaut werden, ebenso die Mark-to-Base-, Mark-to-Ligature- und Mark-to-Mark-Anker — jeder Akzent, jedes diakritische Zeichen neu verankert an Konturen, die sich verschoben hatten.

Drei weitere Dinge, die in keinem Specimen auftauchen:

Combining Marks behalten eine Advance Width von null. Stimmt das nicht, bekommt akzentuierter Text stillschweigend Abstände, die niemand bestellt hat.
Die vertikalen Metriken vermeiden Clipping unter Windows. Verschiedene Plattformen lesen verschiedene Metrik-Felder; die falsche Kombination schneidet Oberlängen auf einem System ab und sieht bei dir tadellos aus.
TTF und WOFF2 sind für kleine Grade gehintet. Eine Schrift, die bei 48 px souverän wirkt, kann in einer Tabellenzelle bei 12 px auseinanderfallen.

Nichts davon ist auf dem Poster zu sehen, das man postet. Alles davon ist in einem Formularfeld zu sehen.

Wie Software behandelt

Hier liegt die Verschiebung, die das Projekt getragen hat. Schriftprojekte werden üblicherweise über Specimen begutachtet — Seite rendern, Augen zusammenkneifen, nachjustieren. Das erwischt, worin das Auge gut ist, und übersieht den Rest.

Die Release-Kriterien sind deshalb Prüfungen, keine Eindrücke:

FontBakery meldet weder FAIL noch FATAL noch ERROR, in TTF und OTF. Nicht „weitgehend sauber" — null.
Neun Playwright-Checks decken die Darstellung von 10 bis 18 Pixeln ab, dazu Baselines, Überlauf, tabellarische Ziffern und visuelle Regression, in Chromium, Firefox und WebKit.
Der Build ist reproduzierbar, ein Release also etwas, das man neu erzeugen kann, statt etwas, das man auf einer Platte findet.

Für das Band von 10 bis 18 Pixeln würde ich am lautesten argumentieren. Dort steht Interface-Text tatsächlich, und genau diesen Bereich zeigt eine Specimen-Seite nie.

Packaging gehört zum Entwurf

Die Schrift liegt als zutat-font auf npm und als vollständiges GitHub-Release, Quellcode und Build-Pipeline sind öffentlich. Das Paket enthält vier komplette WOFF2-Dateien, vier Latin-Subsets, Next.js-Wrapper, TypeScript-Typen und Plain-CSS-Exports.

Seit 0.6.1 hat es keine Dependencies und keine Peer Dependencies, besteht npm audit ohne Findings und wird über GitHub Trusted Publishing mit Provenance ausgeliefert.

Der letzte Punkt wiegt schwerer, als er klingt. Ein Font-Paket ist ein Supply-Chain-Artefakt wie jedes andere. Wer eines in eine Produktiv-App holt, sollte nachvollziehen können, woher die Datei stammt.

Was die AI gemacht hat, und was nicht

Die mechanische Hälfte hat die AI getragen: Konturen transformieren, Varianten erzeugen, sich durch repetitive Korrekturen arbeiten, schneller als ich von Hand.

Entschieden hat sie nichts. Welche von vier o-Varianten neben einem n richtig sitzt, ob die Laufweite bei 11 px zu eng liest, wann eine Korrektur weit genug gegangen ist — das blieb jedes Mal eine Urteilsfrage, und dorthin ging der Großteil der Runden.

Ehrlich zusammengefasst: Die AI hat die Kosten pro Iteration gedrückt, wodurch ich mehr Runden gedreht habe, als ich sonst gedreht hätte. Die Notwendigkeit, dass jemand hinsieht und eine Meinung hat, hat sie nicht abgeschafft.

Was das nicht klärt

Es ist eine Ableitung, und das ist eine echte Einschränkung. Von Geist aus zu starten hieß, Entscheidungen zu erben, die ich nicht getroffen habe. Ein Teil der Kalibrierung war Arbeit gegen das Original statt mit ihm.
Saubere Toolchain ist nicht dasselbe wie gute Schrift. Ein bestandener FontBakery-Lauf sagt, dass die Datei wohlgeformt ist, nicht dass die Buchstaben taugen. Das sind zwei Fragen, und nur für eine gibt es einen Prüfer.
Eine Familie, ein Gestalter, keine Kritik. Schrift wird besser, wenn Leute draufschauen, die selbst Schrift zeichnen. Meine hat das nicht durchlaufen.

Next

Was ich daraus in jede Gestaltungsarbeit mitnehmen würde:

Specimen schmeicheln. Teste in den Graden, in denen die Sache benutzt wird.
Ein Release-Kriterium, das nicht durchfallen kann, ist keins.
Packaging, Provenance und Audit-Status gehören zum Artefakt, nicht zum Papierkram danach.
AI verkürzt die Schleife zwischen Versuchen. Den Geschmack, der zwischen ihnen auswählt, liefert sie nicht — dieselbe Trennung, nach der ich Modelle route.

Offen sind variable Schnitte. Alles oben ist statisch, und eine variable Achse würde die ganze Metrik- und Hinting-Geschichte deutlich schwerer machen. Ob sich das lohnt, habe ich noch nicht entschieden.

Falls du selbst eine Schrift ausgeliefert hast, oder eine Ableitung: Mich würde interessieren, wie deine Release-Checkliste aussieht, und ob darauf je etwas angeschlagen hat, das dein Auge schon abgenickt hatte.

1b:T1eef,

Jedes Design System hat eine Progress Bar. Ein abgerundetes Rechteck, das sich von links nach rechts füllt, und in den meisten Systemen endet das Nachdenken genau dort.

Merkwürdig eigentlich. Es ist eine der wenigen Komponenten, deren ganze Aufgabe darin besteht, jemandem, der wartet, eine Zahl mitzuteilen. Das ist ein echtes Gestaltungsproblem, und die Antwort, die alle ausgeliefert haben, ist ein Rechteck.

Ich baue seit einer Weile an einem kleinen Satz Progress- und Datenkomponenten, um zu sehen, was passiert, wenn man das Rendering ernst nimmt und alles andere in Ruhe lässt.

Gleiche Semantik, anderes Bild

Die Komponente stellt drei Renderer hinter einer API bereit. Ein variant-Prop wählt zwischen einer geflochtenen Welle, einem Ordered-Dither-Feld und einer geschichteten Dither-Fläche. Sonst ändert sich nichts.

Diese Einschränkung ist der eigentliche Entwurf. Ein Renderer-Wechsel darf nicht ändern:

role="progressbar" am Element
aria-valuenow — vorhanden bei bekanntem Wert, abwesend sonst
den Wert, die Grenzen, oder wie ein Screenreader das ansagt

Ein Screenreader kann nicht erkennen, welcher Renderer aktiv ist, und soll es auch nicht können. Das Visuelle ist eine Darstellungsentscheidung über einer Komponente, deren Vertrag sich nicht bewegt. Dieselbe Trennung, nach der ich auch Modellarbeit verteile: Entscheiden und Darstellen sind zwei Aufgaben.

Geprüft wird das im Indeterminate-Fall. Ein Zustand unbekannter Dauer muss aria-valuenow vollständig weglassen — eine erfundene Prozentzahl anzusagen ist schlimmer als gar nichts, während der Renderer weiterläuft. Die beiden Belange müssen wirklich getrennt sein, sonst hast du eine geschäftig wirkende Welle und einen Screenreader, der 0 % behauptet.

Die Zahlen, sonst ist das Dekoration

Eine Komponente, die dauerhaft auf einem Canvas animiert, lädt zu einer berechtigten Frage ein: Was kostet das? Im Repository liegen deshalb ein Bundle-Audit und ein Browser-Benchmark, die bei jeder Änderung laufen.

Prüfung	Ergebnis
Komponenten-JS	7.834 Bytes gzip
Komponenten-CSS	2.575 Bytes gzip
Gesamt	10.409 Bytes gzip
50 Wave-Instanzen	120 FPS Mittel
50 Dither-Instanzen	120 FPS Mittel
50 Dither-Instanzen mit Assembly-Effekt	120 FPS Mittel
50 Indeterminate-Instanzen	120 FPS Mittel

Ein Detail am Benchmark wiegt schwerer als die Zahl selbst: Er hält alle fünfzig Instanzen sichtbar und hovert eine davon während der Messung, damit der aktive Geometrie-Morph im Frame-Budget steckt. Ein Benchmark über fünfzig ruhende Komponenten sagt fast nichts — teuer ist der Frame, in dem sich etwas ändert.

React ist die einzige Laufzeit-Abhängigkeit, die die installierte Komponente mitbringt.

Zwei Dinge, die verhindern, dass es mehr kostet als nötig

Instanzen außerhalb des Sichtfelds pausieren. Eine Komponente, die unterhalb des Falzes animiert, verbrennt Frames für niemanden. Phase und Indeterminate-Animation stoppen, sobald die Instanz nicht sichtbar ist — erst das macht fünfzig gleichzeitige Instanzen zu einem Benchmark statt zu einer Warnung.

Reduced Motion ist ein getesteter Pfad, kein Kommentar. Es ist ein Unterschied, ob man prefers-reduced-motion beachtet — die Media Query, oder ob ein Test fehlschlägt, sobald man aufhört, es zu beachten. Im Repository liegt die zweite Variante.

Quellcode statt Abhängigkeit

Installiert wird über die shadcn-Registry, die Dateien landen also in deinem Repository statt hinter einer Versionsnummer:

npx shadcn@latest add https://example.com/r/wave-progress.json

Die Registry ist noch nicht veröffentlicht, die URL ist also illustrativ und nicht etwas, das du heute ausführen kannst. Bei allem Visuellen finde ich dieses Modell inzwischen richtig. Eine Progress Bar ist genau die Art Komponente, an der ein Team schrauben will — die Wellenamplitude passt nicht zur Marke, die Meilenstein-Beschriftung braucht andere Texte, und gegen ein npm-Paket heißt das entweder Fork oder eine Konfigurationsfläche, die endlos wächst.

Gehört dir der Quellcode, ist die Anpassung ein Diff im eigenen Repo. Der Preis: Updates kommen nicht mehr von allein. Bei einer Komponente dieser Größe würde ich den Tausch machen.

Was ich nicht behaupten würde

Ich weiß nicht, ob es beim Warten hilft. Die Annahme ist, dass ein lesbarerer Fortschrittsanzeiger das Warten erträglicher macht. Das ist eine Annahme. Ich habe es nicht mit Nutzern getestet, und ein 120-FPS-Benchmark sagt nichts darüber, ob die Sache angenehmer anzusehen ist.
Drei Renderer sind Wartungsfläche. Jeder muss den ARIA-Vertrag halten, Reduced Motion überstehen und die Geometrie-Tests nicht brechen. Für eine visuelle Entscheidung sind das laufende Kosten.
Die Zahlen sind lokal. Auf meiner Maschine gemessen, bei jeder Änderung neu, und sie bewegen sich mit der Last. Sie sind eine Größenordnung zum Nachdenken, keine Zusage.

Next

Was sich über diese Komponente hinaus verallgemeinern lässt:

Wie etwas aussieht, darf nicht ändern, was es ansagt. Kann der Renderer die Semantik verschieben, sitzt die Abstraktion an der falschen Stelle.
Benchmarke den teuren Frame. Fünfzig ruhende Instanzen sind keine Messung.
Reduced Motion braucht einen Test, der fehlschlägt — nicht eine Media Query und guten Willen.
Bei visuellen Komponenten schlägt eigener Quellcode eine Konfigurationsfläche, die endlos wächst.
Abnahmekriterien, die durchfallen können, schlagen ein Changelog. Es ist die zweite Sache diesen Monat, die ich gegen eine Messlatte statt gegen einen Termin gebaut habe — die Schrift lief genauso, und in beiden Fällen haben die Kriterien etwas erwischt, das mein Auge schon durchgewunken hatte.

Als Nächstes will ich genau das, von dem ich gerade sagte, dass ich es nicht habe: einen Hinweis darauf, ob ein lesbarerer Anzeiger verändert, wie lang sich eine Wartezeit anfühlt. Das ist eine Nutzerfrage, kein Benchmark, und wie ich sie ehrlich stelle, weiß ich noch nicht.

Falls du eine Standard-Progress-Komponente durch etwas Eigenes ersetzt hast, würde mich interessieren, was dich dazu gebracht hat, und ob es jemandem aufgefallen ist.

3e:I[302847,["/_next/static/chunks/225u9y9y62hte.js","/_next/static/chunks/1skg5sjyr5qzo.js","/_next/static/chunks/2rb3bq9nehl88.js","/_next/static/chunks/1n-1sx_0ke85t.js","/_next/static/chunks/1blgycuzwyhgp.js","/_next/static/chunks/3w6j-d9quekp8.js"],"default"] 3f:I[757590,["/_next/static/chunks/225u9y9y62hte.js","/_next/static/chunks/1skg5sjyr5qzo.js","/_next/static/chunks/2rb3bq9nehl88.js","/_next/static/chunks/1n-1sx_0ke85t.js","/_next/static/chunks/1blgycuzwyhgp.js","/_next/static/chunks/3w6j-d9quekp8.js"],"default"] 40:I[611015,["/_next/static/chunks/225u9y9y62hte.js","/_next/static/chunks/1skg5sjyr5qzo.js","/_next/static/chunks/2rb3bq9nehl88.js","/_next/static/chunks/1n-1sx_0ke85t.js","/_next/static/chunks/1blgycuzwyhgp.js","/_next/static/chunks/3w6j-d9quekp8.js"],"default"] 41:I[27201,["/_next/static/chunks/225u9y9y62hte.js"],"IconMark"] 1c:T1aee,

Ich habe meine privaten Projekte auf Coolify gelegt, weil es schneller stand als alles andere, das ich mir angesehen hatte, und weil ich wissen wollte, wie sich eine selbstgehostete PaaS anfühlt, nachdem ich jahrelang Terraform für andere geschrieben habe. Beides waren gute Gründe. Beides hat es eingelöst.

Inzwischen laufen dort elf Projekte. Mehrere PostgreSQL-Instanzen, Redis, Prometheus, Grafana. Irgendwann dazwischen hörte es auf, ein Experiment zu sein, und wurde das, worauf meine Arbeit steht. Den Übergang habe ich nicht bemerkt.

Bemerkt habe ich, als sich die Frage änderte. Lange lautete sie wie deploye ich das, und darauf antwortet Coolify gut. Jetzt lautet sie wie ziehe ich das um, und das ist eine andere Art von Frage.

Was ein Umzug tatsächlich verlangt

Coolifys eigene Dokumentation ist beim ersten Teil eindeutig: Es gibt keinen eingebauten Weg, Anwendungen von einem Server auf einen anderen zu migrieren. Das ist keine Lücke in der Doku. Die Funktion existiert nicht.

Eine Instanz umzuziehen heißt, vier Dinge von Hand mitzunehmen:

Den coolify-db-Container, in dem die Konfiguration sämtlicher Projekte liegt.
Den APP_KEY aus der .env, weil diese Datenbank damit verschlüsselt und ohne ihn wertlos ist.
Die SSH-Keys, mit denen Coolify deine Server erreicht.
Die authorized_keys, mit denen diese Server ihn akzeptieren.

Volumes sind eine eigene Übung: jedes in einen temporären Container mounten, den Inhalt tarballen, das Archiv herauskopieren, den Container löschen. Danach auf der Gegenseite das Dashboard öffnen und jede Anwendung neu deployen, damit die Container gegen die zurückgespielten Volumes hochkommen.

Nichts davon ist unangemessen für ein Werkzeug dieser Art. Es sagt dir aber, wo die Wahrheit über deine Infrastruktur liegt, und in diesem Fall ist die Wahrheit ein verschlüsselter Postgres-Container plus ein Geheimnis in einer Punktdatei.

Was mir wirklich fehlt

Nicht die Migration.

Das Review.

Ich kann meine Infrastruktur nicht diffen. Es gibt keine Datei, in der elf Projekte beschrieben sind, also gibt es nichts, wogegen man einen Pull Request öffnen könnte, nichts, das man in einem Jahr liest, um herauszufinden, warum ein Container die Umgebungsvariable hat, die er hat, nichts, das man auf einen frischen Host abspielt, um zu sehen, ob es identisch zurückkommt. Die Konfiguration ist echt und sie ist korrekt, und einsehbar ist sie nur, indem man sich Projekt für Projekt durch eine Oberfläche klickt.

Das ist derselbe Defekt in anderem Kostüm. Ein Terraform-State-File für alles ist gefährlich, weil es den Radius jeder Änderung auf den gesamten Bestand ausdehnt. Eine PaaS-Datenbank für alles ist aus dem gespiegelten Grund gefährlich: Es gibt gar keinen Radius, weil es überhaupt keine Änderung zu reviewen gibt.

An Berechtigungen wird es konkret. In Kubernetes ist eine Datei, wer was darf. Eine Role, ein RoleBinding, ein securityContext, eine NetworkPolicy. Man kann sie lesen, diffen, im Review ablehnen und im Incident darauf zeigen. In Coolify sind Berechtigungen das, was die Oberfläche anbietet, ausgedrückt als Zustand einiger Checkboxen, und der einzige Weg, sie zu prüfen, ist hinzugehen und nachzusehen.

Was ArgoCD ändert, und was nicht

Der Grund, warum ich zu Kubernetes mit ArgoCD tendiere, ist nicht, dass Kubernetes Container besser ausführt. Für elf Projekte ist es offensichtlich schlechter: mehr bewegliche Teile, mehr zu patchen, mehr Wege, an einem Sonntag angepiept zu werden.

Es ist, dass GitOps umdreht, wo die Wahrheit liegt. Bei derselben Frage bin ich gelandet, als ich aufgeschrieben habe, was deine Infrastruktur wirklich ausführt, wenn du SST benutzt: Die Schicht, die den Sollzustand hält, ist die Schicht, die du reviewen kannst. Der Sollzustand des Clusters ist ein Repository. Migration hört auf, eine Tarball-Prozedur zu sein, und wird dazu, ein neues Cluster auf dasselbe Repo zu zeigen. Erweitern hört auf, eine Klickfolge zu sein, die sich jemand merken muss, und wird zu einem Diff, den jemand freigeben kann. Rollback ist git revert.

Ich will bei den Kosten ehrlich sein, weil die Fassung dieses Arguments, die man sonst liest, es nicht ist. Du tauschst einen Nachmittag Einrichtung gegen ein System mit echter Lernkurve, und du übernimmst den Betriebsaufwand der Control Plane selbst. Wenn du nur elf Container brauchst, die laufen, ist der Tausch schlecht und Coolify gewinnt auf jeder Achse, die zählt.

Der Tausch lohnt erst, wenn deine Fragen von Änderung handeln statt von Verfügbarkeit. Meine tun das seit einer Weile, und ich war langsam darin, es zu merken.

Wo die Grenze verläuft

Meine ehrliche Einschätzung, nachdem ich auf beiden Seiten stand:

Coolify ist richtig, solange das, was du betreibst, klein genug ist, um es im Kopf zu behalten, und solange du der Einzige bist, der es verstehen muss. Das ist keine Einschränkung, das ist die meiste private Infrastruktur, und eine Oberfläche ist dafür eine wirklich gute Schnittstelle. Das Tempo, das ich am Anfang gekauft habe, war echt, und ich würde es wieder kaufen.

Richtig ist es nicht mehr ab dem Punkt, an dem jemand anderes rekonstruieren können muss, was du gebaut hast. Dieser jemand anderes bist meistens du selbst, achtzehn Monate später, ohne jede Erinnerung an die Checkboxen.

Umgezogen bin ich noch nicht. Ich schreibe das auch, um zu prüfen, ob die Gründe standhalten, wenn ich sie ordne. Bisher tun sie es.

Next

Die Kurzfassung:

Coolify hat keine eingebaute Anwendungsmigration. Ein Instanzumzug heißt: Datenbank-Container, der APP_KEY zum Entschlüsseln, beide Sätze SSH-Keys und jedes Volume von Hand.
Der eigentliche Preis ist nicht die Migration, sondern dass es keine Datei zum Diffen, Reviewen und Abspielen gibt.
Berechtigungen sind in Kubernetes eine Datei, die man im Review ablehnen kann. In einer PaaS sind sie der Zustand eines Formulars.
ArgoCD lohnt seinen Aufwand erst, wenn deine Fragen von Änderung handeln statt von Verfügbarkeit. Für elf Container, die einfach laufen sollen, ist es der falsche Tausch.

Als Nächstes will ich klären, was die Migration tatsächlich an Stunden kostet, gemessen statt geschätzt. Diese Zahl ist das ganze Argument, und ich habe sie noch nicht. Sobald ich sie habe, steht sie hier. Falls du diesen Wechsel mit vergleichbarem Bestand hinter dir hast, würde mich interessieren, was er dich gekostet hat. Jede Schätzung, die ich finde, stammt von jemandem, der eine der beiden Seiten verkauft.

1d:T18f1,

Jedes Infrastrukturwerkzeug ist eine Wette darauf, in welcher Ebene du denken willst. Terraform wettet, dass du Ressourcen beschreiben willst. CloudFormation wettet, dass du AWS’ Vokabular akzeptierst und dafür AWS’ Garantien bekommst. SST wettet, dass du lieber eine Anwendung beschreibst und die Ressourcen daraus folgen lässt.

Interessant an SST ist nicht die Wette, sondern was darunter liegt. In v3 hat sich die Antwort geändert, und die neue führt mitten durch Terraform.

Die Kette, ohne Umschweife

SST v2 übersetzte deine Konfiguration in AWS-CDK-Konstrukte, die in ein CloudFormation-Template übersetzt wurden, das AWS dann ausführte. Drei Übersetzungen zwischen dem, was du geschrieben hast, und dem, was lief.

SST v3, vom Projekt Ion genannt, hat CDK und CloudFormation entfernt und Pulumi an ihre Stelle gesetzt. Pulumi wiederum schreibt die meisten seiner Provider nicht selbst, sondern erzeugt sie über eine Brücke aus Terraform-Providern. Pulumi sagt das unmissverständlich: SST „leverages Pulumi behind the scenes for its providers and deployment engine while also bridging Terraform providers through Pulumi.“

Wenn eine sst.config.ts also einen S3-Bucket anlegt, geht das Schema, gegen das validiert wird, auf denselben Terraform-AWS-Provider zurück, den du bei handgeschriebenem HCL benutzen würdest. Nicht auf einen ähnlichen. Auf denselben, verpackt.

Das ist der Teil, der zählt, wenn du Terraform-Erfahrung hast, und der Teil, den kaum jemand ausspricht: dein Wissen überträgt sich. Argumentnamen, Defaults, die sperrigen Ecken einer Ressource, die du dir mühsam angeeignet hast. Sie überleben den Wechsel, weil der Provider ihn überlebt hat.

Was SST dir tatsächlich bringt

Drei Dinge, und es lohnt sich, sie zu trennen, weil das Marketing sie verschwimmen lässt.

Eine Konfiguration für Infrastruktur und Anwendung. Eine einzige sst.config.ts beschreibt den Bucket, die Funktion, die daraus liest, und das Frontend, das die Funktion aufruft. In Terraform beschreibst du Bucket und Funktion; die Anwendung damit zu verdrahten ist ein separates Problem, das du mit Variablen, Outputs und einem Deployment-Skript löst.
Breite ohne neue Syntax. SSTs Dokumentation nennt über 150 unterstützte Provider, von AWS, Azure und GCP bis zu Cloudflare, Stripe, Vercel und Auth0. Diese Zahl ist eine direkte Folge der Brücke. SST hat nicht 150 Integrationen geschrieben, sondern ein Ökosystem geerbt.
Kein CloudFormation. Als Gründe für den Abschied werden die AWS-Zentriertheit von CDK und CloudFormation genannt sowie, dass das Zwischen-Template „often obscured the underlying logic and made it much more difficult to diagnose and resolve problems“. Wer je eine CloudFormation-Rollback-Meldung gelesen hat, erkennt die Beschwerde wieder. Das Template, das du debuggst, ist nicht der Code, den du geschrieben hast.

Was du aufgibst

Wähle ein Werkzeug danach, was es dich kostet, nicht nur danach, was es dir spart.

Eine zusätzliche Abstraktion im kritischen Pfad. Du hast eine Schicht über den Terraform-Providern gewonnen. Geht etwas kaputt, debuggst du jetzt in drei Vokabularen: SST-Komponenten, Pulumi-Ressourcen und der Provider darunter. Die CloudFormation-Undurchsichtigkeit, vor der SST geflohen ist, ist weniger verschwunden als umgezogen.

Der State gehört wieder dir. CloudFormation hielt ihn auf AWS-Seite, was einschränkend war und zugleich eine Sache weniger, die man verlieren kann. Pulumi-basierter State ist eine Datei in deiner Verantwortung, mit allen Fragen zu Locking und Backup, die daraus folgen. Wer Terraform in Größe betrieben hat, hatte die Diskussion über Remote State schon, und ich habe darüber geschrieben, was es kostet, wenn ein Team sie nie führt: ein State File für alles ist das Anti-Pattern, das irgendwann die Seite umlegt.

Ein kleinerer Arbeitsmarkt. Terraform und HCL sind einer. SST ist ein kleinerer. Das spricht nicht dagegen, aber dafür, die Entscheidung schriftlich zu begründen.

Wo die Grenze verläuft

Die nützliche Frage ist nicht, welches Werkzeug besser ist, sondern für welche Ebene dein Team die Verantwortung tragen will.

Existiert deine Infrastruktur, um eine Anwendung zu bedienen, und sind die Leute, die sie schreiben, dieselben, die sie deployen, dann entfernt SST einen Übersetzungsschritt, der sich nie verdient hat. Die eine Konfiguration ist keine Bequemlichkeit, sondern eine Korrektheitseigenschaft: Funktion und Bucket können nicht auseinanderlaufen, weil sie gemeinsam deklariert sind.

Bedient deine Infrastruktur viele Anwendungen, oder übergibt ein Plattformteam Umgebungen an Produktteams, arbeitet dieselbe Kopplung gegen dich. Dann soll der Bucket ein Leben unabhängig von dem haben, der ihn nutzt. Terraforms Trennung von Ressource und Konsument ist der Zweck, nicht eine Lästigkeit, die man wegabstrahiert.

Die Kette zu kennen lohnt sich in beiden Fällen. Wenn ein SST-Deployment an einem Argument scheitert, von dem du nie gehört hast, steht die Antwort drei Schichten tiefer in der Terraform-Provider-Dokumentation. Seltsames Erbe für ein Werkzeug. Aber ein sehr brauchbares.

Next

Die Kurzfassung:

SST v3 läuft auf Pulumi, und Pulumi erzeugt seine Provider aus denen von Terraform. Das Schema, gegen das validiert wird, ist in beiden Fällen dasselbe.
Terraform-Erfahrung überträgt sich. Argumentnamen, Defaults und die sperrigen Ecken überleben den Wechsel, weil der Provider ihn überlebt.
Du tauschst CloudFormations Undurchsichtigkeit gegen ein drittes Vokabular beim Debuggen, und das State File gehört wieder dir.
Eine Anwendung, ein Team: SST entfernt einen Übersetzungsschritt. Viele Konsumenten hinter einem Plattformteam: halte die Ressource unabhängig von dem, der sie nutzt.

Ungeklärt ist für mich, was aus dem Argument der einen Konfiguration wird, sobald ein zweites Team denselben Bucket braucht. Ab da geht es nicht mehr um Syntax, sondern um Zuständigkeit, und das beantwortet dir keine Vergleichstabelle.

1e:T1eb4,

Ich habe letzten Monat die Terraform-Konfiguration eines Kunden zum ersten Mal geöffnet. Eine einzelne main.tf-Datei mit 1.847 Zeilen. Darin waren ein VPC, drei EC2-Instanzen, eine RDS-Datenbank, zwei S3-Buckets, eine CloudFront-Distribution, eine Route-53-Zone mit 14 Records, eine IAM-Rolle mit Inline-Policy und ein Elastic-Load-Balancer.

Alles in einer Datei. Kein Remote-State. Keine Module. Fest kodierte AMI-IDs, Instanz-Typen und IP-Bereiche in den Ressourcenblöcken. Das State-File lag im Home-Verzeichnis des CTO auf seinem Laptop. Er war die einzige Person, die Terraform ausführen konnte, und er tat es, indem er terraform apply ohne Plan laufen ließ.

Das ist kein Ausreißer. Acht von zehn Startups, die ich auditiere, haben drei oder mehr dieser Muster. Jemand hat die Infrastruktur einmal eingerichtet, als das Unternehmen drei Leute hatte. Niemand hat sie überarbeitet.

1. Monolithischer State

Die 1.847-Zeilen-Datei meines Kunden hat ein einziges State-File produziert, das jede Ressource in ihrer gesamten Infrastruktur verfolgt. Wenn sie die DNS-Records aktualisieren wollten, betrachtete Terraform jede einzelne Ressource, auch die Datenbank, auch den Load Balancer, auch die EC2-Instanzen.

Die Planausführung dauerte 4 Minuten. Jede Änderung, egal wie klein, erzeugte einen Plan, der die gesamte Infrastruktur abdeckte. Die Blast-Radius einer falschen terraform apply war alles. Ein Tippfehler in einer Sicherheitsgruppe konnte die Datenbank betreffen, weil alles im selben State lag.

Aufteilen nach Schicht. Netzwerk in einem State. Compute in einem zweiten. Datenbank in einem dritten. DNS in einem vierten. Jeder State hat seinen eigenen Blast-Radius.

2. Lokaler State

Das State-File ist Terraforms Aufzeichnung darüber, wie deine Infrastruktur aktuell aussieht, und es enthält sensible Daten. Datenbank-Passwörter, API-Keys, Verbindungsstrings. Alles im Klartext. Wenn das State-File auf dem Laptop eines Entwicklers liegt, sind diese Secrets genau so sicher wie dieser Laptop. Wenn der Laptop gestohlen wird, verloren geht oder einfach von jemand anderem genutzt wird, sind deine Infrastruktur-Secrets kompromittiert.

Remote State mit einem S3-Backend und DynamoDB-Locking behebt das. Das State-File liegt in einem verschlüsselten Bucket. DynamoDB verhindert gleichzeitige Änderungen. Mehrere Entwickler können Terraform ausführen, ohne sich gegenseitig die Änderungen zu überschreiben.

Die Einrichtung dauert 30 Minuten. Die Migration vom lokalen zum Remote State ist ein einzelner terraform init -migrate-state-Befehl. Bester ROI aller Fixes in diesem Artikel.

3. Keine Module

Wenn du drei EC2-Instanzen hast und jede 45 Zeilen kopierter Konfiguration hat, hast du drei Stellen, an denen du Änderungen vornehmen musst, wenn sich der Instanztyp ändert. Wenn du die zweite aktualisierst, aber die dritte vergisst, weichen deine Instanzen voneinander ab, ohne dass jemand es merkt.

Module lösen das. Ein Modul definiert ein Muster (eine EC2-Instanz mit Sicherheitsgruppe, EBS-Volume und Tags), du rufst es dreimal mit unterschiedlichen Parametern auf, und wenn sich der Instanztyp ändert, änderst du ihn einmal im Modul. Eine Stelle statt drei. Kein Drift zwischen den Instanzen, kein Vergessen der dritten Kopie um 17:30 am Freitag.

Die Versuchung ist, sofort ein riesiges Modulverzeichnis zu bauen. Mach das nicht. Fang mit dem Pattern an, das du am häufigsten kopierst. Für die meisten Startups ist das eine "Webservice"-Modulgruppe: EC2 oder ECS-Taskdefinition, Security Group, Target Group, ALB-Listener-Rule. Refaktoriere ein existierendes Beispiel in ein Modul und ersetze die Kopien.

4. Fest kodierte Werte

Fest kodiert direkt in den Ressourcenblöcken landen typischerweise:

AMI-IDs
Instanztypen
CIDR-Blöcke
Kontonummern

Das steht dann so im Code. Das funktioniert, bis du eine zweite Umgebung brauchst. Dann kopierst du alles, änderst die fest kodierten Werte, verpasst zwei, und deine Staging-Umgebung hat denselben CIDR-Block wie Produktion.

Variablen mit umgebungsspezifischen .tfvars-Dateien lösen das. variables.tf definiert, was konfigurierbar ist. prod.tfvars und staging.tfvars liefern die umgebungsspezifischen Werte. Der Terraform-Code selbst ist identisch für beide Umgebungen.

Unveränderliche Werte (AWS-Region, Standard-Tags) in locals. Umgebungsspezifische Werte (Instanzgröße, Replikaanzahl, Domain) als Variablen.

5. Keine Drift-Erkennung

Drift ist die Lücke, die entsteht, wenn Infrastruktur außerhalb von Terraform verändert wird. Du hast alles in Terraform definiert. Aber am Mittwoch hat jemand die Sicherheitsgruppe manuell in der AWS-Konsole geändert, weil ein Debugging-Issue Zugriff auf einen bestimmten Port brauchte. Sie haben vergessen, es nach dem Debugging zurückzusetzen. Jetzt stimmt dein Terraform-State nicht mehr mit der Realität überein.

Führe terraform plan in einem wöchentlichen CI-Cronjob aus. Wenn der Plan Änderungen zeigt, die niemand erwartet, hat jemand etwas manuell geändert. Untersuche und bringe den Code mit der Realität in Einklang (entweder die manuelle Änderung in Terraform übernehmen oder die manuelle Änderung rückgängig machen).

Fünf Minuten pro Woche. Verhindert das Szenario, in dem ein terraform apply drei manuelle Änderungen rückgängig macht, die niemand dokumentiert hat, und einen Ausfall in der Produktion verursacht, der den gesamten Freitagnachmittag ruiniert.

Der gemeinsame Nenner

Alle fünf sind Probleme des Infrastrukturmanagements, keine Terraform-Probleme. Terraform ist nicht opinionated genug, um sie zu verhindern, also passieren sie standardmäßig bei jedem Unternehmen, das schneller wächst als seine Infrastruktur-Praktiken reifen.

Alle fünf in einer bestehenden Codebase zu fixen dauert ein bis zwei Wochen fokussierte Arbeit. Sie in einem neuen Projekt zu verhindern dauert ungefähr zwei Stunden initialen Setup. Der Unterschied in den laufenden Wartungskosten ist enorm.

Die fünf nebeneinander

Anti-Pattern	Was es kostet	Der Fix
Ein State File für alles	Blast Radius: ein Tippfehler in einer Security-Group kann die Datenbank treffen	State pro Umgebung und pro abgegrenzter Domäne trennen
Kein Remote Backend	State auf einem Laptop. Kein Locking, keine Historie, parallele Applies zerstören ihn	Remote Backend mit Locking und Versionierung
Keine Module	Derselbe Block pro Umgebung kopiert, driftet still auseinander	Wiederkehrende Form in ein Modul ziehen, Unterschiede parametrisieren
Hardkodierte Werte	Umgebungsunterschiede leben in Kopien statt in Variablen	Variablen und tfvars pro Umgebung
Keine Drift-Erkennung	Konsolen-Änderungen sammeln sich, bis ein Apply etwas Beunruhigendes vorschlägt	Geplantes `terraform plan -detailed-exitcode` in CI

Wenn du nur eines davon machst: das Remote Backend. Alles andere ist reparierbar; ein zerschossenes lokales State File bei einem parallelen Apply ruiniert die Woche. Und wenn deine Pipeline zusätzlich agentengenerierte Änderungen verarbeitet, gilt das Argument noch stärker, was das mit den CI-Fehlerraten macht, habe ich separat untersucht.

1f:T1b68,

Jede Erklärung eines Sprachmodells fängt gleich an: Es sagt das nächste Token voraus. Diesen Satz habe ich unzählige Male gelesen und jedes Mal genickt.

Dann wollte ich mir selbst erklären, warum ein Modell bei niedriger Temperature anfängt sich zu wiederholen, und merkte: aufsagen ja, herleiten nein.

Das ist bei mir meistens ein Zeichen dafür, dass ich die Form einer Erklärung auswendig kann und den Mechanismus darunter nicht. Worum es in diesem Post am Ende auch geht.

Also habe ich das kleinste Modell gebaut, das dasselbe Problem hat. Es steht unten auf dieser Seite, läuft komplett im Browser und besteht aus rund achtzig Zeilen Zählerei.

Das ganze Modell ist ein Durchlauf Zählen

Geh Wort für Wort durch einen Text. An jeder Stelle notierst du drei Dinge:

welches Wort auf die zwei Wörter davor folgte — die kleine → Katze
welches Wort auf das eine Wort davor folgte — kleine → Katze
welches Wort das hier ist, ganz ohne Kontext

Diese drei Tabellen sind das komplette Modell. Keine Gewichte, keine Gradienten, nichts, was sich nach dem Durchlauf noch ändert. Training ist eine einzige Schleife über den Text — deshalb kann die Figur unten bei jedem Tastendruck neu trainieren.

Vorhersagen heißt nachschlagen. Erst der spezifischste Kontext, also die Zwei-Wort-Zeile. Kennt das Modell die nicht, fällt es auf die Ein-Wort-Zeile zurück. Fehlt die auch, bleibt die reine Worthäufigkeit.

Backoff hatte ich mir nie wirklich vorgestellt

Den Begriff kannte ich. Gesehen hatte ich ihn nie.

Die Figur schreibt dazu, welche Tabelle geantwortet hat und auf welchem Kontext. Damit kann man beim Abrutschen zusehen. Tipp eine Wendung ein, die im Text vorkommt, und du bekommst eine Trigram-Antwort mit zwei, drei Kandidaten und einer scharfen Verteilung. Ändere ein Wort, und es fällt auf die Bigram-Zeile: plötzlich viel mehr Kandidaten, viel flacher verteilt. Noch einen Schritt weiter landest du beim Unigram, das nur noch sagt „hier sind die häufigen Wörter", und die Ausgabe hat mit deiner Eingabe nichts mehr zu tun.

Dieses Gefälle hatte ich so noch nie gesehen: erst spezifisch und sicher, dann allgemein und vage, dann bedeutungslos. Ein echtes Modell fällt nicht in solchen Stufen zurück, und ich will die Analogie nicht überdehnen. Aber die Richtung stimmt: Wo nichts Spezifisches da ist, wird die Ausgabe generisch, bevor sie falsch wird.

Es gibt keine richtige Temperature

Temperature ist eine Zeile Code. Jede Zählung hoch 1/T, dann normalisieren. Kleines T macht die Verteilung um den Spitzenwert herum scharf, großes T zieht sie flach, bis seltene Wörter eine echte Chance bekommen.

Der Regler macht sichtbar, dass beide Enden kaputt sind, nur gegenläufig:

Bei 0,05 nimmt das Modell immer den höchsten Zählwert. Sample ein paar Mal hintereinander und es läuft in einen Zyklus und bleibt drin. Es ist nicht verwirrt. Es tut genau das, was du verlangt hast: immer den sichersten Schritt.
Bei 1,8 wird ein Wort, das einmal im Text steht, fast so oft gezogen wie eines, das zehnmal drinsteht. Jede einzelne Entscheidung ist zulässig, der Absatz ist Unsinn.

Ich war halb davon ausgegangen, niedrige Temperature sei die genaue Einstellung und hohe die kreative. Treffender ist: Es steuert, wie viel von der Verteilung du überhaupt benutzt, und der brauchbare Bereich liegt aus Gründen in der Mitte, die mit Genauigkeit nichts zu tun haben.

Der Begriff kommt nicht zufällig aus der Physik. Dieselbe Gleichungsform steuert in der Boltzmann-Verteilung, wie oft ein System höhere Energiezustände besucht. So ein Detail hätte ich vor einer Woche überlesen.

Das Spielzeugmodell ist der Memorisierungsfehler

Das ist der Teil, für den sich der Abend gelohnt hat.

Gib dem Zählmodell einen großen Korpus, und seine Trigram-Tabelle wird sehr gut auf genau diesem Korpus und lernt nichts, was sie irgendwo anders hin mitnehmen könnte. Sie kann nicht generalisieren, weil nichts darin das könnte. Sie ist eine Lookup-Tabelle im Kostüm einer Wahrscheinlichkeitsverteilung.

Vor ein paar Tagen habe ich dasselbe auf ganz anderer Ebene beschrieben: was passiert, wenn du einen Agent-Loop bewertest statt ihn zu reviewen, und der Loop anfängt, das Eval zu optimieren statt das Problem. Ein System, das auf der Menge, auf die es abgestimmt wurde, perfekt abschneidet und umkippt, sobald sich die Oberfläche ändert — das war der Fehler, den ich dort beschrieben habe. Dieses Achtzig-Zeilen-Modell ist dieser Fehler, dauerhaft und bauartbedingt.

In einer Form, die man am Stück lesen kann, wird die große Variante deutlich weniger abstrakt. Der Probe Gap, den ich auf Agent-Runs anwende, ist in einem Satz: ein Test darauf, ob das Ding zu einem n-Gram-Modell meines Eval-Sets geworden ist. Diesen Satz hatte ich vorher nicht.

Was das hier nicht ist

Deutlich gesagt, weil dieses Genre die Lücke gern überspielt:

Keine Attention. Dieses Modell sieht zwei Wörter zurück, immer. Das Transformer-Paper von 2017 gibt es, weil diese Grenze tödlich ist und weil die sequenziellen Alternativen, die sie behoben, langsam zu trainieren waren.
Kein Lernen. Nichts wird an irgendwas angepasst. Zählen ist kein Training, auch wenn ich es dauernd so nenne.
Kein Tokenizer. Ich trenne an Leerzeichen und nenne die Stücke Wörter. Echte Modelle machen das nicht, und das fällt mehr ins Gewicht, als ich dachte.

Neuland ist das alles auch nicht. Andrej Karpathys makemore geht denselben Weg gründlicher, und dahin würde ich jeden zuerst schicken. Gebaut habe ich es trotzdem selbst, weil eine Implementierung zu lesen und eine zu schreiben zwei verschiedene Tätigkeiten sind, und nur eine davon hat mir gesagt, dass ich Temperature nicht verstanden hatte.

Next

Tokenization, gleiche Behandlung: Byte-Pair-Encoding implementieren, in die Seite stellen und herausfinden, was es kostet, in einer Sprache zu schreiben, die die Merge-Schleife kaum gesehen hat.

Danach würde ich gern etwas Echtes und Kleines trainieren und den Bewertungsapparat aus meinem Agenten-Setup darauf richten. Das Vokabular ist offensichtlich dasselbe, und mich interessiert, ob die Instinkte es auch sind.

Ich hätte erwartet, dass mir Attention fehlt. Es war Temperature. Falls du selbst mal so etwas gebaut hast: Was hat dir das Schreiben gesagt, was das Lesen nicht gesagt hatte?

20:T187a,

Jede Zahl, die man zu einem Modell bekommt, ist in Tokens angegeben. Kontextfenster, Preis pro Million, Rate Limit. Ich hatte mir „ein Token sind ungefähr vier Zeichen" gemerkt, damit überschlagen und nie genauer hingeschaut.

Dann habe ich Byte-Pair-Encoding implementiert, als Ergänzung zum Zählmodell aus dem letzten Post, einen deutschen Satz eingetippt, und die Tokenzahl ging irgendwo hin, wo ich sie nicht erwartet hatte.

BPE ist eine Schleife, die das häufigste Paar zusammenzieht

Am Anfang ist jedes Wort eine Liste einzelner Zeichen. Dann wiederholt sich das hier:

Zähle im gesamten Korpus jedes benachbarte Symbolpaar.
Such das häufigste.
Zieh es überall zusammen, sodass daraus ein Symbol wird.

Jede Runde fügt dem Vokabular genau einen Eintrag hinzu. Dreißig Runden auf einem Absatz ergeben Fragmente wie th, the, ing. Fünfzigtausend Runden auf einem großen Korpus ergeben die meisten gängigen englischen Wörter als einzelne Tokens.

Das ist der ganze Algorithmus. Eingeführt wurde er für maschinelle Übersetzung in Sennrich et al., 2015, und er steckt bis heute unter den gebräuchlichen Tokenizern, mit reichlich Technik drumherum.

Beim Kodieren werden diese Merges in ihrer Lernreihenfolge wieder abgespielt. Das Vokabular ist also kein Wörterbuch, das jemand kuratiert hat, sondern eine Fossilienschicht dessen, was im Trainingskorpus häufig war.

Was ich nicht verstanden hatte: Vertrautheit ist der Preis

Die Figur unten auf dieser Seite trainiert auf einem editierbaren Korpus und kodiert, was du eingibst. Zwei Dinge sieht man nach ungefähr einer Minute Spielen.

Wörter, die der Korpus oft gesehen hat, fallen auf ein oder zwei Tokens zusammen. Wörter, die er nie gesehen hat, zerfallen in Einzelzeichen, weil kein Merge je bei ihnen angekommen ist. In der Voreingabe steht kitten, das im Trainingstext nicht vorkommt — man kann zusehen, wie es neben the und little auseinanderfällt.

Eine Wortanfangs-Markierung ändert alles. Echte Tokenizer halten the am Wortanfang von denselben drei Buchstaben mitten im Wort getrennt. Deshalb springen Tokenzahlen, wenn du in einem Prompt an Leerzeichen oder Zeichensetzung etwas änderst. Das Verhalten war mir vorher aufgefallen, ohne dass ich einen Grund dafür hatte.

Kosten hängen also nicht daran, wie lang dein Text ist, sondern daran, wie sehr er dem Korpus ähnelt, auf dem die Merges gelernt wurden.

Und genau da wird Deutsch teuer

Ich schreibe diesen Blog auf zwei Sprachen. Gleiche Argumente, gleicher Aufbau, ungefähr gleich viele Zeichen. Dass die beiden für ein Modell nicht gleich groß sind, war mir nie in den Sinn gekommen.

Deutsch macht zwei Dinge, mit denen eine überwiegend auf Englisch gelernte Merge-Schleife schlecht zurechtkommt. Es baut Komposita — ein langes Wort, wo Englisch drei kurze nimmt, und diese Komposita sind einzeln selten, auch wenn jeder Bestandteil häufig ist. Und es hat Zeichen, die schlicht seltener vorkommen, also gehen weniger Merges für sie drauf.

Die Richtung sieht man in der Figur. Wie viel Gewicht das trägt, will ich allerdings sauber einordnen: Mein Spielzeug trainiert auf drei Zeilen Text und übertreibt deshalb. Ein produktiver Tokenizer hat erheblich mehr Deutsch gesehen und kommt deutlich besser damit klar.

Der Effekt selbst ist aber real und gemessen, nicht nur eine Eigenart meines Spielzeugs. Petrov et al. (2023) haben genau das über Sprachen und Tokenizer hinweg untersucht und festgestellt, dass der Abstand groß genug ist, um sowohl bei den Kosten als auch beim effektiven Kontextfenster ins Gewicht zu fallen. Sie ordnen es als Fairness-Problem ein, nicht bloß als Effizienzfrage. Das halte ich für richtig.

Die Prüfung, die ich tatsächlich empfehlen würde, dauert zwei Minuten: Nimm einen Absatz, den du in beiden Sprachen geschrieben hast, und jag ihn durch den echten Tokenizer des Modells, das du benutzt. Mein Spielzeug zeigt dir die Form der Antwort. Deine Zahl bekommst du nur vom echten.

Was das an den Zahlen ändert

Drei Dinge, die ich für fix gehalten hatte und die es nicht sind:

Ein Kontextfenster ist keine Textmenge. Es ist eine Textmenge in einer bestimmten Sprache, in einem bestimmten Stil. Dasselbe Fenster fasst weniger Deutsch als Englisch, und weniger Code mit ungewöhnlichen Bezeichnern als Code mit gewöhnlichen.
Preis pro Million Tokens ist kein Preis pro Million von irgendwas Sichtbarem. Zwei Dokumente, die gleich lang aussehen, können in der Verarbeitung spürbar unterschiedlich kosten.
Seltene Tokens sind nicht nur eine Kostenfrage. Ein Wort, das in sechs Fragmente zerfällt, sind sechs Positionen, die das Modell erst wieder zusammensetzen muss, bevor es mit der Bedeutung überhaupt arbeiten kann.

Nichts davon ist ein Grund, nicht mehr auf Deutsch zu schreiben. Es ist ein Grund, nicht mehr in Zeichen zu überschlagen, was ich bis dahin getan hatte.

Next

Das naheliegende Experiment ist, einen Tokenizer auf meinen eigenen Texten zu trainieren, diesen Blog in beiden Sprachen, und zu sehen, welche Merges er lernt, die ein allgemeiner nicht lernt. Ob dabei etwas Brauchbares herauskommt oder nur eine unterhaltsame Vokabelliste, weiß ich noch nicht.

Danach das, worum ich seit dem Zählmodell herumlaufe: etwas Kleines wirklich trainieren und den Bewertungsaufbau aus meinen Agent-Loops darauf richten. Gleicher Apparat, viel kleinerer Gegenstand.

Falls du in einer Sprache arbeitest, die nicht Englisch ist: Hast du mal nachgemessen, was deine Prompts im Vergleich zur englischen Fassung kosten, oder hast du wie ich in Zeichen überschlagen?

21:T1c63,

Sean Goedecke argumentiert, dass die wichtigste Fähigkeit beim Prompten die Expertise in der Domäne ist, für die man promptet. Sein Hauptbeleg ist ein Gespräch von Terence Tao mit ChatGPT: Tao kommt weiter als die meisten, nicht weil er allgemein besser promptet, sondern weil er die Mathematik gut genug kennt, um zu wissen, wo er nachbohren muss.

Ich halte das für richtig und fahre seit Monaten danach. Wie ich Arbeit über Modelle verteile ist eine Wette auf genau diese Behauptung: Der Plan entsteht vor dem Code, im Plan steckt das Urteil, und das Modell, das implementiert, macht die billigere Hälfte.

Dann habe ich das Urteil automatisiert, und die Behauptung hielt nicht mehr in der Richtung, die ich erwartet hatte.

Was passiert, wenn man die Expertise aufschreibt

Goedeckes Experte sitzt in der Schleife. Er liest eine Antwort, erkennt sie als subtil falsch und hakt nach. Die Expertise wird laufend angewendet, und sie passt sich dabei an, weil sie noch in einem Kopf steckt.

Eine bewertete Loop funktioniert anders. Du schreibst auf, was gut heißt — präzise genug, dass ein Skript es ausrechnet —, und dann läuft die Sache stundenlang ohne dich. Darin liegt der ganze Gewinn, und der ist echt.

Nur wird die Expertise dabei nicht mehr angewendet. Sie wurde einmal angewendet, beim Schreiben der Spec und beim Bauen der Eval, und danach in Dateien eingefroren, die absichtlich unveränderlich sind, damit sich nichts im Lauf zu einem besseren Score hinbearbeiten kann.

Unveränderlich ist die richtige Bauart. Sie macht die Annahmen des Experten aber auch zum einzigen Teil des Laufs, den niemand mehr revidieren kann.

Sechshundert Szenarien, kein einziger Request

Das Target, an dem mir das passiert ist, ist ein Partner-Attributionssystem. Seine Eval hat 600 Szenarien: 400 Dev, 200 Holdout. Jedes einzelne ist eine vorgefertigte Zustandsdatei — Affiliates, Empfehlungskanten, Events, Links, Offers, Auszahlungen.

In keinem steckt ein HTTP-Request.

Der Lauf ist sauber durchgelaufen. 1,0 auf der Stichprobe, 1,0 auf dem vollen Dev-Set, 1,0 auf dem Probe-Set — ein Gap von exakt null, also die Zahl, die sagt: generalisiert, nicht auswendig gelernt. Nichts wurde ausgetrickst. Die Datenbank war echt. Row-Level Security war echt, unter einer Rolle ohne Superuser- und ohne Bypass-Rechte. Die Append-only-Hash-Kette wurde direkt geprüft und nicht über einen Sonderweg fürs Scoring, weil ich all das in die Constraints geschrieben hatte.

Nicht hineingeschrieben hatte ich den Einstiegspunkt des Produkts. Die Ingestion-Routen — das, worüber jedes echte Event hereinkäme — standen kein einziges Mal auf dem Prüfstand. Sie konnten es nicht. In der Eval gab es nichts, was sie erreicht hätte.

Das ist kein Modellfehler. Das Modell hat gebaut, was verlangt war, korrekt, und hat nachgewiesen, dass es generalisiert. Das ist ein Spezifikationsfehler, und spezifiziert habe ich.

Warum das schlimmer ist als eine Loop, die betrügt

Eine Loop, die ihre Eval austrickst, ist lästig und beherrschbar. Du checksummst das Target, blendest die Antworten aus, lässt einen Lint über die Tricks laufen, die du kennst, und hältst ein Probe-Set zurück. Diese Verteidigungen funktionieren, und wie man sie baut, habe ich beschrieben.

Sie zeigen alle nach innen.

Der Probe-Gap fragt, ob die Sache über die Oberfläche generalisiert, die ich abgetastet habe. Ob diese Oberfläche die richtige war, dazu sagt er nichts.
Die Lints fragen, ob der Code bei der Aufgabe wie spezifiziert geschummelt hat. Eine korrekte Implementierung des falschen Zuschnitts besteht sie alle.
Das Holdout stammt aus demselben Generator wie das Dev-Set und erbt damit jede Annahme, die das Dev-Set hat.

Die Fassung davon, zu der ich immer wieder zurückkomme: Ein Experte, der Ergebnisse reviewt, kann von ihnen überrascht werden. Ein Experte, der die Eval geschrieben hat, hat vorher festgelegt, was als Überraschung zählt.

Goedeckes Satz lautet, der Mensch sei der Flaschenhals, nicht das Modell. Für eine beaufsichtigte Session würde ich zustimmen. Für einen bewerteten Lauf ist es genauer und weniger schmeichelhaft: Der Mensch ist der Rahmen, und nichts innerhalb eines Rahmens prüft den Rahmen.

Was von der Behauptung übrig bleibt

Nicht „Expertise ist egal" — der Lauf ist überhaupt nur so weit gekommen, weil die Spec gut war, und der meiste Wert entstand beim Spezifizieren, bevor ein einziger Zyklus lief. Dieser Teil von Goedeckes Argument kommt gestärkt heraus, nicht geschwächt.

Was sich ändert: Expertise erledigt offenbar zwei verschiedene Aufgaben, und nur eine davon übersteht das Aufschreiben.

Die Grenze ziehen. Entscheiden, was zählt, was gemessen wird, was „richtig" für diese Aufgabe heißt. Das lässt sich hervorragend in Dateien überführen. Es ist der größte Teil dessen, was eine gute Spec ausmacht.
Die Grenze prüfen. Merken, dass das Gemessene nicht das Gewollte ist. Das überträgt sich nicht, weil die Prüfung von außerhalb des Rahmens kommen muss, den die Expertise gezogen hat.

Ich hatte die beiden für eine Fähigkeit gehalten. Sind sie nicht, und die zweite ist die, an deren Automatisierung ich scheitere. Gefunden habe ich den Zuschnittsfehler, indem ich mir das Produkt Wochen später angesehen habe — nicht durch irgendein Instrument im Harness.

Die praktische Fassung für mich lautet also: Je mehr von meinem Urteil ins Target wandert, desto bewusster muss ich den Teil einplanen, der nicht dorthin wandern kann. Nicht das Review des Diffs — darin ist das Scoring der Loop inzwischen besser als ich. Das Review der Frage. Irgendwer muss in irgendeinem Takt das Produkt aufmachen und prüfen, ob die Eval es noch beschreibt.

Bisher ist dieser Irgendwer ich, in keinem bestimmten Takt, aus Versehen.

Next

Was ich will und nicht habe, ist ein Instrument für den Zuschnitt: etwas, das anschlägt, wenn die Eval das Produkt nicht mehr abdeckt, so wie der Probe-Gap anschlägt, wenn die Eval nicht mehr ehrlich ist. Einen Entwurf dafür habe ich nicht. Vielleicht ist es nichts, was ein Skript halten kann — dann wäre die ehrliche Antwort ein Kalendereintrag und kein Harness.

Die billige Variante, die ich zuerst probiere, ist eine End-to-End-Probe pro Target, die über den echten Einstiegspunkt läuft und bewusst nicht bewertet wird. So kann nichts gegen sie optimieren, und sie kann mir nur eines sagen: dass Eval und Produkt auseinandergelaufen sind.

Meine eigene Antwort lautet bisher „gar nicht, ich habe es zufällig gemerkt", und die höre ich lieber von dir zurück als einen Mechanismus, den keiner wirklich betreibt. Also: Falls du Loops gegen eine aufgeschriebene Spec fährst — womit ist dir Zuschnittsdrift je aufgefallen?

Saghallo

Cookie-Einstellungen

Sag
hallo