<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Notes on Jedi Knights</title><link>https://jedi-knights.tech/notes/</link><description>Recent content in Notes on Jedi Knights</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://jedi-knights.tech/notes/index.xml" rel="self" type="application/rss+xml"/><item><title>Learning-first</title><link>https://jedi-knights.tech/notes/learning-first/</link><pubDate>Tue, 14 Jul 2026 00:00:00 +0000</pubDate><guid>https://jedi-knights.tech/notes/learning-first/</guid><description>&lt;p&gt;The usual advice for building event streaming into a system is short: don&amp;rsquo;t. Use Kafka. Use Redpanda. Use NATS. Use a managed service. The problem is solved; the incumbents are good; the operational literature is deep. Building your own broker is, by every reasonable metric, a bad idea.&lt;/p&gt;
&lt;p&gt;We built &lt;a href="https://jedi-knights.tech/projects/holocron/"&gt;Holocron&lt;/a&gt; anyway. Not because we thought we could beat Kafka — we can&amp;rsquo;t, and we&amp;rsquo;re not trying to — but because &amp;ldquo;use Kafka&amp;rdquo; answers a different question than the one we were asking.&lt;/p&gt;</description></item><item><title>One event, two consumers</title><link>https://jedi-knights.tech/notes/one-event-two-consumers/</link><pubDate>Tue, 14 Jul 2026 00:00:00 +0000</pubDate><guid>https://jedi-knights.tech/notes/one-event-two-consumers/</guid><description>&lt;p&gt;The obvious way to add paid tiers to a product is to bolt on Stripe Billing, sprinkle metering calls through the code, and ship. The path is well-documented, the vendor is excellent, and it works. It&amp;rsquo;s also the wrong shape for a system that already emits structured events for a different reason — every metering call you add is a second instrumentation of a thing the codebase is already telling you about.&lt;/p&gt;</description></item><item><title>Tools, not endpoints</title><link>https://jedi-knights.tech/notes/tools-not-endpoints/</link><pubDate>Tue, 14 Jul 2026 00:00:00 +0000</pubDate><guid>https://jedi-knights.tech/notes/tools-not-endpoints/</guid><description>&lt;p&gt;The obvious way to build an MCP server is to open your REST client, wrap each endpoint in a tool, and ship. Every route becomes a function, every parameter becomes a JSON Schema field, every response becomes whatever the upstream API happened to return. Two afternoons and you&amp;rsquo;re done.&lt;/p&gt;
&lt;p&gt;Don&amp;rsquo;t.&lt;/p&gt;
&lt;p&gt;We&amp;rsquo;ve now built three of these — one for ECNL youth soccer, one for the NWSL, one for the NFL — and the servers that survive contact with real agents look almost nothing like a mirror of their upstream APIs. The caller is not a script written by someone who read your docs. The caller is a model that will pattern-match your tool signatures and confabulate the rest. Every shape you get wrong is a hallucination generator.&lt;/p&gt;</description></item><item><title>When the caller is a coin flip</title><link>https://jedi-knights.tech/notes/caller-is-a-coin-flip/</link><pubDate>Tue, 14 Jul 2026 00:00:00 +0000</pubDate><guid>https://jedi-knights.tech/notes/caller-is-a-coin-flip/</guid><description>&lt;p&gt;You cannot unit-test your way out of the anxiety of shipping something an LLM will call. Unit tests answer &lt;em&gt;did this function return the right value for these inputs?&lt;/em&gt; The question that keeps you up at night is different: &lt;em&gt;will the model, in a phrasing we didn&amp;rsquo;t anticipate, hallucinate an argument, or reformat our output in a way that changes what it means?&lt;/em&gt; You can raise coverage to 100% and that question stays exactly as loud.&lt;/p&gt;</description></item></channel></rss>