Llms

In the previous post, the important idea was that an editor is not a magical code mind… Visual Studio, VS Code, Neovim, and Emacs know how to display files and react to cursor positions. The deeper code knowledge usually lives in language services: parsers, syntax trees, symbol tables, type checkers, diagnostics, caches, and sometimes language servers speaking LSP. That explains how an editor can answer precise questions: what symbol is under the cursor? where is it defined? what type does this expression have? which references should change during a rename? where should this diagnostic squiggle appear? AI coding assistants start from a different place. ...

Most RAG demos stop at the happy path: split a PDF, embed the chunks, retrieve the nearest neighbors, put them in a prompt, call a model. That is the right starting point, but it leaves out the parts that make the system feel like an actual assistant instead of a stateless search box. I built a small agent in Python to explore those missing pieces. It is a FastAPI service with two main endpoints: /ingest for uploading documentation and /ask for asking questions against it. Under the hood it uses Redis Stack via redisvl for vector and full-text search, OpenAI for embeddings and answer generation, and Redis again for sessions, semantic cache entries, long-term memory, and metrics. ...

I had read about attention more times than I can count. Watched the 3Blue1Brown video, skimmed the Illustrated Transformer, half-read the paper. I could recite the slogan queries, keys, values but when I tried to picture what a single forward pass actually looked like in memory, I got fuzzy. Specifically: I was never sure, in a given diagram, whether each row of the attention matrix corresponded to one query or one key. That tiny ambiguity told me I did not really understand it yet. ...