DEV Community: Nandan

When AI Predicts Too Well: Understanding Hallucinations in Large Language Models

Nandan — Sun, 26 Oct 2025 13:53:10 +0000

Generative AI as we know now can write, explain, summarize, and even debug like an experienced engineer. But sometimes, it produces something that sounds perfect and still turns out false. That moment, when language outpaces truth, is what developers call a hallucination.

It is not lying. It is not guessing in the human sense. It is the result of a model doing what it was built to do, continue patterns, one token at a time, until a complete sentence appears.The difference between fact and fiction is invisible to it. The model knows form, not meaning.

The confident AI moment

It sounded sure of itself. It wasn’t.

Imagine asking a code assistant to create a secure SQL connection helper. It returns a snippet that looks professional, reads cleanly, and compiles with no warnings. You test it and realize the class it used doesn’t exist anywhere.

public SqlConnection ConnectSecure(string connectionString)
   {
      // here the Secure Connect is hallucinated class

      var secure = new SecureConnect();
      return secure.Connect(connectionString);
   }

Why does this happen?

The model doesn’t retrieve real code. It predicts what should appear next in a pattern of text. It saw the words “secure,” “connect,” and “SQL” used together during training so it built the most probable continuation. That’s probability, not knowledge.

For a developer, this feels like talking to a confident intern who always sounds sure but sometimes makes things up with a straight face. The presentation is smoothb but the output isn’t grounded.

When thoughts start to drift

Each word makes sense. Together, they start to wander.

Inside the model, everything happens as a flow of numbers embeddings and attention weights. Each token (a piece of text) affects what comes next. With each new token, the model’s focus shifts slightly. When these shifts stack up, the text can drift from the question’s anchor.

This is how a small mismatch becomes a full hallucination:

A minor assumption gets carried forward.
The next token fits the local context but moves further from truth.
The pattern continues until a full paragraph emerges fluent, confident, and wrong.

In simple terms, the language remains correct while the meaning slips away.

It’s like reading a story that starts about machine learning and somehow ends in a conversation about coffee 😂 😂.

Every step is logical, yet the final scene no longer connects to the start.

The human parallel

We do this too. Writers fill memory gaps with what “sounds right.” Developers name a function before writing its logic because they already feel what belongs there. Humans improvise meaning from structure. A language model just does the same thing at scale, faster and without awareness of what it’s doing.

This is why hallucination is not a random glitch, it is a natural side effect of fluency. The better the model gets at generating language, the better it becomes at generating convincing illusions of correctness.

When data and design feed the loop

The source of a hallucination isn’t just the model. It can start in how data was prepared, how feedback was scored, or even how prompts are written.

Compression - billions of facts are compressed into a limited space of parameters. Fine details vanish.
Ambiguity - when a question allows multiple valid answers, the model fills the gap with one it finds stylistically strongest.
Reward models - reinforcement from human feedback often rewards confidence and politeness more than factuality.
Context overflow - if a prompt or document is longer than the model’s context window, older parts fade from memory, causing mixups.

These small design and data effects combine into what we perceive as a single event: a hallucination.

Bringing the model back to earth

Even machines can learn to check their work.

The best current fix is retrieval grounded generation (RAG).

Before answering, the model queries a database or document store to gather real context. Then it writes, using that information as a local truth source. It still predicts words, but now the prediction passes through factual gravity.

A grounded setup works like this:

You ask a question.
A retriever searches indexed knowledge sources for relevant chunks.
Those chunks are added to the model’s prompt.
The model generates text that stays tethered to those chunks.

This simple architectural change drastically reduces fabricated details. It does not make models infallible, but it shifts them from pure imagination toward informed storytelling.

The hidden discipline for developers

Hallucinations don’t make these models useless, they make them unpredictable. For engineers, that means two disciplines matter more than ever:

Prompt design - precise prompts create smaller spaces for the model to drift.
Verification - outputs should be checked against something objective: logs, APIs, documents, or test data.

Treat the model as a collaborator that needs supervision, The same way a senior reviews a junior’s pull request, review what the model writes. The goal is not to silence creativity, it is to build a system that can create and verify.

A closing reflection

Hallucinations remind us that language models do not understand the world, they approximate it. They weave probability into sentences, and probability sometimes bends truth. Our task is to pair their creativity with our judgment.

AI does not need to be perfect to be useful. It needs to be transparent enough that humans can see where it may fail. The next generation of developers won’t just build models. They’ll build guardrails, grounding layers, feedback loops, and retrieval systems that turn fluency into trust.

And maybe one day, hallucination will become what debugging used to be: a normal, necessary step in making something smarter than it was yesterday.

React’s Leaner Twin? A Deep Dive into Preact

Nandan — Sat, 04 Oct 2025 09:37:46 +0000

I like tools that stay close to the browser. Preact does that and still feels familiar if you come from React. This doc is about how I set it up, how it keeps code light, where it fits next to React, and a small contribution I made that later led to a fix upstream The goal here is to help you understand Preact and Roll out and not to document a manual.

A quick picture of Preact and React together

Fig:1 React and Preact share the same model, but Preact trims the overhead

A short idea of Preact

Preact is a compact runtime for JSX and components. It uses the native event system that the browser provides. That choice keeps overhead down and makes interop with plain DOM code simple. The core is small, and extra parts live in packages you add only when you need them. For example, the compat layer lets most React libraries run without pulling React itself. See the guide on event semantics and compat notes for details.

Clear view next to React

You can move between the two without changing how you think about components. Here are the points that tend to matter when you are shipping.

Events. In Preact, onInput fires on every keystroke and onChange fires when the value is committed. In React, the onChange prop behaves like onInput. When porting code, map this one carefully.
Bundle shape. Preact keeps the base small and places extras behind imports, so you do not pay for features you are not using. The compat alias can be enabled only for the packages that need it.
Server render. You can render to HTML and then attach on the client with preact-render-to-string. It works in Node and also in the browser if you really need it for tests.

How it stays lightweight

Two design choices keep Preact small and fast.

First, its core doesn’t try to recreate browser behavior. It uses the browser’s native event system instead of adding a synthetic layer, which means less code to ship and fewer surprises when mixing with plain DOM APIs.

Second, anything extra like compatibility layers, debug tools, or dev only helpers lives in separate packages. You bring them in only when you need them.

and similarly If you enable compat for one React-only library, check its cost in your own build and keep everything else on core Preact. The Vite preset makes toggling this easy.

Build setup that does not grow out of control

// vite.config.ts
// I keep compat off unless a dependency truly needs React types or internals.
// Dev tools stay on only in development. This keeps the production bundle lean.

import preact from '@preact/preset-vite';

export default {
  plugins: [preact({
    reactAliasesEnabled: false,
    devToolsEnabled: true
  })]
};

If you want static pages with client features, the preset can prerender routes at build time. For server HTML, use preact-render-to-string and then attach on the client.

// server.ts
// This renders a full HTML string. Keeping this step simple so it's easy to follow and debug later.

import { renderToString } from 'preact-render-to-string';
import { App } from './App';

export function render(url: string) {
  const html = renderToString(<App url={url} />);
  return `<!doctype html><html><body>
    <div id="app">${html}</div>
    <script type="module" src="/client.tsx"></script>
  </body></html>`;
}

// client.tsx
// We attach interactivity to the server HTML. The root stays stable.

import { hydrate } from 'preact';
import { App } from './App';

hydrate(<App />, document.getElementById('app')!);

Forms that match the platform

In Preact, form events behave just like they do in plain HTML. If you want your code to respond every time the user types, use onInput.

If you only care when the user finishes typing or leaves the field, use onChange. Stick to these browser rules and your forms will stay consistent without extra fixes.

// This input updates a signal on each keystroke.

import { signal } from '@preact/signals';

const name = signal('');
export function NameField() {
  return (
    <input
      value={name.value}
      onInput={e => { name.value = e.currentTarget.value; }}
    />
  );
}

Precise state with signals

Fig:2 The signal feeds a computed value, an effect, and a view. Only readers update.

Signals automatically keep track of which components use a specific value and update only those parts when it changes. That means you don’t need extra wrappers like useMemo or useCallback to control rerenders.

Here’s a simple pattern that I’ve found clear and efficient in real projects.

// Signals for shared state, computed for derived values, effect for side work.

import { signal, computed, effect } from '@preact/signals';

const items = signal<{ id: string; price: number }[]>([]);
const total = computed(() => items.value.reduce((s, i) => s + i.price, 0));

effect(() => {
  window.dispatchEvent(new CustomEvent('cart_total', { detail: total.value }));
});

export function Cart() {
  return (
    <section>
      <ul>
        {items.value.map(i => <li key={i.id}>{i.price}</li>)}
      </ul>
      <strong>Total: {total}</strong>
    </section>
  );
}

The signal feeds a computed value, an effect, and a view. Only readers update.

Server HTML with suspense and islands

Fig:3 Islands hydrating after fallback resolves, without layout shifts.

If parts of the page wait on data, you can show a fallback and attach when the island resolves. The current work in Preact makes this smoother and removes some old layout constraints, which helps when you stream or mix static and live parts.

// This island may load later. The layout stays natural.
// A wrapper is not required when it becomes many nodes.

import { lazy, Suspense } from 'preact/compat';

const Profile = lazy(() => import('./Profile'));
export function Page() {
  return (
    <main>
      <h1>Team</h1>
      <Suspense fallback={<div>Loading profile…</div>}>
        <Profile />
      </Suspense>
    </main>
  );
}

Static HTML lands first, the fallback appears, the island resolves, then listeners attach.

Learning through contribution

While exploring Preact’s context and memo behavior during performance tests, I noticed a subtle memory pattern that kept detached nodes around longer than expected.

Fig:4 Memory retention issue and how the fix resolved detached nodes.

I raised it upstream, and the Preact maintainers quickly improved the commit path logic in v11. After the patch, heap snapshots stabilized exactly as they should.

That kind of responsiveness is one reason I like working with Preact, the core stays small, but the community moves fast.

Why Preact earns its place

Same mental model as React, with less code shipped.
Real DOM events, no synthetic layer.
Fast hydration and smaller bundles.
Straightforward state through Signals.
Great compatibility when you need React libraries — and you can turn it off when you don’t.

If you’ve been building React apps and want the same comfort with better performance, Preact deserves a look.