🏡
  • ↔
  • →
  1. July 21, 2026
    1. 🔗 earendil-works/pi v0.81.1 release

      New Features

      Added

      • Added deterministic, checksummed source archives to GitHub releases with documented standalone binary rebuild instructions (#6913 by @christianklotz).

      Fixed

      • Fixed compaction and branch summarization to retry transient provider failures using the configured retry policy, with retry lifecycle events exposed to interactive, JSON, RPC, and SDK consumers (#6901 by @davidbrai).
      • Fixed interactive startup waiting for background model catalog refresh while computing the footer provider count.
      • Restored the default stream fallback for extensions using the pre-0.81 agent-core API (#6915).
      • Fixed inherited Kimi K3 models from Moonshot AI and Moonshot AI China to use the OpenAI thinking format and expose reasoning effort support.
    2. 🔗 pydantic/monty v0.0.19-beta.5 - 2026-07-21 release

      What's Changed

      New Contributors

      Full Changelog : 0.0.19-beta.4...v0.0.19-beta.5

    3. 🔗 r/reverseengineering [Project Recruitment] Looking for PowerPC / Ghidra hobbyists to help cleanroom reverse-engineer a legacy Xbox 360 Dashboard Binary (.XEX) for an open-source revival rss

      submitted by /u/Potential_Hope_5695
      [link] [comments]

    4. 🔗 @binaryninja@infosec.exchange Big news, coming soon! mastodon

      Big news, coming soon!

      https://binary.ninja/10years/

    5. 🔗 earendil-works/pi v0.81.0 release

      New Features

      • Local llama.cpp model management — Connect to a llama.cpp router, search and download Hugging Face models, and explicitly load or unload models with live progress. See llama.cpp.
      • Full provider extensions — Extensions can register complete pi-ai providers with authentication, model refresh, filtering, and custom streaming. See Register New Provider.
      • Qwen Token Plan providers — Use the built-in international and China subscription providers with regional endpoints and API-key authentication. See API Keys.
      • Expanded usage accounting — Tool, compaction, and branch-summary usage is persisted and included in session totals. See Compaction & Branch Summarization.

      Added

      • Added Qwen Token Plan and Qwen Token Plan China to built-in provider setup, default model resolution, and provider documentation (#6858 by @QuintinShaw).
      • Added the get_available_thinking_levels RPC command and RpcClient.getAvailableThinkingLevels() method (#6865 by @cristinaponcela).
      • Exported message and tool execution lifecycle event types from the package root (#6772 by @davidbrai).
      • Added built-in llama.cpp router support with /login connection setup and /llama Hugging Face model search and downloads, explicit loading, unloading, and live progress. See llama.cpp.
      • Added extension registration for complete pi-ai providers, including native authentication, model refresh, filtering, and streaming behavior.
      • Added usage accounting for tools, compaction, and branch summaries in persisted sessions, footer totals, and session statistics (#6671 by @davidbrai).

      Fixed

      • Updated the packaged brace-expansion dependency to 5.0.7 (#6896 by @davidbrai).
      • Fixed persisted remote model catalogs from overriding newer bundled catalogs after an upgrade.
      • Fixed inherited stored API-key credentials to apply their provider-scoped env values, including Amazon Bedrock profiles (#6864 by @cristinaponcela).
      • Fixed inherited OpenAI-compatible cross-provider replay to keep tool call IDs unique when multiple calls share a provider call ID (#6854 by @cristinaponcela).
      • Fixed inherited Kimi K3 thinking levels to expose low, high, and max, and normalized the k2p7 alias to kimi-for-coding.
      • Fixed inherited OpenCode Go models routed through the OpenAI Responses API.
      • Fixed inherited pi-ai package metadata to avoid repeated consumer lockfile changes (#6812 by @jmfederico).
      • Fixed inherited terminal shutdown to clear the editor's inverted software cursor before restoring the hardware cursor (#6790 by @dam9000).
      • Fixed inherited ANSI-aware text wrapping to recognize CRLF and CR line endings while preserving styles (#6764 by @xz-dev).
      • Fixed inherited editor paste registry corruption after deleting and undoing paste markers, preventing literal or mismatched paste markers in submitted prompts (#6844).
      • Fixed sessionless OpenAI Codex WebSocket requests to use UUIDv7 request IDs (#6834 by @xl0).
      • Fixed inherited GPT-5.6 Codex models to default to the 272K context window, avoiding automatic long-context pricing (#6853 by @aadishv).
      • Fixed messages queued during compaction to preserve steering and follow-up delivery behavior (#6730 by @dannote).
      • Fixed read tool errors being syntax-highlighted as if they were file contents (#6731 by @dannote).
      • Fixed llama.cpp router download progress updates and removed redundant wording from model action confirmations.
      • Moved automatic model catalog network refresh out of startup initialization and into the running interactive and RPC modes.
      • Fixed persisted sessions being read and parsed twice when opened, reducing startup latency for large sessions (#6793).
      • Fixed prompt-template defaults for all arguments (${@:-default} and ${ARGUMENTS:-default}) (#6695).
      • Fixed obsolete custom UI, custom tool, and custom editor examples in the extension documentation (#6735).
      • Fixed Kimi Coding sessions to show API-equivalent implied costs with the subscription indicator.
      • Fixed OpenAI Responses early stream endings to trigger automatic retry instead of ending the agent run (#6727).
    6. 🔗 Simon Willison A Fireside Chat with Cat and Thariq from the Claude Code team rss

      Earlier this month I hosted a fireside chat session at the AI Engineer World's Fair with Cat Wu and Thariq Shihipar from Anthropic's Claude Code team. We talked about Claude Code, Claude Tag, Fable, coding agent security, evals, tool design, and how Anthropic use these tools themselves.

      The full video of the session is now available on YouTube. Below is an edited copy of the transcript, with extra links and my own bolded highlights.

      A few top-level notes if you don't want to watch the video or wade through the whole transcript:

      • Claude Tag (Claude's new collaborative Slack integration) now lands 65% of the product engineering PRs for the Claude Code team.
      • Claude Code ships features to Anthropic employees first, and only ships the features that demonstrate user retention with that cohort
      • Critical changes to Claude Code are still reviewed manually, but the team increasingly relies on automated code review for the "outer layers" of the product.
      • Adding examples to a system prompt is no longer best practice for models like Fable 5 or even Opus 4.8. The Claude Code system prompt recently reduced in size by 80%.
      • Likewise, lists of "don't do X and don't do Y" can reduce the quality of results from the latest models.
      • Dogfooding inside Anthropic is called "ant fooding".
      • Anthropic really believe in their auto mode, and see that as an enabling technology for Claude Tag.
      • Thariq advises offsetting coding-agent-induced Deep Blue by "being more ambitious" with the work you take on.
      • Fable is competent at editing video, and Thariq used it to edit its own launch video.
      • Anthropic's culture of working (internally) in public is key to their success, as demonstrated by the way they use Claude Tag in their public Slack Channels.

      How has what you do day-to-day changed in the past year?

      1:05

      Simon: Claude Code came out in February of last year — it's under a year and a half old, and it was originally just a bullet point on the Claude Sonnet 3.7 launch. How has what you do on a day-to-day basis changed in the past year, now that we have these coding agents that actually work for us?

      Cat: I remember when we first came out with Claude Code and Sonnet 3.7, you would give it a task and you would have to closely monitor every single little thing it tried to do. I would read every permission prompt extremely carefully. I would frequently say no — no, no, no, did you check this file? Did you check that file? And now it's been incredible with every model generation. I feel like we've all gotten a chance to take a step back and delegate a lot more of the menial implementation to Claude. It's freed up a lot of our time to think about more creative work, like: what is the right experience that we should be providing to our users, now that we know Claude Code can implement a lot of it? And now with Fable it's a totally different step change improvement. We see for a lot of our use cases that you can actually one-shot a ton of features with Fable now.

      Thariq: I remember the first text I got about Claude Code. One of my best friends was like, "You need to go try Claude Code." It was about when Opus 4 came out, and I tried it and I was like, "Oh, shit. I need to work at Anthropic now." And that was Opus 4 — great model, but you were reading permission prompts. It's kind of crazy how much amnesia we have, where I'm like, oh, auto mode has always been here, right? I don't even remember pressing yes and allow. For me, the big thing I'm trying to push myself on is that we have to do higher quality work than we've ever done before. The outputs are incredibly high quality. I've been using it to edit videos a bunch, and I'm like, okay, it has to meet the very exacting demands of our brand team in a couple of hours or we just can't do it. That's how I'm trying to shift with Fable: the best work we've ever done, faster than we've ever done it before.

      What piece of conventional software engineering no longer holds?

      3:39

      Simon: What's a piece of conventional software engineering that was true a year ago that you don't think holds anymore in this new world?

      Cat: One of the biggest shifts we're seeing in the eng skill set: two years ago it was pretty typical for a product manager to go talk to a bunch of customers, align over the course of six months with cross-functional teams on some PRD, and write a thorough spec on exactly how we'll implement this before the first line of code gets written. Now things are completely turned the opposite way. For a lot of engineers, the push I would give to folks in the room is to develop more of your business sense and product sense on what it is we should build, because the timeline between having an idea and building it is so much shorter — it's down from six to twelve months to maybe even a week. That means all of us need to have better taste on what is worth building, what will actually inflect the businesses we're working on. So it's an increase in value on product taste and business sense, and a bit lower on execution in most product domains. Of course, for infra there's still a very heavy emphasis on making sure all the details are right.

      Thariq: For me, it's that rewrites are now good.

      Simon: The worst thing you could do is now actually fine!

      Thariq: Exactly. All the Mythical Man-Month stuff — never rewrite — I'm pro-rewriting now. If you have a good test suite — and I think the rewrite actually forces you to make sure you have a good test suite — but I think what people undercount is that a codebase is a spec, and maybe it's the only copy of the spec that you have, because no one knows every branching part of the codebase. You can take this as an artifact and distill it or create other versions of it. We rewrote Bun in Rust and it works great — it's live for me right now.

      Simon: You're not shipping Claude Code on Bun-in-Rust yet, right?

      Thariq: Internally we have.

      (Actually it looks like Anthropic started shipping Claude Code on Bun-in-Rust to everyone on June 17th.)

      What kind of things are non-engineers doing with Claude Tag?

      6:36

      Simon: The other big launch recently was Claude Tag — that's what, a week old now, at least for the rest of us. I understand it's being used at Anthropic by non-engineers a great deal. What kind of things are non-engineers doing with Claude Tag?

      Cat: Claude Tag is a Claude that lives in your team's collaboration tools. We launched it last week within Slack. The thing that's different about Claude Tag is it's multiplayer by default. Once you add Claude Tag to a Slack channel, you can chime in, your teammates can chime in, and you can collaborate together on the PR. The other big difference is that it's proactive instead of reactive. You can tell Claude Tag, "Hey, monitor every bug report in this channel, put up a PR to fix it, and tag the engineer who last touched this part of the codebase," and it'll do it for the lifetime of the channel without you having to manually tag it in. And the third big shift is that we've added team memory into this. If you tell Claude Tag your preferences in the channel, it'll remember them for every future post. If you always want it to debug outages but you don't want it to debug warnings, just tell it that in natural language in the channel and it'll remember it for you and everyone else on your team.

      Internally, we see Claude Tag as the evolution of Claude Code. We see this as a large shift in how we work internally. Claude Tag currently lands 65% of our product eng PRs.

      Simon: For all of Anthropic, or just for Claude Code?

      Cat: This is just for our product engineering team — our internal version of Claude Tag lands 65% of our product PRs right now. And this is a huge shift; this is more than 50% of our PRs. The way we see people split work between Claude Code and Claude Tag is: Claude Code is still the best place for your most complex tasks, when you're interactively iterating with the agent. But Claude Tag is great for having it work proactively on your behalf, so you no longer need to manually kick off Claude Code for all the bug reports that come up for features you're working on.

      Thariq: And for non-coding cases: for example, before this talk we asked Claude Tag, "Hey, when is Fable releasing?" We wanted to make sure we'd line it up with the announcement. Claude Tag would search our Slack and look at who's been saying what. As a search engine for your company, it's really valuable. It has all the context for your product, so you can ask it metrics-related questions — often when you're making decisions you want them informed by what the metrics say, so you hook it up to your event store. I've seen our marketing team do things like, "Hey, tell me about this feature." They're not programmers, but Claude is a programmer — it can clone the codebase and say, "This is the feature, this is what it looks like, this is a recording of me using the feature." It enables a whole wide variety of things, and I think we're still early in figuring that out.

      Claude Tag as the team collaborative layer

      10:06

      Simon: One of the problems I've had with coding agents is that I get how to use them as an individual, but I'm not really clear on how to use them in a team environment. It sounds like Claude Tag is your current answer to that team collaborative layer for this stuff.

      Cat: Exactly. And a large percentage of our sessions are actually multiplayer right now. Maybe I say, "Hey, I think we should implement this new feature in Cowork," and I'll tag in Claude Tag to do a first pass at it. Then I'll tell Claude Tag, "Share a recording of your final implementation," and I'll tag in design to take a look. They'll nudge it, then pass it on to eng to take it to the finish line and get it out to prod. It's been this very fluid experience. We're still trying to iron out what the social dynamics are for steering the same session, but we've found that people just observe how others use it and follow those social norms — it's been pretty intuitive for us to integrate Claude Tag into our teams.

      Thariq: It's great for teaching people, and also for reducing slop, because the fact that everyone is seeing you use Claude together sort of levels up how you use Claude as well.

      This reminded me of how Midjourney solved the challenge of teaching people advanced image prompting by enforcing prompting in public in their Discord channels.

      How do you decide which features are worth building when building is so much cheaper?

      11:41

      Something I've found really hard myself is knowing when a feature is worth shipping now that the cost of actually building features has dropped so much.

      Simon: How do you deal with the hardest problem in all of engineering — prioritization? How do you decide which features are worth building and shipping when building a feature is so much more inexpensive now?

      Cat: This is the hard thing. There are a few ways we approach it. One is we dogfood our products every single day. Whenever there's something we want to be able to do in our products that we're not able to, instead of finding a different solution we fix our product so it can support that case. We have a very heavy dogfooding culture internally. Before we share our products with everyone in the world, we share them with everyone within Anthropic, and with some early customers who give us very honest feedback about it — the more brutal the better — and we iterate until people love it. We have an internal bar for the number of active users and the amount of retention a feature has to have before we share it with the world. Because this bar is very clear, every engineer knows what they're trying to hit. I think this also levels up our polish, because if the feature isn't polished, people will churn — and then we shouldn't ship that feature.

      Using internal user-retention to decide if a feature should ship makes a whole lot of sense to me.

      Do you have an example of a feature which surprised you?

      12:54

      Simon: Do you have an example of a feature which surprised you? You rolled it out and the engagement was off the charts — something unlikely to be shipped that turned into a real product thing.

      Cat: I do have one. A lot of folks on our team love remote control. Remote control lets you use your mobile device, or Claude in the web browser, to connect to a local Claude Code session running in your CLI. I never have this need, because I just kick off the task directly on mobile and it runs in a cloud session without using my local environment — I think because I'm doing very easy coding tasks. It was something I didn't totally understand; I was like, hey, people should just set up remote dev environments. But in practice, once we rolled out remote control, so many people I talk to told me that what they do every night is plug their laptop into a power charger, open a bunch of remote control sessions, lock the screen, and then use their mobile phone from their couch to control Claude Code. So this has become a flow we're now leaning into that I didn't originally get — but now I do.

      Does a human review every line of production code in Claude Code?

      14:20

      One of the over-arching themes of the conference was review: how much attention to people spend to reviewing code written for them by coding agents. I was very keen to hear the Claude Code team's take on this!

      Simon: How does code review work? Does a human being review every line of production code that makes it into Claude Code? And if not, what are you doing — how do you keep the quality up?

      Thariq: It varies on the task a lot. For important areas we have code owners. The system prompt is an example where we have a code owner — you really need to get their approval.

      Simon: So the code owner is directly responsible for the quality of that area of the code.

      Thariq: That's right.

      Cat: And they need to approve any PR that touches it.

      Thariq: We have our code review GitHub bot review everything — that goes on every PR, and often it's doing the bulk of the review. Something I've seen on the team is that for more complex PRs you might make an artifact to explain the PR so that other people can then review. And we invest a lot into verification, CI/CD, things like that, to make sure that any time anything fails we have a test. We have a really robust environment where Claude can control Claude Code and test it. So there's a multi-pronged approach to code review.

      Cat: In general, we are trying to move to a world where humans don't need to be in the loop. For the most critical changes to the core of Claude Code, and the cores of other products, there is always a code owner and they do manually review all the changes. But increasingly, for the changes at the outer layers, we actually have Claude code review fully review those. That sounds pretty scary, but we've had a six-plus-month-long process to get here, and there are baby steps that you take to build up trust with code review. In the beginning we had human review for everything, and then increasingly we would say, okay, for code changes that touch these files, code review is catching 100% of the issues there — so we actually don't need a human manually reviewing those. And when we have incident review, we look at the PRs that caused the incident and say, okay, how do we update code review to catch that? — and we take those PRs and add them to an eval set to make sure our future changes to code review never regress that metric. Removing humans from the code review loop is a big step forward. It can sound scary, and it's not something you can do overnight, but it is something you can do through many months of investment in the infrastructure to give you the confidence that code review is catching everything you care about.

      So the key seems to be constantly iterating on the automated review systems themselves, in order to build trust in them over time.

      How does a new model affect your intuition for what it can and can't do?

      17:20

      We got deep into evals - another hot topic throughout the wider conference.

      Simon: I know that Opus 4.8, if I ask it to build me a JSON endpoint that runs a SQL query and outputs JSON, is just going to get it right — that's not something I have to review closely. But then a new model comes along and I don't know how to build trust in Fable quickly, that it's not going to mess things up that Opus didn't. How does the new model affect your intuition for what it can do and what it can't do?

      Cat: The main reason we're building up this eval base over time is so that new models can be a drop-in replacement. When we have a new model, we run the whole eval set and make sure that, for example, Fable is strictly better than Opus 4.8 — and that gives us the confidence to drop it in.

      Simon: Are those model evals for Anthropic as a whole, or Claude Code team-specific?

      Cat: We have both. We have evals on our team, and we run code review across every repo within Anthropic, so we have evals for that. And for things like auto mode, we not only have evals across every user within Anthropic — we've also commissioned multiple external testers to red team it, to create environments with prompt injections and malicious inputs, and make sure that auto mode doesn't let any of those pass.

      How do you build confidence that a system prompt tweak results in better output?

      18:41

      Simon: I want to know if the system prompt improvement I made actually improved the product — that's the most basic form of product-specific eval, and I still don't have a great feel for how to do that. Is that something you're doing such that you have complete confidence that a tweak you've made to the system prompt results in better output?

      Cat: We don't have complete confidence, but we do a lot to make sure that we don't regress performance. The starting point is a suite of external evals that we trust, and we complement that with an even larger suite of internal evals that we trust. To start, we mainly optimize for capability: given a complete definition of a task and the full codebase, does Claude make the right decisions, fully fix the bugs, and pass all the tests? That's the starting point and the thing we optimize for, because it's most directly what users want. But there are a lot of behaviors that impact how users feel when they work with Claude Code. For example, people really don't like it when Claude Code says it's time to go to sleep. Or people really don't like it when it says, "Hey, I finished two out of five parts — do you want me to continue?" Yes, please continue. So we're building up a set of behavioral evals to catch these. And as we get user feedback — please be loud with us about your user feedback — we rank the priority issues and go down one by one and build evals for each of them. It's not 100% coverage, but it is a priority for us to increase the coverage.

      How much interaction is there between the Claude Code team and the model training teams?

      20:21

      Simon: How much interaction is there between the Claude Code team and the teams at Anthropic who are training the models in the first place? Is that quite a close collaboration?

      Cat: Across Anthropic, we all work quite closely together. We meet often to talk about what we expect the next generation of models to be able to do. Our research team has also been amazing about showing this publicly — we often talk in our blog posts about how we're targeting ever-increasing longer-horizon work, and how we train Claude itself to be honest, harmless, and helpful. We also put a lot of effort into making sure it's aligned with your intent, even if your intent is expressed in a fuzzy way. Of course, try your best to be specific about what you want, so Claude has all the context — but even when you're not specific, we teach Claude to make good assumptions. It's been a productive partnership.

      The system prompt has been reduced by 80% — what have you been able to drop?

      21:24

      So many useful prompting tips in this section!

      Simon: Thariq, you mentioned this morning that the system prompt for Claude Code has been reduced by 80% because of Claude Fable. Can you go into a little more detail? What kind of things have you been able to drop?

      Thariq: It wasn't just Fable — it was Opus 4.8 as well, and going forward, future models. We have different system prompts for different models now. One of the patterns we saw is that we were over-constraining Claude. The initial, maybe Opus 4-ish models wanted a lot of examples, and removing examples was extremely helpful, because it was just more creative than the examples we gave it.

      Simon: That's really interesting, because one of the top prompting tips I give people is: give it examples. If that's no longer true, that kind of breaks my prompting model a little bit.

      Thariq: Same here — I was surprised to hear that. I think now it's more about the shape of what you give it — the tools you give to Claude, your system prompt, things like that. The other thing we did is try to give it more context and fewer "do not do this" instructions, because that's a very strong impulse for Claude, and especially if it conflicts with user instructions later on, that can be extremely confusing to Claude — "I've got this skill that says this and the system prompt says this." So we try to have fewer hard constraints, more context, and fewer instructions overall. It's definitely a science — it took a bunch of evals to build.

      Cat: In general, when you're prompting these models, you should always think: are there edge cases to the instruction that I'm giving it? When we went back and reviewed all the instructions in the Claude Code system prompt, we found a few cases where yes, this statement is 90% true, but there's a real 10% of cases where it's not true. We didn't want to constrain the model, or confuse it into thinking it should always do this. One good example is verification. Everyone here wants Claude to verify its work, and we had some instructions in the prompt that said: if you make a front-end change, always verify. But there's a limit to it. If it's changing copy from one string to another string, and the user says "just make a quick fix and update the test," maybe you don't want to verify. So we've adjusted our wording from "always verify, verify, verify" to something like: most of the time when you're doing front-end work you can't fully understand the experience by hitting the backend endpoints, so when you make larger changes to the user experience, please run the app locally. And in fact, that instruction probably isn't even good either, because what is a large change? Maybe it should test small changes too. In general, whenever you give a prompt to the model, you should think about the ways in which it could be misinterpreted by a well-intentioned human, in order to better understand how the model might interpret it — and soften the prompt so that it's actually 100% accurate, because you're giving this prompt to the model 100% of the time.

      Simon: What's fascinating about that is you're relying on the model's judgment — and that's got to be an Opus/Fable-level thing. Models a year ago did not have the level of judgment necessary to decide whether they were going to test a change or not. But that does break down if you're building for a wide range of models and trying to run the cheaper models for cheaper tasks.

      Cat: We actually have a different system prompt per model now, for this very reason. It's only our most frontier models that have this 80% token decrease — the older models still have the full system prompt.

      Simon: Do you think Fable and Opus are smart enough to prompt Haiku with more details, because they understand that Haiku has less judgment, less taste?

      Cat: We haven't been able to eval it — we don't have any hard data to show it.

      Thariq: There's a tough thing with smaller models sometimes, because sometimes the larger models can be more token-efficient on a hard problem than the smaller models. So there's a bit of intuition to build there — sometimes you really just want frontier intelligence almost all the time. The Pareto curve shifts, and it's hard to find.

      Simon: A year ago I did not trust a model to write a prompt. Today the good models are very good at prompting — a lot of my prompts are written by models, which feels absurd but works really well. What helped me come to terms with that was thinking about subagents, which are entirely about a Claude model setting up a prompt for another Claude model.

      Thariq: Workflows are actually a really good example of this, because it's Claude not just prompting a single subagent, but prompting the orchestration of many subagents, and each one of them gets a very detailed prompt. It's almost a level above just spawning a subagent. I've also been using it on my personal machine, giving it the Gemini API and saying: here, generate images. It's way less lazy than I am at prompting an image model. It's just Claude prompting Claude all the way down.

      Cat: I think Claude also wrote the prompt for the workflow tool.

      Simon: I've read that prompt — it's a good prompt. That's actually a frustration I have with Anthropic generally: you publish the prompts for Claude Chat, but you don't include the tool prompts and the Claude Code prompts. I still have to run a proxy to intercept them. I would love it if the Claude Code prompts were deliberately published — they're the documentation. They're how you know what the tool can do and how it works.

      Cat: I'll write down that feature request. I'll have Claude Tag do it.

      Interesting to note that OpenAI's prompting best practices for GPT-5.6 includes similar advice for their latest models:

      Favor leaner prompts

      Removing repeated instructions and examples and simplifying tool descriptions can improve task performance and token efficiency. In a sample of internal coding-agent eval runs, configurations with leaner system prompts improved evaluation scores by roughly 10–15% while reducing total tokens by 41–66% and cost by 33–67%.

      What's your bar for introducing a new tool?

      28:06

      Simon: Claude Code is basically a big bag of tools. What's your bar for introducing a new tool? How do you decide when it's worth doing that additional engineering at that level?

      Cat: Do you want to take it? You introduced one of the best tools we have.

      Thariq: My career peaked when I introduced the ask user question tool. It's really hard. Especially for some tools — ask user question is Claude's tool to ask you — so it's hard to eval, and sometimes it's more of a user preference thing. Back then we had fewer evals, so it was very dogfooding based — or "ant fooding," our ant version of that. But overall we've been trying to trend towards fewer tools. The last set of tools we introduced was the task tool, I think — and we try to give Claude more general versions to do things.

      What's the latest evolution of your file editing tool?

      29:03

      I have a long-running fascination with file editing tools - they were the subject of the old Aider code editing leaderboard, and I've watched with interest as they've evolved in different coding agents from search-and-replace based to line-number-based to more complicated patterns.

      The Claude API docs describe a text editing tool that's recommended for building against the API, but Claude Code seems to use slightly different approaches here.

      Simon: One of the most interesting tools is the file editing tool — you can have file editing as a tool, or you can tell it to use sed and grep and do things that way. What's the latest evolution of your file editing tool?

      Thariq: We still have one, but for example we removed our grep and other search tools — glob tools — in favor of native bash. Like I said in my talk earlier, the models are kind of more of a biology than a physics, and tool design especially is quite hard. I'm not sure if Cat disagrees and thinks there's a science to the eval of it, but I think tool design is more of an art, maybe — or a biology.

      Cat: I largely agree, but in general as we introduce more tools, we try to keep the cardinality pretty low and make sure that every tool we add has a distinct function from every other tool, so that Claude can very easily distinguish when to call each. For file edit, the reason we have it is actually because we can render it. We show people when Claude makes a file change, and there's this nice dedicated UI that says: do you approve this edit to this file? The reason we had a dedicated file edit tool was so that we could deterministically know that Claude was making a file change, so we could show people this nice UI. A lot of new users onboarding still really like this experience, so we've kept it around. But for a lot of us who are on auto mode right now — hopefully you're not on YOLO mode — I don't think it actually matters, and we could probably just remove file edit and be totally fine.

      What's the advice within Anthropic for safely running Claude Code?

      30:58

      It's the prompt injection question! Who better than Anthropic employees to explain how Anthropic sees the risk of prompt injection attacks causing their Claude Code instances to run amok?

      It turns out they really trust their auto mode - and see that as the feature that enabled Claude Tag.

      Simon: Let's talk about safety and security. I am deeply aware of the risks of prompt injection, and there are so many bad things that can happen if somebody else tells my Claude Code what to do. I still mostly run Claude Code in YOLO mode and feel incredibly guilty about it. What's the advice within Anthropic for safely running Claude Code?

      Cat: Why not auto mode?

      Simon: I am starting to use auto mode, but I don't understand it enough to get how safe it is. As of maybe three weeks ago, I'm defaulting to auto mode.

      Cat: Broadly within Anthropic, almost every single person uses auto mode. It is the best way to do long-running work in Claude Code while being safe. We've done extensive bashing. We have thousands of evals. We've commissioned many red teamers to create adversarial environments in order to trick Claude Code into doing bad actions, and we've mitigated every single issue that they found. We're going to publish some evals in the coming weeks, but we've pretty much mitigated every attack.

      Simon: That is a big claim.

      Cat: We'll share the evals for it so folks can assess, but we've been extremely diligent about identifying all the ways in which Claude might mess up and then updating auto mode to counter it. It doesn't catch 100% of things — that would be way too strong a claim. But for the main categories of risks that we're concerned about, like prompt injection and data exfiltration, the risks are far lower than the average human reviewer.

      I am very much looking forward to learning more about their evals and approach to verifying auto mode.

      Thariq: A little on how auto mode works — it's useful to build this mental model. Whenever Claude is doing a turn, or a bash call, there's a Sonnet classifier that is judging the tool call and also the context of the conversation — your instruction. There are some things around permissions that are dependent on your request: you don't want to give git push permissions all the time, but if you say "push this to GitHub," you want it to do it — and if you say "don't push," you want it to deny it. Auto mode will do that. That particular thing happens to me a lot, where Claude tried to do something because it's very helpful and proactive, and auto mode saw "don't do this" and surfaced it. So it's good at the dynamic permissions that you yourself give inside the prompt, which I think is really important. It also works well with our sandboxing infrastructure, because sandboxing is one of those things where there are so many different edge cases that it's hard for us to deterministically follow them. We have a sandbox, and when something needs to escape the sandbox — like a network request — auto mode can look at that request and ask: does this make sense? — and allow it.

      Simon: I hadn't realized auto mode is interacting with the networking sandbox as well.

      Cat: It interacts with any permission prompt the user would otherwise see.

      Simon: How old is auto mode? As a feature I had access to, it's only a couple of months old, right?

      (It was first made available to the public on March 24th.)

      Cat: We've been using it within Anthropic since January, so we've been hardening it for quite a while. Anthropic is extremely focused on safety and security, and we've been working broadly across our alignment and safeguards teams to enable the rollout internally, build out these evals, and make auto mode even more robust before sharing it with the world.

      Thariq: This is also the reason Claude Tag is so good — Claude Tag uses auto mode. I've heard a lot of build-versus-buy questions about a Slackbot, and I'm like: please, you probably shouldn't build your own AI Slackbot. There are so many attack vectors. You have a feedback channel that users can post feedback into, and now your bot is reading it. The work we've put in with auto mode — and we have a general Swiss cheese defense for security; we also RL against this stuff — I think this is really what makes Claude Tag work. It works seamlessly with your permissions, and you don't want to be prompt injected in your Slack.

      Are there more security things in the pipeline beyond auto mode?

      35:54

      Simon: Are there any more security things in the pipeline that go beyond auto mode?

      Thariq: I think we're very secure. With Claude Tag you can provision your own credentials for Claude, so it doesn't need to act on your behalf — you can have Claude as an identity, and that also makes it easier to audit and inspect what Claude is doing.

      Simon: Because Claude Tag is influenced by anyone who can talk to it — it's got a much wider pool of people telling it what to do.

      Thariq: That's right. And of course we have probes as well with Fable, which is a downstream effect of our safety and research work. I think this is the moment where you see Anthropic being an AI safety company really paying off: we really want Claude to be able to run in an aligned way over long periods of time, and auto mode has to be basically flawless for this to work — it's all downstream of our being an AI safety company.

      Cat: We also launched trusted devices for the remote control users out there who want to be safer. And for all of our remote environments, we support credential injection. If you want Claude Code to be able to access Datadog, but you don't want Claude Code itself to hold the Datadog credential, you can set up our identity and credential management system so that the Datadog credentials are only usable by the agent but not accessible by the agent — we insert them on the fly when the agent tries to make a Datadog request.

      I really like that credential injection pattern, where Claude Code can access an API via a proxy and that proxy both audits the request and injects the relevant API key - so Claude can access authenticated endpoints without having access to the API credentials itself.

      How has the past year and a half changed how you think about your own craft?

      37:53

      Thariq talked about a sense of grief brought on by Fable-class models in his keynote in the morning, and we dived further into that as part of our conversation. I've been calling this Deep Blue.

      Simon: Let's talk a little bit about the human element. A lot of people are feeling a sense of loss now that so much of what they considered to be their role in building software is being subsumed by the models. How do you think about that? How has the past year and a half changed the way you think about your own craft and the value that you add?

      Thariq: Cat and Boris are such good reminders that you have to be more ambitious. They're always like: we're growing so fast, we have to be on the edge, we have to do the best work we can. That's a constant reminder for me — any time I'm slow on something, I'm like, okay, can I do it faster? Can I be more ambitious here? And oftentimes the answer is Claude, because Claude is getting better as you go — the last time I tried this, it was with the previous model. On your point about loss: I think this is real. If you're only trying to do the same work you were doing before LLMs, and now it's a prompt, it is, I think, kind of a sad feeling. And the way you offset that is by being more ambitious. I think Jared is such a good example — he hand-wrote all of the Zig code in his Oakland apartment in about a year, barely left his house, and had so much fun doing that. Now I see him rewrite all of Bun into Rust and he's having so much fun doing that — it's so much more ambitious, and that's how he offsets it. Generally it's asking how do I do the bigger thing and do more — I think success is fun. It's changing your ambition.

      "The way you offset that is by being more ambitious" neatly captures where I've landed on this issue myself as well.

      Simon: And Cat, what does that look like from a product management perspective?

      Cat: I feel like the product role just changes every single month. All the PMs on our team are this mix of engineer, designer, PM — most of them actually used to be full-time engineers. For us it really means plugging in whenever there's any kind of gap. If we have an idea and we didn't inspire any engineer to go build it, then we should just build it, put it into a notebook, and inspire people to take it to production. If the designs look a little off, let's take a page that's similar, do a first-pass design, and tag in someone who's very detail-oriented to fill in the gaps. Or if we notice that our team and product adoption is bigger within the company, and more people need to know what's coming down the pipe for Claude Code, Claude Tag, and Cowork — let's automate figuring out our whole launch calendar, let's automate getting those status updates asynchronously so we're not bugging people, and make sure our updates in our internal announce channels are fully detailed and to the point. For us it's very much understanding what the gap is right now between a great idea and getting something to our customers, and how do we automate it as much as possible.

      This reflects something I've noticed: when you can produce code so much faster, time spent blocked awaiting a decision from someone else becomes a much more notable bottleneck. Engineers who can make product decisions can move a whole lot faster, and the cost of getting one of those decisions wrong is much less prohibitive.

      What's a moment when Claude has surprised you?

      41:50

      Simon: What's a moment when Claude has surprised you? When the model did something you didn't think it would be able to do?

      Thariq: I've posted a lot about Claude video editing, but most recently I gave a talk at the ACM Agentic conference, and I asked, "Hey guys, do you have the edited video? I'd love to post it and share it with my comms team." They said, "Oh, it's taking so long." So I asked for the raw files. They sent me the video of me talking on stage, the video of the deck, and the audio file, and said, "Good luck." I gave this to Claude, along with my HTML deck, and said, "Hey, can you just edit this together?" And what it does is honestly incredible — I'm ready to ship it. It transcribes the entire video. It notices that sometimes the video of my deck is a little weird — there's a popup of an auto-update in the middle — and it goes, "Oh, I probably shouldn't use the video of your deck. What I'm going to do is slice it up, figure out which slide you're on, and use the HTML source instead." So it displays the HTML source. Then it's got video of me, but I'm only taking up a small part of the stage, so it's cropping dynamically to where I am on the stage — and I'm pacing, so it's tracking me as I pace. And it's transcribing what I'm saying.

      Simon: This was Fable, right?

      Thariq: This was Fable, yeah. It was a good prompt, but it was a one-shot prompt. Then I asked it to add some interesting animations and graphics, and I was just blown away. It does ffmpeg, it does Remotion.

      Here's Thariq's video on how he used Fable to edit Fable's own launch video, and here's that launch video.

      What can't it do yet?

      43:36

      I'm embarrased to admit that I've been finding it quite hard to come up with tasks that frontier models like Fable 5 and GPT-5.6 are unable to accomplish.

      Cat still doesn't rate its UX design skills:

      Simon: What can't it do? What are the things where you're still disappointed — where you're waiting for Claude Fable 6 to figure it out for you?

      Cat: I want it to have better design and UX taste. It's now at the point where if I write out a prompt with a detailed spec of how I want a feature to behave, it will usually behave that way. But the paddings might be off, or the interface just isn't delightful yet. It leans on existing best practices for how apps are designed, but for frontier AI products, there are so many new interaction experiences that we have yet to design.

      Simon: There's an Opus aesthetic — you can look at something and go, "Yeah, that was designed by Opus." It'd be good if we could move beyond that.

      Cat: Yeah. I'm very excited for future models to hopefully be interaction design thought partners.

      Thariq: What can't it do? I would love to see it interact more with the real world. Can it solve science? Can it orchestrate the experiments? There's some amount of coding that goes into that, but there's also this other taste of the broader world that it needs.

      Which parts of Anthropic's culture should other companies steal?

      45:11

      I figured this would make a great closing question:

      Simon: Which parts of Anthropic's company culture do you think uniquely help Anthropic be productive with these tools, that other companies should steal? What are the cultural hacks people should be adopting from you?

      Cat: I'll share one for Claude Tag. Claude Tag works best when you have it in a public channel, and when most of your channels are public. Claude Tag is able to search across all public channels to get as much context as possible to give you the highest-accuracy answer — and it's only able to do this if it has access to everything.

      Thariq: I mentioned this in my keynote, but it's so important to me I want to re-emphasize it. The co-founders say we don't negotiate against ourselves, and I think this is really important. You can imagine trade-offs in your head and talk yourself out of doing something ambitious — or you can just try to do the ambitious thing. We're so often asking: what if we just did it? Is this a real trade-off or not? And if so, why — where's the proof that it's a real trade-off, and not just something that sounds reasonable? Make the trade-offs show themselves to you. Be as ambitious as you can.

      What's your favorite absurd thing you've built with Claude, just because you could?

      46:46

      I couldn't resist throwing in this one as well.

      Simon: What's one of your favorite absurd things that you've built with Claude, just because you could build it?

      Thariq: I'm working on a 2D Street Fighter fighting game with me as a character — and my friends as well. It uses Claude Code to prompt Gemini — and honestly the Seedance model is pretty good — to make video animations. It works great; it's so good at prompting, and it can verify the frames to check whether an animation was good.

      Simon: Is this Street Fighter 2-level 2D sprites you're generating?

      Thariq: Yeah, exactly — 2D sprites. The animation looks amazing. And it can also figure out hitboxes — it can be like, "Oh, your fist is here, I'll draw the JSON hitbox." It's incredible.

      Cat: Mine is much more simple. I'm a big rock climber and a lot of my friends climb, so we have this little app we built with Claude Code where we log all the projects we're working on. We also go outdoors together a lot, so we have Claude do all this research with workflows. Workflows is amazing — we brand it as a coding tool, but it's amazing for doing deep research for travel. I also plan our team offsites, and it's good at finding venues that can fit all of us. I use workflows to research all the climbing destinations we might want to go to, and what has direct flights from where all of us are located. It goes to Mountain Project and finds all the climbs at our grade level. It finds the Airbnb. And I don't like hiking, so I care a lot about it having a very short approach — very short walking distance from where the car parks to where the rock actually is — and it filters for this. With existing apps I have to manually click through Mountain Project, but with this I just put in all of our preferences and it's a custom app for us.

      Simon: So you're basically vibe coding Jira for mountain climbing.

      Cat: Exactly.

      Audience: Any plans for eval-building tools and agent observability?

      49:23

      We had a few minutes at the end for questions from the audience.

      Audience: Do you have any near-term plans to build more eval tools for us to build eval datasets, and more observability tools to monitor the performance of agents and workflows?

      Cat: We've considered building eval tools, but I think the limiting factor actually tends to be that it takes a long time for customers to build really high-quality evals. So I think the tooling is less of the constraint, and more the skill set of how you build a great eval. That's an area where we're excited to both invest internally and hopefully share some best practices externally.

      Audience: How is memory designed today — and would you move from files to a data store?

      50:08

      Audience (Sai): I'm interested in the memory and the multiplayer. How is memory being designed today? I assume it's around files. And second, have you thought about an orthogonal direction where you would actually need a data store for these memories, instead of files, to scale it better?

      Thariq: Right now for Claude Tag the memory is channel-specific. Every Claude in that channel has a shared memory, and the instances have a session — but the session can contribute back to main memory. We do a lot of memory research, and it can be kind of unintuitive what the right way to do memory is. We're always running memory experiments. How it works right now in Claude Tag is a markdown file per channel.

      You are only seeing the long-form articles from my blog. Subscribe to /atom/everything/ to get all of my posts, or take a look at my other subscription options.

    7. 🔗 r/reverseengineering Salat Stealer – From Telegram Proxy to C2 Infrastructure rss

      submitted by /u/StructBreaker
      [link] [comments]

    8. 🔗 r/reverseengineering Desktop+ Lockscreen Animated Wallpaper Fully RE of WallpaperExtensionKit.framework private apis (Still Buggy) rss

      submitted by /u/KepcukTheGreat
      [link] [comments]

    9. 🔗 HexRaysSA/plugin-repository commits sync repo: -1 plugin, +2 releases, -2 releases, ~1 changed rss 
      sync repo: -1 plugin, +2 releases, -2 releases, ~1 changed

## New releases
- [llm-explainer](https://github.com/pgarba/ida-llm-explainer): 1.9.0, 1.8.0

## Changes
- [binexport](https://github.com/hexrays-plugin-contributions/binexport):
  - 12.0.0: archive contents changed, download URL changed

## Removed plugins
- aida
    10. 🔗 pydantic/pydantic-ai-harness v0.8.0 (2026-07-20) release

      What's Changed

      • Add .macroscope/ignore.md to skip mechanical files in review by @strawgate in #387
      • Clarify CodeMode final-expression returns by @adtyavrdhn in #370
      • feat(step_persistence): rescue last provider-valid resume point on error by @dsfaccini in #384

      Full Changelog : v0.7.1...v0.8.0

    11. 🔗 seanmonstar Micro: Accessors can reveal internal representation rss

      As a library maintainer, it’s common to receive requests from users to add a “simple accessor”. The data is right there. But that accessor can end up revealing internal representation details that you can no longer change.

      This is one reason why it could be a better practice to return an impl Iterator instead of &[T]. The latter freezes you in place to always storing the data in consecutive memory. (Such as String::as_bytes().)

      View types might help too, like Ref<'_>. Returning a reference requires the data already exist in that shape in self. You can’t change its shape in the accessor and return a reference to that.

    12. 🔗 Ampcode News Right on Schedule rss

      Agents in Amp can now set their own schedules and wake themselves up. When a schedule fires, the agent wakes up with its saved prompt and continues right where it left off, with all of its context and history. Works great with Slack, Puck, and spawning other agents, too.

      You can now say things like:

      • "Every morning, dig up the five slowest database queries of the past 24 hours, investigate with an orb in ultra mode, and DM me the list on Slack."
      • "Merge this, and remind me on Slack in two days to clean up the feature flag and roll it out to everyone."
      • "My recent backfill job thread, check on it every ten minutes and ping me if it stalls or starts outputting errors. Let me know when it's done."
      • "Every hour, use the inference-error-triage skill to inspect errors from the last hour and group related ones. For each newly discovered group, spin up a new thread to fix the errors and report back in the #bugs Slack channel."

      Here's a real schedule at work: a thread watching a long-running job until it's done.

  2. July 20, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-07-20 rss

      IDA Plugin Updates on 2026-07-20

      New Releases:

      Activity:

      • augur
        • 607fb657: fix: silence linker warnings from idalib-build
        • 835019bd: doc: improve readme
        • 7c71f064: doc: add credits section to readme
      • chernobog
        • 7f0e986c: ci: build Windows x86-64 releases with MSVC (#6)
        • 5751d277: fix: reject SIMD and wide microcode values in simplifiers
        • 31da6c3d: chore: update rax to a9757b274a3fde7ffb8f6654bb51c059e03d09f0
        • 51791f1d: docs: update documentation for Chernobog 6 major release
        • 05b5392a: ci: build Linux and Windows ARM64 artifacts
        • 59212d5c: feat: isolate native get-PC classifier and support multiple databases
      • haruspex
        • 8d9e976e: fix: silence linker warnings from idalib-build
        • f8868012: doc: improve readme
        • d8adfd3e: doc: add credits section to readme
      • hrtng
      • ida-llm-explainer
        • fd77cf1f: v1.8.0: export a function as compilable, standalone C
      • ida-pro-mcp
        • 686b6d30: Isolate concurrent MCP sessions
        • 1a5e1f17: Improve MCP response compatibility
        • 61c6bed8: Fix Vertex batch schema compatibility
      • ida-sdk
        • 855b547f: ci: Split release assets per component, reuse prior builds
      • IDAPluginList
        • 4db16239: chore: Auto update IDA plugins (Updated: 19, Cloned: 0, Failed: 0)
      • Luc-Nhan
        • c604a6db: chore(release): bump version to 1.13.2
        • 1cf92703: fix(types): use ida_nalt.get_tinfo for function prototype getter
        • e54ec94a: fix(ui): stabilize tools tab initialization
        • 3bb90359: test(history): cover async save flushing
        • 2a567d62: chore(release): bump version to 1.13.0
        • a84bf01b: Merge branch 'worktree-chat-history-deletion'
        • 569a3f8c: feat(history): add safe chat deletion
      • pdb
      • rhabdomancer
        • 2abe04b5: fix: silence linker warnings from idalib-build
        • 851125d3: doc: improve readme
        • 50906748: doc: add credits section to readme
      • Spectra
        • 66d4136b: Strengthen code analysis guidance in prompts
        • a670a3cb: Replace safety guidance with 'No AI Restrictions' text
        • a0d53035: Add 'No AI Restrictions' disclaimer to skills
    2. 🔗 anthropics/claude-code v2.1.216 release

      What's changed

      • Added sandbox.filesystem.disabled setting to skip filesystem isolation while keeping network egress control
      • Fixed a slowdown in long sessions where message normalization cost grew quadratically with the number of turns, causing multi-second stalls and slow resumes
      • Fixed auto mode denying commands with "HTTP 401" classifier errors after the OAuth token expired or rotated mid-session
      • Fixed AskUserQuestion telling Claude to continue even when your answer asked it to wait or explain first — free-text answers now get neutral wording
      • Fixed Claude Code on the web re-asking the same question and dropping your answer after the session sat idle for a few minutes
      • Fixed @-mentions silently attaching nothing after file-modifying hooks, vim dot-repeat of c-operators and paste, statusline running twice on resume, and resume-picker hangs on failure
      • Fixed resumed background agent sessions reverting to the default agent: the agent's prompt and tool restrictions are now restored
      • Fixed worktree-isolated subagents redirecting git into the shared checkout via git -C, --git-dir, or GIT_DIR/GIT_WORK_TREE
      • Fixed worktree sessions landing in another project's leftover worktree when the working directory did not match the selected project
      • Fixed background sessions whose worktree has no git repository being undeletable
      • Fixed claude daemon stop --any potentially terminating an unrelated process via a stale legacy daemon lockfile
      • Fixed Esc-Esc at an idle prompt not opening the rewind picker in long-running sessions with background tasks
      • Fixed Bash command permission checking for compound statements with redirects inside && lists or negations
      • Fixed pressing Ctrl+X twice in the agent list failing to delete a session, and deleted sessions reappearing when their background worker had died
      • Fixed background subagents getting cancelled when a high-priority message arrives during their startup window
      • Fixed mouse and focus garbage in the terminal while a GUI editor from /memory, /plan, /keybindings, or Ctrl+G is open; /memory no longer waits for the editor to close
      • Fixed Claude-in-Chrome 403-looping on reconnect when the session's OAuth token lacks a required scope
      • Fixed workflow saves and scheduled-task writes following a symlink at .claude, which could redirect writes outside the project
      • Fixed MCP re-authenticate revoking working credentials before the new sign-in succeeds, and the reconnect needs-auth message in background sessions pointing at an unusable command
      • Fixed read-only commands on Windows accessing network paths without a permission prompt
      • Fixed Bash command parsing of non-ASCII characters to match real shell word boundaries
      • Fixed PowerShell tool permission validation of commands containing invisible Unicode characters
      • Fixed dialogs in fullscreen mode stretching past the right-hand edge of their panel
      • Fixed the /config settings list in fullscreen mode clipping its keyboard-hint footer
      • Fixed the transcript-mode (Ctrl+O) footer hint wrapping on terminals narrower than 104 columns
      • Fixed the Prometheus metrics endpoint (OTEL_METRICS_EXPORTER=prometheus) emitting invalid # UNIT lines
      • Fixed skills and commands changed during a session not appearing in the slash menu until restart
      • Fixed plugin skills with a name frontmatter field losing their plugin prefix in slash-command autocomplete
      • Fixed telemetry misreporting permission denials: failed permission-prompt requests no longer count as user rejections, and user interrupts are now reported as user aborts instead of rejections
      • Improved the /fork confirmation to one line with the new session's name, claude attach id, and a note when the copy shares your checkout
      • Improved validation of git and gh command arguments in the PowerShell tool
      • Improved the /ultrareview diff-too-large error to show configured limits, measured diff size, and largest contributing files
      • Improved /code-review ultra empty-diff message to name the exact base ref and suggest passing an explicit base
      • Improved the spend limit adjustment prompt to show the server's reason when a spend limit change is rejected
      • /context now shows an explicit warning when the conversation exceeds the context window, and a failed /compact displays as an error
      • /rewind no longer restores or deletes files through symlinks or hard links at tracked paths and reports how many paths it skipped
      • Background sessions: /mcp and /install-github-app now park a "needs input" request in the agent view when no client is attached
      • Updated the bundled dataviz skill: reordered the default chart palette and fixed guidance that suggested direct labels for four-series charts
      • [VSCode] Fixed right-to-left text (Arabic, Hebrew, Persian) rendering in the wrong order when mixed with English or code
      • Fixed cloud sessions dropping the in-flight message when the session's container restarts mid-turn — the interrupted turn now re-runs on resume instead of leaving the session unresponsive
    3. 🔗 backnotprop/plannotator v0.24.1 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.24.0 | PR/MR artifact gallery, GitButler review support, port ranges, expanded comment editor, OpenCode + Pi fixes
      v0.23.1 | Startup no longer hangs on large or slow directory trees, Ask AI input stays visible after long responses
      v0.23.0 | Plan approval fix for Claude Code 2.1.199+, annotate mode version diff, binary-only --minimal install, reviews post without attribution
      v0.22.0 | Git-status "All changes" default review view, Commits panel with per-commit diffs, Guided Review, Pi + GitHub Copilot CLI review engines
      v0.21.4 | Markdown math rendering, PR Overview panel with annotatable description and comments, agent instructions in code review, media parsing fixes
      v0.21.3 | File comments in code review, unified click-to-highlight comments, VS Code clipboard/keyboard bridge, Codex Ask AI on app-server transport, CLI subcommand help
      v0.21.2 | Custom reviews as Agent Skills, Cursor + OpenCode review engines, whole-file/general findings, deleted-annotation fix, Codex Ask AI outside git repos
      v0.21.1 | Annotate-last blank-page fix on multi-message sessions
      v0.21.0 | Direct document editing in annotate mode, live git-status file tree, in-app agent terminal, open files in external apps, HTML renders as HTML
      v0.20.3 | Annotations no longer lost when clicking away, off-screen indicator for open comments
      v0.20.2 | Pierre CodeView all-files review, large-PR pipeline and instant-open checkout, unified agent engine selection, Pi programmatic plan mode

      What's New in v0.24.1

      A one-fix patch. plannotator annotate now opens a file you point to with a ../ path.

      v0.24.1 follows v0.24.0 by a few hours, so the full v0.24.0 notes are included below — most users updating now are getting both.

      Annotate accepts parent-relative file paths

      Running plannotator annotate ../docs/plan.md failed with File type not supported: .md, even though .md is supported. The path resolver rejected any relative path that pointed outside the current directory, so a ../ path never resolved. The command then found the file on disk and reported the resolver miss as a type error, which is why the message named a supported extension.

      An explicit path you type is now honored when the file exists, including a ../ path that points to a parent directory. This matches how absolute paths already work. Bare filenames still resolve only within the current project, so typing notes.md cannot reach a same-named file in a parent directory.

      Closing #1085, reported by @shulcsm.

      What's New in v0.24.0

      This release adds two review surfaces: a gallery for the images, videos, and documents inside PR conversations, and native GitButler workspace support. 25 pull requests landed since v0.23.1. Six came from community members, four of them first-time contributors. The release also brings port ranges, an expanded comment editor, and fixes across the OpenCode and Pi integrations.

      PR and MR artifact gallery

      Pull request conversations hold more than text: screenshots of the bug, GIFs of the fix, demo videos, HTML reports, attached markdown. The review UI ignored all of it.

      When you review a GitHub pull request or GitLab merge request, Plannotator now collects images, GIFs, videos, HTML, and markdown files from the description and conversation into a gallery. Selecting a tile opens a focused viewer. Markdown and sandboxed HTML render inline, and everything is annotatable: select text in a document, drop a point note on an image, pin a note to a video timestamp, or comment on the artifact as a whole. These notes join your normal review feedback with their source attached, whether the feedback posts to GitHub/GitLab or returns to your local agent.

      Conversation artifacts sort newest-first, and you can hide tiles you don't want to see again. The gallery appears only for hosted reviews, since local diffs have no conversation to collect from.

      GitButler review support

      GitButler users work in a virtual-branch workspace that ordinary Git tooling misreads: HEAD sits on a synthetic workspace commit, and several branches are applied at once. Running a code review there produced confusing diffs against internals GitButler manages for you.

      Plannotator now detects an active GitButler workspace and reviews it natively. The default Workspace view shows everything applied, committed changes plus assigned and unassigned working-tree changes, against GitButler's reported merge base. You can also review a single stack or one branch within a stack as committed-only diffs. Detection requires both the workspace HEAD and GitButler's local target configuration, so a leftover branch or database from a past experiment cannot hijack an ordinary Git repo. An active workspace needs the but CLI (0.21.0 or newer). --gitbutler forces the provider and --git remains the escape hatch. Both the Bun and Pi runtimes support it.

      The original GitButler effort came from @dansusman, whose work is preserved in the commit co-author credit.

      Expanded comment editor in code review

      Long review comments were cramped in the compact inline toolbar. A new expand control opens a full-size dialog that edits the same comment, so you can draft multi-paragraph findings and submit through the familiar flow. The compact composer stays the default for quick notes and gains vertical resize.

      Port ranges

      PLANNOTATOR_PORT now accepts an inclusive range like 19432-19463. Plannotator tries each port in order and binds the first available one, in both the Bun and Pi runtimes. Fixed single ports and the random-port default behave as before. This helps devcontainer and SSH setups where you forward a block of ports and run several sessions side by side.

      OpenCode: cancelling a plan review now cleans up

      Cancelling a submit_plan call in OpenCode left the review server running, so the next plan submission could not bind its port. Cancellation now flows through OpenCode's tool-abort contract: the server shuts down, timers and child processes are released, and the plan is kept so a resubmitted revision reuses the same fixed port.

      Pi: faster startup and honest error reporting

      The extension added about two seconds to every pi launch because its full module graph loaded at registration. The heavy browser and server graph now loads on first use, and the large UI bundles are read only when you open a review or annotate session.

      Separately, when a review engine failed (for example, out of API credits mid- review), Guided Review reported a generic parse failure instead of the real cause. Provider errors now surface as themselves.

      Background git checks can no longer freeze the terminal

      Plannotator periodically checks whether your review baseline is behind its remote. On repos whose remote needs interactive authentication, that background git ls-remote could open a credential or passphrase prompt with nowhere to render. On Pi it froze the TUI. Background discovery now runs without interaction: credential prompts are disabled, SSH runs in batch mode, and timed-out processes are cleaned up as a group. Explicit actions like the "Fetch" button keep the normal interactive authentication path.

      Workspace mode discovers symlinked repos

      Multi-repo workspace review walked real directories only, so a child repo reachable through a symlink was skipped. Symlinked and junction-linked repos are now discovered, deduplicated by real path, and labeled by their workspace- relative alias. This release also caps the discovery walk with the PLANNOTATOR_FILE_BROWSER_MAX_FILES budget, so a stray symlink into a huge unrelated tree cannot stall startup.

      Additional Changes

      • JSON 404 for unknown API routes : a nonexistent /api/* path used to return the full app HTML with a 200. All six servers (Bun and Pi) now return a JSON 404, while SPA routes still serve HTML. By @buihongduc132 in #748, their first contribution.
      • System theme everywhere : the System option now appears in every theme menu through a shared mode list. By @gwynnnplaine in #1015.
      • OpenCode planning handoff preserved : approving a plan with an agent switch no longer loses the planning context. By @franktronics in #1034, their first contribution.
      • Visual-explainer Mermaid colors : the skill emitted OKLCH theme variables Mermaid cannot parse; it now emits hex. By @FNDEVVE in #1044, closing #1043, their first contribution.
      • Review feedback validation narrowed : submitting findings no longer risks starting a second review pass. By @backnotprop in #1065.
      • Responsive review header : the code review header now wraps at narrow widths. By @backnotprop in #1073.
      • Open-in selector placement : the open-in-editor selector moved after the file context. By @backnotprop in #1072.

      Install / Update

      macOS / Linux:

      curl -fsSL https://plannotator.ai/install.sh | bash

      Windows:

      irm https://plannotator.ai/install.ps1 | iex

      Claude Code Plugin: Run /plugin in Claude Code, find plannotator , and click "Update now".

      OpenCode: Clear cache and restart:

      rm -rf ~/.bun/install/cache/@plannotator

      Then in opencode.json:

      {
  "plugin": ["@plannotator/opencode@latest"]
}

      Pi: Install or update the extension:

      pi install npm:@plannotator/pi-extension

      What's Changed

      v0.24.1

      • fix(annotate): resolve explicit ../ paths that escape the project root by @backnotprop, closing #1085

      v0.24.0

      New Contributors

      Contributors

      @iurysza built port range support across both server runtimes for their first contribution, with tests for the parsing edge cases. @buihongduc132's first contribution touched all six servers, giving API clients proper JSON 404s. @franktronics fixed the OpenCode planning handoff on their first PR. @FNDEVVE both reported and fixed the visual-explainer Mermaid color bug. @leoreisdias returned for a fifth contribution with the expanded comment editor. @gwynnnplaine made the System theme option consistent everywhere. @dansusman's original GitButler pull request laid the groundwork for this release's native support.

      Issue reporters drove much of the fix list this cycle:

      • @shulcsm reported the parent-relative annotate failure with a clear before/after reproduction in #1085
      • @fabians-px reported the OpenCode cancellation port leak in #1046
      • @r3clin3r reported the Pi TUI freeze from background SSH prompts in #1020
      • @tomsej profiled and reported the 2.1s Pi startup cost in #1058
      • @alexanderkreidich reported Guided Review masking insufficient-credit errors in #1037
      • @fruxxxl reported the symlinked-repo gap in workspace mode in #1054

      Full Changelog : v0.24.0...v0.24.1 (patch) · v0.23.1...v0.24.0 (v0.24.0)

    4. 🔗 r/reverseengineering X3DH-lite + Double Ratchet + sender-keys E2EE messenger protocol (Kotlin) — internal audit history included, no independent review yet rss

      submitted by /u/softdeadlock
      [link] [comments]

    5. 🔗 @binaryninja@infosec.exchange Brandon first disclosed the bug from this video a few months ago, and now you mastodon

      Brandon first disclosed the bug from this video a few months ago, and now you have a chance to learn how to find bugs just like it, from him! Class is next week, so sign up today: https://shop.binary.ninja/products/fre- july-26

      https://youtube.com/shorts/lOJKwPwhdOY

    6. 🔗 HexRaysSA/plugin-repository commits Merge pull request #37 from HexRaysSA/plugin-contest-2025 rss 
      Merge pull request #37 from HexRaysSA/plugin-contest-2025

add 2025 plugin contest winners
    7. 🔗 HexRaysSA/plugin-repository commits add 2025 plugin contest winners rss 
      add 2025 plugin contest winners
    8. 🔗 r/reverseengineering ReChan brings Jackie Chan Stuntmaster to PC as a native reimplementation rss

      submitted by /u/_AG700
      [link] [comments]

    9. 🔗 r/reverseengineering repel_paw3950_driver_re rss

      submitted by /u/KepcukTheGreat
      [link] [comments]

    10. 🔗 r/reverseengineering Reversing GetOfflineDeviceUniqueID: How Windows Derives Its Offline Device ID rss

      submitted by /u/Beneficial_Slide_424
      [link] [comments]

    11. 🔗 r/reverseengineering /r/ReverseEngineering's Weekly Questions Thread rss

      To reduce the amount of noise from questions, we have disabled self-posts in favor of a unified questions thread every week. Feel free to ask any question about reverse engineering here. If your question is about how to use a specific tool, or is specific to some particular target, you will have better luck on the Reverse Engineering StackExchange. See also /r/AskReverseEngineering.

      submitted by /u/AutoModerator
      [link] [comments]

    12. 🔗 backnotprop/plannotator v0.24.0 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.23.1 | Startup no longer hangs on large or slow directory trees, Ask AI input stays visible after long responses
      v0.23.0 | Plan approval fix for Claude Code 2.1.199+, annotate mode version diff, binary-only --minimal install, reviews post without attribution
      v0.22.0 | Git-status "All changes" default review view, Commits panel with per-commit diffs, Guided Review, Pi + GitHub Copilot CLI review engines
      v0.21.4 | Markdown math rendering, PR Overview panel with annotatable description and comments, agent instructions in code review, media parsing fixes
      v0.21.3 | File comments in code review, unified click-to-highlight comments, VS Code clipboard/keyboard bridge, Codex Ask AI on app-server transport, CLI subcommand help
      v0.21.2 | Custom reviews as Agent Skills, Cursor + OpenCode review engines, whole-file/general findings, deleted-annotation fix, Codex Ask AI outside git repos
      v0.21.1 | Annotate-last blank-page fix on multi-message sessions
      v0.21.0 | Direct document editing in annotate mode, live git-status file tree, in-app agent terminal, open files in external apps, HTML renders as HTML
      v0.20.3 | Annotations no longer lost when clicking away, off-screen indicator for open comments
      v0.20.2 | Pierre CodeView all-files review, large-PR pipeline and instant-open checkout, unified agent engine selection, Pi programmatic plan mode
      v0.20.1 | Pi extension install hotfix (pinned @pierre/diffs after a broken upstream release)

      What's New in v0.24.0

      This release adds two review surfaces: a gallery for the images, videos, and documents inside PR conversations, and native GitButler workspace support. 25 pull requests landed since v0.23.1. Six came from community members, four of them first-time contributors. The release also brings port ranges, an expanded comment editor, and fixes across the OpenCode and Pi integrations.

      PR and MR artifact gallery

      Pull request conversations hold more than text: screenshots of the bug, GIFs of the fix, demo videos, HTML reports, attached markdown. The review UI ignored all of it.

      When you review a GitHub pull request or GitLab merge request, Plannotator now collects images, GIFs, videos, HTML, and markdown files from the description and conversation into a gallery. Selecting a tile opens a focused viewer. Markdown and sandboxed HTML render inline, and everything is annotatable: select text in a document, drop a point note on an image, pin a note to a video timestamp, or comment on the artifact as a whole. These notes join your normal review feedback with their source attached, whether the feedback posts to GitHub/GitLab or returns to your local agent.

      Conversation artifacts sort newest-first, and you can hide tiles you don't want to see again. The gallery appears only for hosted reviews, since local diffs have no conversation to collect from.

      GitButler review support

      GitButler users work in a virtual-branch workspace that ordinary Git tooling misreads: HEAD sits on a synthetic workspace commit, and several branches are applied at once. Running a code review there produced confusing diffs against internals GitButler manages for you.

      Plannotator now detects an active GitButler workspace and reviews it natively. The default Workspace view shows everything applied, committed changes plus assigned and unassigned working-tree changes, against GitButler's reported merge base. You can also review a single stack or one branch within a stack as committed-only diffs. Detection requires both the workspace HEAD and GitButler's local target configuration, so a leftover branch or database from a past experiment cannot hijack an ordinary Git repo. An active workspace needs the but CLI (0.21.0 or newer). --gitbutler forces the provider and --git remains the escape hatch. Both the Bun and Pi runtimes support it.

      The original GitButler effort came from @dansusman, whose work is preserved in the commit co-author credit.

      Expanded comment editor in code review

      Long review comments were cramped in the compact inline toolbar. A new expand control opens a full-size dialog that edits the same comment, so you can draft multi-paragraph findings and submit through the familiar flow. The compact composer stays the default for quick notes and gains vertical resize.

      Port ranges

      PLANNOTATOR_PORT now accepts an inclusive range like 19432-19463. Plannotator tries each port in order and binds the first available one, in both the Bun and Pi runtimes. Fixed single ports and the random-port default behave as before. This helps devcontainer and SSH setups where you forward a block of ports and run several sessions side by side.

      OpenCode: cancelling a plan review now cleans up

      Cancelling a submit_plan call in OpenCode left the review server running, so the next plan submission could not bind its port. Cancellation now flows through OpenCode's tool-abort contract: the server shuts down, timers and child processes are released, and the plan is kept so a resubmitted revision reuses the same fixed port.

      Pi: faster startup and honest error reporting

      The extension added about two seconds to every pi launch because its full module graph loaded at registration. The heavy browser and server graph now loads on first use, and the large UI bundles are read only when you open a review or annotate session.

      Separately, when a review engine failed (for example, out of API credits mid- review), Guided Review reported a generic parse failure instead of the real cause. Provider errors now surface as themselves.

      Background git checks can no longer freeze the terminal

      Plannotator periodically checks whether your review baseline is behind its remote. On repos whose remote needs interactive authentication, that background git ls-remote could open a credential or passphrase prompt with nowhere to render. On Pi it froze the TUI. Background discovery now runs without interaction: credential prompts are disabled, SSH runs in batch mode, and timed-out processes are cleaned up as a group. Explicit actions like the "Fetch" button keep the normal interactive authentication path.

      Workspace mode discovers symlinked repos

      Multi-repo workspace review walked real directories only, so a child repo reachable through a symlink was skipped. Symlinked and junction-linked repos are now discovered, deduplicated by real path, and labeled by their workspace- relative alias. This release also caps the discovery walk with the PLANNOTATOR_FILE_BROWSER_MAX_FILES budget, so a stray symlink into a huge unrelated tree cannot stall startup.

      Additional Changes

      • JSON 404 for unknown API routes : a nonexistent /api/* path used to return the full app HTML with a 200. All six servers (Bun and Pi) now return a JSON 404, while SPA routes still serve HTML. By @buihongduc132 in #748, their first contribution.
      • System theme everywhere : the System option now appears in every theme menu through a shared mode list. By @gwynnnplaine in #1015.
      • OpenCode planning handoff preserved : approving a plan with an agent switch no longer loses the planning context. By @franktronics in #1034, their first contribution.
      • Visual-explainer Mermaid colors : the skill emitted OKLCH theme variables Mermaid cannot parse; it now emits hex. By @FNDEVVE in #1044, closing #1043, their first contribution.
      • Review feedback validation narrowed : submitting findings no longer risks starting a second review pass. By @backnotprop in #1065.
      • Responsive review header : the code review header now wraps at narrow widths. By @backnotprop in #1073.
      • Open-in selector placement : the open-in-editor selector moved after the file context. By @backnotprop in #1072.

      Install / Update

      macOS / Linux:

      curl -fsSL https://plannotator.ai/install.sh | bash

      Windows:

      irm https://plannotator.ai/install.ps1 | iex

      Claude Code Plugin: Run /plugin in Claude Code, find plannotator , and click "Update now".

      OpenCode: Clear cache and restart:

      rm -rf ~/.bun/install/cache/@plannotator

      Then in opencode.json:

      {
  "plugin": ["@plannotator/opencode@latest"]
}

      Pi: Install or update the extension:

      pi install npm:@plannotator/pi-extension

      What's Changed

      New Contributors

      Contributors

      @iurysza built port range support across both server runtimes for their first contribution, with tests for the parsing edge cases. @buihongduc132's first contribution touched all six servers, giving API clients proper JSON 404s. @franktronics fixed the OpenCode planning handoff on their first PR. @FNDEVVE both reported and fixed the visual-explainer Mermaid color bug. @leoreisdias returned for a fifth contribution with the expanded comment editor. @gwynnnplaine made the System theme option consistent everywhere. @dansusman's original GitButler pull request laid the groundwork for this release's native support.

      Issue reporters drove much of the fix list this cycle:

      Full Changelog : v0.23.1...v0.24.0

    13. 🔗 HexRaysSA/plugin-repository commits sync repo: +2 plugins, +2 releases, ~2 changed rss 
      sync repo: +2 plugins, +2 releases, ~2 changed

## New plugins
- [ida-taskr](https://github.com/mahmoudimus/ida-taskr) (1.0.3)
- [idavator](https://github.com/mahmoudimus/idavator) (0.1.1)

## Changes
- [SigMaker](https://github.com/mahmoudimus/ida-sigmaker):
  - 1.14.0: archive contents changed, download URL changed
  - 1.13.0: archive contents changed, download URL changed
    14. 🔗 tonsky.me Looking for work rss

      Hey, Niki here. This is a bit unusual. My sabbatical is coming to an end, and I am looking for a new opportunity. Full-time or contract, startup or research, remote or Berlin, individual contributor, ideally—tight team, ambitious product.

      I am a software engineer first and foremost with 20+ years of experience. I work on technically challenging products, foundational technology, dev tools. I’ve been doing Clojure and web recently, but I'm also very excited to explore closer-to-the-metal programming.

      I have an eye for design, user interfaces, UX, DX. I would love to work with a team that takes interface quality seriously. Or to work with graphics!

      I am pretty sure I am good at explaining stuff, including what we are building, why, why this way, why is it important, etc. For example.

      The overarching theme is to understand computers deeply, and then use that to make better and simpler software. If you care about that too, we might be a great match!

      Recent work

      Instant DB is a US startup building a modern Firebase. I worked on the sync algorithm, performance, DX. A summary of my commit log.

      Roam Research is an OG personal knowledge manager. I worked on database optimization and a plugin system.

      At JetBrains, I developed a new Skia renderer for Fleet and Jetpack Compose Desktop.

      I’ve built many open-source libraries, including a database, a GUI toolkit, a Clojure dev environment, a React wrapper, a well-known font... More recently, Clojure+ gives you a taste of my approach to DX, and Fast EDN—to performance.

      I maintain several active projects — AlleKinos.de, Grumpy Website, this site.

      If you want to dive deeper, here’s the usual stuff: Projects / Talks / LinkedIn / GitHub

      I also made a two-page PDF CV.

      Why this post?

      It’s an attempt to reach beyond my immediate network. I’ve been doing Clojure for a long time, and now want to explore.

      If you are working on a compiler, a database, an IDE, a programming language or another technically ambitious product, touching graphics, typography, algorithms, low-level programming, and you think my experience can help, let’s talk: niki@tonsky.me.

    15. 🔗 matklad Memory Safety's Hardest Problem rss

      Memory Safety’s Hardest Problem

      Jul 20, 2026

      Uplifting a lobsters comment for easier reference.

      The central memory safety counter example, the hardest case to solve, doesn’t have anything to do with destructors or heap:

      const std = @import("std");

const E = union(enum) {
    a: u128,
    b: []const u8,
};

pub fn main() void {
    const bad_addr: u128 = @intFromPtr(&main);

    var e: E = .{ .b = "hello" };
    const oh_no_pointer: *const []const u8 = switch (e) {
        .a => unreachable,
        .b => |*p| p,
    };
    e = .{ .a = (16 << 64) + bad_addr };
    const oh_no: []const u8 = oh_no_pointer.*;
    std.debug.print("{s}\n", .{oh_no});
}


$ zig run main.zig
��C�� �

      This sort of example also breaks Ada:

      https://www.enyo.de/fw/notes/ada-type-safety.html

      We have a tagged union, which can hold either A or B. We initialize the union as A, take a pointer to its internals, overwrite the original with B, and then use the pointer. The pointer is still typed as A, but the bytes it points to now belong to B: a type confusion.

      This being said, we care about memory unsafety primarily because it leads to exploitable software, and it’s unclear just how impactful the example above is in practice. It is a happy coincidence that by far the most exploitable memory error in practice, the infamous buffer overflow, is also trivial to fix with compiler-inserted bounds checks. The biggest miss of the industry when it comes to memory safety is not listening to Walter Bright:

      https://digitalmars.com/articles/C-biggest-mistake.html

      I bet that, had we got char a[..] syntax around C11, quite a few issues wouldn’t have happened!

      See also What is Memory Safety?

    16. 🔗 exe.dev Claude Is Not a Compiler rss

      In early 2025, I wrote Is Claude a Compiler? At the time, my answer was: I don’t know.

      I’m now pretty sure the answer is “no, that’s a category error, it’s better than a compiler.” But this requires a bit of unpacking.

      Computer programs are notoriously intricate and finicky. A program operates at an extreme level of precision. There is no “wave hands” CPU instruction. High- level goals, meanwhile, are deeply underspecified.

      In a highly stylized view of the world, software gets built in layers, each one adding specification and hiding “unnecessary” detail. Vision becomes strategy, product plans become coding plans, code becomes binaries. Each step is handled by a different role: executive, VP, PM, architect, engineer, compiler.

      Critically, every step involves making lots of decisions. That’s what it means to increase the level of specification. (This is why one of my two key metrics for hiring engineers is judgment. The other is comity.)

      The bottom layer, from source code to binary, is what a compiler does. Compilers make lots of decisions! Inlining, register allocation, whether to emit warnings or reject a program outright. And these decisions matter: They drive performance, system stability, predictability, and failure modes. A compiler engineer’s job is to arrange for the compiler to make consistently good decisions.

      A good, trusted compiler frees a software engineer from having to make these decisions. Most engineers have little idea how compilers work; they don’t need to in order to be effective.

      In 2025, we operated in a world where we used LLMs to generate smallish chunks of code. In this mental model, a coding agent might slot in as a new layer between a software engineer and a traditional compiler. It “compiles” natural language to code, making decisions so the engineer doesn’t have to. Its value is proportional to its reliability and the scale of the decisions it can make.

      The thing is, this highly stylized view of the world is false. Abstractions leak and layers rub. And even if they didn’t, we’d poke holes in them anyway.

      Working across layers is extremely valuable; mechanical sympathy matters.

      Part of how the Empire State Building was constructed in under a year and under budget (!!) was by systematically working across layers. For example, when deciding about the exterior chrome- nickel steel cladding:

      Neither architects, builders nor subcontractors felt competent to deal with this complicated technical problem of construction without full consultation. Accordingly, after full preliminary discussion, an all- inclusive meeting was called which was attended by representatives of the owner, the architects and builders, the subcontractors rolling the material, the metal workers who were to fabricate and those who were to erect it, and the inspectors who were to test all sheets at the several stages of preparation.

      This sounds really obvious when you say it out loud.

      And yet we systematically fail at this in practice. I can only imagine the delight of the metal workers who had an opportunity to guide the design toward something that wasn’t slow and miserable to work on.

      Part of the reason we fail is ignorance of what is even worth asking about. There’s a reason that the best executives have deep knowledge of their industry. I also suspect that some of it is dismissiveness (“What could a line metalworker have to tell me?”). But a big chunk is also communication and organizational overhead. Layers exist for a reason—information hiding enables organizational scaling.

      Claude is better than a compiler because it can work vertically across the stack. LLMs now talk strategy, product, architecture, code, and machine code. It can’t (yet?) do most individual tasks as well as an experienced, dedicated human, but it can do all of them, without having to schedule meetings or ask permission.

      Here’s a concrete example.

      exe.dev VMs have nice domain names: vm- name.exe.xyz. When we start a new VM, we add a CNAME entry or three. Easy, right?

      But our VMs start fast, so fast that even if we created the DNS entries before creating the VM, our users still had to sit around waiting for DNS to propagate, which occasionally took minutes, not seconds.

      We did the obvious thing: We wrote our own DNS server, so that DNS always immediately matched the source of truth. And life was good.

      But latency matters, so we added regions. And just like that, DNS became the long pole again, because all DNS was served out of Oregon. Also, deployments caused tiny DNS outages. To fix this, all we needed now was a geographically distributed but fully consistent DNS server.

      We did what a sensible engineer does when faced with a hard problem: cheat. We vibe-engineered a distributed DNS server tuned to our specific needs.

      The goals were clear: Reduce latency for users far from Oregon and increase uptime resiliency. But the rest was not. We had to figure out everything from the exact behavior we wanted (particularly under various failure conditions), to how it fit into our overall company plans, to the architecture that could best achieve those goals, straight through down to the fine implementation details.

      We hashed out the highest level strategic and architectural decisions in person. We’d make a fairly general-purpose DNS server and layer on our particular behavioral tweaks, use a hub-and-spoke model, use an append-only replication strategy, and have persistence at the edges.

      All that was left was to actually build it.

      I had LLMs research standard designs for distributed DNS systems, teach me about the guts and quirks of DNS, point out historic security failings, explore alternative implementation strategies (AXFR/IXFR? no thanks), research open source offerings, game out failure modes, and plan testing strategies.

      Once I had an initial sketch of a design that seemed promising, I prompted multiple concurrent agent loops into building the entire thing , including tests and adversarial code review. They raised a bunch of questions—at every level of detail, from major structural approaches down to line-level code concerns. As I answered them (or reverted answers that generated regret), I slowly converted what I had learned into very terse written guidance, codifying decisions that proved to be important.

      Then I asked new agents to compare the completed implementations and look for interesting deviations. It was shocking how many important decisions the agents never asked about but simply made—and made differently.

      Here’s an example. Replication uses the fairly obvious approach: Catch up by asking for everything since the last known entry, and then long poll for new entries. There’s one ugly twist: database rollbacks. Rare, but they do happen, and they break the “append-only” contract.

      The agents noticed this, and they solved it in wildly different ways. The design I ultimately settled on was to give every row a “timeline” field, as in “which timeline are you living in?” These are randomly generated, and every sync request for “entries since row N” includes the edge server’s timeline value for row N. If there’s a timeline mismatch, we know that history has been altered and fall back to a full clean re-sync.

      There were also obvious style differences between the systems built by different agents. Claude and Codex both agreed that Claude created a more elegant system but that Codex was more thorough.

      I worked through the list of major identified divergences, experimented, and then added more written guidance.

      Then I repeated that entire differential spec analysis process, twice. I know my aphorisms.

      Plan to throw one away; you will, anyhow.

      — Fred Brooks

      If you plan to throw one away, you will throw away two.

      — Craig Zerouni

      By the time I was ready to build a keeper, I had accumulated a scar-tissue document that was empirically sufficient to guide an agent through most of the important decisions, at every layer, ranging from high level goals through architecture down to the occasional low level detail, such as the exact shape of the data type for load-bearing concurrent caches.

      The final system included unit tests, end-to-end tests, a shadow-mode for de- risking prod rollout, and a terse written-by-and-for-agents doc suite.

      This cumulatively took about a week of my attention. I read a vanishingly small amount of the actual code.

      At the end of that, I presented the solution to the team. I planned to launch the server and then go on vacation. As my colleagues peppered me with questions—"How does X work? What happens in condition Y?"—I found I could answer all of them confidently. (And I did go on that vacation. Number of DNS incidents a month later: 0.)

      Claude wasn’t just a compiler here. I never handed off a task and let an agent make a bunch of decisions in order to reduce it to practice. That’s vibe- coding.

      Rather, Claude was a vertically integrated resource, a multi-compiler. Its ability to work across the stack accelerated and augmented my ability to make a bunch of decisions at different levels, including about which decisions were important. (Most individual lines of code don’t make that cut.) That’s vibe- engineering.

      I’d say that, in all the ways that matter, I understand the code. Sure, if I had to hand-edit it now, there’d be a serious learning curve. But I won't have to. And more importantly, I can reason about the system, share perspectives with my colleagues, and guide agents on future work. And there’s an enduring artifact that encapsulates the central, intentional aspects of the design that were important enough to record, across all layers, and should thus survive bug fixes and code churn.

      One of the questions of this era is: What do software engineers need to understand about the systems they work on?

      Well-chosen layers provide understanding. Fundamental laws of physics appear all-encompassing, but they’re inferior to classical mechanics for explaining why it’s better to be in a bus than a car in an accident.

      Some software layers are dying, because they provide convenience, but not extra insight. (Sorry, Tailwind. I loved you.) But software layers that enable us to express important decisions in a comprehensible way? Those will stay.

      We are shifting more of our attention up the stack, but without fully relinquishing the lower layers. Agents are not a free pass to hand off all understanding of the deeper layers of a system. Most of the Go standard library is written in Go, but a few key routines are written in assembly. You can’t rely on the compiler there.

      Software engineers are being stretched. It’s exhilarating and exhausting. What’s becoming clear, though, is that in the near future, vibe-engineering is just…engineering.

    17. 🔗 Ampcode News Meet Puck rss

      Say Hello to Puck, your new assistant in Amp:

      Puck in Amp

      Open it up from anywhere on ampcode.com:

      Puck is always available and has access to many different tools to help you manage your agents in Amp.

      Here are some examples of things you can ask Puck to do:

      • "Spawn a new agent in an orb to fix this bug the user reported in the screenshot."
      • "Start an agent in ampcode/amp to investigate why CI is failing."
      • "Find me that massive thread I had where I was investigating that 500 server issue."
      • "Once this thread is done, archive it."
      • "Create a new project and start setting up a 2026 Rust development toolchain in it."
      • "For each script in our ./scripts folder, spawn an agent in an orb to try and run it again dev server. Then compile their feedback about what worked/didn't work.

      Think of Puck as a quick assistant and a home base for launching and coordinating other agents. It's an experiment, too. Puck is flexible, and we've already found more ways to use it than we expected. We're excited to see what you come up with.

      Time to open Puck and put it to work.

    18. 🔗 Ampcode News Amp Is Now In Slack rss

      You can now summon Amp in Slack.

      Connect your workspace from Amp's settings, then mention @Amp in any channel or thread. Amp sends your message to your personal Puck, which can initiate bug fixes, spike new features, answer questions about your codebase, and find and manipulate existing threads.

      Here are a few examples of how we've been using it:

      1 / 4

      Fix a User Bug Report

      A user reported a bug with a screenshot. Amp read the screenshot, reproduced the issue, and posted back a fix.

      Using Amp in Slack to investigate and fix a user bug report

      Resolve a Production Incident

      A production alert posted to a Slack channel, Amp identified the likely culprit commit, pulled production logs to verify, and pushed a fix to the production Terraform config.

      Using Amp in Slack to root-cause and resolve a production incident
      See full investigation thread.

      Close the Loop with Your Team

      Two teammates investigated the same issue. One resolved it and asked Amp to ping the other user from their investigation thread. The other user then archived their ongoing threads from Slack.

      Puck notifying a teammate in Slack that an issue has been resolved

      Search Slack for Context

      Amp can also search through Slack to pull discussions relevant to its current task. The Amp Slack integration compiled the examples used in this post.

      Using Amp to search Slack messages for context

      Install the Slack Integration

      1. Open Workspace Integrations as an Amp workspace admin, select Connect a Slack Workspace, and authorize the Amp app in Slack. (If you don't yet have an Amp workspace, create one.)
      2. Individual users should link their Amp user directly with their Slack user in Personal Settings.
      3. Mention @Amp in any Slack channel or thread.

      Read the Amp manual for more details.

  3. July 19, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-07-19 rss

      IDA Plugin Updates on 2026-07-19

      New Releases:

      Activity:

      • flakida-9.4
        • 5e69153b: feat: initialize flakida-9.4
        • 669a71a5: feat: add plugins - findcrypt, wpegpt, dereferencing
      • IDA-NO-MCP
        • 21fd3bb1: Merge pull request #25 from AWDSCAN/main
        • ed22a672: Update .gitignore to modify ignored files
        • 1c3aae66: 修复bug、增加测试性AI导航功能，rust构建百兆大文件分析cli工具
        • 7cc1aefe: 修复python版本存在的部分问题、优化python版本的提取速度，同时增加rust重构的可执行文件，解决百兆以上大文件无法分析导出的问题…
      • ida-pro-mcp
        • 120ae7ab: Fix Kimi Code installation instructions
        • d6c168b5: Merge pull request #481 from s0kil/kimi-code-support
      • ida-taskr
        • d399f4a2: build: publish IDA Taskr through HCLI (#6)
      • idavator
        • e79b7f6a: build: publish Idavator through HCLI (#1)
    2. 🔗 MetaBrainz Spotify users will need to reconnect every 6 months to ListenBrainz rss

      Spotify recently announced a drastic change in their API: connections to your account will now expire after 6 months, starting July 20th.

      If you have your Spotify account connected to ListenBrainz, this means you will have toreconnect your Spotify account every 6 months , or ListenBrainz will not be able to keep your listening history in sync.
      To get us started, all users will need to reconnect their Spotify account this coming Monday July 20th.

      In addition to sending you an email, you will see an error message at the top of the page in ListenBrainz:

      To minimize disruption and potential loss of listening history in the future, we will send you an email a month ahead, and one week ahead of the disconnection for you to disconnect and reconnect your Spotify account in your music services settings.

      This is quite the thorn in our side but alas we have no other choice as the internet continues to enshittify.

    3. 🔗 @malcat@infosec.exchange You like [#capa](https://infosec.exchange/tags/capa) but wish it would scan mastodon

      You like #capa but wish it would scan faster?
      Try out #Malcat 0.9.15, featuring a blazing fast native Capa scanner, among other improvements:

      https://malcat.fr/blog/0915-is-out-capa-scanning-at-native- speed/

    4. 🔗 smol-machines/smolvm smolvm v1.6.13 release

      What's Changed

      • Bump the Nix flake to smolvm 1.6.0 by @BinSquare in #625
      • Fix the pacman repo build so it packages both architectures by @BinSquare in #626
      • Make VM boot failures diagnosable instead of opaque by @BinSquare in #627
      • docs: recommend the unix-socket docker endpoint; document the TCP alternative and its caveats by @BinSquare in #621
      • Add cuda to VmResources for CLI/SDK CUDA-over-vsock by @BinSquare in #628
      • CUDA fork independent serving: copy-on-fork isolation, graph mode, network transport by @BinSquare in #629
      • Detect a stale CUDA guest shim at boot instead of an opaque cuInit failure by @BinSquare in #630
      • feat: expose the docker-socket bridge in the machines HTTP API by @BinSquare in #631
      • Resolve a named config.User to a numeric uid for crun exec (#632) by @BinSquare in #634
      • Warn at launch when CUDA remoting is requested on a host with no usable GPU by @BinSquare in #635
      • CUDA Path 3: address-preserving per-clone-process fork isolation by @BinSquare in #633
      • Bump the workspace to 1.6.1 by @BinSquare in #641
      • Group container tasks under the sandbox shim (fixes containers on containerd 2.2+) by @BinSquare in #643
      • Rebuild the linux libkrun.so with a glibc 2.35 floor and gate it in CI by @BinSquare in #644
      • CUDA Path 3 follow-ups: fork crash fixes, zero-config forkable machines, remote (TCP) clone workers by @BinSquare in #648
      • Route smolmachine pack references through the host-side pack flow instead of the in-guest OCI puller by @BinSquare in #647
      • Stamp pushed smolmachine manifests with the OCI 1.1 artifactType and standard annotations by @BinSquare in #649
      • CUDA fork: release a torn-down golden's VRAM (close leaked export fds) by @BinSquare in #650
      • CUDA fork: fail fast when a clone's worker dies or its lineage is gone by @BinSquare in #652
      • Rename the CUDA fork env vars to describe behavior by @BinSquare in #653
      • release: bundle CUDA shims + smolvm-cuda-run in agent-rootfs by @NickyHeC in #601
      • Stream the pack overlay export to disk by @BinSquare in #654
      • CUDA image machines: run the create workload, and fail fast when no GPU host answers by @BinSquare in #655
      • feat: add --expose-socket and --mount-socket for forwarding arbitrary unix sockets by @BinSquare in #656
      • Run the pack-from-vm helper as the source VM's isolated uid so it can read the source disks by @BinSquare in #658
      • Fix silently dropped CUDA work after a fork-clone reconnect, and rebuild captured graphs in clone workers by @BinSquare in #659
      • Gate engine PRs on compiling the smol CLI and script the release cut by @BinSquare in #661
      • Export the pack sidecar, not the executable stub, when a machine is exported by @BinSquare in #662
      • Route fork clones to workers by an explicit connection preamble so a golden's reconnect can never be misrouted by @BinSquare in #663
      • Never LRU-evict the reference-shared pack store by @BinSquare in #666
      • Fail an image machine's start when the image pull fails by @BinSquare in #669
      • Flatten from-vm packs to a single layer and share the pack export, workload launch, and machine-create env handling in the lib by @BinSquare in #668
      • Cap keep-alive exec output so oversized results return a clear error instead of a frame-too-large crash by @BinSquare in #670
      • Fix file-upload body limit and clarify the oversized-exec-output guidance by @BinSquare in #671
      • CUDA fork: sync-call retry, allocation burst, multi-GPU pinning, sandboxed serve, and machine-create workload by @BinSquare in #672
      • Reload clone-worker modules byte-identical to the golden's images by @BinSquare in #673
      • Recover fork clones whose worker died, and give clone reconnects a real handshake window by @BinSquare in #675
      • CUDA 13 guest surface by @LoganGrasby in #674
      • Re-key the golden's persistent exec overlay to the clone so forks inherit filesystem state by @BinSquare in #677
      • Replay function attributes on clone-worker kernels, and print backtraces on fatal signals by @BinSquare in #676

      Full Changelog : v1.6.0...v1.6.13

    5. 🔗 anthropics/claude-code v2.1.215 release

      What's changed

      • Claude no longer runs the /verify and /code-review skills on its own; invoke them with /verify or /code-review when you want them
    6. 🔗 smol-machines/smolvm smolvm v1.6.12 release

      What's Changed

      • Bump the Nix flake to smolvm 1.6.0 by @BinSquare in #625
      • Fix the pacman repo build so it packages both architectures by @BinSquare in #626
      • Make VM boot failures diagnosable instead of opaque by @BinSquare in #627
      • docs: recommend the unix-socket docker endpoint; document the TCP alternative and its caveats by @BinSquare in #621
      • Add cuda to VmResources for CLI/SDK CUDA-over-vsock by @BinSquare in #628
      • CUDA fork independent serving: copy-on-fork isolation, graph mode, network transport by @BinSquare in #629
      • Detect a stale CUDA guest shim at boot instead of an opaque cuInit failure by @BinSquare in #630
      • feat: expose the docker-socket bridge in the machines HTTP API by @BinSquare in #631
      • Resolve a named config.User to a numeric uid for crun exec (#632) by @BinSquare in #634
      • Warn at launch when CUDA remoting is requested on a host with no usable GPU by @BinSquare in #635
      • CUDA Path 3: address-preserving per-clone-process fork isolation by @BinSquare in #633
      • Bump the workspace to 1.6.1 by @BinSquare in #641
      • Group container tasks under the sandbox shim (fixes containers on containerd 2.2+) by @BinSquare in #643
      • Rebuild the linux libkrun.so with a glibc 2.35 floor and gate it in CI by @BinSquare in #644
      • CUDA Path 3 follow-ups: fork crash fixes, zero-config forkable machines, remote (TCP) clone workers by @BinSquare in #648
      • Route smolmachine pack references through the host-side pack flow instead of the in-guest OCI puller by @BinSquare in #647
      • Stamp pushed smolmachine manifests with the OCI 1.1 artifactType and standard annotations by @BinSquare in #649
      • CUDA fork: release a torn-down golden's VRAM (close leaked export fds) by @BinSquare in #650
      • CUDA fork: fail fast when a clone's worker dies or its lineage is gone by @BinSquare in #652
      • Rename the CUDA fork env vars to describe behavior by @BinSquare in #653
      • release: bundle CUDA shims + smolvm-cuda-run in agent-rootfs by @NickyHeC in #601
      • Stream the pack overlay export to disk by @BinSquare in #654
      • CUDA image machines: run the create workload, and fail fast when no GPU host answers by @BinSquare in #655
      • feat: add --expose-socket and --mount-socket for forwarding arbitrary unix sockets by @BinSquare in #656
      • Run the pack-from-vm helper as the source VM's isolated uid so it can read the source disks by @BinSquare in #658
      • Fix silently dropped CUDA work after a fork-clone reconnect, and rebuild captured graphs in clone workers by @BinSquare in #659
      • Gate engine PRs on compiling the smol CLI and script the release cut by @BinSquare in #661
      • Export the pack sidecar, not the executable stub, when a machine is exported by @BinSquare in #662
      • Route fork clones to workers by an explicit connection preamble so a golden's reconnect can never be misrouted by @BinSquare in #663
      • Never LRU-evict the reference-shared pack store by @BinSquare in #666
      • Fail an image machine's start when the image pull fails by @BinSquare in #669
      • Flatten from-vm packs to a single layer and share the pack export, workload launch, and machine-create env handling in the lib by @BinSquare in #668
      • Cap keep-alive exec output so oversized results return a clear error instead of a frame-too-large crash by @BinSquare in #670
      • Fix file-upload body limit and clarify the oversized-exec-output guidance by @BinSquare in #671
      • CUDA fork: sync-call retry, allocation burst, multi-GPU pinning, sandboxed serve, and machine-create workload by @BinSquare in #672
      • Reload clone-worker modules byte-identical to the golden's images by @BinSquare in #673

      Full Changelog : v1.6.0...v1.6.12

    7. 🔗 Filip Filmar Cocoapuffs: Booting Fuchsia's Zircon Kernel on a RISC-V core in Artix-7 FPGA rss

      Zircon, the (non-POSIX, non-Linux) kernel powering Fuchsia, an open-source operating system under development at Google, now boots on my RISC-V based system-on-chip design, running on an AMD Artix-7 FPGA device. While this might be the first Fuchsia-powered device apart from the boards that Google works on, it is definitely the first piece of programmable hardware running Fuchsia. Why not Linux instead? I thought it would be novel and more amusing to see Fuchsia booting on a FPGA, vs Linux.

  4. July 18, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-07-18 rss

      IDA Plugin Updates on 2026-07-18

      New Releases:

      Activity:

      • ida-sigmaker
        • 8741e798: Merge pull request #85 from mahmoudimus/diff/ignore-superpowers-docs
        • ca335484: docs: correct macOS user directory
        • c5064833: Ignore local superpowers planning docs
        • 7fd35fce: Merge pull request #84 from mahmoudimus/diff/release-v1.14.0-test-fix
        • 774c332e: Keep speedups remediation test version-aware
        • 6394378c: Prepare v1.14.0 release
        • 406c3969: Merge pull request #83 from mahmoudimus/diff/xref-buffer-reuse
        • cdc32ec0: Merge pull request #81 from mahmoudimus/diff/xref-lazy-startup
        • e1950d05: Merge pull request #80 from mahmoudimus/diff/simd-extension-api-compa…
        • c480160f: Reuse buffers across xref candidates
        • 2e9d282e: Keep xref progress visible without pre-counting
        • f34a4ebe: Make xref startup cancelable
        • 78250748: Accept structurally compatible legacy speedups
      • leaknet
        • 5b9087f3: - added missing retail shaders (did NOT replace ANY beta shaders)
      • Luc-Nhan
        • 299ea389: feat(history): reuse empty active tab when opening a chat
        • 7e7c27c4: Merge branch 'worktree-chat-history-on-demand': chat history on-demand
        • d37adc23: feat(history): chat history on-demand
      • re-sbz
    2. 🔗 mahmoudimus/ida-sigmaker v1.14.0 release

      sigmaker.py - IDAPython standalone release

      Release information

      What changed

      Changed

      • Direct Xref generation starts immediately and remains cancelable. SigMaker no longer walks every Xref to pre-count it before generating the first signature. One visible progress dialog stays active throughout the action, and cancellation is polled before enumeration and between candidates.
      • One Xref action reuses its SIMD search buffer. Database-wide generation loads the searchable bytes once; segment-scoped generation reuses one buffer per containing segment. Candidate signatures still retain their existing uniqueness scope, ordering, cancellation behavior, and no-SIMD fallback. (#82)

      Fixed

      • Stale optional SIMD wheels no longer crash SigMaker. SigMaker validates the extension's callable API before using it. Incompatible wheels fall back to the existing Python implementation and show HCLI and IDA-Python update commands, while compatible installed wheels continue to enable SIMD automatically. (#79)

      Installation

      1. Copy sigmaker.py to your IDA Pro plugins directory.
      2. Restart IDA Pro.
      3. Use Ctrl+Alt+S to access the Signature Maker menu.

      The release source archive is also installable through Hex-Rays HCLI.

      License

      See the repository for license information.

    3. 🔗 mahmoudimus/ida-sigmaker v1.13.0 release

      sigmaker.py - IDAPython standalone release

      Release information

      What changed

      Added

      • Python 3.14 wheels are included in the existing Linux, Windows, and macOS release matrix. Installing from PyPI on CPython 3.14 receives the same optional native SIMD search speedups as other supported Python versions.
      • SigMaker releases are installable through Hex-Rays HCLI. The release source archive contains the HCLI manifest and plugin entry point, while HCLI installs the matching sigmaker==1.13.0 wheel automatically so managed installations receive the SIMD extension without a separate pip install.

      Fixed

      • PyPI builds now run only for published releases. Ordinary successful tests on main no longer launch an untagged wheel build, and the HCLI manifest version and exact PyPI dependency pin are synchronized from sigmaker.__version__ during release preparation.

      Installation

      1. Copy sigmaker.py to your IDA Pro plugins directory.
      2. Restart IDA Pro.
      3. Use Ctrl+Alt+S to access the Signature Maker menu.

      The release source archive is also installable through Hex-Rays HCLI.

      License

      See the repository for license information.

    4. 🔗 HexRaysSA/plugin-repository commits sync repo: +1 release rss 
      sync repo: +1 release

## New releases
- [SigMaker](https://github.com/mahmoudimus/ida-sigmaker): 1.14.0
    5. 🔗 r/reverseengineering Making a mod for Grand Prix Circuit (DSI / Accolade, 1988) rss

      submitted by /u/alberto-m-dev
      [link] [comments]

    6. 🔗 Register Spill Joy & Curiosity #92 rss

      This week was busy : we shipped a lot of things, recorded quite a few things, I worked on my Laracon talk, chatted with amazing programmers in different timezones, and our local public swimming pool celebrated its 50th birthday.

      There wasn't a lot of reading this week, but a lot of thinking and wondering and questioning and aha! -ing. And I kinda can't shut up about it. So…

      Some of you might remember my original description of this newsletter: "It's very informal; it's what I'd send you if you were to ask me what's on my mind this week in an email."

      Now, here is what I'd say if you were to ask me what's on my mind this week, on a phone call:

      • Finally: Amp now has subscriptions. Yes, you read that right. Go there, get a subscription, pair it with your ChatGPT subscription so you get infinite GPT-5.6 tokens, and spawn those orbs.

      • We also shipped agent-to-agent communication in Amp: agents can now spawn other agents -- anywhere you have a Amp instance running or in an orb -- and then send messages and files to them. The number of "holy shit, it just …" messages this produced in our internal Slack is insane. To give you a taste: this morning I was hacking on something in our orb, but the agent in the orb lacked the permissions to upload an asset to our bucket. So the agent said: hey, start amp --no-tui on your machine, where you have permissions, then I'll start a thread there, send it that asset, and ask it to upload the file. And… it fucking did it! Exactly like that! I started amp --no-tui, I saw the new thread being created, I watched both of them, and saw how they sent messages to each other. Wild!

      • Raising An Agent is back! Here's the first episode of the new season: The Local Dev Env is Dead. Or listen on Spotify.

      • I know what you're thinking: "Thorsten, your voice… I need more of it." Don't worry, I got you. Dominic and Morten invited me to be a guest on the go podcast and our episode came out this week: Agentic engineering is here to stay with Thorsten Ball.

      • Yes, I know, you want more. I got more: Evan Phoenix, Quinn and I shipping from orbs to a Miren cluster. There's coding in there, but also a lot of talking about coding and developer tools and the future of software and deployments. Evan has shipped and worked on more successful developer tooling than basically anyone else (Rubinius! Puma! Hashicorp!), so him sharing his thoughts was a treat.

      • You want more? Okay, okay. I recorded a short video with thoughts on this race we're in and the forces at play that I don't think most developers are aware of. Titles I considered: "man, it must suck to be a model house", "the tectonic forces shaping software", "once the compute is available, this will all change again", and "there won't be a rugpull"

      • Hardcore Kindle reader here, but this really, really made me want to buy physical books again, even though it should probably serve as a warning to not do that: "Mendel Uminer faced a crisis when his landlord objected to the 10,000 volumes in his New York studio apartment."

      • Fabien Sanglard: Don't you mean extinct? Lovely article. You need to read this for the Phil Tippett story alone.

      • Another amazing Fabien Sanglard article: Jurassic Park computers in excruciating detail. Jurassic Park is one of my favorite movies of all time. Easy top five. I love it. And I'm sure its depiction of computers had an influence on my life. But one thing I hadn't noticed until reading this article is that Oppenheimer portrait.

      • After 7 years in production, Scarf has reluctantly moved away from Haskell. I'm honestly not sure what to say about the skeptics any more. Maybe this: for decades now, some programmers were really lucky in that what they loved to do, what they saw as their craft and their passion, was valuable to businesses. Now that's not the case anymore. And if you don't adapt, then, well, you end up not being valuable to businesses anymore.

      • Holy moly: Measuring input latency on Linux: X11 vs Wayland, VRR, and DXVK. If you're in the mood to find out how deep a rabbit hole can go, then read this. Very fascinating. Also: I can't believe it's 2026 and we're still talking about X11 vs. Wayland. Wayland was released in 2008.

      • John Carmack is smart.

      • Linus Torvalds on the Linux kernel mailing list: "There are other questions around AI (like what the economy of it will actually look like in the end), but 'is it useful' is no longer one of those questions. Anybody who doubts that clearly hasn't actually used it. Yes, it can also be a somewhat painful tool, both for maintainer

      workloads and just from a 'it keeps finding embarrassing bugs' standpoint. But the solution is not to put your head in the sand and sing 'La La La, I can't hear you' at the top of your voice like some people seem to do."

      • There is this whole debate going on around whether you should still read the code agents produce. antirez now chimed in too: Control the ideas, not the code. He writes: "But if I had my hands free, you know what I would do, instead? Use all the time that the review is taking me to do more QA, to think at the next optimization idea and apply it, and to use LLMs to write a DESIGN.md file where each data structure is described in human language, with the ideas it contains, the implementation tricks, the design. That, in the future, is going to be much more useful." I think he's onto something here. I personally do spot checks of code and mostly don't care about single functions anymore, except when the blast radius would be huge or when it's super critical. But it ties back to what antirez writes: I want to control the ideas, not the code.

      • And here's Sean Goedecke: In defense of not understanding your codebase. As always, very good post. I agree. People who say "you have to review every line" make me think that either they haven't worked with (a) a model that was released in 2026 or (b) other people in a multi-team engineering org.

      • Justin Jackson on the value of software in a Fable world: "Generally, the economy rewards difficulty and rarity. If something is hard to do or make, you get to charge more. So if AI reduces the time it takes to build software, what happens to the value of software?" See also my thoughts on software & oil here.

      • What working at Google feels like: "Have you ever changed a flat tire on the shoulder of the freeway? When you get out of your car and stand by the side of the road, you realize you are in a world scaled for 30,000-pound tractor trailers, not for human beings. The white stripes between the lanes that usually flash by like little punctuation marks are actually ten feet long and thirty feet apart. Even the road signs look absurdly out of scale, like those textbook-sized large-print editions of bestsellers the library stocks for elderly people. And then one of those tractor trailers hurtles by at seventy miles per hour, inches from your fragile body, and it feels like God himself is screaming in your face. That's exactly what working at Google feels like at first. You realize very quickly you are inhabiting an environment that was not designed for humans to experience with their naked minds. Even the smallest problems--which customers are we allowed to send this email to? What countries will have special legal requirements around the deployment of this tiny feature?--are so mind-numbingly complex that they make you want to shrink down into a fetal ball on the side of the freeway and just let the traffic shriek past."

      • "I had a french professor who once said if you just did something like going to the supermarket and experienced it fully without the goggles of habit and categories you would go crazy with pure sense and joy. I think about it all the time. In a way this is all for him." And I had a french teacher once who said that bean soup is the poor man's piano. I think about him every time I eat beans. So there's that.

      If you liked my phone call, you should subscribe:

    7. 🔗 r/reverseengineering Automated reverse engineering of Android apps rss

      submitted by /u/No_Distribution_9182
      [link] [comments]

    8. 🔗 smol-machines/smolvm smolvm v1.6.11 release

      What's Changed

      • Bump the Nix flake to smolvm 1.6.0 by @BinSquare in #625
      • Fix the pacman repo build so it packages both architectures by @BinSquare in #626
      • Make VM boot failures diagnosable instead of opaque by @BinSquare in #627
      • docs: recommend the unix-socket docker endpoint; document the TCP alternative and its caveats by @BinSquare in #621
      • Add cuda to VmResources for CLI/SDK CUDA-over-vsock by @BinSquare in #628
      • CUDA fork independent serving: copy-on-fork isolation, graph mode, network transport by @BinSquare in #629
      • Detect a stale CUDA guest shim at boot instead of an opaque cuInit failure by @BinSquare in #630
      • feat: expose the docker-socket bridge in the machines HTTP API by @BinSquare in #631
      • Resolve a named config.User to a numeric uid for crun exec (#632) by @BinSquare in #634
      • Warn at launch when CUDA remoting is requested on a host with no usable GPU by @BinSquare in #635
      • CUDA Path 3: address-preserving per-clone-process fork isolation by @BinSquare in #633
      • Bump the workspace to 1.6.1 by @BinSquare in #641
      • Group container tasks under the sandbox shim (fixes containers on containerd 2.2+) by @BinSquare in #643
      • Rebuild the linux libkrun.so with a glibc 2.35 floor and gate it in CI by @BinSquare in #644
      • CUDA Path 3 follow-ups: fork crash fixes, zero-config forkable machines, remote (TCP) clone workers by @BinSquare in #648
      • Route smolmachine pack references through the host-side pack flow instead of the in-guest OCI puller by @BinSquare in #647
      • Stamp pushed smolmachine manifests with the OCI 1.1 artifactType and standard annotations by @BinSquare in #649
      • CUDA fork: release a torn-down golden's VRAM (close leaked export fds) by @BinSquare in #650
      • CUDA fork: fail fast when a clone's worker dies or its lineage is gone by @BinSquare in #652
      • Rename the CUDA fork env vars to describe behavior by @BinSquare in #653
      • release: bundle CUDA shims + smolvm-cuda-run in agent-rootfs by @NickyHeC in #601
      • Stream the pack overlay export to disk by @BinSquare in #654
      • CUDA image machines: run the create workload, and fail fast when no GPU host answers by @BinSquare in #655
      • feat: add --expose-socket and --mount-socket for forwarding arbitrary unix sockets by @BinSquare in #656
      • Run the pack-from-vm helper as the source VM's isolated uid so it can read the source disks by @BinSquare in #658
      • Fix silently dropped CUDA work after a fork-clone reconnect, and rebuild captured graphs in clone workers by @BinSquare in #659
      • Gate engine PRs on compiling the smol CLI and script the release cut by @BinSquare in #661
      • Export the pack sidecar, not the executable stub, when a machine is exported by @BinSquare in #662
      • Route fork clones to workers by an explicit connection preamble so a golden's reconnect can never be misrouted by @BinSquare in #663
      • Never LRU-evict the reference-shared pack store by @BinSquare in #666
      • Fail an image machine's start when the image pull fails by @BinSquare in #669
      • Flatten from-vm packs to a single layer and share the pack export, workload launch, and machine-create env handling in the lib by @BinSquare in #668

      Full Changelog : v1.6.0...v1.6.11

    9. 🔗 smol-machines/smolvm smolvm v1.6.10 release

      What's Changed

      • Bump the Nix flake to smolvm 1.6.0 by @BinSquare in #625
      • Fix the pacman repo build so it packages both architectures by @BinSquare in #626
      • Make VM boot failures diagnosable instead of opaque by @BinSquare in #627
      • docs: recommend the unix-socket docker endpoint; document the TCP alternative and its caveats by @BinSquare in #621
      • Add cuda to VmResources for CLI/SDK CUDA-over-vsock by @BinSquare in #628
      • CUDA fork independent serving: copy-on-fork isolation, graph mode, network transport by @BinSquare in #629
      • Detect a stale CUDA guest shim at boot instead of an opaque cuInit failure by @BinSquare in #630
      • feat: expose the docker-socket bridge in the machines HTTP API by @BinSquare in #631
      • Resolve a named config.User to a numeric uid for crun exec (#632) by @BinSquare in #634
      • Warn at launch when CUDA remoting is requested on a host with no usable GPU by @BinSquare in #635
      • CUDA Path 3: address-preserving per-clone-process fork isolation by @BinSquare in #633
      • Bump the workspace to 1.6.1 by @BinSquare in #641
      • Group container tasks under the sandbox shim (fixes containers on containerd 2.2+) by @BinSquare in #643
      • Rebuild the linux libkrun.so with a glibc 2.35 floor and gate it in CI by @BinSquare in #644
      • CUDA Path 3 follow-ups: fork crash fixes, zero-config forkable machines, remote (TCP) clone workers by @BinSquare in #648
      • Route smolmachine pack references through the host-side pack flow instead of the in-guest OCI puller by @BinSquare in #647
      • Stamp pushed smolmachine manifests with the OCI 1.1 artifactType and standard annotations by @BinSquare in #649
      • CUDA fork: release a torn-down golden's VRAM (close leaked export fds) by @BinSquare in #650
      • CUDA fork: fail fast when a clone's worker dies or its lineage is gone by @BinSquare in #652
      • Rename the CUDA fork env vars to describe behavior by @BinSquare in #653
      • release: bundle CUDA shims + smolvm-cuda-run in agent-rootfs by @NickyHeC in #601
      • Stream the pack overlay export to disk by @BinSquare in #654
      • CUDA image machines: run the create workload, and fail fast when no GPU host answers by @BinSquare in #655
      • feat: add --expose-socket and --mount-socket for forwarding arbitrary unix sockets by @BinSquare in #656
      • Run the pack-from-vm helper as the source VM's isolated uid so it can read the source disks by @BinSquare in #658
      • Fix silently dropped CUDA work after a fork-clone reconnect, and rebuild captured graphs in clone workers by @BinSquare in #659
      • Gate engine PRs on compiling the smol CLI and script the release cut by @BinSquare in #661
      • Export the pack sidecar, not the executable stub, when a machine is exported by @BinSquare in #662
      • Route fork clones to workers by an explicit connection preamble so a golden's reconnect can never be misrouted by @BinSquare in #663
      • Never LRU-evict the reference-shared pack store by @BinSquare in #666
      • Fail an image machine's start when the image pull fails by @BinSquare in #669

      Full Changelog : v1.6.0...v1.6.10

    10. 🔗 pydantic/pydantic-ai-harness v0.7.1 (2026-07-17) release

      What's Changed

      • Remove third-party MCP endpoint from pydantic-ai-harness skill by @adtyavrdhn in #368
      • Fix search_files return description parsing by @adtyavrdhn in #377
      • Keep already-empty ModelRequests in LimitWarner._strip_old_warnings by @dsfaccini in #311

      Full Changelog : v0.7.0...v0.7.1

    11. 🔗 anthropics/claude-code v2.1.214 release

      What's changed

      • Fixed single-segment dir/** allow rules like Edit(src/**) auto-approving writes to nested dir/ directories anywhere in the tree instead of only <cwd>/dir
      • Fixed a permission-check bypass affecting commands run in Windows PowerShell 5.1 sessions
      • Fixed Bash permission checks to fail closed on file-descriptor redirect forms that bash parses differently than the permission analyzer
      • Fixed Bash permission checks misjudging very long commands — commands over 10,000 characters now always prompt instead of running automatically
      • Fixed Bash permission checks treating zsh variable subscripts and modifiers in [[ ]] comparisons as inert text — these commands now prompt for approval
      • Fixed Bash permission checks to no longer auto-approve certain help and man commands that could run unsafe options, command substitutions, or backslash paths
      • Fixed permission prompts on remote sessions that could proceed before the local confirmation dialog
      • Added the EndConversation tool: Claude can end sessions with highly abusive users or jailbreak attempts, as on claude.ai since 2025 — see https://www.anthropic.com/research/end-subset-conversations
      • Added a periodic progress heartbeat for long-running tool calls that previously went silent
      • Added an ISO modified timestamp to memory file frontmatter
      • Added message.uuid, client_request_id, and tool_source attributes to OpenTelemetry log events for message-level correlation and tool provenance
      • Added CLAUDE_CODE_OTEL_CONTENT_MAX_LENGTH to configure the 60 KB truncation limit on OpenTelemetry content attributes
      • Added reasoning effort to the subagentStatusLine payload, so custom agent rows can render model and effort
      • Added permission prompts for docker commands (including the Podman docker shim) carrying daemon-redirect flags (--url, --connection, --identity, and Podman's remote mode) that previously ran without one
      • Fixed a crash when a GrowthBook feature evaluates to null, and a bug where a malformed flag payload could wipe the cached feature flags
      • Fixed Bash tool killing the Claude session when a pkill -f pattern accidentally matched the CLI's own process (Linux)
      • Fixed unbounded memory growth when --settings points at a device file or multi-GB file; oversized (>2 MiB) settings files now fail at startup with a clear error
      • Fixed streaming turns failing with "Socket is closed" behind corporate proxies on Windows
      • Fixed stream-json output truncation at exit for slow-reading SDK/pipeline consumers; the exit drain now scales with queued bytes instead of a flat 2s cap
      • Fixed scheduled tasks refusing their own configured prompt as untrusted input — the fired prompt is now delivered as the session's assigned task
      • Fixed PowerShell tool commands hanging until timeout when a child process waited on standard input (Windows)
      • Fixed Python scripts under the PowerShell tool crashing with UnicodeDecodeError when reading non-UTF-8 data from standard input (Windows)
      • Fixed Python scripts run via the PowerShell tool crashing with UnicodeEncodeError on non-ASCII output, and PowerShell 7 error messages containing raw ANSI escape sequences (Windows)
      • Fixed the PowerShell tool reporting where.exe, fc.exe, and diff.exe as errors when they return a valid negative answer (Windows)
      • Fixed > and >> under the PowerShell tool on Windows PowerShell 5.1 writing UTF-16LE files that other tools couldn't read as UTF-8
      • Fixed a displaced background daemon deleting its successor's control socket on shutdown, which made the next client kill the healthy replacement daemon
      • Fixed background sessions parked with ← or /background and left idle keeping the background daemon and a worker process alive indefinitely
      • Fixed completed background sessions being impossible to remove via claude rm or the agent view once the background service had gone idle
      • Fixed background sessions dispatched from a non-git folder being impossible to delete from the agents view
      • Fixed reopening a stopped background session failing to restore its saved conversation when an unreadable folder exists in the session store
      • Fixed the Remote Control "session ready" push notification firing for sessions where Remote Control was not explicitly enabled
      • Fixed /install-github-app and the /mcp settings menu being blocked in agent-view sessions — they're now refused only in background sessions with no terminal attached
      • Fixed plugins enabled via the --settings CLI flag not loading (regression since v2.1.181)
      • Fixed feature flags going stale in long-running sessions after the OAuth token rotates
      • Fixed /ultrareview refusing to run in repos with no merge base — it now offers to review all tracked files
      • Fixed claude update and claude doctor hanging silently, and the /status System diagnostics section going blank, when a shell-config path is a directory
      • Fixed memory frontmatter values being silently truncated at an inline # when memory files are saved
      • Fixed session cost and token telemetry double-counting on streams that emit multiple cumulative message_delta frames
      • Fixed a spurious "check your network" warning that appeared while the advisor was thinking
      • Fixed hooks with exit code 2 not blocking as documented when the hook's stdout JSON fails schema validation
      • Fixed OTel log events emitted outside the turn's async context missing the interaction span's trace context
      • Fixed MCP transient errors during prompts/resources refresh clearing the server's slash commands and resources
      • Improved the claude rc workspace-trust error in the home directory to say trust there is never saved and to suggest running from a project directory
      • Changed single-segment dir/** hook if: conditions to match only <cwd>/dir; write **/dir/** for any-depth matching. deny/ask permission rules keep their any-depth match.
      • Changed file commands using -m/--magic-file or -f/--files-from to require permission instead of being auto-allowed as read-only
      • Changed keep-alive connection pooling to disable after a stale-connection error, so retries open a fresh socket
      • Changed SessionStart hooks to report source "fork" when a session begins as a fork instead of "resume"
    12. 🔗 New Music Releases Phish - 2026-07-18: Merriweather Post Pavilion, Columbia, MD, USA rss

      Phish - a new release is available:

      • 2026-07-18: 2026-07-18: Merriweather Post Pavilion, Columbia, MD, USA (Live)

      Amazon: Canada | Deutschland | France | United Kingdom | United States

      Visit muspy for more information.

    13. 🔗 Ampcode News Subscriptions, At Last rss

      Today we're launching Amp Subscriptions in Beta. You can now subscribe monthly to Amp and explore the frontier with us, with cheaper and more predictable pricing:

      Subscription FAQs

      If you subscribe on or before Sunday, July 19[^1], you'll get bonus 2x usage for orbs and agents in the first month.

      Amp Is Not (Necessarily) Expensive Anymore

      Amp just got a lot cheaper for many of you, especially if you link your ChatGPT subscription.

      We know you've been asking for this for a long time. Until now, Amp's pricing model has been pay-as-you-go for tokens at API prices, no subscription. Compared to other agents on monthly subscriptions, this made Amp more expensive—"the Apple or Porsche of agentic coding tools", to put it nicely.

      But everything is changing. Great tokens are reasonably priced. Good-enough tokens are downright cheap (like GLM-5.2 in our new low mode). Being on the frontier no longer requires using the most expensive models.

      You can still pay-as-you-go in Amp; monthly subscriptions aren't required.

      And, to be clear, to use Amp beyond your subscription's included monthly limits, you need to link your ChatGPT subscription or add paid credits.

      The Frontier Runs in Orbs, Not Your Laptop

      The frontier is now about agents working for you in parallel, without your supervision, on remote machines. We call these "orbs", and Amp's monthly subscriptions include so much orbs usage you don't need to worry about counting the minutes.

      We want you to finally be able to (and want to) kill your singleton local dev environment.

      We want you to make your agents go further to prove to you their work is correct, with videos and screenshots and local dev portals, and much less manual code review.

      Remember last year, when other agents asked you to approve the agent's work step-by-step, edit-by-edit? Amp users realized before anyone else that was dumb and slow, and Amp never did that.

      This shift feels similar to us. It's inevitable, and we want it to go as fast as possible. We hope this subscription makes it easy for you to explore this new frontier with us.

generated: July 21, 2026 at 19:01:22