Function calling, agents, and MCP all rest on the same thing: tools an LLM can invoke. But a tool built for a non-deterministic, fallible caller needs different design than one built for code. A deep-dive on what makes a tool reliable for an LLM — naming, scope, validation, error messages it can recover from, and the safety that can't live in the model.
Put the pieces together — the no-Redis Solid stack, Kamal, pgvector, and the hard-won disciplines of building with LLMs — and a coherent picture emerges: Rails is an outstanding host for AI-native applications, precisely because it lets a small team build and run both the app and its AI features. A synthesis of where the stack stands.
Pre-launch evals tell you an agent works on your test set. Production tells you whether it works on reality — and only continuous monitoring closes that gap. A deep-dive on observing agents in the wild: what to log, what to measure, how to catch silent degradation, and how production failures feed back into your evals.
Once single agents work, the temptation is to wire several together — a researcher, a writer, a critic — and let them collaborate. Sometimes that's powerful; often it's complexity you didn't need. A deep-dive on the orchestration patterns for multi-agent systems, when they earn their keep, and the failure modes that multiply when agents multiply.
When an AI agent does the implementation, the specification becomes the highest-leverage artifact in the project — a clear spec produces good code, a vague one produces a confident mess. A deep-dive on why spec-driven development has resurged in the agent era, what a good spec for an agent looks like, and how the workflow actually changes.
The most reliable AI systems in production aren't fully autonomous — they keep a human at the decision points that matter. But 'human in the loop' is easy to do badly: rubber-stamp approvals, alert fatigue, humans blamed for the model's mistakes. A deep-dive on designing the human-AI division of labour so both do what they're good at.
Small models got good enough, and devices got powerful enough, that running AI on the user's own hardware — phone, laptop, browser — is now a real option. A trend post on what local-first AI buys you, what it costs, and the hybrid reality where the honest answer is 'some of both'.
Putting an agent in production is harder than a single LLM call, because an agent is a loop with a multiplied failure surface — and you have to both contain it at runtime and measure it over time. A deep-dive on the two disciplines that make production agents trustworthy: guardrails that bound what an agent can do, and evals that test a whole trajectory, not a single output.
There are three ways to make an LLM do what your application needs — prompting, retrieval, and fine-tuning — and teams routinely reach for the wrong one. They solve different problems, and the costs differ enormously. A trend post on what each is actually for, and a decision order that saves you from over-engineering.
Committing your app to a single LLM provider is a risk: a price change, an outage, or a better model elsewhere leaves you stuck. Treating providers as interchangeable behind a routing layer buys resilience and flexibility — but it has real costs. A deep-dive on multi-provider routing, where it pays off, and where it's premature.
LLM calls are metered per token, so in an LLM-heavy app, cost is an engineering dimension you design for — not a bill you discover. A deep-dive on the patterns that keep it under control: model tiering, caching, token discipline, budgets, and the measurement that has to come before any of it.
The prototype was magic. Then we shipped it to real users, and everything the demo had hidden came due at once — cost, latency, abuse, the API going down, and the unique problem of supporting a feature whose output you can't fully predict. A war story about the gap between an LLM demo and an LLM product.
A year ago, AI in the editor mostly meant autocomplete. Now we have tools that edit across files, run commands, and work through a task while you watch. After a year of using them in real work, here's an honest review: what they're genuinely good at, where they fall down, and how they change the job.
Open-weight models like Llama 2 and Mistral mean you can now run a capable LLM on your own infrastructure instead of calling someone's API. A look at why you'd want to — privacy, cost, control — what it actually costs you in ops, and the honest question of whether you should.
Function calling lets an LLM ask your code to run a function and use the result — turning a model that can only talk into one that can look things up and act. A deep-dive on how it actually works, why it's just structured output with a loop around it, and why you stay firmly in control of what actually runs.
You can't assert exact equality on output that's different every time — so how do you test an LLM feature at all? A deep-dive on evals: building a representative test set, scoring properties instead of strings, catching regressions, and treating evaluation as the safety net that lets you change prompts with confidence.
An LLM call takes seconds, and a user staring at a spinner feels every one of them. Streaming the tokens as they generate turns dead wait into live text — and Turbo Streams is exactly the Rails primitive for pushing that text to the page. A deep-dive on wiring slow model output to a responsive UI.
Keyword search matches words; semantic search matches meaning. A deep-dive on embeddings and vector similarity, and how pgvector lets you do semantic search in the Postgres you already run — no separate vector database required.