6 posts tagged with "ai"

Introduction​

RSI stands for Recursive Self-Improvement: an AI system that improves itself, then uses the improved version to improve itself again. It is one of the milestones AI is expected to reach one day. In 1965, the mathematician I. J. Good put it like this:

Let an ultraintelligent machine be defined as a machine that can far surpass all the intellectual activities of any man however clever. Since the design of machines is one of these intellectual activities, an ultraintelligent machine could design even better machines; there would then unquestionably be an 'intelligence explosion,' and the intelligence of man would be left far behind.

I. J. Good, Speculations Concerning the First Ultraintelligent Machine, 1965

Introduction​

Every codebase eventually needs the same change in many places: a library swap, an API that changed shape, a convention the team agreed on last week. You know the usual options. Find and replace sees only text. Doing it by hand works for ten places and falls apart at three hundred. An AI assistant will happily make all three hundred edits, and then someone has to review each one.

In this blog, we will look at three tools that read code at three different levels. grep reads text. ast-grep reads structure, the syntax tree your editor already builds. A small local model, asked through classif, reads meaning. They are separate tools, each takes the part of the job it can see, and the interesting part is where each one stops.

Introduction​

In this blog, we will look at how programs make decisions about text, and how that changed once small language models started running on our own machines. Along the way, I will introduce classif, a small command-line tool I built that lets a shell script ask a local model a question and act on the answer.

I have 395 notes in Obsidian and ~2,800 memories from past AI sessions. My AI agent knows none of it unless I paste it in manually. And I can only paste what I remember to paste — which defeats the point of having a knowledge store.

So I built a hook that fires before every prompt, searches a unified vector store, and injects the relevant context before the agent thinks. R2R as the RAG backend, pgvector for storage, Ollama for embeddings, all on a homelab Kubernetes cluster. Total latency: under 100ms. Zero tokens consumed in the retrieval path.

The value isn't the search itself. It's what surfaces when you stop choosing what's relevant. Ask about a Kubernetes pattern and a six-month-old Obsidian note appears. Debug a tmux issue and a memory from a previous session shows up with the exact fix. The agent answers from your accumulated knowledge, not just its training data.

AI agents learn things about you as you work. Your coding style, your infrastructure quirks, which tools you prefer, how you name things. That context accumulates across dozens of sessions. But it evaporates when the session ends or when you switch tools. Use Claude Code in the terminal, Cursor in the IDE, and a web-based MCP client on your phone. Three tools, three isolated memory silos. You can share static knowledge with files. But the context that accumulates from your interactions has nowhere to go.

What if the memory layer was separate from the tools entirely? Redis Agent Memory Server does exactly that. It's an open-source memory service that speaks MCP over HTTP. CLI tools (Claude Code, Codex, Gemini CLI), IDE tools (Cursor, Windsurf, Copilot), and any web-based MCP client all connect to the same store. Because the server runs over HTTP, you can expose it beyond the homelab with Cloudflare Tunnels or similar, so tools outside your network connect too. The memory lives on your infrastructure, not theirs.

The server provides two tiers: working memory (session-scoped context that auto-promotes to long-term) and long-term memory (persistent, semantically searchable). It exposes both a REST API and an MCP interface.

I deployed it on my homelab Kubernetes cluster. Four pods, one PVC, zero API costs. Here's how.

Building a Deterministic vCluster Validation MCP Server to Ground AI in Real Schemas

You ask an AI to generate a Kubernetes manifest, Helm chart values, or Ansible playbook. It responds instantly with clean, well-formatted YAML. You apply it. Nothing works.

This isn't a bug—it's AI hallucination. The AI knows YAML syntax but hallucinates config options that don't exist, mixes incompatible versions, or confidently suggests deprecated fields. It generates what looks right based on patterns, not what is right according to actual schemas.