DEV Community: Azad Shukor

Node Scaling and Pods Scaling Are Not The Same

Azad Shukor — Fri, 25 Sep 2026 06:36:41 +0000

the misunderstanding

pod autoscaling is different from node autoscaling. they both need different configurations and they solve different problems.

the imagination

to walkthrough this scenario, imagine a restaurant. for the restaurant to operate, we have 3 components. we have customers, chefs, and the restaurant itself.

each customer orders 1 food, and each chef can handle 5 orders. at a given moment, a restaurant can fit a maximum of 3 chefs because the kitchen only has 3 workstations.

the number of orders from customers refers to how much traffic we have, a chef is a pod, and the restaurant is a node.

now imagine we start with only 1 chef.

customers start coming in and the chef becomes busier. instead of waiting until the chef reaches the maximum 5 orders, the business owner sets an alarm. when the chef reaches around 3 out of 5 orders, the alarm goes off and the business owner hires another chef to help with the orders.

this is similar to HPA. when the pod reaches the CPU utilization target, HPA will increase the number of pods.

as more customers come in, the same thing happens again. eventually, we have 3 chefs working inside the restaurant.

now we have another problem.

the restaurant only has 3 workstations, and all 3 are already occupied. if more customers come in and the alarm says we need another chef, the business owner can hire the chef, but there is nowhere for the new chef to work.

this is where node autoscaling comes in.

because the new chef cannot find an available workstation, the business owner opens another restaurant with another 3 workstations. the new chef can then work inside the new restaurant.

so the important part is, more customers do not directly create another restaurant.

more customers increase the workload, the workload causes HPA to create more pods, and when there is no more space to run those pods, node autoscaling creates another node.

that is how pod and node autoscaling work together.

Error Handling for MCP

Azad Shukor — Thu, 24 Sep 2026 12:43:16 +0000

When you ask an MCP server to edit a file, the tool might fail. The error could happen because the command is wrong or the file does not exist.

To handle this, add a runtime instruction for when the tool returns an error.

For example, if you ask the MCP server to edit a file and it returns { "error": true }, the instruction could be: “Tell the user the edit failed and ask what to do next.”

That is one way to handle errors from an MCP server.

Identity-Driven Premature Closure: The PR Review Trap I Fell Into Every Day

Azad Shukor — Sat, 01 Aug 2026 05:09:15 +0000

I review a PR. The diff is small. I scroll until something catches my eye:

if (!person.Data) return empty;

I've seen patterns like this before. Something about it feels off. A familiar irritation rises — this ticket has been reopened multiple times. The developer has a history of missed scenarios. I don't trace the callers. I don't pull the branch. I don't read the full function. I post:

"Why isn't this checking .Data.name and returning 'anonymous'?"

Then I pull the code locally. I see the whole function — more lines, more context, the full shape. The logic becomes apparent. The guard clause is correct. The name replacement happens in the caller. The implementation follows best practice. I reply: "actually it is correct."

No apology. Just embarrassment. Again.

This happens on nearly every PR I review.

I called this laziness. I was wrong.

The Science Behind It

It's not laziness. It's identity-driven premature closure.

Three mechanisms converge:

1. Need for Cognitive Closure

In 1996, psychologist Arie Kruglanski defined the need for cognitive closure as the desire for "an answer on a given topic, any answer… compared to confusion and ambiguity" (Kruglanski & Webster, Psychological Review, 1996). It has two components:

Urgency tendency ("seizing"): the impulse to reach a conclusion as quickly as possible
Permanence tendency ("freezing"): the impulse to hold onto that conclusion once reached

When I see unfamiliar code in a narrow diff window, I feel confusion. Confusion is uncomfortable. My brain wants it resolved — fast. I seize on the first familiar pattern (return empty → "missing something"), freeze on it ("this is wrong"), and post.

The discomfort drives the speed. The speed prevents correction.

2. Confirmation Bias in Code Review

Devroey, Matton, and Vanderose (2024, arXiv:2407.01407) studied cognitive biases in code review. They found that confirmation bias — searching for evidence that supports your pre-existing belief — is especially strong when:

A reviewer identifies heavily with a "gatekeeper" role
The reviewer enters the review with expectations about the author

Both apply to me. I believe my job is to find what's wrong. I enter reviews of repeatedly-reopened tickets with a pre-existing story: "this developer doesn't check all scenarios." I don't read the code neutrally. I read it looking for a confirmation of that story — and I find one.

3. Identity-Protective Cognition

This is the deepest layer. Kunda (1990, Psychological Bulletin) showed that when reasoning touches self-concept, people don't just make errors — they're motivated to reach conclusions that protect their identity.

My identity is organized around being the person who catches bugs. Catching a real bug "feels the best." Finding clean code triggers embarrassment — because if the code is clean, then what value did I add? The review becomes less about code quality and more about proving I'm competent.

The quick criticism serves an identity function: it proves I'm doing my job. Even when it's wrong.

What Is the Proof?

Here is the chain — mapped from my own answers under direct questioning:

TRIGGER
  PR on a reopened ticket
  + Author with a bug history
  + Diff view that shows only fragments
        ↓
INTERNAL REACTION
  "Why is this still open?"
  + Identity activation: "I am the bug-catcher"
  + Irritation from missing context
        ↓
SHORTCUT
  Scroll until something familiar catches my eye
  + Familiarity feels like understanding (it isn't)
  + "I've been right before" → permission to trust my judgment
  + Skip: callers, tests, full function, pulling locally
        ↓
IMMEDIATE REWARD
  Temporary resolution of "what's my role?" anxiety
  + Relief from the discomfort of confusion
  + The possibility of that "best feeling" (catching a real bug)
        ↓
MISTAKE
  The code was correct. My criticism was based on a fragment.
  Flat retraction: "actually it is correct."
        ↓
LONG-TERM COST
  Embarrassment that compounds
  + Colleagues learn my reviews are unreliable
  + I model "criticize first, understand later"
  + I never practice reading unfamiliar code
  + Pattern repeats — every PR

The evidence is in the pattern, not a single incident

This isn't one bad review. It's every review. The behavior persists because it's intermittently reinforced. Some of my criticisms are correct — real bugs do slip through. That variable reward (the same mechanism that makes slot machines addictive) keeps the habit alive. Enough of my snap judgments are right that my brain keeps gambling on the next one.

The familiarity illusion

I mistook familiarity for understanding. Recognizing a code pattern feels like comprehending the logic — but it isn't. The narrower my view (a diff fragment vs. the full function), the more my brain fills gaps with assumptions. And those assumptions feel as solid as facts.

I learned this when I traced what happens when I pull the branch locally: more lines, more context, bigger view → the logic becomes apparent → the irritation disappears → "this code is correct." The diff physically hides the evidence that would disprove my assumption.

The irritation was never about the developer

Under questioning, this surfaced: the irritation I feel during review isn't about the developer. It's about missing context. I feel irritated because I'm looking at a fragment and my brain needs the whole shape to function. I misattribute that irritation to the developer — and criticize them instead of closing the context gap. When I pull the code and see the full function, the irritation vanishes. The developer didn't change. The context did.

How to Fix It

The goal isn't to stop having the impulse. The goal is to redirect it before it produces damage.

The method: "I Observed / I Expected / Help Me Understand"

Adapted from the SBAR communication framework used in aviation and medicine (Haig, Sutton, & Whittington, 2006), where structured communication reduces errors in high-stakes judgment.

Every review comment must include three fields:

I observed: [concrete line(s) from the diff — not your interpretation]
I expected: [what pattern you thought should be there]
Can you help me understand: [the flow, the reasoning, the missing context]

Why each field matters

Field	What it does
I observed	Forces you to name the actual code, not your story about it. The fragment becomes visible as a fragment — not as the whole truth.
I expected	Surfaces your assumption. Once written, you can see it's an assumption — not an observation. The gap between "I observed" and "I expected" is where your error lives.
Can you help me understand	Replaces accusation with inquiry. You're not a critic delivering a verdict. You're an understander who found a gap and wants to close it. This removes the identity threat for both you and the author.

Example: my own PR review, rewritten

Instead of:

"Why isn't this checking .Data.name and returning 'anonymous'?"

The method produces:

I observed: if (!person.Data) return empty — a guard clause checking Data, not the .name field.

I expected: to see a check for person.Data.name with an 'anonymous' fallback, since this ticket is about filling empty names.

Can you help me understand: where the name replacement happens in the flow? I may be missing the callers.

The second version doesn't assert. It reveals. The missing context (callers, the rest of the function) becomes a visible gap — and my instinct to scan the whole thing drives me to close it before posting.

Why this works for the specific mechanism

Problem	How the method addresses it
Diff hides disconfirming context	Writing "I observed only this fragment" makes the missing context feel physically present
Familiarity mistaken for understanding	Writing "I expected" separates the recognition from the comprehension — you see the gap
Irritation misattributed to developer	The "help me understand" phrase redirects the energy toward closing the gap, not blaming
"I've been right before" permission slip	The template delays the post. The permission loses its urgency in the pause
Identity threat ("if I don't criticize, what's my role?")	The understander role is equally valuable. Understanding clean code is a success, not a failure

The two-week protocol

Days 1–3: Every review comment uses the template. No exceptions. You will feel the obstacle. That's the friction of a habit changing.

Days 4–7: Add a fourth field: "What I have NOT yet seen: [callers / tests / full function / error paths]." Name the missing context explicitly before posting.

Days 8–14: Pull the branch before any critical comment. Use the template as your draft while viewing the full function locally. Check whether the "I expected" field changes once you have full context.

How to know it's working

Track three numbers daily:

Metric	Target
Comments posted	—
Comments retracted ("actually it is correct")	Zero by Day 14
Comments phrased as questions, not assertions	80%+ by Day 14

Track one qualitative signal: at the end of each day, write one sentence about how you felt during reviews. Irritation should shift from developer-directed to context-directed — and then to curiosity.

If it doesn't work

Two failure modes to watch for:

Empty template: You fill the fields mechanically without actually pulling context. "I observed the diff. I expected it to be different. Help me understand." This is compliance, not change. The fix: the "What I have NOT yet seen" field is your honesty check. If you can't name a specific file or function you haven't inspected, you're not using the method.
Template as weapon: You use the structure to sound more authoritative while still being wrong. "I observed a critical flaw. I expected best practices. Help me understand why this was done incorrectly." The fix: if "Can you help me understand" isn't a genuine question, rewrite it until it is.

Conclusion

I called myself lazy. I wasn't lazy. I was running a learned pattern:

Professional identity fused with finding fault
Need for cognitive closure triggered by unfamiliar code in narrow context
Familiarity mistaken for understanding
Irritation from missing context, misattributed to developers
"I've been right before" as a permission slip to skip verification
Intermittent reinforcement maintaining the habit across every PR

The name for this pattern is identity-driven premature closure. It's not a personality flaw. It's not a diagnosis. It's a behavioural mechanism that can be dismantled once you see it clearly.

The fix isn't "try harder." It's not "read more carefully." It's a structure that makes your own gaps visible to you — before you post. Three fields: what you saw, what you expected, what you need help understanding.

The method doesn't silence the impulse to judge. It gives the impulse a shape that leads to truth instead of error. And over time, it rewires what "doing my job" means. My job isn't to be the best critic. It's to be the best understander. When I understand fully and the code is clean, that's not a failed review. That's a successful one.

References

Kruglanski, A. W., & Webster, D. M. (1996). Motivated closing of the mind: "Seizing" and "freezing." Psychological Review, 103(2), 263–283.
Devroey, X., Matton, N., & Vanderose, B. (2024). Towards debiasing code review support. arXiv:2407.01407.
Kunda, Z. (1990). The case for motivated reasoning. Psychological Bulletin, 108(3), 480–498.
Haig, K. M., Sutton, S., & Whittington, J. (2006). SBAR: A shared mental model for improving communication between clinicians. The Joint Commission Journal on Quality and Patient Safety, 32(3), 167–175.
Parnin, C., & Orso, A. (2011). Are automated debugging techniques actually helping programmers? Proceedings of the 2011 International Symposium on Software Testing and Analysis (ISSTA), 199–209.

Memory Exploitation

Azad Shukor — Thu, 30 Jul 2026 15:30:33 +0000

here’s what i know about how an openai model hacked a vulnerable test system. it all begins with this one paper named ExploitGym.

one of the tasks was to exploit the memory system in the v8 engine. the vulnerability was a memory bug that allowed the model to read a memory address, or pointer, from a v8 object.

the function they wanted was puts, not PUT. from the address of puts, they could find the base address of libc, and from libc, they found system().

with system(), they could run shell commands, such as sending a request to a url using curl.

AI Predicts Code, Developers Still Have to Prove It

Azad Shukor — Tue, 28 Jul 2026 11:53:22 +0000

After reading a book about large language models, I started looking at AI-generated code differently.
Every AI-generated function I had seen worked.
That was exactly why I became skeptical.

My experience with coding agents has been positive. The code looks correct, runs correctly, and helps me move faster.

The book made me think about what happens underneath.
Large language models generate code through prediction.
They are not deterministic systems in the simple sense that one plus one equals two.

That does not mean the generated code is automatically bad.
It means that successful output answers only one part of the question.
I still need to know whether the code matches the intent behind the request.

Why working code feels trustworthy

Software gives us strong feedback.
The compiler rejects some mistakes. Tests reject others.
A running application makes a generated change feel trustworthy.

That feeling is reasonable.
If the function compiles, passes its tests, and solves the immediate problem, what else should I check?

The problem is that tests cover only the behavior we wrote down.
They do not automatically reveal every unstated requirement, insecure assumption, or dependency that does not exist.

Evidence for usefulness and caution

AI coding systems can produce useful results.
GitHub has reported productivity improvements in controlled studies of Copilot users. Its research also discusses code-quality outcomes.

SWE-bench Verified evaluates coding agents against real GitHub issues and issue-specific tests. Passing those tests is meaningful evidence that an agent solved a task-level problem.

The evidence does not prove that the implementation matches every unstated intention. A test confirms the behavior it covers. It does not confirm that the code is secure, maintainable, or based on real dependencies.

A USENIX Security 2025 study examined 576,000 code samples from 16 code-generating LLMs. It found hallucinated package names, including packages that did not exist. The reported average was at least 5.2% for commercial models and 21.7% for open-source models.

Spracklen et al., “We Have a Package for You!”

A separate replication study examined security weaknesses in GitHub Copilot suggestions. Vulnerable suggestions decreased from 36.54% to 27.25% in the newer setup. The authors still concluded that the model suggested insecure code.

Tahir et al., “Assessing the Security of GitHub Copilot Generated Code.”

These findings do not cancel out the productivity evidence.
They describe different properties. AI-generated code can be useful and test-passing while still needing review.

The verification model I am looking for

The paper I found described a hybrid approach to formal verification.
When the AI makes an assumption, it should check that assumption and record where the supporting implementation exists.

Instead of reading a function name and inferring what it does, the system could point to the actual implementation.
It could leave a note or citation showing why the assumption is true.

That approach changes the question. I should not ask only whether the generated code looks correct. I should also ask what evidence supports its assumptions.

The useful output would be a patch with a trail of reasons that I can inspect.

What I think now

I still use AI coding agents.

My skepticism is not a conclusion that they are useless or unreliable.

I think prediction and verification are different jobs.
The model can propose code.

I still have to decide whether that code expresses the right intent.

That means running tests, reading the implementation, checking dependencies, reviewing security-sensitive operations, and comparing the result with the original requirement.

I have not personally experienced a coding agent hallucinating a function or producing an obviously broken implementation.

This concern grew from understanding how the system works and from published evidence, not from a dramatic failure in my own project.

For now, I will keep using AI-generated code. I will stop treating successful output as the end of verification.

What I Added to My Prompts to Stop Models From Wandering

Azad Shukor — Sun, 26 Jul 2026 07:37:45 +0000

A few months ago, I was doing agentic coding with DeepSeek V4 Pro. It was cheap, it was fast, and it kept getting lost.

I'd watch the stream response in real time. The model would open a config file it didn't need. Then a test file. Then some unrelated utility. Then circle back. Minutes gone, nothing done. I'd sit there thinking: what a dumb model, can't do much.

Every session ended the same way. I'd give up on DeepSeek and switch to a frontier model to actually finish the thing.

I thought the problem was the model. Cheaper models have weaker reasoning, right? You get what you pay for.

The actual problem was that I wasn't giving it any direction.

What I was doing

This was my typical prompt:

Fix the login bug where users get 401 after password reset.

That's it. I was dropping the model into my codebase with nothing except the problem statement. No wonder it wandered. It had to figure out where to start, what files mattered, what "fixed" even meant. It was searching, not solving.

The change

Two things. Two lines added to every prompt.

First: success criteria. A concrete definition of done. Not "fix the auth bug" but "the login endpoint returns 200 with a valid JWT when given correct credentials." If I can't write a one-sentence check for it, the model can't either.

Second: an entry point. The exact file to start from. Not "somewhere in the auth module" but src/auth/login.ts.

The same prompt became:

Success criteria: POST /auth/login returns 200 with a valid JWT
when given the new password from the reset flow.
Entry point: src/auth/login.ts
Fix the login bug where users get 401 after password reset.

What happened

I wasn't expecting a revolution. I'd seen advice about being concrete in prompts. It sounded too simple. I figured maybe it'd save a few seconds.

The first time I used both rules together, the stream looked different. No file hunting. No detours. It opened src/auth/login.ts immediately and started working.

What surprised me more than the speed was how I felt. Before, I braced for frustration every time I used a cheaper model. Now I was just watching something do exactly what I asked. The emotional difference was bigger than the time saved.

The pattern

I started applying this to everything. Bug fixes, refactors, features. Same result: less wandering, less frustration, faster resolution. DeepSeek V4 Pro, a model I'd written off as "the cheap one," started handling tasks I used to reserve for frontier models.

The structure settled into three steps:

Success criteria first. Define done before anything else. Make it testable.
Entry point second. Give the file path. If the task spans multiple files, list them.
The actual ask last. Once the model knows what done means and where to start, the task almost writes itself.

The research I found later

After this became my default, I went looking to see if there was actual research behind what I'd stumbled into. There was.

The Prompt Report (Schulhoff et al., 2024) catalogued 58 prompting techniques and found that structured prompting consistently beats vague prompts across model sizes. They call what I'm doing "output specification": telling the model what the finished state looks like, not just what to do.

Another study by Pecher et al. found that smaller specialized models needed only about 100 labelled samples to match larger general ones on text classification tasks. The variable that moved the needle wasn't model size. It was task framing.

So it's not that I discovered something new. I just found it the usual way: through frustration, by accident, after assuming the tool was broken when I was the one not steering.

What got worse

This approach has limits. If the problem is genuinely ambiguous, if I don't know what file it lives in or what "fixed" looks like, I can't write good success criteria. Forcing it anyway gives the model a wrong target, which is worse than no target.

There's also a skill cost. Writing concrete success criteria is harder than writing a vague ask. It forces me to think through what I actually want before I ask for it. That's work. But it's work I'd have to do eventually anyway, either upfront in the prompt or downstream cleaning up after a wrong turn.

For genuinely exploratory problems, or when I'm navigating an unfamiliar codebase, I still reach for a frontier model. Some tasks need broader reasoning capacity. But that's fewer problems than I thought. Most of the time, I just needed to give direction.

References

Schulhoff, S. et al. (2024). The Prompt Report: A Systematic Survey of Prompt Engineering Techniques. arXiv:2406.06608.
Pecher, B. et al. (2024). Comparing Specialised Small and General Large Language Models on Text Classification: 100 Labelled Samples to Achieve Break-Even Performance. EMNLP 2025. arXiv:2402.12819.

I notice that glm-5.2 talk more compared to other models? do you agree?

Azad Shukor — Fri, 24 Jul 2026 10:44:56 +0000

Why is it AI generated codes are a very hard to read?

Azad Shukor — Fri, 24 Jul 2026 00:13:40 +0000

How I Use “Grill With Docs” to Understand Why I Procrastinate

Azad Shukor — Thu, 23 Jul 2026 00:15:31 +0000

When we talk about procrastination, I think it is not always about laziness. Sometimes, it is about fear.

The problem is, often we do not really know what we are afraid of. It can be so many things, right? Because of that, we sometimes need someone to help us see the pattern behind our procrastination.

Recently, I came across a skill from Matt Pocock called Grill With Docs. From my understanding, this skill will ask you a lot of questions. It will interview you relentlessly to understand further what you actually want, what you need to do, and what is still unclear.

Then it made me think, what if I use this same idea to understand why I procrastinate?

Sometimes, I know that I am procrastinating, but I do not fully understand the reason. So instead of asking AI to complete the task for me, I asked the AI to keep questioning me until we could find the actual root cause.

I changed the skill slightly from “Grill With Docs” into something like Root Cause Procrastination. The goal is to understand why I keep avoiding a certain task.

One example is writing a document.

Sometimes, I take a long time to start writing. At first, I thought the problem was that I did not know what to write. But after the AI kept asking me questions, I realised that the underlying issue was that I was not confident enough to write it.

The conversation could look something like this:

AI: Why are you avoiding writing the document?
Me: I am not sure what I should write.
AI: Why does that stop you from starting?
Me: Because I am afraid that my ideas will not sound clear.
AI: Does the first draft need to be clear immediately?
Me: Not really. I can improve it after I write it.

The thing I was most afraid of was that my ideas would sound unclear and that writing the document would be difficult.

The AI can then give some reasoning about why I should not care too much about that fear. For example, the first draft does not need to be perfect. Sometimes, the ideas only become clearer after we start writing them down.

For me, this method really works because it can pinpoint the reason why I procrastinate.

Instead of immediately calling myself lazy, I can ask more questions and understand what I am actually afraid of.

How I Understand Foundation Models and Reasoning Models

Azad Shukor — Wed, 22 Jul 2026 00:29:35 +0000

Recently, I was trying to understand what actually makes a reasoning model different from a normal language model.

From my understanding, everything starts with a foundation model.

A foundation model is trained using a very large amount of content, such as websites, books, code, research papers, and other documents. The basic task during this training is actually quite simple. The model tries to predict the next token.

A token can be a word, part of a word, or even punctuation.

For example, when we give the model:

I love to eat...

The model will try to predict what should come next. Maybe it is rice, pizza, chicken, or something else.

It repeats this process again and again using a huge amount of data. Because of this, the model slowly learns language, grammar, coding patterns, facts, and even some reasoning ability.

However, the foundation model is still not enough.

The main issue is that the goal of the foundation model is only to predict text. Its goal is not to become helpful, safe, polite, or consistent.

Because it learns from internet content, it can also learn some unwanted behaviour. The internet contains useful information, but it also contains toxic comments, angry conversations, misinformation, and many other bad examples.

For example, when a user becomes angry at the model, we do not want the model to become angry in return just because it has seen this kind of conversation before.

This is where post-training comes in.

Post-training is the process of teaching the model how it should respond. It shapes the behaviour of the foundation model so that it becomes more useful as an assistant.

There are different methods used in post-training, but I will not cover all of them here. The main idea is that the model is trained using examples of good and bad answers.

So where does the reasoning model come from?

A reasoning model is usually not trained completely from zero. It starts from a foundation model and then goes through more specialised post-training.

For reasoning tasks, the model is trained using problems that require multiple steps.

For example, in a mathematics problem, the model may need to understand the question, choose the correct formula, calculate an intermediate result, and then use that result in the next step.

This is also why reasoning models are slower.

They spend more computation trying to work through the problem before giving the final answer.

However, this does not mean reasoning models are always better for every task.

Sometimes I only want the model to check a log, find a certain value, rewrite a sentence, or answer a simple question. For these tasks, I usually do not need deep reasoning.

In my own work as a programmer, I use reasoning models more when I need to create a PRD, plan a complex feature, review architecture, or understand several connected requirements.

So my current understanding is simple:

Pretraining
    ↓
Foundation model
    ↓
Post-training
    ↓
Assistant or reasoning model

Without the foundation model, there is no reasoning model.

The foundation model provides the base knowledge. Post-training shapes how it behaves. Reasoning-focused post-training makes it better at solving complex problems.

The Mechanics Of Decision Of Test Double: Dummy

Azad Shukor — Mon, 04 May 2026 02:07:51 +0000

The most basic concept in test doubles is the dummy.

When testing a function, there are usually two kinds of input:

Meaningful input

Data that affects the result of the function.
Dummy input

Data that is required by the function, but does not affect the behavior we are testing.

Below is an example of meaningful data vs dummy data.

This is a calculateShipping function:

function calculateShipping(
  weight: number,
  user: { id: string },
  logger: { info: (message: string) => void }
) {
  return weight * 5;
}

In this function, only weight affects the result.

The user and logger parameters are required, but they do not affect the shipping calculation.

const meaningfulWeight = 10;
const dummyUser = { id: "dummy-user" };
const dummyLogger = { info: () => {} };

const result = calculateShipping(
  meaningfulWeight,
  dummyUser,
  dummyLogger
);

expect(result).toBe(50);

In this test:

const meaningfulWeight = 10;

is meaningful input because changing it changes the result.

For example:

calculateShipping(10, dummyUser, dummyLogger); // 50
calculateShipping(20, dummyUser, dummyLogger); // 100

But these two values are dummy inputs:

const dummyUser = { id: "dummy-user" };
const dummyLogger = { info: () => {} };

They are only passed because calculateShipping() requires them.

Changing them does not change the result:

calculateShipping(10, { id: "user-1" }, dummyLogger); // 50
calculateShipping(10, { id: "user-2" }, dummyLogger); // 50

So the purpose of a dummy is simple:

A dummy lets the function run without distracting the test from the behavior we actually care about.

In this case, we care about the shipping formula:

weight * 5

We do not care about the user or logger.

That is why user and logger can be dummy values.

A dummy is useful because it keeps the test focused. Without naming something as dummy, future readers may wonder whether user or logger matters to the test.

By naming them dummyUser and dummyLogger, we are saying clearly:

This value is only here because the function requires it. It is not part of the behavior being tested.

Understanding CIDR Notation

Azad Shukor — Sun, 12 Apr 2026 02:05:48 +0000

Understanding IPv4 CIDR Blocks

A CIDR block looks like:

10.0.0.0/16

It has two parts:

IP address → starting point
Prefix (/16) → how many bits are fixed

Core Idea (Memorize This First)

IPv4 = 32 bits total
CIDR /N = N bits are fixed (network)
Remaining bits = host bits (free to change)

Total addresses = 2^(32 - N)

IPv4 Structure

An IPv4 address:

10.0.0.0

Breakdown:

10       . 0       . 0       . 0
8 bits     8 bits    8 bits    8 bits

Total = 32 bits

Each block:

8 bits = values from 0 to 255
Example:
- 0 → 00000000
- 255 → 11111111

Think in Terms of LOCKED vs FREE

Instead of memorizing formulas, think:

Locked bits = define the network
Free bits = generate all possible addresses

Example: `10.0.0.0/16`

Step 1: Count free bits

32 - 16 = 16 free bits

Step 2: Calculate total addresses

2^16 = 65,536

Step 3: Visualize

10       . 0       . 0       . 0
[LOCKED]   [LOCKED]   [FREE]    [FREE]
  8 bits     8 bits     8 bits    8 bits

First 2 blocks fixed → 10.0
Last 2 blocks vary → 0.0 to 255.255

Range:

10.0.0.0 → 10.0.255.255

How to Read Any CIDR Quickly

Rule:

Move left to right, filling 8 bits per block, until you reach /N.

Example: `/10`

10.0.0.0/10

10       . 0       . 0       . 0
[8 LOCK]   [2 LOCK]   [FREE]    [FREE]

8 bits from first block
2 bits from second block

Total locked = 10 bits
Free = 22 bits
Total addresses = 2^22 = 4,194,304

Example: `/20`

10.0.0.0/20

10       . 0       . 0       . 0
[8 LOCK]   [8 LOCK]   [4 LOCK]   [FREE]

Locked = 20 bits
Free = 12 bits
Total = 2^12 = 4,096

Example: `/26`

10.0.0.0/26

10       . 0       . 0       . 0
[8 LOCK]   [8 LOCK]   [8 LOCK]   [2 LOCK]

Locked = 26 bits
Free = 6 bits
Total = 2^6 = 64

Example: `/30`

10.0.0.0/30

10       . 0       . 0       . 0
[8 LOCK]   [8 LOCK]   [8 LOCK]   [6 LOCK]

Free bits = 2
Total = 2^2 = 4

Range:

10.0.0.0 → 10.0.0.3

Shortcut Patterns (High Value)

Instead of recalculating every time:

CIDR	Free Bits	Total IPs
/16	16	65,536
/24	8	256
/26	6	64
/30	2	4

Important Practical Note

Not all addresses are usable:

First IP → network address
Last IP → broadcast address

Example /30:

10.0.0.0 → network
10.0.0.1 → usable
10.0.0.2 → usable
10.0.0.3 → broadcast

Mental Model (Best Way to Think)

Treat CIDR like a binary lock:

/N = how many switches are locked
Remaining switches = combinations

More free bits → bigger network
Fewer free bits → smaller network

One-Line Summary

CIDR is just: how many bits are fixed vs how many bits can vary.

DEV Community: Azad Shukor

Node Scaling and Pods Scaling Are Not The Same

Error Handling for MCP

Identity-Driven Premature Closure: The PR Review Trap I Fell Into Every Day

The Science Behind It

It's not laziness. It's identity-driven premature closure.

1. Need for Cognitive Closure

2. Confirmation Bias in Code Review

3. Identity-Protective Cognition

What Is the Proof?

The evidence is in the pattern, not a single incident

The familiarity illusion

The irritation was never about the developer

How to Fix It

The method: "I Observed / I Expected / Help Me Understand"

Why each field matters

Example: my own PR review, rewritten

Why this works for the specific mechanism

The two-week protocol

How to know it's working

If it doesn't work

Conclusion

References

Memory Exploitation

AI Predicts Code, Developers Still Have to Prove It

Why working code feels trustworthy

Evidence for usefulness and caution

The verification model I am looking for

What I think now

What I Added to My Prompts to Stop Models From Wandering

What I was doing

The change

What happened

The pattern

The research I found later

What got worse

References

I notice that glm-5.2 talk more compared to other models? do you agree?

Why is it AI generated codes are a very hard to read?

How I Use “Grill With Docs” to Understand Why I Procrastinate

How I Understand Foundation Models and Reasoning Models

The Mechanics Of Decision Of Test Double: Dummy

Understanding CIDR Notation

Understanding IPv4 CIDR Blocks

Core Idea (Memorize This First)

IPv4 Structure

Think in Terms of LOCKED vs FREE

Example: 10.0.0.0/16

Step 1: Count free bits

Step 2: Calculate total addresses

Step 3: Visualize

Range:

How to Read Any CIDR Quickly

Rule:

Example: /10

Example: /20

Example: /26

Example: /30

Shortcut Patterns (High Value)

Important Practical Note

Mental Model (Best Way to Think)

One-Line Summary

Example: `10.0.0.0/16`

Example: `/10`

Example: `/20`

Example: `/26`

Example: `/30`