DEV Community: Puneet Khandelwal

Running Local LLMs on Developer Hardware is Mostly a Distraction

Puneet Khandelwal — Tue, 03 Nov 2026 15:29:48 +0000

Running a seven-billion parameter model on unified memory sounds great. You spend an afternoon downloading GGUF files, tuning context windows, and fighting with Ollama. Then your fans spin up like a jet engine and the token generation crawls. The pitch promises privacy, zero latency, and no rate limits. The actual coding session looks a lot different.

Software bottlenecks aren't typing speed or cloud round-trips. Real friction lives in architectural decisions and edge-case debugging. Standard developer hardware struggles with large codebase contexts because heavy quantization strips away crucial nuance. You end up babysitting syntax errors and wasting mental cycles on local infra management.

Take writing database migrations or unit tests. A hosted API returns accurate code in milliseconds. A quantized local model takes five seconds per prompt, drains your battery, and misses your interface definitions anyway. Hardware depreciation and lost engineering hours dwarf any cloud API pennies saved.

Local inference makes sense for specific niches. Defense, healthcare, and finance sectors with strict data egress policies need local weights. Security research requires a local harness too. But for normal feature work, treating your laptop like an enterprise AI server kills your output.

Tinkering with model weights is a fun weekend project. Building software needs tools that shorten feedback loops. Running heavy language models on consumer hardware belongs in the hobby category.

Treat AI as a stateless utility instead of a local pet.

Why Your Houseplants Die (And Which Ones Actually Survive Neglect)

Puneet Khandelwal — Mon, 02 Nov 2026 12:21:24 +0000

If your apartment is a graveyard for ferns, your dedication probably isn't the problem. Your watering schedule is. Most indoor plants die from overwatering instead of neglect. Waterlogged soil suffocates roots long before drought does.

When you're deep in a code sprint or traveling for weeks, high-maintenance foliage won't survive. You need specimens built like tanks. Snake plants and ZZ plants top resilience charts because their thick rhizomes store water. They survive three or four weeks without a single drop and bounce right back when you finally remember them.

Pothos varieties hit a different sweet spot of toughness because they communicate visually. A thirsty pothos leaf droops. A thorough drink revives limp vines within hours. The main threat to these trailing plants is stagnant moisture around the base. Use a loose, well-draining potting mix so excess water escapes immediately and protects roots from fungal rot.

Keeping your desk green shouldn't feel like managing a complex microservice. Swap high-maintenance cultivars for ironclad champions to get the aesthetic benefits of nature without the cognitive load of a strict schedule. If you want to check survival ratings and practical care routines, read the full breakdown on low-maintenance indoor plants that thrive on busy schedules.

Threat Modeling a Citizen Ballot API

Puneet Khandelwal — Sun, 01 Nov 2026 09:22:27 +0000

When a municipal government exposes a ballot tracking API, the threat model changes. You aren't protecting corporate data anymore. You're defending civic trust.

While auditing a regional voting status service last quarter, we found a classic vulnerability dressed up in JSON. The endpoint took raw string parameters for ballot IDs and returned precinct statuses without schema validation or rate limits. An attacker with a cluster of headless scrapers could easily deny service to citizens checking their status on election night.

Engineers default to web application firewalls and API keys. But civic infrastructure needs a different baseline. Public APIs can't use secret credentials because the public is the user base. Anyone needs to query their status. That constraint invalidates authentication as a primary defense against scraping. The burden shifts entirely to behavioral analysis and input sanitization.

Let's look at the SQL injection vector. The backend used dynamic string concatenation to build query filters. A reporting route bypassed the ORM for performance, leaving a wide-open door for tautology payloads. We stripped out the raw query builder and dropped in parameterized statements enforced at the driver level. We also added strict TypeScript interfaces for all incoming query parameters, rejecting any payload with unexpected keys or special characters before it hit the connection pool.

Stopping scrapers required a nuanced approach. We couldn't block automated tools outright. News orgs, researchers, and civic tech groups scrape public data with custom scripts. Instead of blocking non-browser user agents, we built an algorithmic rate limiter using sliding windows tied to subnet blocks and query costs. Requesting a single ballot ID cost almost nothing. Paginating through millions of sequential IDs triggered escalating delays and token bucket exhaustion. We also dropped cryptographic nonces into the frontend payload, forcing automated clients to run a lightweight proof-of-work challenge that made large-scale scraping too expensive to run.

Civic tech gets probed by hostile actors who view election infrastructure as a high-value target. Code meeting the reality of public administration means our responsibility goes past clean architecture and low latency. We have to build systems that stay transparent to legitimate users while resisting bad actors.

Stop Using LLMs Like Search Engines

Puneet Khandelwal — Fri, 30 Oct 2026 18:30:48 +0000

Most devs use modern language models wrong. They open a chat window, paste an error stack trace, and wait for a magic snippet. When it works, they celebrate. When the model hallucinates a nonexistent method on a standard library class, they complain that AI is overhyped.

The core mistake is treating an LLM like a deterministic search engine or a junior dev who actually knows your codebase. It is neither. It's a spatial compressor of human text, mapping tokens across multi-dimensional vector spaces. Feed it vague prompts and you get average code. Want production-grade output? Treat the interaction like an API design problem.

Look at how this plays out in practice. Ask an LLM to write a complex database migration or an asynchronous worker loop from scratch and you invite disaster. The model samples from the most common patterns on the public internet, which usually means deprecated libraries, unhandled race conditions, and zero error boundaries.

Flip the workflow. Use the model as a strict transformation engine. Feed it your exact architectural constraints, your types, and your failure modes as explicit parameters.

Picture needing a robust parser. Instead of asking for a parser, provide the grammar rules and the exact failure states you expect. The mental shift is simple. You aren't asking the model to think. You are asking it to interpolate between boundaries you defined.

# Bad prompt approach:
# "Write me a Python function that parses incoming webhook payloads safely."

# Structural engineering approach:
# Define the strict input schema and error boundaries first.
from pydantic import BaseModel, ValidationError

class WebhookPayload(BaseModel):
 event_id: str
 timestamp: int
 data: dict

def parse_webhook(raw_bytes: bytes) -> WebhookPayload:
 # Force the LLM to work within explicit parsing boundaries
 # rather than inventing arbitrary validation logic.
 pass

Constrain the output space and the hallucination rate drops fast. The model stops guessing your validation preferences because you handed it Pydantic and said, fill in the transformation logic between these exact types.

This points to how engineering teams will structure developer tools next. We are moving past general-purpose chat interfaces. The real speed comes from building domain-specific wrappers that inject your team's internal documentation, SDK versions, and linting rules directly into the context window before the model ever sees the prompt.

If your devs still copy-paste code snippets from a browser-based chat window, you are losing velocity. Treat prompt engineering like systems programming. Build the harness, define the types, and let the inference engine do the heavy lifting only inside safe, walled gardens.

Quiet the pixels: tiling window managers for deep focus

Puneet Khandelwal — Thu, 29 Oct 2026 18:25:33 +0000

That notification badge sitting in your corner is an open loop draining your working memory.

For years, I treated my workstation like a command center. Slack lived in the bottom right, half a dozen browser tabs crowded the left, and my terminal sat in the middle. I felt like an air traffic controller. Then I tracked my actual output and realized I spent half my day just re-orienting myself after every visual ping.

Meditation apps didn't fix it. Writing rigid rules for my tiling window manager did. The machine started enforcing boundaries my discipline couldn't.

We optimize query execution times and CI/CD pipelines all day long. Yet we leave our primary interface in a chaotic default state. Every notification pop-up demands a micro-decision from your prefrontal cortex. Multiply that by a hundred daily events, and you've engineered your own burnout.

I finally stripped the noise out of my window manager config. When I hit my focus shortcut, deterministic rules take over. Chat apps get shoved to a secondary workspace without their unread badges. Browser windows ditch their borders and maximize to kill peripheral chrome. Floating windows are banned.

Here is what that looks like in practice using a standard rules block:

windowrulev2 = workspace 2 silent, class:^(Slack|Discord)$
windowrulev2 = tile, class:^(Slack|Discord)$
windowrulev2 = noborder, focus:1

Hit that hotkey and visual clutter vanishes instantly. You get the editor, the terminal, and the bug. My peripheral vision no longer catches rogue animation frames from background browser tabs.

Productivity usually comes down to removing environmental friction rather than adding habits. When your desktop refuses to show you distractions, you stop hunting for them.

Verifying the Vote: Building a Go CLI for Poll Book Integrity

Puneet Khandelwal — Wed, 28 Oct 2026 15:29:53 +0000

Trust in an election depends entirely on verifiable data integrity. Last month, I pulled the state-certified electronic poll book export from our county election board public data releases. It was a massive JSON file paired with a cryptographic signature file claiming the data came straight from the secretary of state without tampering. Instead of trusting a dashboard, I opened my terminal, fired up Go, and wrote a hundred lines of code to check the math myself.

Our default state as engineers is skepticism. We reject production deployments without checksums, so we shouldn't accept civic data systems on blind faith either. The state export used a standard ECDSA signature over a SHA-256 hash of the voter registration ledger. The official public key sat on the state portal, buried under three layers of PDF documentation. The real challenge wasn't complex cryptography. It was building a pipeline that ingested the raw export without mutating whitespace or line endings, which ruins the cryptographic hash instantly.

I built a CLI utility that takes the public key, data file, and signature as arguments. Using standard library packages like crypto/ecdsa and crypto/sha256, the script streams the file contents through a hash reader instead of loading the multi-gigabyte dataset entirely into RAM. Memory efficiency matters when dealing with statewide voter files on modest hardware. Within milliseconds, the terminal printed the boolean result of the verification function. It passed. The real value wasn't the green confirmation text. The value was having an auditable, reproducible artifact anyone in the community can run.

Civic tech discussions stay abstract too often. We talk about transparency like it's a philosophical posture rather than an engineering constraint. When citizens rely on proprietary software interfaces locked behind non-disclosure agreements, accountability breaks. Open source tools change that dynamic. They shift verification from a privilege granted by authorities to a right exercised by the public. If a county publishes election records, those records need developer-friendly verification paths out of the box.

Writing this small CLI tool reminded me why I started writing code. Software is our most powerful tool for enforcing truth in complex systems. When we build transparent verification mechanisms for civic infrastructure, we stop complaining and start engineering resilience.

Why Your Telemetry Code Fails During Live Production Incidents

Puneet Khandelwal — Tue, 27 Oct 2026 15:26:02 +0000

Most telemetry code gets written when you're calm, happy, and have zero idea how your system is actually going to fail. The result is predictable. A production incident hits at three in the morning, and your logs tell you everything you already know while hiding what you actually need. They show that a connection was attempted, but they completely omit the internal queue state that caused the deadlock.

We treat logging like a journaling exercise. We drop info statements into catch blocks just because linter rules demand a paper trail. Then an incident hits, and we waste hours grepping through unstructured text to reconstruct a distributed state machine from scattered print statements.

Defensive telemetry means changing how you think. You aren't writing diary entries for a human reader. You're emitting state vectors that an observability tool can query against reality. When an error happens, the log entry needs the exact conditions that triggered that branch. It needs the invariants that broke.

Look at how most backend services handle errors. A standard block looks like this:

try:
 process_payload(data)
except Exception as e:
 logger.error(f"Failed to process payload: {e}")
 raise

This is useless under load. It grabs the exception message you already get from the stack trace, but it throws away the shape, size, and specific field values of the payload that broke the parser. A defensive version looks like this:

from kluvex.telemetry import capture_context

try:
 process_payload(data)
except ValidationError as e:
 capture_context(
 event="payload_parse_failed",
 payload_keys=list(data.keys()),
 payload_size_bytes=len(str(data)),
 schema_version=e.schema_version,
 validation_errors=e.errors()
 )
 raise

Capturing structural metadata instead of raw error strings gives you a way to query your log aggregator for actual patterns. You can check how many failures came from a specific schema version or whether payload size correlates with timeout rates.

Here is the kicker for modern tooling. As AI agents start handling incident triage, the quality of your telemetry dictates the intelligence of your automated remediation loops. An LLM cannot debug your system if your logs consist of generic error messages and stack traces stripped of local state. If you want automated agents to fix your production issues, your telemetry has to act as a precise, structured API for system failure.

Stop writing logs for yourself. Write them for the automated debugger that will wake you up tomorrow.

I Built a Terminal Tool to Force My Screen Breaks

Puneet Khandelwal — Mon, 26 Oct 2026 12:29:44 +0000

Most wellness software treats you like an adult, which is your first mistake.

If you're anything like me, you've installed a dozen ambient break reminders over the years. They slide into the corner of your monitor with a soft chime, asking if you might fancy a walk. You dismiss them with a reflex twitch of your left thumb. You're in the middle of debugging a race condition. You don't have time for gentle suggestions. You need friction that works.

Engineers spend their lives automating tedious tasks, yet we rarely automate our own self-preservation. When my shoulders started migrating toward my earlobes last month, I stopped trusting my willpower. Willpower is a leaky abstraction. I wrote a CLI tool in Go that monitors active keystroke frequency and locks the terminal session when I cross a safety threshold.

The logic is simple. The tool reads raw device inputs from the OS event queue to count actual keystrokes instead of active window time. Active window time is a liar since you can stare blankly at a compiler error for twenty minutes. Keystrokes tell the truth about physical output. Once my cumulative typing weight crosses a set limit within a rolling window, the script triggers a system lock.

At first, it was infuriating. The screen went black right as I hit the final semicolon of a complex function. I cursed my own code. Within three days, my behavior adapted in ways no passive desktop app could achieve. I started batching my thoughts. I started pausing between methods because the penalty for mindless code churning was an enforced physical reset.

We pour endless hours into optimizing dotfiles, key bindings, and compiler flags. We obsess over the micro-latency of our toolchains while completely ignoring the biological hardware running the whole operation. Treating your physical stamina as something that requires hard limits changes your relationship with the screen. You stop treating fatigue as a badge of honor and start treating it as a system constraint.

You don't need another habit tracker or a softer notification chime. You need a tripwire that respects your biology more than your deadlines do.

What 1 Year of Peel-and-Stick Wallpaper Taught Me About Adhesives

Puneet Khandelwal — Mon, 26 Oct 2026 09:31:50 +0000

If you treat peel-and-stick wallpaper like a regular sticker, your walls will punish you. After twelve months with temporary accent walls in a rental apartment, I learned that self-adhesive vinyl acts like a temperamental polymer sheet under constant thermal stress.

Like many renters, I expected easy installation and clean removal. The daily reality brings seasonal temperature swings, subtle wall textures, and stubborn adhesive residue that threatens your security deposit. When I applied a bold floral print in my living room, the backing felt aggressively sticky. Within three months, the top edge started curling downward.

The culprit wasn't bad glue. It was temperature fluctuation near my baseboard heating vents. As indoor temperatures swung between cool nights and warm heating cycles, the vinyl backing expanded and contracted at a different rate than the drywall underneath. Pressure-sensitive acrylic adhesives rely entirely on stable surface contact. When thermal stress introduces tiny gaps, air pockets form, and the bond fails at the seams.

Surface chemistry matters just as much as temperature. Modern low-VOC wall paints often contain silicone or fluoropolymer additives designed to repel stains. Unfortunately, those same additives repel your wallpaper adhesive. Wiping down your walls with isopropyl alcohol before application is non-negotiable if you want the panels to stay put.

Removal brings its own engineering challenges. Pulling vinyl straight out from the wall instead of peeling it back at a sharp parallel angle will tear the paper layer and leave a gummy matrix of acrylic glue behind. Warming the surface gently with a standard handheld hair dryer softens the polymer chains just enough to release the bond without stripping your landlord's paint.

Treating apartment upgrades like a mini engineering project saves time, money, and deposit deductions. For the full breakdown of what held up, what failed, and how to prep your walls properly, read the complete Is Peel-and-Stick Wallpaper Worth It? A Renter's 1-Year Test.

Verifying Democracy: Building an Immutable Voting Machine Audit Log

Puneet Khandelwal — Sat, 24 Oct 2026 18:32:08 +0000

Trust in an election doesn't come from blind faith in hardware vendors. It comes from verifiable proof that the software running on a voting machine hasn't been altered between the loading dock and the precinct floor. Civic infrastructure needs the exact same cryptographic rigor we apply to financial ledgers and secure package managers.

Elections run on administrative inertia. Jurisdictions update firmware ahead of primaries, load config files, and sign off on deployment hashes via paperwork that ends up in filing cabinets. If a bad actor gets physical access to a tabulator, swapping a binary or tweaking a config file takes seconds if nobody checks the state continuously against a root of trust. We need an immutable audit log that makes any silent modification mathematically impossible to hide.

To fix this, we can build a lightweight Merkle tree for every machine deployment. Each leaf node holds the SHA-256 hash of a specific binary, library, or config file. Parents combine these hashes upward until a single root hash represents the entire software state. When the system pushes updates, it appends the new root hash to a public log backed by cryptographic signatures. Anyone can audit the path.

Here is a minimal Python script that generates a tree and verifies file integrity against a known root.

import hashlib
import json

def hash_file(filepath):
 sha256 = hashlib.sha256()
 with open(filepath, 'rb') as f:
 while chunk := f.read(8192):
 sha256.update(chunk)
 return sha256.hexdigest()

def build_merkle_root(file_paths):
 if not file_paths:
 return hashlib.sha256(b'').hexdigest()

 current_level = [hash_file(fp) for fp in sorted(file_paths)]

 while len(current_level) > 1:
 next_level = []
 for i in range(0, len(current_level), 2):
 left = current_level[i]
 right = current_level[i+1] if i + 1 < len(current_level) else left
 combined = left + right
 parent = hashlib.sha256(combined.encode('utf-8')).hexdigest()
 next_level.append(parent)
 current_level = next_level

 return current_level[0]

critical_binaries = ['/opt/voting/bin/tabulator', '/opt/voting/config/ballot_def.json']
root_hash = build_merkle_root(critical_binaries)
print(f'Computed Precinct Root Hash: {root_hash}')

This code doesn't need cloud infrastructure or proprietary blockchain tokens. It runs on standard hardware using pure math to enforce accountability. Publishing the root hash to an immutable bulletin board before polls open gives independent observers the power to verify integrity without trusting the manufacturer.

Code transparency turns abstract debates about election security into verifiable engineering realities. When citizens can independently confirm that every byte of voting machine firmware matches the certified reference standard, democracy gets an invisible layer of armor.

Why Serverless Cold Starts Still Kill API Latency Budgets

Puneet Khandelwal — Fri, 23 Oct 2026 16:53:04 +0000

Your serverless functions are fast, until they aren't. We built our entire backend on scale-to-zero primitives, believing the marketing about infinite horizontal scaling and zero idle costs. Then we hooked up user-facing latency monitoring, and the truth stared us in the face. A cold start on a modern runtime isn't just a minor blip. It's a multi-second penalty that turns a snappy web application into a sluggish mess.

Here's what actually happens under the hood when a cold start hits. The cloud provider spins up a new execution environment. That means allocating memory, instantiating the runtime, pulling your deployment package from storage, and running initialization code before your handler handles a single byte. If you bundle heavy third-party libraries, ORM configs, and bloated telemetry clients into that bundle, you push init times past the threshold of human patience. A user staring at a loading spinner for three seconds assumes your product is broken.

Let's look at a typical Node or Python setup that quietly destroys latency budgets. Developers love writing initialization logic at the top level of their script.

// This runs on every cold start, blocking the first request
const { Client } = require('heavy-database-driver');
const { initTelemetry } = require('@company/monitoring');

const db = new Client(process.env.DATABASE_URL);
initTelemetry();

exports.handler = async (event) => {
 const data = await db.query('SELECT * FROM users WHERE id =?', [event.id]);
 return { statusCode: 200, body: JSON.stringify(data) };
};

Every module required at the top level, every database connection pool initialized outside the handler function, adds direct overhead to the cold start cycle. When traffic drops to zero overnight, the first user in the morning pays for every single import you decided was convenient to place in the global scope.

Fixes usually involve provisioned concurrency. This means paying to keep instances warm, which defeats the core financial incentive of serverless architecture in the first place. If you pay for warm instances across dozens of microservices, you might as well run a lean Kubernetes cluster or a dedicated VPS and save your cash.

Here's the non-obvious tax of the serverless cold start. It forces teams to write worse software engineering patterns to chase performance. We see developers refactoring clean, modular codebases into monolithic single-file scripts to minimize bundle sizes. We see them ditching strongly typed validation libraries because the package size bloats initialization times. When infrastructure constraints dictate code architecture, you traded developer velocity for operational convenience.

If your API handles user-facing interactions where sub-hundred-millisecond response times matter, evaluate whether serverless is the right primitive. For background jobs, webhook processors, and asynchronous queues, scale-to-zero is unmatched. For the critical path of a web or mobile app, those cold starts will eventually catch up to your metrics.

Fixing Context-Switching Fatigue With OS Accessibility Scripts

Puneet Khandelwal — Thu, 22 Oct 2026 16:10:34 +0000

Every notification badge leaves an open loop in your working memory. Jump from your IDE to a chat client, and your brain doesn't instantly shift gears. It drags a cognitive residue behind, slowing your throughput for the next twenty minutes.

Most productivity tips tell you to just use willpower against the noise. That's a bad engineering fix. Stop fighting your setup and rewrite it.

Custom OS accessibility scripts let you gate your attention programmatically. Turn off the visual screaming on your desktop when it's time to build. On macOS, tap into the Accessibility API using JXA or AppleScript to inspect window trees and mute background apps. On Linux, a quick Python script with Xlib or Wayland handles the same state manipulation.

Run a deep work script and let the system hide peripheral distractions. Unread counts vanish from dock icons. Non-essential windows drop to a single workspace. Your audio switches to focus tracks. You build a firewall for your attention at the OS level.

Treat your operating system like a dynamic state machine that protects your mental energy instead of a static canvas. Build triggers right into your terminal environment rather than trusting a morning routine. Type your work command, and the OS clears the visual clutter automatically.

You feel the difference at the end of the day. You stop wasting cycles on context switches and save your focus for the logic that matters.