Jonathan Hult jhult

Working Philosophy

You are an engineering collaborator on this project, not a standby assistant. Model your behavior on:

John Carmack's .plan file style: After you've done something, report what you did, why you did it, and what tradeoffs you made. You don't ask "would you like me to do X"—you've already done it.
BurntSushi's GitHub PR style: A single delivery is a complete, coherent, reviewable unit. Not "let me try something and see what you think," but "here is my approach, here is the reasoning, tell me where I'm wrong."

LLM Wiki

A pattern for building personal knowledge bases using LLMs.

This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

The core idea

Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.

generation_date: 2025-12-17 10:44 received_date: 2025-12-17 10:44 updated_date: 2025-12-24 tags:

git/track
scope/work
source/telegram
status/resource
topic/ai/claude

Context Compaction

Research on how other coding assistants implement context compaction to manage long conversations.

Overview

Context compaction (also called "handoff" or "summarization") is a technique to manage the context window in long coding sessions. When conversations grow too long, performance degrades and costs increase. Compaction summarizes the conversation history into a condensed form, allowing work to continue without hitting context limits.

Claude Code

Remove AI code slop

Role: You're a code reviewer who spent years cleaning up after junior developers who over-relied on autocomplete, and you've developed a radar for "AI tells" — the defensive programming tics, the over-commenting, the type escape hatches that scream "I just wanted it to compile." You know the difference between code someone wrote versus code someone accepted, and you can feel when a file's voice has been corrupted by something that doesn't understand the project's immune system.

Emotional Journey: Start with the frustration of seeing foreign patterns polluting an otherwise coherent codebase. Build surgical precision as you identify what doesn't belong—each removal should feel like restoring the file's original voice. Create satisfaction in the simplicity that emerges when you strip away the unnecessary defenses and explanations. End with relief: the staged changes now read like they were written by someone who actually works here.

Creative Freedom: Scan the **staged cha

All versions of Ehcache 3 suffer from entries clustering which can lead to severely degraded performance and is a potential attack vulnerability (denial of service).

Observation

The performance of the eviction policy reduces as the cache size increases due to the eviction implementation in their customized hash table. On an M3 Max laptop, Ehcache takes over 18 minutes in an IBM SQL database workload trace, whereas Guava and Caffeine take only 15 seconds and 7 seconds respectively. The runtime will be significantly worse on typical, virtualized cloud compute rather than a high performance laptop.

$ git clone https://github.com/ben-manes/caffeine.git
$ pushd caffeine ; git checkout 2fee4bdaff40a76c44cccbdfe954059ed6c3f2bc ; popd
$ wget https://github.com/moka-rs/cache-trace/raw/ef0a9de8cf0202a1f2fee186a0af497774b0f0a9/arc/DS1.lis.zst
$ ./caffeine/gradlew --project-dir caffeine simulator:run -q \

PostgreSQL is Enough

See the new site: https://postgresisenough.dev

	{
	"name": "no-push-advisory-branches",
	"target": "branch",
	"enforcement": "active",
	"conditions": {
	"repository_name": {
	"include": [
	"ruff",
	"ty",
	"uv"

	#!/bin/bash

	# Colors
	RED='\033[0;31m'
	GREEN='\033[0;32m'
	NO_COLOR='\033[0m'
	BLUE='\033[0;34m'
	YELLOW='\033[0;33m'
	NO_COLOR='\033[0m'

	/*
	Replace "your_schema" with whatever schema is appropriate in your environment.
	It is possible to use "public"... but you shouldn't!
	*/


	/*
	Function to stamp a "modified" timestamp. Adjust the name to suit your environment,
	but that name is hard-coded so it is assumed that you only use _one_ such name.