The Trick to Using LLMs to Learn – Grant Sanderson (@3blue1brown )

Dwarkesh Patel · 2026-07-08

This discussion emphasizes the importance of learning from human-authored content, whether through educators, books, or specialized encyclopedias, over crowd-sourced or AI-generated summaries like Wikipedia or current LLMs. The speaker argues that human-crafted explanations provide a crucial 'motivation' and a structured narrative that anticipates and addresses a learner's potential misunderstandings, even if they contain minor inaccuracies that are later corrected. While LLMs and Wikipedia offer broad, accessible information, their correctness-focused, aggregate nature often lacks the pedagogical depth and human perspective found in dedicated expert resources, making them better suited for finding references to authoritative sources rather than serving as primary learning tools.

Experiences with local models for coding

Martin Fowler · 2026-07-08 · 12 min read

TLDR: Small local models (Qwen3.6 35B MoE being the most viable) can handle contained, well-scoped coding tasks on high-end Apple Silicon machines, but reliability drops sharply with task complexity, longer conversations, and the need for self-correction. The biggest practical insight is that task selection is the dominant factor: local models are genuinely useful for narrow, predictable changes, but the evaluation results were highly inconsistent — models that succeeded manually often failed in automated runs, making it hard to trust them for autonomous agentic workflows without significant hand-holding.

DeepSeek's New AI Speed Hack Is Amazing

Two Minute Papers · 2026-07-07

DeepSeek introduces DSpark, a speculative decoding method that significantly accelerates Large Language Models (LLMs) by allowing a smaller, faster draft model to propose multiple tokens in advance for a larger, more accurate target model to verify. DSpark improves upon prior methods by adding a small cache to the draft model, estimating token survival probability to avoid wasted computation, and dynamically adjusting lookahead distance based on content predictability. This results in a 60-85% speedup in per-user generation speeds at matched throughput levels for production models, making previously unusable LLM applications viable.

read more

DeepSeek's new research introduces DSpark, an advanced speculative decoding technique aimed at accelerating Large Language Models (LLMs). The core idea of speculative decoding is to use a smaller, faster LLM (the draft model) to predict several tokens in advance, which are then quickly verified by a larger, more accurate LLM (the target model). This parallelizes some of the computational work, making generation faster.

Traditional speculative decoding faces challenges: the draft model, being smaller, can be prone to errors, and if a predicted token is incorrect, all subsequent predictions based on it must be discarded, leading to wasted computation. DSpark addresses these issues with three key innovations:

1. Tiny Memory/Context for the Draft Model: DSpark enhances the draft model by giving it a minimal amount of memory. This small cache allows the draft model to maintain context from previously drafted tokens, improving its ability to predict subsequent tokens accurately. Unlike larger models, it doesn't need a huge brain, just enough to ensure coherence over a small window of predictions. This helps prevent early divergence in the draft, reducing the likelihood of subsequent tokens being incorrect. This is particularly useful for tasks like code generation or mathematical problems where subsequent tokens are highly dependent on preceding ones.

2. Confidence-Scheduled Pruning: DSpark introduces a confidence head into the draft model. This head is trained to predict the probability of each drafted token surviving verification by the target model. If the confidence in a drafted token falls below a certain verify threshold, DSpark can immediately discard that token and all subsequent drafted tokens without even submitting them to the expensive target model for verification. This prevents the target model from wasting computational resources on low-confidence predictions, significantly reducing verification waste. For example, if the draft model proposes a nonsensical word, DSpark can pre-emptively prune it, saving the target model's time.

3. Dynamic Lookahead Adjustment: DSpark intelligently adjusts the number of tokens the draft model attempts to predict (the lookahead distance) based on the predictability of the content. For highly structured tasks like code generation or mathematical proofs, where the next token is often very predictable, the draft model can confidently propose many tokens. In contrast, for open-ended or creative tasks like generating a funny wedding speech, where many diverse and equally valid continuations exist, the draft model might propose fewer tokens to avoid high-risk, low-confidence predictions. This dynamic adjustment ensures optimal efficiency, leveraging the draft model's strengths where content is predictable and being conservative where it's not.

The empirical results are impressive. DeepSeek reports that DSpark accelerates per-user generation speeds by 60-85% at matched throughput levels, compared to their established production baseline (MTP-1). This is a significant improvement, especially considering it's measured against an already optimized multi-token prediction system. While the reported 661% throughput gain is a corner case achieved when the baseline system is severely bottlenecked (running out of room), the consistent 60-85% speedup across typical scenarios is a game-changer. This means that many slow AI systems, particularly those constrained by sequential token generation, can become much more responsive and usable, potentially even enabling deployment on resource-limited devices like smartphones.

It's important to note that DSpark is not a "magic switch" that can be applied to any closed API. Its implementation requires deep integration into the LLM's architecture, including access to the draft model, the target model's probabilities, and a serving system capable of efficiently managing this speculative process. The gains also depend on the workload: tasks like code and math generation see substantial benefits due to their high predictability, while open-ended chat might see more modest improvements, as there's less certainty in future tokens. Nevertheless, DSpark represents a significant step forward in making LLMs more efficient and broadly applicable, demonstrating the power of intelligently leveraging a smaller model to peek into the future predictions of a larger one.

The Orchestration Tax

Addy Osmani · 2026-05-24 · 8 min read

TLDR: Your cognitive bandwidth is serial — you're the GIL of your agent fleet, and every agent you spawn just deepens the review queue feeding into that single bottleneck. Adding more agents speeds up the part of the workflow that was never the constraint, while the actual limiting factor (your judgment and code review) stays fixed. The fix is to treat your attention as a scarce resource: cap your parallel agents to match your review throughput, not your tool's UI limit.

Don't Outsource the Learning

Addy Osmani · 2026-05-16 · 7 min read

TLDR: AI coding tools are optimized for closing tasks, not building understanding — and research confirms that passively accepting AI-generated code measurably degrades comprehension and debugging ability over time. The fix isn't using AI less, but changing your posture: form a hypothesis before prompting, ask for explanations before code, and treat AI output like a junior engineer's PR rather than ground truth. Shipping velocity and genuine learning are two separate metrics, and only one of them compounds into long-term career value.

Earn *And* Learn

Kent Beck · 2026-02-18 · 4 min read

TLDR: There are two fundamentally different software games: the Finish Line Game (build to a spec, ship, done) and the Compounding Game (each release funds the next, indefinitely). Spec-driven development and AI-assisted coding only work reliably for the former — in the Compounding Game, over-optimizing for features without investing equally in "futures" (structural capacity to keep building) will eventually hit a complexity ceiling and kill the system. The key discipline is deliberately alternating between shipping features and improving the codebase's future potential.

Bring Back Ops Pride

Charity Majors · 2026-01-19 · 14 min read

TLDR: "Ops" isn't toil or a consolation prize for engineers who can't code — it's a distinct, highly demanding discipline concerned with keeping systems resilient and efficient at scale, as opposed to dev's focus on building features. Google's SRE movement accidentally collapsed this into a "coders are good, manual operators are bad" framing, which eroded respect for a function that actually handles the hardest technical problems in any engineering org. Developers owning their code in production is right and good; conflating that with "devs should own everything including ops" misunderstands what ops is.

On Friday Deploys: Sometimes that Puppy Needs Murdering

Charity Majors · 2025-12-24 · 7 min read

TLDR: Deploy freezes are a pragmatic hack for teams that lack the observability to deploy safely — not a virtue to be proud of. If you want holiday stability, freeze merges instead of deploys, so changes don't pile up into a January minefield. And if you normally deploy daily, keep running the deploy pipeline over the break even without new code — because two weeks of inaction is itself a reliability risk.

sqlite-utils 4.0, now with database schema migrations

Simon Willison · 2026-07-07 · 12 min read

TLDR: sqlite-utils 4.0 introduces built-in schema migrations (promoted from the separate `sqlite-migrate` package), letting you define ordered migration functions in Python files that are tracked and applied automatically against SQLite databases. The release also fixes long-standing transaction handling with a nestable `db.atomic()` context manager and adds compound foreign key support — changes significant enough to warrant the first major version bump in five years.

Don't Accomplish Everything

Kent Beck · 2026-02-23 · 4 min read

TLDR: Facebook deliberately set goals that employees were only expected to complete ~50% of — and hitting all of them was a red flag, not a win. This "P50 goals" approach makes sense specifically in exploratory phases, where learning and unexpected discoveries are more valuable than predictable delivery. The broader takeaway: Extract-phase management tools (OKRs, KPIs, tight dependencies) actively harm exploration, and most teams are now in exploration whether they recognize it or not.