DEV Community: Ryan Brinn

Mapping Semantic Meaning Onto the Night Sky

Ryan Brinn — Fri, 10 Jul 2026 15:57:33 +0000

If you were to look up into the night sky, what would you see? Countless points of light, scattered in every direction. Most of what you're looking at are stars. But some of those points are whole galaxies—vast collections of stars, spread across incomprehensible distances, compressed by that distance into a single pinprick of light. And what you can see with the naked eye is only a small fraction of what's actually out there.

I want to use this as a way to offer you a way of thinking about how large language models work. Just an analogy, not literally what's happening inside the mathematics—that's not my forte. My hope is that it captures something true about the mechanics, and more importantly, it gives you a mental model you can actually use when you're working with these systems.

About two years ago, I was wrestling with finding a way of explaining what an LLM does. My first analogy was that of a dictionary. The naive view was that a dictionary uses words to define other words, and an LLM holds a matrix of words with weights that describe their relationships to each other. So the parallel seemed natural: both systems work through relational structure.

However, a dictionary gives you denotation—the surface-level meaning. It's a lookup tool for individual words, not a model of language itself. And critically, you have to already understand language before a dictionary is useful to you at all. The analogy didn't capture what was actually happening in the weight relationships—the distributional semantics, the contextual patterns that let an LLM generate coherent text.

Ok, so back to galaxies, when you look up at the night sky, you're not seeing distance—you're seeing direction. That galaxy over there, the one that looks like a point of light, could be millions of light-years away, but what matters for our analogy isn't how far it is. It's which way you're looking. And when you point yourself in that direction and venture toward it, you discover it's not a point at all. It's a vast, intricate structure. A whole semantic space.

Like galaxies in the night sky, or even stars within a single galaxy, the semantic space an LLM inhabits is finite, but it's breathtakingly large. The vocabulary is bounded—there are only so many tokens the model knows. But within that bounded space, the possible paths, the possible combinations, the possible directions you could take through a single galaxy... they're effectively infinite from a practical standpoint. You could spend your entire life exploring one semantic region and never exhaust it.

That's how I think about what's happening inside a language model. Each galaxy in the night sky mapped onto a small portion of linguistic semantic space—a region of meaning. Your prompt is both the direction you choose to look, and also sets your entry point into that galaxy. Once you're in, you're free to navigate, however how you navigate can be shaped by a few things, most importantly of which are temperature and context.

So how do temperature and context shape your journey through that galaxy? Think of it this way: your prompt has given you an entry point. You're standing at the edge of the galactic disk, ready to move. Now you need to decide how to traverse it.

Temperature controls your hop distance. You're trying to move from star to star through the galaxy. Each star represents a token, a possible next word. Some stars are closer than others—they're more probable given where you are. Low temperature means you take the shortest hops. You move from star to star along the most likely path, the ridge of probability. The model hugs the modal distribution. You get deterministic, predictable output.

Crank up the temperature, and suddenly you're allowed to make bigger leaps. You can skip over the nearest stars and jump to ones farther out—less probable but still reachable. Those distant stars might connect to regions of the galaxy you'd never reach on the short-hop path. The output becomes more exploratory, more creative, but also less predictable.

Context is different. Context doesn't change your hop distance. Instead, it whispers a direction. It says: "You're free to hop as you like, but stay in this region. Make your leaps this way." Context sculpts which parts of the galaxy remain navigable. It narrows the space without necessarily restricting your hop size—you're still making leaps, but they're guided leaps.

Context and Temperature; together, they're a two-lever system: context says "navigate toward this region of the galaxy," temperature says "how freely can you hop to get there."

In this thought experiment, not all galaxies are created equal, and this greatly affects how useful temperature and context are.. Some semantic spaces are small, densely packed, heavily weighted toward a single region. Others are vast, with multiple distinct regions and countless branching paths.

Some semantic galaxies are dominated by their central structure. Imagine a galaxy where most of the mass is concentrated tightly around a supermassive black hole at the center—a small, dense disk with little structure extending outward. When your prompt points you toward the galactic center, you can't escape the black hole's gravitational pull. The galaxy's structure simply doesn't have room for alternatives. The prompt "What is the capital of France?" is going to send you into a very small galaxy dominated by a supermassive black hole called Paris—your entry point is going to point you directly at it. And here's the key: temperature and context barely matter in a galaxy like this. The gravitational dominance is so overwhelming that whether you take short hops or long leaps, whether context tries to steer you sideways, you're getting pulled toward the same inevitable answer. The mechanism itself constrains the outcome.

Now imagine a galaxy more like our own—one with a large, distributed disk extending far from the center. Stars, nebulae, structure spread throughout. Yes, there's a supermassive black hole at the core, but it is small and the galactic disk stretches out beyond its influence. You can explore the outer regions, the spiral arms, distant pockets of activity. That's where temperature and context actually have power. Low temperature hugs the probable paths, high temperature explores distant regions, and context can steer you through entirely different neighborhoods. Your prompt might point you generally in a direction, but the galaxy has room for genuine divergence. That's more like "The future of AI is..."—vast, branching, with multiple regions worth exploring.

Same mechanism. Completely different effect, because the underlying gravitational structure of the galaxy itself is fundamentally different.

So here's the mental model I've been sitting with. A semantic galaxy, shaped by its own gravitational landscape. Some queries pull you inevitably toward a single region. Others open onto vast, distributed space. Temperature and context are levers you can work with, but what they actually do depends entirely on the structure you're navigating.

I don't know if this frame will stick, or if it'll hold up under scrutiny, or if it's even pointing at something real. But it's been useful to me—it's given me a way to think about why some prompts respond to tweaking and others don't. Why temperature matters sometimes and barely registers other times.

Maybe it's useful to you too. Or maybe you'll take it apart, refine it, add something I'm missing. I'm genuinely curious where it goes.

Are We All Artists Now?

Ryan Brinn — Sun, 05 Jul 2026 21:58:09 +0000

Here's something I've been thinking about for a while now — a mental model I keep coming back to whenever I try to understand how anyone actually gets good at something. I think mastering a skill happens in two phases, and I've always just thought of them as the science of something and the art of something.

The science is where you're learning something — a craft, a trade, a discipline, a sport, whatever — and you start by inheriting the rules. Somebody already went through the trial and error. They figured out what works, wrote it down, handed it to you so you don't have to relearn the whole thing from scratch. You follow it, you absorb the pattern, you do it the way it's supposed to be done, because that's what's been laid out for you. And honestly, that's a fine way to get competent fast. Nothing wrong with it.

Then, at some point, if you keep going long enough, something shifts. You stop asking "what's the rule" and start asking "why does this rule even exist, and does it still apply here?" You start bending things, breaking things, going back and reexamining stuff you used to just take for granted. Not randomly — that's important — but with this kind of earned judgment about which parts of the rulebook are actually load-bearing and which parts are just habit nobody's bothered to question in a while. That's the art.

Turns out I didn't come up with this myself, which, fine. Once I started poking at it I found it maps pretty closely onto existing thinking about skill acquisition — the Dreyfus model of skill mastery describes something similar, moving from novice rule-following (the science) toward this expert-level improvisation past the rules (the art). So I'm not being nearly as clever as I thought I was. But I'm going to keep using my own language for it anyway, because I think it's the more useful frame for what I actually want to talk about here: "art" and "science" as names for two tiers of any skill. Not fine art. Not literal science. Just rule-following versus rule-transcending.

So that's the mental model. What I want to spend this piece doing is pushing on it a bit — specifically, why I think generative AI is stuck pretty firmly in the science tier, why that might be making the art tier more valuable rather than less, and where I think that actually leaves people.

The tell

Here's something I'd bet almost everyone reading this has felt: you read something, or look at something, and some part of you just goes — yep, that's AI. You can't always say exactly why. It's a little too smooth. A little too resolved. Technically fine, but somehow thin.

I don't think that reaction is some mystical sixth sense. I actually think it might be a pretty accurate read of what's happening underneath.

Generative models are trained to predict the most statistically likely continuation given everything they've seen. That process pulls outputs toward the center of the training distribution — smoothed, average, safe. Human work, even mediocre human work, tends to carry more irregularity in it: specific choices, small "wrong" decisions that somehow turn out right, texture that comes from one particular person's particular constraints and mood and history on that day. If AI output tends to read like an average and human output tends to read like a point of view, maybe that difference is genuinely detectable — not just something we're imagining.

"But models keep getting better" — sure, but at what, exactly?

The obvious pushback here: models keep improving, constantly. Doesn't that just erode this whole argument over time?

I don't think it does, actually, and I think it's worth walking through why models get better, because as far as I can tell, none of the reasons actually touch the thing I'm talking about:

Scale — more parameters, more data. This just gives a model a bigger map of the territory it was trained on, and more resolution once it's there.
Architecture and training method improvements — these make navigating that map more efficient, less wasted effort on noise.
Post-training and fine-tuning — this one's closer, honestly. It's sculpting which parts of the existing map the model gets pulled toward by default. That's a real form of discernment. But it's discernment done by humans, in advance, on the model — not something the model works out itself, in the moment, for a case nobody already judged.
Inference-time stuff — longer context, more reasoning steps. This just gives the model more time to search the map it already has before it answers. Bigger map. Better-curated map. More time to search the map. That's basically every lever I can name, and every one of them is about navigating the existing space better. None of them is "redraw the map because this part of it is wrong." Which isn't a knock on the technology, it's just not what any of these methods are built to do. And honestly, I think that absence is the actual evidence here — not just something I'm asserting because it happens to support what I already wanted to believe.

What's actually missing

Here's where I want to push back on my own instinct a bit. The naive version of "art versus science" makes it sound like creativity is just rule-breaking — like the more you depart from convention, the more creative you are. But I don't think that's really true. Randomly ignoring constraints doesn't produce insight, it produces noise. A musician who "breaks" a harmonic rule isn't just playing random notes — they're breaking exactly the one rule that's stopped being load-bearing, while keeping everything else intact enough that the thing still holds together as music.

So maybe the sharper version of the claim is this: creativity isn't measured by distance from the rules, it's measured by how precisely you can tell which constraints are still structural and which ones are just calcified habit. That's a much harder thing to do than either blindly obeying or blindly departing, and I think that's the actual content of "transcending the rules" — not escaping them, but understanding them well enough to know the one case where they don't hold.

I'll be honest about where this leaves me, though: I don't think we actually have a clean theory of what makes human creative cognition tick, so I hold this with real uncertainty, not settled confidence. I lean toward believing there's something happening when a person does this kind of discernment that isn't happening when a model does pattern completion. But I'm genuinely not sure I'm the person qualified to prove that, and I'd rather just say that out loud than pretend I've got it all figured out.

Where does that leave the rest of us

I think this generalizes across pretty much every field, not just software. If the rule-following tier of a field is what's getting commoditized, the valuable skill in that field was probably never really "know the rules" — it was always "know when they stop applying." That's true in law, in medicine, in writing, in management, in the trades, wherever. It's just that AI is making the floor of rule-execution cheap enough and fast enough that the tier above it is the only one left with any real scarcity.

So if you're trying to figure out where to put your own effort right now, I don't think the useful question is "which tasks can AI not do yet." I think it's closer to: which parts of what I do are me applying a rule someone else already worked out, and which parts are me actually deciding whether that rule still holds in this specific case? The first tier is getting automated out from under all of us, in pretty much every field, on a timeline none of us fully control. The second one's the one worth deliberately getting better at.

So — are we all artists now?

Not literally, no. I'm not telling anyone to quit their job and pick up a paintbrush, and I don't think the economics of fine-arts careers are suddenly any different. But I do think the thing "art" was always shorthand for — the rule-transcending, question-asking, "does this concept even still deserve to exist" instinct — is now the scarce, valuable tier in pretty much every field, including plenty of fields that pride themselves on being practical and rule-bound.

I don't know if that means we're all artists now. But I think it means the thing we used to dismiss as "just art" might be the one thing left with no substitute.

Maybe Chain-of-Thought Isn't the Trick. Maybe Specification Is.

Ryan Brinn — Tue, 30 Jun 2026 16:24:08 +0000

I want to think through something out loud, and I'd genuinely love to know if this lands for anyone else or if I'm just talking myself into a corner.

I've been chasing a hunch lately, the kind that starts as a half-formed idea you can't quite let go of. It's about prompting — specifically, why we talk about prompting the way we do, and whether the techniques everyone swears by are actually doing what we think they're doing. I went looking for an answer and found something that, if it holds up, kind of upends how I've been thinking about this. So take this as me showing my work, not announcing a conclusion.

Here's where it started: prompt engineering has accumulated a pretty standard toolkit by now. Chain-of-thought. Few-shot examples. Persona framing — "you are an expert clinician," that sort of thing. And most of the advice floating around amounts to some version of "stack enough of these and your results get better." I wanted to understand why that's supposedly true. I expected to find a tidy explanation. What I found instead was a paper suggesting it mostly... isn't true. Which sent me somewhere I didn't expect to go.

Where my head was at first

My own way into this question started with pedagogy, of all things — specifically Bloom's Taxonomy, which is a framework educators use to classify what kind of thinking a question is actually asking for. Remember, understand, apply, analyze, evaluate, create. "List the causes of WWI" wants remembering. "Why did WWI happen instead of being avoided" wants analysis. Same topic, completely different cognitive demand.

And it mapped onto prompting in a way that felt almost too clean. "Summarize this doc" — remember/understand. "Critique this argument" — evaluation. I started wondering whether the actual skill in prompting wasn't "pick the right technique" but something more like "ask for the right kind of thinking," the way a good teacher designs a question around the exact cognitive move they want a student to make.

I liked this idea a lot. I still kind of do. But it turned out to be a detour, not the destination — because the real surprise was sitting in the data, not in my analogy.

The belief I didn't realize I was testing

Here's a belief I think most of us building with LLMs are carrying around, myself included until recently: that prompting technique — chain-of-thought, personas, the clever phrasing patterns — is where the real leverage lives. It's certainly where most of the content lives. Every "10 prompting tricks that actually work" post is selling some version of this.

Then I came across a study out of UConn that tested this head-on, I interpret the results pretty clearly. The researchers were trying to get LLMs to classify psychological constructs in text — something like gratitude, which sits close to the surface of the language and is relatively easy to spot, versus something like negative core beliefs, which needs real interpretive distance and a precise theoretical definition before you even know what you're looking for.

They threw the whole toolkit at it: personas, chain-of-thought, explanations, few-shot examples. But the interesting move was that they also systematically varied the baseline task description itself — just rewording the definition and instructions dozens of different ways, and actually measuring what had significant impact.

And the popular techniques... mostly didn't. Persona framing, chain-of-thought — the paper describes their improvements as small and inconsistent, and across the board, not even statistically significant. What actually mattered, by a wide margin, was getting the definition of the thing you're asking for exactly right. The gap between their best-worded prompt and their worst, on the hardest construct, was a 28-point swing in F1 score. From wording alone. No clever tricks involved.

So maybe the strawman isn't "people think prompting is teaching" — I don't think anyone seriously believes that. I think the real strawman is closer to "people think technique is the lever," and this paper makes a pretty strong case that it mostly isn't. Specification might be doing most of the work instead.

The finding that actually reframed things for me

There's a second result in that paper I didn't see coming, and it's the one that ended up answering my original pedagogy question — just not in the direction I thought I was headed.

Across 71 different prompt components they tested, only three improved both precision and recall at the same time. Almost everything else was a trade-off — fix one kind of error, introduce another. Adding context wasn't free. It behaved like bias, in the literal statistical sense: it tilted the result, one way or another, almost every time.

That's roughly when my Bloom's thread resolved itself — by falling apart, which I wasn't expecting but probably should have. Bloom's was built for development. The whole structure assumes a learner can't reliably analyze something before they understand it, so a curriculum sequences cognitive demand over weeks or months. An LLM doesn't really develop across a conversation the way a student develops across a semester. It's not "becoming ready" for evaluation after demonstrating comprehension first. So the part of Bloom's I actually cared about — the sequencing — just doesn't transfer. What's left is more of a label set, a way to name what kind of operation you're asking for. Still useful, I think, just smaller than I originally hoped it would be.

Where it seems to point, at least to me

If I had to name the discipline that explains both of these findings — technique mattering less than expected, context behaving like measurable bias — I don't think it's teaching. It feels closer to something like survey methodology, or structured interviewing: the practice of trying to pull a true signal out of someone without your own question quietly shaping the answer.

Think about what a good survey question is actually trying to do. Not "lead the respondent toward what I want to hear." The opposite, really — precise enough to be answerable, but neutral enough that the response reflects what the person actually thinks rather than what they assume you're hoping for. A good structured interview works the same way. So does a well-built psychometric test item. The common thread across all of them is something like elicitation without leakage — pulling out a real signal without the act of asking corrupting it.

That feels like a better description of what's actually happening when a prompt works than "the right combination of tricks" ever did. And the UConn data backs it up reasonably directly — the lever that mattered was precise, theory-grounded specification of the thing being measured, which is more or less the exact discipline a psychometrician applies when trying to pin down something genuinely hard to define. The lever that mattered less was the technique-stacking most prompting advice is built around.

Where I've landed, for now anyway

Two things surprised me here that I didn't expect going in: prompting technique might not be the leverage point most content treats it as, and the better explanation for why isn't really pedagogy — it's something closer to applied measurement. Bloom's still has a seat at the table, I think, as a way of naming what kind of cognitive operation a prompt is asking for. But the discipline underneath that seems to be more about closing the gap between what you're actually asking for and what context, once you add it, quietly tilts the answer.

I'm not totally sure I've got this right, to be clear — it's an interpretation, and I'd genuinely like to hear where it breaks. I'm working up a more formal version of this for a white paper, where I can lay the research out properly. But this was the messier version, including the part where my first idea turned out to be the wrong one. If you've spent time in the prompting weeds and this rings true — or doesn't — I'd like to hear about it.

The case for letting your UI tell you what to build next

Ryan Brinn — Mon, 29 Jun 2026 18:02:36 +0000

There's a pattern I keep coming back to that sits somewhere between "chat interface" and "traditional app UI," and I've been trying to figure out whether it's actually interesting or just a cool demo that falls apart in production. I wrote a longer whitepaper on this, but I wanted to share the rough edges of the thinking here and see what resonates — or where I'm wrong.

The problem I kept running into

I've worked on software for over 20 years, and what's surprising is how much we still get wrong: Pendo found that 80% of software features are rarely or never used (the Standish Group puts it at 64%). Either way, it's a lot of engineering effort going nowhere.

The frustrating thing is this isn't a "bad engineers" problem. I think it's a signal problem. Teams build the wrong things because they have no reliable feedback loop between what users actually need and what ends up on the roadmap. Roadmaps get driven by whoever is loudest — escalated tickets, squeaky customers, whoever had the best slide.

Wouldn't it be nice if the interface itself could tell you what to build next?

That led me into Generative UI territory.

What I mean by Generative UI (and what I don't)

Here's the pattern I'm working with: an AI layer sits alongside a traditional UI — not replacing it — and handles requests the static interface can't. The key constraint: the AI generates structured data that selects from a fixed set of pre-built components. It does not generate arbitrary code or markup.

The most concrete production implementation of this is Vercel's AI SDK Generative UI, which originated from v0.dev and was open-sourced around 2024. The LLM calls predefined "tools," and tool results are passed to corresponding pre-built React components for rendering — the LLM never touches the component code itself. There's also a 2025 arXiv paper formalizing the framework and research from CHI '26 on semantic guidance for closing the gap between intent and generated output. The academic lineage goes back further through Ink & Switch's malleable software work and Horvitz's mixed-initiative UI research, but Vercel is where I'd point anyone who wants to see it running in production.

That schema-vs-code distinction matters more than it might seem, and I'll come back to it.

The "alongside" part is equally important. I'm not interested in the "everything is a chatbot now" approach. I'm interested in UIs where 95% of interactions still go through normal, fast, deterministic code — and the AI layer activates only when the user hits a ceiling. Two ways that activation can happen: the user explicitly reaches for it (they hit a wall and ask for something the UI doesn't support), or the system notices something and surfaces UI proactively, without being asked.

I've been spending most of my thinking time on the proactive case, because it's weirder and less explored.

The cost problem reframed

I think it is safe to say that: GenUI is structurally more expensive than a conventional web stack. Every request that passes through an LLM inference layer costs orders of magnitude more than a normal database query and render. That gap narrows as model costs fall but it never closes.

But I think people compare against the wrong baseline. The real comparison isn't "LLM inference vs. a database query." It's "LLM inference costs (cents per request) vs. engineering waste costs (hundreds of thousands of dollars per year building things nobody uses)."

If the AI layer generates demand signal — if every unresolvable user request becomes a labeled data point about what users actually want — then the inference costs are buying something that didn't exist before: a continuous, behavior-grounded product roadmap. Not "GenUI is cheap" (it isn't), but "GenUI's costs show up on the infrastructure budget while its savings show up in planning efficiency and reduced waste."

Whether that's convincing probably depends a lot on your org structure. I'm genuinely curious how others see it.

The graduation pipeline

This is the piece that made the whole thing feel deployable rather than theoretical.

Don't think of GenUI as a permanent runtime. Think of it as a temporary handling layer with a built-in exit ramp. The lifecycle: the AI layer handles a novel request and logs it ({intent, parameters, timestamp}). Once that intent crosses some threshold — say, 50+ occurrences over 90 days — it becomes a graduation candidate. The team ships a real hardcoded view. The AI layer routes that intent to the new view permanently. Inference cost for that pattern: zero, forever.

The AI surface area shrinks over time. You're paying inference costs early, when patterns are novel and uncertain, and cashing out into zero marginal cost later, once patterns are understood. The inference path keeps narrowing toward the genuine long tail.

The thing I'm still working out: what's the right graduation threshold? Frequency is the obvious answer, but I wonder if there are better signals — user confirmation rate on AI-composed views, task completion time, explicit "save this" actions. Haven't landed on this yet, and I suspect the right answer is domain-specific.

Where I've been actually building this: arr-mcp

The proactive variant is easier to think through in a concrete domain, so I've been prototyping against a home lab setup I already maintain — an open-source MCP server for self-hosted media stacks (Plex, Sonarr, Radarr, that whole ecosystem).

The core scenario: you pull a new container image. Without doing anything else, the system identifies what it is, surfaces a configuration form specific to that service in your current stack context, and pre-populates what it can infer. You answer a handful of questions. Dependent services get updated silently.

That works here because the domain has exactly the right shape for this kind of intelligence. The container runtime emits events you can observe. The canonical Plex + Sonarr + Radarr + SABnzbd stack is well-understood enough to encode in a static service registry. Setup is genuinely painful — API keys, library paths, inter-service connections — so there's real value in automating it. And the user base is split between power users who want full control and household members who just want it to work, which is exactly the population where proactive UI earns its keep.

The architecture I've been working with has three agents running in sequence: a domain agent that looks at the detected event and answers "what is this, what does it depend on, what does it replace?"; a security agent that runs in parallel and vets the image before anything happens; and a UX/component agent that takes both outputs and decides what the user actually needs to see. The UX agent doesn't act until both upstream agents resolve. A security block from the security agent halts the whole pipeline — no override except explicit, logged admin acknowledgment.

The confidence thresholds are where it gets interesting in practice. High confidence (>0.90): act and tell the user what you did. Medium confidence (0.60–0.90): surface a question, wait for confirmation. Low confidence (<0.60): flag it, don't guess. Security warning at any confidence level: block regardless. The numbers above are hypothetical — I'm still calibrating what they should actually be. If anyone has done empirical calibration of this in a deployed system, I'd genuinely love to hear about it.

The one architectural thing I feel strongly about

There are two architectures that both get called "Generative UI" and they have very different risk profiles. In one, the LLM generates structured data selecting from a closed, pre-validated schema — component code is written and reviewed by developers in advance, and LLM output is treated as untrusted input, validated before rendering. In the other, the LLM generates executable code or markup that gets run.

That second one is genuinely risky. It creates an LLM-controlled code injection vector. Indirect prompt injection — malicious instructions hidden in data the LLM processes — becomes an attack surface for the entire UI. Everything I've described above assumes the schema-generating model. The audit guarantees, the governance properties, the safety of proactive action — none of that holds if you let the LLM write code.

The weak point to watch even in the safe variant: an overly generic "escape hatch" component in your schema — arbitrary HTML, raw markup, iframes. Every component the LLM can select should be something a developer would have shipped on its own.

What I don't have good answers to yet

Confidence calibration at scale is the one that keeps me up a little. The thresholds I'm using are hypothetical and I suspect they're very domain-specific, which makes me wonder how much the approach generalizes.

Multi-agent conflict resolution is also unresolved for me — when the domain agent and security agent return conflicting signals, what does the UX agent actually do? I have a rough intuition (security wins, always) but haven't thought through the edge cases.

And I'm not sure this works at all in regulated industries. Auditability requirements are in direct tension with non-deterministic UI generation. The exception-path scoping probably helps — the AI layer is discovery and triage, not the system of record — but I haven't tried to make that argument to a compliance team yet.

Where I'm at

I'm in the early stages of building this out more seriously, and I'm less certain about the right approach than this article might make it sound. The home lab prototype is narrow enough that I trust it. Generalizing to production software products is where the interesting hard parts live.

If you've shipped something that looks like this — or tried and hit walls — I'd really like to compare notes. What broke? What surprised you? Where did the confidence calibration go sideways?

If you want the full architecture document with the cost/tradeoff tables and a minimal viable experiment spec, I'm happy to share that separately.