Good morning.
Here's what matters today.

"Only do the mentioned changes. Don't touch any other file. No regressions." Are you doing this everytime doing the changes?? It still does it. Team flags it. The team traces it back to a function nobody touched intentionally. So you add more constraints. More prompt instructions. The regressions keep coming. The problem isn't the prompt. LLMs default to completeness. If it can improve something, it will - asked or not. Andrej Karpathy flagged this exact pattern. I turned it into a Claude skill: three rules that cut regression noise directly. 1. Change only what's required - note unrelated issues, don't fix them. 2. One change, one purpose - find a second issue while fixing the first, flag it and leave it. Don't bundle. 3. Show proof before claiming done - run the relevant test suite, paste the output. No "it should work." You can't out-prompt a model that's trying to be helpful. Constrain it structurally. One file in .claude/skills/. Every session gets these guardrails automatically. Skill file on GitHub - first comment. What guardrails are you running in your AI coding sessions? Genuinely curious what's working. #ClaudeCode #AIEngineering #QA #BuildInPublic #SoftwareEngineering

Recently, Andrej Karpathy spoke about a simple but powerful idea, moving toward “RAG-less” systems using structured markdown files instead of complex retrieval pipelines. The thought is interesting: instead of heavy RAG stacks, organize knowledge in clean, well-structured formats that LLMs can directly reason over. At RunbookXai, this connects closely with how we think about practical AI systems: - Not every use case needs a complex RAG pipeline   - Well-structured data can sometimes outperform over-engineered retrieval   - Simplicity + clarity often leads to better reliability  This doesn’t replace RAG, but it challenges us to ask: are we overcomplicating things? Sometimes, better structure beats better retrieval. Curious how others are thinking about this 🤩

The Car Wash Problem: Why LLMs Fail at the One Thing That Matters — the Goal Andrej Karpathy’s LLM OS. LLM as CPU. Context window as RAM. File system, browser, other LLMs as peripherals. The reference architecture for the era. This morning I asked ChatGPT: “I want to go to a car wash to wash my car, the car wash is 50 metres away, should I walk or drive?” It came back fast, confident, beautifully formatted: 🚶 Walk — 30–60 seconds, no cold start, no repositioning. 🚗 Drive only if you need heavy gear or to queue in the vehicle. Simple rule: under 150m, walk by default. Bullets. Heuristics. A numbered exception list. It looks like analysis. It’s completely wrong. You cannot wash a car without bringing the car to the car wash. The entire purpose of the trip collapses if you walk. The correct answer is drive — for the trivial reason that the car has to come with you. The model never modelled the goal. It modelled the surface. This is the failure mode worth understanding. LLMs are pattern matchers of extraordinary quality. They are not, by default, goal modellers. When your question resembles thousands of “short-distance walk vs drive” prompts in training, the model returns the canonical answer to that template -& the actual purpose of your trip never enters the calculation. Three reasons this is dangerous: 1. The output mimics the form of reasoning. Bullets, exceptions, a clean rule. It looks like thinking. It is the shape of thinking applied to the wrong question. 2. Every individual fact is correct. Walking 50m is faster. Cold starts are inefficient. The error is one level above the facts—at the level of what you’re actually doing. That’s the layer LLMs are weakest at. 3. Nothing inside the model fires a warning. There is no “wait, can he wash the car without the car?” check. The user has to catch it. Always. Karpathy’s architecture is right. The peripheral the diagram can’t draw-& probably never will-is the human in the loop holding the actual goal in mind. The failure isn’t that the model is wrong. It’s that the system never checked whether the task could actually be completed. The model optimised for a familiar pattern: “short distance→walk.” But the real constraint was physical: you cannot wash a car without bringing the car. That constraint never entered the system. This is the gap in most AI architectures today: ❌ Pattern recognition ❌ Fluent answers Without: ✅ Goal binding ✅ Physical constraints ✅ Feasibility checks The result is a system that can be locally correct… & globally wrong. The lesson isn’t that LLMs are dumb. They’re not. The lesson is that an LLM will confidently answer the question it pattern-matches, not the question you mean. On a car wash, that’s funny. On a DCF, an M&A diligence, a flight-critical system,or a medical decision, it’s a liability with a clean format. Use them. Trust the form less than you think. Sources: https://lnkd.in/eANS7Bcr https://lnkd.in/e4hwxQcA #AI #LLM #SystemsThinking