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.

I found this and the references within helpful.

Have you tried talking to someone about the topic, possibly while recording yourself, and then working off of whatever it is you ended up saying?

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.

You mean besides using an LLM? I've found mind map software helpful. I liked FreeMind, but there are others. It's pretty similar to outlining (and can be converted to one), but you can drag and drop subtrees to another location, etc.

There are many kinds of writing with different purposes, and they have different methods. What are you trying to do?

For things like essays or textbooks, dump everything into the mind map until you've covered all the points you want, and then use that subset for your outline.

Text is made of details, but you need the form first or they'll be out of place. I'm reminded of the No Erasing advice about drawing. Writing longer texts coherently is similar. You can maybe keep the form in your head, or you can dump it out first somehow. That's basically an outline.

There are different ways to organize trees. When being informative, consider prerequisites and what order you should present the points. You can probably do this by hand, but there are topological sorting algorithms you could try if it's getting too complicated. (Python standard library graphlib module, for example.) You are allowed to cover a point more than once. Iterative deepening depth-first search is an important algorithm to know. You can cover your mind map that way, with subsequent section going deeper, but repeating the basics.

When being persuasive (essays), consider that earlier points, if accepted, may make later points easier to accept.

For creative writing, show don't tell. Make your reader experience the thing. For writer's block, write more, even if it's bad. You don't have to show anyone when it's bad. Keep a journal. You don't have to talk about your day, especially creative writing is the goal. You make stuff up. Just do it more. Also read quality writing more. You get used to it, and this trains your brain to predict it. Predicting is basically the same as producing, which is how LLMs work.

Even for fiction, you can use outlines, but Rational Fic is more driven by coherent worldbuilding and characters, maybe more like a tabletop roleplaying game. Reading through a dungeon master's guide or equivalent may be helpful.

I haven't found a method for getting stuff written quickly. I also find it impossible to work with outlines. Here's why: at the outset, I only have a vague idea of what I want to write. I refine my thoughts through the act of writing; as I write, my own thinking get clearer, and I pull in quotes from sources that tend to nudge the narrative in new or interesting directions. I typically go through many iterations before I get to the finished result; more than 25 revisions were needed for my latest article. Quite often, a structure is imposed almost at the end of the process by snipping up the text and rearranging it. Needless to say, this goes against pretty much everything I was taught about writing at school. It's the method that works for me; I leave it here in the hope that it may be helpful.

I'd echo David's comments as well: my wife has published two novels and she can write for 2 hours max per day, often less, amounting to two or three pages.

You should complain on Intercom, it seems like the only way to consistently able to get a mod's attention except for pinging them, which I usually avoid

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:

1. 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.
2. 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.
3. 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 have definitely seen this online, and it also smells like a conspiracy theory to me. I can't tell you where it ultimately came from, just that certain influential people are parroting it, like the CEO of Mistral.

It feels like it's the standard pattern of calling everything security related that the companies do as being publicity stunts.

If you believe that Anthropic hold back Fable for their stated cybersecurity reasons as a publicity stunt, this is just more of the same reasoning.

The type of agents responsible for the Hugging Face cyberattack were relentless and were not particularly dissuaded by the fact that what they were doing was outside of the intended scope or illegal. These agents were trained to have an imperfect tendency to follow directions, but they also had a tendency to cheat, and those directions didn't have to come from humans. Agents might try workarounds when access is denied. You can already see this kind of thing happening with open-weight coding agents in open-source agent harness sandboxes.

MIRI's publications have a lot to say about why alignment is hard, what doesn't work, and what little progress we've made so far.

But start with The Sequences, ideally. There's probably a shorter corpus that would work though. Minimally, Raising the Sanity Waterline, and its linked posts, maybe? HPMOR covers a lot of the same ground in a more narrative way, but it's not short either.

If your very smart person is already minimally sane by rationalist standards, the most important point to learn might be security mindset. I don't have a good reading recommendation here. It came kind of naturally to me. But that wikitag is a start, at least.

The point is that a lot of obvious alignment answers don't work. One would need to treat obvious proposals with due suspicion and keep digging, rather than latching on to something when it just seems like it might work. When an adversary is out to get you, it's not enough to be respectable; you need to be paranoid. Maybe some of the James Randi skeptic stuff could be helpful here. In the face of charlatans, even scientists, who at least knew better than to be fooled by Nature (most of the time), could nonetheless be deceived.

Bostrom's Superintelligence: Paths, Dangers, Strategies covers a lot about the topic, although it's over a decade old now, a lot of it is still relevant.

For futurism in general, Superforecasting: The Art and Science of Prediction might be helpful. I started with Kurzweil's straight lines on log plots thesis, but I now think he's being too optimistic about outcomes. Three Major Singularity Schools is probably a good enough intro.

There's a deep relationship between programming and math. If your very smart person isn't already familiar with the topic (LEAN seems pretty well-known among mathematicians at this point.) then a textbook on formal verification of software is probably worth reading.

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.