- https://github.com/simonw/denobox is a new Python library that gives you the ability to run arbitrary JavaScript and WASM in a sandbox provided by Deno, because it turns out a Python library can depend on deno these days. I built that on my phone in bed yesterday morning.
- https://github.com/simonw/pwasm is a WebAssembly runtime written in pure Python with no dependencies, built by feeding Claude Code the official WASM specification along with its conformance test suite and having it hack away at that (again via my phone) to get as many of the tests to pass as possible. It's pretty slow and not really useful yet but it's certainly interesting.
- https://github.com/datasette/datasette-transactions is a Datasette plugin which provides a JSON API for starting a SQLite transaction, running multiple queries within it and then executing or rolling back that transaction. I built that one on my phone on a BART (SF Bay Area metro) trip.
- https://github.com/simonw/micro-javascript is a pure Python, no dependency JavaScript interpreter which started as a port of MicroQuickJS. Here's a demo of that one running in a browser https://simonw.github.io/micro-javascript/playground.html - that's my JavaScript interpreter running inside Python running in Pyodide in WebAssembly in your browser of choice, which I find inherently amusing.
All of those are from the past three weeks. Most of them were built on my phone while I was doing other things.
I think that's the reason why LLMs work so well for some like you, and generate slop for others, because if you let them alone with projects that require opinionated code and actual decision making they most often don't grasp the users intention well or worse misinterpret it so confidently that you end up with something with all the wrong opinions and decisions compounding path-dependently into the strangest and most useless slop.
Yes, exactly! How amazing is it that we have technology now that lets us quickly build projects where we would normally have to spend considerable time on the finicky implementation details?
Not that I mind, of course. As you said: amazing!
Maybe someone just check in with the CEOs who were in the news recently talking about their work force…
Every single tool or utility you have in the back of your head, you can just make it in a few hours of wall-clock time, minutes of your personal active time.
Like I wanted a tool that can summarise different sources quickly, took me ~3 hours to build it using llm + fragments + OpenAI API.
Now I can just go `q <url>` in my terminal and it'll summarise just about anything.
Then I built a similar tool that can download almost anything `dl <url>` will use yt-dlp, curl and various other tools depending on the domain to download the content.
You should reinterpret that as "not having to type the code out be hand any more". You still need a significant depth of coding knowledge and experience to get good results out of these things. You just don't need to type out every variable declaration and for loop yourself any more.
More and more I think this is it.
Looking at these projects, I have a few questions:
1. These seem to be fairly self-contained and well specified problems, which is the best case scenario for “vibe coding”. Do you have any examples of projects where the solution was somewhat vague and open-ended? If not, how do you think Claude Code or similar would perform?
2. Did you feel excited or energized by having an LLM implement these projects end-to-end? Personally, I find LLMs useful as a closely guided assistant, particularly to interactively explore the space of solutions. I also don’t feel energized at all by having it implement anything non-trivial end to end, outside of writing tests (and even then, not all types of tests!).
3. Do you think others would find these projects useful? In particular, if you vibe coded them, why couldn’t someone else do the same thing? And once these projects are picked up by future model training runs, they’ll probably be even easier to one shot, reducing the value even further.
Let me provide an example of what I mean by (2), at least in the context of hobbyist dev. I could have Claude Code vibe code a Gameboy emulator and it would probably do a fine job given that it’s a well specified problem that is likely well represented in its training data. But the process would neither be exciting nor energizing. I would rather spend hours gradually getting more and more working and experience the fruits of my labor (I did this already btw).
At $DAYJOB, I simply do not have confidence in an LLM doing anything non-trivial end to end. Besides, the complexity remains in defining the requirements and constraints, designing the solution, gaining consensus, and devising a plan for implementation. The goal would be for the LLM to pick up discrete, well defined chunks of work.
This one is pretty open ended, and I'm having a ton of fun designing and iterating on it: https://github.com/simonw/claude-code-transcripts - it's also attracting quite a few happy users now.
I have another project in the works in Go which is proving to be a ton of fun from a software design perspective, but it's not ready for outside eyes just yet.
"Did you feel excited or energized by having an LLM implement these projects end-to-end"
I'm enjoying myself so much right now. My BART rides have never been this entertaining before!
"Do you think others would find these projects useful? In particular, if you vibe coded them, why couldn’t someone else do the same thing?"
I don't think many developers have the combined taste and knowledge necessary to spin up Denobox or django-transactions. They both solve problems that I'm very confident need solving, but I expect to have to explain why those matter in some detail to all but a very small group of people who share my particular interests.
The other two are pretty standard - I suggest anyone who wants to learn more about JavaScript interpreters or WASM runtimes try something similar in the language of choice as a learning exercise.
As a long-time user of the language I'm happy see that Go seems to be excellent for LLM agent development. The language is simple, there's only one way to do loops etc. It hasn't changed that much syntax wise (I think `any` is the only thing that LLMs miss).
Gofmt (or goimports) makes sure all code looks the same, there are VERY robust linters and a built-in testing framework so the LLM only needs to know one. And the code won't even compile if there are unused variables or other cruft.
It might be boring or verbose, but it's also very predictable and simple. All things LLMs like :D
It's also really easy to read code and understand exactly what it does, I'm still finding Rust a lot harder to decode - way more ampersands!
> My BART rides have never been this entertaining before!
Not clear if this is snark, but if vibe coding on a train ride is actually energizing, then good for you haha.
> I don't think many developers have the combined taste and knowledge necessary to spin up Denobox or django-transactions.
Perhaps, but that’s just for now. What do you do when your “taste” no longer makes a difference? In other words, looking at the bigger picture, do you like where the field is going?
> I suggest anyone who wants to learn more about JavaScript interpreters or WASM runtimes try something similar in the language of choice as a learning exercise.
Agreed, but depending on learning style, vibe coding such a project might not teach you anything new at all :)
Because here In northern Europe you couldn’t even have a completely untrained teenager working 4 hours a week at minimum wage at that level.
There is nothing dubious about it. It’s providing verifiable value. Tasks that we would have set for developers or UX’ers last year are solved by it. At 1/50 of the cost, and with great scaling because the tasks are solved faster than you would even be able to explain them to a human and we can initiate 5-10 parallel tracks without having to onboard new people.
And sure it might not make sense to give a 200$/m AI tool to a worker you are paying 800$ but when we have devs that are paid 8000$/m then it’s great return on value to have one person being 10 times as productive at 8200$ instead of spending 80000$/m on ten developers just to be able to say we are doing authentic AI free artisanal software development.
Of course I don't know for sure if you had any substantial input other than writing a few paragraphs of prompt text and sending Claude some links, because I didn't witness your workflow there. But I think this is kind of what irks some people including myself.
What's stopping me from "building" something similar also? Maybe I won't be as fast as you since you seem to be more experienced with these tools, but at the end of the day, would you be able to describe in detail what got built without you asking Claude about it? If you don't know anything about what you built other than just prompting an AI, in my opinion you didn't actually "build" anything -- Claude did.
One of my favorite options is "directed" - "I directed this". It's not quite obvious enough for me to use it in comments on threads like this though.
I've also experimented with "We built" but that feels uncomfortably like anthropomorphizing the model.
One of the reasons I publish almost all of my prompts and transcripts is that I don't believe in gatekeeping this stuff and I want other people to be able to learn how to do what I can do. Here are the transcripts for me Denobox project, for example: https://github.com/simonw/denobox/tree/transcripts - you can view those with my new https://orphanhost.github.io/ tool like this: https://orphanhost.github.io/?simonw/denobox/transcripts/ses...
I don't say "my tablesaw and I built this table" I say "I built this table"
When you build a table, you use a tool as a means to an end, i.e. you use the tool to cut and shape, but you are fully in control and engaged in the process. When you prompt an LLM, you tell it what to do and it does something for you. How is that not the same as telling someone else to build the table for you? You don't say "I built the table", you say "I got someone else to build the table for me."
I think it's great that simonw responded with some information on his process, that definitely helps provide perspective on how he engaged with Claude to make these projects.
People are under zero obligation to release their work to the public. Simon actually publishes and writes about a remarkable amount of the side projects he builds with AI.
The rest of us just build tons of cool stuff for personal use or for $JOB. Releasing stuff to the public is, in general, a massive amount of extra work for very little benefit. There are loads of FOSS maintainers trapped spending as much time managing their communities as they do their actual projects and many of us just don't have time for that.
Software quality has been on a step downwards curve as far as quality and capabilities are concerned, for years before LLM coding had its breakthrough. For all the promises I'd have expected to, three years later, at least notice the downward trajectory easing off. But it hasn't been happening.
I wouldn't worry about this.
There are many examples of people sharing a project they've used LLMs to help write, and the result was not a huge amount of attention & expectation of burden.
Perhaps "I don't share it because I'm worried people will love it too much" even suggests the opposite: you can concretely demonstrate the kinds of things you've been able to build using LLMs.
> This is such a tired response at this point.
Lack of specificity & concrete examples frequently mean all that's left for discussion is emotion for hype and anti-hype, though.
In this thread, the discussion was:
pro: use LLMs or get left behind
conserve: okay, I'll start using LLMs when they're good
pro: no no they won't be that good, it takes effort to get to use them
conserve: do you have any examples?
pro: why should we have to share examples?
I like LLMs. But making big claims while being reticent about concrete claims and demonstrations is irksome.> I could if I wanted to, but I just don't feel like it.
What am I missing where I can understand that's not what you meant?
People seem to believe that there is a burden of proof. There is not. What do I care if you are on board?
I don't know what could change your mind, but of course the answer is "nothing" as long as you aer not open to it. Just look around. There is so much stuff, from so many credible people in all domains. If you can't find anything that is convincing or at least interesting to you, you are simply not looking.
Without enough adoption expect some companies you are a client of to increase prices more, or close entirely down the road, due to insufficient cash inflow.
So, you would care, if you want to continue to use these tools and see them evolve, instead of seeing the bubble pop.
The burden of proof rests on those making the positive claim. You say you don't care if others get on board, but a) clearly a lot of others do (case in point: the linked article) and b) a quick check of your posts in this very thread shows that you are indeed making positive claims about the merits of LLM assisted software development.
This is baffling. Why would you make the claim if you do not care if we are on board? Who are you talking to if not exactly those who you care to convince?
https://github.com/williamcotton/gramgraph
The motivation? I needed a declarative plotting language for another DSL I'm working on called Web Pipe:
GET /weather.svg
|> fetch: `https://api.open-meteo.com/v1/forecast?latitude=52.52&longitude=13.41&hourly=temperature_2m`
|> jq: `
.data.response.hourly as $h |
[$h.time, $h.temperature_2m] | transpose | map({time: .[0], temp: .[1]})
`
|> gg({ "type": "svg", "width": 800, "height": 400} ): `
aes(x: time, y: temp)
| line()
| point()
`
"Web Pipe is an experimental DSL and Rust runtime for building web apps via composable JSON pipelines, featuring native integration of GraphQL, SQL, and jq, an embedded BDD testing framework, and a sophisticated Language Server."https://github.com/williamcotton/webpipe
https://github.com/williamcotton/webpipe-lsp
https://williamcotton.com/articles/basic-introduction-to-web...
I've been working at quite a clip for a solo developer who is building a new language with a full featured set of tooling.
I'd like to think that the approach to building the BDD-testing framework directly into the language itself and having the test runner using the production request handlers is at least somewhat novel!
GET /hello/:world
|> jq: `{ world: .params.world }`
|> handlebars: `<p>hello, {{world}}</p>`
describe "hello, world"
it "calls the route"
let world = "world"
when calling GET /hello/{{world}}
then status is 200
and selector `p` text equals "hello, {{world}}"
I'm married with two young kids and I have a full-time job. Before these tools there was no way I could build all of these experiments with such limited resources.- https://tools.simonwillison.net/bullish-bearish
- https://tools.simonwillison.net/user-agent
If you're here to converse in good faith, what's your opinion of the examples I shared in this post over here? https://news.ycombinator.com/item?id=46574276#46582192
For more impressive examples see https://simonwillison.net/2025/Dec/10/html-tools/ and https://news.ycombinator.com/item?id=46574276#46582192
I can't gauge the other two since I don't use those things, so maybe they are cool, idk.
To some extend it's an understandable ask, but obviously even with a decent productivity boost side projects still require a lot of time and effort before a possible public release.