Blog¶

Hybrid RAG in Production: A Full n8n + Airflow Implementation

You've got the concepts — chunking, hybrid search, reranking, GraphRAG. This is the wiring diagram. A complete hybrid RAG system you can import and run: ingestion on Apache Airflow, the query pipeline on n8n, retrieval fused across dense, BM25, GraphRAG, and live web.

This is the companion build to Agentic Retrieval: The Complete Guide. Every technique there, ported into nodes and DAG tasks you can click, run, and adapt — with a local-first swap for every cloud component.

Building a Production RAG App: The Decisions, the Traps, and the Fixes

I built a full-stack RAG application — streaming chat, document ingestion, hybrid search, sub-agents, admin-managed model config — and most of the hard parts had nothing to do with calling an LLM. The LLM call is 20 lines. The other 95% is retrieval quality, ingestion correctness, and not blocking your event loop.

This walks through the real decisions and the traps I hit: where naive RAG breaks, and the exact fix that shipped. Every number here is from the running code, not a whitepaper.

All the code is open source: github.com/pkhamdee/rag. Every snippet below links to the file it came from, so you can read the full implementation in context.

Credit: the template's structure and workflow originate from the Claude Code Agentic RAG Masterclass

Build a Second Brain with Claude Code and Obsidian

Most note-taking apps are graveyards. You clip an article, it sits in a folder, you never read it again. The knowledge doesn't connect to anything. It doesn't compound. After three years you have 4,000 notes and can't find anything.

This guide builds something different: a self-maintaining knowledge base where Claude Code acts as your librarian. You dump raw material in. Claude reads it, writes structured wiki articles, cross-links related concepts, and files everything. You ask questions. The answers become new notes. The library grows smarter every time you use it.

The architecture is based on Andrej Karpathy's LLM Wiki pattern: a persistent, compounding knowledge base where an LLM does the bookkeeping you'd never do yourself.

Git Workflow for Release Management: Branches vs Tags

Most teams invent their Git strategy as they go. One developer starts tagging releases. Another uses branches. A third creates a hotfix branch and never deletes it. By the time you need to patch a six-month-old release, nobody remembers what release-final-v2 means or where hotfixes actually landed.

A clear branching strategy prevents this. This post covers a battle-tested Git workflow built around two parallel approaches — version control with branches and version control with tags — and tells you exactly when to use each.

Agent-Driven Software Factory: Replace Vibe Coding With a 12-Agent Pipeline

Vibe coding is not a software development process.

Fire a prompt, accept the result, ship it. Fast in the same way skipping tests is fast — until something breaks and you can't explain why. The output is plausible-looking code with no validated problem, no verified requirements, no threat model, no acceptance tests, no deployment strategy. One feature. Eleven things that were supposed to happen but didn't.

The Software Factory Agent replaces that with a 12-agent pipeline. One developer runs the chain. Specialized agents handle market research, product scoping, UX design, security, implementation, testing, validation, and deployment — each in its own clean context window with only the tools it needs.

Two modes. Discovery mode (12 agents) validates the market, defines the product, and designs the UX before any engineering starts. Feature mode (9 agents) skips straight to implementation for incremental work on an existing product.

CKA Mock Exam — Complete Questions & Solutions

Exam Rules Reminder

• Use sudo to edit files in /etc/kubernetes/manifests/
• Use sudo for kubelet restart and system-level debugging
• Use documentation links provided in each question
• SSH into the correct node as specified in the question
• Always verify the correct namespace before applying changes

The Karpathy Skill: Four Rules That Make You a Better AI-Era Engineer

Most developers use AI coding assistants wrong.

They fire off a vague prompt, accept the first 200-line response, and then spend the next hour debugging why the "helpful" code broke three other things. The tool is fast — the outcome is slow.

Andrej Karpathy — the Stanford AI researcher who co-founded OpenAI, led Tesla's Autopilot team, and built NanoGPT from scratch — distilled decades of engineering intuition into four rules that are now circulating as a CLAUDE.md template for AI coding assistants. These rules are not about AI. They are about how senior engineers think — and they happen to be exactly what you need to get great results from any AI coding tool in 2026.

This post unpacks every rule with the why, concrete examples, and practical habits you can start using today.

PostgreSQL High Availability with Patroni: 2026 Edition

Running a single PostgreSQL instance in production is a liability. When it goes down — and it will — so does your application. High availability is not optional for production databases; it is the baseline.

This guide builds a production-grade PostgreSQL HA cluster using the fully open-source community stack: PostgreSQL 17 from PGDG, Patroni 4.x, etcd 3.5, pgbackrest 2.58, and HAProxy. No vendor-specific packages. No proprietary repositories. Everything here runs on Rocky Linux 9 or AlmaLinux 9 and stays fully open-source.

PostgreSQL Performance Tuning for Application Developers (2026 Edition)

Slow queries are not a database problem. They are a design problem.

A query that takes 4 seconds on a table with 100 million rows almost always has a fixable root cause: missing index, wrong index type, table bloat, exhausted connection pool, or configuration defaults that were set for a 1GB dataset and never updated. Most performance problems are found — and solved — at the query and schema level before any hardware needs to be touched.

PostgreSQL Server Tuning: The Complete 2026 Configuration Guide

A freshly installed PostgreSQL server is configured to run safely on a shared laptop from 2005. shared_buffers = 128MB. work_mem = 4MB. max_connections = 100. These defaults have not changed in over a decade — and they are deliberately conservative so the server starts without crashing on anything.

Your production server is not a 2005 laptop.

This guide covers every postgresql.conf parameter that matters, the OS-level settings that underpin them, and a ready-to-use configuration reference for common server sizes — all updated for PostgreSQL 17 on Linux in 2026. It is the server configuration companion to the query and index tuning guide, which covers EXPLAIN, indexes, and PgBouncer.