jph00

They rarely are IO constrained.

No, your job is to help your reader get to the end of the text. That means writing in a way that most of your audience finds compelling, readable, and not intimidating.

Not all readers are the same, so you will fail at your job for some readers.

But few readers are emotionless automatons that need nothing but dry technical content, unless it’s a topic they are very motivated to understand.

This is not due to slowness of the file system. Native ntfs tools are much faster than Unix ones in some situations. The issue is that running Unix software on windows will naturally have a performance impact. You see the same thing in reverse using Wine on Linux. Windows uses a different design for IO so requires software to be written with that design in mind.

Obviously what matters is how much of the world’s products they produce - especially products that require high energy input. I can’t imagine why you think per capita is the appropriate statistic to compare.

This has already been pointed out to you in this discussion, so it seems you are not actually engaging with the information you’re being provided with for some reason.

I got one of these stupid emails too. I’m guessing it spammed a lot of people. I’m not mad at AI, but at the people at this organisation who irresponsibly chose to connect a model to the internet and allow it to do dumb shit like this.

It reads exactly like all his writing over many years afaict. Which is to say - it reads well. Just because someone is clear, thoughtful, and thorough, does not make them an AI. AI writing is actually quite different to this.

Your request to read charitably is not supported by your followup of cartoonish straw man questions.

You are using rhetorical trickery to make a point rather than engaging in honest dialog.

You misunderstand how neurodivergence is be handled in education. It isn't a single diagnosis, and does not have a single accommodation. We use a catch-all word because it makes it easier to talk about as a collection of issues, but that's not how it's diagnosed or treated.

If you would find wearing noise blocking ear muffs, or sitting on a bouncy chair, or using a typing instrument instead of writing, improves your performance on a test, then yes that should be permitted.

(I do also think it would be a good idea if people had longer for many tests or tests had less on them. That kind of speed is rarely an important part of real world workplaces so those tests are rewarding low-value skills.)

You incorrectly drew an implication. The authors words only actually imply that some accommodations are still needed, not that they are the same accommodations.

This conclusion is obvious given that the underlying condition is not curable.

A third is about as common as astigmatism in >50 year olds (like me, for instance!) I wear glasses to accommodate this disability, and as a result have nearly no practical problems due to it.

I don't think a problem having a high frequency means that we should decide it doesn't matter or need rectification.

I don't know about Stanford, but in earlier schooling accomodations can include things like being allowed to sit on a bouncy chair, or use a fidget toy, or type instead of hand-write (physical asynchronous development is a common issue), or wear headphones, or take more frequent breaks.

I do think that more flexibility in educational environments might be good for most people, yes.

Amongst groups for extremely gifted kids I’ve seen, well over half are neurodivergent. It’s a well understood issue in gifted kids psychology. When these kids are accommodated appropriately they ace their classes, and when not, they fail out entirely, even at the most basic levels of education.

So the statistics mentioned in the article are not necessarily inconsistent with what we’d expect, since Stanford is a highly selective school that’s by definition going to be picking gifted kids over less gifted ones, and from that group will pick those that were accommodated appropriately.

(There could also be cheating - I don’t know either way. I’m just commenting on the premise of the article. One person in it claims the kids aren’t really disabled because they don’t have wheelchairs. Hopefully it’s fairly obvious that this claim is totally illogical. Such an obviously unreasonable claim on a website called “Reason” makes me wonder what they are actually trying to achieve there.)

If Sam said that, he is wrong. (Remember, he is not an AI researcher.) Anthropic have been using this kind of approach from the start, and it's fundamental to how they train their models. They have published a paper on it here: https://arxiv.org/abs/2212.08073

On Mac you type opt-shift-hyphen — like this — and on Win/Linux you use a compose key.

A lot of people who care about typography/grammar have spent a moment to learn to do this. Once learned, you can use it for the rest of your life.

IMO the em-dash version is way easier to read in this example, FWIW.

The article didn't read at all like AI-generated text.

And not even in their native tongue :(

There’s already a language that provides all the features of awk plus modern language conveniences, and is available on every system you can think of. It’s Perl.

It even comes with an auto translator for converting awk to Perl: https://perldoc.perl.org/5.8.4/a2p

It also provides all the features of sed.

The command line flags to learn about to get all these features are: -p -i -n -l -a -e

The author does not say a script works as well as a proof.

We knew in 2017 that PyTorch was the future, so moved all our research and teaching to it: https://www.fast.ai/posts/2017-09-08-introducing-pytorch-for... .

Actually there are VAEs which use a codebook approach to creating discrete tokens instead of float vectors. There has been some success in that direction in diffusion models for instance.

(2) is not quite right. I created ULMFiT specifically because I thought a language model pretrained on a large general corpus then fine-tuned was the right way to go for creating generally capable NLP models. It wasn't an accident.

The fact that, sometime later, GPT-2 could do zero-shot generation was indeed something a lot of folks got excited about, but that was actually not the correct path. The 3-step ULMFiT approach (causal LM training on general corpus then specialised corpus, then classification task fine tuning) was what ChatGPT 3.5 Instruct used, which formed the basis of the first ChatGPT product.

So although it took quite a while to take off, the idea of the LLM was quite intentional and has largely developed as I planned (even although at the time almost no-one else felt the same way; luckily Alec Radford did, however! He told me in 2018 that reading the ULMFiT paper was a big "omg" moment for him and he set to work on GPT right away.)

PS: On (1), if I may take a moment to highlight my team's recent work, we updated BERT last year to create ModernBERT, which showed that yes, this approach still has legs. Our models have had >1.5m downloads and there's >2k fine-tunes and variants of it now on Huggingface: https://huggingface.co/models?search=modernbert

This is quite a good overview, and parts reflect well how things played out in language model research. It's certainly true that language models and deep learning were not considered particularly promising in NLP, which frustrated me greatly at the time since I knew otherwise!

However the article misses the first two LLMs entirely.

Radford cited CoVE, ELMo, and ULMFiT as the inspirations for GPT. ULMFiT (my paper with Sebastian Ruder) was the only one which actually fine-tuned the full language model for downstream tasks. https://thundergolfer.com/blog/the-first-llm

ULMFiT also pioneered the 3-stage approach of fine-tuning the language model using a causal LM objective and then fine-tuning that with a classification objective, which much later was used in GPT 3.5 instruct, and today is used pretty much everywhere.

The other major oversight in the article is that Dai and Le (2015) is missing -- that pre-dated even ULMFiT in fine-tuning a language model for downstream tasks, but they missed the key insight that a general purpose pretrained model using a large corpus was the critical first step.

It's also missing a key piece of the puzzle regarding attention and transformers: the memory networks paper recently had its 10th birthday and there's a nice writeup of its history here: https://x.com/tesatory/status/1911150652556026328?s=46

It came out about the same time as the Neural Turing Machines paper (https://arxiv.org/abs/1410.5401), covering similar territory -- both pioneered the idea of combining attention and memory in ways later incorporated into transformers.

Everything is recorded so it doesn't matter at all if you catch up later. Some people in the preview course didn't start until we finished! Obviously you'll get better interaction with the community if you're following along at the same time, but that's the only real issue.

I'd say budget a minimum 4 hours homework + 3-4 hours lesson watching time.

Yes I think you've done a good job of capturing the key ideas. Thank you for taking the time to look into it!

I think you might be somewhat under-estimating the amount of novel ideas in, and the significance of, the solveit platform. But "chatgpt + vscode editor + jupyter + a persistent Linux server" is a reasonable starting point for thinking about what it consists of.

It's totally fine to disagree on the philosophy. I suspect it'll turn out that both the approach you describe and our very different approach can both work, and are probably suited for different kinds of people and tasks.

It's very early days and there's no established methodologies for AI-assisted software dev. I know our approach works and scales across a team of 10 and over a period of >1 year (and across multiple connected projects), since that's what we do in-house.

The 400 includes platform access from signup until a few weeks after course finishes. No quota - use whatever you need. You can't purchase access to the platform directly. It's not aimed at junior devs - e.g here's a post from a 25 year experience dev: https://christhomas.co.uk/blog/2025/09/24/the-human-is-the-a... . Alums from the preview course include professors, senior VPs, etc. Our approach to using AIs is very different to automated approaches like DSPy -- it is all about human-in-the-loop; the human is the agent. We do tackle head on the inherent limitations of LLMs, but not using anything like JEPA (LeCun's approach).

At the end of the last course we put out a survey and asked for feedback. There were multiple questions in the feedback form. That's why there are multiple quotes from each person.

If you google any of those names you'll see they are absolutely real people. E.g. here's Pol's Google Scholar page: https://scholar.google.com/citations?user=ayz0DtUAAAAJ&hl=en . (And I see he's posted here on this HN chat too in fact.) Here's Mathew Miller on Twitter: https://x.com/matdmiller?lang=en .

Oops that should say "which fast.ai is now part of". s/not/now/

I apologise folks that we did a bad job of explaining exactly what we're launching! My bad. :( I've added this to the top of the article now -- I hope this does a better job of explaining things:

----

*tldr from Jeremy:* You can now sign up for Solveit, which a course in how to solve problems (including coding, writing, sysadmin, and research) using fast short iterations, and also provides a platform that makes this approach easier and more effective. The course shows how to use AI in small doses to help learn as you build, but doesn't rely on AI at all -- you can totally avoid AI if you prefer. The approach we teach is based on decades of research and practice from Eric Ries and I, the founders of Answer.AI. It's basically the opposite of "vibe coding"; it's all about small steps, deep understanding, and deep reflection. We wrote the platform because we didn't find anything else sufficient for doing work the "solveit way", so we made something for ourselves, and then decided to make it available more widely. You can follow the approach without using our platform, although it won't be as smooth an experience.

The platform combines elements of all these: ChatGPT; Jupyter Notebook + nbdev; Bits of vscode/cursor (we embed the same Monaco editor and add similar optional AI and non-AI autocompletion); a VPS (you get your own persistent full VPS running Linux with a URL you can share for public running applications); Claude Code (all the same tools are available); a persistent terminal. Then there's some bits added that don't exist elsewhere AFAIK: something like MCP, but way simpler, where any Python function can be instantly used as an AI tool; the ability to refer directly to any live Python variable in AI context (but optional, so it doesn't eat up your context window); full metaprogramming of the environment (you can through code or AI tools modify the environment itself or the dialog); context editing (you can -- and should -- directly edit AI responses instead of tell the AI it's wrong); collaborative notebook coding (multiple people can edit the dialog, run code, etc, and all see live updates).

That's fair! I guess since it's a new thing that doesn't quite neatly fit in a category, we were perhaps too shy about trying to define it. Also, we really want to focus on the methodology, rather than the platform. But yes, you're right we should explain the platform too. :) I'll have a go here, and will then go and add it to Johno's article.

So basically, you can think of the platform as combining all these: ChatGPT; Jupyter Notebook + nbdev; Bits of vscode/cursor (we embed the same Monaco editor and add similar optional AI and non-AI autocompletion); a VPS (you get your own persistent full VPS running Linux with a URL you can share for public running applications); Claude Code (all the same tools are available); a persistent terminal.

Then there's some bits added that don't exist elsewhere AFAIK: something like MCP, but way simpler, where any Python function can be instantly used as an AI tool; the ability to refer directly to any live Python variable in AI context (but optional, so it doesn't eat up your context window); full metaprogramming of the environment (you can through code or AI tools modify the environment itself or the dialog); context editing (you can -- and should -- directly edit AI responses instead of tell the AI it's wrong); collaborative notebook coding (multiple people can edit the dialog, run code, etc, and all see live updates).

The combination of these things is rather different (and IMO better!) than the sum of its parts, but hopefully this helps a bit?