An 11-Hour Reasoning Model Course in Practice: How Small Models Learn to Think

Machine learning author Sebastian Raschka has released a video course spanning over 11 hours that demonstrates how to train a model small enough to run on a laptop into a reasoning model. The course accompanies his book Build a Reasoning Model from Scratch and has sparked intense discussion on Hacker News about whether individuals can truly get hands-on with machine learning.

What Is a Reasoning Model? From Graders to Reward Signals

Raschka's definition is straightforward: a reasoning model is an ordinary large language model that has undergone additional training, where the training rewards answers that a program can automatically check. In other words, the model doesn't learn to reason from human ratings but from a checker that can judge right from wrong.

The course's path is designed pragmatically. Early videos load an already-pretrained small model, then build a grader that scores the model's answers on 500 math problems. Subsequent videos first try cheaper tricks, such as having the model answer multiple times and taking a majority vote. Then the same grader becomes the reward source during training, and the small model learns from the math problems it gets right. In the final video, the small model learns from a larger teacher model, replicating answers written by DeepSeek^Ad R1.

A note on hardware requirements. Early examples run on an ordinary processor, but training experiments are more practical on a GPU. This is also the most painful part of the HN discussion.

Verifiable Rewards and RLVR

What Raschka calls "answers a program can automatically check" corresponds in reinforcement learning terms to a verifiable reward. Such rewards don't rely on human preference ratings but come from a deterministic program: math problems compare final numeric values, coding problems run unit tests, and formal proofs are checked by a theorem prover. Reinforcement learning with verifiable rewards as its signal is often abbreviated as RLVR (Reinforcement Learning with Verifiable Rewards), and it is a key component in the training pipelines of reasoning models like DeepSeek R1 and the OpenAI o series.

The value of RLVR lies in bypassing expensive and noisy human annotation: as long as the checker is written correctly, the reward signal is objective. The cost is that it can only cover tasks whose answers can be judged by a machine; open-ended writing, strategic advice, and similar problems are hard to fit. This also explains why the course chose math problems as its training ground—the grader can run thousands of times cheaply in batch.

Majority Voting and Knowledge Distillation

The technique in the course of "having the model answer multiple times and taking a majority vote" is called self-consistency: sampling multiple reasoning paths for the same question and taking the most frequent answer. It requires no training at all, only inference compute, and is often used as a low-cost baseline before reinforcement learning.

The final video demonstrates knowledge distillation: having a small model fit the answer distribution generated by a large teacher model (such as DeepSeek R1). Unlike reinforcement learning, distillation doesn't require answers to be judged by a checker; the model learns the teacher's output style and reasoning traces, so some of the large model's capabilities can be transferred to a small model at lower compute cost.

HN Discussion: Software Can Start from Scratch, Machine Learning Can't

A reader tinkering at home said ML courses always feel like "one small step at a time," and that real practice requires far more compute than his devices can offer. One reply pinpointed the key difference: in software, a smart mind plus a cheap laptop is enough, but machine learning is more like biology or law—you need experimental conditions.

Another hobbyist confirmed this: he can build almost any new software for free, but running a trained model requires hardware he can't afford. Others offered a more optimistic path, pointing to small projects that already work, such as a classifier someone built to automatically organize bank statements for budgeting, emphasizing that "you don't need the best model for everything."

Other readers questioned the course's audience, suspecting it was a "personal brand monetization strategy." But a reader who trains models professionally said Raschka's previous book taught him more than any other source. The skeptic conceded this was a strong rebuttal but remained doubtful. The discussion ultimately points to a reality: introductory materials are easy to find, but compute for sustained experimentation is the real dividing line.

Legal Tech's "Git Moment": Version Control for the U.S. Code

Another project that drew attention came from legal tech company LexFina. They replayed every congressional amendment to nine titles of the U.S. Code since 2017, creating a system that lets you view the text of the law as it existed on any date.

The core argument has a programmer's flavor: programmers can see who wrote each line of code and when, while lawyers can only dig through prose-style notes beneath each provision. LexFina's example is the debt limit for small business bankruptcy—Congress has repeatedly raised it, let it lapse, and restored it since 2019. The higher limit expired in March 2022, and three months later Congress restored it for cases already filed. So for cases filed in between, the Code as printed at the time showed the lower limit, and only subsequent legislation changed the answer.

The construction method is also version-control-like: apply each law's amendment instructions to older text in date order, then compare against the next official edition. The company's own checks showed that 361 of 365 changes matched exactly. The page also color-codes which law introduced each phrase.

The significance lies in the fact that legal research is increasingly being handed to AI models. A study cited by LexFina found that these models often apply rules that have already been replaced. Discussion on HN extended from the Code to bills, with someone citing a 2007 New York Times column hoping version control could show what each legislator inserted into each change. One reader responded that the commit author would be the House Office of the Legislative Counsel—the nonpartisan lawyers who draft bills.

But a former legal data professional pointed out that lawyers already pay LexisNexis and Thomson Reuters handsomely for this, because cases are won or lost based on the law at the time. He cited the 2002 campaign finance law as an example and cautioned that textual differences don't equal changes in legal meaning.

The Codification Structure of the U.S. Code

The United States Code is not a single law passed by Congress at once, but a compilation of public laws scattered across the Statutes at Large over the years, organized by subject into 54 "titles," such as Title 11 for bankruptcy and Title 26 for tax law. When Congress passes a new law, it usually doesn't reprint an entire title but issues an amendment instruction specifying "replace a certain sentence in a certain section and subsection of a certain title with a certain sentence."

This means the Code's text is built up layer by layer of patches, and any printed edition reflects only the patch state as of that date. LexFina's approach is precisely to replay each amendment instruction in chronological order to reconstruct the text at any historical point—similar to replaying diffs in commit order in Git. For this reason, the provisions applicable to the same case at filing may differ from those at judgment, and lawyers must confirm "the text in effect at the time," not just the latest version.

Your Thumbs-Up Might Put the Entire Conversation into the Training Set

An August privacy page from Anthropic revealed an easily overlooked detail: in Claude's commercial products (such as Claude for Work and the API), a thumbs-up or thumbs-down stores the entire conversation for up to five years and may be used to train models. Reporting a bug has the same effect as pressing the thumbs-up or thumbs-down button.

The stored record includes chat content, custom styles, and model settings. Files brought in through connectors (such as Google Drive) are not included unless someone pastes them into the conversation. Each stored conversation is de-identified from user and customer IDs before use and is not associated with that user's other conversations. Only owners of Team and Enterprise plans can disable the thumbs-up/down buttons for employees. Separate pages for the Free, Pro, and Max plans also specify the same five-year rule; on those plans, conversations also enter training when users enable model improvement or when a conversation is flagged for safety review.

The controversy on HN centered on an edge case: whether turning off a Claude Code session survey also counts as feedback. One blogger worried it did, while another reader dismissed it as speculation. The blogger cited personal experience—he pressed zero to close a survey, yet Claude Code thanked him for helping improve the model. Someone then cited Claude Code's data policy, stating that answering surveys (including closing them) only records the rating and does not store conversation records. The blogger responded that the policy page appeared about six weeks after his post, which made him feel better about Anthropic.

A more substantive criticism came from a reader with higher expectations for enterprise plans: Anthropic could have retained only details, such as which model answered, without keeping the conversation itself. The counterargument was that such metadata is useless, because judging a bad answer requires seeing both the question and the answer.

The Boundary Between Feedback Data and Training Data

The data generated by thumbs-up/down buttons is commonly called feedback data, and it is a different collection channel from everyday conversation logs. What makes feedback data special is that it carries preference labels—the same conversation being liked or disliked forms a comparable set of positive and negative samples that can be used directly for reinforcement learning from human feedback (RLHF) or preference optimization. This is also why vendors are willing to retain it for longer periods: ordinary logs lose value over time, while labeled preference samples can be reused repeatedly for subsequent model iterations.

"De-identified from user and customer IDs" is a de-identification process that reduces the risk of associating data with a specific individual, but it is not the same as anonymization—the conversation content itself may still contain identifiable information. This is exactly the disagreement in the HN discussion over "whether keeping only metadata would work": metadata is enough to locate which interaction it was, but not enough to judge whether the answer was good or bad, so vendors tend to keep the question and answer text together.

The Blind Spot of Reviews: Owners Care More About Reliability Than Reviewers

A BetaScore study based on public reviews found that product owners on Reddit mention reliability about twice as often as YouTube reviewers. Their explanation is a time gap: reviews cover the first few weeks, while most failures appear months later.

The study used AI models to label thousands of opinions across 14 product categories and classify them by topic. Reliability and support accounted for 17% of owner opinions. Except for tennis ball machines, owners mentioned reliability more often in every category. The gap was especially pronounced for self-cleaning litter boxes (though the sample was small), with owners mainly describing failures and wait times for replacements. When owners mentioned reliability, most of the content was negative, while reviewers' negative opinions were about one in seven—though owners are naturally more inclined to post when something goes wrong.

A story from a Kia Telluride owner on HN is representative: he bought based on glowing reviews, but the model was too new to have years of data behind it. By 70,000 miles, expensive components like the alternator began failing right on schedule. Repair was a second problem; even a minor accident brought bills of $10,000 to $20,000. Insurance paid, but the car sat in the shop for a long time. Respondents attributed part of this to modern cars' dense sensors and crumple zones, as well as parts and paint labor costs. Some recommended Toyota as a safe choice, only to be rebutted by another reader with a relative's RAV4 Prime—after its dashboard screen went black, that car was out of commission for over four months.

Survivorship Bias and Time-Window Bias

The gap BetaScore observed is partly the result of two statistical biases stacking. One is time-window bias: reviews cluster in the weeks after a product launch, while failure rates typically follow a bathtub curve—early failures are low, and wear-out failures take months or even years to appear—so review samples naturally lack long-term data. The other is a reverse form of survivorship bias: owners tend to post when something goes wrong, while satisfied users stay silent, inflating the negative proportion in owner opinions.

These two biases point in opposite directions, meaning the conclusion that "owners mention reliability twice as often as reviewers" cannot simply be read as "products are less reliable than reviews suggest." A safer interpretation is that reviews are good at capturing out-of-box experience and design strengths and weaknesses, while long-term reliability can only come from data sources with sufficient usage duration—which is why long-term tracking data such as Consumer Reports and vehicle-age statistics remain irreplaceable in durable consumer goods.

A Few Signals Worth Remembering

These five trending HN posts seem scattered but share a theme: when systems become complex, understanding their history, training process, and real-world usage feedback matters more than looking at surface results. Reasoning models need verifiable reward signals, legal texts need dated version histories, AI products need transparent data boundaries, and product reliability takes time to emerge. For developers and users alike, these are the prerequisites for making better judgments.

One-line Summary

Five trending HN posts reveal that the history, training, and real feedback of complex systems matter more than surface results

Paragraph Summary

The article reviews five popular discussions on Hacker News. Sebastian Raschka released an 11-hour course demonstrating how to train a reasoning model using a small model plus an automatically checkable grader, with discussion centering on the compute threshold for individual practice. Legal tech company LexFina replayed every amendment to the U.S. Code since 2017 to create a Git-like version history system, with 361 of 365 changes matching official editions, addressing the problem of AI legal research applying outdated rules. Anthropic's privacy page shows that a single thumbs-up or thumbs-down in commercial products stores the entire conversation for up to five years and may be used for training, sparking debate over data boundaries. A BetaScore study found that car owners mention reliability about twice as often as YouTube reviewers, because review time windows are too short.