DEV Community

I Built a Random Word Generator… Then Realized How Often People Get Stuck

Bhavin Sheth — Tue, 12 May 2026 04:01:44 +0000

🚨 The Problem Wasn’t “Lack of Ideas”

It was something smaller.

And honestly… more annoying.

I’d sit there trying to:

Name something
Start writing
Think of an example
Create test content

And suddenly my brain would go completely blank.

Not because I had no ideas.

But because:

Starting is weirdly hard.

😐 The Funny Part?

Sometimes all you need is:

One random word
One unexpected idea
One small trigger

And suddenly your brain starts moving again.

💡 Why I Built This Tool

So I built something simple:

Random Word Generator

A tool that instantly generates:

Random words
Creative prompts
Naming inspiration
Brainstorming triggers

No signup.
No setup.
No overthinking.

Just:

Click → Get a word → Keep going

🧠 What I Realized

People don’t always use random words for “fun”

They use them when they’re:

Stuck
Overthinking
Brainstorming
Naming projects
Practicing writing
Testing UI/content

⚡ The Real Frustration

Creative blocks rarely look dramatic.

Usually it’s just:

Sitting there… thinking too long about one tiny thing.

And the longer you wait…

👉 The harder it becomes to start.

🔍 Why Random Inputs Actually Help

A random word forces your brain to react.

Even if the word isn’t perfect…

It creates movement.

And honestly:

Movement is usually more important than the “perfect idea”

😬 Where Most Tools Feel Wrong

A lot of generators online feel:

Cluttered
Slow
Filled with ads
Trying too hard to be “creative”

But this use case is simple.

You just want:

One quick spark.

🔥 What I Focused On

I kept it:

Fast
Minimal
Instant
Distraction-free

Because this tool isn’t about features.

It’s about:

Breaking mental friction.

📈 What Surprised Me

After launching it:

Some people used it for writing prompts
Others used it for project naming
Developers used it for dummy content/testing
Students used it for practice exercises

And honestly…

👉 The variety surprised me most.

🤯 The Real Insight

Sometimes the hardest part of creativity is not the work itself.

It’s simply:

Getting started.

🧩 Simple Rule I Follow Now

If users feel stuck…

👉 Reduce the pressure to be “perfect”

🚀 Final Thought

You don’t always need a big idea.

Sometimes:

One random word is enough to restart your brain.

Be honest — what do you usually do when your brain goes blank?

Take a break?
Search inspiration?
Force yourself to continue? 😅

Curious how others handle it 👇

A Physics-Aware React Design System for Modern Frontend Architecture

Limon — Tue, 12 May 2026 04:01:16 +0000

How I built a scalable React component ecosystem with Liquid Glass UI, token-driven theming, ITCSS architecture, accessibility-first APIs, and physics-reactive rendering.

Introduction

Modern frontend development has evolved far beyond styling buttons and shipping pages.

Today’s applications require:

scalable component systems
accessible interfaces
runtime theming
predictable architecture
performance-aware rendering
animation systems
design token synchronization
developer tooling
maintainable APIs

Most UI libraries solve only a portion of these problems.

Some provide components.
Some provide styling.
Some provide theming.
Some focus on animations.

Very few attempt to unify all of them into a single frontend architecture system.

That became the motivation behind Atomix.

⚛️ Atomix is a modern React design system and component architecture framework built to combine:

enterprise-grade component patterns
token-based theming
accessibility-first APIs
physics-aware visual rendering
ITCSS + Sass architecture
Storybook-driven development
tree-shakable package exports
CLI-based tooling
modern DX workflows

The project started as a small internal component system.
Over time, it evolved into something much larger.

Today, Atomix includes:

50+ typed React components
a physics-reactive Liquid Glass rendering engine
a configurable theme compiler
a CLI toolchain
multiple package entry points
chart systems
accessibility tooling
runtime theme injection
utility-first architecture

This article explores the architecture decisions, rendering systems, and engineering concepts behind Atomix.

The Problem with Most Component Libraries

Most component libraries eventually run into the same limitations.

1. Styling Becomes Fragile

Applications start small.
Then CSS grows.
Then overrides appear.
Then theme exceptions appear.
Then design inconsistencies spread.

Without a strict architecture system, frontend codebases become difficult to maintain.

2. Components Are Not Truly Reusable

A component may look reusable, but often:

styles are tightly coupled
theming is incomplete
accessibility is inconsistent
APIs are rigid
motion systems are disconnected

True reusability requires architectural consistency.

3. Most Design Systems Ignore Motion

Animation is often treated as decoration.

But modern interfaces increasingly rely on:

motion feedback
physics
transitions
interaction-driven rendering
spatial continuity

Motion is part of UX.

Atomix was designed with that idea from the beginning.

The Vision Behind Atomix

The goal was never just “another React UI library.”

The vision was:

Build a frontend architecture system where design tokens, components, accessibility, motion, rendering, and developer tooling work together as a unified ecosystem.

That meant focusing on several core principles.

Core Principles

1. Architecture First

Atomix follows a strict system-oriented philosophy.

The project uses:

ITCSS
layered Sass architecture
token-driven styling
utility namespaces
predictable component APIs
isolated rendering systems

This creates long-term maintainability.

2. Accessibility by Default

Accessibility should not be optional.

Every component is built with:

keyboard navigation
ARIA attributes
focus management
screen reader support
reduced motion awareness
semantic HTML patterns

Atomix targets WCAG 2.1 AA compliance.

3. Performance Matters

Modern frontend systems can easily become bloated.

Atomix focuses on:

tree-shakable exports
lazy-loaded heavy components
isolated package entry points
runtime performance optimization
GPU-accelerated rendering
adaptive animation quality

4. Motion Is Part of the System

Interfaces should feel responsive and alive.

That led to one of the most experimental parts of Atomix:

AtomixGlass

AtomixGlass — Building a Physics-Reactive Glassmorphism Engine

Glassmorphism became extremely popular across modern interfaces.

But most implementations are static.

Usually it’s just:

backdrop-filter: blur(20px);

I wanted something more dynamic.

Something that reacted to motion.
Something that felt physical.
Something closer to real optical distortion.

That became AtomixGlass.

What AtomixGlass Does

AtomixGlass is a rendering layer that provides:

backdrop blur
SVG displacement distortion
shader-based rendering
spring physics elasticity
velocity-aware gradients
chromatic aberration
adaptive FPS rendering
cursor-reactive deformation
reduced-motion accessibility

Instead of static blur, the surface behaves like a physical material.

Rendering Modes

AtomixGlass supports multiple rendering strategies.

Standard Mode

A lightweight SVG-based displacement effect.

Good for:

cards
buttons
lightweight UI

Polar Mode

Applies radial distortion patterns.

Useful for:

immersive panels
hero sections
futuristic UI

Prominent Mode

Increases deformation intensity.

Designed for:

interactive demos
marketing experiences
motion-heavy layouts

Shader Mode

The most advanced rendering mode.

This uses:

GLSL-inspired displacement techniques
off-thread calculations
cached distortion maps
adaptive frame scheduling

The result feels much closer to dynamic liquid glass.

Physics-Aware Interaction

One of the most important ideas behind AtomixGlass was elasticity.

The system tracks motion velocity and applies:

stretch
deformation
border intensity shifts
displacement updates

using spring-based calculations.

This creates interfaces that feel reactive rather than static.

Accessibility and Motion

Motion systems can become problematic for accessibility.

That’s why AtomixGlass respects:

prefers-reduced-motion

When reduced motion is enabled:

animations decrease
distortions soften
rendering loops reduce intensity
transitions become simpler

Accessibility remains part of the architecture.

Building the Theme Engine

The second major challenge was theming.

Most design systems eventually struggle with:

color overrides
spacing consistency
dark mode
runtime themes
token synchronization
CSS drift

Atomix solves this using a token-driven architecture.

Token-Based Theming

Atomix uses CSS custom properties as the foundation.

Example:

import { defineConfig } from '@shohojdhara/atomix/config';

export default defineConfig({
  theme: {
    extend: {
      colors: {
        primary: {
          main: '#7AFFD7'
        }
      }
    }
  }
});

This allows:

runtime theme injection
theme extension
token synchronization
dynamic overrides
predictable design systems

Runtime Theme Injection

Themes can also be injected dynamically.

import { createTheme, injectTheme } from '@shohojdhara/atomix/theme';

const css = createTheme();
injectTheme(css);

This makes it possible to:

switch themes instantly
generate runtime themes
support multi-brand systems
power white-label applications

Why ITCSS?

Many developers ask why Atomix still heavily uses Sass and ITCSS.

The reason is architectural predictability.

Atomix uses layered styling:

Settings
Tools
Generic
Elements
Objects
Components
Utilities

This prevents:

specificity wars
random overrides
inconsistent styling patterns
scaling issues

Large frontend systems need structure.

Utility Architecture

Atomix includes utility classes with strict namespacing.

Everything uses the u- prefix.

Example:

<div className="u-flex u-gap-4 u-items-center">

This prevents:

naming collisions
CSS ambiguity
framework conflicts

The goal is controlled flexibility.

Tree-Shakable Architecture

Large UI systems often become bundle-size problems.

Atomix solves this using segmented entry points.

import { Button } from '@shohojdhara/atomix/core';

or:

import { LineChart } from '@shohojdhara/atomix/charts';

This ensures applications only load what they need.

Building the CLI Toolchain

As the project grew, configuration became increasingly important.

That led to the Atomix CLI.

The CLI handles:

component generation
token synchronization
migrations
diagnostics
validation
theme building

Example:

atomix generate component Button

or:

atomix tokens sync

The goal is to reduce repetitive engineering work.

Storybook-Driven Development

Every Atomix component is developed inside Storybook.

This improves:

visual testing
interaction testing
accessibility inspection
isolated rendering
documentation quality

The ecosystem uses Storybook 8 with:

a11y addons
interaction testing
viewport testing
measurement tools
outline debugging

Component Philosophy

Atomix components are intentionally designed around composability.

Examples:

polymorphic rendering
slot-based composition
accessibility-first APIs
controlled + uncontrolled states
motion-aware interactions

Example:

<Button
  as="a"
  href="/dashboard"
  LinkComponent={Link}
>
  Dashboard
</Button>

This allows seamless integration with:

Next.js
React Router
custom navigation systems

Charts as First-Class Components

Another goal was avoiding fragmented visualization systems.

Atomix includes:

LineChart
HeatmapChart
TreemapChart
RadarChart
FunnelChart
GaugeChart
CandlestickChart
and more

All charts follow the same design-token architecture.

That creates consistency across applications.

Developer Experience Matters

One of the biggest lessons from frontend engineering is:

Good DX improves product quality.

Atomix prioritizes:

TypeScript-first APIs
strict typing
IntelliSense support
consistent naming
discoverable architecture
scalable imports
Storybook documentation
CLI tooling

Frontend tooling should accelerate development rather than slow it down.

Lessons Learned While Building Atomix

Building a design system teaches you a lot about frontend engineering.

Some of the biggest lessons:

1. Consistency Beats Complexity

Fancy abstractions are useless if developers cannot understand them.

Predictability matters more than cleverness.

2. Motion Requires Restraint

Animation can easily become overwhelming.

The best motion systems enhance usability without distracting users.

3. Accessibility Must Exist From Day One

Retrofitting accessibility later becomes extremely difficult.

It needs to be foundational.

4. Architecture Is a Long-Term Investment

Small projects can survive chaotic CSS.

Large systems cannot.

The Future of Atomix

Atomix is still evolving.

Planned areas include:

advanced animation primitives
design token pipelines
visual editors
AI-assisted theme generation
rendering optimizations
WebGPU experiments
advanced chart tooling
layout engines
motion orchestration systems

The long-term vision is ambitious:

Build a complete frontend architecture ecosystem for modern applications.

Final Thoughts

Frontend development is no longer just about building pages.

We are designing systems.

The future belongs to:

scalable architecture
accessible experiences
motion-aware interfaces
token-driven design
performance-focused rendering
developer-first tooling

Atomix is my attempt to bring those ideas together into a single ecosystem.

Still experimental.
Still evolving.
Still growing.

But the direction is clear.

Frontend systems should feel engineered — not assembled.

Run Claude Code Locally for Free with Docker Model Runner

Pradumna Saraf — Tue, 12 May 2026 03:56:26 +0000

We know that the Claude Code is phenomenal for development and code. But we can easily run out of tokens, and it becomes quickly expensive as your project becomes more complex. What if we can keep all the good parts about the Claude Code, but use the local models instead of clouds once from Anthropic?

Another reason we want to use the local models is that we have something proprietary or private that we don't want to expose to the cloud models, or we are in flight with no internet connection.

This is where Docker Model Runner is really useful; it helps us run the LLMs very easily locally on our machine, and we will then we will do some configuration to make it work with the Claude Code.

Prerequisites

Before we begin, make sure you have:

Docker Desktop or Docker Engine installed.
Docker Model Runner enabled.
Claude Code is installed and ready to go.

If you're on Docker Desktop, head over to Settings > AI and enable TCP access for Model Runner.

Or, if you prefer the terminal:

docker desktop enable model-runner --tcp 12434

Getting Started

1. Choosing and pulling a local model

There are a load of LLMs to choose from. I'll go with ai/phi4:14B-Q4_K_M, but you can pick whatever fits your machine can handle.

You can find all the models here in the DocketHub AI catalogue. Make sure that whenever you choose a model that is good on the coding side.

To pull the model, execute the command below. Pull time depends on the size of the model.

docker model pull ai/phi4:14B-Q4_K_M

2. Checking the connection

Using docker model sub-commands, we can check various things like the status and the model we have pulled. It's very similar to how we work with Docker images and containers.

Run the command below to check the model status and the list of models we have

docker model status
docker model ls

3. Testing the endpoint

Before we jump to test and use Claude Code, we should confirm that the API is actually responding. We can curl and send the request to the /v1/messages endpoint, and check that.

This is how the curl structure will look. Let's execute it in the terminal.

curl http://localhost:12434/v1/messages \
  -H "Content-Type: application/json" \
  -d '{
    "model": "ai/phi4:14B-Q4_K_M",
    "max_tokens": 100,
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

We will get a response like this. I am using jq to better format the output.

4: Pointing Claude Code at the local endpoint

It is very simple. We just need to tell Claude Code to use the local API instead of Anthropic's. We can do it by setting up a variable and a model name.

Set the ANTHROPIC_BASE_URL environment variable to use the Docker Model Runner endpoint and pass the model name we pull with --model. Execute the command below to set that:

ANTHROPIC_BASE_URL=http://localhost:12434 claude --model ai/devstral-small-2

That's about it. Claude Code is now pointing and running against your local model. You can also see the model being used by the Claude Code.

5: Adding the Shell config

As we know, the environment variable ANTHROPIC_BASE_URL is not persistent, and only lives for that session of the terminal. Setting the env variable every time is annoying.

To make it permanent so that every time you openup and new terminal, you have the same setup, we need to add the below shell config (~/.zshrc, ~/.bashrc, etc):

export ANTHROPIC_BASE_URL=http://localhost:12434

After you've done this. Restart your terminal, now the Claude Code will always use your local endpoint when you pass --model.

6. Using the Claude Code

Now, everything is set. Let's run Claude's code. To run with the local model, pass the same model flag and name, like this:

claude --model ai/phi4:14B-Q4_K_M

And we can give some simple tasks to check it's working:

6. Watching the requests flow

If you are a bit nerdy like me, and want to see what is happening under the hood. You can actually watch every request Claude Code is making to your local model:

To do that, execute the command below:

docker model requests --model ai/phi4:14B-Q4_K_M

Again, we used jq for better formatting.

7: What next?

The default context size on most models is fine for small tasks, but Claude Code reads a lot of files. For big project work, you'll want more headroom and a bigger context.

For example, to package gpt-oss with a 32k context window:

docker model pull ai/gpt-oss
docker model package --from ai/gpt-oss --context-size 32000 gpt-oss:32k

Then run Claude Code with the new variant:

claude --model gpt-oss:32k

And this is the game: we keep trying and experimenting with different models and context sizes until we find a perfect model for a task.

That was it. That's how you can run Claude Code completely locally with Docker Model Runner.

Give it a try, and let me know what model works best for you.

As always, I'm glad you made it to the end. Thank you for your support and reading. I regularly share tips on Twitter. You can connect with me there.

The Lie of Time Management: Why Your Energy is the Real Bottleneck

Hamza Hasanain — Tue, 12 May 2026 03:53:56 +0000

I recently tried a very foolish experiment. I decided to overwhelm myself with a massive workload to force myself to learn better time management. Between juggling university coursework, optimizing cloud infrastructure for Repovive, and grinding through AWS architecture study sessions, I mapped out every hour of my day.

I failed miserably.

But from that failure, I discovered a crucial truth: Time management is an overrated concept. The problem has never been a lack of time. The problem is entirely your energy as a human being.

Your energy is your daily currency. You spend it throughout the day on decisions, complex logic, and effort until your balance is depleted. Everything around us, especially in the tech industry, seems designed to drain this balance without us even noticing.

Here is the reality of what is actually stealing your energy, why we avoid hard tasks, and how to stop the leak.

The Procrastination Myth

We often think we procrastinate because we are out of time or lack discipline. But psychological research paints a different picture. According to Dr. Tim Pychyl, author of Solving the Procrastination Puzzle, procrastination is not a time management issue; it is an emotional regulation problem.

As developers, we procrastinate to avoid the immediate negative emotions—like anxiety, frustration, or the intimidation of a blank IDE—associated with a complex task. When your energy is already low, you simply do not have the internal currency left to fight those negative feelings, so your brain seeks a quick dopamine hit elsewhere.

Silent Energy Drains for Developers

1. Context Switching and The "Quick Check"

Those five minutes you spend checking your phone, replying to a Slack ping, or glancing at a Jira board don't just waste time; they burn your mental currency.

When you are deep in a complex problem—like holding the architecture of a distributed submission pipeline in your head or debugging a custom C++ allocator—your brain builds a massive, fragile mental model. Research by Gloria Mark at UC Irvine shows that it takes an average of 23 minutes and 15 seconds to return to your original state of flow after an interruption. Tearing down and rebuilding that mental model multiple times a day is exhausting.

2. The Morning Coffee Trap

Drinking coffee the second you wake up is actively setting you up for a mid-day crash.

According to neurobiologist Dr. Andrew Huberman of Stanford University, caffeine doesn't give you energy; it blocks adenosine, the brain chemical that makes you feel sleepy. If you drink coffee immediately, the adenosine continues to build up in the background. Once the caffeine metabolizes, you are hit with a massive backlog of adenosine all at once, causing your brain to shut down in the middle of the afternoon.

Delay your coffee by 90 to 120 minutes after waking up. Let your body's natural cortisol spike clear out the morning adenosine first.

3. Mental Load and Analysis Paralysis

Giving tasks more mental weight than they deserve drains your reserves fast. Staring at the screen, agonizing over the absolute most optimal database schema or over-engineering a simple microservice, burns more energy than actually writing the code. Overthinking is a massive energy leak. Often, writing a naive implementation and refactoring it later is far cheaper on your internal battery.

How to Protect Your Currency

If energy is the real bottleneck, how do we protect it?

Audit Your Drains: Stop tracking your time and start tracking your energy. Notice when you feel sharpest and when you feel completely brain-dead. Protect your high-energy windows fiercely—schedule your hardest architecture or problem-solving work for those specific hours.
Strategic Ignorance: Turn off notifications when doing deep work. Batch your communication. Check your emails and messages only at specific, low-energy points in the day rather than leaving them open on a second monitor.
Lower the Activation Energy: To fight the emotional block of starting an intimidating ticket, break it down into absurdly small steps. Don't set out to "build the feature." Set out to "create the file" or "write the function signature." Once the initial friction is overcome, momentum takes over.

Time is just a container. What matters is the energy you bring to the time you have. Stop trying to manage the clock, and start managing your battery.

Day 15/45 — Building a Workforce Management SaaS in Public

Taskdudes — Tue, 12 May 2026 03:50:17 +0000

At Taskdudes, our team is currently building a workforce management SaaS focused on simplifying employee operations for businesses.

The core problem we’re solving:
Most companies rely on multiple disconnected tools for scheduling, attendance tracking, employee management, and invoicing. That creates unnecessary operational friction.

Our approach is to unify those workflows into a single scalable platform.

What We’ve Built So Far
Employee Management Module
Shift Scheduling System
Time Tracking Features
Automated Invoicing Workflows
Backend Optimization
Testing & Quality Improvements
Tech Stack
Next.js
NestJS
PostgreSQL
Redis

This is a collaborative build involving multiple developers working together on architecture, scalability, workflows, and product decisions.

We’re documenting the entire process publicly — including challenges, trade-offs, and technical learnings.

45 days. One production-ready SaaS product.

Taskdudes #SaaS #WebDevelopment #SoftwareEngineering #NextJS #NestJS #PostgreSQL #Redis #BuildInPublic

Coding Cat Oran S2 Ep3 — The Auditor Arrives

SysLayer — Tue, 12 May 2026 03:48:43 +0000

She doesn't look at the machines.
She looks at the filing cabinets.

Her name is Ms. Chen.

She arrives at 9am with a rolling carry-on bag,
an iPad in a hard case,
and the specific kind of calm that belongs to people
who have seen this before.

Many times before.

The plant manager gives her a tour.
New equipment. Clean floors. Calibrated instruments.
He is proud of the production line.
He should be. It's good work.

Ms. Chen walks the line for two hours.
She says nothing.
She writes nothing on her iPad.

Then she turns to the plant manager and says:
"I'd like to see the production records. All of them. Going back eighteen months."

The plant manager smiles.
He has been preparing for this question.
He did not prepare for the answer to be complicated.

Here is what Ms. Chen finds:

The production floor: acceptable.
The equipment: calibrated, documented, within spec.
The documentation:

Batch records exist in three formats across four departments.
No single record contains the full picture of any batch.
To trace one production run from raw material to finished goods,
you would need to:

Find the batch number in Manufacturing's daily log (Excel, by shift, by month, one file per month, stored on the shift supervisor's PC)
Cross-reference with QA's inspection log (different Excel format, different batch number convention, stored on the QA lead's laptop)
Find the process parameters in Engineering's test folder (password protected; the VP is in a meeting)
Locate the material lot number in the incoming inspection binder (physical binder, shelf B3, organized by receipt date, not by lot number)

Ms. Chen does not do all of this.
She does enough of it to write, in the Notes field of her iPad:

Traceability: not demonstrated.

She meets with the CEO at 2pm.

She is direct. She is not unkind.

"Your production capability is real," she says.
"Your quality control process is real.
Your documentation system
is not a system.
It is hope organized into folders."

She opens her iPad and reads from the checklist:

Single source of truth for production data: Not met.
Traceability from raw material to finished goods: Not met.
Audit trail for process parameter changes: Not met.
Data stored in auditable, non-editable system: Not met.

"You have ninety days," she says.
"If these items are addressed at re-audit,
we proceed with the contract.
If not—"

She doesn't finish the sentence.
She doesn't need to.

The emergency meeting is Monday, 8am.
All senior managers. No exceptions.

The CEO does not raise his voice.
He doesn't need to.

He says: "Everything goes into a database. Oran is the project manager."

Then he looks at Oran.

Oran has been in this company for two years.
He has fixed the printers.
He has recovered someone's corrupted Excel file at 11pm.
He has set up the WiFi in the new warehouse.

He has never been a project manager.

He has also never wanted to be one.

But he has been taking notes since this meeting started,
and he has been thinking about this problem since the yield rate argument
three months ago,
and he knows — with the specific certainty that comes from
having already tried to do the thing the wrong way —
that there is no version of this that works
if IT just builds a database and waits for departments to fill it.

So before he says yes,
he stands up.

He writes three things on the whiteboard.

1. The timeline is IT's decision.

"The audit deadline is ninety days from today.
That does not mean the system is delivered in ninety days.
That means the system is delivered in whatever time it takes to build it correctly,
and the scope is defined by what can be done correctly,
not by what the deadline demands.
If the scope doesn't fit the timeline,
that is a conversation about scope.
Not about overtime."

The VP of Engineering shifts in his seat.

2. Resourcing is non-negotiable.

"I need two additional developers.
I need budget for tooling — database licenses, server infrastructure, testing environment.
I am one person. One person cannot build a traceability system for six product lines
in ninety days and also answer the help desk tickets
and also be in four status meetings a week."

The VP of Manufacturing starts to say something.
Oran continues.

3. Passive cooperation is not cooperation.

"Every department will have data submission deadlines.
If a department does not submit data by the agreed date,
the project is blocked.
That is documented as a management issue,
not an IT issue.
I will not absorb delays caused by other departments.
I will document them and escalate them."

He looks at the room.

"I want this in writing.
Signed.
Before the project starts."

The room is quiet for a moment.

Then the VP of QA says: "I think that's reasonable."
The VP of Engineering says nothing, which Oran writes down.
The VP of Manufacturing smiles — the specific smile of someone
who has already decided what they are going to do
and it is not what they are about to say —
and says: "Of course. We'll cooperate fully."

Oran writes that down too.
He writes the date next to it.
He puts a small star next to the VP of Manufacturing's name.

The CEO looks at Oran for a long moment.
Then he nods once.

"Ninety days," he says. "Make it work."

After the meeting, Oran walks back to his desk.
He opens his notebook to a fresh page.
At the top he writes:

Day 1.

Below it:

Things that are true:
— The system doesn't exist yet.
— The data is in twelve drawers.
— Three departments will say they're cooperating.
— Two of them mean it.
— The one who doesn't will be the most enthusiastic in every meeting.

He draws a line.

Below the line:

Things I can control:
— What I agree to.
— What I document.
— What I build.

He looks at that list for a while.

Then he opens his laptop and starts writing the schema.

The battle for the data hadn't started yet.
But Oran had just made sure that when it did,
he would not be the one who lost it alone.

Next: Ep4 — The Voluntary Table
No department wanted to think about the whole picture.
Then they sat in a room with a deadline and no escape.
Oran said nothing. That was the point.

← Ep1: The Excel Republic
← Ep2: The Big Customer

Coding Cat Oran is a serialized fiction about building real production systems inside real companies.
The audits are real. The ninety days are real. The cat is fictional.
The VP of Manufacturing is, unfortunately, also real.

By SysLayer · dev.to/syslayer

Why does paying more make your LLM reply faster?

Ashwin Hariharan — Tue, 12 May 2026 03:43:49 +0000

Why does Claude respond faster when you pay more? And why does a longer conversation cost disproportionately more than a short one?

For the longest time I simply accepted these as "it's just how it works". Like most engineers, I burn through Claude and GPT tokens all day and assumed "longer prompts cost more" was just a billing convention.

As it turns out, memory is one of the factors that influence LLM pricing.

Now memory in AI systems lives in a lot of places. vector stores for RAG, Redis for semantic caches and session state, in process caches for short-lived data. Each layer has its own latency budget and its own access pattern.

One layer that doesn't get talked about much, but quietly determines almost every LLM pricing decision from Claude, GPT, and Gemini, is HBM - the high-bandwidth memory inside the GPU itself.

At every token generation phase, the GPU does two reads from this high-bandwidth memory:

reading the model's weights
reading the KV cache

Let's unpack each briefly.

Reading the model's weights

Every time the model generates a token, your input flows through the model's layers one by one - from the first layer all the way to the output. This is called a forward pass.

Each forward pass reads the model weights just once, regardless of how many users are calling the API at the same moment. The weights are constant; they don't change between users.

This means the cost of that one weight read can be split. If the GPU packs 100 user requests into the same forward pass as a batch, those 100 users share the single weight read. The cost is split amongst 100 users.

Basically, it means that the "fast tier" modes in tools like Cursor are smaller batches (fewer people splitting the bill) - so you pay more per token.

Reading the `KV` Cache

The KV cache works differently. It is a variable cost that grows with your conversation.

A quick detour: the attention mechanism

When the model generates a new token, it doesn't treat every earlier token equally. It uses attention to decide which earlier tokens matter most.

The easiest way to picture it: imagine every token in your conversation is a sticky note with two parts.

The key is a short tag describing what kind of information this token carries.
The value is what's written inside the note — the actual information the model can pull in.

Take the sentence: "The cat sat on the mat. It was fluffy."

When the model gets to "It was fluffy" and tries to predict the next word, it needs to know what "It" refers to. So it scans the tabs (keys) of every earlier token:

cat: key indicates "I'm a noun, an animal, the subject". Value carries "small, furry, four legs, often a pet."
mat: key indicates "I'm a noun, an object, a location". Value carries "flat thing on the floor."

Both are nouns, but the cat key matches the question "what could 'It' refer to that could be fluffy?" better. So the model pulls in cat's value more strongly than mat's, and uses that to shape the next token.

Note: In reality keys and values aren't English sentences - they're vectors of numbers the model learned during training. But functionally that's the job they do: the key is how this token gets found, the value is what gets pulled in once it's found.

For every token in your conversation, the model saves a key (a searchable label) and a value (the content). Without the cache, the attention mechanism would recompute these from scratch on every step. With it, it just reads them back.

But that read grows linearly with every conversation:

1,000 tokens of context -> 1,000 key-value pairs read per generated token
100,000 tokens of context -> 100,000 key–value pairs read per generated token

And unlike weights, this cache is unique to your session - the GPU can't read user A's KV cache and reuse it for user B, because the data is different. Every user pays the full cost of reading their own KV cache, with no sharing.

💡 So under the hood, it's about how fast a chip can read memory.

The weight bill gets split across the batch, whereas the KV bill is just yours.

Learn more here

The math behind how LLMs are trained and served

The "Tunnel Vision" Effect and the Eclipse of A Priori Judgment in the Age of AI

Christian Herlein — Tue, 12 May 2026 03:38:20 +0000

As developers, we have always sought tools to optimize our workflow. However, the massive integration of Generative AI is not merely a change in tooling; it is a shift in our cognitive paradigm.

Lately, I have been reflecting on how this technology is altering our approach to complex problem-solving. What happens when we only activate our analytical capacity once a proposal is already on the table? Do we become mere editors of external solutions instead of the architects of our own?

This post is the first in a series of reflections on new workflows in our industry: the productivity gains, the invisible costs—in other words, the risks, challenges, and new opportunities.

Prolegomena: The Mutation of the Heuristic Process

The integration of Generative Artificial Intelligence into the software development lifecycle has introduced a mutation in the developer's heuristic. This phenomenon, characterized by a shift from systemic analysis toward point validation, threatens the architectural integrity of complex systems.

The Shift Toward A Posteriori Judgment

From a Kantian perspective, traditional software design has fundamentally relied on a priori judgment: the engineer's ability to structure mental schemas, model data to define information, establish interface contracts, and foresee potential internal system collisions before its formal codification.

This synthetic judgment has always acted as a mediator between the provided requirement and the resulting source code, serving as a channel for intellectual effort. The time invested in generating the theoretical framework—within which the source code possesses its own life—was the space where the developer added the most value, making the deepest design decisions. In this schema, the act of writing code was a task subordinate to mechanics and technique rather than to creative-architectural thought.

Conversely, the irruption of AI through the immediate availability of syntactic proposals induces a cognitive relaxation. The developer no longer generates the solution; they react to it. This transition toward an exclusively a posteriori judgment—where criticism is only activated in the face of an already produced artifact—eliminates the phase of pure reflection.

The Trap of Concreteness and the Loss of the "Big Picture"

Current language models are, by definition, local probability optimizers. Their output tends toward extreme concreteness: solutions that satisfy immediate functional requirements but lack the capacity for synthesis necessary for abstraction.

By delegating the choice of implementation strategy, the human developer falls into a "tunnel vision"; the leap from requirement to source code becomes instantaneous. The task of validating what was written—a mechanical activity—occurs immediately after receiving the requirement, eliminating the perception of added value in the essential decision-making process. Consequently, the unity of the system fragments:

At a local level: The solution is efficient, syntactically and functionally correct, and produces a reaction to the human perception of time that is substantially different from the traditional process.
At a systemic level: Architectural elegance is lost. AI does not comprehend the teleology of the system, nor does it possess the intrinsic intertemporality of the system it modifies, resulting in entropic growth of the codebase.

Consequences for Software Architecture

Abstraction is the primary mechanism for managing complexity. However, a posteriori judgment is inherently reactive and tends to accept the path of least cognitive resistance. If the AI’s proposal "works," the incentive to refactor toward a higher abstraction disappears.

In the long run, this produces systems composed of disjointed concrete solutions, increasing technical debt and reducing maintainability, as the "Big Picture" is sacrificed at the altar of delivery speed.

Conclusion

Software engineering must not be confused with the mere production of code; it is a discipline of systems design. Valuing and maintaining the exercise of a priori judgment is imperative to prevent technological assistance from degrading our ability to build robust and coherent systems, grounded in interconnected abstractions that provide unity and completeness. AI must be an instrument of execution, not the arbiter of our mental architecture.

Kubernetes CNI Complete Guide: Flannel vs Cilium vs Calico + Cloud Provider CNIs

Pendela BhargavaSai — Tue, 12 May 2026 03:30:00 +0000

K3s v1.29+ | Flannel v0.24+ | Cilium v1.15+ | Calico v3.27+ | AWS VPC CNI v1.18+ | Azure CNI v1.5+ | GKE Dataplane V2 (Cilium-based)

A definitive comparison of every major Kubernetes CNI — open-source plugins (Flannel, Calico, Cilium, Weave, Antrea, Multus) and cloud-managed defaults (AWS VPC CNI on EKS, Azure CNI on AKS, and GKE's Dataplane V2 on GKE) — across architecture, performance, network policy, observability, encryption, and when to choose each.

CNI	Identity	Core Approach	Default On
🟢 Flannel	Simple Overlay	VXLAN tunnel, zero policy	K3s
🟠 Calico	Policy Powerhouse	BGP routing, iptables/eBPF	Self-managed
🔵 Cilium	eBPF Native	Kernel eBPF, replaces kube-proxy	GKE (Dataplane V2)
🟡 Weave Net	Mesh Overlay	Gossip-based mesh routing	Self-managed
🟣 Antrea	VMware-backed	OVS dataplane, Antrea policies	Self-managed
🔶 AWS VPC CNI	Cloud-native	Native VPC IP assignment	EKS
🔷 Azure CNI	Cloud-native	Azure VNET IP assignment	AKS
♦️ GKE CNI / Dataplane V2	Cloud-native + eBPF	Cilium-based eBPF on GKE	GKE

What Is a CNI?
Open Source CNIs
- 2.1 Flannel — Simple Overlay
- 2.2 Cilium — eBPF Native
- 2.3 Calico — BGP + Flexible Dataplane
- 2.4 Weave Net — Mesh Overlay
- 2.5 Antrea — OVS-based CNI
- 2.6 Multus — Meta CNI
Cloud Provider CNIs
- 3.1 AWS VPC CNI — EKS Default
- 3.2 Azure CNI — AKS Default
- 3.3 GKE Dataplane V2 — GKE Default
Data Plane Comparison
Network Policy
Observability
Performance Benchmarks
Encryption
Multi-Cluster
Resource Usage
Full Feature Comparison
When to Choose Each
K3s-Specific Setup
Migration Guide on K3s
Conclusion

1. What Is a CNI and Why Does It Matter?

The Container Network Interface (CNI) is the plugin layer every Kubernetes cluster depends on for:

Assigning IP addresses to pods from a defined CIDR range
Creating virtual Ethernet (veth) pairs between pod namespaces and the host
Programming cross-node routing so pods on Node A can reach pods on Node B
Optionally enforcing NetworkPolicy resources to control traffic flow

Cloud providers like AWS, Azure, and GCP have built proprietary CNI plugins that deeply integrate with their underlying VPC/VNET networking primitives — providing native IP assignment, cloud-aware routing, and tight integration with cloud IAM, load balancers, and security groups.

💡 K3s Key Flag
To replace the default CNI on K3s, install with --flannel-backend=none --disable-network-policy. This leaves the CNI slot open for Calico or Cilium to fill.

2. Open Source CNIs

2.1 Flannel Simple Overlay

Flannel's design philosophy: do one thing well. A user-space daemon (flanneld) manages subnet allocation, while the kernel's own VXLAN and bridge code handles all actual forwarding. No policy, no observability — just connectivity.

Pod A (eth0: 10.244.0.2)          Pod B (eth0: 10.244.0.5)
        │                                  │
        │ veth pair                        │ veth pair
        ▼                                  ▼
           cni0 Linux bridge (kernel)
                    │
      iptables PREROUTING / FORWARD / POSTROUTING
                    │
         VXLAN encapsulation — UDP 8472
                    │
     flanneld (user-space) ← etcd / K8s API
                    │
          Physical NIC → Node B

Available backends:

Backend	Transport	Use Case
`vxlan`	UDP encap (default)	Works across any network, even routers
`host-gw`	Direct routing	Fastest, requires L2 adjacency between nodes
`wireguard-native`	Encrypted WireGuard tunnel	When you need encryption
`udp`	Legacy user-space	Fallback only — very slow

Network Policy: Flannel enforces zero NetworkPolicy. Resources are silently ignored. You must pair it with Calico (Canal) to get policy — adding a second DaemonSet, version compatibility risk, and split ownership between two projects.

Flannel Encryption: Flannel encrypts cross-node traffic only — pod-to-pod on the same node travels through the cni0 bridge unencrypted. No auto key rotation; restart flanneld to rotate keys.

{
  "Network": "10.244.0.0/16",
  "Backend": {
    "Type": "wireguard"
  }
}

Best for: Dev/CI clusters, Raspberry Pi, edge nodes, K3s defaults.

2.2 Cilium — eBPF Native

Cilium compiles and injects eBPF programs into the Linux kernel at TC/XDP hook points. There is no bridge, no iptables — packets are forwarded via bpf_redirect() at line rate, and policy is enforced via O(1) BPF map lookups.

Pod A (eth0)                         Pod B (eth0)
       │                                  │
       │ veth pair                        │
       ▼                                  ▼
TC eBPF hook ──── bpf_redirect() ──── TC eBPF hook
                  │
BPF maps: identity · policy · NAT · LB
                  │
cilium-agent — compiles eBPF, watches K8s API
                  │
  Physical NIC — GENEVE / native routing

Datapath modes:

Mode	Encapsulation	Requirement
`tunnel: geneve`	GENEVE (default)	Any network topology
`native-routing`	None	L2 adjacency or BGP underlay
`wireguard`	WireGuard transparent	Kernel ≥ 5.6
`ipsec`	IPsec	FIPS-regulated environments

Network Policy: 4.3 Cilium — L3 Through L7, No Sidecar

Cilium enforces standard NetworkPolicy and extends it with CiliumNetworkPolicy (CNP) for Layer 7 rules — no sidecar required:

# CiliumNetworkPolicy — L7 HTTP rule
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-get-only
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: GET
          path: "/api/v1/.*"

🔭 Cilium + Hubble

✅ Per-flow visibility on every packet
✅ Live service dependency map (Hubble UI)
✅ L7 HTTP / DNS / Kafka / gRPC flows
✅ Drop reason per endpoint
✅ Rich Prometheus metrics

# Enable Hubble and UI
cilium hubble enable --ui

# Watch live flows in a namespace
hubble observe --namespace production --follow

# Show only policy drops with reason
hubble observe --verdict DROPPED --follow

# Sample output:
# 12:34:01: default/frontend → default/backend  FORWARDED  TCP:SYN
# 12:34:02: default/attacker → default/backend  DROPPED    Policy denied

Cilium Encryption: Cilium WireGuard + IPsec

# WireGuard with strict mode (drops unencrypted packets)
cilium install \
  --encryption wireguard \
  --encryption-strict-mode true

# IPsec for FIPS-regulated environments
cilium install --encryption ipsec

Best for: Large-scale production, L7 policy, observability (Hubble), zero-trust, multi-cluster.

2.3 Calico — BGP + Flexible Dataplane

Calico uses BGP (Border Gateway Protocol) to distribute pod routes across nodes — no encapsulation by default. Each node acts as a BGP peer, advertising its pod CIDR to other nodes and upstream routers. Calico's data plane is pluggable: iptables, eBPF, or even Windows HNS.

Pod A (eth0: 192.168.0.2)          Pod B (eth0: 192.168.1.2)
        │                                  │
        │ veth pair                        │ veth pair
        ▼                                  ▼
      Host routing table (no bridge needed)
                    │
      iptables / eBPF policy enforcement
                    │
     Felix (per-node agent) ← Typha (fan-out)
                    │
     BIRD (BGP daemon) — peers with other nodes
                    │
    Physical NIC — direct IP routing (no encap)

Key Calico components:

Component	Role
Felix	Per-node agent; programs iptables/eBPF rules and routes
BIRD	Open-source BGP daemon; advertises pod subnets to peers
Typha	Fan-out proxy for the K8s datastore; recommended at 50+ nodes
calico-kube-controllers	Garbage-collects stale Calico resources

Network Policy: 4.2 Calico — L3/L4 Policy Leader

Calico is widely regarded as the gold standard for L3/L4 NetworkPolicy. It supports standard NetworkPolicy resources plus its own GlobalNetworkPolicy and NetworkSet CRDs:

# Calico GlobalNetworkPolicy — cluster-wide deny-all
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: default-deny-all
spec:
  selector: all()
  types:
  - Ingress
  - Egress

# Calico NetworkSet — group external CIDRs
apiVersion: projectcalico.org/v3
kind: NetworkSet
metadata:
  name: trusted-external
spec:
  nets:
  - 203.0.113.0/24
  - 198.51.100.0/24

⚠️ Calico does not support L7 HTTP/gRPC policy natively in OSS. For that you need its optional Envoy-based Application Layer Policy (ALP), which adds a sidecar and complexity.

Calico Encryption: Calico supports WireGuard for node-to-node encryption, enabled with a single patch:

kubectl patch felixconfiguration default \
  --type merge \
  --patch '{"spec":{"wireguardEnabled":true}}'

Starting in Calico v3.26, same-node pod traffic encryption is also supported via host-to-pod WireGuard options.

Best for: BGP-integrated DCs, Windows node support, bare-metal L3, robust L3/L4 policy.

2.4 Weave Net — Mesh Overlay

Weave Net uses a gossip protocol to build a full mesh topology between all cluster nodes without any central store. It wraps packets in a sleeve (VXLAN-like) tunnel and can optionally encrypt all traffic with NaCl. Weave is simpler to operate than Calico/Cilium but is no longer under active development (archived by Weaveworks in 2023).

Pod A (eth0)
       │
    weave bridge
       │
  weave daemon (gossip mesh peer discovery)
       │
  Sleeve / Fast Datapath (VXLAN kernel bypass)
       │
    Node B weave daemon
       │
    Pod B (eth0)

Key characteristics:

Feature	Detail
Discovery	Gossip — no external etcd needed
Datapath	Sleeve (user-space) or Fast Datapath (kernel VXLAN)
Encryption	NaCl (enabled per-pod connection)
NetworkPolicy	✅ Standard K8s policy supported
Status	⚠️ Archived/maintenance mode (use Cilium or Calico for new clusters)

⚠️ Important: Weaveworks ceased active development in 2023. Weave Net is community-maintained but no longer receives feature updates. It is not recommended for new clusters — migrate to Cilium or Calico.

Best for: Legacy clusters already running Weave with migration on the roadmap.

2.5 Antrea — OVS-based CNI

Antrea is a CNI backed by VMware (now Broadcom) that uses Open vSwitch (OVS) as its dataplane. It supports both Linux and Windows nodes and provides its own AntreaNetworkPolicy and ClusterNetworkPolicy CRDs with tiered policy enforcement. Antrea integrates well with NSX-T for enterprise SD-WAN environments.

Pod A (eth0)
       │
   OVS (Open vSwitch) bridge
       │
   antrea-agent (per-node DaemonSet)
       │
   antrea-controller (centralized)
       │
   Encap: Geneve / VXLAN / GRE (configurable)
       │
   Node B OVS bridge → Pod B

Key features:

Feature	Antrea
Dataplane	Open vSwitch (OVS)
Windows support	✅ Full (OVS on Windows)
NetworkPolicy	✅ K8s standard + AntreaNetworkPolicy CRDs
Tiered policy	✅ (Emergency / Security / Application tiers)
Encryption	✅ IPsec / WireGuard
Observability	✅ Antrea Octant plugin, Prometheus metrics
NSX-T integration	✅ Enterprise add-on
eBPF support	✅ AntreaProxy (partial eBPF)

Best for: VMware/NSX-T environments, Windows-heavy clusters, tiered network policy.

2.6 Multus — Meta CNI

Multus is not a standalone CNI — it is a meta CNI that allows pods to attach multiple network interfaces simultaneously. A pod can have its primary network (managed by Flannel/Calico/Cilium) and secondary interfaces (SR-IOV, DPDK, Macvlan) for specialized workloads like telco NFV or HPC.

Pod with Multiple NICs:
  eth0 (primary) ← Flannel/Calico/Cilium (cluster network)
  net1 (secondary) ← SR-IOV (high-throughput direct NIC)
  net2 (secondary) ← Macvlan (storage network)

Multus reads NetworkAttachmentDefinition CRDs and delegates
to the correct CNI for each interface.

# NetworkAttachmentDefinition for secondary interface
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: sriov-net
spec:
  config: |
    {
      "type": "sriov",
      "name": "sriov-net",
      "ipam": { "type": "static" }
    }

Best for: Telco/NFV workloads, HPC, pods that need to straddle multiple network segments.

3. Cloud Provider CNIs

Cloud-managed Kubernetes services ship their own CNI plugins that are deeply integrated with the underlying cloud networking fabric. These provide first-class VPC routing, cloud IAM integration, and managed lifecycle — but are typically locked to their respective cloud.

3.1 AWS VPC CNI — EKS Default

Amazon EKS uses the Amazon VPC CNI plugin (aws-node DaemonSet) by default. Instead of an overlay, it assigns real VPC secondary IP addresses directly to pods from Elastic Network Interfaces (ENIs) attached to the worker node.

Worker Node (EC2 instance)
    │
    ├── Primary ENI (node IP: 10.0.1.10)
    │      └── eth0
    │
    ├── Secondary ENI (attached by vpc-cni)
    │      ├── 10.0.1.20 → Pod A (eth0 via veth)
    │      ├── 10.0.1.21 → Pod B (eth0 via veth)
    │      └── 10.0.1.22 → Pod C (eth0 via veth)
    │
    └── vpc-cni (aws-node DaemonSet)
           manages ENI lifecycle via EC2 API

How pod IPs work:

Each EC2 instance can attach multiple ENIs; each ENI holds multiple secondary IPs
vpc-cni pre-warms a pool of secondary IPs per node via EC2 API calls
Pods receive a real VPC IP — routable natively across the VPC, peered VPCs, VPNs, and Direct Connect — with no overlay

Pod density limits per node (examples):

Instance Type	Max ENIs	Max IPs (pod limit)
t3.medium	3	17
m5.large	3	29
m5.xlarge	4	58
m5.4xlarge	8	234
c5.18xlarge	15	750

⚠️ Important: Default pod density is capped by the ENI/IP limit per instance type. For IP-constrained environments, use VPC CNI with prefix delegation (ENABLE_PREFIX_DELEGATION=true) to assign /28 prefixes instead of individual IPs, dramatically increasing pod density.

Key features:

Feature	AWS VPC CNI
IP assignment	Native VPC secondary IPs from ENIs
Overlay	✗ None — native VPC routing
NetworkPolicy	✗ Not built-in — requires Calico or Cilium add-on
Security Groups	✅ Security Groups for Pods (SGP) — per-pod AWS SGs
IPv6	✅ Supported
Prefix delegation	✅ /28 prefix per ENI (more pods per node)
Windows nodes	✅ Supported
Custom networking	✅ Pods in different subnet than node
eBPF acceleration	✅ via Cilium add-on (EKS + Cilium mode)

Enabling Network Policy on EKS:
AWS VPC CNI itself does not enforce NetworkPolicy. You must add one of:

Calico (most common) — install as an add-on alongside vpc-cni
Cilium in chained mode — replaces policy enforcement, keeps VPC IP routing
Amazon VPC CNI Network Policy (AWS-native, GA as of 2024) — uses eBPF for policy enforcement

# Enable AWS-native network policy controller (EKS add-on)
aws eks create-addon \
  --cluster-name my-cluster \
  --addon-name vpc-cni \
  --configuration-values '{"nodeAgent":{"enablePolicyEventLogs":"true"}}'

When to choose AWS VPC CNI:

✅ Running EKS — it is the default and AWS-managed
✅ Need pods directly reachable from on-premises via Direct Connect / VPN
✅ Need per-pod AWS Security Groups (SGP feature)
✅ Compliance requires no overlay network
⚠️ Watch instance type ENI limits for large pod densities

3.2 Azure CNI — AKS Default

Azure Kubernetes Service (AKS) offers multiple CNI modes. The default for most production clusters is Azure CNI, which assigns pod IPs directly from the Azure Virtual Network (VNET) subnet — similar in concept to AWS VPC CNI but using Azure's networking primitives.

AKS CNI Modes:

Mode	Description	Default?
kubenet	Basic overlay; nodes get VNET IPs, pods get private overlay IPs (NAT)	Legacy default
Azure CNI	Pods get real VNET IPs from a pre-allocated subnet	Current recommended default
Azure CNI Overlay	Pods get overlay IPs (larger scale, fewer VNET IPs needed)	Recommended for large clusters
Azure CNI + Cilium	Azure CNI routing + Cilium eBPF dataplane + Hubble	Recommended for policy/observability
Bring Your Own CNI	Disable Azure CNI; install Calico, Flannel, etc.	Advanced

Azure CNI (traditional):

AKS Worker Node (Azure VM)
    │
    ├── Primary NIC (node IP: 10.240.0.4)
    │      └── VNET: 10.240.0.0/16
    │
    └── Pod IPs pre-allocated from subnet:
           ├── 10.240.0.10 → Pod A
           ├── 10.240.0.11 → Pod B
           └── 10.240.0.12 → Pod C

azure-vnet (CNI plugin) programs routes in Azure SDN

Azure CNI Overlay (recommended for scale):
Introduced to solve IP exhaustion. Pods get IPs from a private overlay CIDR (e.g., 10.244.0.0/16) while nodes get real VNET IPs. Azure SDN handles the translation — no overlay encap at the packet level from the VM's perspective.

# Create AKS cluster with Azure CNI Overlay + Cilium dataplane
az aks create \
  --resource-group myRG \
  --name myAKS \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --network-dataplane cilium \
  --pod-cidr 192.168.0.0/16

Key features:

Feature	kubenet	Azure CNI	Azure CNI Overlay	Azure CNI + Cilium
Pod IPs	Overlay (NAT)	Real VNET IPs	Overlay (Azure SDN)	Overlay (Azure SDN)
IP exhaustion risk	Low	High	Low	Low
Direct pod routing	✗	✅	✅ (via Azure SDN)	✅
NetworkPolicy	Basic	Azure Network Policy / Calico	Azure NP / Calico	✅ Cilium (eBPF)
Windows nodes	✅	✅	✅	⚠️ Partial
Hubble observability	✗	✗	✗	✅
Max pods/node	110	250	250	250

Network Policy options on AKS:

Azure Network Policy Manager (NPM) — iptables-based, Azure-native, limited feature set
Calico — add-on, full L3/L4 policy, most commonly used
Cilium — available with Azure CNI Overlay mode, eBPF enforcement + Hubble

When to choose Azure CNI:

✅ Running AKS — Azure CNI Overlay is the modern recommended choice
✅ Need pods directly reachable from on-premises via ExpressRoute
✅ Want Hubble observability → use Azure CNI Overlay + Cilium dataplane
✅ Large clusters (100+ nodes) → use Overlay mode to avoid VNET IP exhaustion
⚠️ Traditional Azure CNI requires pre-allocating pod IPs per node — plan subnet size carefully

3.3 GKE Dataplane V2 — GKE Default

Google Kubernetes Engine (GKE) introduced Dataplane V2 in 2021, which is based on Cilium's eBPF engine. It is the default for new GKE clusters and brings production-grade eBPF networking, built-in NetworkPolicy enforcement, and a subset of Hubble observability — all managed by Google.

GKE networking modes:

Mode	Description	Default?
Legacy (iptables)	kube-proxy + iptables, no Dataplane V2	Older clusters
Dataplane V2	Cilium eBPF, managed by GKE, no full Cilium control plane	Default for new clusters
Dataplane V2 + Hubble	Same + network telemetry via Hubble	Optional add-on

Architecture:

GKE Node (GCE VM)
    │
    ├── Alias IP range (VPC-native pod CIDRs)
    │     Pods get real VPC IPs, routed via Google SDN
    │
    └── Dataplane V2 (Cilium eBPF engine)
           ├── TC eBPF hooks on veth interfaces
           ├── BPF maps for policy, NAT, LB
           ├── kube-proxy replaced by eBPF
           └── Hubble telemetry (if enabled)

GKE uses VPC-native networking (alias IP ranges) — pods get real VPC CIDRs routed natively through Google's Andromeda SDN. Dataplane V2 sits on top, adding eBPF policy enforcement and observability.

Enabling Dataplane V2 on GKE:

# Create GKE cluster with Dataplane V2 (default for new clusters)
gcloud container clusters create my-cluster \
  --enable-dataplane-v2 \
  --enable-ip-alias \
  --location us-central1

# Enable Hubble observability add-on
gcloud container clusters update my-cluster \
  --enable-dataplane-v2-flow-observability \
  --location us-central1

Key features:

Feature	GKE Dataplane V2
Dataplane	Cilium eBPF (managed subset)
kube-proxy replacement	✅ eBPF
NetworkPolicy	✅ eBPF-enforced (L3/L4)
FQDN policy	✅ (GKE 1.28+)
Hubble observability	✅ Optional add-on
L7 policy	⚠️ Not exposed (managed limitations)
Pod IPs	Real VPC IPs (alias ranges)
Windows nodes	✅
Multi-cluster	✅ via GKE Fleet / Anthos
Managed lifecycle	✅ Google manages upgrades

Dataplane V2 vs self-managed Cilium on GKE:

Aspect	GKE Dataplane V2	Self-managed Cilium on GKE
Management	Google-managed	You manage Helm values/upgrades
Feature exposure	Subset of Cilium	Full Cilium feature set
Hubble	Basic (add-on)	Full Hubble UI + Relay
Cluster Mesh	✗ (use GKE Fleet)	✅
L7 CNP	✗	✅
Support	GKE SLA	Community / Isovalent

💡 GKE Recommendation: For most workloads, Dataplane V2 is the right choice — Google manages it, it's eBPF-based, and it covers L3/L4 policy. If you need full CiliumNetworkPolicy L7 rules or Cluster Mesh, consider self-managed Cilium on GKE with --network-plugin=cni and disabling kube-proxy.

When to choose GKE Dataplane V2:

✅ Running GKE — it is the default and Google-managed
✅ Want eBPF performance without managing Cilium yourself
✅ NetworkPolicy enforcement at scale (eBPF O(1) lookups)
✅ Need basic Hubble network telemetry
⚠️ For full L7 policy or Cluster Mesh, self-manage Cilium on GKE instead

4. Data Plane Comparison

Service Scalability — All CNIs

Services	Flannel (iptables)	Calico (iptables)	Calico (eBPF)	Cilium (eBPF)	AWS VPC CNI	Azure CNI	GKE DPv2
100	~10 ms	~10 ms	< 1 ms	< 1 ms	~10 ms	~10 ms	< 1 ms
1,000	~80 ms	~80 ms	< 1 ms	< 1 ms	~80 ms	~80 ms	< 1 ms
10,000	~800 ms	~800 ms	< 1 ms	< 1 ms	~800 ms	~800 ms	< 1 ms
50,000	⚠️ drops	⚠️ drops	< 1 ms	< 1 ms	⚠️ drops	⚠️ drops	< 1 ms

5. Network Policy

Policy Feature Comparison

Policy Feature	Flannel	Calico	Cilium	Weave	Antrea	AWS VPC CNI	Azure CNI	GKE DPv2
Standard NetworkPolicy	✗	✅	✅	✅	✅	✅ (add-on)	✅	✅
Egress Policy	✗	✅	✅	✅	✅	✅	✅	✅
GlobalNetworkPolicy	✗	✅	✅ CCNP	✗	✅ ClusterNetworkPolicy	✗	✗	✗
FQDN / DNS policy	✗	✅	✅	✗	✅	✗	✗	✅ (1.28+)
L7 HTTP method/path	✗	⚠️ ALP	✅ no sidecar	✗	✗	✗	✗	✗
Kafka / gRPC policy	✗	✗	✅	✗	✗	✗	✗	✗
Tiered policy	✗	✗	✗	✗	✅	✗	✗	✗
Security Groups (cloud)	✗	✗	✗	✗	✗	✅ SGP	✅ NSG	✅ Firewall rules

6. Observability

Feature	Flannel	Calico	Cilium	Weave	Antrea	AWS VPC CNI	Azure CNI	GKE DPv2
L3/L4 flow logs	✗	✅	✅	✗	✅	✅ VPC Flow Logs	✅ NSG Flow Logs	✅
L7 HTTP flows	✗	✗ (OSS)	✅	✗	✗	✗	✗	✗
Live service map	✗	✗	✅ Hubble UI	✗	✅ Octant	✗	✗	✅ (add-on)
Drop reason	✗	✅	✅	✗	✅	⚠️	⚠️	✅
Prometheus metrics	Basic	✅	✅ Rich	✅ Basic	✅	✅ CloudWatch	✅ Azure Monitor	✅
Built-in UI	✗	✗ (OSS)	✅ Hubble UI	✗	✅ Octant	✅ CloudWatch	✅ Azure Monitor	✅ Cloud Console

7. Performance Benchmarks

TCP Throughput — iperf3, Pod-to-Pod Same Node

CNI	Mode	Throughput
Flannel	VXLAN	~8 Gbps
Flannel	host-gw	~9.5 Gbps
Calico	BGP direct (iptables)	~9.3 Gbps
Calico	BGP direct (eBPF)	~9.7 Gbps
Cilium	GENEVE tunnel	~8.5 Gbps
Cilium	native-routing	~9.8 Gbps
Cilium	XDP	line rate
AWS VPC CNI	Native VPC routing	~9.5 Gbps
Azure CNI	Native VNET routing	~9.4 Gbps
GKE Dataplane V2	Alias IP + eBPF	~9.7 Gbps

⚠️ Results are representative — hardware, kernel version, and NIC driver all affect real-world numbers.

p99 Latency — Same Node

CNI	Mode	p99 Latency
Flannel	VXLAN	~0.35 ms
Flannel	host-gw	~0.18 ms
Calico	BGP direct (eBPF)	~0.15 ms
Cilium	native-routing	~0.16 ms
AWS VPC CNI	Native	~0.17 ms
Azure CNI	Native	~0.18 ms
GKE Dataplane V2	eBPF	~0.15 ms

8. Encryption

Feature	Flannel WG	Calico WG	Cilium WG	Cilium IPsec	Antrea WG/IPsec	AWS CNI	Azure CNI	GKE DPv2
Cross-node encryption	✅	✅	✅	✅	✅	✅ (NLB/TLS)	✅ (Azure Firewall)	✅ (WireGuard, beta)
Same-node encryption	✗	✅ (v3.26+)	✅	✅	✅	✗	✗	✗
Strict drop mode	✗	✗	✅	✅	✗	N/A	N/A	✗
Auto key rotation	✗	✅	✅	✅	✅	Managed	Managed	Managed
FIPS compliance	✗	✗	✗	✅	✅ IPsec	✅ (AWS FIPS)	✅ (Azure FIPS)	✅ (Google FIPS)

9. Multi-Cluster

Feature	Flannel	Calico	Cilium	Antrea	AWS EKS	Azure AKS	GKE
Native multi-cluster	✗	✅ BGP	✅ Cluster Mesh	✅ Antrea Multi-cluster	✅ EKS Connector	✅ AKS Fleet	✅ GKE Fleet
Unified service DNS	✗	✗	✅	✅	⚠️ (manual)	⚠️ (manual)	✅ (Anthos)
Cross-cluster NetworkPolicy	✗	✗ (OSS)	✅	✅	✗	✗	✅ (Anthos)
Cross-cluster observability	✗	✗	✅ Hubble	✅	✅ CloudWatch	✅ Azure Monitor	✅ Cloud Ops
Max clusters	—	Unlimited	255	Unlimited	Unlimited	Unlimited	Unlimited

10. Resource Usage

Resource	Flannel	Calico	Cilium	Weave	Antrea	AWS VPC CNI	Azure CNI	GKE DPv2
DaemonSet CPU (idle)	~5 mCPU	~20–60 mCPU	~30–80 mCPU	~10–30 mCPU	~20–50 mCPU	~10–25 mCPU	~10–30 mCPU	~30–80 mCPU
DaemonSet RAM (idle)	~30 MB	~60–150 MB	~100–300 MB	~50–100 MB	~50–100 MB	~30–80 MB	~40–80 MB	~100–300 MB
Startup time	~5s	~10–20s	~30–60s	~10s	~10–15s	~5–10s	~5–10s	Managed
Additional CRDs	0	~8	~15	0	~10	0–2	0	0
Minimum kernel	Any	Any / ≥5.3 (eBPF)	≥4.9	Any	Any	Any	Any	GKE-managed
Operator required	✗	✅ tigera	✅ cilium-operator	✗	✅ antrea-controller	AWS-managed	Azure-managed	GKE-managed

11. Full Feature Comparison

Dimension	Flannel	Calico	Cilium	Weave	Antrea	AWS VPC CNI	Azure CNI	GKE DPv2
Data plane	Bridge + iptables	BGP + iptables/eBPF	eBPF kernel-native	Mesh sleeve/VXLAN	OVS	VPC native	VNET native	eBPF (Cilium)
kube-proxy replacement	✗	✅ (eBPF)	✅	✗	✅ AntreaProxy	✗	✗	✅
Encapsulation	VXLAN	None/IPIP/VXLAN	GENEVE	Sleeve/VXLAN	Geneve/VXLAN	None	None	None
BGP routing	✗	✅ native	✅ optional	✗	✗	✗	✗	✗
L3/L4 NetworkPolicy	✗	✅	✅	✅	✅	✅ (add-on)	✅	✅
L7 HTTP/gRPC policy	✗	⚠️ ALP	✅ no sidecar	✗	✗	✗	✗	✗
FQDN-based policy	✗	✅	✅	✗	✅	✗	✗	✅ (1.28+)
GlobalNetworkPolicy	✗	✅	✅ CCNP	✗	✅ CNP	✗	✗	✗
Flow observability	✗	✅ flow logs	✅ Hubble	✗	✅ Octant	✅ VPC Flow	✅ NSG Flow	✅
L7 flow visibility	✗	✗ (OSS)	✅	✗	✗	✗	✗	✗
Cross-node encryption	✅ WG	✅ WG	✅ WG/IPsec	✅ NaCl	✅ WG/IPsec	Cloud-layer	Cloud-layer	✅ WG (beta)
Same-node encryption	✗	✅ (v3.26+)	✅	✗	✅	✗	✗	✗
FIPS encryption	✗	✗	✅ IPsec	✗	✅ IPsec	✅ (AWS)	✅ (Azure)	✅ (GCP)
Multi-cluster	✗	✅ BGP	✅ Cluster Mesh	✗	✅	EKS Fleet	AKS Fleet	GKE Fleet
Windows nodes	⚠️	✅ HNS	✗	✗	✅	✅	✅	✅
Cloud default	K3s	Manual	GKE	Manual	Manual	EKS	AKS	GKE
RAM per node (idle)	~30 MB	~60–150 MB	~100–300 MB	~50–100 MB	~50–100 MB	~30–80 MB	~40–80 MB	~100–300 MB
Operational complexity	Very low	Medium	Medium–High	Low	Medium	Low (managed)	Low (managed)	Low (managed)
Active development	✅	✅	✅	⚠️ Archived	✅	✅	✅	✅

12. When to Choose Each

🟢 Choose Flannel when…

✅ Dev, CI, or home lab cluster with no production traffic
✅ No NetworkPolicy requirement whatsoever
✅ RAM-constrained nodes (Raspberry Pi, 1 GB edge devices)
✅ You want the absolute lowest operational overhead
✅ Running a legacy kernel (RHEL 7 / CentOS 7)
✅ Already using a service mesh (Istio, Linkerd) for policy and observability

🟠 Choose Calico when…

✅ NetworkPolicy is required and Cilium feels like overkill
✅ You need BGP peering with upstream physical routers
✅ Windows nodes exist in your cluster
✅ No-encap direct routing is preferred for performance
✅ Your team already has Calico expertise
✅ Medium cluster size (10–200 nodes) with moderate policy complexity

🔵 Choose Cilium when…

✅ L7 HTTP/gRPC/Kafka policy without a service mesh sidecar
✅ Hubble observability and a live service map are needed
✅ 100+ services with high service churn (eBPF O(1) matters)
✅ End-to-end pod traffic encryption including same-node
✅ Multi-cluster federation with unified DNS and policy
✅ Building toward zero-trust networking inside the cluster

🟡 Choose Weave when…

⚠️ Generally not recommended for new clusters — Weaveworks is archived
✅ Only if migrating from an existing Weave deployment with no immediate migration path
✅ Simple overlay needed with built-in NaCl encryption (short term)

🟣 Choose Antrea when…

✅ VMware NSX-T / Tanzu environment requiring deep SD-WAN integration
✅ Tiered network policy enforcement (Emergency / Security / Application tiers)
✅ Windows and Linux mixed clusters in an enterprise VMware stack
✅ OVS dataplane is a hard requirement (telco, NFV)

🔶 Choose AWS VPC CNI (EKS) when…

✅ Running EKS — it is the default AWS-recommended CNI
✅ Pods must be natively routable across VPC, VPN, or Direct Connect
✅ Per-pod AWS Security Groups are required (SGP feature)
✅ Compliance mandates no overlay network
✅ Integrate with AWS services that need pod-level VPC routing

🔷 Choose Azure CNI (AKS) when…

✅ Running AKS — use Azure CNI Overlay mode for most production workloads
✅ Pods need to be reachable from on-prem via ExpressRoute
✅ Want eBPF performance + Hubble → choose Azure CNI Overlay + Cilium dataplane
✅ Large clusters → Azure CNI Overlay avoids VNET IP exhaustion
✅ Windows node support is required (all Azure CNI modes support it)

♦️ Choose GKE Dataplane V2 (GKE) when…

✅ Running GKE — it is the default for new clusters
✅ Want eBPF-based policy without managing Cilium yourself
✅ Need Hubble network telemetry (enable as add-on)
✅ FQDN-based NetworkPolicy (GKE 1.28+)
✅ Google-managed lifecycle and upgrades are preferred
⚠️ For L7 CNP or Cluster Mesh, self-manage Cilium on GKE instead

13. K3s-Specific Setup

Flannel — Built-In, Nothing to Do

# Flannel ships with K3s — just install
curl -sfL https://get.k3s.io | sh -

# Change backend in /etc/rancher/k3s/config.yaml
flannel-backend: host-gw   # vxlan | host-gw | wireguard-native | none

Installing Calico on K3s

Step 1 — Install K3s without Flannel:

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--flannel-backend=none \
  --disable-network-policy \
  --cluster-cidr=192.168.0.0/16" sh -

Step 2 — Install Calico operator:

kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/tigera-operator.yaml

Step 3 — Apply Installation CR:

apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  calicoNetwork:
    ipPools:
    - cidr: 192.168.0.0/16
      encapsulation: VXLANCrossSubnet
      natOutgoing: Enabled

Installing Cilium on K3s

Step 1 — Install K3s without Flannel:

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--flannel-backend=none \
  --disable-network-policy \
  --disable=servicelb" sh -

Step 2 — Install Cilium via Helm:

helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set operator.replicas=1 \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=<YOUR_K3S_API_IP> \
  --set k8sServicePort=6443 \
  --set bpf.masquerade=true \
  --set ipam.mode=kubernetes

Minimum Kernel Requirements

Feature	Cilium	Calico eBPF
Basic CNI	≥ 4.9	Any
kube-proxy replacement	≥ 5.2	≥ 5.3
WireGuard encryption	≥ 5.6	≥ 5.6
XDP acceleration	≥ 5.10	≥ 5.10

✅ Ubuntu 22.04 ships kernel 5.15, Debian 12 ships 6.1, Raspberry Pi OS Bookworm ships 6.1 — all satisfy every requirement.

14. Migration Guide on K3s

All migrations follow the same pattern:

drain → clean CNI state → restart K3s with --flannel-backend=none → install new CNI → uncordon

Flannel → Calico

# Step 1: Drain the node
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data

# Step 2: Remove Flannel state on the node
systemctl stop k3s
ip link delete flannel.1 2>/dev/null || true
ip link delete cni0 2>/dev/null || true
rm -rf /var/lib/cni /etc/cni/net.d

# Step 3: Set flannel-backend: none in /etc/rancher/k3s/config.yaml, then restart
systemctl start k3s

# Step 4: Install Calico operator
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/tigera-operator.yaml

# Step 5: Uncordon
kubectl uncordon <node>

Flannel → Cilium

# Steps 1–3 same as above (drain, clean, restart with flannel-backend=none)

# Step 4: Install Cilium
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=<API_IP> \
  --set k8sServicePort=6443

# Step 5: Uncordon
kubectl uncordon <node>

💡 Pro Tip: For single-node K3s lab environments, a clean reinstall is always faster and safer than a live migration. Run k3s-uninstall.sh, reinstall with the correct flags, then Helm install your chosen CNI — total time is about 10 minutes.

15. Conclusion

Open-Source CNIs

🟢 Flannel — A masterpiece of minimalism. One job, done perfectly, with near-zero operational overhead. The right choice when simplicity and RAM constraints matter more than policy or observability.
🟠 Calico — The policy-first CNI. BGP-native routing, mature L3/L4 NetworkPolicy, Windows node support, and a pluggable data plane. The right choice when you need robust policy enforcement, prefer no-encap routing, or operate in an environment with existing BGP infrastructure.
🔵 Cilium — The platform CNI. eBPF-native with O(1) service lookup, L7-aware policy with no sidecar, Hubble observability, full pod-traffic encryption, and Cluster Mesh multi-cluster. The most capable networking layer available in Kubernetes today.
🟡 Weave Net — Once a popular choice for simplicity and built-in encryption. Now archived — migrate to Cilium or Calico for any new or long-running cluster.
🟣 Antrea — The VMware-native CNI. OVS dataplane, tiered policy, Windows support, and NSX-T integration. The right choice in Tanzu or NSX environments.
🔷 Multus — Not a CNI replacement but a CNI multiplier. Essential for telco/NFV workloads needing multiple pod network interfaces.

Cloud Provider CNIs

🔶 AWS VPC CNI (EKS) — Native VPC IP assignment with no overlay. Pods are first-class VPC citizens. Add Calico or the AWS-native policy controller for NetworkPolicy. Choose prefix delegation for high pod density.
🔷 Azure CNI (AKS) — Use Azure CNI Overlay for most production workloads to avoid IP exhaustion, and add the Cilium dataplane for eBPF policy + Hubble observability. Azure CNI traditional still works, but requires careful subnet pre-planning.
♦️ GKE Dataplane V2 (GKE) — Google's managed Cilium eBPF layer. The default for new GKE clusters. Handles NetworkPolicy at scale with eBPF O(1) lookups. Add the Hubble observability add-on for network telemetry. Self-manage Cilium on GKE only if you need L7 CNP or Cluster Mesh.

Bottom line: If you run a managed Kubernetes service, use the cloud-default CNI and layer policy/observability on top. If you run self-managed clusters, Cilium is the most capable long-term investment, with Calico as the pragmatic choice if BGP integration or Windows nodes are required.

The networking layer of your cluster is not where you want to cut corners at scale.
Choose based on where your cluster is going — not just where it is today.

⚖️ Case File 2.1: The Prompt-and-Pray Conspiracy

Manoj Mishra — Tue, 12 May 2026 03:30:00 +0000

The AI Syndicate

AI doesn't make you a better engineer; it makes you a faster version of whoever you already are. If you’re a "Software Criminal," it just makes you a Serial Offender.

In our transition to Agentic Development, we’ve entered a dangerous era. With 17+ years in tech, I’ve seen the shift from "copying from StackOverflow" to "prompting an LLM." The difference? AI produces "plausible-looking" code at machine speed. This is the Prompt-and-Pray Conspiracy, and it is the fastest way to lose your technical authority.

🎭 The Crime: The Black-Box Handover

If you can't explain the code the AI wrote, you didn't "build" it—you just found it.

The Scenario: A developer uses an AI agent to generate a complex data transformation logic involving multiple streams and nested loops.
The Crime: Copying the generated code directly into the PR without stepping through the logic to understand the time complexity ($O(n^2)$ vs $O(n)$).
The Brutality: The code works in staging with small datasets but causes a memory leak and production timeout when the first 100k records hit. The developer is unable to debug it because they don't understand the "black-box" logic.
How to Avoid It: Treat AI as a junior intern, not a senior architect. Every line it writes must be vetted by your brain as if you were doing a hostile code review.
Brutal Habit to Adopt: The Verification Loop. Never merge AI code until you can manually trace the data path and explain the "Why" behind every generated abstraction.

"Own the Output."

🤖 The Crime: The "LGTM" for Agents

Trusting an AI to review an AI is like letting two toddlers guard the cookie jar.

The Scenario: A team sets up an automated AI agent to review Pull Requests. The agent checks for linting and syntax but misses a critical logical flaw in the transaction management.
The Crime: Delegating the "Human Judgment" of a code review to a model that only understands patterns, not business consequences.
The Brutality: The "clean" code is merged, leading to partial database writes because the AI didn't catch that the @Transactional annotation was on a private method (a common Java pitfall).
How to Avoid It: Automated tools are for syntax; humans are for semantics. Use AI to find typos, but never let it sign off on logic.
Brutal Habit to Adopt: The Manual Intercept. Even if an AI agent gives a "Green Check," a human architect must perform a high-level logic verification before any merge to the main branch.

"Judgment is Non-Transferable."

🧩 The Crime: The Context Collapse

AI is brilliant at functions but blind to systems.

The Scenario: A developer prompts an AI to "optimize this specific function" in a high-concurrency microservice.
The Crime: Implementing a local optimization (like adding a local cache) while ignoring the global system impact (cache inconsistency across multiple nodes).
The Brutality: The function is now 5x faster, but the system starts returning stale data, leading to financial discrepancies that take weeks to reconcile.
How to Avoid It: Before applying an AI suggestion, zoom out. Ask: "How does this local change affect the upstream database and downstream services?"
Brutal Habit to Adopt: The Context Anchor. Before you prompt, define the system constraints (Concurrency, Latency, Consistency). If the AI response ignores these anchors, discard it.

"System Over Syntax."

🛠️ Case File Takeaway: The "Logic First" Rule

AI should be the last step in your process, not the first.

💡 Professional Tip: When faced with a complex task, design the logic on paper first. Map out the input, the transformation, and the expected output. Once your "Paper Model" is solid, use the AI only to generate the boilerplate. If the AI’s logic differs from your paper model, the AI is wrong until proven otherwise.

📋 Cheat Sheet: The AI Syndicate

[The Prompt-and-Pray Conspiracy]

The Crime	The Red Flag	The Fix	Mnemonic	Brutal Habit to Adopt
Black-Box Handover	"I'm not sure how this part works."	Trace every line manually.	Own the Output	Verification Loop
Agent LGTM	"The AI said the PR is fine."	Logic reviews are human-only.	Judgment is Non-Transferable	Manual Intercept
Context Collapse	"It works for this function."	Check upstream/downstream impact.	System Over Syntax	Context Anchor

Next Drop: We move to Case File 2.2: The Stagnation Syndicate, where we discuss the crime of using outdated patterns in a modern, agentic world.

What’s the most "confident" but completely wrong code an AI has ever given you?

💬Let’s talk in the comments.

Migrating Off Google Analytics: Umami vs Plausible vs Fathom

Alan West — Tue, 12 May 2026 03:18:38 +0000

The wake-up call I didn't ask for

Last week the TanStack folks reported what appears to be a compromise affecting some of their NPM packages (the details are still being sorted out in issue #7383 — read it yourself before drawing conclusions). I won't rehash the postmortem here. What I want to talk about is the gut-punch feeling I had reading it.

I run npm install every day. I've barely thought about which third-party scripts are loading in production. And one of the worst offenders sitting in nearly every site I've ever shipped? Analytics.

So this post is about something I've been chewing on for months but finally moved on: ripping Google Analytics out of three side projects and picking a privacy-focused alternative. Specifically, I'll compare Umami, Plausible, and Fathom — the three I actually evaluated — and walk through the migration steps that worked for me.

Why even migrate?

A few honest reasons, none of them ideological:

Script weight. GA4's gtag.js is heavy. The privacy-focused tools are typically 1–2 KB.
Cookie banners. No cookies = no consent banner in most jurisdictions. Fewer modals = fewer bounces.
Vendor trust. After watching a supply chain story unfold in real time, having fewer third-party scripts feels less reckless.
Self-hosting option. If I can run it on my own infra, I control the script.

If you genuinely need Google's audience features (remarketing, conversion linking to Google Ads), this post probably isn't for you. Stay where you are.

The contenders

Plausible

Open source (AGPL), GDPR/CCPA compliant, cloud or self-hosted. The script is small — the docs claim under 1 KB. Written in Elixir. Cloud plans are subscription-based.

Fathom

Privacy-focused, cloud-only since they pivoted from the original open source v1 ("Fathom Lite," archived) to a commercial closed-source product. I evaluated the commercial product.

Umami

Open source (MIT), self-hosted by default with a hosted cloud option on umami.is. Built on Next.js, runs on PostgreSQL or MySQL. Free if you host it yourself. Easy enough that I had it running in an evening.

Side-by-side

I'll keep this honest — I ran all three on the same site for two weeks before deciding.

Feature	Plausible	Fathom	Umami
Open source	Yes (AGPL)	No (closed)	Yes (MIT)
Self-host	Yes	No	Yes (primary path)
Cookies	No	No	No
GDPR	Yes	Yes	Yes
Cloud option	Paid	Paid	Free tier + paid
Script size	~1 KB	~2 KB	~2 KB
Funnels / goals	Yes	Yes	Yes (basic)

The sizes above match what I observed in the network tab, but check each vendor's docs before quoting them anywhere serious.

What the snippets look like

Replacing GA is mostly about swapping a script tag. Here's the before:

<!-- Google Analytics (the thing we're leaving) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXX'); // sends pageview + sets cookies
</script>

And the replacements:

<!-- Plausible (cloud) -->
<script defer data-domain="example.com"
        src="https://plausible.io/js/script.js"></script>

<!-- Fathom -->
<script src="https://cdn.usefathom.com/script.js"
        data-site="ABCDEFG" defer></script>

<!-- Umami (self-hosted) -->
<script defer src="https://analytics.mydomain.com/script.js"
        data-website-id="your-website-id"></script>

That's it. No dataLayer. No consent banner gate. The script loads once, sends a single beacon per pageview, and stops bothering you.

Custom events

The thing I almost forgot when migrating: GA's gtag('event', ...) calls. Here's how I rewrote them for Umami (the APIs are similar across the three, but each has its own conventions):

// Before (GA4)
gtag('event', 'signup_completed', {
  plan: 'pro',
  source: 'pricing_page'
});

// After (Umami)
// `umami` is attached to window by the loader script
window.umami?.track('signup_completed', {
  plan: 'pro',
  source: 'pricing_page'
});

Plausible uses window.plausible('signup_completed', { props: { plan: 'pro' } }). Fathom uses fathom.trackEvent('signup_completed'). Don't do a global find-and-replace — the property conventions differ enough that you'll want to read each vendor's docs first.

Self-hosting Umami in five minutes

This is the part that sold me. Here's the docker-compose.yml running on the VPS for one of my side projects:

services:
  umami:
    image: ghcr.io/umami-software/umami:postgresql-latest
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: postgresql://umami:umami@db:5432/umami
      DATABASE_TYPE: postgresql
      APP_SECRET: change-me-to-a-real-secret # rotate this
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_DB: umami
      POSTGRES_USER: umami
      POSTGRES_PASSWORD: umami
    volumes:
      - umami-db:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U umami"]

volumes:
  umami-db:

Run it behind Caddy or Nginx, point a subdomain at it, drop the script tag into your site. You own the data. Nothing leaves your server. The dashboard is genuinely pleasant — the Next.js UI loads fast and shows the things I actually look at.

Migration steps that worked

No magic, just mechanical:

Inventory your GA calls. Grep your codebase for gtag(, dataLayer, and any analytics wrapper functions. Write them down.
Pick your destination. Zero ongoing cost and own your data → self-hosted Umami. Don't want to run Postgres → Plausible Cloud. Want the most polished commercial dashboard → Fathom.
Run them in parallel for a week. Drop the new script alongside GA. Compare daily pageview counts. You'll see drift — the privacy-focused tools usually report fewer visits because they don't fingerprint, and that's kind of the point.
Rewrite custom events. Map each gtag('event', ...) to the new API. Wrap them in a helper so you can switch again later without grepping.
Remove the GA script and the cookie banner. This is the satisfying part.

My recommendation

Honestly? Here's how I'd choose:

Side projects, solo devs: Self-hosted Umami. Free, simple, MIT-licensed.
Small business, no ops appetite: Plausible Cloud. Easiest onboarding, still open source if you ever want to migrate off.
Polished dashboards for clients: Fathom. The UX feels the most "finished" of the three.

I'm not saying Google Analytics is bad — it's free, it's powerful, and it's still the right answer if you live inside their ad ecosystem. But for the rest of us, three lines of script and a Postgres container will get you 90% of what you actually look at, with one less third-party domain in your Content-Security-Policy.

The TanStack situation reminded me that every script tag is a trust decision. Make fewer trust decisions.

Fixing XSLT Import Issues in MuleSoft (Works in Local but Fails in RTF Runtime)

sphurthi Edara — Tue, 12 May 2026 03:16:49 +0000

Fixing XSLT Import Issues in MuleSoft
(Works in Local but Fails in RTF Runtime)

Introduction
XSLT (Extensible Stylesheet Language Transformations) is used to transform XML data from one format into another during application integrations.
While working on a MuleSoft integration project, I faced a challenging issue where the XSLT transformation worked perfectly in Anypoint Studio (local environment) but failed after deployment to Runtime Fabric (RTF).
After trying multiple approaches and finding very limited documentation for this issue, I was able to identify the root cause and implement a working solution. In this article, I will explain the issue, failed approaches, and the final solution that resolved it successfully.

🔹 Scenario
I had:
• A parent XSLT file
• One or more child XSL files
• Requirement: Import child XSL inside the parent and perform transformation

🔹 Local Setup vs Runtime Issue
• Both the parent and child XSL files were stored under:
src/main/resources/xslt/

In the General section, I used:
• Content → Passed the payload to be transformed
• XSLT → Referenced the parent XSL file using:
${file::xslt/parent.xsl}

• Inside the parent XSL, I imported the child XSL using:

📸 (Refer to the screenshot above for the exact configuration)

👉 With this setup, the transformation worked perfectly in the local environment (Anypoint Studio).

🔴 Issue in Runtime Fabric (RTF)

However, when the same application was deployed to the RTF (Runtime Fabric) environment, the transformation failed with the following error:

[2026-04-21 17:50:36.966] ERROR DefaultExceptionListener [[MuleRuntime].uber.03: [test].test.CPU_INTENSIVE @65f712f4] [event: ]:

Message : I/O error reported by XML parser processing file:/apps/test/xslt/xsl/child.xsl: /apps/test/xslt/xsl/child.xsl (No such file or directory)

💡 Why This Happens

In Anypoint Studio (local):
• Mule can resolve ${file::} paths directly from the filesystem

In RTF (runtime):
• Resources are packaged inside the application JAR
• Mule uses classpath-based resolution, not filesystem paths

👉 That’s why the child XSL cannot be found in runtime

🔴 Failed Approaches
I tried multiple approaches, but none worked:

Using classpath inside parent XSL

❌ Error:

Message : I/O error reported by XML parser processing classpath:/xslt.xsl/child.xsl: unknown protocol: classpath
Using relative path

❌ Error:

Message : I/O error reported by XML parser processing file:/tmp/child.xsl: /tmp/child.xsl (No such file or directory)
Using absolute path

*Both child and parent xsl are in same xslt folder unser src/main/resoucrces.
❌ Error:

Message : I/O error reported by XML parser processing file:/xslt/child.xsl: /xslt/child.xsl (No such file or directory)

✅ Final Working Solution
The solution was a combination of correct XSLT reference + classpath usage + dependency alignment.
✔ Step 1: Change how parent XSL is referenced
Instead of using ${file::...}, declare XSL directly in the XSLT component:
xml-module:xslt
<![CDATA[]]>
/xml-module:xslt

✔ Step 2: Use classpath inside parent XSL

👉 This ensures Mule runtime correctly resolves resources from the classpath.

✔ Step 3: Ensure correct folder structure
src/main/resources/xslt/
└── child.xsl

✔ Step 4: Match Mule XML Module dependency with runtime

org.mule.modules
mule-xml-module
1.4.3
mule-plugin

👉 Important: Dependency version must align with your Mule runtime.
• Runtime used: 4.10.2
• Module version: 1.4.3

💡 Bonus Insight
This solution also works when:
• You have multiple child XSL files
• Complex transformations with nested imports
I tested this with multiple child XSLs, and it worked consistently in both:
• Local (Studio)
• RTF Runtime

🔹 Conclusion
This issue is not well documented, and it can be frustrating when something works locally but fails in runtime.
• By correctly using classpath-based imports and aligning dependencies, you can ensure consistent XSLT execution across environments.
• I hope this helps anyone facing similar issues and saves valuable debugging time.

✍️ Author
Sphurthi Edara
MuleSoft Developer
Connect with me on LinkedIn:
https://www.linkedin.com/in/sphurthi-edara/

DEV Community

I Built a Random Word Generator… Then Realized How Often People Get Stuck

🚨 The Problem Wasn’t “Lack of Ideas”

😐 The Funny Part?

💡 Why I Built This Tool

🧠 What I Realized

⚡ The Real Frustration

🔍 Why Random Inputs Actually Help

😬 Where Most Tools Feel Wrong

🔥 What I Focused On

📈 What Surprised Me

🤯 The Real Insight

🧩 Simple Rule I Follow Now

🚀 Final Thought

A Physics-Aware React Design System for Modern Frontend Architecture

Introduction

The Problem with Most Component Libraries

1. Styling Becomes Fragile

2. Components Are Not Truly Reusable

3. Most Design Systems Ignore Motion

The Vision Behind Atomix

Core Principles

1. Architecture First

2. Accessibility by Default

3. Performance Matters

4. Motion Is Part of the System

AtomixGlass

AtomixGlass — Building a Physics-Reactive Glassmorphism Engine

What AtomixGlass Does

Rendering Modes

Standard Mode

Polar Mode

Prominent Mode

Shader Mode

Physics-Aware Interaction

Accessibility and Motion

Building the Theme Engine

Token-Based Theming

Runtime Theme Injection

Why ITCSS?

Utility Architecture

Tree-Shakable Architecture

Building the CLI Toolchain

Storybook-Driven Development

Component Philosophy

Charts as First-Class Components

Developer Experience Matters

Lessons Learned While Building Atomix

1. Consistency Beats Complexity

2. Motion Requires Restraint

3. Accessibility Must Exist From Day One

4. Architecture Is a Long-Term Investment

The Future of Atomix

Final Thoughts

Links

Run Claude Code Locally for Free with Docker Model Runner

Prerequisites

Getting Started

1. Choosing and pulling a local model

2. Checking the connection

3. Testing the endpoint

4: Pointing Claude Code at the local endpoint

5: Adding the Shell config

6. Using the Claude Code

6. Watching the requests flow

7: What next?

The Lie of Time Management: Why Your Energy is the Real Bottleneck

The Procrastination Myth

Silent Energy Drains for Developers

1. Context Switching and The "Quick Check"

2. The Morning Coffee Trap

3. Mental Load and Analysis Paralysis

How to Protect Your Currency

Day 15/45 — Building a Workforce Management SaaS in Public

Taskdudes #SaaS #WebDevelopment #SoftwareEngineering #NextJS #NestJS #PostgreSQL #Redis #BuildInPublic

Coding Cat Oran S2 Ep3 — The Auditor Arrives

Why does paying more make your LLM reply faster?

Reading the model's weights

Reading the KV Cache

A quick detour: the attention mechanism

Reading the `KV` Cache