Pazsit's Dev Blog – Skilled software developer and technical content creator with a focus on advanced Java, Kotlin, Spring Boot, and software architecture. Sharing tutorials, insights on coding practices, and explorations of software engineering concepts, to help myself :) and other developers improve their skills.

Teach Your Harness What to Forget

In the previous article we talked about the basics of how to customize your instructions, skills and hooks, and what they are useful for.

If you followed my guidance and did set up the Lessons instruction and worked on the project, you probably have some amount of Lessons as well next to the Memories.
This is great, the content loaded directly into your context is a short listed format, however this can still grow big.
I personally easily did create 1.4 entries per day, which can overly fill your context.

Your Lessons Are Costing You Context

Now let’s see how to tackle this situation and improve the cost-value ratio.

Make your harness Learn From Its Mistakes

How a Model Eval Turned out Agent Contract Refinement

Small Models Are Prompt Linters: How a Model Eval Turned out as an Agent Contract Refinement Exercise

I ran a five-model comparison to find out which model could drive my planner agent of my Forge agentic pipeline. I got back a code review of my prompt.

Building an Agentic Dev Pipeline — From Ad-Hoc Prompting to a Repeatable Protocol

My /forge pipeline starts with a planner agent. It interviews me, sends researchers into the codebase, and writes a plan.md that the coder agent implements without re-exploring anything. It had run on a frontier model since I built it, and I wanted to know whether a local model could take that seat. The planner is the most expensive stage, and it runs first, so every token it burns is spent before I know the task was worth doing.

So: a one-shot simple prompt, 4 models adn the pipeline. A frontier reference (Sonnet 5) plus three open-weight models I can host (qwen3.5-122b-a10b, qwen3.6-35b-a3b, qwen3.6-27b), producing plans, scored on contract compliance, grounding, hazard coverage, executability and consistency.

I got the ranking I wanted. I also got something I hadn’t gone looking for: a defect list for my own agent definition.

Make your harness Learn From Its Mistakes

Claude Code ships with a set of native building blocks for shaping how the assistant works. Instruction files (CLAUDE.md, AGENTS.md), shareable Skills, deterministic Hooks, and a self-managing Memory. Each one moves knowledge out of the chat window and into something persistent: conventions the model always honors, workflows anyone can invoke, guardrails the harness enforces, and facts that survive across sessions. The first four sections below cover those natives briefly, mostly to set the stage.

The real subject of this article is what sits at the end of that progression: Lessons: a small custom layer I built on top of Memory to turn Claude into something that actively learns from its own mistakes. Native Memory remembers what your project is; Lessons remembers what went wrong and how not to repeat it. Read the natives as context, then linger on Memory and Lessons, where the interesting part lives.

Token Efficiency for LLM assisted Development

How seven load-bearing principles across chat sessions and agentic pipelines, keep LLM dev costs manageable without degrading what the tools produce.

Occasinally I had a problem most people working with LLMs eventually run into: Long sessions forgot their own constraints. Multi-file investigations dumped thousands of tokens into the main context and never gave them back. Pipelines paid full price for content that should have been cached. None of it was the model’s fault, all of it needs only changing how you worked with the tools. The patterns below come experience and research about LLM assisted development to scale. Design choices about where to spend tokens and where not to.

One-line thesis: token efficiency is a design discipline, effectivness not being cheap.

Building an Agentic Dev Pipeline — From Ad-Hoc Prompting to a Repeatable Protocol

How eleven design decisions, a structured interview technique, and two effectiveness axes turned a slash command into a self-managing dev loop.

I had a problem that most people using LLMs for development eventually hit: inconsistency. Sometimes I’d get well-structured code with tests. Sometimes I’d get a half-finished implementation with no tests and no explanation of what changed. Sometimes I’d ask the same question twice and get architecturally different answers. The issue wasn’t the model — it was me. Every session started from scratch. No shared protocol. No handoffs. Just vibes.

The pipeline I built this week replaces that. It’s not a framework or a library — it’s nine files that define a protocol: who does what, in what order, with what information, and when to ask me before proceeding. The output is repeatable. The quality is auditable. And the design decisions that shaped it contain, I think, some generally useful lessons about building agentic systems.

One-line thesis: a well-designed agentic pipeline is a protocol, not a prompt.

Tuning RAG Retrieval Quality with the Autoresearch Pattern

Applying Karpathy’s autoresearch loop to measure and systematically improve RAG retrieval — from gut-feel tuning to +68% MRR across 8 eval runs.

A retrieval pipeline has a lot of knobs. Dense vs. sparse. Hybrid on or off. Time-decay reranking on or off. Per-collection fusion weights for every source feeding the index. I had built one with all of them, and I had gut feelings about every setting. Hybrid probably helps. Time decay probably helps for recency-sensitive queries. The fusion weights were whatever felt reasonable when I first wrote them.

What I didn’t have was a way to tell whether a change made things better or just different. Tweak a weight, run a few questions, eyeball the results — that’s not measurement, that’s superstition.

This article is the story of how I replaced the superstition with a small, fast evaluation harness, and how an automated loop borrowed from a recent Karpathy project ended up finding a +68% MRR improvement over the dense-only baseline I had been quietly running for months.

My Always-On Dev Environment pt. 2 – More Than One Stack

In part 1 I set up a Raspberry Pi 5 as an always-on dev box: code-server running as a systemd service, and a single PHP/MySQL/Vite project running inside Docker Compose. The whole point of keeping the host clean — no PHP, no Node, no MySQL installed directly on the Pi — was that the Pi was never going to stay a single-project machine. Sooner or later I’d want to run something else next to it without the two stacks fighting each other. This post is what happens when “sooner or later” arrives.

Running More Than One Stack on the Same Pi

The PHP/MySQL/Vite project is the one I’ve been using as an example, but the whole point of keeping the host clean is that it’s never just one project. The Pi doesn’t care what language a project is written in — it just needs a Compose file and a free range of ports.

The pattern I follow is simple and boring, which is exactly what you want:

One folder per project, each with its own docker-compose.yml.
One Docker network per project (Compose creates this automatically from the folder name), so services in different projects can’t accidentally see each other.
A port allocation note in my own head — or in a text file — so projects don’t collide on the host ports.

My Always-On Dev Environment on a Raspberry Pi 5

There’s a particular kind of friction every developer knows: you sit down at a different machine, your laptop instead of your desktop, or your phone while waiting for a train. Then suddenly your project feels far away. The repo isn’t cloned. The Node version is wrong. The database is empty. The ten minutes you had to jot down an idea evaporate into setup.

I wanted to get rid of that friction entirely. The result is a small, always-on development server running on a Raspberry Pi 5 in the corner of my room, and a setup where every device I own: desktop, laptop, Android phone. They’re just a different window into the same live project.

This article is the story of how that environment is built, why it’s shaped the way it is, and where its limits are.

Optimizing Relative Read Frequency Queries in SQL

My goal was just to create, test and use a relatively simple SQL query. Some complexity comes from aggregate functions and table self joins only.
I had 2 tables, article and view, where I store view count. I wanted to calculate a relative measure of read frequency, instead of absolute view counts. So recently published content is more comparable to older material.
To normalize this, we can calculate a views-per-day ratio and then compare all articles against the highest ratio one.

In this article, we’ll walk through:

Showcasing the schema and the goal to achieve.
Building the query that calculates relative read frequency.
Investigating indexing strategies based on execution plans.

Expanding on Property Injection with Spring Boot Auto-Configuration

In a previous post, we discovered how auto-configuration in Spring Boot enables bean and configuration creation.

Discover the Different Auto-Configuration Options in Spring Boot

In Spring, managing settings, configuring beans, or handling application constants, properly injecting properties into the environment is crucial. Here we’ll explore different methods of injecting properties in a Spring Boot auto-configuration setup.