Dagens Vibes — 20. juli 2026

Perry E. Metzger@perrymetzger

Hugging Face dealt recently with an AI operated attack. They had to use open models to defend, because the closed model guardrails would not allow them to use them for defense. Most important quotes: “When we started the log analysis, we first used frontier models behind commercial APIs. This did not work: the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker. We ran the forensic analysis instead on GLM 5.2, an open-weight model, on our own infrastructure. This had a second benefit: no attacker data, and none of the credentials it referenced, left our environment.” and: “We do not know which model powered the attacker's agents, whether a jailbroken hosted model or an unrestricted open-weight one; either way, the attacker was bound by no usage policy, while our own forensic work was blocked by the guardrails of the hosted models we first tried. The practical lesson for defenders: have a capable model you can run on your own infrastructure vetted and ready before an incident, both to avoid guardrail lockout and to keep attacker data and credentials from leaving your environment.” https://t.co/ilXiPUzAMA

Perry E. Metzger@perrymetzger

So what ever happened to the world falling apart if a model like Mythos got released without infantilizing restrictions on its use?

Peter Yang@petergyang

“We’ve got /loop, /goal, and workflows. They all get the agent to run for long periods of time.” Here’s my new episode with @trq212 from the Claude Code team, where he shared how he plans, builds, and runs loops with Claude Code: → How /loop, /goal, and workflows work differently → Live demo: Editing launch videos with Claude → Using HTML artifacts to plan and learn Some quotes from Thariq: “We cut Claude Code’s system prompt by 80%. As models have gotten smarter, they need less direction, fewer constraints, and fewer examples.” “Planning is an iterative process of exploring, investigating, and finding out what you don’t know.” “One failure mode I see is that people glaze over AI’s plans. You want to make sure it’s something you read.” I've been wanting to interview Thariq for a long time and I learned so much from this epsiode. 📌 Watch now: https://t.co/mMrt4D5qU7 Thanks to our sponsors: @RiversidedotFM: All-in-one AI studio for podcasts and video https://t.co/uWnS6aiMPE @WisprFlow: 4x faster than typing with your voice https://t.co/oqHJ8bN3ll

Dan Shipper 📧@danshipper

RT @frankhellend: cool read by @lauraentis from @every: over-engineering your agent skills may lead to the (newer/better) model underperfor…

aditya🇦🇷@adxtyahq

Yesterday I posted that I was able to cut a startup's LLM costs by almost 65-70%, bringing the average cost from around $3-4 per prompt to roughly $1-1.5 A lot of people asked how it was done, so here's the engineering behind it. Not every implementation detail can be shared, but the architecture and decisions definitely can The funny part is my first attempt actually made things worse. Cost went up to almost $5 per prompt, quality wasn't where I wanted it either. After weeks of rebuilding the architecture, refactoring pipelines, benchmarking every change and testing everything in production, it slowly became $5 -> $2.5 -> $2.2 -> finally around $1-1.5 The product itself was closer to a website builder like Lovable or Replit, so routing everything to Opus or GPT-5.5 was never going to scale. We skipped LangChain and LangSmith completely and built custom orchestration, prompt management, tracing, evaluation pipelines and model routing on top of the Vercel AI SDK because we needed much tighter control over the entire execution flow The first thing I added was a prompt classifier with multiple validation layers. Instead of treating every prompt the same, it classified scope, complexity, build vs edit and feature count before deciding what should happen next. That alone avoided a huge amount of unnecessary spend because simpler requests didn't need the most expensive models Another thing that helped was breaking every request into features and sub-features instead of generating everything together. Harder requests could have up to 6 feature groups, and every feature went through prompt validation, code generation, testing and regeneration if validation failed. That loop kept running until the output actually passed instead of hoping the first generation would be correct Generating an entire application in one shot also wasn't reliable, so we switched to generating file by file. Internally we followed a simple execution formula of 4*n + 5, where n was the number of feature groups and the extra five were the fixed steps every request always needed like preloading files, context skimming, prompt setup and routing. It wasn't some universal formula, just a simple way to keep the execution pipeline predictable After generation, the work still wasn't finished. Everything entered another agent loop where tool calls like web search, edit code and site testing kept running alongside validation. Only after every check passed did we stream the JSON output. If something failed, the pipeline moved back instead of letting broken code continue downstream We also added a preload strategy for context. Smaller projects loaded the full codebase, but once projects became large we only loaded referenced files and the relevant parts of the main files. Most requests don't need the entire repository in context, and cutting unnecessary tokens improved both latency and cost without hurting output quality Looking back, the biggest improvements had very little to do with prompt engineering. Better routing, validation, context management, execution loops and weeks of benchmarking mattered far more than changing a few lines in a prompt

Howaboua@Howaboua

I played around with the ChatGPT desktop app. Verdict: - Work mode looks absolutely fantastic and there are absolutely zero complaints about functionality, beyond maybe shared complaints about a bit of context bloat - but I do understand that Work is supposed to work without having to worry about it. - It would be cool if Work could manage its chats. I'd love a feature to tidy the hell up. - I am not entirely sure why I see Codex projects in non-codex modes. - Codex mode is fine, but once you tried Pi in a GUI or TUI, there is no going back to the token consumption that other apps have. I understand they are supposed to work out of the box for everyone, so this is a "me" thing and you need to decide if this is also a "you" thing. I asked it to research how I can integrate discord into Codex, it worked for like, idk 15 min, consumed 60% of the context. Suffice to say 60% in Pi would probably be enough to research, implement and test the thing (or at least the first version that doesn't quite work). - Yes, I did try to slim it down. Turning things off doesn't quite remove them from context, from what I observed, maybe I did something wrong, but stuff keeps a ppearing no matter what. - I am running 5 words as the base prompt, so that's not it. - No, I didn't have any extra skills beyond some basic bundled ones that I couldn't quite switch off. - It is weird that I cannot configure the Codex instance I ssh into? Or am I missing something? Yeah I suppose I could just ask Codex to reconfigure itself so it's slimmer, but then it starts losing to Pi quite badly. - The unofficial Linux installation for whatever reason doesn't like closing all the process, unsure why. Annoying. Just in case anyone is using it and isn't monitoring the resources. - I'm not going to review performance etc, it's an unofficial installation after all. So all in all, the desktop app is good. I only have complaints about the harness itself. But it's really hard to work in anything other than Pi, once you have fully kitted it out with optimised toolkit, lazy loaded skills/tools etc. I suppose time to resume work on howcode, as I believe my toolkit post 5.6 launch has now stabilised. Some minor issues here and there, but hey. Not enough time in a day.

Ryan Lopopolo@_lopopolo

This is the way. A folder full of markdown is, in fact, all you need for "RAG".

Adam@_overment

starting week 10 of my workout routine, guided by my agentic system across training, diet, habits, and mindset. the app is wired to the Action button on my iPhone and Apple Watch, with voice interaction, so I can easily add training notes, meal photos, etc. I think this has become my number one AI use case, as nothing else has had such a real impact on my life as this workflow. although the entire workflow is built on top of my custom system, created from scratch, the core idea is straightforward: - have two files: `workouts.md` and `diet.md` - tell the agent to create `[type][date].md` and wire it to the main files this can be done with pretty much any agent that can interact with the filesystem. note: I could undoubtedly do many things better here, but the overall plan was tailored to my personal preferences.