Another midnight I’m working on my side project; my child and wife are sleeping a few meters away.
I’m asking Claude to help out: write a plan, implement a simple feature. I do a review and the result is quite clean. Modified 9 classes in a few minutes.
But did the model follow practices? Project design, patterns, separation of concerns? Do we have documentation, do we know what and how in the project?
Continue reading How to Relate to AIIn 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.
Small Models Are Prompt Linters: How a Model Eval Turned out as an Agent Contract Refinement Exercise
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.
Continue reading How a Model Eval Turned out Agent Contract RefinementOccasinally 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.
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.