Podcast Summary: Digital Disruption with Geoff Nielson
Episode: LLMs in 2026: What’s Real, What’s Hype, and What’s Coming Next
Date: February 23, 2026
Guest: Sebastian Raschka – LLM Research Engineer, Author
Host/Interviewer: Geoff Nielson, Info-Tech Research Group

Episode Overview

This in-depth conversation explores the rapidly evolving landscape of large language models (LLMs) as we enter 2026. Host Geoff Nielson speaks with acclaimed LLM researcher and educator Sebastian Raschka to demystify current capabilities, ongoing industry trends, and common misconceptions, separating practical progress from pervasive AI hype. The discussion gives both a technical and practical perspective, yielding insights for technology leaders, developers, and anyone seeking to leverage (or understand) the next wave of AI disruption.

Key Discussion Points & Insights

1. The State of LLMs in 2026

(Timestamps: 01:23–05:57)

• 2025 as a Pivotal Year:
  The field saw breakthroughs such as "deep seq" and the new paradigm of "reinforcement learning with verifiable rewards," focused on improving LLM reasoning—"sometimes called thinking models."
  • “Reasoning is also in quotation marks... it's a set of techniques that make LLMs better at solving complex tasks. It shouldn't be taken too literally, like how humans reason.” (Sebastian, 01:53)
• Innovation Trajectories:
  • Ongoing improvements are twofold:
    1. Refined training techniques for reasoning abilities (e.g., reinforcement learning).
    2. Smarter, more cost-effective inference scaling—using resources during model usage, not just training.
• No Huge Leaps Expected:
  • Anticipate continued iteration and enhancement rather than a “trillion-dollar idea” of radically new architecture in the near term.

2. What LLMs Are (and Aren’t) Good For

(05:57–12:23)

• Misconceptions about 'Reasoning':
  • LLMs can make “stupid mistakes” (like failing the “strawberry problem” of counting letters in a word) due to tokenization and inherent model limitations.
  • "Overthinking" can lead LLMs to miss simple answers—"something humans also suffer from." (07:37)
• Tool Use and Specialization:
  • Modern LLMs excel when allowed to use external tools (e.g., Python code for string manipulation).
  • Optimal usage often involves leveraging prompt engineering and tool API calls rather than expecting LLMs to natively solve every task.
• Best Use Cases (as of 2026):
  • Coding remains the flagship application, with LLMs driving substantial efficiency for developers.

3. How LLMs Transform Developer Workflows

(13:28–18:02)

• Augmenting vs. Replacing Developers:
  • LLMs are excellent for coding assistance, refactoring, and automating repetitive or unfamiliar tasks (e.g., building a macOS app to automate image processing).
  • “For things I care about... I usually write most of the code myself just to think through the problem... I use an LLM to get a second opinion, kind of like a proofreader or sanity check.” (Sebastian, 13:54)
• Limits to Automation:
  • LLMs increase productivity ("apps that took years now take days"), but do not eliminate the need for human iteration, testing, or domain knowledge.
  • Alarmist takes that software development will become obsolete are misplaced: “It’s still work. Maybe one day… but usually the first version is not the final version. There are iterations, you have to test and tweak—and that’s still work.” (Sebastian, 18:02)

4. Generalist vs. Specialist Models: When to Customize or Build from Scratch

(21:43–29:12)

• Specialization Tradeoffs:
  • Fine-tuning transforms a generalist LLM into a domain expert, but may erode other competences (e.g., a better coding model, but worse at math or languages).
• Three Customization Levels: (24:18)
  1. Full Pretraining from Scratch: Expensive; only feasible for large, resource-rich organizations (e.g., Bloomberg for financial news).
  2. Fine-Tuning on Top of Existing Models: More practical, but still expensive and rapidly subject to obsolescence as new base models supplant old ones.
  3. Prompt-Based Customization: Accessible, but limited; suffices for many lightweight or non-sensitive tasks.
• Who Should Build from Scratch?
  • Building a complete LLM is reserved for those learning architecture fundamentals, massive commercial/industry players, or those in highly regulated fields needing specialized models.

5. The Value of Learning to Build LLMs (Even If You Never Deploy One)

(29:12–33:59)

• Analogy:
  • “You want to learn how cars work… you wouldn’t build a Ferrari yourself, but you might build a simple car from the 1980s to learn the principles. That helps you understand how a Ferrari is built.” (Sebastian, 29:54)
• Educational Purpose:
  • Building an LLM from scratch is best for education: not for direct competition, but to understand core mechanics, limitations, and foster intuition for using and troubleshooting existing models.

6. Challenges with Proprietary Data and LLM Context

(35:26–43:43)

• Context Size and Data Inclusion:
  • The main limitation is how much data can fit into an LLM’s context window. Advances in 2025 expanded this (e.g., up to 1 million tokens), but challenges remain with “needle in a haystack” retrieval problems.
• Solutions:
  • “RAG” (Retrieval Augmented Generation) techniques and clever chunking/application-layer workarounds (e.g., recursively breaking up tasks) mitigate limitations.
• Privacy Considerations:
  • Uploading proprietary or confidential data to cloud LLMs is risky due to potential leakage and integration into public training sets (notably including some real-world breaches in 2026).
  • Strong case for local/private LLM deployment for sensitive data.

7. Reasoning, Inference Scaling, and Multi-Agent Systems

(43:43–48:58)

• Inference Scaling:
  • Scaling up inference (e.g., trying multiple solutions and selecting the best) yields higher accuracy but at greater computational cost.
• Tool Use/Agentic Operations:
  • “Biggest progress driver” is LLM tool use and “agentic” problem solving—models calling themselves, or other models, or external APIs to break down and solve tasks more effectively.
• Product vs. Local Model Gap:
  • "What differentiates ChatGPT or Gemini isn’t just the LLM but the surrounding application layer—tool use, context/history management, typo correction, etc." (Sebastian, 45:45)

8. Benchmarking, Performance Testing, and Hype

(48:58–57:59)

• Challenges with Benchmarks:
  • Multiple evaluation types—multiple choice (MMLU), leaderboard rankings, verifiable answers (math/code), and LLM “judges”—all have limitations and biases.
  • “At some point, if it’s passing a minimal threshold, I don't think it matters if it's 90 or 95%. You have to use it and see what works for you.” (Sebastian, 49:55)
• Performance is Contextual:
  • Real-world LLM utility depends on prompt clarity, use case, and supporting application layer—benchmarks only tell part of the story.

9. Common Misconceptions About LLMs

(57:59–61:22)

• Biggest Misconception:
  • Underestimating the complexity and scale of LLM development. Training a production-grade model is “not a weekend project” but requires “a whole team, GPU infrastructure experts, huge data, and substantial investment.” (Sebastian, 57:59)
• Academia vs. Industry:
  • Academic labs are largely edged out from frontline LLM research due to resource demands; most innovation now comes from well-funded companies.

10. Practical Advice for Tech Leaders and Learners

(66:03–73:50)

• Hands-On Learning:
  • “Coding an LLM from scratch—even a simple example—demystifies jargon, helps grasp trade-offs, and gives foundational understanding.” (Sebastian, 66:32)
• Building from Fundamentals:
  • Focus on mastering core architectures and evolving from there, rather than getting lost in “fuzzy big picture” explanations that invite hype and misunderstanding.
  • “There’s no substitute for getting your hands a little dirty and seeing how it actually operates in an environment.” (Geoff, 70:10)
• Separating Hype from Reality:
  • Understanding fundamentals enables critical evaluation of news and research, preventing overreaction to short-term trends or “too good to be true” claims about the latest model.

Notable Quotes & Memorable Moments

• On 'Reasoning' in LLMs
  “Reasoning is in quotation marks…it shouldn’t be taken too literally, like how humans reason.” (Sebastian, 01:53)

• On LLM Shortcomings
  “Counting the R in ‘strawberry’... you’re not evaluating it in the real use case you care about.” (Sebastian, 07:37)

• On Coding Automation Limits
  “It’s not making people developing code…obsolete, because it’s still work. You can’t just say, ‘build XYZ’ and it will build a perfect version. Usually, the first version is not the final version. There are iterations, you have to use it, test it, and tweak it…and that is still work.” (Sebastian, 18:02)

• On Model Benchmarking
  “Each of these methods to evaluate LLMs has its shortcomings…in the end, they all look similar. You have to use it and see what works for you.” (Sebastian, 49:55)

• On LLM Development Realities
  “It’s not usually something someone can do by themselves…looking at Llama 2 or 3—thousands of GPUs, constant failures, checkpointing, monitoring. This is not a weekend project…it’s a lot of work, and that’s why now it’s mostly companies with resources doing it.” (Sebastian, 57:59)

Key Takeaways & Action Points

For Technology Leaders

• Encourage hands-on exploration of LLM fundamentals (ex: code walkthroughs from scratch) to build organizational wisdom and demystify jargon.
• Don’t chase the hype—focus on practical, high-value use cases like coding assistance, and consider the real costs of model customization or training.
• Be wary of uploading sensitive data to public LLM APIs; prioritize privacy and consider local deployment for sensitive use cases.
• Use basic, out-of-the-box LLM solutions first; only invest in customizing, fine-tuning, or building if clear competitive/technical needs emerge.

For LLM Enthusiasts and Developers

• Value the educational process of building small models—understanding limitations, architectures, and practicalities will pay dividends, even if not used in production.
• Understand that tool use and application layer engineering (retrieval, chunking, reasoning orchestration) are areas where much recent progress has been made.
• Stay skeptical of headlines—strong AI systems often hide complexity in orchestration and infrastructure, not just model weights.

Timestamps for Important Segments

• 01:23: State of LLMs in 2026 – Reasoning, industry status, and expected developments
• 05:57: What LLMs are actually good at (and where they still fall short)
• 13:28: How LLMs impact coding workflows and developer productivity
• 18:02: Developer productivity, automation, and the myth of obsolescence
• 21:43: Specialized models vs. generalists—when to fine-tune or build from scratch
• 29:12: Who should be building LLMs? Educational perspective and skills development
• 35:26: LLMs, proprietary data, and privacy considerations
• 48:58: Benchmarking and evaluating LLM performance
• 57:59: Common misconceptions and barriers for non-technical audiences
• 66:32: Advice for tech leaders on LLM learning and team development

Conclusion

Sebastian Raschka brings a pragmatic, deeply knowledgeable perspective, urging teams and leaders to get past AI hype and build essential understanding from first principles, while recognizing the real costs, limitations, and best practices for leveraging LLMs in 2026 and beyond. The future is likely to be shaped not by revolutionary new architectures in the short term, but by smarter training, usage, and orchestration—grounded in practical, demystified understanding.