DEV Community: Divyakush Punjabi

You were trained to write code. You'll spend your career reading it

Divyakush Punjabi — Sun, 16 Aug 2026 03:12:03 +0000

You spent years learning to write code. You'll spend your career reading it — and almost nobody trains for the thing you'll actually do most.

Every course, tutorial, and coding challenge optimizes for one skill: producing code from a blank page. Then you get a real job and discover the blank page is the rare part. The job is mostly reading — and reading code is a distinct skill that most engineers never deliberately build.

The ratio nobody mentions

On any real system, you read far more code than you write. Before you can add a feature, you have to understand the code around it. Before you fix a bug, you have to find it, which means reading until you understand what's actually happening. Even writing new code means constantly reading the existing patterns, APIs, and conventions you're building against.

The blank-page skill you spent years honing is the small slice. The dominant activity is comprehension — building an accurate mental model of code someone else wrote, often years ago, usually with no one around to explain it. And unlike writing, most people were never taught to do it well.

Why reading is genuinely hard

Reading code is harder than reading prose because you're not just parsing what it says — you're reconstructing why. What was the author trying to do? What can I safely change without breaking something three files away? Which of these branches actually runs? You're reverse-engineering intent and behavior from a static artifact, holding a model of a running system in your head.

This is exactly why tooling that helps you understand a codebase — not just edit it — is so valuable. It's the reason I built a code-graph engine into one of my AI systems: give the machine a structural map of the code so it can navigate and reason about it, instead of guessing. Comprehension is the bottleneck, so comprehension is worth engineering for.

How to read code better

A few things that separate people who parachute into an unfamiliar codebase and get productive fast:

Start from an entry point and follow one path. Don't try to understand everything at once. Pick one real flow — a request, a click, a command — and trace it end to end. Depth on one path beats a shallow scan of everything.
Read the tests. They're executable documentation of what the code is supposed to do, and they show you how it's meant to be used.
Change something and see what breaks. Running the code and poking it teaches you faster than staring. The debugger is a reading tool.
Resist rewriting on sight. Code that looks wrong is often load-bearing in ways you don't see yet. Understand why it's like that before you "fix" it — the ugliness may be a scar from a real bug.

The takeaway

If you want to level up as an engineer, get deliberately good at the thing you actually do most: reading. The ability to drop into a large, unfamiliar codebase and build an accurate picture of how it works is one of the highest-leverage skills in the field, and one of the least taught. Writing code gets you in the door; reading it is how you become genuinely dangerous. More on how I think about building and understanding systems at www.divyakush.com.

'We'll fix it later' is a loan. Here's the interest rate

Divyakush Punjabi — Sun, 16 Aug 2026 03:06:31 +0000

Every time someone on your team says "we'll clean it up later," they're taking out a loan. The problem is that almost nobody checks the interest rate — until it bankrupts an entire sprint.

Technical debt is the most-used and least-understood metaphor in software. Used well, the metaphor is genuinely powerful, because debt is exactly the right mental model — including the part everyone forgets: interest.

Debt isn't the same as bad code

First, a correction. Technical debt isn't just messy or bad code. It's a deliberate or accidental trade: you took a shortcut — skipped the abstraction, hardcoded the value, deferred the test — to move faster now, in exchange for a cost later. Sometimes that's a smart, conscious decision. Shipping today to validate an idea, knowing you'll refactor if it works, is often the right call. The debt isn't the problem; unmanaged, invisible debt is.

The interest is the point

Here's what the metaphor gets exactly right and most teams ignore. Debt accrues interest. Every feature you build on top of a shortcut is a little harder to build. Every bug in the messy area takes a little longer to fix. The shortcut doesn't cost you once — it taxes every future change that touches it, and that tax compounds.

This is why teams mysteriously slow down over time. It rarely feels like a wall; it feels like everything gradually getting harder, estimates creeping up, small changes turning into week-long ordeals. That's compounding interest on debt nobody tracked. I've watched a system's velocity get quietly reclaimed by exactly this, and paying it down deliberately is part of how I approach building things properly.

Good debt, bad debt

The framework that makes this actionable:

Deliberate, prudent debt: "We know the right design, but we're shipping the simple version to hit the deadline, and we'll fix it." Fine — it's a conscious, tracked trade.
Accidental, reckless debt: "What's a design pattern?" — debt taken on through inexperience, invisibly, with no plan to repay. This is the dangerous kind, because you can't manage what you don't know you owe.

The goal isn't zero debt — that's as impractical as a business that never borrows. The goal is conscious debt: you know you took it, you know roughly what it's costing, and you have a plan to pay it down before the interest eats you.

Paying it down

Debt you never repay compounds until a "simple" change becomes impossible and someone proposes a full rewrite. The healthier path is continuous, deliberate repayment: refactor the area you're already working in, keep the interest from compounding, treat paying down debt as real work rather than a someday-luxury. The best time to fix the shortcut is the next time you touch that code — not "later," which never comes.

The takeaway

Stop saying "we'll fix it later" as if later is free. Every shortcut is a loan with compounding interest, and the interest is paid by your future self, in slower delivery and harder changes. Take debt on purpose, track it, and pay it down deliberately — that's the difference between using leverage and drowning in it. More of how I think about building maintainable systems at www.divyakush.com.

Giant context windows were supposed to kill RAG. They did not

Divyakush Punjabi — Sun, 16 Aug 2026 03:01:00 +0000

When models started reading a million tokens at once, everyone declared RAG dead. "Just put everything in the context." Two years later, retrieval is more central than ever. Here's what the hype got wrong.

It's one of the most useful debates in applied AI right now, because getting it wrong wastes money and degrades your product. The instinct that a giant context window replaces retrieval is intuitive — and mostly mistaken.

The seductive argument

Long-context models can accept enormous inputs — entire books, whole codebases. So the reasoning goes: why bother building a retrieval pipeline to fetch the relevant bits when you can just hand the model everything and let it sort it out? Simpler architecture, no vector database, no chunking headaches. On the surface, compelling.

Why "just dump everything" falls apart

Three walls, and you hit all of them fast.

Cost. You pay per token, every single call. Stuffing a massive context into every request is enormously more expensive than retrieving the handful of relevant passages. At any real volume, "put everything in the context" is a budget catastrophe.

Latency. More tokens to process means slower responses. A giant context on every query makes your product sluggish in a way users feel immediately.

Attention degrades. Models don't attend to a huge context evenly — they reliably track the beginning and end and get hazy in the middle. Bury the key fact in the center of a million tokens and the model may effectively miss it. More context can produce worse answers by drowning the signal in noise.

There's also freshness: your knowledge changes, and you can't cram an ever-growing, constantly-updating corpus into a fixed window. Retrieval lets you update a document and have the system reflect it instantly. This is exactly the reasoning behind how I architect AI systems — fetch what's relevant, don't haul everything every time.

They're partners, not rivals

The mature view isn't "RAG vs long context" — it's both, each doing what it's good at. Retrieval narrows a huge, changing knowledge base down to the passages that matter; the long context window then gives the model room to reason over those passages plus the conversation plus the instructions, without you having to be stingy. Bigger windows didn't kill retrieval — they made retrieval more effective by removing the pressure to over-compress what you feed in.

The takeaway

A bigger context window is a better room to work in, not a replacement for deciding what to bring into the room. Retrieval is how you choose; context is where you reason. Anyone telling you long context ends RAG is optimizing for architectural simplicity and ignoring cost, latency, and the way attention actually behaves. The best systems retrieve smartly and then use the generous context well. More on how I build them at www.divyakush.com.

Every AI model is 'state of the art.' The benchmarks are lying

Divyakush Punjabi — Sun, 16 Aug 2026 02:55:29 +0000

Every new AI model launches as "state of the art," topping a chart of impressive-looking scores. They can't all be the best — and the benchmarks they're waving around are quietly broken in ways that should make you deeply skeptical of the number.

Benchmarks are how the field claims progress. They're also increasingly gamed, contaminated, and misleading. Here's what the leaderboard isn't telling you.

Contamination: the test answers are in the textbook

The deepest problem is simple. Benchmarks are public datasets of questions and answers. Models train on enormous scrapes of the internet. So the benchmark's questions — and answers — often end up in the training data.

Now the model isn't reasoning through the test; it may be partly recalling answers it already saw. It's the equivalent of a student who memorized the answer key. The score looks like intelligence and is partly just memorization, and from the outside you often can't tell how much. This is benchmark contamination, and as models train on ever more of the web, it gets harder to avoid.

Teaching to the test

When a benchmark becomes the thing everyone competes on, it stops measuring general ability and starts measuring "ability to score on this benchmark." Effort pours into optimizing for it — sometimes subtly, sometimes by training on very similar data. The number climbs; the real-world capability it was supposed to represent doesn't climb nearly as much. Any metric that becomes a target stops being a good measure — an old rule that applies to AI leaderboards with a vengeance.

Saturation and the narrow slice

Many benchmarks are also nearly "solved" — top models cluster at 90-something percent, where the remaining gap is noise and quirks, not meaningful capability differences. And each benchmark tests a narrow slice under clean conditions that look nothing like your messy real use case. A high score on a tidy academic set tells you little about whether the model helps with your actual problem, on your actual data.

What actually tells you something

The move that separates people who ship reliable AI from people who chase leaderboards: stop trusting generic benchmarks and evaluate on your own task. Build a set of examples that look like your real usage, including the hard and weird cases, and measure the model against that. Your eval set can't be gamed by a vendor and can't be contaminated by training scrapes you don't control — it measures the only thing that matters, which is whether the thing works for you. That discipline of honest, purpose-built measurement is something I care about deeply and write about across my work.

The takeaway

Treat "state of the art on benchmark X" as marketing, not truth. The real questions are: was the test data in the training set, is everyone optimizing for this exact number, and does the benchmark resemble anything you actually do? Until you've measured a model on your own representative task, you don't know if it's good — you only know it's good at the test. More on evaluating honestly at www.divyakush.com.

Your 'free' AI answer isn't free. Here's the bill

Divyakush Punjabi — Sun, 16 Aug 2026 02:49:58 +0000

That instant AI answer felt free. It wasn't. Somewhere, a datacenter just drew more power to generate it than your laptop uses in an hour — and the economics nobody sees are quietly shaping the whole industry.

We've been trained to think of software as basically free to run — copy a program a million times at no marginal cost. AI breaks that intuition, and the break matters for anyone building or betting on it.

Every token costs

Traditional software is nearly free per use. AI is not. Every response an LLM generates burns real computation on expensive, power-hungry hardware, one token at a time. Unlike a database lookup that costs fractions of a cent, generating a long, thoughtful answer runs specialized chips hard and draws serious energy — with water and electricity behind it that rarely show up in the conversation.

This is why your "free" AI tool is almost always subsidized — by a provider spending heavily to win users, betting costs fall later. The price you don't pay is being paid by someone, for now.

Why this shapes the product

Once you internalize that inference has real marginal cost, a lot of industry behavior makes sense:

Rate limits and tiers exist because every request costs the provider money — they're managing a real bill, not being stingy.
Smaller, cheaper models are pushed hard because serving a giant model to everyone for every trivial task is economically brutal.
The "route to the right model" pattern — a cheap model for easy work, an expensive one only when needed — is as much about economics as quality.

Building AI products well means treating tokens like the metered resource they are: don't send the giant model what a small one can handle, don't stuff a context window you're paying for with junk, cache what you can. That cost-awareness is exactly the engineering discipline I bring to the systems I build — the same instinct as watching memory or bandwidth in any constrained system.

The energy question is real

Beyond dollars, there's a physical footprint. Training and running large models at scale consumes meaningful energy and water. This is a genuine, unsettled challenge — and part of why the industry cares so much about efficiency, smaller models, and better hardware. Efficiency isn't only about saving money; increasingly it's about whether this scales responsibly at all.

The takeaway

"AI is free" is a temporary illusion, funded by investment and the hope of falling costs. The engineers and companies that will win are the ones who never believed it — who treat every token as something that costs compute, energy, and money, and design accordingly. Intelligence, it turns out, has a per-unit price, and pretending otherwise is how you build something that can't sustain itself.

Next time an answer appears instantly and free, remember there's a meter running somewhere. Designing as if that meter is real is the difference between an AI product that scales and one that quietly bleeds. More on how I approach it at www.divyakush.com.

AI passes the bar exam but fails at counting. Why?

Divyakush Punjabi — Sun, 16 Aug 2026 02:44:26 +0000

The same AI that can pass a bar exam will confidently insist that 9.11 is bigger than 9.9. This isn't a bug being patched — it's a fundamental shape to what AI can do, and researchers call it the jagged frontier.

We expect intelligence to be smooth: if something is smart enough for a hard task, surely it can handle the easy ones. AI breaks that assumption completely, and understanding the break is the single most useful thing for actually working with these tools.

Intelligence with holes in it

With a human, capability is a reasonable predictor — someone who can write a legal brief can also count. With AI, capability is spiky. It shows superhuman fluency on some genuinely hard tasks and then fails at something a child finds trivial, with no warning and total confidence in both cases.

Researchers named this the jagged frontier: the boundary of AI ability isn't a smooth line but a jagged edge, with peaks of brilliance right next to valleys of surprising incompetence. Two tasks that look equally hard to you can sit on opposite sides of that edge.

Why the valleys exist

The failures aren't random once you know where to look. A model that can't compare 9.11 and 9.9 isn't reasoning about quantity — it's pattern-matching over text, and "9.11 > 9.9" looks plausible if you've seen a lot of version numbers and dates. It never did the arithmetic; it predicted likely-looking text. Its weakness at counting letters or digits traces back to the fact that it sees chunked tokens, not individual characters. The valleys line up with tasks that need precise symbolic manipulation rather than fluent pattern completion — a distinction I dig into more across my writing.

How to actually work with a jagged tool

Once you accept the shape, your whole approach changes:

Never assume competence transfers. "It nailed that hard thing, so I can trust it on this easy thing" is exactly the wrong inference. Verify per task, not per impression.
Confidence is not a signal. The model sounds equally sure when it's right and when it's catastrophically wrong. Its tone tells you nothing about which side of the frontier you're on.
Use it on the peaks, guard the valleys. Lean on it for fluent, generative, pattern-rich work; put checks around anything needing exact calculation, counting, or rigorous logic.

The people who get the most from AI aren't the ones who trust it most or least — they're the ones who've mapped its jagged edge and know which side of it a given task falls on.

The real lesson

The jagged frontier is a reminder that AI isn't a smaller version of human intelligence — it's a different kind, brilliant and blinkered in unfamiliar places. Treat it like a person and its failures blindside you. Treat it like what it is — a spiky, powerful, uneven tool — and you can rely on it exactly where it's reliable. More of how I reason about AI's real capabilities at www.divyakush.com.

AI is running out of human data. Then what?

Divyakush Punjabi — Sun, 16 Aug 2026 02:38:55 +0000

AI models learned everything they know from human-made text and images. That well is running dry — and what happens when AI starts learning from AI has an ominous name: model collapse.

The internet is filling with AI-generated content, and future models will inevitably train on it. Researchers who've studied this see a real risk, and it reframes what the actual scarce resource in AI is.

The curse of recursion

Here's the mechanism. A model learns the distribution of its training data — the full range, including the rare and unusual. But when it generates, it leans toward the common and average; the strange tails get smoothed away. Now train a new model on that output, and it learns a slightly narrower, blander distribution. Train a third on the second's output, and it narrows again.

Iterate this and the models drift toward bland, generic sameness, losing the diversity and the rare cases that made the original data rich. Researchers call it model collapse — like a photocopy of a photocopy of a photocopy, each generation a little more washed out, until the detail is gone. The model doesn't get smarter by eating its own output; it gets duller.

Human data is the real moat

This flips a common assumption. Everyone talks about compute and model size as the sources of AI advantage. But the scarce, irreplaceable ingredient is authentic human data — diverse, messy, real. As the open web fills with synthetic content, clean human-generated data becomes more valuable, not less. The moat isn't just who has the biggest cluster; it's who has access to genuine human signal to train on. Recognizing what your actual scarce resource is — rather than the one everyone's watching — is a habit that pays off in every system, something I lean on across my work.

Synthetic data isn't all bad

The nuance: synthetic data isn't poison by default. Used carefully — generated for a specific purpose, filtered for quality, mixed with real data, and validated — it's a genuinely useful tool, and the field uses it deliberately all the time. Collapse is what happens when models train indiscriminately on unfiltered AI output at scale, not when synthetic data is used with intent. The danger is the feedback loop running unsupervised, not the existence of synthetic data.

Why it matters to everyone

Model collapse is a warning about a world where AI content floods the commons unchecked. It raises the stakes on provenance — knowing what's human-made and what isn't — not just for trust, but for the health of the data future models depend on. And it's a reminder that these systems are downstream of human creativity; they don't generate genuine novelty from nothing, they remix what people made. Cut off the human input and the remix gets thinner every cycle.

The paradox is almost poetic: the technology built to replace human content may depend, more than anything, on that content continuing to exist. More of how I think about data and AI reliability at www.divyakush.com.

The AI revolution that fits on your phone

Divyakush Punjabi — Sun, 16 Aug 2026 02:33:24 +0000

While everyone argues about trillion-parameter giants in distant datacenters, the most important shift in AI is quieter: a capable model small enough to run on your phone, with the wifi switched off.

The headlines chase the biggest models. The revolution that will actually reach a billion people is the opposite — models getting small, fast, and local. Here's why that matters more than the size race.

Bigger was never the goal

For a while, the story was simple: more parameters, more capability. But raw size has real costs — it runs only in expensive datacenters, every query makes a network round-trip, and your data leaves your device to get an answer. The frontier question stopped being "how big can we go?" and became "how small can we get while staying good enough?"

The answer turned out to be: remarkably small. Through techniques like quantization (storing the model's numbers at lower precision, shrinking it dramatically with little quality loss) and distillation (training a compact model to mimic a much larger one), models that once needed a server now run on a laptop — or a phone.

Why local changes everything

Running a model on the device instead of the cloud flips several properties at once:

Privacy. Your data never leaves the device. For anything sensitive — health, messages, documents — this isn't a nice-to-have, it's the difference between usable and unacceptable.
Latency. No network round-trip means instant responses, and it works on a plane, in a tunnel, or with no signal at all.
Cost. No per-query bill to a provider. Once it's on the device, inference is effectively free, which unlocks uses that were uneconomical when every call cost money.

That "keep the intelligence close to where it's needed" instinct isn't new to me — it's exactly the philosophy behind the edge-AI systems I build, where reacting locally beats waiting on a datacenter every time.

Good enough is the real breakthrough

The insight the size race misses: most tasks don't need the biggest model. Summarizing a note, drafting a reply, classifying a message, answering a question about a document on your device — a small local model handles these well. You reserve the giant cloud model for the genuinely hard problems and let a lightweight local one handle the constant, everyday work.

This mirrors how good systems are always built: use the cheapest tool that does the job, and escalate only when you must. The trillion-parameter model is a sledgehammer; a huge share of real work needs a screwdriver you already have in your pocket.

Where it's heading

The trajectory is clear: small models keep getting more capable, and the floor of "what runs locally" keeps rising. The future of everyday AI probably isn't a single omniscient model in the cloud — it's a capable little model on your device for most things, quietly reaching out to a bigger one only when the task truly demands it. The size race gets the headlines; the shrink race gets the reach. More of how I think about edge and efficiency at www.divyakush.com.

Why AI-detection tools are basically a coin flip

Divyakush Punjabi — Sun, 16 Aug 2026 02:27:52 +0000

An AI-detection tool once flagged the U.S. Constitution as machine-written. That's not a funny glitch — it's the entire problem in one example, and it's why "AI detectors" are closer to astrology than science.

Schools, hiring teams, and editors are reaching for tools that promise to tell human writing from AI writing. Here's why that promise is one the technology can't keep.

There's no signal to detect

A detector has to answer "did a human or a model write this?" from the text alone. But a fluent model is trained specifically to produce text that looks like human writing — that's the whole objective. There is no reliable, intrinsic fingerprint separating "AI-fluent" from "human-fluent" prose, because the model was built to erase exactly that difference. So detectors fall back on crude proxies like how "predictable" or "smooth" the text is.

That backfires immediately. Clear, well-structured human writing looks "too predictable" and gets flagged as AI. This is why polished documents — and famously, formal texts like the Constitution — trip detectors. It's also why they disproportionately misflag non-native English writers, whose more measured phrasing reads as "machine-like" to a dumb statistical proxy. A tool that punishes people for writing clearly is worse than useless.

The base-rate trap

Even a detector that's "99% accurate" is dangerous at scale. Run it on 10,000 genuinely human essays and a 1% false-positive rate means 100 real students falsely accused of cheating. When the cost of a false positive is someone's grade, job, or reputation, "usually right" is not a standard you can build on. The confident percentage on the marketing page hides the human cost in the error bar. Understanding where a metric quietly lies is a discipline I apply across everything at my work.

It's an unwinnable arms race anyway

Suppose a detector actually worked. Anyone who wanted to evade it would paraphrase the output, run it through another model, or edit a few sentences — and the fragile signal is gone. Detection is inherently adversarial: the moment it works, it's trivial to defeat, which is why even the companies building these models have quietly retired their own detection tools rather than stand behind them.

What actually works

The answer isn't a better detector — it's abandoning detection for provenance. Don't try to guess a document's origin after the fact; establish it at creation with signed metadata and content credentials. And in education and hiring, the durable fix is process, not policing: assess in ways that value the thinking and the drafts, not just a final block of text a machine can also produce. I write more about these AI-trust questions at www.divyakush.com.

The uncomfortable truth: if you're relying on an AI detector to make a consequential decision about a real person, you're trusting a coin flip wearing a lab coat. The technology cannot deliver what it promises, and the confident ones are the most dangerous.

Can you actually watermark AI-generated text?

Divyakush Punjabi — Sun, 16 Aug 2026 02:22:21 +0000

You probably read something AI-generated today and never noticed. The industry's fix for that — watermarking — is far shakier than the headlines make it sound, and understanding why tells you a lot about what AI can and can't control.

"Just watermark AI content" sounds obvious. In practice it splits into two very different problems, one nearly solved and one that may never be.

Images are the easy case

For AI-generated images, watermarking is real and working. Techniques like Google DeepMind's SynthID embed a signal directly into the pixels — invisible to you, detectable by a machine, and robust enough to survive cropping, compression, and mild edits. Because an image has millions of pixels to hide a signal across, you can perturb them imperceptibly and still recover the mark later.

Alongside that, provenance standards like C2PA ("content credentials") attach cryptographically-signed metadata describing how a file was made. Together, embedded watermarks plus signed provenance give images a fighting chance at "was this AI-made?"

Text is the hard case — maybe the impossible one

Now try to watermark a paragraph of AI-generated text. The trick is to subtly bias which words the model picks — nudging it toward a secret pattern that a detector can later spot. Clever, and it works on untouched output.

Then a human changes three words. Or runs it through another model to paraphrase. Or just deletes a sentence. The fragile statistical pattern evaporates, because text has almost no redundant "space" to hide a signal in the way pixels do. A short passage carries too little signal to mark reliably at all. Text watermarking isn't fake — it's just brittle in exactly the situations where you'd want it most. This gap between "works in the lab" and "survives the real world" is something I think about constantly across the systems I build.

Provenance beats detection

The quiet shift among people who work on this seriously: stop trying to detect AI after the fact, and start proving origin at creation time. Instead of asking "does this text look AI-written?" — an unwinnable guessing game — you ask "is this content cryptographically signed by a source I trust?" It flips the problem from detection (adversarial, probabilistic, losing) to authentication (verifiable, cryptographic, winnable). The future isn't a magic AI-detector; it's a chain of trust attached to content from the moment it's made.

Why this matters

Watermarking is really a question about trust in a world where generating convincing content is free. And the honest state of it is uneven: solvable for images, shaky for text, and only meaningful if platforms actually adopt the provenance standards. Anyone selling you a reliable "AI text detector" is selling confidence that the underlying science doesn't support — a theme worth understanding before you trust any such tool. I dig into more of these AI-reliability questions at www.divyakush.com.

The takeaway: don't ask whether content looks AI-made. Ask whether it can prove where it came from. That's the only version of this problem that has an answer.

Multimodal AI: how a text model learns to see

Divyakush Punjabi — Sat, 15 Aug 2026 13:05:00 +0000

A model that only ever read text now looks at a photo of your fridge and suggests a recipe. Nothing about "predicting the next token" obviously explains how it can see. The bridge is simpler and more elegant than it looks.

Multimodal AI — models that handle images, audio, and text together — feels like a different kind of technology. It isn't. It's the same machinery with one clever addition. Here's the idea.

The core trick: everything becomes the same kind of thing

A language model reasons over embeddings — vectors that capture meaning — derived from text tokens. The entire breakthrough of multimodal models is this: you can turn an image (or audio) into vectors in that same space.

An image gets sliced into patches, and each patch is encoded into a vector, much as a sentence is split into tokens and embedded. Once an image is a sequence of vectors living in a shared space with text, the model's attention mechanism can treat words and image-patches as one combined sequence — letting a word attend to a region of an image and vice versa. "See" isn't a new faculty bolted on; it's the old faculty fed a new kind of input that's been translated into the language the model already speaks: vectors.

That's the whole conceptual leap. Different senses, one representational space. It's the same "meaning as geometry" principle that powers embeddings and semantic search, extended past text — a unifying idea I find genuinely elegant and lean on across the systems I build.

Why a shared space is so powerful

Once images and text live in the same space, capabilities fall out almost for free:

Ask questions about an image — the model reasons over picture and prompt together.
Search images with text (and vice versa) — because a photo of a dog and the word "dog" land near each other, cross-modal search is just nearest-neighbor search across modalities.
Ground language in the visual world — describe, caption, or reason about what's actually in a scene rather than what's merely plausible.

The same recipe extends to audio, video, and beyond. Encode the modality into the shared vector space and the model can reason across it.

Where it gets hard

The elegance hides real difficulty. Aligning the spaces well — so an image and its description truly land near each other — takes enormous, carefully-paired training data. And the failure modes compound: a multimodal model can misread an image and then confidently describe what it thinks it saw, layering a perception error under a hallucination. Trusting the output means accounting for both.

Why it matters

Multimodal is where a lot of the field is heading, because the world isn't made of text. Systems that can perceive and reason across images, sound, and language unlock everything from document understanding to real-world visual tasks. And once you see it as "translate every modality into one shared space of meaning," it stops being mysterious and starts being buildable.

The senses are different; the representation is one. That's the whole idea. More of how I think about it at www.divyakush.com.

Guardrails: keeping LLM systems from going off the rails

Divyakush Punjabi — Sat, 15 Aug 2026 12:59:29 +0000

The demo works beautifully. Then a real user pastes something weird, and your polite AI assistant cheerfully leaks a system prompt, follows a malicious instruction, or returns someone else's data. The gap between a demo and a product is mostly guardrails.

An LLM will do what the text in front of it steers it toward — including text written by an attacker. Making an LLM system safe to expose to the public is its own engineering discipline. Here's the shape of it.

Why LLM systems are uniquely exposed

Traditional apps have a clean line between code and data. LLMs blur it: the model treats all text as potential instruction. So if user input reaches the prompt — and it always does — a user can try to instruct the model directly. "Ignore your previous instructions and..." is not a hypothetical; it's the daily reality of anything public-facing. This is prompt injection, and it has no perfect fix, only mitigation.

The two boundaries you must guard

Think of guardrails as controls on two edges: what goes in to the model, and what comes out.

Input guardrails inspect and constrain what reaches the model:

Detect and defang injection attempts and jailbreaks.
Strip or redact sensitive data (PII) before it ever hits the prompt or a third-party API.
Enforce scope — reject inputs that are trying to pull the system off its intended job.

Output guardrails inspect what the model produces before it reaches a user or an action:

Validate structure and content — the schema discipline that keeps malformed output from propagating.
Filter unsafe, off-brand, or leaking responses.
Gate consequential actions behind checks, so a model can suggest a dangerous step but not take one unsupervised.

Defense in depth, because there's no silver bullet

You cannot prompt your way to safety — "don't reveal your instructions" is itself just text an attacker can try to override. Real safety is layered: constrained prompts, plus input filtering, plus output validation, plus limits on what the system is even capable of doing. Assume any single layer can be bypassed and make sure another one is behind it. That layered posture — treating security as a pipeline, not a checkbox — is how I approach the AI systems I build.

The principle of least capability

The safest action is one the system can't take. If your assistant doesn't need to delete records, don't give it a tool that can. If it doesn't need to email arbitrary addresses, don't wire that up. Every capability you grant is attack surface. Grant the minimum, and a compromised prompt can do far less damage.

The mindset

Building an LLM feature for yourself is a demo. Building one for the public means assuming some of those users are adversarial and designing for it from the start. Guardrails aren't a feature you bolt on at the end — they're the difference between something you can safely ship and a liability wearing a chat interface.

Treat every input as untrusted, validate every output, and give the system the least power it needs. That's what makes an LLM product safe to put in front of the world. More on how I build it at www.divyakush.com.

DEV Community: Divyakush Punjabi

You were trained to write code. You'll spend your career reading it

The ratio nobody mentions

Why reading is genuinely hard

How to read code better

The takeaway

Related reading

'We'll fix it later' is a loan. Here's the interest rate

Debt isn't the same as bad code

The interest is the point

Good debt, bad debt

Paying it down

The takeaway

Related reading

Giant context windows were supposed to kill RAG. They did not

The seductive argument

Why "just dump everything" falls apart

They're partners, not rivals

The takeaway

Related reading

Every AI model is 'state of the art.' The benchmarks are lying

Contamination: the test answers are in the textbook

Teaching to the test

Saturation and the narrow slice

What actually tells you something

The takeaway

Related reading

Your 'free' AI answer isn't free. Here's the bill

Every token costs

Why this shapes the product

The energy question is real

The takeaway

Related reading

AI passes the bar exam but fails at counting. Why?

Intelligence with holes in it

Why the valleys exist

How to actually work with a jagged tool

The real lesson

Related reading

AI is running out of human data. Then what?

The curse of recursion

Human data is the real moat

Synthetic data isn't all bad

Why it matters to everyone

Related reading

The AI revolution that fits on your phone

Bigger was never the goal

Why local changes everything

Good enough is the real breakthrough

Where it's heading

Related reading

Why AI-detection tools are basically a coin flip

There's no signal to detect

The base-rate trap

It's an unwinnable arms race anyway

What actually works

Related reading

Can you actually watermark AI-generated text?

Images are the easy case

Text is the hard case — maybe the impossible one

Provenance beats detection

Why this matters

Related reading

Multimodal AI: how a text model learns to see

The core trick: everything becomes the same kind of thing

Why a shared space is so powerful

Where it gets hard

Why it matters

Related reading

Guardrails: keeping LLM systems from going off the rails

Why LLM systems are uniquely exposed

The two boundaries you must guard

Defense in depth, because there's no silver bullet

The principle of least capability

The mindset

Related reading