A Mental Model of LLMs for Engineers Who Crave Simplicity Instead of Hype

Are you frustrated with the AI hype, and the talk about software engineers becoming “obsolete?” Instead, don't you just want to understand LLMs simply and use it just like any other tool?

I was frustrated too. And I had two choices.

  1. Continue sharing why the art of software engineering is not dead.
  2. Be silent and let the narrative sort itself out. (Like we often do in meeting rooms.)

Instead, I chose a third option. Which is what my book is about. Incidentally, this is the option software engineers naturally elect as the solution to any problem they face. And it is the best solution. (There is indeed some truth to the smartness of programmers.)

How AI Thinks Book Cover

What I liked about this book is that it tries to explain LLMs from first principles, in a simple and structured way, especially around patterns, tokens, context, prediction, and reasoning.

For me, the biggest value is that it gives a cleaner mental model to think about AI more practically, instead of treating it as magic.

AbulAsar Sayyad

The Engineer's Solution

How engineers learn

Engineers have long learned that neither trying to reason relentlessly, nor staying silent, really works out for them.

Instead, they focus on a third option. Which is to understand the technology better and act on that understanding. Then, no one really is able to argue with the results, even if they have misplaced opinions about the process.

In short, engineers build.

It is through that understanding that:

  1. Web apps become CRUD.
  2. Kafka becomes a mere log.
  3. Redis becomes an ephemeral key-value store instead of a “magical cache.”

In that same spirit, LLMs are just next-token prediction tools. With just that one principle, we have a plethora of emergent behaviors like assisting with queries, coding, designing, or even solving arcane problems.

However, to truly understand LLMs, it’s not enough to merely believe that they predict the next token. It’s important to actually know it and the emergent behaviors it leads to. (Just like how calling Python “simple” doesn’t make it simple for someone.)

How AI Thinks is my attempt at communicating that understanding, so that you don’t have to scour the internet or read obscure papers just to get a gist of what’s really happening. It took me several months to track down enough details to be happy with my understanding, but you can do the same in just a few hours with this book.

The purpose of this book isn’t to dive into complex math, or intricate neural network architectures, or whatever. The goal is to stay at a conceptual level while abstracting away all the unnecessary details. That way, we get an intuition for how LLMs work, how they might perform under certain circumstances, and how to design features that effectively use them. But we neither go into math, nor into code, nor into neural network architectures.

Simplicity is a Culmination, Not a Starting Point

And what you'll learn in this book

Sure, just calling an LLM a “next-token prediction” tool appears to solve the problem. Anyone can do that. But that’s mistaking simplicity to be a starting point; it isn’t.

True simplicity is a culmination. Once you cut through the contradictions, fluff, and hype, and really understand why hallucination and creativity are not so different, everything starts to look simple in hindsight. Simplicity is the destination.

Here are a few things you'll understand better as a consequence of reading this book:

Decide when an LLM is the right tool

Not every problem should be solved with AI (contrary to what the world largely believes). You’ll gain the intuition to tell the difference before you build the wrong thing.

Predict how a model is likely to behave in new situations

Instead of trial and error, you’ll understand why certain prompts work, why others fail, and why outputs vary. LLMs don't work just because the user asked nicely.

Understand where hallucinations actually come from

Not just that they happen, but why they happen, and which kinds of problems make them more likely. The source of hallucinations is also the source of creativity, so it's a tough balance.

Make sense of “reasoning” without mysticism

You’ll see how LLMs can appear to reason, what that means mechanically, and where that illusion breaks down. You'll never again be fooled by the loose usage of the word "reasoning."

Design AI features instead of poking at them

You’ll be able to think in terms of inputs, constraints, and tradeoffs. When you see Kafka as a log, you're able to design systems better. You'll get a similar mental model for LLMs.

Explain what’s happening to other engineers

Taking architectural decisions is tough enough. But coming to consensus about LLMs, about which everyone has a different idea entirely, is a real challenge. You'll be able to back your solutions up with explanations that everyone understands.

Table of Contents

What's inside this book

Here’s the table of contents. Note that we stay away from math as much as possible. Even if it’s included, it’s at a very shallow level. The better thing to do is to get the intuition of how it works, rather than trying to do a rigorous mathematical analysis.

CHAPTER 1
Cutting Through the AI Jargon

We keep using words like “intelligence,” “thinking,” or “reasoning” very loosely. Most marketing materials have incorporated these inaccurate buzzwords so that everyone gets confused about what’s really being implied.

CHAPTER 2
A Crash Course on How LLMs Work

The fundamentals of next-token-prediction is distilled in this chapter. We then look at how that principle translates to the tasks of drafting emails, writing code, and the relationship of text and meaning.

CHAPTER 3
The Word is a Lie

LLMs operate on tokens, although we can loosely say that they operate on “words” for simplicity. However, as software engineers, we should always understand the details of any approach, including the kind of edge cases that they tackle. In this chapter, we understand what the LLM actually sees behind each word, and how tokens allow us to have a more concise vocabulary while also allowing us to express novel words effectively, without having to re-train the LLMs all the time.

CHAPTER 4
How LLMs are Trained

Instead of diving into the nitty-gritty of neural network architecture, we take a high-level view of how LLM training is prepared (in contrast to traditional machine learning models). We also look into the basics of instruction-tuning.

You will also learn how to look at text generation with the LLM’s eyes, and how the LLM manages to predict and accurately use words in the right context, even if it can’t grasp their meaning.

Finally, we discuss the two major things the LLM learns during training.

CHAPTER 5
Why LLMs Don’t Give the Same Answer Twice

We look at how the decoding process works, and why adjusting the temperature changes the variability of the output. There is some light math here to drive the point across, because it will come in handy for the next chapter too.

CHAPTER 6
The Two Sides: Creativity & Hallucination

Most discussions about hallucinations never look at the underlying mechanisms that cause them. If we completely eliminate hallucinations, we will be left with a model that's not creative at all. You will learn to understand the tradeoff, and to some extent, control it.

CHAPTER 7
How Reasoning Works in LLMs

We carry the same mental models and abstractions we've been building so far, and then finally apply it to reasoning. You'll understand what "reasoning" really is, and why LLMs need to do it, and why it looks like self-talk.

Book page preview

Who This Book is For

How to best use this book depending on your background

The book might not appeal to everyone. However, if you like first-principles thinking, and prefer simplicity in your design more than arbitrary complexity, you'll probably love it.

What's described below are possibilities for how you might apply the knowledge in this book. These do not represent topics covered in the book, but are just ideas of its application.

CTOs & VPs of Engineering

Senior leaders who are responsible for the technical direction, and don't want to make fundamental mistakes that can stall their AI progress.

  • Cut through AI hype realistically evaluate strategy, so that you build a roadmap that's plausible
  • Understand what LLMs actually optimize for, so that you can build the rest of the systems right
  • Evaluate vendor narratives properly, and ask the right pointed questions, so that you're not buying an LLM wrapper
  • Plan features which will actually give an ROI, rather than just being a fancy demo, so that your product becomes viable

Engineering Managers

Leaders managing teams building with or around LLMs who need accurate intuition to guide decisions and expectations.

  • Set realistic expectations to stakeholders about what's possible. Push back on naive "let's use AI to solve it" when a classical algorithm might work better. Avoid burnout for both you and your team.
  • Make sure that the stakeholders, like product managers, account for all the sub-optimal emergent behaviors, rather than just focusing on the happy path. LLMs don't work like most imagine.
  • Lead your team to build intelligent systems using these models. Help them learn new skills.

Tech Leads & Architects

Senior engineers responsible for designing systems that incorporate LLMs.

  • Understand what models actually operate on (tokens, probabilities, representations). Just like how you view Kafka as a distributed log.
  • Reason about randomness, decoding, and nondeterminism, so that you can build better systems around the LLM
  • Design systems that account for hallucination and uncertainty, so that your design is robust
  • Avoid architectural decisions based on false assumptions about “understanding”. Instead build reliable systems that work.

Startup Founders

Builders using LLMs as core technology who need clarity before scaling ideas, teams, or narratives.

  • Separate real capability from demo magic so that customers don't churn
  • Avoid building products on misunderstood assumptions that result in negative ROI
  • Communicate honestly with investors, customers, and teams so that they know you can take a lead in the AI race
  • Identify where LLMs add leverage, and where they don’t, so that you can get to product-market fit sooner

Data Science & ML Leaders

Managers of ML or data teams who want a deeper explanation of model behavior beyond surface-level explanations.

  • Understand what training actually teaches a model (for people who are obsessed about knowing)
  • Reason about behavior emergence from large-scale data, so that you can predict how LLMs might behave in certain situations
  • Understand and creativity, hallucination, and “reasoning” without mysticism. Guide your team to build workable products rather than one-off demos.
  • Align technical reality with business expectations. Push back on unrealistic expectations.

Product Leaders

Product managers and directors working with AI-powered features.

  • Build intuition for what models can and cannot reliably do. You can be more creative when you understand constraints better.
  • Make better tradeoffs between creativity and correctness, so that you're neither aiming for a perfect infeasible product, nor for a shallow wrapper
  • Avoid roadmap decisions driven by misleading AI language. You don't want to spend a quarter building nothing.
  • Communicate AI capabilities clearly to non-technical stakeholders and customers, so that they see the magic behind your decisions

And Isn't For

This book won't be the right fit if you're looking for quick fixes or surface-level answers. Because this book is about thinking clearly, not shipping faster.

Not for Tutorial Seekers

People looking for step-by-step tutorials or prompt recipes won't find them here. This book teaches the why, not the how.

Not for Hype Chasers

Readers who want hype, futurism, or AGI speculation won't find it here. This book is grounded in reality, not marketing.

Not for Quick Fixes

Teams seeking implementation patterns without understanding fundamentals won't find shortcuts. This book requires thinking.

What Would Happen to Engineers Who Don’t Understand LLMs?

Honestly? I don’t know. But the question you should ask yourself is, how many engineers truly become good at what they do, without ever touching the fundamentals of their craft?

And wouldn’t you want to be someone proud of whatever you create? Instead of clobbering a few packages, snippets, and questionable design into a mess only to produce digital junk food?

I strongly believe that the purpose of new technology is to make new things possible. With AI, a good chunk of things have now become possible for non-technical folks. And those possibilities overlap somewhat with what software engineers used to do. However, new frontiers have also opened for software engineers; things they couldn’t do before but now have become plausible.

Rather than focusing on things we don’t have to do anymore, we should focus on new things that we can. And what made us engineers in the first place was our insatiable curiosity. This book a light nudge in that direction.

Why Was Writing This Book Hard?

Writing this book was hard. One of the primary reasons is that LLMs are prone to regression to the mean. Which means, they opposed almost everything that I wrote in this book. Only when I submitted additional evidence did the LLMs actually “agree” (if they can actually do that) to whatever I had to say.

Incidentally, it’s also the reason why I possibly couldn’t have used an LLM to “generate” this book. It took good-old hard writing. And then editing. And then revising. And then making sure that all the principles covered flow effortlessly across chapters, so that you feel like reading a cohesive book rather than a collection of blog posts. Finally, I illustrated every major concept myself to ensure that they communicated the ideas well, and also designed the book in InDesign for a pleasant reading experience. (I’d be embarrassed to talk about how much time I spent just deciding on the fonts.)

It took me just a week to conceive the book's idea, but 5 months to condense it into a fluff-free form.

Pricing

Choose the right option for you or your team

Individual

Perfect for personal learning

$24.95
  • ~80-page digital copy (PDF eBook)
  • Written, illustrated, and designed by a human (not AI slop)
  • Instant download
  • DRM-free
Get Your Copy
For teams

Team License

For teams and organizations

Volume discount included
Easy distribution to team members
DRM-free PDF format
Get Team License
Raahul Seshadri
About the Author

Raahul Seshadri

I'm current the Director of AI for a leading MarTech SaaS, and primarily focus on setting the AI vision, researching and developing interesting features through a combination of LLMs and computer science, and packaging them into great product experiences. The best part of my job is my team, who surprise me every day by pushing new possibilities.

My background: I've been programming since the age of 11 (almost 25 years). I'm an undergraduate in Electronics & Telecommunications Engineering and hold a Master's in Computer Science from GeorgiaTech, specializing in Machine Learning.

I started my career by freelancing. Then, I decided to join EdCast, which was a ed-tech startup specializing in micro-learning, as a Technical Architect. Within a few years, I became the Chief Architect. At EdCast, I also worked on classical NLP as part of our recommendation systems.

After that, I joined WebEngage as a Director of Engineering and helped design and build really high-scale stuff. Some of the major accomplishments here was getting the organization its first ISO 27001 compliance. And also introducing some of the first AI features. And improving the architecture to solve the skyrocketing cloud costs.

After that, I had a brief stint at a health-tech startup, and post that I came back to WebEngage as the Director of AI. This time, the game was purely focused on AI. I've built sophisticated features and products like Significant Factors (automated hypothesis generation and data science), our core conversational agents (for journeys, segments, content, and image assets), a few data-mining algorithms, and a lot more. My focus is turning my knowledge of computer science into product differentiators.

In writing this book, I combine my AI knowledge with my first-principles thinking approach, putting everything in the context of the business of technology so what I cover is both clear and useful. I've taken all the experience with technology which I've had, as well as the hard lessons learned by putting sophisticated AI systems on production, and tried to distill the basics which would be widely applicable in this book.

As part of my job, I've been generally featured in (and maybe some more):

MMA
CIO Insider
PC Quest
TechSparks
Financial Express
ET Healthworld
Express Computer

Frequently Asked Questions

Common questions about the book, what you'll learn, and who it's for

Who should read this book?
This book is designed for engineers at all levels who are obsessively curious to understand AI. It's valuable for tech leads, architects, startup founders, data science leaders, and product leaders who need clear mental models of AI.
What makes this book different from other AI books?
This book isn't about implementation details, tutorials, or hype. It's about building accurate mental models of how AI actually works. It's written for engineers who need to reason clearly about AI, without vendor narratives, AGI speculation, or cargo-cult explanations.
How deep does the book go into technical details?
The book strikes a balance between simplicity and accuracy. You'll learn what tokens are, how training works, why models hallucinate, and how "reasoning" emerges, without needing to understand the math behind gradient descent. It's technically accurate but accessible to engineers.
What will I be able to do after reading this book?
You'll be able to reason about AI rather than just using it. You'll know when an LLM is the right tool, predict how it will behave, understand where hallucinations come from, make sense of "reasoning", and design AI features instead of poking at them.
Can my whole team read this together?
Absolutely. The book is designed to be accessible to engineers at all levels, from engineers to managers to CTOs. Team licenses are available with tiered pricing. Reading it together can help align your team on mental models and set realistic expectations.
Does the book cover specific tools or platforms?
No, this book is tool-agnostic. It focuses on fundamentals that apply regardless of whether you use GPT, Claude, open-source models, or future AI systems. The principles you learn will remain relevant even as the technology landscape changes.
What formats are included?
The book is available in digital format only. You'll receive the eBook in DRM-free PDF format.