Open Thread Autumn 2026
If it’s worth saying, but not worth its own post, here’s a place to put it.
If you are new to LessWrong, here’s the place to introduce yourself. Personal stories, anecdotes, or just general comments on how you found us and what you hope to get from the site and community are invited. This is also the place to discuss feature requests and other ideas you have for the site, if you don’t want to write a full top-level post.
If you’re new to the community, you can start reading the Highlights from the Sequences, a collection of posts about the core ideas of LessWrong.
If you want to explore the community more, I recommend reading the Library, checking recent Curated posts, seeing if there are any meetups in your area, and checking out the Getting Started section of the LessWrong FAQ. If you want to orient to the content on the site, you can also check out the Concepts section.
The Open Thread tag is here. The Open Thread sequence is here.
Is there a repeatable process for getting stuff written in a reasonable amount of time?
I take an excessively long time to write most things and I generally find the writing process unpleasant (I think these both cause each other), so I tend to avoid writing.
I got an 800 on the writing SAT, which implies that I’m good at things like grammar and sentence structure, but if I have to write something longer than a paragraph, I get stuck and I often avoid texting due to similar difficulties).
Is there a specific process (as opposed to something vague like “write a creepy rough draft and then edit it”) that you use that gets stuff written quickly? What step by step sequence of actions do you take when you want to write something? (I know the process will be different for different kinds of writing, but any example at all would be helpful)
I have a similar problem, and a solution that I imagine but I never actually tried would be to write an outline first (and maybe do some fact-checking before you spend an afternoon writing an article based on a possibly wrong premise), and then record yourself talking, let the computer transcribe it, and then edit it.
computer-facilitated dictation has come a long way and some people find it liberating. that said, it has its own idiosyncrasies and can get in the way of more technical writing. give it a go though. buy a good microphone and/or headset—they aren’t that expensive and quality matters. the Apple ecosystem built around the latest model AirPods is state of the art.
Learning how to use AI Agents?
I’m not a programmer but seeing all these supposedly ‘vibecoded’ apps is giving me FOMO—especially considering how LLMs, in general, are now an integral part of any future work environment. What are the best resources for learning agentic programming? I see that Anthropic have some free online courses, not sure of ChatGPT equivalents, but it seems like it would help to have some understanding of MCP?
Then there’s the question of environment to actually run agents? What are the best environments for absolute beginners who don’t know what a Python Wheel is, and think a sandbox is for making castles?
I can tell you what I use… and if that is horribly wrong, hopefully someone else will be sufficiently horrified reading that and will correct me. ;)
On Windows (you probably also have that?) I enabled WSL and installed Ubuntu. In Ubuntu I created a user called “claude”, and under this user I installed Claude Code. In Windows, I installed Windows Terminal from Microsoft Store.
If any of these steps sound complicated, the web chatbot can navigate you through them! I don’t know if there is an equivalent for chatgpt, but the web chatbot can tell you that, too. And the web chatbot can also tell you how to enable sandbox mode.
You do not have to be a Linux pro. The idea is that installing Ubuntu in WSL creates a computer inside your computer—and you let the AI work on the inner computer. However, the outer computer is still reachable from the inside one via ”/mnt/c” (perhaps there is a way to remove that? no idea). Never ask the AI to do something on the outer computer; tell it to only use its ”/home/claude” directory. (The sandbox mode should enforce this. It will probably also keep asking you tons of questions, that may be annoying.)
How does it work: I start the Windows Terminal, and open an Ubuntu tab (so I have a command-line access to the inner computer). I type “claude” for the first time, or “claude—continue” every following time. Then I communicate to Claude Code using that window in the Windows Terminal.
How can I copy the files into / out of the inner computer? In Explorer, type something like “\wsl$\Ubuntu\home\claude” into the address bar, and it will show you the inner computer’s disk. You can copy there.
...the cool part is that if you did not understand any of this, you can just copy the entire comment into a web chatbot, and ask it to explain it, or to navigate you step by step, or to propose improvements. Basically, use the web chatbot in order to set up the system on your machine.
Thanks, that’s a very clear write up. I didn’t even need to ask a chatbot to understand it.
What’s the speed or latency like? Is it very resource intensive running Ubuntu inside of Windows like that?
My computer is 11 years old, and even back then it was a cheap machine, so… it works… I can’t say how quickly because I have nothing to compare it with (never ran Claude Code on a different computer) and I can watch a movie while Claude Code is working, depending on the movie resolution. I’d guess it consumes about 50% of the computer’s capacity, so it is possible to do some simple tasks in parallel. It is faster than using a virtual machine. I am okay using it like “I spend 20 minutes talking to Claude Code about what to do in the next iteration, then I say do it, and I do something else, like watch a movie or do the dishes”.
There is one part of your question I forgot to answer, and that is specifically about Python. (I usually work in Java, so I tell Claude Code to make me a ZIP file that I can unzip and run on Windows. Then I copy the ZIP file and it works.) I am not that experienced in Python, but it seems to me like a good idea to use “venv”, which is a virtual Python environment, in other words a system of libraries installed specifically for the purpose of your app. The thing is that pure Python does not have a good way to handle library versions: if you tell it to install library X, it will install the latest version of it. If you need an older version, because the new one is not backwards compatible, you are screwed. You are even more screwed if you have two Python programs who each require a different version of the same library.
The solution to this problem is the “venv” which basically installs the libraries for your program in a separate place, as opposed to directly in the Python installation. Advantage: solves the “what if the latest version is not the best” problem. Disadvantage: slightly more space on disk (installing the libraries separately for each project, even if not necessary), and you need to explicitly start the environment before starting the program.
What I would suggest: Tell Claude Code to create you a ZIP fie containing the generate Python program and two Windows BAT files—one to create the virtual environment (unless it already exists) and install there all libraries required by your program (unless they are already installed); the idea is that this BAT can be used repeatedly if the list of libraries later changes. The second BAT file to activate the virtual environment and start the Python program. And then, the usage is just: double-click “init.bat”, wait until done, then double-click “run.bat” and use the Python program.
You can probably ignore this, because for the freshly written code the latest version will almost certainly be the right one. This is something you may worry about in long term, or if you try to publish the code (when publishing Python programs one should specify the versions of the libraries… somehow).
depends on your application. WSL overhead can be as low as 1% or as high as 90%. most heavy compute is done on the cloud these days (including claude CLI/codex inference), so locally you likely won’t notice if you’re not short on RAM. some of that worst case performance comes from interaction between Linux and Windows filesystems, so avoid that.
I would assume that your FOMO means that you probably do not have time to actually learn how to code, to be able to review AI-generated code. This doesn’t mean I wouldn’t in general recommend people to learn how to code—I think at this point it depends on the circumstances.
With that in mind, I think the environments (sandboxes, and not the castle ones) built into ChatGPT/Claude that run the code that those LLMs write “on the fly” (while you interact with them through the usual chat interface), are your best friends here. They allow you to quickly iterate on simpler concepts without fearing that you might mess something up on your machine. I’ve seen some really great demos built fully inside those.
More importantly, using them even to flesh out simple ideas will give you a feel of what interacting with LLMs is like when vibecoding: how they react to steering at different levels of abstraction, what their common blind spots and ticks are, and to what level are they blindly agreeable at different levels of the stack. Obviously, a lot of their errors might go unnoticed since you won’t understand the code, but you will by carefully examining the product you will catch many of them. I think that at this stage, it is most important for you to be able to sniff out when AI is deceptively confident, and how best to correct its course.
Next, I would practice writing clear and self-contained “one-shot” tasks. After a heavy back-and-forth session, once you’re happy with how one of your ideas turned out (following what I described above), try writing a clear task which, given to that same model in a fresh session, would result in equally good product. Note a couple of things here:
Try to avoid overly specific instructions based on the errors the model has made. Especially try to avoid “negative” instructions. E.g. if the model initially made some button highlighted by adding a glow effect, and you wanted a more minimalist style, your one-shot task should not contain “The button should not be glowing”. Instead, describe what kind of style you do want.
Be conscious of various dead-ends and loop-y bits of discussion you had with the initial agent and try to cut through those—your one-shot task shouldn’t necessarily follow the same order of subtasks as the original session did.
Specify the intent clearly, and avoid overs-specifying whatever can be induced from that intent. This one is difficult to explain and over time you’ll get a feel for it. Roughly speaking, LLMs these days are very good at extrapolating user intents (I’d say this is one of the main improvements that enabled “agentic coding” that we have today), and it should be leveraged as much as possible. If you state your intent as “I want this popup to push users to buy X as strongly as possible”, and you get something distasteful, then try to modulate your intent instead of appending fixes. Rewrite it as “I want this popup to convince potential customers, especially those on the fence, about the benefits of X”.
In practice, of course, you will rarely write such one-shot documents, and the models today really do shine in their ability to iterate on a task. But every message you send during such iterations will be better if you practice on these one-shotters.
Finally, still relying solely on built-in sandboxes, take one of your successful one-shot specs, and pass them on to different models: try different providers, different model tiers (e.g. Luna/Terra/Sol/Astra on GPT, Haiku/Sonnet/Opus/Fable on Calude). Try some of the “previous generation” models (e.g. Gemini 3.1 Pro). This will help you understand how capabilities are improving with model size and over time, and will help you prepare for the next gen.
After you have iterated in this way on a couple of your ideas (that you found are suitable for built-in sandboxes), take your newly built LLM-whisperer experience and start building locally. At this point, I’m sure, you’ll be confident enough, have enough interesting ideas to play with, and know the names of some of the tech stacks that could support those ideas, that you will naturally ask your (at that point) favourite model for advice, and it can guide you through the local setup. There will always be risks with doing so without having substantial SWE experience, but I think the advice around sandbox setup that LLMs will give you today is at least as good as what you’d get from the internet—as long as you know how to steer those models well.
Good luck!
I often browse lesswrong in greyscale while on mobile and find that I cannot distinguish when I have upvoted a post or comment. The strong upvote (and downvote) is very distinguishable and the regular downvote changes shade when it has been pressed, but the regular upvote doesn’t seem to have an analogous change in greyscale. The same nit applies to comment agree votes as well. It’s a very minor inconvenience and I figured it might not have been an issue surfaced in the past.
Many memeplexes evolve to be religions in order to capture your “epistemic lymph nodes”. That is, in order to make a set of narratives maximally sticky, it must infect the top of your ontology; or it must modify the rules of your inference.
That being said, similarly to evolutionary psychology, getting predictive value out of these considerations seems kind of hard.
Au contraire, it suggests you should be more paranoid about your epistemic methods than about object level claims. That is, I should trust people less when they say claims like “X is how you should evaluate whether Y is true” compared to “Here’s why Y is true”. I should of course also downweight whatever preconceived notions of epistemic process I have if I got them from a society hijacked with anti-epistemic memes.