Liffy

Liffy sends your browser to GitHub, attaching a one-time random string it also stores in a cookie.

That random string is an anti-forgery measure. If the reply that comes back doesn't carry the same string, Liffy knows the reply was manufactured by somebody else and throws it away.

GitHub shows its own consent screen listing what Liffy is asking for: permission to read your repositories, and your username.

This screen is GitHub's, not Liffy's. Your password is typed into GitHub and never travels anywhere near Liffy.

GitHub sends your browser back to Liffy carrying a short-lived code. Liffy exchanges that code, server to server, for an access key tied to your account.

A short-lived day pass that expires after fifteen minutes, and a long-lived membership card good for thirty days that can be traded for a fresh day pass at any time.

Two passes instead of one because of what happens if a pass leaks. A stolen day pass is worthless in fifteen minutes. The membership card is stored in Liffy's own database, so if it is ever stolen it can be cancelled immediately — and it is replaced with a new one every single time it is used, so a copied card stops working the moment the real owner uses theirs.

Liffy walks the repository through GitHub's API, skipping images, compiled binaries and anything over 200 KB — those are almost always machine-generated bundles, not code a human wrote.

A parser called Tree-sitter reads the file the way a linguist diagrams a sentence — identifying which lines form a function, which form a class, where each one begins and ends.

This is the same technology code editors use to colour your code. Liffy uses it to find the natural seams in a file.

The file is split into chunks — one complete function or class each. A file in a language Liffy has no grammar for still gets chunked, just by fixed line windows instead.

This is the decision the whole system rests on. Chopping code every 50 lines regardless of content would cut functions in half, and half a function means nothing to anybody. Cutting at the seams means every chunk is a complete thought.

Every chunk is passed through a model that converts it into a list of 384 numbers. Chunks that do similar things end up with similar numbers.

Think of it as giving every function a position on a map, where distance means "how alike are these two pieces of code." Two functions that both validate an email address land near each other even if they share not one word. This model runs on Liffy's own machine — nothing is sent anywhere to do it.

The coordinates go into ChromaDB, a database built for exactly one question: given this position, what are the nearest neighbours? Every repository gets its own private shelf.

Separate shelves per repository, deliberately. Letting one project's code turn up while reviewing another's would produce confident, irrelevant advice — and would be impossible to debug.

Liffy records a fingerprint of every chunk's contents. Next time it re-reads the repository, anything whose fingerprint is unchanged is skipped.

So the first read is slow and every read after it is nearly instant — only what actually changed gets re-read.

A developer finishes a piece of work and asks for it to be merged into the project.

GitHub immediately sends a message to a dedicated address on Liffy's server. This is called a webhook — GitHub pushing news out, rather than Liffy repeatedly asking "anything new?"

The address is public, so anyone could send it a fake message. GitHub signs every message with a shared secret; Liffy recomputes that signature and compares. Anything that doesn't match is discarded unread.

Like a wax seal. Only someone who holds the same stamp can produce a matching impression — and the comparison is done in a way that gives an attacker no clue how close a guess was.

The knock carries only headline details, so Liffy calls GitHub back for the full diff — the exact list of lines added and removed.

The raw diff is one long block of text. Liffy parses it into structured pieces — which file, which lines, added or removed — keeping a map back to the real line numbers.

That map matters at step 11. A comment is only useful if it lands on the right line of the right file.

The job is put on a queue and Liffy answers GitHub instantly. A separate background worker picks the ticket up and does the slow part.

Reviews take tens of seconds. If Liffy held the line until it was finished, GitHub would give up waiting and the review would be lost. The queue also means a crash costs nothing: the ticket is still there when the worker restarts.

Each changed piece goes through the same model used during indexing, producing a position on the same map.

For each changed piece, Liffy pulls the five most similar pieces of existing code from that repository's shelf.

This is the retrieval step — the "R" in RAG, and the reason Liffy can say "you've written this before, over here" instead of guessing.

Liffy assembles one document for the AI: who it is meant to be (a senior engineer), exactly what shape its answer must take, the change under review, and the retrieved surrounding code.

The order is fixed on purpose — the unchanging part goes first so it can be cached between reviews, which cuts both cost and waiting time.

The model returns an overall summary, a verdict, and a list of comments — each pinned to a file and line, tagged with a category and a severity.

Liffy is not tied to one AI. The same slot accepts Claude, OpenAI, or a model running on your own laptop for free — the rest of the system doesn't change.

The reply is validated field by field against a strict schema. Anything malformed is rejected and the model is asked again. Then each comment's line numbers are translated from diff coordinates back to real file line numbers.

An AI can produce beautifully-worded nonsense. This step makes structural nonsense literally unable to enter the database.

Review and comments are written to the database, along with which model was used, how many tokens it consumed and how long it took — the raw material for measuring quality later.

The dashboard has been checking for updates the whole time. The finished review renders over the code diff in the same editor component that powers VS Code, each comment attached to the line it is about.

Each comment carries a thumbs up and a thumbs down. One click, stored immediately against that specific comment and that specific person.

Deliberately the smallest possible ask. A feedback form nobody fills in produces no data, and no data means no way to improve.

Once a week, a scheduled task walks every completed review and computes its approval rate. Reviews scoring below 50% are flagged for a human to read.

The flagged reviews get read. If the same kind of wrong comment keeps appearing, the instructions given to the AI at step 09 are rewritten to prevent it — and the next week's scores show whether that worked.

This is the loop that closes. Liffy does not learn on its own; it produces the evidence its builders need in order to improve it deliberately.