Posts

Pinned Post

OpenSpec UI: ein Live-Dashboard für deine Specs

Bild
OpenSpec UI: ein Live-Dashboard für deine Specs Wer mit einem KI-Agenten und OpenSpec arbeitet, kennt das Bild. Im Projekt wächst ein Verzeichnis openspec/ heran: Changes mit proposal.md , design.md , tasks.md und ihren Delta-Specs, daneben die kanonischen Specs der einzelnen Capabilities. Die Absicht hinter dem Code steht damit endlich geschrieben, statt sich in ihm zu verstecken. Nur verteilt sie sich über Dutzende Markdown-Dateien, und der Editor zeigt eben Dateien. Was er nicht zeigt, ist der Zustand. Woran arbeitet der Agent gerade? Welcher Task ist der nächste offene? Und was hat sich verändert, während ich zehn Minuten woanders hingeschaut habe? Genau diese Lücke füllt OpenSpec UI , ein kleines Phoenix-LiveView-Dashboard, das lokal neben deinem Projekt läuft und den OpenSpec-Workspace im Browser zeigt — live, während gearbeitet wird. Der Code liegt offen auf GitLab: https://gitlab.com/public_elixir/openspec_ui Ein Blick statt Datei-Hopping Du startest den Server, gibst d...
Bild
Spec Driven Development mit OpenSpec: ein Praxisbeispiel Die meisten Änderungen an einer Software fangen mit einem Halbsatz an: „Bau mal eben ein Cover in den Artikel ein.” Und dann geht es sofort in den Editor. Unterwegs treffen wir ein Dutzend kleiner Entscheidungen, raten, was wohl gemeint war, und am Ende läuft es irgendwie. Nur weiß hinterher niemand mehr genau, was das System eigentlich können soll. Diese Wahrheit steckt dann im Code, verteilt über viele Dateien, und entfernt sich mit jedem Commit ein Stück weiter von der ursprünglichen Absicht. Spec Driven Development, kurz SDD, dreht die Reihenfolge um. Zuerst wird beschrieben, was das System tun soll. Erst danach geht es an das Wie. In diesem Artikel zeige ich, was dahintersteckt, wie der Prozess mit dem Werkzeug OpenSpec (openspec.dev) konkret aussieht und welche Befehle man dafür braucht. Als roter Faden dient eine echte Änderung aus dem Projekt pdf_finder. Was Spec Driven Development ist Im Kern trennt SDD zwei Dinge, die s...

Semantische Suche für die eigene Bibliothek: eine RAG-Architektur in Elixir

Bild
Angefangen hat das Ganze als schlichter „PDF-Finder". Eine Handvoll E-Books, eine Upload-Maske, eine Volltextsuche, mehr sollte es nicht sein. Aber Sammlungen wachsen, und irgendwann ist ein Archiv so groß, dass man es nicht mehr überblickt. Die Volltextsuche fand nur etwas, wenn ich die exakten Begriffe kannte. Frage ich mich „Wie funktioniert Quantenverschränkung?", das Buch schreibt aber von „verschränkten Zuständen", dann findet die Suche nichts. Was fehlt, ist also keine bessere Suche über Wörter. Was fehlt, ist eine Suche über Bedeutung. Diese Erkenntnis kommt schnell. Spannender ist der Weg von dort zu einem System, das mir eine Frage in natürlicher Sprache beantwortet, mit Quellenangabe, aus meinen eigenen Dokumenten und komplett auf meinem Rechner. Um diesen Weg geht es hier, und um die Design-Entscheidungen, an denen er sich entschieden hat. Die Idee: nicht suchen, sondern antworten Das Verfahren dahinter heißt RAG, kurz für Retrieval-Augmented Generation...

Semantic Search for Your Own Library: a RAG Architecture in Elixir

Bild
It started as a plain "PDF finder." A handful of e-books, an upload form, full-text search, nothing more was planned. But collections grow, and at some point an archive gets so big you can no longer keep track of it. Full-text search only found things when I already knew the exact words. If I ask "How does quantum entanglement work?" but the book says "entangled states," the search finds nothing. So what's missing isn't a better search over words. What's missing is a search over meaning. That realization comes quickly. The interesting part is the road from there to a system that answers a question in natural language, with citations, from my own documents, and entirely on my own machine. This post is about that road, and about the design decisions where it was actually decided. The idea: don't search, answer The technique behind this is RAG, short for Retrieval-Augmented Generation. Put simply, you pull the relevant passages out of yo...

Jido in Practice: Agents in Elixir as Composable Actions

Bild
At Fiatbitcoin, around two dozen small agents run in the background. They fetch prices, read the mempool, score news, compute tax deadlines, send alerts. In the beginning these were all just GenServers and Oban jobs, each built a little differently. That works, but it gets messy fast: every job has its own input and output, its own way of reporting errors, its own idea of what “done” means. Jido is a framework for exactly this kind of work. It hands you a small set of clearly defined building blocks that let you assemble agents from small, testable units. I use it in version 2.1. This article is a tour through real code from the project, and the question behind it stays the same throughout: where does Jido pull its weight, and where does it not. If you don’t write Elixir, a few words up front. A module is a collection of functions. {:ok, value} and {:error, reason} are the usual way to return success or failure, a tagged pair. A GenServer is a lightweight, long-lived process wit...

Jido in der Praxis: Agenten in Elixir als komponierbare Actions

Bild
Bei Fiatbitcoin laufen rund zwei Dutzend kleine Agenten im Hintergrund. Sie holen Kurse, lesen die Mempool, bewerten Nachrichten, rechnen Steuerfristen aus, schicken Alerts. Am Anfang waren das alles einfach GenServer und Oban-Jobs, jeder ein bisschen anders gebaut. Das funktioniert, wird aber schnell unübersichtlich: Jeder Job hat seinen eigenen Ein- und Ausgang, seine eigene Art, Fehler zu melden, seine eigene Vorstellung davon, was “fertig” heißt. Jido ist ein Framework für genau diese Art von Arbeit. Es gibt einem eine Handvoll klar umrissener Bausteine, mit denen man Agenten aus kleinen, testbaren Einheiten zusammensetzt. Ich benutze es in Version 2.1. Dieser Artikel ist eine Tour durch echten Code aus dem Projekt, und die Frage dahinter ist die ganze Zeit dieselbe: Wo trägt Jido sein Gewicht, und wo nicht. Falls du kein Elixir schreibst, ein paar Vokabeln vorab. Ein Modul ist eine Sammlung von Funktionen. {:ok, value} und {:error, reason} sind die übliche Art, Erfolg oder ...

Classic Agent, AI Agent: the same job, two very different brains

Bild
For about two years now, everything is an "agent." Any app that makes more than one API call in a row sells itself as agentic, and in the same breath it sounds as if humanity had only just invented the concept. Both are off. Agents are ancient, and "agent" doesn't automatically mean "AI." I didn't want to assert the difference, I wanted to see it. So I built a small Elixir app in which two agents solve exactly the same task: break a goal down into a to-do list. One follows fixed rules, the other asks a language model. Both are the same kind of agent, just with a different brain. That single spot is where the whole difference sits. Agents have been around far longer than "AI" in today's sense Before we get to the contrast, a quick look back, because it puts the whole debate in perspective. In the textbook that every AI course has used since the nineties, Russell and Norvig define an agent about as plainly as it gets: something t...

Beliebte Posts aus diesem Blog

Splitting an ML model and a web app across two BEAM nodes — the technical blueprint

Jido in Practice: Agents in Elixir as Composable Actions

A Foundation Model in the BEAM: On-Chain Anomalies with Google TimesFM in Elixir