development – Pazsit's Dev Blog

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.

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.