DEV Community: Azad Shukor

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.

Next.js ConnectRPC Proxy Pattern

Azad Shukor — Wed, 04 Feb 2026 14:05:13 +0000

This article demonstrates a strictly typed gRPC implementation in Next.js using ConnectRPC and TanStack Query.

The core architectural goal is to unify the Server and Client definitions. It achieves this by implementing a Proxy Pattern: the Next.js API route exposes a local GreetService that acts as a typed gateway, forwarding requests to a remote ElizaService while reusing the exact same Proto definitions.

1. Dependencies

Required packages for ConnectRPC v2, Next.js 15, and TanStack Query.

package.json

{
  "name": "airborneo-grpc-proxy",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "eslint",
    "generate": "buf generate proto"
  },
  "dependencies": {
    "@bufbuild/protobuf": "^2.2.3",
    "@connectrpc/connect": "^2.0.1",
    "@connectrpc/connect-next": "^2.0.1",
    "@connectrpc/connect-node": "^2.1.1",
    "@connectrpc/connect-query": "^2.0.1",
    "@connectrpc/connect-web": "^2.1.1",
    "@tanstack/react-query": "^5.0.0",
    "next": "15.1.0",
    "react": "^19.0.0",
    "react-dom": "^19.0.0"
  },
  "devDependencies": {
    "@bufbuild/buf": "^1.47.0",
    "@bufbuild/protoc-gen-es": "^2.2.3",
    "@connectrpc/protoc-gen-connect-query": "^2.0.1",
    "@types/node": "^20",
    "@types/react": "^19",
    "@types/react-dom": "^19",
    "typescript": "^5"
  }
}

2. Proto Definition & Generation

We define two proto files. GreetService imports ElizaService messages to ensure strict type parity between the proxy and the upstream backend.

proto/connectrpc/eliza/v1/eliza.proto

syntax = "proto3";

package connectrpc.eliza.v1;

message SayRequest {
  string sentence = 1;
}

message SayResponse {
  string sentence = 1;
}

service ElizaService {
  rpc Say(SayRequest) returns (SayResponse) {}
}

proto/greet/v1/greet.proto

syntax = "proto3";

package greet.v1;

import "connectrpc/eliza/v1/eliza.proto"; 

// This service mimics the remote service but is exposed locally
service GreetService {
  rpc Say(connectrpc.eliza.v1.SayRequest) returns (connectrpc.eliza.v1.SayResponse) {}
}

buf.gen.yaml

version: v1
plugins:
  # 1. Generates Types AND Service Definitions (v2 Standard)
  - plugin: es
    path: ./node_modules/.bin/protoc-gen-es
    out: gen
    opt: target=ts

  # 2. Generates React Hooks (TanStack Query)
  - plugin: connect-query
    path: ./node_modules/.bin/protoc-gen-connect-query
    out: gen
    opt: target=ts

Run the generator:

npm run generate

3. The Proxy Utility

This utility dynamically implements a service definition by forwarding method calls to a target client. This allows us to "mount" the remote backend onto our local API route without manually rewriting every resolver.

src/utils/proxy.ts

import { type DescService } from "@bufbuild/protobuf";
import { type Client } from "@connectrpc/connect";

export function createProxy<T extends DescService>(
  service: T,
  client: Client<T>,
) {
  const implementation: any = {};

  for (const method of service.methods) {
    const fnName = method.localName;

    implementation[fnName] = async (req: any) => {
      console.log(`[Proxy] Forwarding ${fnName} for ${service.typeName}`);

      // Call the client dynamically
      return await (client as any)[fnName](req);
    };
  }

  console.log(
    `[Proxy] Built methods for ${service.typeName}:`,
    Object.keys(implementation),
  );

  return implementation;
}

4. API Route Implementation

We create a backend connection to the demo Eliza service, then route our local GreetService to proxy that connection.

pages/api/[[...connect]].ts

import { nextJsApiRouter } from "@connectrpc/connect-next";
import { ConnectRouter } from "@connectrpc/connect";
import { createClient } from "@connectrpc/connect";
import { createConnectTransport } from "@connectrpc/connect-node";

// Generated Code
import { GreetService } from "@/gen/greet/v1/greet_pb";
import { ElizaService } from "@/gen/connectrpc/eliza/v1/eliza_pb";
import { createProxy } from "@/src/utils/proxy";

// 1. The Backend Connection (Target)
const elizaBackend = createClient(
  ElizaService,
  createConnectTransport({
    baseUrl: "https://demo.connectrpc.com",
    httpVersion: "1.1",
  }),
);

function routes(router: ConnectRouter) {
  // ---------------------------------------------------------
  // ROUTE 1: GreetService (Proxy -> ElizaService)
  // URL: /api/greet.v1.GreetService/Say
  // ---------------------------------------------------------
  router.service(GreetService, createProxy(GreetService, elizaBackend));
}

export const { handler, config } = nextJsApiRouter({ routes });
export default handler;

5. Client Consumption

The frontend uses connect-web to talk to the local Next.js API. Note that we are using the GreetService definition here, but the data types (sentence) are strictly typed to the original Eliza definition.

app/page.tsx

"use client";
import { useState } from "react";
import { useMutation } from "@tanstack/react-query";
import { createClient } from "@connectrpc/connect";
import { createConnectTransport } from "@connectrpc/connect-web"; 
import { GreetService } from "@/gen/greet/v1/greet_pb";

// Point to YOUR local API
const transport = createConnectTransport({ baseUrl: "/api" });
const client = createClient(GreetService, transport);

export default function ChatPage() {
  const [input, setInput] = useState("");
  const [history, setHistory] = useState<string[]>([]);

  const mutation = useMutation({
    mutationFn: async (msg: string) => {
      // Input is typed as SayRequest (from Eliza)
      const res = await client.say({ sentence: msg });

      // Output is typed as SayResponse (from Eliza)
      return res.sentence;
    },
    onSuccess: (answer) => {
      setHistory((prev) => [...prev, `Eliza (via Proxy): ${answer}`]);
    },
  });

  return (
    <div style={{ padding: "50px", fontFamily: "sans-serif" }}>
      <h1>Proxy Chat</h1>
      <div style={{ display: "flex", gap: "10px" }}>
        <input
          value={input}
          onChange={(e) => setInput(e.target.value)}
          placeholder="Say something..."
          style={{ padding: "8px", flexGrow: 1 }}
        />
        <button onClick={() => mutation.mutate(input)} disabled={mutation.isPending}>
          {mutation.isPending ? "Sending..." : "Send"}
        </button>
      </div>

      <div style={{ marginTop: "20px", background: "#f5f5f5", padding: "20px", borderRadius: "8px" }}>
        {history.map((line, i) => (
          <p key={i} style={{ borderBottom: "1px solid #ddd", padding: "8px 0" }}>
            {line}
          </p>
        ))}
      </div>
    </div>
  );
}

Understanding SSL/TLS Certificates

Azad Shukor — Thu, 15 Jan 2026 05:47:38 +0000

The Name Game: SSL vs TLS

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are often used interchangeably, but here's the reality: SSL is dead. It hasn't been updated since 1996 and is riddled with security vulnerabilities. Everything we use today is actually TLS.

So why do we still hear "SSL" everywhere? Simple—it was the first name people learned, so the industry stuck with it for marketing. When you purchase an "SSL Certificate" today, you're actually getting a certificate that enables TLS.

What Does TLS Actually Do?

Think of TLS as a secure tunnel between two computers. When you click "Proceed to Payment" on a website, TLS creates an encrypted tunnel to transmit your payment information to the payment processor (like Visa or Stripe). Without TLS, anyone could intercept and read that data.

The Trust Problem: Certificate Authorities

Here's the million-dollar question: how do you know the tunnel is actually secure and going to the right place? You need someone to verify the certificate's legitimacy—kind of like an immigration officer checking your passport at the border.

In the TLS world, these "immigration officers" are called Certificate Authorities (CAs). Popular CAs include:

Let's Encrypt
Google Trust Services
Cloudflare
DigiCert
GoDaddy

How It Works: The Certificate Process

Step 1: Generate the Certificate Signing Request (CSR)

First, you generate a certificate locally or on your server. This creates two files:

# Generate a private key
openssl genrsa -out private.key 2048

# Generate a CSR using the private key
openssl req -new -key private.key -out certificate.csr

This gives you:

Private Key (private.key) - Keep this SECRET on your server, never share it
Certificate Signing Request (certificate.csr) - Send this to the CA

Step 2: CA Verification

You submit your CSR to a Certificate Authority. They'll verify:

Is this a legitimate company?
Do you actually own/control this domain?
Is the information accurate?

For domain validation, the CA might ask you to:

Add a DNS record
Upload a specific file to your website
Respond to an email sent to your domain

Step 3: Receive the Signed Certificate

After verification, the CA returns a signed certificate with their cryptographic signature. This is your "stamped passport."

# You'll receive something like this
certificate.crt  # Your signed certificate
ca-bundle.crt    # The CA's chain of trust

Step 4: Install on Your Server

Now you configure your server to use both the private key and the signed certificate.

Example for Nginx:

server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate /path/to/certificate.crt;
    ssl_certificate_key /path/to/private.key;

    # Modern TLS configuration
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
}

Example for Apache:

<VirtualHost *:443>
    ServerName yourdomain.com

    SSLEngine on
    SSLCertificateFile /path/to/certificate.crt
    SSLCertificateKeyFile /path/to/private.key
    SSLCertificateChainFile /path/to/ca-bundle.crt
</VirtualHost>

The Full Handshake (What Happens Behind the Scenes)

When a user visits your site:

Client Hello: Browser says "Hey, I want to connect securely"
Server Hello: Server responds with its certificate (the one signed by the CA)
Certificate Verification: Browser checks if the certificate is signed by a trusted CA
Key Exchange: They agree on encryption keys for the session
Encrypted Communication: All data flows through the secure tunnel

// This is what happens when you make an HTTPS request
fetch('https://api.example.com/payment', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    cardNumber: '4242424242424242',
    amount: 99.99
  })
});

// TLS encrypts everything in that request body automatically
// Without TLS, anyone on the network could read your card number

Why You Should Care

Without TLS:

❌ Passwords sent in plain text
❌ Credit cards visible to attackers
❌ Session tokens can be stolen
❌ Data can be modified in transit

With TLS:

✅ Everything encrypted end-to-end
✅ Authenticity verified by CAs
✅ Protection from man-in-the-middle attacks
✅ That reassuring padlock in the browser

Quick Start with Let's Encrypt (Free!)

# Install Certbot
sudo apt install certbot python3-certbot-nginx

# Get a certificate and auto-configure Nginx
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

# Auto-renewal is set up automatically
# Certificates are valid for 90 days

That's it. You now have TLS up and running, and your users can browse safely through that secure tunnel.

DEV Community: Azad Shukor

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

Next.js ConnectRPC Proxy Pattern

1. Dependencies

2. Proto Definition & Generation

3. The Proxy Utility

4. API Route Implementation

5. Client Consumption

Understanding SSL/TLS Certificates

The Name Game: SSL vs TLS

What Does TLS Actually Do?

The Trust Problem: Certificate Authorities

How It Works: The Certificate Process

Step 1: Generate the Certificate Signing Request (CSR)

Step 2: CA Verification

Step 3: Receive the Signed Certificate

Step 4: Install on Your Server

The Full Handshake (What Happens Behind the Scenes)

Why You Should Care

Quick Start with Let's Encrypt (Free!)

Example: `10.0.0.0/16`

Example: `/10`

Example: `/20`

Example: `/26`

Example: `/30`