Intro

If you have tried to build a project recently, the sheer volume of choices in the modern web stack can look overwhelming. But let’s be honest: in the age of AI, that is no longer a blocker. You do not need to spend a weekend researching bundlers or frameworks. You can write a single prompt and have an AI spin up a fully functioning stack in a minute or two.

So if we can outsource the setup to AI in seconds, why write a guide explaining the layers?

Because if you are someone who wants to understand a little more deeply why those choices were made, “it just works” is not enough. You want to know what happens when you pick a meta-framework, and what trade-offs you are implicitly accepting. This article is not a time-saving research shortcut; the AI has already solved that. This article is for satisfying the developer curiosity to understand the map.

A web stack is not a pile of competing tools. It is a stack in the literal sense: seven layers, each one sitting on the one below it, each one answering a different question. Once you draw the map, every tool snaps into exactly one place, and the decision at each layer becomes clear.

This article is that map. I will walk through all seven layers from the bottom up, compare the real options at each one, and tell you what I picked for my own project and why. By the end you will be able to look at any new tool that launches next week and know immediately which layer it lives in and what it is actually competing with.

Here is the whole thing at a glance:

┌───────────────────────────────────┐
│  Layer 7: Animation & Motion      │  ← interaction polish
│  Layer 6: Styling                 │  ← how components look
│  Layer 5: UI Framework            │  ← how you write components
│  Layer 4: Meta-Framework          │  ← routing, SSR/SSG, data loading
│  Layer 3: Build Tools & Bundlers  │  ← transforms source → browser-ready code
│  Layer 2: Server Framework        │  ← handles HTTP, APIs, business logic
│  Layer 1: Runtime                 │  ← the engine everything runs on
└───────────────────────────────────┘

Not every project needs every layer. A static site might skip Layer 2 entirely. A backend API skips Layers 5 through 7. But understanding the full stack shows you what you are choosing, and more importantly, what you are implicitly accepting when a framework chooses for you.

Let’s start at the bottom.

Layer 1: The engine nobody thinks about

The runtime is the engine that executes JavaScript and TypeScript on the server. It runs your build tools, powers your dev server, and serves your app in production. Everything else in this article sits on top of it.

For fifteen years this was not a decision at all. The runtime was Node.js, period. Now there are three serious options.

Node.js is the default for a reason. Every library assumes it, every hosting platform supports it, and it is battle-tested in production everywhere. It is also the slowest of the three and still needs a transpilation step for TypeScript.

Bun is the young challenger, written in Zig on top of JavaScriptCore instead of V8. Its pitch is raw speed: startup is 3 to 5 times faster, and package installs are dramatically quicker. For most projects it works as a drop-in Node replacement, though complex native modules can still hit compatibility gaps. If you maintain a large monorepo or care about CI pipeline speed, Bun is worth a serious look.

Deno comes from Node’s original creator and fixes Node’s design regrets: security-first with a permissions model, native TypeScript, web-standard APIs. It is stable and pleasant, but adoption stayed smaller, and it makes the most sense if you are deploying on Deno Deploy.

What I picked: Node.js. Boring answer, deliberate choice. Maximum compatibility with the rest of my stack and with Netlify. Bun would have worked as a drop-in for faster installs, and nothing in the layers above would change if I swapped it in later. That is the nice thing about the bottom layer: it is the easiest one to revisit.

Layer 2: Do you even need a backend framework?

One layer up sits the server framework: the thing that handles HTTP requests, API routes, middleware, and business logic. Express is the name everyone knows, but the field has changed more in the last four years than in the previous ten.

Here is the field today:

The pattern becomes obvious when you sort by generation:

  Generation 1 (2010-2015):  Express, Koa, Hapi
                           Callback/middleware patterns, Node.js only
Generation 2 (2016-2021):  Fastify, NestJS
                           Speed + structure, still Node.js
Generation 3 (2022-now):   Hono, Elysia
                           Multi-runtime, edge-native, TypeScript-first

Express is the jQuery of backend JavaScript. It is everywhere, everyone understands it, and it is showing its age. Callback-based middleware, no built-in TypeScript, no schema validation. New projects pick it because everyone knows it, not because it is the best tool. Fastify is what Express should have become: schema-based validation, a real plugin architecture, two to three times the throughput, and Express-compatible enough to migrate to.

Hono is the one I find most interesting. It is about 14KB, TypeScript-first, and runs on literally any runtime: Node, Bun, Deno, Cloudflare Workers, Lambda. If you are building for the edge or want to keep your deployment options open, Hono is the modern answer. Elysia plays the same game but goes all-in on Bun, squeezing out the highest throughput of anything on this list. And NestJS is the enterprise choice, with Angular-style decorators and dependency injection that feel instantly familiar to anyone coming from Java or Spring.

But here is the question that matters more than which framework: do you need this layer at all?

Meta-frameworks (Layer 4, coming up) ship with built-in server capabilities. Next.js has API routes, SvelteKit has server endpoints, Nuxt has server routes. For a lot of projects, those are enough:

Meta-framework routes are fine for:    You need a dedicated server framework for:
  - Form submissions                     - Complex business logic
  - Email capture                        - Microservices
  - Simple CRUD APIs                     - Real-time (WebSockets)
  - Basic authentication                 - One API serving multiple frontends

What I picked: nothing. My form submission and email capture are a couple of endpoints, and SvelteKit’s built-in server routes handle them. If the project ever grows a real backend, Hono or Fastify would be the natural addition. Skipping a layer you do not need is a feature of understanding the stack, not a shortcut.

Layer 3: The tool you talk to every day without noticing

Every time you run npm run dev or npm run build, you are talking to Layer 3. Build tools sit between your source code and the browser, transforming TypeScript, JSX, Svelte files, and CSS imports into optimized files a browser can actually run.

This layer went through a revolution recently, and the revolution has a one-line summary: stop bundling during development.

Generation 1 (2012-2019):  Webpack, Rollup, Parcel
                           Bundle everything, JS-based, slow on large projects
Generation 2 (2020-now):   Vite, esbuild, Turbopack, Rspack
                           Native ESM in dev, Rust/Go for speed, 10-100x faster

Webpack dominated for a decade, and its configuration complexity became legendary in the process. It still powers enormous codebases, but new projects rarely choose it.

Vite is the current default, and it earned that position with one key insight: during development, do not bundle at all. Serve source files as native ES modules, let the browser import them directly, and only transform what is requested. The result is a dev server that starts in about 100 milliseconds whether your project has fifty files or five thousand. For production it hands off to Rollup, the bundler that pioneered tree-shaking. SvelteKit, Nuxt, Astro, and Remix all build on Vite, which tells you where the ecosystem has consolidated.

esbuild is the Go-based transformer doing the heavy lifting inside Vite, 10 to 100 times faster than Webpack at raw transformation. You will probably never configure it directly. Turbopack is Vercel’s Rust-based Webpack successor, currently exclusive to Next.js. Rspack is the pragmatic one: Rust speed with Webpack-compatible configuration, built as a migration path for big Webpack projects that want speed without a rewrite.

What I picked: Vite. Honestly, I did not pick it. SvelteKit picked it for me, and that is the most important lesson of this layer: in 2026, your meta-framework usually decides your bundler. You choose this layer indirectly.

Layer 4: The decision that makes the other decisions

This is the big one. The meta-framework is the orchestration layer: routing, server-side rendering, static generation, data loading, deployment. It is the thing you actually npm create when you start a project, and it reaches down to pick your bundler and up to dictate your UI framework.

If you only think hard about one layer, make it this one.

The names matter less than the three architectures hiding underneath them:

Ship the full runtime. Next.js, Nuxt, and Remix send the framework to the browser along with your code. Every user downloads React or Vue itself, then your application on top. Consistent and predictable, but you start with a baseline of framework weight before writing a feature.

Compile the framework away. SvelteKit takes the opposite approach: Svelte components become plain vanilla JavaScript at build time, and no framework ships to the browser at all. The framework exists only on your machine.

Islands. Astro and Fresh render the page as static HTML and ship JavaScript only for the specific components that need interactivity. A page that is 90 percent static gets 90 percent less JavaScript. For content-heavy sites this is the theoretically optimal architecture, and Astro deserves special mention because it is framework-agnostic: you can write your islands in React, Svelte, Vue, or Solid, mixed in one project.

What I picked: SvelteKit. And I will be honest about the road not taken: for a site that is 80 percent static content, Astro was arguably the more “correct” choice on pure architecture. I went with SvelteKit because my interactive parts (the timeline, the assessment flow) are stateful enough that I wanted one coherent app model rather than scattered islands, the Netlify adapter is first-class, and the compile-away approach gets me most of Astro’s weight savings anyway. When two options are this close, ergonomics win.

Layer 5: How you actually write components

The UI framework defines how you author components and manage state. Here is the twist that most comparison articles miss: by the time you reach this layer, the decision is usually already made. Pick SvelteKit and you write Svelte. Pick Next.js and you write React. Astro is the only mainstream escape hatch that lets you mix.

So why understand this layer at all? Because it should inform your Layer 4 choice, not follow from it.

The numbers are interesting, but the mental models are where these frameworks really differ. Here is the same counter with derived state in all four:

// React: state is a function call, re-renders the whole component
const [count, setCount] = useState(0);
const doubled = useMemo(() => count * 2, [count]);

// Svelte 5: state is a variable, the compiler tracks dependencies
let count = $state(0);
let doubled = $derived(count * 2);

// Vue 3: state is wrapped in ref(), the template tracks dependencies
const count = ref(0);
const doubled = computed(() => count.value * 2);

// Solid: state is a signal, fine-grained updates, no re-renders
const [count, setCount] = createSignal(0);
const doubled = () => count() * 2;    

React asks you to learn its rules: re-render cycles, dependency arrays, memoization, the rules of hooks. In exchange you get the largest ecosystem and job market in front-end history. Vue softens those edges with the Composition API and is enormously popular outside the US. Solid keeps React’s look but replaces the virtual DOM with fine-grained signals, so updates touch exactly the DOM nodes that changed. And Svelte, especially since version 5 introduced runes, lets you write nearly plain JavaScript: a variable marked $state is reactive, and the compiler figures out the rest at build time.

What I picked: Svelte 5. For a content-heavy site, shipping a ~2KB compiled output instead of a ~44KB runtime is a real difference users feel on slow connections. The syntax is also simply less code: no hooks, no dependency arrays, no memoization rituals. The trade-off is a smaller ecosystem and a niche job market, which matters for hiring on a team but not for a solo project.

Layer 6: Where the religious wars happen

Styling is the layer with the widest spread of philosophy, and the only one where developers get genuinely angry at each other. The options span a full spectrum from total control to total abstraction:

Full control <-------------------------------------------------------------> Full abstraction
Plain CSS → CSS Modules → Open Props → Vanilla Extract → Tailwind/UnoCSS → styled-components
  ↑                                                                              ↑
  Write every rule yourself                                     Never write a CSS rule    

Tailwind dominates new projects, and it is still controversial. You write utility classes like text-lg bg-blue-500 p-4 directly in your markup instead of authoring CSS files. Critics call it inline styles with extra steps. In practice it eliminates three chronic problems at once: naming things, dead CSS accumulating forever, and specificity wars. Version 4 became a Vite plugin, so even the PostCSS configuration is gone.

CSS Modules are the sane middle ground: write normal CSS, get automatically scoped class names, never worry about leaks. styled-components pioneered CSS-in-JS but is falling out of favor because of its runtime cost; the industry has moved decisively toward build-time solutions like Vanilla Extract, which gives you fully typed styles in .css.ts files with zero runtime. UnoCSS is the efficiency play: Tailwind-compatible class names, but it generates only the CSS you actually use, on demand.

One footnote worth knowing if you go the Svelte route: Svelte components have built-in scoped styles. Plain CSS inside a <style> tag is automatically scoped to that component, like CSS Modules with zero setup. You can use it alongside Tailwind for the cases utilities handle awkwardly.

What I picked: Tailwind CSS v4. Utility-first is simply fast for a solo project, there is no custom CSS file to maintain, and the Vite plugin makes setup a one-liner in SvelteKit. I keep Svelte’s <style> blocks in reserve for anything genuinely custom.

Layer 7: The polish layer

The top of the stack: how things move. Animation gets dismissed as decoration, but transitions are often what separates a site that feels professional from one that feels like a homework assignment.

The practical reality: most projects need enter/exit transitions, hover effects, and maybe a scroll-triggered reveal. That is it. CSS animations cover 80 percent of those cases in any framework. GSAP is the professional tool when you genuinely need timelines and scroll choreography, which is why marketing agencies live in it. Framer Motion is excellent but heavy; notice that it weighs as much as React itself. And the browser-native View Transitions API is quietly making page-level transitions free.

What I picked: Svelte’s built-in transitions. fly, slide, and fade are part of the framework, compiled in at zero added bundle weight, and they cover everything my timeline and assessment flow need. This was the layer where choosing Svelte at Layer 5 paid a second dividend.

The hidden rule: one choice, five consequences

If you zoom back out, a pattern emerges that no single-layer comparison will show you. The meta-framework is the keystone decision. Choose Layer 4 and you have implicitly chosen Layers 1, 3, and 5, plus the natural shape of Layer 2:

Pick this...     ...and you get
─────────────────────────────────────────────────────
SvelteKit    →   Svelte + Vite + built-in endpoints
Next.js      →   React + Turbopack + API routes
Nuxt         →   Vue + Vite + server routes
Astro        →   Any UI + Vite + built-in endpoints
Fresh        →   Preact + esbuild + Deno handlers

Only styling and animation remain genuinely independent choices.

This is why “Vite vs Next.js” is a confused question: Vite is Layer 3 and Next.js is Layer 4, and choosing Next.js means choosing Turbopack, while choosing almost anything else means choosing Vite. The tools were never alternatives. They are answers to different questions, occasionally bundled together.

For quick reference, here is how I would map common project types to stacks:

Project type                  Stack I would reach for
──────────────────────────────────────────────────────────────
Content/marketing site        SvelteKit or Astro + Tailwind
SaaS with complex UI          Next.js or SvelteKit + Tailwind
Enterprise app, large team    Next.js or Angular + CSS Modules
Performance-critical SPA      SolidStart or SvelteKit
Blog/docs site                Astro + Tailwind
API-first backend             Fastify or Hono
Edge/serverless API           Hono
Enterprise backend            NestJS
Prototype / MVP               SvelteKit or Next.js + Tailwind
Heavy scroll animation site   Astro + GSAP

What I actually shipped

Here is the full stack for my project, layer by layer:

Layer 1 | Runtime:         Node.js
Layer 2 | Server:          SvelteKit built-in (no dedicated framework)
Layer 3 | Bundler:         Vite 7
Layer 4 | Meta-framework:  SvelteKit 2
Layer 5 | UI framework:    Svelte 5
Layer 6 | Styling:         Tailwind CSS 4
Layer 7 | Animation:       Svelte built-in transitions
          Deployment:      Netlify (via adapter)

The result for a content-heavy site with interactive components: roughly 16KB of JavaScript shipped to the browser, versus 90KB or more for the equivalent React stack, before I write a single feature. No animation library, no CSS files to maintain, no backend to deploy. Two of the seven layers (server framework and animation library) turned out to be layers I did not need at all, and knowing the map is what made skipping them a confident decision instead of a guilty one.

That is the real payoff of thinking in layers. The next time a shiny new tool tops Hacker News, you will not ask “should I switch to this?” You will ask “which layer is this, and is it better than what that layer already gives me?” Most of the time the answer is no, and you can get back to building.

If you keep one thing from this article, keep the diagram. Seven layers, seven questions, one decision that drives the rest. The JavaScript ecosystem is not chaos. It just needed a map.

Conclusion

By mapping your tools to these seven layers, you can build with confidence, avoid the hype cycle, and design web applications built to last.

If you enjoyed this layer-by-layer breakdown of the modern web stack, follow me here on Medium and subscribe to get notified of my future pieces.

TL;DR. A Linux laptop can use an iPad as a real, draggable second display over local Wi-Fi using a hardware HDMI dummy plug, a passive USB-C hub, Sunshine on the laptop, and Moonlight on the iPad. The non-obvious gotcha is the type of USB-C-to-HDMI adapter you use, which is what most of this article is about. If you just want the working recipe, jump to section The setup that ended up working at the end. If you want the gotcha that cost me two bad hardware buys, read on.

I work on a Dell XPS 17 9730 running Kubuntu. At my desk I have a 5K external monitor and the laptop’s own 4K panel, which is plenty of room for code, notes, browsers, and chat side by side. The problem starts the moment I leave that desk. At a hotel, in a café, on a flight: one screen. Coding with a terminal and a documentation tab open and a Slack window pinging? You’re constantly Alt-Tabbing. It’s fine for casual use. It’s brutal for real work.

I already carry an iPad on every trip. So the question that nagged me for months: surely there’s a way to use the iPad as a second screen for my Linux laptop, the way macOS users do with Sidecar.

The answer turned out to be yes, but only after a winding path that included two pieces of hardware I assumed were broken, one operating-system rename that ate a chunk of time, and a fairly deep dive into how USB-C-to-HDMI adapters actually work. This is that story, with enough technical detail that if you’re trying the same thing, you can skip the parts I got wrong.

Why not just buy a portable monitor?

The obvious question, and one I sat with. Reasons I went the iPad route:

• I’m already carrying the iPad. A portable monitor is another brick in the bag.
• Portable monitors that are big enough to be useful (15"+) weigh about as much as the laptop again.
• iPads have genuinely good panels (ProMotion, P3 colour, brightness levels portable monitors can’t touch) for less money than an equivalent monitor.
• The iPad doubles as an iPad. The monitor only ever monitors.

So the goal: stream part of my desktop to the iPad over local Wi-Fi, with low latency, in a way the operating system treats as a real, draggable second display, not a remote-desktop mirror.

Why software-only didn’t work

The first instinct on Linux is to find a software solution. The ecosystem is crowded: Xvfb, Xephyr, VNC, kernel EDID overrides, compositor virtual outputs, kernel virtual KMS. On a vanilla X11 desktop most of these would work. On my specific stack (KDE Plasma 6 + Wayland + NVIDIA Optimus), the options thinned fast, and the two I seriously tried both failed in instructive ways.

Attempt 1: KDE’s built-in virtual output

KDE Plasma 6 ships its own virtual-output API. You can ask the compositor to add a synthetic screen at any resolution:

kscreen-doctor --add-virtual-output --resolution 2360x1640@60

I picked iPad Air resolution so the captured stream would match the target exactly. The command ran cleanly. What happened next was specific enough to my stack that it didn’t match any of the textbook NVIDIA-Wayland virtual-output failure modes online. I dropped this path and went lower.

Attempt 2: VKMS, the Virtual Kernel Mode Setting module

If the compositor wouldn’t give me a usable virtual screen, the next layer down is the kernel itself. Linux ships a module called VKMS whose entire job is to expose a synthetic DRM/KMS device: no physical hardware behind it, just a CPU-memory framebuffer with simulated vblank timing.

sudo modprobe vkms enable_cursor=1 enable_writeback=1

It loaded cleanly. The kernel announced it:

[drm] Initialized vkms 1.0.0 for vkms on minor 0
faux_driver vkms: [drm] fb1: vkmsdrmfb frame buffer device

A new DRM device appeared at /dev/dri/card0. Sunshine, the streaming server I'd settled on, saw it and attached:

sunshine.log: /dev/dri/card0 -> vkms

This part worked. Sunshine could capture from VKMS. But the moment it tried to encode the captured frames, the architecture broke down.

Hardware video encoders (VAAPI on the Intel iGPU, NVENC on the NVIDIA dGPU) expect to consume frames that already live in GPU memory. The mechanism is called a DMA-buf import: Sunshine hands the encoder a file descriptor, the encoder maps it into its own address space without copying, and the encode runs at zero-copy speed.

VKMS framebuffers don’t live in GPU memory. They live in plain system RAM, simulated by the CPU. There is no DMA-buf file descriptor you can hand to a hardware encoder that points back at a VKMS frame. So Sunshine’s options reduced to:

1. Software encode (libx264), which defeats the entire point of using a low-latency streaming protocol
2. CPU to GPU memcpy then hardware encode, which is even slower than option 1

Either way, the smooth low-latency stream I wanted was off the table.

The kernel was also unhappy about VKMS under any real load. It kept emitting vkms_vblank_simulate: vblank timer overrun warnings, meaning the synthetic 60Hz vblank timer couldn't keep up.

That’s when I gave up on software. I ordered the dummy plug.

What’s a dummy HDMI plug?

A dummy HDMI plug is a small piece of plastic and silicon that fits in an HDMI port and asserts to the host “yes, I am a monitor, here is my EDID.” It contains nothing more than a tiny EEPROM holding monitor identification data and a hot-plug-detect pull-up.

Why does this exist? Mining rigs use them so headless GPUs render at full resolution. Render farms use them so workstation GPUs don’t downclock when no monitor is attached. Streaming setups use them so the OS believes a second display exists, gives it a piece of the desktop, and lets you drag windows onto it.

They’re cheap (about ₹400, or US$5) and they sounded like the most boringly reliable way to make Linux think a monitor was connected.

The XPS 17 has no HDMI port

A wrinkle I should have noticed sooner: the Dell XPS 17 is USB-C only. Four Thunderbolt 4 ports, no HDMI socket on the chassis. So before I could plug a dummy plug into anything, I needed a USB-C-to-HDMI adapter to create an HDMI port to plug it into.

I already owned a Dell DA20, Dell’s official small USB-C-to-HDMI/USB-A adapter, the kind that comes in laptop docking-station kits. Naturally I used that.

It didn’t work. I plugged the dummy plug into the DA20’s HDMI port and waited for a third display to appear in KDE’s display settings. Nothing happened. xrandr showed only my existing two screens. No new connector enumerated.

I assumed the dummy plug was defective and ordered a second one from a different brand. It also did nothing.

At this point I had two presumed-defective dummy plugs, a working-looking adapter, and a broken theory.

The single piece of knowledge that explains everything

Here is what I wish I’d known before clicking “buy” on either of those plugs.

There are two completely different breeds of USB-C-to-HDMI adapter, sold under indistinguishable marketing. Reviews rarely mention which is which. They are not interchangeable for headless or dummy-plug use cases.

Active adapters (what the Dell DA20 is)

Inside the housing is a silicon chip called an LSPCON (Level Shifter / Protocol Converter), typically a Parade PS176 or a MegaChips equivalent. The signal flow is:

The LSPCON is not just a translator; it’s a gatekeeper. When something is plugged into the HDMI end, the LSPCON:

1. Powers the EDID EEPROM on the sink (over HDMI pin 18, +5V)
2. Reads the EDID over the DDC/I²C lines
3. Validates it, checking checksums, supported modes, and extension blocks
4. Only if validation passes, asserts hot-plug-detect upstream toward the laptop

If the EDID looks malformed (bad checksum, modes the LSPCON doesn’t know how to translate to HDMI 2.0, sloppy I²C timing) the LSPCON quietly refuses to assert HPD. The laptop never sees a hot-plug event. No new connector enumerates. No error message anywhere. It just silently doesn’t work.

A real monitor handshakes loosely enough that this validation almost always passes. A cheap HDMI dummy plug, with its mass-cloned reference EDID firmware, often does not. That’s why both my dummy plugs failed identically through the DA20: they probably ship the same reference EDID under different brand stickers, and the Parade chip in the DA20 rejects it.

The LSPCON exists in the DA20 because Dell wanted to guarantee HDMI 2.0 / 4K@60Hz bandwidth on every USB-C port, regardless of whether the laptop’s own port can output HDMI signaling natively. It’s a feature for real monitors. It’s the wrong silicon for a dummy plug.

Passive adapters

No chip. Just a PCB that remaps USB-C pins to HDMI pins, with light voltage level shifting on copper. The signal flow:

This is part of the DisplayPort Alt Mode spec, sometimes called HDMI Alt Mode. The source GPU does the HDMI signaling natively rather than going via DisplayPort first. There is no chip in the middle inspecting the EDID. The DDC/I²C lines run straight through the cable to the GPU’s own HDMI receiver.

GPU HDMI receivers are far more lenient than LSPCONs. They’ll accept the same malformed dummy-plug EDID an LSPCON rejects.

The test that distinguishes them: plug a dummy plug into the adapter’s HDMI port. If a connector lights up in your OS, the adapter is passive (or has a permissive LSPCON). If nothing happens, it’s a strict active adapter.

I happened to have an old generic USB-C hub in a drawer with a passive HDMI port. I tried the same dummy plug in that hub. The connector lit up immediately, claimed 3840×2160@60 as native, and KDE auto-arranged it as an extension of my desktop.

Both dummy plugs worked through this hub. Both had been rejected by the DA20.

The dummy plugs were never defective. The DA20 wasn’t broken either. They’re each fine for their intended use cases. The dummy plugs need a passive path; the DA20 needs a real monitor.

The streaming layer: Sunshine + Moonlight

With a virtual display lit up, the streaming layer was the next problem. I chose the Sunshine server + Moonlight client combination. Sunshine is an open-source implementation of NVIDIA’s discontinued GameStream protocol, and Moonlight is the matching client, with apps for iOS, Android, tvOS, Windows, Linux, and most embedded platforms.

Why this combo and not, say, Steam Link or Parsec or VNC?

• Latency. Moonlight on a local Wi-Fi network gives roughly 20 to 50ms glass-to-glass at 1080p. VNC is multiples of that.
• Hardware encoding. Sunshine targets VAAPI (Intel/AMD), NVENC (NVIDIA), and AMF (AMD). The encode is essentially free on any modern GPU.
• Per-output capture. I can point Sunshine at a specific DRM connector (the dummy plug) while my real screens stay private.
• Native iPad client. Moonlight for iOS is polished, free, no subscription, no telemetry.

Setup was straightforward: install the Sunshine AppImage on the laptop, pair the iPad to it via a 4-digit PIN over Sunshine’s local web UI, done. On first launch Sunshine auto-detected the Intel iGPU’s VAAPI encoders and picked h264_vaapi. NVENC didn't even get tried, because the discrete NVIDIA GPU was asleep in runtime suspend, and the dummy plug lives on the integrated GPU side anyway.

One wrinkle worth knowing. Rather than running the AppImage directly, it’s better to extract it first and grant the binary Linux file capabilities. AppImages, when launched normally, self-mount to a temporary path under /tmp each time they start. That works for running the app, but it makes it awkward to apply persistent file capabilities, and Sunshine needs two of them to perform at its best:

./Sunshine.AppImage --appimage-extract
# the AppImage extracts into a directory called squashfs-root
# move/rename it to wherever you want it to live permanently, e.g. ~/sunshine-app
mv squashfs-root ~/sunshine-app
sudo setcap cap_sys_admin,cap_sys_nice+p ~/sunshine-app/usr/bin/sunshine
~/sunshine-app/AppRun

The two capabilities matter for different reasons. CAP_SYS_ADMIN lets Sunshine perform KMS direct capture without running as root, which is the lowest-overhead capture path on Linux. CAP_SYS_NICE lets it set realtime scheduling priority for the encoder thread, which keeps frame timing consistent under load. Without the second one, you'll see a CAP_SYS_NICE capability is missing warning in the log and visible frame-pacing jitter during streams.

Sunshine’s bundled AppRun --install script does this setcap step plus a few related setup tasks (udev rules for virtual input devices, a systemd user service), so running that once after extraction is usually the cleanest path: ~/sunshine-app/AppRun --install.

Aside: Sunshine when run from an extracted AppImage has a separate quirk on KDE. Its tray icon comes up as an empty slot because the binary requests an icon by name (dev.lizardbyte.app.Sunshine-tray) that lives at a non-standard path inside the AppImage tree. The fix is to copy the relevant SVGs into the user's hicolor icon directory and clear KDE's icon cache.

The aspect-ratio rabbit hole

The stream worked. The picture had black bars.

Setting Moonlight’s resolution to match the iPad’s panel did nothing. I switched the host’s dummy-plug display to a 4:3 mode. Now there were black bars on all four sides: a tidy rectangle floating in the middle of the iPad screen, surrounded by black.

The streaming pipeline preserves aspect ratio at every stage. So:

Host display (3840×2160, 16:9 = 1.78:1)
    ↓  Sunshine captures host canvas
Encoded video (in container at whatever resolution Moonlight requested)
    ↓  scaling preserves the source aspect
    ↓  non-matching aspect = bars baked into the encoded video
Decoded on iPad
    ↓  scaled to fit the iPad panel, aspect preserved
iPad screen (2388×1668, ≈1.43:1, not 16:9, not 4:3, an oddly-specific in-between)

When I “fixed” the bars by switching the host to 4:3 (1.333:1), the host source was now narrower than what Moonlight was requesting (it was still set to a 16:9 preset like 1080p). Sunshine therefore encoded a 4:3 image into a 16:9 container with black bars on the left and right. That 16:9 encoded video then hit the iPad screen (1.43:1), and got more bars on top and bottom from that mismatch. Pillarbox plus letterbox equals picture-frame.

The fix is to align all three aspects:

1. Set the host display to a 4:3 mode (closest available to iPad’s 1.43:1)
2. In Moonlight, use Custom Resolution at the same 4:3 width and height
3. Reconnect the stream

After that, only thin left/right bars remained on the iPad, about 3.4% per side, from the unavoidable 4:3-vs-1.43:1 residual. Visible if you look for them, invisible during actual use.

The setup that ended up working

For reference, the working configuration:

• Laptop: Dell XPS 17 9730, Kubuntu, KDE Plasma 6.5 on Wayland, Intel Iris Xe iGPU and NVIDIA RTX 4060 dGPU
• Dummy plug: BUYMINERS.CA HDMI Dummy Plug, 4K@60Hz EDID (the brand barely matters once you’re on a passive path; this one is confirmed working)
• Adapter: 5-in-1 USB-C Hub (Type-C to 4K HDMI + Ethernet + USB 3.0) with a passive HDMI port (not the Dell DA20)
• Server: Sunshine, AppImage launched via its AppRun script
• Client: Moonlight on iPad Pro 11"
• Host display mode: 1400×1050 (4:3) at 60Hz
• Moonlight stream resolution: Custom 1400×1050
• Audio + keyboard: flow through Moonlight automatically.
• Total extra weight in the bag: a few grams (one small hub plus one small dummy plug, both stay assembled together)

The physical chain at the destination, in order:

laptop USB-C port  ←  the hub  ←  dummy plug (in the hub's HDMI port)

The dummy plug stays plugged into the hub’s HDMI port permanently. It never leaves the hub. The whole “hub + dummy plug” assembly travels as one unit. At a destination, you plug only the hub’s USB-C cable into a free port on the laptop. That single physical action lights up the virtual display, and from there Moonlight on the iPad picks up the stream over Wi-Fi.

If you have a Linux laptop, an iPad, and a long flight coming up: try it. The path is shorter than it sounds, as long as you know which adapter to buy.

I gave the same prompt to two separate agents. Same model (Claude Pro Max). Same codebase. Same instructions.

The results were structurally identical, and subtly, importantly different.

This article is about what I learned from that experiment, and why the lesson isn’t “run everything twice.”

The Setup

I created two Sculptor agents, each on their own branch:

• Agent A: ran first
• Agent B: ran second, identical prompt

Both agents needed to:

1. Add the Google Analytics gtag snippet
2. Create a centralized analytics module
3. Wire up event tracking across landing page components and the assessment flow

Both agents delivered working code. Both created an analytics.ts module with helper functions. At a glance, the output looked nearly identical.

Then I diffed the branches.

What Was the Same

The high-level architecture was identical. Both agents made the same macro decisions:

• Inline the gtag snippet in src/app.html
• Create src/lib/analytics.ts as the centralized tracking module
• Instrument the core components: Hero, Footer, AssessmentCTA, and the assessment page
• Track the same categories of user actions: assessment flow, CTA clicks, email capture, external links

Agent B went further and also instrumented HowItWorks and ParadigmTeaser, giving it broader tracking coverage. But the architecture and approach were the same.

Neither agent invented a novel architecture. They converged on the obvious, correct approach. This is actually reassuring. It means the fundamentals are reliable.

Where They Diverged

The differences were in the details. And in analytics, the details are everything.

Difference 1: When Does “Assessment Start” Fire?

This was the most consequential difference.

Agent A tracked assessment start on the user’s first interaction, specifically when they click their first answer:

// Agent A: Track on first interaction
let hasTrackedStart = $state(false);

function selectOption(questionId: string, optionIndex: number) {
  if (!hasTrackedStart) {
    trackAssessmentStart();
    hasTrackedStart = true;
  }
  trackQuestionAnswer(questionId, currentIndex);
  // ...
}

Agent B tracked it on page load, the moment someone lands on /assess:

// Agent B: Track on page load
import { onMount } from "svelte";

onMount(() => {
  trackAssessmentStart();
});

Why does this matter? Because of the funnel.

With Agent B’s approach, you can measure:

Page visit (100%) → First answer (72%) → Completion (45%) → Email (18%) → Booking (6%)

With Agent A’s approach, your funnel starts at “First answer.” You’ll never know that 28% of visitors bounced before answering a single question. That’s often the most actionable insight. Maybe your first question is intimidating, or the page loads too slowly, or the CTA copy set the wrong expectation.

Agent B’s approach is correct for analytics. Agent A’s approach is a subtle bug that looks like a feature.

Difference 2: How They Structured the Analytics API

This is where the two agents made the most visibly different design choices.

Agent A created a single, generic function for all CTA tracking:

// Agent A: One function, free-form strings
export function trackCTAClick(ctaName: string, location: string): void {
  trackEvent("cta_click", {
    cta_name: ctaName,
    location: location,
  });
}

Used like:

onclick={() => trackCTAClick("take_assessment", "hero")}
onclick={() => trackCTAClick("book_conversation", "footer")}
onclick(() => trackCTAClick("book_diagnostic", "results_page")}

Agent B created separate, purpose-built functions:

// Agent B: Separate functions per CTA type
export function trackAssessmentCTAClick(location: CTALocation): void {
  trackEvent("cta_click", {
    event_category: "cta",
    event_label: "take_assessment",
    cta_location: location,
  });
}
export function trackBookingCTAClick(location: CTALocation): void {
  trackEvent("cta_click", {
    event_category: "cta",
    event_label: "book_conversation",
    cta_location: location,
  });
}

My initial reaction was that Agent B’s approach was clearly better because of type safety. But when I looked more closely, I realized Agent A’s labels were actually correct. The footer button says “Book a Conversation.” The results page button says “Book a 30-Minute Diagnostic.” These are different CTAs with different copy. Tracking them with different names is the right call.

So this turned out to be a genuine style difference, not a correctness issue. Agent A went with fewer, more flexible functions. Agent B went with more structured, specialized functions. Both are defensible choices. For a small site with a handful of CTAs, Agent A’s simplicity is arguably the better tradeoff. For a larger site where dozens of developers are adding tracking calls, Agent B’s structure would matter more.

The lesson here is subtler than “one is right and one is wrong.” It’s that you have to actually read the output in context before judging which approach is better. I almost dismissed Agent A’s version as buggy when it was actually doing the right thing.

Difference 3: Event Richness

Agent A sent minimal data:

// Agent A: Just the basics
export function trackQuestionAnswer(
  questionId: string,
  questionIndex: number
): void {
  trackEvent("question_answer", {
    question_id: questionId,
    question_number: questionIndex + 1,
  });
}

Agent B sent richer context:

// Agent B: Full context for analysis
export function trackQuestionAnswer(
  questionId: string,
  questionIndex: number,
  totalQuestions: number
): void {
  trackEvent("question_answer", {
    event_category: "assessment",
    event_label: questionId,
    question_index: questionIndex,
    total_questions: totalQuestions,
    progress_percent: Math.round(
      ((questionIndex + 1) / totalQuestions) * 100
    ),
  });
}

With Agent B, you can immediately build a drop-off chart by progress percentage. With Agent A, you need to hardcode the total question count in your analytics dashboard configuration. Small difference, but it’s the kind of thing that determines whether you actually build that dashboard or just say “I’ll get to it later.”

Difference 4: External Link Tracking

An interesting case where Agent A actually had one better idea:

// Agent A: Tracks the URL too
export function trackExternalLink(linkType: string, url: string): void {
  trackEvent("external_link_click", {
    link_type: linkType,
    link_url: url,
  });
}

// Agent B: Only tracks the type
export function trackExternalLinkClick(linkType: ExternalLinkType): void {
  trackEvent("external_link_click", {
    event_category: "outbound",
    event_label: linkType,
    link_type: linkType,
  });
}

Agent A captured the actual URL being clicked. More useful for debugging. A nice touch that Agent B missed.

What Caused the Divergence?

When I saw that Agent B produced better output on funnel tracking, my first thought was: “It did better because it was the second attempt. Maybe there’s some learning happening.”

Nope. These are completely independent agents. No shared memory. No context from the first run. This is correlation, not causation.

LLMs are non-deterministic. The same prompt can produce different design decisions each time. But that variation isn’t random noise. It shows up most when the prompt leaves room for interpretation.

Which led me to my second idea: what if I just run every task through two agents and pick the better output?

I seriously considered this. But it breaks down fast:

• Double the cost. Twice the compute, twice the review time, for every task.
• Diffing is real work. Comparing the two analytics implementations took genuine effort: reading both, reasoning about design tradeoffs, checking consistency across components. For a larger feature, the diff itself becomes a project.
• It treats the symptom, not the cause. The agents didn’t diverge because of bad luck. They diverged because my prompt was underspecified.

What Actually Works: Better Prompts

The real fix is giving the agent the context it needs upfront. If my original prompt had been:

Add Google Analytics tracking. Track assessment start on page load (not on first interaction) so we can measure the full funnel. Include progress percentage in question answer events. Use GA4 event categories and labels.

Both agents would have converged on the better implementation.

Where this matters most (spend the extra five minutes on your prompt):

• Analytics and tracking
• Authentication and authorization
• Data models and schemas
• APIs and contracts

Where first pass is fine (don’t overthink it):

• Wiring up UI components
• Standard CRUD operations
• Configuration and styling

The quality bottleneck isn’t the model. It’s the prompt. Your domain knowledge about what makes analytics data clean or what makes auth code secure is exactly what the AI doesn’t have. The more of it you encode upfront, the less the output varies, and the less it matters whether you run the task once or ten times.

I’m building AI Native Orgs to help engineering teams transform how they work with AI. If you’re navigating the shift from ad-hoc AI usage to AI-native engineering practices, take the assessment to see where your team stands.

It ended up being useful in a very practical way. Teams evaluating migrations (Python → Rust, JS → Go, etc.) used it to decode the learning curve without jumping across docs and blog posts.

Two years later, AI tooling changed enough that I didn’t want this project to stay “stuck in 2023”.

So I tore it down and rebuilt it using modern agentic workflows.

It’s live now at programming-languages.com.

What changed in the rebuild

This wasn’t a cosmetic cleanup. The rebuild touched the foundations:

• Refactored the codebase for maintainability
• Standardized the UI and navigation
• Added comprehensive tests
• Improved SEO structure and analytics instrumentation

In 2023, AI felt like “generate a snippet.”
In 2026, it feels like “do real maintenance.”

I used Antigravity (Google’s AI IDE) with Gemini 3 Pro, plus background agents (Codex) to drive the rebuild.

A quick SEO lesson: GitHub Pages wasn’t reliable for crawling

The original version started on GitHub Pages (github.io).

It was perfect for shipping quickly, but I noticed something frustrating: crawlability and indexing were not reliable for this project.

And for a tool like this, discoverability is part of the product. You want people to land directly on concept pages from search.

So I moved:

1. GitHub Pages → Netlify
2. Netlify → a dedicated domain

That last step mattered the most. The project now lives at programming-languages.com.

A 2026 superpower: SEO + analytics became “one-shot easy”

One of the biggest breakthroughs for me was how much of SEO and analytics is now straightforward with agents.

Things that used to take hours of fiddly effort became closer to:

• clear instruction
• one pass
• quick review
• done

Not everything is automatic, but the “activation energy” is dramatically lower.

Another surprise: JavaScript started feeling like TypeScript

This is unintuitive, but real.

When you work with agents instead of human peers, even JavaScript code comes out more structured and consistent.

In my head it started feeling “TypeScript-like” because:

• fewer sloppy shortcuts
• more repeatable patterns
• more predictable refactors

It’s not a replacement for TypeScript. It’s a shift in baseline quality when an agent is maintaining the code.

Automated browser testing became part of my workflow

Antigravity’s automated browser testing helped a lot during the rebuild.

Not just unit tests. Real flow validation:

• navigate concepts
• search within a concept
• confirm the UI behaves correctly

This is now a permanent part of how I build.

I started saving agent summaries as Git commit context

Another habit I’m keeping:

At the end of an activity, the agent summarizes what it changed and why. I store that summary in the Git commit message (or body).

It improves the repo instantly:

• richer commit context
• decision trail for later
• better “why” documentation without extra work

Try it and tell me what to add next

If you’re comparing languages or planning a migration, try it:

Programming Language Comparison - Side by Side Concept Reference

And if you’re doing a migration right now, what’s the one concept you always end up googling? That’s what I should prioritize next.

🚦 In a Rush? Here’s the 2-Minute Read

India’s traffic isn’t just a problem of potholes and poor signals, it’s a behavioral crisis. From our work at RoadsenseAI, where we analyzed real traffic footage through dash-mounted phones, we saw patterns emerge that go beyond rules a nd deep into culture.

This article explores:

• What makes a Smart Driver in India — not just obedient, but cooperative, predictable, and respectful.
• How we can build a movement of certified smart drivers with social recognition and peer influence.
• Why we should reframe bad driving as rude behavior, much like cutting in line.
• A proposal for vehicle-based fine multipliers, making traffic penalties meaningful across income groups.
• How delivery and cab platforms externalize bad driving and should be held accountable.
• The surprising link between queue culture and road behavior, and how fixing one helps the other.
• Visual nudges like red-marked no-stop zones, inspired by global best practices like London’s yellow box junctions.
• A vision for shifting from zero-sum to co-op driving, where honks become signals of gratitude, not aggression.

These ideas aren’t about stricter enforcement , they’re about creating a culture of cooperation on Indian roads.

⏱️ Got more time? Read the full piece below, about a 15-minute deep dive into how behavior, incentives, and design can transform our streets.

Setting the Stage

From 2019–2020, I co-founded and led a startup called RoadsenseAI. Our bold idea was to put “Eyes on the Wheels” by installing a simple app on the smartphones of Uber and Ola drivers. These phones, mounted on dashboards and already in use for Google Maps navigation, quietly recorded what the driver saw through the windshield. Our backend processed the video streams, extracting real-world intelligence that was valuable to traffic police, real estate developers, and insurance companies.

In essence, while Google crawls the web, RoadsenseAI crawls the roads. It created a dynamic, visual index of India’s ever-evolving traffic, streets, and urban behaviors.

This article is about the insights we gleaned from this experiment and how they can seed large-scale change in India’s traffic ecosystem.

Behavioral Change Begins with Critical Mass

One of the more audacious ideas we developed was to define and reward a new class of drivers: good drivers. Here’s how:

Defining a Smart Driver

Before we talk about building a tribe of smart drivers, we must first ask: What exactly is a smart driver in the Indian context?

A smart driver is not merely someone who avoids getting caught for violations. They are not just compliant — they are conscious, cooperative, and culturally aware. In a traffic ecosystem full of unpredictability and stress, the smart driver stands out by making choices that benefit not just themselves but everyone around them.

Core Behavioral Traits of a Smart Driver

• Respectful Merging: Yields when appropriate, avoids aggressive cut-ins.
• Lane Loyalty: Stays within lane boundaries unless required to switch, and signals clearly.
• Predictability: Uses indicators, avoids sudden stops or swerves.
• Queue Discipline: Waits in line, doesn’t bypass or jump ahead unfairly.
• Kindness on the Road: Makes room for others, especially ambulances, pedestrians, and cyclists.
• Patience at Intersections: Doesn’t honk unnecessarily or edge forward aggressively.
• No Honk Policy: Reserves honking only for genuine warnings.
• Peer Reinforcement: Educates co-passengers or peers on smart behavior where possible.

Building the Smart Driver Tribe

Self-Certifying Training Program
We start with a training or course area where drivers watch a video on smart driving principles. They then practice these principles in a controlled environment. We record their driving session and provide them with that video as a positive artifact of their behavior. Upon completion, drivers receive a physical sticker for their vehicle — identifying them as a certified smart driver.

QR Code Verification
Each sticker includes a QR code that links to a central database. When scanned, it displays details about the driver’s certification, the date they were certified, and the car number. This allows community partners (like parking facilities or toll booths) to verify the certification and grant benefits such as reserved parking or discounted tolls.

Community Rewards and Visibility
By making smart drivers easily identifiable, we encourage a culture of respect on the road. Other drivers can see and anticipate that these drivers follow traffic rules, promoting a cooperative driving environment.

Additionally, this recognition can serve as a form of social capital. Certified smart drivers can use their status as a point of pride on dating sites, job applications, or community forums — showcasing it as a positive character trait that reflects responsibility, respect, and civic-mindedness.

Iterative Experimentation
We can also offer a lighter version — like watching a YouTube video and answering questions — to expand participation. Over time, we refine the certification process based on feedback.

If we reach a tipping point with this tribe, their influence can reshape social norms on the road.

Don’t Be Rude: A New Vocabulary for Driving

Telling people not to speed or cut lanes isn’t working. Instead, we need to reframe bad driving as rude behavior.

Because when you make anti-social driving culturally unacceptable, it triggers a shift deeper than rules can.

We already call people rude for cutting in line at a buffet or interrupting someone mid-sentence. The same needs to be true when someone honks needlessly, bypasses a queue, or refuses to yield. It’s not just unsafe. It’s inconsiderate.

This reframing turns the conversation from law enforcement into social etiquette. From “don’t break the rules” to “don’t be rude.”

Currently, we are competing against billions spent by three powerful cultural forces:

• Movies that idolize high-speed chases, defiance of traffic norms, and rebellious anti-heroes behind the wheel. Think of the Fast & Furious franchise, Need for Speed, or countless Bollywood action sequences.
• Gaming, where titles like Grand Theft Auto, Burnout, and Asphalt reward chaotic or ultra-aggressive driving styles.
• The high-performance car industry, which markets speed and power as status symbols, glorifying 0–100 km/h acceleration and track-style handling, even in urban cars.

We need counter-narratives that associate speeding and lane-cutting not with thrill or power, but with selfishness, rudeness, and immaturity. Culture shapes conduct. If we want better roads, we must start by reshaping what people admire behind the wheel.. We need new cultural narratives that associate speeding and lane-cutting not with thrill, but with selfishness and rudeness.

Vehicle-based fine multiplier

One idea borrowed from behavioral economics is the concept of income-adjusted fines, used in some European countries like Finland and Switzerland. These are often calculated based on a person’s daily income, ensuring that a fine for reckless behavior stings equally for a millionaire and a minimum-wage worker.

In India, however, the divide between the haves and the have-nots is vast, and formal income records are often missing or unreliable. A more practical and culturally attuned alternative is to use the vehicle type as a proxy for economic status.

We propose a vehicle-based fine multiplier system:

• Entry-level hatchbacks pay the base fine.
• SUVs and higher-end sedans pay 2x.
• Premium and luxury vehicles (e.g., BMWs, Audis, Mercedes) pay 5x.

This system reflects the owner’s likely financial capacity while being easy for law enforcement to verify and implement. By linking penalties to the visible, tangible asset (the car), it aligns consequences with affordability — and discourages the wealthy from treating fines as trivial fees.

The underlying principle is simple: bad behavior should hurt more for those who can absorb a bigger hit.

Externalizing the Damage: Holding Platforms Accountable

Companies like Swiggy, Zomato, Ola, and Uber have built their empires on a gig economy backbone — drivers and delivery partners who are technically “independent” but functionally essential. In their quest for speed and volume, these platforms incentivize faster turnarounds, more trips, and tighter delivery windows — often pushing their partners into violating traffic rules.

This is a form of externalization, much like how manufacturing industries pollute while expecting the community or the Government to absorb the damage. In this case, the community pays — in the form of congestion, accidents, stress, and eroded public norms.

We propose a simple but powerful shift: if a ride-hailing or delivery driver violates traffic rules, the platform pays 10x the fine.

This would:

• Push platforms to invest in better training, education, and behavioral nudges
• Drive innovation in real-time tracking, route optimisation, and behavior-aware incentives
• Force companies to align with public interest, not just profit per kilometre

The moment these costs hit a platform’s bottom line, their priorities will change. And as they improve their partners’ driving behaviors, they contribute directly to the critical mass of cooperative road users — shaping the culture through scale.

This isn’t just policy. It’s structural behavior design.

How We Queue Is How We Drive

Could one of the deeper reasons for poor road behavior in India stem from how we behave in queues? There seems to be a striking resemblance between how people navigate traffic and how they navigate public lines. Both are shaped by early exposure, informal social rules, and survival instincts in crowded environments. This observation raises an important question worth exploring further: Is our chaotic road behavior an extension of our queue culture?

From a young age, children observe chaotic queue dynamics: people skipping lines, crowding each other, and the tallest or loudest pushing through. Over time, this trains the subconscious belief that survival depends on aggressively asserting one’s place, not waiting one’s turn.

This same logic then plays out on the roads: lane-cutting, tailgating, honking, and refusing to yield. In both queues and traffic, the lack of mutual respect and perceived fairness leads to stress, anxiety, and rule-breaking.

To truly reform road behavior, we need to address how people queue in everyday life — in small restaurants, bus stops, ticket counters, and hospitals. We propose a multi-pronged approach:

• Encourage the creation of a free, publicly available set of space design templates — contributed by architects and urban designers — that promote single-file discipline with natural spacing. These designs should be simple, modular, and adaptable for use by small shops, restaurants, bus stops, and public venues, enabling them to implement better queue systems without incurring significant costs.
• Encourage designs that reduce ambiguity — e.g., painted footprints, rope dividers, staggered markers.
• Pair design with nudges: signage that reminds people that “respect starts here,” or even community recognition for shops with good queue practices.

Queue Dynamics, Not Just Lane Discipline

When you fix queues, you fix driving. They are cognitively and culturally linked.

• Design and implement visible, behavioral queues at entry points
• Avoid aggressive merging by pre-defining entry zones
• Move from gap driving to lane driving

It’s a mindset shift, not just an infrastructure challenge. Changing how people wait in line might be the most foundational step toward changing how they behave on the road.

Red-marked no-stop zones

These are specially designated areas — particularly near U-turns, intersections, and signal junctions — where stopping is absolutely prohibited. The road surface itself will be literally painted in red, acting as a strong visual and psychological signal, similar to the yellow box junctions used in cities like London or Singapore. These markings are meant to communicate clearly that the area must always remain free-flowing — no stopping, no idling, and no waiting. Such bottleneck points often become the root cause of peak-hour traffic chaos when even a single two-wheeler or auto rickshaw halts, blocking others from taking turns or clearing the junction. The red paint on the road enforces a zero-tolerance policy: these are not parking spaces, not waiting zones, and not areas to pause when traffic ahead is stalled. If you can’t move forward, you stop before the red — it is meant only for moving vehicles.

To reinforce this, we propose a community-enforced model: anyone should be able to capture a short video of a violation and submit it to a public portal. This data could be verified using timestamp/location metadata, and verified contributors would be rewarded with small credits or incentives. The goal isn’t surveillance for punishment, but to make it socially and economically risky to violate obvious common-sense rules. This builds a critical mass of behavior change — when everyone expects accountability, everyone behaves better.

From Zero-Sum to Cooperative Driving

Driving on Indian roads often feels like a zero-sum game: if one driver gains, others must lose. For example, if the vehicle in front slows down, the immediate assumption is that the driver is incompetent — prompting the next driver to aggressively overtake, often from the wrong side, only to get stuck behind a two-wheeler or incoming traffic. No one wins, but the urge to ‘get ahead’ dominates.

Contrast this with driving behavior in countries like the US, where the mindset resembles a co-op game: people yield, trust the intentions of others, and collaborate to ensure a smoother experience for everyone. There’s an unspoken social contract — to trust, to wait, and to flow together.

To shift Indian roads from zero-sum to cooperative dynamics, we need new cultural cues and reinforcements. One such idea is to reverse the emotional role of honking. Instead of aggressive or intimidating honks, what if we had a second tone — a softer, lighter ‘thank-you honk’? Either through a dedicated button or by modulating the intensity of the horn press (soft press = gratitude tone, hard press = alert tone), we could create auditory signals of appreciation.

Imagine driving through a city where you hear frequent tones of gratitude, kindness, and acknowledgement. This could reinforce co-op game dynamics subconsciously — making drivers feel calmer and more connected.

Co-op Game Signals: Thank-you honks or lights when someone lets you go. It’s not just about utility, it’s about signalling that we’re in this together.

Next Steps

We’ll be expanding this article with visuals. If you’re a policymaker, technologist, or someone who believes traffic is solvable, let’s connect.

What blew my mind wasn’t just the elegance of the project , it was how something so small, so focused, had quietly gone viral within niche creative communities. Blender MCP is essentially a bridge between Anthropic’s Claude (a powerful AI assistant) and Blender, the much-loved 3D creation suite.

As someone who’s dabbled in creative tools for years, I’ve always found Blender powerful but intimidating. The learning curve feels steep, the UI a little too layered. But the promise of conversational assistance inside Blender? That got me curious.

Wait… Claude inside Blender?

Yes. With Blender MCP, you can talk to Claude (via Claude Desktop) while working inside Blender. Imagine asking:

“Can you help me model a low-poly tree?”
“What’s the fastest way to rig this character?”
“Give me color palette ideas based on this HDRI.”

It turns Claude into your co-pilot for 3D creation.

But there was a small challenge: I use Linux, specifically Kubuntu. And Claude Desktop hasn’t officially been released for Ubuntu.

So here’s a quick guide for fellow Linux users to get this running.

Installing Claude Desktop on Ubuntu (Debian-based)

I found aaddrick’s Claude Desktop for Debian — a FOSS project that lets you install Claude Desktop as a .deb package. Basically downloads the windows installer , extracts the electron binaries required and repacks them for Linux electron and builds Ubuntu installer. I even asked Claude itself to audit the code for anything suspicious, it passed the vibe check. Following instructions will build you a .deb installer. I would recommend this instead of appimage binary because of better system integration.

# Clone this repository
git clone https://github.com/aaddrick/claude-desktop-debian.git
cd claude-desktop-debian

# Build the package (Defaults to .deb and cleans build files)
./build.sh

# Replace VERSION and ARCHITECTURE with the actual values from the filename
# sudo dpkg -i ./claude-desktop_VERSION_ARCHITECTURE.deb   
sudo dpkg -i ./claude-desktop_0.12.16_amd64.deb

Fixing MCP Config for Linux

Check https://github.com/ahujasid/blender-mcp for configuring MCP on claude. The default config for Blender MCP didn’t work out of the box. Here’s the working configuration that finally got everything talking. You need to replace the command path with the location of uvx on your system.

whereis uvx
uvx: /home/srix/.local/bin/uvx

{
  "mcpServers": {
    "blender": {
      "command": "/home/srix/.local/bin/uvx",
      "args": ["blender-mcp"]
    }
  }
}

How It Works — The Architecture

Once you have Claude Desktop and Blender MCP set up, the magic happens through a light weight MCP server and an addon (server) inside blender.

Essentially, Claude Desktop acts as the front-end assistant. When you ask something, the request is routed to the Blender MCP server, which then talks to a Blender Addon (running inside Blender itself) via a TCP socket. The Addon, in turn, executes API calls inside Blender — or fetches assets from sources like PolyHaven or Sketchfab.

It’s a clever, modular setup. Lightweight. Hackable. Extendable.

Tiny UX Note

One small UX issue I noticed: Blender addon integration button says “Connecting to MCP Server”, which feels misleading . It’d be better as “Listening to MCP Server”.

Installing Blender

If you don’t already have Blender installed:

sudo apt install blender

Or get the latest version directly from blender.org. Make sure to enable scripting and the MCP addon.

See it in Action

Here’s a short video clip of Blender MCP in action — Claude assisting while I generate an animation sequence:

Why This Matters for Artists

This tool isn’t about making AI do your work , it’s about removing friction. When the tools fade into the background, play and flow emerge. That’s when great art happens.

If Blender ever felt “too technical” for you, give this a spin. Claude becomes your whispering muse. Ask questions, get inspiration, explore faster.

And if you’re building tools like this, please keep going. These are the bridges that make creation more inclusive and delightful.

🔗 Links:

• Blender MCP GitHub
• Claude Desktop Debian Installer
• Claude by Anthropic

If you try it out or have questions, drop a comment . Let’s keep hacking creativity forward.

It is a café located at the corner of a busy intersection.
There was construction work happening all around.
Scaffolds raised on the walkway making the intersection look smaller than it was.
Creating new mazes to be negotiated by already busy New Yorkers and baffled tourists frequently staring at their phones,
reassuring themselves they are in the right direction toward their destiny.

The café has great coffee. Great sandwich.
What differentiates a tourist from a New Yorker?
Walking speed, the dressing, staring at phone,
and a slight hint of subtle expression of annoyance.

Annoyed at what?
As a tourist I am excited about everything NYC has put on display.
The tall buildings with vintage motifs and gargoyles
give me an impression that someone took an old European city
and pulled the buildings vertically.

In the night the buildings dazzle with lights.
Maybe someone is working, watching TV,
making decisions that will change others’ lives
or tallying their results in trading stocks.

If I squint my eyes I may even see a flying car
like that one in the popular sci-fi movies like Fifth Element or Star Wars.
Something about the tall buildings all around you, everywhere,
installs a weird sense of diminished size
in stature and also in ego.

Navigating the tall, ridiculously tall, 3D space
feels weird and feels like I am in a computer game
with artificially rendered buildings.

The contrasting aging subway that connects
every posh area of downtown Manhattan
grounds you, rather undergrounds you.

Dressing up, yes, the people in the city dress up.
They pay attention to what they wear, how they wear,
I am sure they know why they wear.
My interest is trying to guess why they wear what they wear.
Like a detective piecing together the clues of a crime scene,
I try to guess the story of a passerby.

Tourists are easy to call out.
They are not of big interest to me.
However, the New Yorkers — they are a different breed.

The city is cold.
Just out of snow when I visited.
I see everyone wearing appropriate levels of layers.
Except for many tourists.
They either wear too many or too few.
Me, on the too-little side.

Why dress up?
How do they know how to dress up?
Not for me.
They don’t know a traveller from India
is sitting in the café and watching them in amusement.
Like performers in a Broadway show.
Or maybe the Broadway shows are the inspiration.
When so many avenues of creativity flow through your city
like Broadway shows, art galleries, science, universities,
it rubs on you whether you want it or not.
Like the cold wind that embraces you
and welcomes you when you step out of the subway
whether you want it or not.

In me it installed a sense of writing.
As if it is a serious offence if I don’t chronicle this.

ChatGPT is quicker than search. But that’s not the point.

Searching for a solution while coding is inefficient.

Firstly, It takes time to read the multiple sites that Google serves as a result, including stack overflows pages, blogs, videos etc. Some might be correct, but outdated. For example, if you are looking for string interpolation in Python and land up in a blog that explains the same for Python versions previous to 3.6, it may recommend str.format() or % formatting instead of fstrings. All solutions will work with the latest Python. However, fstrings are more readable. Processing this and choosing relevant information takes time.

Secondly, the cost of context switching. Context switching breaks focus and flow state. Switchback takes time, and frequent switches may cause mental fatigue.

The fastest way to get help while coding is to ask an expert next to you (assuming you got one). An expert's answer usually has the following characteristics.

• Solution: The solution to your question. Sometimes experts may even share a code on Slack with you.
• Explanation: Explain the rationale for arriving at the answer. They don't want you to come again with similar questions and take their time. So they invest in explaining the thinking process.
• Caution: May inform you about the most common mistake you may make while implementing the solution. (because very likely they also made it)
• If you repeat the same query on another day, the expert may still provide the solution but might omit some information and add some new one.

ChatGPT is this expert.

Thanks to the integration of ChatGPT into VScode with Github Co-PilotX, there's minimal context switching required. In the following section, I will explain with an example the above characteristics.

Let’s analyse a solution.

I asked ChatGPT for a solution for an error in using Openai API in Python. Following is what ChatGPT replied.

The first paragraph starts with Explaining the rationale.

Then the Solution is provided step by step in three bullet points.

Followed by Caution

I started a side project, Comprehensive Comparison of Programming Languages, to understand coding from scratch using ChatGPT, including creating system diagrams. This article is the outcome of the observations during that project.

I started learning Rust recently. Began with the excellent material on the rust-lang website https://doc.rust-lang.org/book/. Though I learnt a lot going through it, I found something missing. I have deep expertise in Python and C# and wish a side-by-side comparison of concepts in these languages existed. I believe it will help me compare and understand the implementation of the same concept in Rust faster. Of course, I searched online and found a few useful sites like evmorov. Extending on Evgenii Morozov’s approach created a webpage where one can compare language concepts side-by-side. The content is generated using ChatGPT.

visit https://programming-languages.com

(old url https://srix.github.io/prog-lang-compare/)

The project was built entirely using ChatGPT (GPT-4) for content and assisted coding. In a way, it helped me understand what are the nitty gritty in building a product from scratch using ChatGPT and Github Co-Pilot. Currently, it supports more than 20+ programming languages including Dart , Go , Groovy , Haskell , Java 20 , JavaScript — ECMAScript 2021 , Julia , Kotlin , Lua , MATLAB , Objective-C , PHP , Perl , Python 3.10 , R , Ruby , Rust 1.55 , Scala , Swift , TypeScript , Visual Basic .NET.

I have been a long term Google G Suite user and like that product. Recently I was creating an account for a new domain and was rejected with a peculiar reason.

When I tried setting up the G Suite email account for a business domain RoadSenseAI.com , G Suite threw a weird error “Sorry, We’ve got dibs on that one.” and didn’t allow me to proceed. I didn’t find any details on the internet. So raised a support ticket with Google.

I received a prompt call from Google support shortly. The support personnel was himself surprised at the error message and politely put me on hold for 15 minutes. When he resumed the call, he gave me a peculiar reason and said it was not possible to subscribe to G Suite with this domain name. For a moment I thought it was ridiculous. So asked him to send a mail with the reason.

Thank you for answering my call.

I understand that you’re trying to sign up for G Suite using the domain name roadsenseai.com and you’re getting the following error message: “Sorry, we’ve got dibs on that one!”

You will not be able to register with that domain name as Google has a program named AdSense and your domain has the word “adsense”. I hope that I was helpful by clarifying this to you.

Since there are no further actions that our team is able to take to further assist you I will close this case.

Have a lovely rest of the week!

This was a complete disappointment for me. I enquired about the process to escalate or appeal, hoping G Suite will approve on case by case basis on such situations. Unfortunately, I was told, no such process exists.

My guess is Google is paranoid about Domain squatting and similar techniques impacting their AdSense product and rejecting all domains containing the AdSense product name.

I am sharing this so, if anybody getting “Sorry, We’ve got dibs on that one.” will be aware of the reason and not waste time on figuring out the root cause. Also hoping that Google may take this as feedback and have a special case by case approval rather sweepingly rejecting all such domains.