DEV Community: Md Jamilur Rahman

25 Years of Headaches. Zero Doctors Found the Cause. One AI Conversation Did.

Md Jamilur Rahman — Fri, 03 Jul 2026 21:12:54 +0000

A 62-year-old man in India. Kidney failure, on dialysis three times a week. Diabetes. Hypertension. A stroke six years ago. And one symptom nobody could explain: severe headaches, but only when lying down to sleep.

For 25 years, specialists came up empty.

Then his nephew uploaded everything into Claude. And the AI asked one question that changed everything: "Does he snore?"

The answer was yes. Loudly. For 25 years.

That was the clue. The sleep study confirmed severe sleep apnea: 119 breathing stops per night, oxygen dropping to 78%, 47 oxygen desaturations per hour. CPAP treatment started. Headaches gone. (India Today, NDTV)

What Actually Happened

The story was posted on Reddit's r/ClaudeAI community by user u/the_kuka in March 2026. It went viral immediately, covered by India Today, NDTV, Hindustan Times, Economic Times, and Times of India within days.

Here's the timeline:

25 years of symptoms. The uncle had loud snoring, daytime exhaustion, and severe positional headaches (only when lying down). Every doctor attributed the fatigue to "dialysis fatigue" or "age." The snoring was something the family joked about.

Multiple specialists, zero connections. He saw neurologists. He saw nephrologists. He had brain MRIs and blood work. Each specialist looked at their domain. Nobody stepped back and asked what connected everything.

One conversation with Claude. The nephew compiled all medical records, MRI notes, and symptom history, and uploaded them. Over several days, Claude did three things:

Identified the positional pattern as the key clue. Headaches triggered by lying down is not random. It points to something that happens during sleep.
Pulled research showing 40-57% of dialysis patients have undiagnosed sleep apnea. This is a published statistic, not a guess.
Asked about snoring. This is the question no specialist had asked in 25 years. The answer was immediate and obvious in hindsight. (Substack - Chetan Pujari)

The sleep study confirmed it. Severe obstructive sleep apnea. CPAP treatment resolved the headaches.

Why Doctors Missed It

This is not a story about doctors being incompetent. It is a story about how medical systems work.

Specialists work in silos. Nephrology looks at kidneys. Neurology looks at the brain. Pulmonology looks at lungs. When a patient has symptoms that cross domains, nobody owns the full picture. The positional headache was a neurological symptom. The snoring was a pulmonary symptom. The dialysis fatigue was a nephrological symptom. Each specialist saw their piece.

Nobody asked about snoring. This is the detail that a doctor commenting on the Reddit thread confirmed: "As a doctor I'll say, this is not common. You'd have to ask about snoring and apnoeic episodes in the first place, which often doesn't happen." (NDTV)

Time pressure. Doctors in India see 40-60 patients a day. There is no 45-minute holistic intake. The system is not built for cross-domain reasoning on complex cases.

What Claude Actually Did

Let's be precise about what happened, because the "AI replaces doctors" narrative is wrong here.

Claude did not diagnose the uncle. Claude connected dots across domains, suggested a possibility, and recommended a sleep study. A doctor ordered the study. A doctor confirmed the diagnosis. A doctor prescribed the CPAP machine.

What Claude specifically did:

Analyzed the MRI report and flagged findings that had not been emphasised
Calculated a STOP-BANG score of 6-7 out of 8 (extremely high risk for sleep apnea)
Created a diagnostic roadmap: which specialist to see first, what tests to request, what questions to ask
Helped with CPAP setup: picked the right machine, explained settings, wrote maintenance instructions in Gujarati (the family's native language)

The AI did not replace the doctors. It helped the family advocate. It helped them walk into the pulmonologist's office prepared with the right questions.

The Real Takeaway

Sleep apnea affects an estimated 936 million adults worldwide, and roughly 80% of moderate-to-severe cases go undiagnosed. (American Academy of Sleep Medicine, 2018 study) In dialysis patients specifically, the 40-57% undiagnosed rate that Claude cited is from published research.

The question this story raises is not whether AI is smarter than doctors. It is whether our medical systems are structured to catch cross-domain conditions. Right now, they are not.

A tool that can take unlimited time, reason across specialties, and ask simple follow-up questions filled a gap that the system created. Not by being intelligent. By being thorough.

The Caveats

One story is not a clinical trial. Important things to keep in mind:

Confirmation bias. We hear about the AI success story. We do not hear about the thousands of times AI suggested wrong diagnoses that led to wasted tests or anxiety.
No medical license. AI cannot practice medicine. It should not be your first stop for medical advice. It is a tool, not a doctor.
Data privacy. Uploading medical records to an AI chatbot raises serious privacy concerns. Health data is sensitive, and chatbot companies' data handling policies vary.
The diagnosis was obvious in hindsight. Snoring for 25 years. Daytime exhaustion. Positional headaches. Any doctor who asked the right question would have caught it. The problem was not medical complexity. It was a system that did not ask.

For 25 years, the answer was hiding in plain sight. In the snoring the family joked about. In the afternoon naps everyone thought were normal. In a simple question nobody asked.

Does he snore?

Sometimes breakthroughs do not require new medicine. They require connecting obvious dots. And sometimes, the tool that helps you do that is AI.

Not because it is brilliant. Because it is patient enough to ask.

Sources:

Someone dumped 20 zero-days on open source tools with no warning. The fuzzing was run by AI.

Md Jamilur Rahman — Sun, 28 Jun 2026 02:06:52 +0000

Last week an anonymous GitHub account called bikini pushed a repository named exploitarium and, in the space of a few days, dropped more than twenty proof-of-concept exploits against popular open source software. nmap, Ghidra, FFmpeg, VLC, Firefox, libssh2, c-ares, OpenVPN, Docker, PHP, ImageMagick. None of the bugs had been reported to the maintainers beforehand. None were patched. The README said so plainly: at the time of posting, none had been reported, and you were free to file them yourself and "take credit for the CVE."

It hit the top of Hacker News and the thread filled up fast, and the argument that broke out underneath is more interesting than the exploits themselves.

This is worth paying attention to if you build, ship, or rely on open source infrastructure. Which is most of us.

What actually got dropped

The repository is a single consolidated archive. Twenty-three folders, each one a self-contained proof of concept against a different target. Some are network plumbing you probably run without thinking about it: c-ares (the DNS resolver library behind curl and a long list of other tools), libssh2, nghttp2, OpenVPN. Some are tools developers use directly: Ghidra and objdump for reverse engineering, nmap for scanning, Wireshark-adjacent dissectors in spirit if not in this specific repo. Several are media decoders, which is a category that has been quietly dangerous for two decades: FFmpeg, VLC, ImageMagick, 7-Zip's RAR5 handling.

A few of the entries already carry CVE numbers. libssh2-cve-2026-55200 is in there by name. Others read like serious findings: use-after-free bugs, RCE candidates, a privilege escalation in MyBB, a local privilege escalation in SystemInformer. The nmap one targets IPv6 extension-length parsing, and several people in the thread flagged it as potentially high severity because it sits in parser code, which is exactly where remote code execution tends to hide.

So this is not one researcher responsibly nudging one vendor. It is someone emptying a notebook onto the public internet, all at once.

Some of these are real. Some are not.

Here is where the story gets complicated, and why the Hacker News thread turned into a forensic argument rather than a victory lap.

People who actually know these codebases went digging, and the verdict was mixed. A Ghidra user pointed out that one of the three Ghidra findings requires you to already have the ability to overwrite binaries in the Swift tool directory. If you can overwrite the binaries a program runs, yes, you get code execution. That is not a vulnerability. That is how computers work. Someone else called the Docker entry "just a weird bug" rather than an exploitable flaw, and the VLC proof of concept landed as a straight crash with no path to running arbitrary code.

But not everything was dismissed. The same person who brushed off Ghidra checked c-ares, libssh2, and FFmpeg and said the bugs there "seem to all work as of the latest upstream commit." The nmap parser bug drew serious concern. The Firefox one, which involves the private-data and untrusted-input flags, sounded plausible to people who don't work on Firefox internals but couldn't fully rule it in or out.

This is the messy reality of a drop like this. No single person is an expert on every codebase. A maintainer of FFmpeg is not also a maintainer of OpenVPN. So when twenty bugs land at once, the entire security community has to scramble to triage them in parallel, and a lot of that triage happens in public, badly, on a forum, while the clock runs.

The fuzzing was run by AI

This is the part I keep coming back to.

After the initial wave of criticism, the account posted a statement, and it is unusually honest about method. The fuzzing workflow was automated. All of it. They used GPT-5.5-3-Codex-Spark to run the fuzzing against a strict harness, and the AI flagged candidate bugs that a human then investigated and confirmed.

Two things in that statement stood out. First, the author pushes back hard on the idea that you need a frontier model to find these. "You do not need a SOTA model to help you identify these issues," they wrote. Their data, they claim, shows that the model choice is marginal once you pair decent human oversight with a good harness. Second, they are explicit about what was and was not AI-generated: the proofs of concept were hand-typed, except RustDesk, where they leaned on AI because they are less fluent in the language. The README writeups, they admit, are "very clearly entirely AI," because an LLM formats Markdown well and they reviewed the output for accuracy.

Read that again. The discovery was AI-assisted and scaled. The writeups were AI-generated. The actual exploit code was human. That division of labor is probably the template for the next few years of security research, and it is a little unsettling how productive it is.

We are used to thinking of AI as either a coding autocomplete or a threat that writes malware. This is neither. It is an analyst that never sleeps, pointing a human at the exact lines of C where an integer wraps or a buffer gets reused after free. The human still has to write the exploit and confirm it lands. But the finding, the part that used to take weeks of manual auditing, got compressed into an automated loop.

Full disclosure, the brutal kind

The ethical question underneath all of this is older than the internet, and it never gets resolved. It just gets re-litigated every time someone drops a batch of bugs.

There are two camps, and both have a real point.

Coordinated disclosure says you tell the maintainer first, give them a reasonable window, usually sixty to ninety days, to ship a fix, and only then publish. The argument is simple: publishing a working exploit for an unpatched bug puts every user at risk the moment it goes public, and the people who get hurt first are not the maintainers. They are the admins and end users who had no say in the matter.

Full disclosure says the opposite. Publish immediately. The argument has a few forms, but the core one is that secret bugs are not safe. They sit in the code whether or not they are public, and the only people who benefit from them staying quiet are attackers who already know. Public pressure, the full-disclosure crowd argues, is the only reliable way to get things fixed. Vendors drag their feet. ninety-day windows stretch into years. Silence protects nobody.

The bikini account took the most extreme version of full disclosure. No private report. No window. No warning. The bugs went straight to GitHub, working exploits attached, and the author invited the community to do the responsible reporting themselves.

In the Hacker News thread the split was visible in real time. One commenter said flatly that they prefer these being public over sitting in "some government or corporate toolbox." Another countered that disclosure still enables better software to exist, even if nobody follows through. A third, the one I found most honest, said the whole situation just sucks: we are apparently going to need every open source project in the world to stop and audit this one repository on the off chance that their codebase is in it.

I do not have a clean answer here. Coordinated disclosure is the grown-up choice and I lean toward it, but I also cannot pretend the full-disclosure argument is wrong. What I am certain of is that this model, one person emptying twenty bugs onto GitHub with no warning, is going to get copied. The cost of doing it just dropped, because of the AI fuzzing part.

Why parsers keep losing

Step back from this specific drop and a pattern is obvious, and it is not new.

Almost every target in the repo parses untrusted input in C. Network protocol parsers. Container formats. Image and video decoders. DNS messages. SSH handshakes. The reason Wireshark dissectors came up repeatedly in the discussion, even though Wireshark is not directly in this repo, is that dissectors are protocol decoders written almost entirely in C, and anyone who can send packets can pick which decoder runs. The same is true of media players: hand VLC a malformed VP9 stream and you are exercising C code that was never formally verified, written under deadline pressure, handling a format specification that runs hundreds of pages.

C is not the enemy. A lot of the most important software in the world is written in it. But C does not check your bounds, and it does not refuse to use memory after you free it, and it does not tell you when you have wrapped an integer past its maximum. Every parser written in C is a standing invitation to exactly the class of bug that fills this repository: use-after-free, out-of-bounds write, integer overflow that becomes a memory corruption.

This is why the Rust rewrite movement exists. It is why curl now ships an optional Rust-based DNS resolver. It is why people keep trying to move parsers into memory-safe languages. The bugs in exploitarium are not exotic. They are the same bugs we have been shipping for forty years, found faster, by a loop that runs while the human sleeps.

What you should actually do

If you maintain or operate any of the affected software, the practical moves are unglamorous.

Patch as fixes land. The maintainers are going to be triaging in public over the coming weeks, and the responsible thing for everyone else is to follow their advisories and update promptly. Do not pull proof-of-concept code from a random GitHub repository onto a production machine to "test" it. Several commenters joked about the irony of security hobbyists rushing to download exploits and compromising themselves in the process. It is not really a joke.

If you run services that accept untrusted input, and you probably do, sandbox the parser. Run your media decoders and protocol parsers in containers or seccomp-restricted processes. Network parsers like nmap and protocol dissectors belong behind a trust boundary, not on a laptop that also holds your SSH keys.

And if you are a maintainer of C-based parsing code, this is a good week to look at property-based testing and continuous fuzzing of your own. The author of this drop built an AI-assisted harness in their spare time. Organizations with actual budgets can do the same thing before someone else does it for them and publishes the results without warning.

The part that stays with me

I keep thinking about the asymmetry. One anonymous person, an AI fuzzing loop, a GitHub account, and suddenly twenty open source projects have to drop everything and figure out whether they are on fire. The maintainer of a small library does not have a security team. They have evenings and weekends and a day job. Multiply that across twenty-three codebases and you get a meaningful slice of the open source world burning cycles it does not have.

The bugs are real, or some of them are. The disclosure ethics are debatable, and reasonable people land on different sides. But the part that feels new is the speed and the scale, and the fact that the loop behind it is going to get cheaper, not more expensive, from here. The next drop will be bigger. It will probably also be messier.

We have been treating memory bugs in parsers as a background fact of computing for decades. That background hum is about to get louder.

Setting Up VS Code for Java Development

Md Jamilur Rahman — Sat, 27 Jun 2026 02:04:51 +0000

VS Code is the most popular code editor on the planet. It's fast, free, and runs everywhere. But out of the box, it knows nothing about Java. Open a .java file and you get syntax highlighting. That's it. No autocomplete for your imports, no "click to run" button, no debugger.

The fix takes about two minutes. You install a Java extension, point it at a JDK, and you're writing real Java with a real debugger. Let me walk through the whole thing.

Install the Java extension

VS Code calls everything an "extension." For Java, you have a couple of options. This guide follows the one Oracle maintains, called the Oracle Java Platform extension. (Microsoft also publishes an "Extension Pack for Java" that bundles several tools together. Both get you up and running. Pick whichever you like.)

To install it:

Open VS Code.
Go to Code > Settings > Extensions (or press Ctrl+Shift+X).
Search for "Oracle Java Platform" and click Install.

That's the setup. The extension handles compiling, running, debugging, and project management under the hood.

Make sure you have a JDK

A JDK (Java Development Kit) is what actually compiles and runs your code. VS Code can't do Java without one.

Here's the nice part: if you don't have a JDK installed, the extension can download one for you. Open the command palette (Ctrl+Shift+P, or Cmd+Shift+P on Mac) and run:

Download, install, and Use JDK

Pick a version from the list. 17 and 21 are both good choices for new projects. The extension downloads it and saves the path in your settings, so you never have to wrestle with environment variables.

Already have a JDK? The extension finds it automatically by checking JAVA_HOME and JDK_HOME, then your system PATH. You can override it later in settings under jdk.jdkhome.

One thing to keep in mind: the extension needs JDK 11 or newer. If you're stuck on Java 8 for an old project, you can still write code that targets 8. But VS Code itself runs on a newer JDK.

Create your first project

Now you can actually build something. Open the command palette again and run:

Java: New Project

Choose Java with Maven. It asks for a folder name (let's say myapp) and a package name (something like com.example). Hit Enter.

The extension generates a basic Maven project: a pom.xml file, a src/main/java folder, and a starter class. Maven is a build tool that manages dependencies and packaging. For now, all you need to know is that pom.xml is where your project configuration lives.

Write some code and run it

Open the generated Java class and replace its contents with something simple:

package com.example;

public class MyApp {
    public static void main(String[] args) {
        System.out.println("Hello from VS Code!");
    }
}

To run it, look just above the main method. You'll see two little links: Run main and Debug main. Click Run main.

Your output appears in the terminal panel at the bottom. No manual compile step, no javac command. The extension compiles and runs behind the scenes.

Debug like you mean it

Click Debug main instead, and VS Code drops you into the debugger. Set breakpoints by clicking in the gutter next to line numbers, then step through your code one line at a time.

The debugger supports what you'd expect:

Pause and resume
Step over, step into, step out
Inspect variables mid-run
Evaluate expressions on the fly

Need to pass arguments to your program, like a list of numbers? Open the Run and Debug panel, find your launch configuration, and add them to the Program Arguments field. There's a launch.json file generated for you where all of this lives.

Refactoring and shortcuts

This is where a real editor earns its keep. The Oracle extension can:

Generate toString(), hashCode(), and equals() for you
Organize and sort imports automatically (turn on "Organize Imports on Save" in settings and forget about it)
Rename methods and move classes between packages without breaking references
Convert .get(0) to the newer .getFirst() syntax (Java 21 and up) across your whole project

Most of these live under the Source Action right-click menu, or the little lightbulb icon that appears next to your code.

Generate tests

Right-click a class, pick Source Action > Create Test Class, and the extension scaffolds a test file with empty test methods. Fill them in with your assertions, then use the Test Explorer to run individual tests or the full suite. Green checkmarks mean passing tests, red means something broke. Straightforward.

JavaDoc in two keystrokes

Type /** above any method and press Enter. The extension generates a JavaDoc comment with placeholders for each parameter and the return value. It sounds minor, but you'll reach for this constantly once you know it's there.

Summary

Install the Oracle Java Platform extension (or Microsoft's Extension Pack for Java) from the VS Code marketplace.
No JDK? The extension downloads one for you. It needs JDK 11 or newer.
Create a project through Java: New Project in the command palette.
Click Run main or Debug main above your main method to execute code.
The debugger gives you breakpoints, stepping, and live variable inspection.
Use Source Actions to generate boilerplate, organize imports, and refactor safely.
Type /** above a method to auto-generate JavaDoc.

Based on dev.java/learn — https://dev.java/learn/vscode-java/

ভালো টিম আর দুর্দান্ত টিমের মধ্যে পার্থক্য কোথায়?

Md Jamilur Rahman — Sat, 27 Jun 2026 02:04:15 +0000

গত মাসে আমাদের একটা payment system এ বারবার একই সমস্যা আসছিল। Transaction fail হচ্ছে, একজন developer ঠিক করছে, ticket close হচ্ছে। তিনদিন পর আবার একই জিনিস।

আমি log গুলো দেখলাম। একই মূল কারণ। কিন্তু কেউ সেটা fix করেনি। সবাই শুধু symptom দূর করে চলে গেছে। ভেতরের অসুখটা ধরেনি।

মাস শেষে হিসাব করলাম। একই সমস্যায় টিম ১০+ ঘণ্টা নষ্ট করেছে। মূল কারণটা fix করতে ৫-৬ ঘণ্টা লাগতো।

সত্যি বলতে, এটা শুধু আমাদের টিমের সমস্যা না। Brain Station 23, Selise, TigerIT এর মত company গুলোতেও এই জিনিসটা দেখা যায়। প্রায় প্রতিটা software team এ।

Anton Zaides, Manager.dev newsletter এর লেখক এবং ১৫+ বছরের tech experience নিয়ে কাজ করছেন। তিনি এই বিষয়ে বিস্তারিত লিখেছেন (source)। উনার মতে, একটা "ভালো" টিম আর "দুর্দান্ত" টিমের মধ্যে পার্থক্য মোটে ৭টা ছোট অভ্যাসে।

কাজ দুগুণ করা না। ১০x engineer থাকা না। শুধু কিছু habit।

আমি উনার ১০টা article পড়েছি। নিজের ৫ বছরের experience মিলিয়ে, এই ৭টা habit, ২টা bonus point, আর FDE এর মত নতুন concept গুলো আমাদের দেশের software company গুলোতে কীভাবে কাজে লাগে, সেটা লিখছি।

কিছু শব্দ আগেই বুঝে নিই:
EM / Team Lead = Engineering Manager। আমাদের দেশে একে Team Lead, Project Lead, বা Tech Lead ও বলা হয় (যিনি টিম চালান)
PM = Product Manager (যিনি কী feature বানাবে ঠিক করেন)
Ticket = Jira/Trello তে কাজের একটা item
PR = Pull Request (code review এর জন্য কোড submit করা)
Deploy = code production server এ পাঠানো
Tech Debt = এমন code বা architecture যেটা পরে সমস্যা তৈরি করবে (ঋণের মতো, পরে শোধ করতে হয়)
Bottleneck = এমন একটা জায়গা যেটা পুরো কাজকে ধীর করে দেয়
AI Coding Tool = Cursor, Claude Code, GitHub Copilot এর মত tool যা code লিখতে, review করতে, debug করতে সাহায্য করে
FDE = Forward Deployed Engineer। engineer যিনি client এর কাছে সরাসরি থাকেন, তাদের সমস্যা বোঝেন, আর solution বানান

📌 Patch না, Root Cause

ভালো টিম bug fix করে। সামনে এগোয়। কিন্তু একই bug আবার আসে। আবার fix। আবার আসে।

আবার fix।

একটা উদাহরণ দিই। ধরুন, আপনার পেট ব্যথা হচ্ছে বারবার। আপনি প্রতিবার painkiller খেয়ে সামলাচ্ছেন। কিন্তু ডাক্তার দেখাচ্ছেন না। এক সময় ব্যথা আরো বড় হবে।

Software এও একই। bKash বা SSL Commerz integration এ কোনো timeout issue আসছে? alert ignore করছেন। test fail করলে restart দিচ্ছেন। manual কাজটা প্রতিদিন হাতে করছেন।

সবই patch। আর patch জমতে থাকে।

এখন যদি AI tool (Cursor, Copilot) ব্যবহার করেন? সেকেন্ডে bug ঠিক হয়ে যাচ্ছে। কিন্তু root cause? AI ও শুধু symptom ঠিক করছে। ভালো টিম এই trap এ পড়ে। দুর্দান্ত টিম প্রশ্ন করে, "AI কেন এটা ঠিক করলো? মূল সমস্যাটা কী?"

xkcd এর একটা famous table আছে। যে কাজে আপনার সপ্তাহে ১৫ মিনিট যায়, সেটা fix করতে ২ দিন লাগলেও ৫ বছরে সেটা লাভের।

একটু ভেবে দেখুন। আপনার টিমে কতগুলো এমন ছোট ছোট patch চলছে?

দুর্দান্ত টিম এই decision টা ভেবে নেয়। কতবার হচ্ছে, fix করতে কত সময়, সব হিসাব করে একটা clear decision। চুপচাপ মেনে নেওয়া না।

📌 কাজ করা না, Own করা

ভালো টিমে engineer কাজ করে। Team Lead decide করে কে কী করবে, engineer execute করে।

সোজা কথায়, Team Lead হয়ে যায় একটা "task routing machine।" টিকিট ঢুকছে, Lead assign করছে, engineer কাজ শেষ করছে। আবার নতুন ticket।

দুর্দান্ত টিমে engineer কাজ own করে। Anton একে বলেছেন "kingdom" (source)।

ধরুন, আপনার টিমে একটা notification service আছে। কে সেটার owner? যে engineer সেটা own করছে, সে-ই সেই service এর সব decision নেয়। কীভাবে চলবে, কখন update হবে, সব তার।

এখন সত্যি কথা হলো, আমাদের দেশের অনেক company তে hierarchy খুব strong। Junior বা Mid-level engineer কে decision দেওয়া খুব rare। Senior বা Lead সব নেন।

কিন্তু ছোট পরিসরে শুরু করা যায়। "তুমি এই module টা দেখো, তোমার decision" শুধু এটুকু বললেও একটা পরিবর্তন আসে।

AI যুগে এটা আরো বেশি গুরুত্বপূর্ণ। AI যখন boilerplate code লিখে দিচ্ছে, তখন engineer এর মূল কাজ হলো decision নেওয়া। "কোন architecture, কোন design pattern," এসব decision এখন মানুষের।

Anton আরেকটা article এ বলেছেন, developer রা কেন চাকরি ছাড়ে (source)। প্রথম কারণটা salary না। প্রথম কারণ হলো, তারা মনে করছে আর নতুন কিছু শিখছে না।

মানে, ownership দেওয়া শুধু ভালো কাজের জন্য না। ভালো engineer ধরে রাখার জন্যও।

📌 নিজেকে না, অন্যকে আগে

আমাদের দেশের company গুলোতে একটা জিনিস খুব বেশি দেখি। এক টিম আরেক টিমের code review তে সপ্তাহ খানেক সময় নেয়। যে টিম review চেয়েছে, তারা অপেক্ষা করতে করতে হতাশ। শেষে নিজেরাই merge করে ফেলে।

Anton এর নিজের একই experience আছে (source)। ঐ টিমের EM review তে ২ সপ্তাহ সময় নিয়েছেন। তারা হতাশায় নিজেরাই merge করে ফেলেছেন।

খেয়াল করুন, review নিয়ে actual data কী বলে। Weave (৪০০+ company এর data analyze করে) এর research (source):

যে টিম ৩ ঘণ্টার মধ্যে review করে, তারা ৮+ ঘণ্টা নেওয়া টিমের চেয়ে ২.১ গুণ বেশি productive।

আর এখন AI reviewer আছে। Sumanyu এর টিম (Hamming AI) একসাথে কয়েকটা AI reviewer ব্যবহার করে (source)। AI প্রথমে সব comment করে, engineer সেগুলো triage করে, তারপর human review আসে। ফলে PR merge এ সময় লাগে মাত্র ১-২ ঘণ্টা।

দুর্দান্ত টিম ৯০% ক্ষেত্রে অন্য টিমের কাজ আগে করে। খুব কঠিন, বিশেষ করে আমাদের দেশে যেখানে টিমগুলোর মধ্যে "এটা আমার কাজ না" মানসিকতা বেশি। কিন্তু যে টিম এটা করে, পুরো company তে তার নাম হয়ে যায়।

Anton, Adam Grant এর "Give and Take" book থেকে একটা জিনিস share করেছেন। মানুষ তিন রকমের হয়:

Taker: যারা শুধু নিজের সুবিধা চিন্তা করে।
Matcher: যারা help করে কিন্তু ভাবে, "আমি কালকে সাহায্য করলাম, আজকে সে আমাকে করবে।"
Giver: যারা কোনো শর্ত ছাড়াই help করে।

খেয়াল করুন, সবচেয়ে কম perform করে কারা? Giver। কারণ তারা সবাইকে help করে নিজের কাজ করতে পারে না।

কিন্তু সবচেয়ে বেশি perform করে কারা?

আবার Giver।

📌 Execute না, Shape

ভালো টিম PM বা client এর roadmap execute করে। PM decide করে কী হবে, engineer বানায়।

দুর্দান্ত টিম roadmap বানাতে সাহায্য করে। Customer এর সাথে কথা বলে। Business বোঝে। যে feature টা make sense করে না, সেটায় push back করে।

খেয়াল করুন, আমাদের দেশের সংস্কৃতিতে senior বা manager কে question করা "disrespect" মনে হয়। Power distance বেশি। কিন্তু push back মানে fight করা না। push back মানে হলো, "এই feature টার পরিবর্তে যদি এটা করি, customer আরো বেশি happy হবে।" Data দিয়ে কথা বলা।

Anton নিজে একবার এই trap এ পড়েছিলেন। PM তাকে না জানিয়ে একটা deadline promise করেছিলেন। Anton রেগে যাওয়ার পরিবর্তে PM কে call করলেন। শান্তভাবে জিজ্ঞেস করলেন কেন। জানলেন PM ও ৩ জন executive এর pressure এ ছিলেন। তারপর দুজন মিলে plan বানালেন।

মানে, সমস্যার দিকে না তাকিয়ে, সমাধানের দিকে তাকালে অনেক সমস্যা ছোট হয়ে যায়।

Hamming AI এর CEO Sumanyu একটা দারুণ experiment করেছিলেন (source)। তিনি আগে customer এর সাথে নিজে কথা বলতেন, তারপর engineer দের বুঝিয়ে বলতেন। Engineer রা customer এর আসল সমস্যা feel করতো না।

তিনি engineer দের সরাসরি customer এর Slack channel এ যুক্ত করলেন। এখন engineer রা নিজে কথা বলে, নিজে সমস্যা বোঝে, আর অনেক সময় সেই দিনেই solution deploy করে দেয়।

"Maximize the bandwidth between the person who has the problem, and the person who can solve it।"

আমাদের দেশে offshore project এ এটা আরো বেশি relevant। Client এর সাথে engineer এর direct communication না থাকলে কাজ দ্রুত হবে না।

Palantir এর মত company গুলো এজন্য একটা role popularize করেছে, নাম Forward Deployed Engineer বা FDE। FDE টিমে বসে code লেখে না। সরাসরি client এর কাছে যায়। তাদের workflow বোঝে, আসল সমস্যা দেখে, তারপর solution বানায়। অর্ধেক engineer, অর্ধেক business analyst।

আমাদের দেশে এটা খুব কম দেখা যায়। অধিকাংশ offshore company তে engineer শুধু requirement document পায়। Client কে, তার business, তার আসল সমস্যা, কিছুই জানে না।

ধরুন, bKash এর মত একটা fintech কোম্পানিতে কাজ করছেন। Client বললেন, "আমাদের একটা report dashboard দরকার।" আপনি বসে বানালেন। ২ সপ্তাহ পর deliver করলেন। Client দেখে বললেন, "এটা তো আমার দরকার না, আমি তো চেয়েছিলাম transaction summary।"

FDE হলে কী হতো? আপনি client এর সাথে ১ ঘণ্টা কথা বলতেন। বুঝতেন তার আসল কী দরকার। তারপর ৩ দিনে সেটা বানিয়ে দিতেন। সময় বাঁচতো, client happy হতো, আপনিও frustrated হতেন না।

AI যুগে কোড লেখা cheap হয়ে গেছে, কিন্তু "সঠিক সমস্যা চিনে নেওয়া" এখনো দামি skill। FDE টাইপ engineer রা এখন সবচেয়ে বেশি valuable।

📌 Plan মেনে চলা না, Plan বাতিল করা

Roadmap বানানো হলো। Phase ১, ২, ৩। Phase ১ এর পর customer feedback এলো, negative।

কিন্তু Phase ২ এর কাজ শুরু হয়ে গেলো। কেউ থামতে চায় না।

কেন? কারণ engineer রা শুনতেই চায় না যে কোড তারা লিখেছে সেটা বাদ দিতে হবে।

দুর্দান্ত টিম শুরুতেই প্রশ্ন করে। কীভাবে measure করবো? Phase ১ success এর definition কী? লক্ষ্য পূরণ না হলে কী হবে? কী হলে আমরা feature টাই বাদ দেবো?

শেষের প্রশ্নটা সবচেয়ে কঠিন। বেশিরভাগ company তে এর উত্তর নেই।

📌 Launch না, Land

ভালো টিম feature deploy করে। Production এ গেছে, PR merged, ticket closed। উৎসব।

দুর্দান্ত টিম deploy কে অর্ধেক পথ মনে করে।

কেউ কি আসলে use করছে? সংখ্যা কি এগোলো? কোনো সমস্যা আছে?

আমি নিজে দেখেছি, feature এর পর feature ship হচ্ছে। প্রতিটা "done।" কিন্তু product তে কোনো improvement হচ্ছে না।

Feature launch হলো। কিন্তু কাজে লাগলো না।

offshore project এ এটা সবচেয়ে বেশি। Client feature চায়, টিম deliver করে, ticket close হয়। কেউ চেক করে না যে এটা আসলে কাজে লাগলো কি না।

📌 Tech Debt কে অবহেলা না, Business Case

ভালো টিমে দুটো backlog থাকে। Product backlog আর tech backlog। Tech এর জিনিসগুলো সবসময় পিছিয়ে যায় যখনই কিছু "urgent" আসে।

দুর্দান্ত টিম tech এর প্রতিটা কাজ কে business value দিয়ে explain করে। "Monolith refactor করতে হবে" না। "এই logic টা আলাদা service এ নিলে আমরা ৩x দ্রুত feature ship করতে পারবো, অন্য টিমের জন্য অপেক্ষা করতে হবে না।"

এখন AI যুগে এটা সবচেয়ে বড় ঝুঁকি। Pragmatic Engineer এর data বলছে (source), developer রা এখন ৬ মাস আগের চেয়ে ২ গুণ বেশি code generate করছে। মানে ২ গুণ দ্রুত tech debt জমছে। যদি কেউ root cause না ভাবে, শুধু AI এর output accept করে, ৬ মাস পর সেই codebase এ কাজ করা দুঃস্বপ্ন হবে।

📌 যেটা দেখা যায় না

Anton এর আরেকটা article পড়লে একটা অদ্ভুত জিনিস জানা যায় (source)। একজন senior engineer এর ৪০% সময় এমন কাজে যায় যেটা কোনো ticket এ নেই।

Code review। Junior দের সাহায্য করা। হঠাৎ support এর request।

এসব কেউ দেখে না। Promotion এর সময় কেউ count করে না।

এটা আমাদেশে আরো বেশি খাটে। আমাদের অনেক company তে engineer এর performance evaluate করা হয় কতটা ticket close করলো, সেটা দিয়ে। Code review, mentorship, knowledge sharing, এসব কেউ count করে না।

মানে, যে কাজ টিমকে একসাথে ধরে রাখে, সেটাই সবচেয়ে কম দেখা যায়।

📌 সবচেয়ে বড় Bottleneck টা খুঁজুন

Sumanyu একটা সহজ framework দিয়েছেন (source)। আপনার টিমকে একটা প্রশ্ন করুন। "তোমরা সময় সবচেয়ে বেশি কোথায় নষ্ট করো?"

উত্তরটা আপনার roadmap হবে। সবচেয়ে বড় bottleneck টা fix করুন। তারপর পরেরটা।

"The goal isn't to optimize everything. It's to remove the biggest source of waste, then move to the next one।"

Sumanyu এর টিম ১০,০০০+ unit test লিখেছে। এটা শুনে হয়তো ভাবছেন, "আমার company তে তো ১০০ test ও নেই।" সেটাও ঠিক আছে। শূন্য থেকে শুরু করুন। AI দিয়ে দ্রুত ship করলে bug ও দ্রুত আসে, তাই test লেখা এখন আগের চেয়ে বেশি দরকারী।

আজই কী করবেন?

একটু ভেবে দেখুন, এই habit গুলোর কোনটা আপনার টিমে নেই?

১. একটা বারবার আসা issue খুঁজুন। হিসাব করুন। যদি লাভ হয়, আজই root cause fix করার কথা টিমে রাখুন।

২. একজনকে একটা module বা service এর দায়িত্ব দিন। ছোট হলেও ঠিক আছে। Decision তার।

৩. একটা feature identify করুন যেটা সম্প্রতি launch হয়েছে। সেটা আসলে কেউ use করছে কি না, data চেক করুন।

৪. Tech debt কে business impact দিয়ে explain করুন। "এতে feature delivery ৩x slow হচ্ছে।"

৫. টিমকে প্রশ্ন করুন। "সময় সবচেয়ে বেশি কোথায় নষ্ট হয়?" সবচেয়ে বড় bottleneck টা এই সপ্তাহে fix করুন।

৬. FDE mindset নিয়ে কাজ শুরু করুন। পরের বার client কে কিছু ask করলে, শুধু requirement না নিয়ে তার সাথে ১৫ মিনিট কথা বলুন। "আপনি এটা কেন চাচ্ছেন, আপনার আসল সমস্যাটা কী?" এই একটা প্রশ্ন পুরো কাজ বদলে দিতে পারে।

শেষ করি সেই payment gateway issue এর কথা দিয়ে। আমরা সেই মাসেই root cause fix করলাম। ৬ ঘণ্টা লাগলো। এরপর থেকে সেই issue আর কখনো আসেনি।

৬ ঘণ্টা। ১০+ ঘণ্টার বারবার নষ্ট হওয়া সময়ের বদলে।

প্রশ্ন হলো, আপনার টিমে কোন patch টা আজই root cause fix করার দরকার? আর সবচেয়ে গুরুত্বপূর্ণ, আপনি নিজে কোন দিকে যাচ্ছেন, ভালো নাকি দুর্দান্ত?

Sources

Anton Zaides - "Okay vs Excellent Engineering Teams" - newsletter.manager.dev
Anton Zaides - "Give Your Engineers a Kingdom" - newsletter.manager.dev
Anton Zaides - "Shadow Work in Engineering Teams" - newsletter.manager.dev
Anton Zaides - "Why Developers Quit" + "The Victim Engineering Manager" - newsletter.manager.dev
Anton Zaides - "When Your PM Drives You Crazy" + "The Delayed Opinions Givers" - newsletter.manager.dev
Anton Zaides - "The Best Engineering Manager I Know" (Give and Take) - newsletter.manager.dev
Anton Zaides & Sumanyu Sharma - "Engineering Velocity on Steroids (10x Team)" - newsletter.manager.dev
Anton Zaides - "The Price of Mandatory Code Reviews" - newsletter.manager.dev
Gergely Orosz - "Slow Down to Speed Up with AI Agents" (Pragmatic Engineer) - newsletter.pragmaticengineer.com
Peopleware by Tom DeMarco & Timothy Lister + Give and Take by Adam Grant (book references)

GLM-5.2 vs Claude Opus: What the Numbers Actually Say for Developers

Md Jamilur Rahman — Sat, 27 Jun 2026 02:03:39 +0000

GLM-5.2 from Z.ai dropped recently and the reaction was loud. Some called it the end of closed models. Others dismissed it as benchmark gaming. This article cuts through the noise with data from an independent hands-on test, benchmark numbers, and community discussion.

To be clear upfront: I did not run my own head-to-head test. This article synthesizes work by James Daniel Whitford at TechStackups, independent benchmarks from Artificial Analysis, and community discussion from Hacker News. All sources are cited at the end. The goal is to help you decide which model fits your workflow.

What Is GLM-5.2?

GLM-5.2 is Z.ai's latest flagship model, released under an MIT license as open weights. You can download it, run it locally, or call it through Z.ai's API. It ships with a 1 million token context window and is designed for long-horizon agentic tasks, the kind of multi-hour coding work that coding agents do.

One key limitation: GLM-5.2 is text-only. It cannot read images, parse screenshots, or understand diagrams. Claude Opus is multimodal. This difference turns out to matter a lot in practice.

The Price Gap

Per 1 million tokens (source: TechStackups, citing Z.ai and Anthropic pricing):

Metric	Claude Opus 4.8	GLM-5.2
Input	$5.00	$1.40
Cache read	$0.50	$0.26
Output	$25.00	$4.40

On output tokens, GLM-5.2 costs roughly one-fifth of what Opus charges. If you run coding agents for hours every day, that difference compounds fast.

A Hacker News commenter raised a valid counterpoint: if you are on a $100/month Claude Max subscription and use it fully, the per-token cost difference shrinks considerably. Subscription pricing changes the math for heavy daily users.

The Test: Build a 3D Game From Scratch

James Daniel Whitford at TechStackups ran both models with the same one-shot prompt: build a third-person 3D platformer in raw WebGL with no libraries. The game needed a character controller, collision detection, a follow camera, a GLB model loader, GLSL shaders, and skinned animation.

This is not a "make me a landing page" test. A 3D engine in raw WebGL has layers of interdependent systems. If one piece is wrong, the whole thing breaks visibly.

Results at a Glance

Metric	GLM-5.2	Claude Opus 4.8
Build time	1h 10m 40s	33m 30s
Output tokens	131,000	216,809
Cost	$5.39	~$21.92 (estimated)
Tool calls	128	153

Opus finished in half the time. GLM-5.2 cost a fraction of the price.

Game Quality

Opus shipped a cleaner game. The character had textures applied correctly. The spike hazard killed the player. There was a working win condition. The camera and controls felt right. Bugs were minor edge cases, like standing on thin air near platforms due to an overly generous coyote-time grace period.

GLM-5.2 shipped a rougher game. The character rendered as flat gray with missing textures. The spike hazard did nothing when you touched it. There was no win condition. The character model faced backwards the entire time. These were fundamental issues, not polish problems.

GLM-5.2 did nail one thing: a spring launch mechanic that let you bounce up to higher platforms. So it is not that the model cannot code. It struggles to hold a complex multi-file build together at the same level as Opus.

The Multimodal Gap

Both models were told to verify their work before stopping. Opus took a screenshot of the rendered game, looked at it, noticed it had left debug overlays on screen, and cleaned them up. It could see the result and catch visual problems.

GLM-5.2 cannot read images. Instead of looking at a screenshot, it wrote scripts to sample pixel colors from the saved frame. It checked whether the colors matched expectations: grass green, dirt brown, coin gold. The colors were there, so it declared the game finished.

But the character was gray with missing textures, and the debug overlay was still visible. GLM-5.2 never saw those problems because it was reading numbers instead of looking at the image.

On visual tasks, this is a real disadvantage. An agent that can inspect its own output catches bugs that a text-only model will ship blind.

What the Benchmarks Say

The table below shows numbers from Z.ai's model card. An asterisk (*) marks self-reported scores (each vendor reports its own numbers). Independent results from Artificial Analysis broadly agree with these rankings.

Benchmark	GLM-5.2	Opus 4.8*	GPT-5.5*	Gemini 3.1 Pro*
AIME 2026	99.2	95.7	98.3	98.2
GPQA-Diamond	91.2	93.6	93.6	94.3
SWE-bench Pro	62.1	69.2	58.6	54.2
Terminal Bench (Terminus-2)	81.0	85	84	74
SWE-Marathon	13.0	26.0	12.0	4.0

GLM-5.2 actually beats Opus on AIME 2026 (math competition). But Opus dominates the coding and long-horizon agentic benchmarks, especially SWE-Marathon where it doubles GLM-5.2's score. GPT-5.5 trails GLM-5.2 on coding benchmarks like SWE-bench Pro (58.6 vs 62.1) and SWE-Marathon (12.0 vs 13.0), but edges ahead on Terminal Bench (84 vs 81).

Independent benchmarking from Artificial Analysis ranks GLM-5.2 as the leading open-weights model with an Intelligence Index score of 51, ahead of MiniMax-M3 (44) and DeepSeek V4 Pro (44). They note it is token-hungry, using about 43k output tokens per task, more than any other leading open model.

Simon Willison, who has reviewed nearly every major model release, called GLM-5.2 "probably the most powerful text-only open weights LLM" on X. Nathan Lambert from the Allen Institute for AI noted that Chinese labs are reaching these scores on less compute, and the open-closed gap is closing faster than many expected.

What HN Commenters Added

The Hacker News discussion (170+ points, 149 comments) added practical ground truth:

One developer found GLM-5.2 solved a 3D fluid dynamics rendering problem that both Opus and GPT-5.5 struggled with
Another noted GLM-5.2 takes its time before generating code and sometimes hallucinates plans it does not follow
Several pushed back on one-shot testing as not representative of real collaborative agent workflows
One commenter claimed "Chinese models optimize for benchmarks and do poorly in real-world tasks" (others disputed this)

What This Means for Developers

The WebGL test is one data point from one prompt. Real development work is different. Here is how to think about the tradeoffs for everyday use.

For boilerplate and standard CRUD code, GLM-5.2 is likely sufficient. Writing a JPA repository, a REST controller, or a Kafka consumer configuration is well-trodden territory. At one-fifth the cost of Opus, GLM-5.2 makes economic sense for these tasks.

For debugging complex issues, Opus pulls ahead. When you have a Kafka rebalance storm caused by a subtle consumer group configuration issue, or a Redis cache invalidation race condition, the difference between SWE-bench Pro 69.2 and 62.1 could matter. Correctness matters more than cost when you are chasing a production bug.

The multimodal gap depends on your work. If you build UIs, run visual regression tests, or work with screenshots, Opus can inspect its own output. If your work is mostly text (stack traces, log files, SQL queries, configuration), GLM-5.2's text-only limitation is less of a problem.

The real value of open weights is operational. A closed model can have an outage, change its pricing, or restrict access. We saw Claude outages hit HN's front page multiple times already this year. GLM-5.2 running on your own hardware has none of those risks.

How to Try Both Models

Both models are accessible through their official platforms:

GLM-5.2: Available via Z.ai's API at open.bigmodel.cn, or through OpenRouter. The weights are on Hugging Face under MIT license if you want to self-host.
Claude Opus: Available via Anthropic's API at platform.claude.com, or through AWS Bedrock and Google Vertex AI.

Z.ai's platform supports an OpenAI-compatible SDK, so if you already use the OpenAI Python library, migration is minimal. Anthropic provides its own Python SDK. Both have free tiers or trial credits to get started.

Practical Takeaway

Neither model wins everything.

Use Claude Opus when:

You need visual verification (screenshots, UI testing, image analysis)
Correctness and polish matter more than cost
You are debugging complex, multi-file issues
You want the best coding benchmarks available

Use GLM-5.2 when:

Cost is a primary concern (it is 4-5x cheaper)
You need open weights that cannot be taken away or restricted
The work is primarily text and logic, not visual
You want to run it locally on your own hardware
You need a fallback when closed models have outages

The smartest approach is to keep both in your toolkit. Use GLM-5.2 for the bulk of text-heavy work where the cost savings add up. Switch to Opus when you need visual judgment, maximum coding reliability, or the kind of long-horizon reasoning where it clearly leads.

The open weights gap is real, but it is narrowing. GLM-5.2 proves you no longer need to pay premium prices to get a genuinely capable coding model. It does not beat Opus yet, but it does not need to. It just needs to be good enough for most tasks, and cheap enough that the math works.

Sources

James Daniel Whitford / TechStackups - "GLM-5.2 vs Claude Opus" (June 18, 2026) - techstackups.com
Hacker News Discussion (170 pts, 149 comments) - news.ycombinator.com
Artificial Analysis - Intelligence Index v4.1 rankings (via X)
Simon Willison - Model review (via X)
Nathan Lambert - Allen Institute for AI commentary (via X)
Z.ai - Model card and pricing (referenced via TechStackups; not independently verified by author)
Anthropic - API documentation at platform.claude.com

"ভালো টিম" আর "দুর্দান্ত টিম" এর মধ্যে পার্থক্য কোথায়?

Md Jamilur Rahman — Mon, 22 Jun 2026 18:27:56 +0000

কাজ দুগুণ করা না। ১০x engineer থাকা না। শুধু কিছু habit।

কিছু শব্দ আগেই বুঝে নিই:
EM / Team Lead = Engineering Manager। আমাদের দেশে একে Team Lead, Project Lead, বা Tech Lead ও বলা হয় (যিনি টিম চালান)
PM = Product Manager (যিনি কী feature বানাবে ঠিক করেন)
Ticket = Jira/Trello তে কাজের একটা item
PR = Pull Request (code review এর জন্য কোড submit করা)
Deploy = code production server এ পাঠানো
Tech Debt = এমন code বা architecture যেটা পরে সমস্যা তৈরি করবে (ঋণের মতো, পরে শোধ করতে হয়)
Bottleneck = এমন একটা জায়গা যেটা পুরো কাজকে ধীর করে দেয়
AI Coding Tool = Cursor, Claude Code, GitHub Copilot এর মত tool যা code লিখতে, review করতে, debug করতে সাহায্য করে
FDE = Forward Deployed Engineer। engineer যিনি client এর কাছে সরাসরি থাকেন, তাদের সমস্যা বোঝেন, আর solution বানান

📌 Patch না, Root Cause

ভালো টিম bug fix করে। সামনে এগোয়। কিন্তু একই bug আবার আসে। আবার fix। আবার আসে।

আবার fix।

সবই patch। আর patch জমতে থাকে।

একটু ভেবে দেখুন। আপনার টিমে কতগুলো এমন ছোট ছোট patch চলছে?

📌 কাজ করা না, Own করা

ভালো টিমে engineer কাজ করে। Team Lead decide করে কে কী করবে, engineer execute করে।

দুর্দান্ত টিমে engineer কাজ own করে। Anton একে বলেছেন "kingdom" (source)।

মানে, ownership দেওয়া শুধু ভালো কাজের জন্য না। ভালো engineer ধরে রাখার জন্যও।

📌 নিজেকে না, অন্যকে আগে

খেয়াল করুন, review নিয়ে actual data কী বলে। Weave (৪০০+ company এর data analyze করে) এর research (source):

Anton, Adam Grant এর "Give and Take" book থেকে একটা জিনিস share করেছেন। মানুষ তিন রকমের হয়:

Taker: যারা শুধু নিজের সুবিধা চিন্তা করে।
Matcher: যারা help করে কিন্তু ভাবে, "আমি কালকে সাহায্য করলাম, আজকে সে আমাকে করবে।"
Giver: যারা কোনো শর্ত ছাড়াই help করে।

কিন্তু সবচেয়ে বেশি perform করে কারা?

আবার Giver।

📌 Execute না, Shape

ভালো টিম PM বা client এর roadmap execute করে। PM decide করে কী হবে, engineer বানায়।

"Maximize the bandwidth between the person who has the problem, and the person who can solve it।"

📌 Plan মেনে চলা না, Plan বাতিল করা

Roadmap বানানো হলো। Phase ১, ২, ৩। Phase ১ এর পর customer feedback এলো, negative।

কিন্তু Phase ২ এর কাজ শুরু হয়ে গেলো। কেউ থামতে চায় না।

কেন? কারণ engineer রা শুনতেই চায় না যে কোড তারা লিখেছে সেটা বাদ দিতে হবে।

শেষের প্রশ্নটা সবচেয়ে কঠিন। বেশিরভাগ company তে এর উত্তর নেই।

📌 Launch না, Land

ভালো টিম feature deploy করে। Production এ গেছে, PR merged, ticket closed। উৎসব।

দুর্দান্ত টিম deploy কে অর্ধেক পথ মনে করে।

কেউ কি আসলে use করছে? সংখ্যা কি এগোলো? কোনো সমস্যা আছে?

Feature launch হলো। কিন্তু কাজে লাগলো না।

📌 Tech Debt কে অবহেলা না, Business Case

📌 যেটা দেখা যায় না

Code review। Junior দের সাহায্য করা। হঠাৎ support এর request।

এসব কেউ দেখে না। Promotion এর সময় কেউ count করে না।

মানে, যে কাজ টিমকে একসাথে ধরে রাখে, সেটাই সবচেয়ে কম দেখা যায়।

📌 সবচেয়ে বড় Bottleneck টা খুঁজুন

উত্তরটা আপনার roadmap হবে। সবচেয়ে বড় bottleneck টা fix করুন। তারপর পরেরটা।

"The goal isn't to optimize everything. It's to remove the biggest source of waste, then move to the next one।"

আজই কী করবেন?

একটু ভেবে দেখুন, এই habit গুলোর কোনটা আপনার টিমে নেই?

২. একজনকে একটা module বা service এর দায়িত্ব দিন। ছোট হলেও ঠিক আছে। Decision তার।

৪. Tech debt কে business impact দিয়ে explain করুন। "এতে feature delivery ৩x slow হচ্ছে।"

৬ ঘণ্টা। ১০+ ঘণ্টার বারবার নষ্ট হওয়া সময়ের বদলে।

Sources

Anton Zaides - "Okay vs Excellent Engineering Teams" - newsletter.manager.dev
Anton Zaides - "Give Your Engineers a Kingdom" - newsletter.manager.dev
Anton Zaides - "Shadow Work in Engineering Teams" - newsletter.manager.dev
Anton Zaides - "Why Developers Quit" + "The Victim Engineering Manager" - newsletter.manager.dev
Anton Zaides - "When Your PM Drives You Crazy" + "The Delayed Opinions Givers" - newsletter.manager.dev
Anton Zaides - "The Best Engineering Manager I Know" (Give and Take) - newsletter.manager.dev
Anton Zaides & Sumanyu Sharma - "Engineering Velocity on Steroids (10x Team)" - newsletter.manager.dev
Anton Zaides - "The Price of Mandatory Code Reviews" - newsletter.manager.dev
Gergely Orosz - "Slow Down to Speed Up with AI Agents" (Pragmatic Engineer) - newsletter.pragmaticengineer.com
Peopleware by Tom DeMarco & Timothy Lister + Give and Take by Adam Grant (book references)

GLM-5.2 vs Claude Opus: What the Numbers Actually Say for Developers

Md Jamilur Rahman — Mon, 22 Jun 2026 15:33:48 +0000

What Is GLM-5.2?

One key limitation: GLM-5.2 is text-only. It cannot read images, parse screenshots, or understand diagrams. Claude Opus is multimodal. This difference turns out to matter a lot in practice.

The Price Gap

Per 1 million tokens (source: TechStackups, citing Z.ai and Anthropic pricing):

Metric	Claude Opus 4.8	GLM-5.2
Input	$5.00	$1.40
Cache read	$0.50	$0.26
Output	$25.00	$4.40

On output tokens, GLM-5.2 costs roughly one-fifth of what Opus charges. If you run coding agents for hours every day, that difference compounds fast.

The Test: Build a 3D Game From Scratch

This is not a "make me a landing page" test. A 3D engine in raw WebGL has layers of interdependent systems. If one piece is wrong, the whole thing breaks visibly.

Results at a Glance

Metric	GLM-5.2	Claude Opus 4.8
Build time	1h 10m 40s	33m 30s
Output tokens	131,000	216,809
Cost	$5.39	~$21.92 (estimated)
Tool calls	128	153

Opus finished in half the time. GLM-5.2 cost a fraction of the price.

Game Quality

The Multimodal Gap

But the character was gray with missing textures, and the debug overlay was still visible. GLM-5.2 never saw those problems because it was reading numbers instead of looking at the image.

On visual tasks, this is a real disadvantage. An agent that can inspect its own output catches bugs that a text-only model will ship blind.

What the Benchmarks Say

Benchmark	GLM-5.2	Opus 4.8*	GPT-5.5*	Gemini 3.1 Pro*
AIME 2026	99.2	95.7	98.3	98.2
GPQA-Diamond	91.2	93.6	93.6	94.3
SWE-bench Pro	62.1	69.2	58.6	54.2
Terminal Bench (Terminus-2)	81.0	85	84	74
SWE-Marathon	13.0	26.0	12.0	4.0

What HN Commenters Added

The Hacker News discussion (170+ points, 149 comments) added practical ground truth:

One developer found GLM-5.2 solved a 3D fluid dynamics rendering problem that both Opus and GPT-5.5 struggled with
Another noted GLM-5.2 takes its time before generating code and sometimes hallucinates plans it does not follow
Several pushed back on one-shot testing as not representative of real collaborative agent workflows
One commenter claimed "Chinese models optimize for benchmarks and do poorly in real-world tasks" (others disputed this)

What This Means for Developers

The WebGL test is one data point from one prompt. Real development work is different. Here is how to think about the tradeoffs for everyday use.

How to Try Both Models

Both models are accessible through their official platforms:

GLM-5.2: Available via Z.ai's API at open.bigmodel.cn, or through OpenRouter. The weights are on Hugging Face under MIT license if you want to self-host.
Claude Opus: Available via Anthropic's API at platform.claude.com, or through AWS Bedrock and Google Vertex AI.

Practical Takeaway

Neither model wins everything.

Use Claude Opus when:

You need visual verification (screenshots, UI testing, image analysis)
Correctness and polish matter more than cost
You are debugging complex, multi-file issues
You want the best coding benchmarks available

Use GLM-5.2 when:

Cost is a primary concern (it is 4-5x cheaper)
You need open weights that cannot be taken away or restricted
The work is primarily text and logic, not visual
You want to run it locally on your own hardware
You need a fallback when closed models have outages

Sources

James Daniel Whitford / TechStackups - "GLM-5.2 vs Claude Opus" (June 18, 2026) - techstackups.com
Hacker News Discussion (170 pts, 149 comments) - news.ycombinator.com
Artificial Analysis - Intelligence Index v4.1 rankings (via X)
Simon Willison - Model review (via X)
Nathan Lambert - Allen Institute for AI commentary (via X)
Z.ai - Model card and pricing (referenced via TechStackups; not independently verified by author)
Anthropic - API documentation at platform.claude.com

JShell: Java's Built-In Scratchpad for Trying Code Fast

Md Jamilur Rahman — Sun, 21 Jun 2026 07:08:44 +0000

Here's a familiar feeling. You want to test one small thing in Java — maybe how String.substring() behaves, or whether a regex pattern matches. So you create a file, write a class, add a main method, type System.out.println, compile, run. All that ceremony for a one-line answer.

JShell does away with the ceremony. It's a read-eval-print loop (REPL) that ships with the JDK since Java 9. You type Java code, press Enter, and see the result immediately. No class, no main method, no compile step. Think of it as a calculator for Java.

Starting JShell

Open a terminal and type:

jshell

If your JDK is installed and on your PATH, you'll see a welcome message and the jshell> prompt. That's it. You're in.

If you get a "command not found" error, double-check that the JDK (not just the JRE) is installed and the bin folder is on your PATH.

Your First Snippets

In JShell, the bits of code you type are called snippets. A snippet can be an expression, a variable, a method, or even a full class. Let's try a few:

jshell> int age = 25
age ==> 25

jshell> age * 2
$2 ==> 50

jshell> "hello".toUpperCase()
$3 ==> "HELLO"

Notice two things. First, no semicolons needed. JShell adds them for you if you forget. Second, when you type an expression without storing it in a variable, JShell creates a scratch variable for you automatically ($2, $3, and so on). You can reuse these later:

jshell> $2 + 10
$5 ==> 60

This is handy when you're poking around and don't want to name every intermediate result.

Defining Methods and Classes

You can define full methods in JShell, not just expressions. Here's a simple one:

jshell> int square(int n) {
   ...>     return n * n;
   ...> }
|  created method square(int)

jshell> square(7)
$7 ==> 49

The ...> prompt means JShell knows you're in the middle of a multi-line snippet and is waiting for you to finish. Close the braces and press Enter.

Classes work the same way. You can define a class, instantiate it, and call methods on it, all without leaving the prompt.

Changing What You Already Wrote

This is where JShell gets genuinely useful. If you redefine a method or variable, the old version is replaced. No need to start over.

jshell> String grade(int score) {
   ...>     if (score >= 90) return "Pass";
   ...>     return "Fail";
   ...> }
|  created method grade(int)

jshell> grade(85)
$3 ==> "Fail"

That pass threshold feels too strict. Just retype the method with a change:

jshell> String grade(int score) {
   ...>     if (score >= 80) return "Pass";
   ...>     return "Fail";
   ...> }
|  modified method grade(int)

jshell> grade(85)
$5 ==> "Pass"

The method updated in place. Any other methods that called grade will use the new version automatically. For longer snippets, use the /edit command to pop open a text editor instead of retyping:

jshell> /edit grade

Make your changes, save, and close the editor. JShell picks up the new version.

The Slash Commands You'll Actually Use

JShell has about 20 commands, all starting with a forward slash. You won't need all of them. Here are the ones that matter day to day:

/list            # show everything you've typed, with IDs
/vars            # show all variables and their values
/methods         # show all methods you've defined
/types           # show classes, interfaces, and enums
/imports         # show active imports

To manage your session:

/save myfile.jsh   # save all snippets to a file
/open myfile.jsh   # load snippets back in later
/reset             # wipe everything and start fresh
/drop 3            # remove a specific snippet by ID
/history           # see everything typed, in order
/exit              # leave JShell

Pro tip: command abbreviations work as long as they're unique. /l runs /list. /v runs /vars. /sa runs /save (since /s alone is ambiguous between /save and /set).

Tab Completion and Shortcuts

Press Tab while typing and JShell fills in the rest. This works for commands, class names, and method names. If there's more than one option, Tab shows you all of them.

A few shortcuts worth knowing:

Tab after a method's opening parenthesis shows you the parameter types. Press Tab again for a description.
Up/Down arrows scroll through your history, just like a regular shell.
Ctrl+R searches backward through what you've typed.
/! reruns your last snippet. /-3 reruns the snippet from 3 steps ago.

The Shift+Tab then V shortcut is a neat trick: type an expression, hit that combo, and JShell converts it into a variable declaration with the correct type filled in.

Feedback Modes

By default, JShell shows a reasonable amount of feedback. But when you're learning, more detail helps. Switch to verbose mode:

jshell> /set feedback verbose

Verbose mode explains what happened after each snippet — what was created, modified, or dropped, and what type it is. Once you're comfortable, switch back to normal or concise:

jshell> /set feedback normal
jshell> /set feedback concise

There's also silent mode if you want zero output (useful when piping JShell into scripts).

Saving and Reusing Sessions

One complaint people have about REPLs: you lose everything when you close them. JShell solves this with /save and /open.

Before you exit, save your work:

/save practice.jsh

Next time you start JShell, load it back:

/open practice.jsh

You can also pass a file directly when launching:

jshell practice.jsh

This makes JShell practical for more than throwaway experiments. Keep a .jsh file of helper methods you use often, and load it whenever you start a session.

When to Reach for JShell

JShell isn't a replacement for your IDE. It's a tool for specific moments:

Learning the language. Type a construct, see what it does, no friction.
Testing an API. Wondering what LocalDate.of(2026, 2, 31) does? Find out in two seconds instead of writing a test class.
Debugging a tricky expression. Isolate the line that's misbehaving and poke at it in isolation.
Prototyping. Sketch out a method, iterate on it interactively, then paste the working version into your project.

The thing I like most about JShell is that it removes the fear of experimentation. In a normal Java project, trying something feels expensive. In JShell, it costs nothing. You type, you see, you move on.

Quick Summary

JShell is a REPL that ships with the JDK. Type jshell to start it.
Snippets can be expressions, variables, methods, or classes. No main method required.
Forgot a semicolon? JShell adds it for you.
Scratch variables ($1, $2, ...) hold results you didn't name.
Redefine a method to change it. Other code picks up the new version.
/list, /vars, /methods, /save, /open, /reset, and /exit cover most of what you need.
Tab completion works for commands and code. /! reruns your last snippet.
Use /set feedback verbose while learning, then dial it back.
Save sessions with /save and reload them with /open.

Based on dev.java/learn — JShell: The Java Shell Tool

Google Paid $2.7B to Keep Its Best AI Researcher. He Left Anyway.

Md Jamilur Rahman — Sun, 21 Jun 2026 07:08:08 +0000

In 2024, Google paid $2.7 billion to bring Noam Shazeer back. Shazeer invented the transformer architecture, the foundation behind GPT, Gemini, and Claude. Google said: "We can't lose this person."

June 2026. Shazeer is leaving Google for OpenAI.

This isn't one person's story. It's a pattern. Google DeepMind's best researchers are walking out the door to AI startups, one by one.

Who Left?

Noam Shazeer — The man who invented the transformer. Co-lead of Google's Gemini model. Google paid $2.7 billion to buy him back from Character.AI. Now joining OpenAI. (Reuters, CNBC, The Information)

John Jumper — Co-creator of AlphaFold. Won the 2024 Nobel Prize alongside Demis Hassabis for protein structure prediction. Spent nearly nine years at Google DeepMind. Now joining Anthropic. (CNBC, Business Insider, the-decoder.com)

Ruoming Pang — Meta hired him for $200 million to lead their Superintelligence team. He jumped to OpenAI after just 7 months. (observer.com)

4 Apple AI researchers — Including Apple's top Siri leader, all departed. (MacDailyNews)

9 of 12 xAI co-founders — Left Musk's AI lab. (tech-insider.org)

Why Are They Leaving?

One thing is clear. The problem isn't pay. Google pays well. The problem is autonomy.

The Los Angeles Times reported that Google researchers are quitting over a "compute crunch" — internal competition for GPU access that slows down research and frustrates top talent. (LA Times)

At startups? Start an experiment today. Fail tomorrow. Try again. Nobody's stopping you.

OpenAI and Anthropic have another card to play — equity. Google has RSUs, but startup equity can be worth far more. OpenAI has filed for a US IPO, targeting a valuation of up to $1 trillion. Early equity holders could see massive payouts. (Reuters, Cybernews)

What Is Google Doing?

Google isn't sitting still.

1. Throwing money at retention
They paid $2.7 billion to bring Shazeer back. Two years later, he left again. Money can't hold people.

2. Compute advantage
Google has massive GPU clusters. Startups don't. But the LA Times report suggests even Google's compute advantage is causing internal friction — too many teams competing for the same resources.

3. Product momentum
Despite the exodus, Google's AI products remain strong. Gemini 2.5 is competitive. DeepMind continues publishing breakthrough research. Accenture recently expanded its partnership with Google Cloud for enterprise AI using Gemini. (Axios)

The question is whether product momentum can outlast the talent drain.

Why This Matters

Think about it. Noam Shazeer invented the transformer. That's the foundation of the AI revolution. That person is now working at OpenAI.

John Jumper cracked protein folding. Anthropic just picked him up.

Google spent billions on their research. When those researchers mature, they leave for other companies. The question is whether this brain drain eventually shows up in Google's products — or whether Google's scale and compute advantage compensate for it.

Demis Hassabis is still there. But the people around him are thinning out.

The question is — which path are you on? Big corporate, scrappy startup, or building something of your own? 🙏

Sources:

AI জুনিয়র ডেভেলপারদের চাকরি কমাচ্ছে বাংলাদেশের ফ্রেশারদের কী করতে হবে?

Md Jamilur Rahman — Sat, 20 Jun 2026 08:11:52 +0000

আমার এক ছোট ভাই CSE থেকে সদ্য পাস করেছে। ভালো CGPA, কোড লিখতে পারে, খুব উৎসাহী। সে আমাকে বললো "ভাইয়া, LinkedIn এ গত তিন মাসে শুধু জুনিয়র developer এর চাকরি খুঁজছি। কিন্তু যেখানে আগে ১০০টা posting থাকতো, এখন ৩০টা। বাকিগুলো কোথায় গেল?"

আমি একটাও উত্তর দিতে পারিনি। কারণ আমিও একই প্রশ্নে হারিয়ে ছিলাম। 😐

AI কি সত্যিই চাকরি খাচ্ছে?

ChatGPT, GitHub Copilot এরা কি সেই কাজগুলো করে দিচ্ছে, যেগুলো আগে একজন fresher শিখতো?

আমি গত কিছুদিন ধরে এই প্রশ্নের উত্তর খুঁজছি। Stanford এর report পড়েছি। BIDA, BASIS, BDPolicyLab সবার report নাড়াচাড়া করেছি। বাংলাদেশের উদ্যোক্তাদের, আন্তর্জাতিক expert দের কথা পড়েছি।

যা পেয়েছি শেয়ার করছি। আমার ছোট ভাইয়ের যা জানা দরকার, ঠিক তেমনি আপনারও।

গল্পটা এখান থেকে শুরু

একটু ভেবে দেখুন ২০২০ সালে আপনার প্রথম চাকরিতে কী করতেন?

Boilerplate কোড লিখতেন। Basic CRUD endpoints বানাতেন। Documentation লিখতেন। Stack Overflow থেকে error ফিক্স করতেন। দিন শেষে একটু শিখে ফেলতেন। পরের দিন আরেকটু। এভাবেই বড় হয়েছেন।

এখন কথা হলো এই কাজগুলো AI করে দিচ্ছে। কয়েক সেকেন্ডে। আর সত্যি বলতে, ভালো করে দিচ্ছে।

Inument এর Co-Founder মঞ্জুরুল আলম মামুন সম্প্রতি Facebook এ লিখেছেন একটা complex software product বানাতে আগে ১০ জন লাগতো। ১ জন PM, ১ জন Designer, ২ জন Frontend, ২ জন Backend, ১ জন QA, ১ জন DevOps, ২ জন Junior।

এখন? মাত্র ৩ জন AI সহ।

কারণ একজন skilled senior এখন code review করতে পারে, test লিখতে পারে, documentation বানাতে পারে, architecture review করতে পারে, deployment automate করতে পারে এমনকি design আর project management পর্যন্ত সামলাতে পারে।

মামুন ভাই একটা প্রশ্ন রেখেছেন "৭ বছর পর কী হবে?"

AI ঠিক কী বদলে দিচ্ছে?

কিন্তু কিছু কাজ আছে AI এখনো পারে না। পুরানো জটিল codebase বুঝে না। Production এ সমস্যা হলে debug করতে পারে না। Code review পারে না। "এই API null return করলে কী হবে?" এরকম প্রশ্ন করতে পারে না। (devshire.ai)

তাহলে যে কাজগুলো দিয়ে developer বড় হতো সেগুলো AI নিয়ে নিলো। আর যে কাজগুলো দরকারে লাগে সেগুলো AI পারে না।

এটাই আসল সমস্যা।

মামুন ভাই খুব পরিষ্কার বলেছেন যারা শুধু "execution" এ focus করে (কোড লেখা, bug fix, simple implementation), তারা ঝুঁকিতে। কারণ AI "execution" এ দ্রুত ভালো হচ্ছে।

এখন value হচ্ছে System Design, Product Judgment, Business Understanding, Architecture Decisions, Leadership, Problem Framing।

তার ভাষায় "কোড লেখা সহজ। কিন্তু সঠিক জিনিসটা build করা, সঠিক trade-off করা, problem frame করা এগুলোর value অনেক বেশি।"

Jensen Huang এর গল্প Radiologist এর উদাহরণ

Nvidia এর CEO Jensen Huang সম্প্রতি একটা খুব শক্তিশালী উদাহরণ দিয়েছেন। শুনুন —

১০-১২ বছর আগে Jeff Hinton বলেছিলেন প্রতিটা radiologist এর চাকরি যাবে। কারণ computer vision এখন superhuman। স্ক্যান পড়ার কাজটা AI করতে পারবে। তিনি সবাইকে বলেছিলেন "radiologist হবেন না। চাকরি শেষ।"

১০ বছর পর? তিনি একদম সঠিক ছিলেন। Computer vision এখন প্রতিটা radiology department এ আছে। ১০০% penetration।

কিন্তু সারপ্রাইজ, radiologist এর সংখ্যা বেড়েছে।

কেন?

Jensen বলছেন AI শুধু কাজের অংশ (task) বদলেছে, কাজের উদ্দেশ্য (purpose) না। Radiologist এর কাজ হলো স্ক্যান পড়া সেটা AI করছে। কিন্তু radiologist এর উদ্দেশ্য হলো রোগ নির্ণয় করা, রোগীর সাথে কথা বলা, ডাক্তারদের সাথে সমন্বয় করা, medical compliance মেনে চলা।

আর যেহেতু AI স্ক্যান পড়া এত দ্রুত করে দিয়েছে এখন আগের চেয়ে অনেক বেশি রোগী স্ক্যান করা যাচ্ছে। বেশি রোগী = বেশি আয় = বেশি radiologist দরকার।

Jensen এর কথায় "If you watch me do my job, if you have an AI watch me do my job... At the end of the week you say, what is Jensen's job? He's typing. He types. He talks to people. And so then you come to the conclusion that AI can type automatically, then Jensen's job is removed. And so that misses the purpose."

এই গল্পটা developer দের জন্যও একই। AI কোড লিখতে পারছে সেটা task। কিন্তু আপনার উদ্দেশ্য কী? System design করা, problem frame করা, business understand করা, team lead করা এগুলো AI replace করতে পারছে না।

সংখ্যাগুলো কী বলছে?

Stanford বলছে AI এর কারণে তরুণ ইঞ্জিনিয়ারদের সুযোগ ১৩% কমছে। আর সিনিয়রদের? সেটা বাড়ছে বা অন্তত stable আছে। (Stanford Digital Economy Lab)

২০২২ থেকে ২০২৬ চার বছরে জুনিয়র চাকরির posting ৬৭% কমেছে। IT তে নতুন নিয়োগের মাত্র ৭% জুনিয়র পদ। আগে ছিল ১৫%। (AlterSquare)

৬৭% একটু দাঁড়িয়ে ভাবুন। এটা কোনো ছোট সংখ্যা না।

কিন্তু একটা মোড় আছে।

২০২৬ এর জানুয়ারিতে ৮৪৭ জন hiring manager কে জিজ্ঞেস করা হলো। তাদের ৮৫% বললেন "হ্যাঁ, জুনিয়র নিয়োগ চালিয়ে যাচ্ছি।" (Markaicode)

তাহলে কি সব ঠিক আছে?

না। সমস্যা হলো চাকরিটা নিজে বদলে গেছে। কোম্পানিগুলো জুনিয়র নিচ্ছে, ঠিকই। কিন্তু এমন জুনিয়র চায় যে প্রথম দিন থেকেই AI tools দিয়ে কাজ করতে পারে।

"কাজ করতে করতে শিখবে" এই model টা আর চলছে না। "ইতিমধ্যে শিখে এসো" এটাই এখন নিয়ম।

বাংলাদেশের ছবিটা কেমন?

বৈশ্বিক কথা শুনলেন। কিন্তু আপনার তো চিন্তা আপনার দেশ নিয়ে। আমারও ছিল।

তাই বাংলাদেশের data খুঁজলাম। যা পেলাম আরো ইন্টারেস্টিং।

আমাদের দেশে স্নাতকদের বেকারত্ব ১৩.৫%। নারী স্নাতকদের ক্ষেত্রে সেটা ২০% এর কাছাকাছি। (nextjobz.com.bd)

প্রশ্ন এটা কি AI এর কারণে?

উত্তর না।

তরুণ স্নাতকদের বেকারত্ব ২০১৩ সালেই ছিল ৯.৭%। ২০২২ সালে সেটা গিয়ে দাঁড়ায় ২৭.৮%। AI tools তো তখন এত জনপ্রিয় ছিলই না। (Journal of Management and Business Education)

তার মানে, সমস্যাটা আগে থেকেই ছিল। AI শুধু সেটাকে জোরে চালিয়ে দিচ্ছে।

IT sector এর দিকে তাকাই। বাংলাদেশে ৫ লাখ+ IT professional আছে। ৪,৫০০+ কোম্পানি। ৬.৫ লাখ+ freelancer। IT services market $২.১ billion বছরে ১১.৮% করে বাড়ছে। (BIDA)

কিন্তু BASIS বলছে IT sector এ ৪০% skills gap আছে। কোম্পানিগুলো কাজের মানুষ পাচ্ছে না। ডিগ্রি আছে সবার। প্র্যাকটিক্যাল skill নেই কারো। (nextjobz.com.bd citing BASIS)

আমার ছোট ভাই যখন LinkedIn এ চাকরি খুঁজছিল সমস্যাটা হয়তো posting কমার কারণে না। সমস্যাটা হতে পারে কোম্পানিগুলো ঠিকই hiring করছে, কিন্তু এমন মানুষ খুঁজছে যাদের কাছে সে রকম skill নেই।

চাকরি আছে। যোগ্য মানুষ নেই। এটাই আসল কথা।

Freelancing দরজাটা কি বন্ধ হচ্ছে?

বাংলাদেশের অনেকের জন্য freelancing ছিল প্রথম দরজা। যাদের চাকরি মেলেনি তারা Upwork বা Fiverr এ কাজ শুরু করেছে। সেখান থেকে বড় হয়েছে।

বাংলাদেশ প্রতি বছর freelancing থেকে $৫০০ মিলিয়ন+ আয় করে। এটা হাসি-খুশি সংখ্যা না।

কিন্তু AI ক্লায়েন্টদের চাহিদা বদলে দিচ্ছে।

Freelance writing এর posting ৩৩% কমেছে। Translation এর কাজ ১৯% কমেছে। Customer support এর পদ ১৬% কমেছে। ঠিক সেই কাজগুলো, যেগুলো দিয়ে বাংলাদেশি freelancer রা শুরু করতো। (WINTK)

কিন্তু একই সময়ে Upwork এ generative AI এর job posting ১০০০%+ বেড়েছে। (The Business Standard)

দরজাটা বন্ধ হচ্ছে না। দরজাটা বদলাচ্ছে। যারা basic skill নিয়ে আছেন তাদের জন্য সরু হচ্ছে। যারা AI skill শিখছেন তাদের জন্য আরো প্রশস্ত হচ্ছে।

টাকার কথা একটু বলি

সত্যি বলতে, সাধারণ developer আর AI developer এর বেতনের গ্যাপ প্রতি দিন বাড়ছে।

লোকাল কোম্পানিতে সাধারণ জুনিয়র developer এর বেতন ৳২৫,০০০ – ৳৪৫,০০০/মাস। সিনিয়র হলে ৳৮০,০০০ – ৳১,৬০,০০০+। (Kaz Software)

কিন্তু AI/ML developer? জুনিয়র থেকেই শুরু ৳৩৫,০০০ – ৳৮০,০০০/মাস। সিনিয়র হলে ৳১,৫০,০০০ – ৳৩,০০,০০০+। আর remote international চাকরি? ৳৪,০০,০০০ – ৳১০,০০,০০০+/মাস। (Nucamp)

৩০-৫০% বেশি। skill আর market এর পার্থক্য।

একটু ভেবে দেখুন আগামী ৫ বছর কোন দিকে যাচ্ছেন সেটার ওপর নির্ভর করছে আপনার আয়।

একটা বড় ঝুঁকি কিন্তু কেউ কথা বলছে না

এখন কোম্পানিগুলো যদি জুনিয়রদের কম নেয় তাহলে ৫ বছর পর সিনিয়র কারা হবে?

AWS এর CEO Matt Garman বলেছেন AI দিয়ে জুনিয়রদের replace করা "সবচেয়ে বোকা কাজগুলোর একটা।" কিন্তু hiring data দেখাচ্ছে কোম্পানিগুলো ঠিক সেটাই করছে।

মঞ্জুরুল আলম মামুন তার post এ একটা কথা বলেছেন যা খুব ভেবে দেখার মতো —

"Today's Junior Engineers = Tomorrow's Missing Seniors."
"AI can generate code. It cannot generate experience."

একদম। কোড AI লিখতে পারে। কিন্তু experience কি AI দিতে পারবে? পারবে না। Experience লাগে বছরের পর বছর কাজ করে, ভুল করে, শিখে।

কিন্তু যদি জুনিয়ররা কাজ করার সুযোগই না পায় তাহলে experience কোথা থেকে আসবে?

২০৩০-৩২ সালের দিকে experienced engineer এর অভাব দেখা দেবে। সিনিয়র বেতন আরো বাড়বে। Team structure দুর্বল হবে। (AlterSquare)

মানে, আজকে যে সিনিয়রদের চাহিদা বাড়ছে, ৫ বছর পর সেই সিনিয়রদের অভাব হবে। কারণ জুনিয়ররা বড় হওয়ার সুযোগই পাচ্ছে না।

ঠিক আছে তাহলে কী করবেন?

আমি data দেখে যা বুঝেছি সোজা ভাষায় বলছি।

১. AI এর কোড যাচাই করা শিখুন

৬৩% developer বলছে AI generated code debug করতে নিজে লেখার চেয়ে বেশি সময় লাগে। মানে AI ভুল করছে। আর সেই ভুল ধরার কাজটাই এখন সবচেয়ে দামি skill। (byteiota)

কীভাবে শিখবেন? আজই শুরু করুন ChatGPT কে একটা জটিল প্রবলেম দিন। যে কোড সে লিখছে সেটা নিজে যাচাই করুন। ভুল খুঁজুন। প্রতিদিন একটু করে।

২. Tutorial বন্ধ করুন real project বানান

Handshake এর survey দেখাচ্ছে ৩ মাসের মধ্যে চাকরি পাওয়া স্নাতকদের ৭৮% এর কাছে শক্তিশালী GitHub portfolio, internship, বা certification ছিল। শুধু ডিগ্রি নিয়ে? মাত্র ৩১% সফল হয়েছে। (FinalRoundAI)

মানে, ডিগ্রি আর যথেষ্ট না। আপনার কাজ দেখতে চায় কোম্পানি।

৩. Execution থেকে বেরিয়ে আসুন System Design শিখুন

মামুন ভাই যা বলেছেন সেটা মনে রাখা দরকার। শুধু কোড লেখা, bug fix, simple implementation এগুলো AI করছে। এগুলো "execution" skill। এগুলোর value কমছে।

এখন value হচ্ছে System Design, Product Judgment, Business Understanding, Architecture Decisions, Problem Framing।

মানে, "কীভাবে কোড লিখবো" না, "কী build করবো আর কেন build করবো" সেটাই এখন প্রশ্ন।

৪. AI-fluent হোন

AI skill এখন ৪২% software job description এ আছে। ২০২২ সালে ছিল মাত্র ৮%। যারা AI পারে তারা ২.৩ গুণ দ্রুত চাকরি পান। (FinalRoundAI)

২.৩ গুণ। একটু ভাবুন।

৫. এমন sector বেছে নিন যেখানে AI replace করতে পারে না

বাংলাদেশে তিনটা sector এখন খুব ভালো:

Fintech bKash, Nagad, SSLCommerz। Compliance এর জন্য human oversight লাগবেই। AI একা চালাতে পারবে না।
Telecom Grameenphone, Robi। বিশাল data infrastructure।
RMG tech Supply chain আর quality inspection।

এই sector গুলোতে AI সাহায্য করবে। কিন্তু replace করবে না।

৬. Remote চাকরির কথা ভাবুন

লোকাল জুনিয়র বেতন ৳২৫,০০০–৪৫,০০০/মাস। Remote international চাকরি শুরু $২০K–$৫০K/year। সেটা বছরে প্রায় ২৩–৫৮ লাখ টাকা।

একই কাজ। ভিন্ন বেতন। পার্থক্যটা শুধু skill আর কোন মার্কেটে আপনি নিজেকে present করছেন।

৭. একটা domain এ গভীরে যান

সাধারণ "MERN stack developer" এখন replaceable। কিন্তু fintech developer? Telecom engineer? AI specialist? তারা না।

একটা domain বেছে নিন। ১৮–২৪ মাস সেটাতে গভীরে যান। Surface level আর কেউ মানে না।

শেষ করি একটা সুখবর দিয়ে

এত কথা শুনে হয়তো ভাবছেন সব শেষ। তাই না?

ভুল ভাবছেন।

বাংলাদেশের AI market প্রতি বছর ২৫–৩০% বাড়ছে। ২০৩০ সালে $৮০M থেকে $২৩০M+ হওয়ার projection আছে। (Nucamp citing Statista)

আরেকটা জিনিস মাত্র ২৮% organization সত্যি সত্যি AI দিয়ে তাদের workflow বদলাতে পারে। ৮৮% হয়তো AI adopt করেছে। কিন্তু কাজে লাগাতে পারছে না।

"AI use করা" আর "AI দিয়ে কাজ করা" এই দুটোর মধ্যে যে gap আছে সেটাই আসল টাকার জায়গা। আর সেই gap পূরণ করতে পারে এমন মানুষ তার অভাব আছে।

BDPolicyLab বলছে বাংলাদেশের ৪৪ লাখ worker এমন occupation এ আছে যেখানে AI impact পড়বে। (BDPolicyLab)

৪৪ লাখ। এর মানে, ৪৪ লাখ মানুষের কাজ বদলবে। যারা আগে থেকে প্রস্তুত তারা এগিয়ে যাবে। যারা না তারা পিছিয়ে পড়বে।

আমার ছোট ভাইকে আমি শেষে যা বলেছি সেটাই আপনাকেও বলছি।

পুরোনো পথ "basic শেখো, জুনিয়র চাকরি নাও, কাজ করতে করতে বড় হও" সেটা বন্ধ হয়ে আসছে। AI tools সেই কাজগুলো নিজে করে ফেলছে।

নতুন পথ আলাদা। AI tools ভালো করে শিখুন। Real project বানান। AI এর কোড validate করুন। Execution থেকে উঠে এসে System Design শিখুন। একটা domain এ specialized হোন। Remote চাকরি লক্ষ্য করুন।

কথা হলো AI কোড লিখতে পারে। কিন্তু experience দিতে পারে না। experience আসবে কাজ থেকে। কাজ পাওয়ার জন্য দরকার এমন skill যা AI শিখতে পারে না।

Data স্পষ্ট বলছে কোম্পানিগুলো ২০২৬ সালেও জুনিয়র নিয়োগ করছে। কিন্তু শুধু তাদেরই যারা প্রথম দিন থেকেই AI tools দিয়ে কাজ করতে পারে।

প্রশ্ন হলো আপনি কোন দিকে যাচ্ছেন? 🙏

সূত্র:

Norway Just Banned AI in Elementary Schools. Here's What That Actually Means.

Md Jamilur Rahman — Sat, 20 Jun 2026 02:05:51 +0000

Norway imposed a near-ban on generative AI for students in grades one through seven. That's kids aged six to thirteen. No more ChatGPT for writing assignments, no more AI-powered brainstorming on school devices. The Reuters story dropped June 19 and the HN thread hit 449 points with 292 comments, which tells you people have feelings about this.

I've been going back and forth on it all day. Part of me thinks it's obviously right. Part of me thinks it's a surrender.

What Norway Actually Did

The policy splits students into three tiers:

Grades 1–7 (ages 6–13): No generative AI, as a general rule. Full stop.
Grades 8–10 (ages 14–16): Can use AI tools cautiously, under teacher supervision.
Grades 11–13 (ages 17–19): Should learn to use AI so they're prepared for work and further education.

This isn't a one-off experiment. In 2024, the Norwegian government banned smartphones from schools and gave teachers more authority to enforce discipline. The AI ban follows the same logic: test scores have been declining, and screens aren't helping.

When the government says students need to "learn to read, write and comprehend text" without AI shortcuts, they're responding to something real.

What a Norwegian Parent Actually Saw

A HN commenter named bendriv, a parent with three kids in school, gave the most useful firsthand account. ChatGPT was whitelisted on school iPads. Teachers were using it for writing assignments, brainstorming, and even speeches.

The school-provided iPads had chatgpt.com whitelisted. Teachers were handing students AI-generated exercises that were, in another parent's words, "quite frankly entirely wrong."

A parent called a meeting with their daughter's math teacher to point out the errors. The teacher's response? They questioned the parent's knowledge because "AI is foolproof."

That's the part nobody talks about. Teachers themselves often don't understand what the tools are doing. They're not evaluating the output — they're assuming it's correct because it looks confident.

The Equity Problem Nobody Wants to Discuss

A HN commenter named Jimmc414 put this bluntly:

A school ban doesn't ban AI at home. It bans the equalizing version. Kids in educated, rich households will get AI exposure from parents. Kids without that won't get it anywhere.

This is a real problem. If wealthy families are teaching their kids to use AI tools effectively while poorer families can't, the school was the one institution that could narrow the gap. Removing it doesn't help.

I don't have a clean answer for this. Neither does anyone else, which is probably why Norway didn't ban AI for older students. They're making a judgment call: kids under 13 need foundational skills first. The tools can wait.

What the Evidence Actually Says

A commenter named JumpCrisscross pointed out: "We have mounting evidence AI hurts learning and cognition in many circumstances. I have not yet seen similar-quality evidence for it helping."

That's not entirely true — there are studies showing AI tutors can help with certain types of math learning when used correctly. But the research on young children and generative AI is thin, and what exists is mixed.

The teacher subreddit r/teachers isn't a scientific study, but it's a useful temperature check. Teachers there describe AI as a "disaster for student outcomes." Students turn in obviously AI-written work, lose the ability to structure their own arguments, and become dependent on the tools for basic tasks.

One commenter nailed it: "AI is both the best technology ever invented for avoiding learning, and the best technology ever invented for learning."

For adults who already know how to think, AI is a productivity multiplier. For kids who are still learning how to think, it might be a crutch that never gets removed.

What Are Schools Actually For?

simonw in the HN thread: "Kids under 13 need to learn to read, write and comprehend text. Generative AI is not going to help them with those skills."

He's right. But the deeper question is harder. If AI is going to be everywhere in these kids' adult lives — at work, in creative projects, in everyday decision-making — is it better to introduce it early so they learn to use it critically? Or build the foundations first, then add the tools?

Norway chose the second option. I'm not sure they're wrong, but I'm not sure they're right either.

The gifted student take is interesting. One commenter argued that if Norway can't harness AI, there's something deeply wrong with the education system. There's something to that — a system that can't integrate new tools without breaking was probably already fragile.

But that assumes the system can integrate AI without breaking. The evidence so far suggests it can't, at least not for young kids.

What Happens Next

Norway is the first country-level ban targeting children. Other Nordic countries are watching. Germany and France are debating similar restrictions. The UK has gone the opposite direction, encouraging schools to integrate AI. The US has no federal policy — individual districts are making it up as they go.

Norway's smartphone ban of 2024 became a model other countries studied. The AI ban might follow the same path. Or it might make Norway an outlier that everyone points to but nobody copies.

For anyone building edtech: the market for AI tools in elementary schools just lost its largest early adopter. Tools that give teachers control — monitoring, filtering, guided use — are probably more viable now than tools that hand students direct access. Norway's Sikt system, which lets teachers monitor AI use, is a model for this.

The Part I Keep Coming Back To

I don't think Norway is overreacting. The evidence that AI helps young kids learn is weak. The evidence that it hurts is growing. And the teachers actually in classrooms, not the ones writing think pieces, are worried.

But a ban isn't a solution. It's a pause. Norway is buying time while it figures out what AI in elementary education should look like. The question is whether other countries use that time wisely or keep pretending the problem doesn't exist.

Five years from now, when today's second graders are in middle school, we'll have some data on whether this helped. That's not a satisfying answer. But it's an honest one.

Based on Reuters reporting (June 19, 2026) and HN community discussion (449 points, 292 comments).

How the Java Launcher Works — Running Programs Without Compiling First

Md Jamilur Rahman — Fri, 19 Jun 2026 02:03:31 +0000

You know the drill. Write code, compile it, run it. Write code, compile it, run it. Over and over. What if you could skip the middle step entirely?

Since JDK 11, Java lets you run a source file directly — no separate javac step needed. The java launcher handles compilation behind the scenes. And as of JDK 22, this works with multi-file programs too.

Let me walk through how it works, when to use it, and where it breaks down.

Single-File Source-Code Programs

Create a file called HelloWorld.java:

public class HelloWorld {
    public static void main(String[] args) {
        IO.println("Hello World!");
    }
}

Instead of running javac HelloWorld.java followed by java HelloWorld, you just run:

$ java HelloWorld.java

That's it. The launcher compiles the file in memory and runs it. No .class file gets written to disk.

This works because the java launcher automatically invokes the Java compiler when you pass it a .java file. The compiled bytecode lives in memory for the duration of the program.

Passing Arguments

You can pass arguments the same way you would with a compiled class:

public class HelloJava {
    public static void main(String[] args) {
        IO.println("Hello " + args[0]);
    }
}

$ java HelloJava.java World!

Output:

Hello World!

Nothing special here — the launcher forwards arguments to your main method just like normal.

Multiple Classes in One File

Sometimes you want a helper class alongside your main class. That works fine:

public class MultipleClassesInSameFile {
    public static void main(String[] args) {
        IO.println(GenerateMessage.generateMessage());
        IO.println(AnotherMessage.generateAnotherMessage());
    }
}

class GenerateMessage {
    static String generateMessage() {
        return "Here is one message";
    }
}

class AnotherMessage {
    static String generateAnotherMessage() {
        return "Here is another message";
    }
}

$ java MultipleClassesInSameFile.java

Output:

Here is one message
Here is another message

The first class in the file must have the public static void main method. The other classes can be package-private.

Multi-File Programs (JDK 22+)

JDK 22 added JEP 458, which lets the java launcher work with programs spread across multiple files and directories.

Say you have this structure:

project/
├── Main.java
├── model/
│   └── Person.java
└── service/
    └── PersonService.java

Main.java:

import model.Person;
import service.PersonService;

public class Main {
    public static void main(String[] args) {
        PersonService service = new PersonService();
        Person person = service.createNewPerson();
        IO.println(person.printName() + " has been created!");
    }
}

As long as model/Person.java and service/PersonService.java exist in subdirectories matching their package structure, the launcher will compile and load everything:

$ java Main.java

You can structure your code properly without setting up a build system. That matters more than it sounds — the jump from single-file programs to multi-file projects used to require a build tool right away.

Using JDK Classes

Any class from the standard JDK libraries works out of the box. No classpath configuration needed:

import java.util.Scanner;
import java.util.regex.MatchResult;

public class ScannerExample {
    public static void main(String... args) {
        String wordsAndNumbers = """
            Longing rusted furnace
            daybreak 17 benign
            9 homecoming 1
            freight car
            """;
        try (Scanner scanner = new Scanner(wordsAndNumbers)) {
            scanner.findAll("benign").map(MatchResult::group).forEach(IO::println);
        }
    }
}

$ java ScannerExample.java

The Scanner and MatchResult classes come from java.util, which is part of the JDK, so no extra setup is required.

External Libraries Need the Classpath

If your code depends on a library that is not part of the JDK, you still need to add it to the classpath manually:

import org.apache.commons.lang3.RandomUtils;

public class ReferenceNonJDKClass {
    public static void main(String[] args) {
        IO.println(RandomUtils.nextInt());
    }
}

$ java -cp /path/to/commons-lang3-3.12.0.jar ReferenceNonJDKClass.java

The -cp flag tells the launcher where to find the external JAR. This is one limitation of the direct-launch approach — it does not resolve dependencies for you. For anything beyond simple programs, you will eventually want a build tool like Maven or Gradle.

Shebang Files: Java as a Script

On Unix-like systems (Linux, macOS), you can run a single-file Java program like a shell script. Add a shebang line as the first line of your file:

#!/path/to/your/bin/java --source 26

public class HelloJava {
    public static void main(String[] args) {
        IO.println("Hello " + args[0]);
    }
}

Two requirements:

The file cannot have a .java extension (try something like hello)
You need to make it executable: chmod +x hello

Then run it like any other script:

$ ./hello Maria

This is handy for small utility scripts. Instead of writing bash or Python, you can write a quick Java program and run it directly from the terminal.

Be careful though — if you forget to pass an argument when the program expects one, you will get an ArrayIndexOutOfBoundsException. There is no safety net here.

When to Use This

Direct source-file execution is great for:

Learning and experimentation. Trying out a new API or Java feature without creating a full project.
Quick scripts. Shebang files turn Java into a viable scripting language for small tasks.
Teaching. No build tool setup means beginners can focus on the language, not the toolchain.
Prototyping. Multi-file support (JDK 22+) lets you structure code properly while still skipping the build step.

It is not a replacement for a proper build system. Anything that needs external dependencies, tests, or packaging should use Maven or Gradle. But for quick, self-contained programs, the java launcher saves you real time.

Summary

The java launcher can compile and run .java files directly without a separate javac step.
The compiler runs in memory — no .class files are written to disk.
You can pass arguments, define multiple classes in one file, and import JDK classes freely.
JDK 22 added multi-file support, letting you structure code across directories.
External libraries still need the -cp classpath flag.
On Unix systems, shebang files let you run Java programs like shell scripts.
Use this for learning, scripting, and prototyping. Use a build tool for everything else.

Based on dev.java/learn — https://dev.java/learn/launch-simple-source-code-programs/