In der tagesschau.de/wirtschaft/… Meldung zum Tod von Klaus-Michael Kühne hätte man meiner Meinung nach kurz auf Problematiken rund um die Nazi-Zeit eingehen können. Frage mich, ob der Tippfehler in einer Überschrift ein Freudscher Vertipper des Redakteurs war.

Ich persönlich bin kein großer Fan von Browser-Benachrichtigungen. Allerdings hat mich @jpawlowski davon überzeugt, dass sie für viele Nutzer tatsächlich praktisch sein können.  Die Funktion kann jetzt unter vutuv.de/settings/notifications aktiviert werden. Standardmäßig ist sie deaktiviert.

AFAIK muss auch jeder Neuwagen eine minimale Blackbox für Fahrzeugdaten (z.B. Gas- und Bremspedaleinstellung) enthalten.

“Das IT-System des Landes ist sehr groß, wir sind überrascht wie groß”, sagte der Staatssekretär.

Huch! Das konnte aber auch wirklich keiner ahnen!

golem.de/news/…

Gibt es irgendwo mehr Informationen zur Version 5.0? Also in Prosa für normale Menschen und nicht in Code im Repository.

Ich habe bei vutuv einige WebPerformance-Optimierungen vorgenommen. Würde mich mal interessieren, ob man das auch in Deutschland spürt. Für mich - heute hier in Windhoek - ist das ein Unterschied wie Tag und Nacht.

And the classic Deadvlei picture. When in Rome!

I am currently on a business trip in Namibia. While eating my own dog food I realize that vutuv needs some more optimization for very slow internet connections. I can work with it here somewhere in the middle of nowhere but it lacks the snappiness of the European internet connection.

Coelho - Structured rich text for Phoenix

I’ve just published Coelho, a structured rich text library for Phoenix.

The idea is somewhat inspired by Rails’ Action Text: provide a proper rich text layer between the editor in the browser and the application’s data model.

But instead of storing HTML, Coelho stores the document as a structured JSON tree — the same kind of document model used by ProseMirror.

That gives the application a single source of truth for both the editor and the server:

• define the document schema once in Elixir
• export the schema to ProseMirror
• validate documents before they reach the database
• store the document directly in a jsonb column
• render it to HTML or extract plain text
• customise rendering without changing the stored document
• use different, restricted schemas for different rich text fields
• validate and cast rich text directly through Ecto
• use it from Phoenix LiveView with an included editor
• support attachments with URLs resolved at render time

One of the things I particularly wanted to avoid is treating HTML as the data model.

When rich text is stored as HTML, the markup becomes part of the persisted data. With a structured document instead, the data remains queryable and migratable, while rendering stays an application-level decision.

Coelho also deliberately keeps the core small: no file storage, image processing or collaborative editing. Those are integration points rather than responsibilities of the document layer.

It’s early, but the core is already in place and tested.

I’d particularly love feedback from people building Phoenix applications that need rich text, especially if you’ve used Action Text or another structured rich text solution before.

HexDocs: coelho.hexdocs.pm/readme.html

Hex.pm: hex.pm/packages/…

github.com/nseaSeb/coelho

Wie ich aktuell mit mehreren Coding-Agenten arbeite

Inzwischen merke ich immer deutlicher: Es gibt nicht den einen perfekten Agenten – und vermutlich auch nicht die eine perfekte Entwicklungsumgebung – für alles.

Ich arbeite aktuell vor allem mit Claude und Codex und merke dabei, dass beide unterschiedliche Stärken haben.

Claude gefällt mir häufig bei Planung, Struktur und einer ersten Umsetzung innerhalb vorhandener Projektregeln. Codex empfinde ich oft als pragmatischer und direkter und setze ihn deshalb gerne als zweiten Blick oder für Reviews ein.

Dabei ist das aber längst kein fester Workflow mehr.

Je nach Aufgabe wechsle ich zwischen den Werkzeugen und lasse auch bewusst einen Agenten auf die Arbeit des anderen schauen.

Der eigentliche Schlüssel ist gemeinsamer Kontext

Damit das funktioniert, muss das Repository selbst gut vorbereitet sein.

Guidelines, Skills, Projektregeln, Tests und eine verständliche Entwicklungsumgebung werden für mich immer wichtiger.

Denn wenn jeder Agent erst wieder neu erraten muss, wie ein Projekt aufgebaut ist und welche Regeln gelten, verliert man einen großen Teil des Produktivitätsgewinns.

Mein Ziel ist deshalb weniger, den „besten“ Agenten zu finden.

Ich möchte ein Projekt so vorbereiten, dass unterschiedliche Agenten sinnvoll daran arbeiten können und austauschbar bleiben.

Agentische Entwicklung findet für mich nicht nur in Agent-First-IDEs statt

Ich nutze VS Code mit Devcontainern ebenfalls intensiv für agentische Entwicklung.

Der Unterschied ist für mich eher: Dort kann ich den Agenten wesentlich besser auf die Finger schauen.

Ich sehe Dateien, Diffs und die Struktur des Projekts direkt vor mir, kann Änderungen gezielt nachvollziehen und habe stärker das Gefühl, jederzeit eingreifen zu können.

Agent-First-Umgebungen wie Claude Code oder Codex sind dagegen besonders angenehm, wenn ich eine Aufgabe stärker delegieren und den Agenten relativ selbstständig daran arbeiten lassen möchte.

Für mich läuft es deshalb nicht auf VS Code oder Agent hinaus.

Und auch nicht auf Claude oder Codex.

Sondern auf eine Kombination daraus – abhängig davon, was ich gerade erreichen möchte und wie eng ich die Umsetzung begleiten will.

Vielleicht ist genau das die neue Fähigkeit:

Nicht nur Code zu schreiben, sondern für jede Aufgabe den richtigen Agenten, den richtigen Kontext und die passende Arbeitsumgebung zusammenzubringen.