DEV Community: Md Jamilur Rahman

35% of Workers Say AI Will Do Most of Their Job Within a Year. Anthropic's Own Data Proves Them Right.

Md Jamilur Rahman — Thu, 09 Jul 2026 09:32:02 +0000

Anthropic just published the most detailed look yet at how AI is reshaping work. The June 2026 Anthropic Economic Index report, based on millions of Claude conversations and a survey of 9,700 users, reveals a workforce that knows the ground is shifting under its feet.

Over one third of respondents expect AI to handle most or nearly all of their work tasks within 12 months. The people who delegate the most to AI are the most optimistic about their careers. And the youngest workers are the most afraid of losing their jobs.

These are not predictions from pundits. This is data from the company that builds one of the world's most capable AI models, drawn from real usage patterns and direct survey responses. (Anthropic Economic Index)

What the Economic Index Actually Measures

Anthropic launched the Economic Index in early 2026 to track how people use Claude across every US state and hundreds of occupations. The June 2026 report, titled "Cadences," is the fourth installment and the most ambitious. It introduces three new data sources: hourly usage sampling, an output classifier that labels what each conversation produces, and the Economic Index Survey. (Anthropic, June 2026 Report)

The dataset is public. Anthropic publishes it on HuggingFace, and the full methodology is in an open appendix. This is not a black-box study.

Finding 1: Your Workweek Is Etched Into AI Usage

Claude usage mirrors the workweek with striking precision. On weekdays, roughly 35% of conversations are personal. On weekends, that jumps to nearly 50%. Business correspondence, marketing copy, and slide decks give way to emotional support, medical questions, and investment advice.

The hourly data is even more revealing. People ask for news at 7 a.m. Business correspondence peaks at 10 to 11 a.m. Recipe requests spike to 2.3 times the average at 6 p.m. Sleep advice peaks around 5 a.m. Tax-related conversations surged to 8 times the average on April 14, the day before the US filing deadline, then dropped sharply on April 16.

On weekends, when people do turn to Claude for work, the tasks skew toward higher-wage occupations. Tasks related to jobs in the bottom two wage quartiles, like telemarketing and clerical work, shrink. This pattern holds even when you remove computer and mathematical occupations entirely. People in higher-paying jobs work more outside traditional hours, and they bring AI with them.

Finding 2: Higher-Wage Work Costs More Compute

Conversations mapped to higher-wage occupations consume more tokens. A lot more. Marketing managers earn roughly twice what editors earn ($80 vs. $37 per hour), and their Claude conversations consume approximately 2.5 times as many tokens.

This is not just because higher-wage work is more complicated. It is also because people in those roles produce more with Claude (1.34 times as much output per turn), engage in more turns (1.53 times as many), and enable extended thinking more often (34% of conversations versus 31%).

The key insight: more Claude production does not mean less human production. Users who get more from Claude also put more in. The pattern looks like labor augmentation, not labor displacement. At least for now.

About 44% of the wage gradient in token consumption is explained by output mix. Higher-wage occupations simply produce more compute-intensive artifacts. Building an app consumes more than 3 times the tokens of the median conversation. A typical explanation uses about a fifth.

Finding 3: Claude Code Changes Everything About How People Work

The report introduces a 1-to-5 autonomy scale measuring how much decision-making power Claude has in a conversation. Across 26 of 31 output types, Claude Code sessions show higher autonomy than chat or Cowork sessions.

The difference is stark. Blog posts and articles illustrate it. On chat, the median blog post conversation involves 13 rounds of back-and-forth. On Claude Code, the median session contains a single human prompt. The person writes one instruction, and Claude builds the entire thing.

Approximately two thirds of the autonomy gap comes from the same tasks being executed with more delegation on Claude Code. The remaining third comes from a different mix of output types.

This matters because Claude Code runs on the most capable models far more often (54% on Opus, versus 10% of chat sessions). But even when you compare conversations served by the same model, the autonomy gap persists. Sonnet sessions on Claude Code still show 0.26 points more autonomy than Sonnet sessions on chat. The product, not just the model, determines how much people delegate.

Finding 4: 35% Expect AI to Do Most of Their Job Next Year

This is the headline number from the Economic Index Survey. Close to 6 in 10 respondents chose a higher capability band for next year than for today. Over one third expect AI to be able to do most or nearly all of their work tasks within 12 months.

Here is the twist: the people who delegate the most to Claude are the most optimistic about their own careers. Across six dimensions of job quality (pay, job security, ability to find a job, meaning, autonomy, and human interaction), people with a higher share of automated sessions feel more positive about AI's effect on their work. The largest effects are on expectations about future pay and job-finding ability.

Large majorities report productivity gains: 86% say AI makes them faster, 82% say it expands their scope, 69% say it improves quality. And 57% say AI has made their skills more valuable. This rises with automation share. Heavier delegators report learning at the same rate as everyone else.

The study authors acknowledge a selection problem. Maybe the people most enthusiastic about AI are also the most willing to delegate. They cannot rule it out. But the pattern holds even when controlling for user tenure on Claude, a proxy for early adoption enthusiasm.

Finding 5: Young Workers Are Scared

Early-career workers report that AI can do the highest share of their work and express the most concern about job loss. Respondents were especially worried about job loss for junior colleagues: over one third said the probability of a junior colleague losing their job in the next year was above 60%.

This lines up with Anthropic's earlier labor market research. A separate study using Current Population Survey data found a 14% drop in the job-finding rate for workers aged 22 to 25 in the most AI-exposed occupations since ChatGPT launched. The effect is just barely statistically significant, but the direction is consistent. (Anthropic, Labor Market Impacts)

The mechanism appears to be slowed hiring, not increased layoffs. Young workers are not being fired. They are simply not being hired into the most exposed roles at the same rate.

Finding 6: The Global Divide Is Real

Per-capita Claude usage varies enormously across countries. Australia tops the index at 6.4, followed by Singapore at 5.81, Switzerland at 5.02, and Luxembourg at 4.85. The United States sits at 3.87. India, despite being the second-largest market by total volume, scores 0.30 on the per-capita index. Bangladesh scores 0.11.

Workers in lower-income countries report that AI can do a larger share of their tasks. This is consistent with the IMF's analysis that while advanced economies face broader AI exposure, workers in developing nations may have less access to the complementary skills and infrastructure that turn AI from a replacement into an augmentation tool. (IMF, AI and the Future of Work)

In Anthropic's earlier work, they documented that lower-income economies use Claude in more automated ways, even after adjusting for differences in task mix. The pattern is clear: where AI substitutes for tasks rather than augmenting them, the risks of displacement are higher.

Finding 7: Women Use AI Differently

Women make up only 12% of the survey's linked respondent sample. Even after accounting for occupational differences, women use Claude differently from men. Their share of sessions in Claude Code is 0.24 standard deviations lower. Their automation share is 0.33 standard deviations lower. Instead, women tend to use Claude more iteratively, logging more active time on chat.

The study does not speculate on why. But the pattern is consistent across occupational controls. Women collaborate with AI. Men delegate to it.

The Bigger Picture: No Unemployment Spike Yet

Despite all these signals, Anthropic's labor market research finds no systematic increase in unemployment for workers in highly AI-exposed occupations since late 2022. The difference-in-differences estimate is small and statistically insignificant.

This does not mean AI is not affecting jobs. It means the effect has not yet shown up in aggregate unemployment data. The BLS projects slower growth for occupations with higher observed exposure: for every 10 percentage point increase in AI coverage, projected employment growth drops by 0.6 percentage points. But projections are not outcomes.

The most exposed occupations include computer programmers (75% task coverage), customer service representatives, and data entry keyers (67%). The least exposed include cooks, motorcycle mechanics, and bartenders, where 30% of workers have zero AI coverage.

What People Actually Hope For

The survey ends with an open-ended question: what do you hope an economy shaped by AI looks like in ten years? The top five themes:

AI augmentation of meaningful work (over half of respondents). Collaboration, not replacement.
Automation of drudgery (just over half). Freeing time for what matters.
Shared prosperity (about one third). The gains should not concentrate at the top.
New industries and opportunities. Hope that AI creates, not just destroys.
Human connection preserved. The relational and interpersonal parts of work matter.

These are not the hopes of people who have given up. They are the hopes of people who use AI every day and want it to make their work better, not make their work irrelevant.

What This Means for You

Three takeaways for anyone watching this space:

Learn to delegate, or learn to collaborate. The data shows that people who delegate more to AI are more optimistic about their careers. This could be selection bias, but the consistency of the finding across multiple controls suggests something real. The workers thriving with AI are not avoiding it. They are leaning in.

Junior roles are the canary. If AI displaces work, it will show up first in entry-level hiring. The 14% drop in job-finding rates for young workers in exposed occupations is the strongest early signal in the data. If you are early in your career, focus on skills that require judgment, context, and human relationships, the things the survey respondents themselves say AI cannot do.

Where you live matters. AI augments in high-income countries and substitutes in low-income ones. If your economy lacks the infrastructure, training, and institutional support to turn AI into a productivity multiplier, the same technology that creates opportunity elsewhere can eliminate it where you are.

Anthropic has done something rare here. They built a public dataset, published their methodology, and shared findings that complicate their own commercial narrative. The data does not say AI is replacing everyone. It also does not say AI is harmless. It says the impact is uneven, early, and accelerating.

The full report is at anthropic.com/research/economic-index-june-2026-report. The dataset is on HuggingFace. The interactive dashboard is at anthropic.com/economic-index.

Sources:

The Postgres Creator Says LLMs Score 0% on Real Databases

Md Jamilur Rahman — Wed, 08 Jul 2026 05:42:30 +0000

Mike Stonebraker has been right before. He built Ingres in 1972, then Postgres in the 1980s, then predicted the death of general-purpose databases in 2005. Every time, the industry caught up years later. Now he is saying something that should make every company betting on "chat with your data" very nervous.

In a recent interview on the Data Renegades podcast, the Turing Award winner revealed that LLMs score 0% accuracy on real-world data warehouse queries. Not 80%, which is what the popular benchmarks report. Zero.

Watch the full interview

The 80% benchmark is a lie

The text-to-SQL leaderboard tells a reassuring story. On popular benchmarks like Spider and Bird, the best LLM systems hit 80-85% accuracy. Impressive. Almost production-ready.

Stonebraker tested the same models on four real production data warehouses. Not synthetic data. Not academic datasets. Actual enterprise systems with actual workloads from actual users.

The result: 0% accuracy. Add RAG and every trick in the book: 10%. Hand the model the exact FROM clause and all JOIN terms on a silver platter: 35%.

A knowledgeable SQL programmer with access to the schema? 90%+.

This is not a small gap. This is the difference between "almost there" and "does not work at all."

Why real databases break LLMs

Stonebraker identified four reasons the benchmarks are meaningless for production use:

1. Enterprise data is not in the training set. LLMs are trained on "the pile," the massive web corpus. Your data warehouse is not in the pile. And if an LLM has not seen data a couple times before, it has almost no chance of reasoning about it correctly.

2. Real queries are 5x more complex. Spider and Bird benchmarks use queries that are 10-20 lines of SQL. Real data warehouse queries run 100+ lines. The complexity scales non-linearly.

3. Real schemas are a mess. Academic benchmarks have clean, mnemonic table and column names like employees.salary. Real data warehouses have materialized views everywhere (creating redundancy), column names like ZUPPERS_BLAH, and idiosyncratic naming conventions built up over decades.

4. Idiosyncratic data. Stonebraker gives the example of "J-term" at MIT, a one-month January term. Not unique to MIT, but not common enough to appear in training data. Every enterprise has dozens of such domain-specific concepts that no LLM has ever seen.

Stonebraker published these benchmarks as BEAVER, an anonymized version of the four real data warehouses, available on arXiv. His message to AI researchers: "If you think you're really good at text-to-SQL, try a real benchmark, not a fake one."

The Oracle playbook, 1980s edition

Stonebraker has seen tech hype cycles before. He built Ingres at Berkeley in 1972 and commercialized it in 1980. The competition was Larry Ellison's Oracle.

His assessment of how Oracle competed is blunt. "Larry Ellison is a fabulous salesman. He made present tense and future tense indistinguishable. He basically lied to customers."

The example he gives is telling. Ingres implemented referential integrity, the database constraint that ensures data consistency (if you fire the last employee in a department, should the department still exist?). Oracle wrote two manual pages defining referential integrity, then added at the bottom: "Not yet implemented."

Customers bought Oracle anyway. The feature was on the roadmap. The documentation existed. The code did not. Sound familiar? It is the same playbook playing out today with AI companies shipping demos of capabilities that do not work in production.

"One size fits none"

In 2004, Stonebraker published a paper arguing that general-purpose databases were doomed. "One Size Fits All: An Idea Whose Time Has Come and Gone" (Brown University PDF) showed that specialized engines outperformed general-purpose systems by an order of magnitude in specific workloads.

Column stores like Vertica and ClickHouse destroy row stores for analytics. Stream processors like StreamBase (which Stonebraker also built) bear no resemblance to relational databases. Pinecone is faster than user-defined types on Postgres for vector search.

His take on Postgres today is surprisingly honest: "At the low end, it's absolutely the right one-size-fits-all. At the high end, that's just not true." Postgres has no column store, no multi-node support, and is not competitive for sizable data warehouses. For getting started, it is the right choice. For petabyte-scale analytics, it is table stakes that it does not have.

The most controversial take: computer science may not be a growth industry

At 83, Stonebraker has no incentive to be cautious. When asked what he would major in if starting today, his answer was blunt:

"Computer science may well not be a growth industry going forward. I'm not sure I would recommend 18-year-olds to major in computer science. Health care and the building trades are safe bets. Everything else looks much riskier."

This from the man who built the database that runs much of the internet.

His reasoning is consistent with his entire career. He has always bet against incumbents and conventional wisdom. The conventional wisdom in 2026 is "learn to code, AI will just make you faster." Stonebraker's counter: if AI makes every coder 10x faster, you need 10x fewer coders. The math is not complicated.

DBOS: Replacing the operating system with a database

Stonebraker's current project is DBOS (Database-Oriented Operating System), born from a collaboration with Matei Zaharia, the creator of Apache Spark and co-founder of Databricks. The insight: Databricks was scheduling a million Spark jobs at any given time, and no existing OS scheduler could handle that scale. So they put all the scheduling data in Postgres and let a database application do the scheduling.

Then it clicked. Most of what an operating system does is manage data at scale. Why not replace the upper half of Linux with a database?

The academic project showed that a file system built on top of a DBMS is faster than the Linux file system. The scheduling engine is competitive. Everything fails over automatically. High availability comes for free.

When Stonebraker mentioned this to OS folks, "they got very, very threatened. The database guys are trying to take over their turf." Same reaction from programming language folks when he suggested the runtime for a programming environment should be a database.

DBOS is now a commercial product (dbos.dev), offering durable workflows in TypeScript, Java, Go, and Python. Two-thirds of their customers are building agentic AI. The key insight: most agentic AI today is read-only (generate a prediction). But it is moving to read-write, and that is a distributed database problem. You want atomicity, consistency, and transactions. Moving $100 between accounts using two AI agents requires both to commit or both to roll back. That is what databases were built for.

What this means for engineers

Three takeaways from Stonebraker's career and current work:

1. "Chat with your database" is not production-ready. The benchmarks are gamed. Real enterprise data is messy, complex, and full of domain-specific knowledge that LLMs have never seen. If you are building a product that depends on text-to-SQL working reliably, test it on your actual data warehouse, not Spider.

2. Specialized always wins at scale. Postgres is the right choice for getting started. But if you are running a petabyte data warehouse, you need a column store. If you are doing vector search, you need a vector database. If you are processing streams, you need a stream processor. The one-size-fits-all era is over at the high end.

3. Agentic AI needs database fundamentals. When AI agents start writing to databases, you need transactions, consistency, and durability. That is not an AI problem. It is a database problem. The engineers who understand both worlds, AI and database internals, will be the ones building the systems that actually work.

Stonebraker's career is a masterclass in betting against the herd. He was right about specialized databases. He was right about MapReduce being inefficient (Google eventually abandoned it). He was right about eventual consistency being wrong for most use cases (Google abandoned that too with Spanner). His track record on text-to-SQL should make you pause before trusting the benchmark numbers.

Sources: Data Renegades Podcast - Mike Stonebraker Interview, BEAVER Benchmark (arXiv), Recce Blog: Benchmarks Lie, One Size Fits All paper (Brown University), DBOS, DBOS Wikipedia

150,000 Tech Workers Laid Off in 2026 While Companies Post Record Profits: The AI Excuse

Md Jamilur Rahman — Tue, 07 Jul 2026 04:47:33 +0000

Something changed in 2026. Companies are no longer blaming layoffs on the economy, post-pandemic corrections, or market downturns. They are blaming AI. And they are doing it while posting record revenue.

The numbers

Through mid-June 2026, 363 layoff events have affected roughly 150,000 tech workers, approximately 974 people per day. Last month alone saw 40,000 cuts. AI has been cited as the primary driver across all industries for three consecutive months (ByteIota).

But here is what makes 2026 different from every previous layoff cycle: these companies are profitable. Many are posting record numbers.

Company	Jobs Cut	% of Workforce	Revenue Trend
Block	~4,000	40%	Record profit
Oracle	~30,000	18%	+95% net income
Meta	8,000	10%	Growing
Microsoft	~8,750	7%	Record revenue
Cloudflare	1,100	20%	Record revenue, +34% YoY
PayPal	4,760	20%	Growing
Coinbase	700	14%	Growing

Source: HeroHunt.ai, CNBC

Cloudflare is the clearest example. They cut 1,100 people, 20% of their workforce, in the same earnings call where they reported record quarterly revenue of $639.8 million, up 34% year-over-year. Their internal AI usage had increased 600% in three months. CEO Matthew Prince said it was not a cost-cutting exercise. It was about "defining how a world-class company operates in the agentic AI era" (TechCrunch).

Block went further. Jack Dorsey cut 40% of the workforce. The stock soared 24% the same day. Block posted $2.87 billion in gross profit that quarter, up 24% (CNN).

These are not distressed companies cutting costs to survive. These are profitable companies replacing humans with AI and telling shareholders about it.

What the CEOs are saying

The rhetoric has shifted from hedging to explicit.

Dario Amodei (Anthropic CEO) predicted AI would write "90% of code in 3-6 months" and "essentially all of the code in 12 months" (Yahoo Finance). That timeline has passed. It did not happen at the scale he described.

Mark Zuckerberg said "probably maybe half the development is going to be done by AI" at Meta within a year. Satya Nadella confirmed over 30% of Microsoft's code is AI-generated, targeting 60% by 2026 (TechTimes). Sundar Pichai said 75% of new Google code is AI-generated (Fast Company).

Then there is Jensen Huang. The Nvidia CEO pushed back: "If we convinced all the young college graduates to not be software engineers, and it turns out the United States needs more software engineers than ever, that's hurtful." He accused some CEOs of having a "God complex" about AI apocalypse warnings (Fortune).

Notice the pattern. The companies that sell AI (Anthropic, OpenAI) push the "AI replaces workers" narrative hardest. That narrative drives adoption of their products. The companies that need engineers to build AI features (Google) or sell hardware to make AI possible (Nvidia) are more measured. Follow the incentives.

The "AI wrote half our code" problem

Freshworks CEO Dennis Woodside said "over half our code is written by AI." This is almost certainly true if you measure by lines generated. It is also almost entirely misleading.

If AI writes 100 lines of boilerplate and a human writes 10 lines of critical business logic, AI wrote "91% of the code" but the human wrote most of the value. Lines of code is a terrible productivity metric. Every engineer knows this. The CEOs citing it either do not know or do not care.

The real job of a software engineer is not typing code. It is understanding requirements, designing systems, debugging edge cases, handling production incidents, and making tradeoff decisions. AI can generate a function. It cannot attend a architecture review, negotiate with a product manager about scope, or figure out why the payment service intermittently fails on the third retry.

The real casualties: junior engineers

The layoffs are not hitting evenly. Junior roles are being decimated.

Coinbase's restructuring eliminated "pure managers" in favor of "player-coaches" and introduced "AI-native pods" that could include one-person teams directing AI agents. That is a senior-heavy structure. There is no room for someone who needs mentorship, code review, and time to learn the codebase.

Salesforce cut approximately 5,000 customer service roles across two rounds. CEO Marc Benioff said "I need less heads" while his Agentforce product handled 1.5 million customer conversations alongside human agents (CNBC). Those customer service roles were entry-level positions.

The long-term risk is obvious. If nobody hires juniors today, there are no seniors in five years. You cannot skip the pipeline. But individual companies do not care about the pipeline. They care about this quarter.

The Oracle playbook

Oracle's layoffs are the most disturbing. According to TIME, Oracle ran a deliberate data-collection program asking employees to document their workflows to train AI systems, then used those results to make the same employees redundant. A 30-year veteran technical writer was called while driving to the hospital for back surgery and told she was laid off. $300,000 worth of her stock units vanished overnight. Oracle had posted a 95% jump in net income that quarter and committed to $156 billion in AI infrastructure buildout (TIME).

That is not AI replacing workers. That is using workers to build their own replacement, then firing them with the technology they helped create.

The whiplash

Many affected employees describe a specific kind of betrayal. Their companies spent the previous year encouraging AI adoption, providing internal training, celebrating teams that shipped features faster using AI tools. Then those same productivity gains became the justification for cutting the teams that achieved them.

The message engineers hear is: "Thank you for becoming more productive. Your reward is that we no longer need you."

This creates a chilling effect. Why would any engineer adopt AI tools aggressively if the outcome is their own elimination? Smart engineers are learning to use AI quietly, deliver results slowly enough to avoid drawing attention, and keep their productivity gains invisible.

What is actually happening

Three things are true simultaneously:

AI genuinely makes some roles unnecessary. Customer support, content moderation, basic QA testing, and boilerplate code generation are being automated. These are real displacements.
Some companies are using AI as cover for pandemic over-hiring corrections. The narrative is convenient. "AI made us do it" plays better with shareholders than "we hired too many people during the boom and are now correcting."
The companies cutting the most are also investing the most. Meta raised capex guidance to $125-145 billion for AI infrastructure. Microsoft set $190 billion. The four largest tech companies alone are spending a combined $725 billion on AI capex in 2026 (24/7 Wall St.). The money is not disappearing. It is shifting from payroll to GPU clusters.

What this means for engineers

If you are a software engineer reading this in 2026, here is the honest takeaway:

AI is not replacing engineering. It is replacing tasks within engineering. The engineers who adapt will be fine. The ones who refuse to use AI tools will not.
Junior roles are the most vulnerable. If you are early career, focus on skills AI cannot replicate: system design, cross-team communication, domain expertise, and debugging complex production issues.
"Percentage of code written by AI" is a marketing metric. Do not let it panic you. Code generation is the easiest part of engineering.
The companies cutting workers while posting record profits are making a bet. They believe smaller, AI-augmented teams can maintain and grow their products. Some of those bets will fail. Companies that tried full AI replacement and had to reverse course already exist (HeroHunt.ai).
The safest position is being the engineer who can ship complete AI products end-to-end, not just call an API. Full-stack AI engineering, the kind where you control the frontend, the backend, and the model, is where the demand is heading.

The layoffs are real. The AI component is real. But "AI replaces engineers" is a headline, not a fact. The reality is messier, more nuanced, and less apocalyptic than the CEOs selling AI would have you believe.

Sources: ByteIota, HeroHunt.ai, Invezz, CNBC, TechCrunch, CNN, TIME, Fast Company, Fortune

Setting Up IntelliJ IDEA for Java Development

Md Jamilur Rahman — Sun, 05 Jul 2026 09:04:23 +0000

If you asked a hundred Java developers what editor they use, most of them would say IntelliJ IDEA. There is a reason for that. It has been the dominant Java IDE for years, and once you get used to how much it does for you, going back to a plain text editor feels like writing with your non-dominant hand.

This walkthrough covers the setup from scratch. Download, install, create a project, write some code, run it, and debug it. By the end you will have a working Java environment and a feel for the shortcuts that make IntelliJ worth learning.

Community vs Ultimate

IntelliJ comes in two editions. Community is free and has everything you need for standard Java development. Ultimate is the paid version with extra support for web frameworks, databases, and enterprise tools.

When you first install IntelliJ, you get a 30-day trial of Ultimate. After that, it drops down to Community automatically. For learning Java and most personal projects, Community is more than enough. Do not pay for Ultimate unless you know you need it.

Download IntelliJ from the JetBrains website and follow the installer for your operating system.

Create your first project

Launch IntelliJ and you will see a welcome screen. Click New Project.

In the New Project window:

Select Java on the left.
Give the project a name, something like java-demo.
Pick a build system. You have three choices here, and it matters less than you might think:
- IntelliJ is the simplest. No extra config files. Fine for small experiments.
- Maven is the industry standard. It uses a pom.xml file to manage dependencies and builds. If you plan to share your code or add libraries later, pick this.
- Gradle is the other big build tool. Common in Android and large projects. Slightly steeper learning curve.

For this guide, choose Maven. It is the most common in tutorials and job listings, so getting comfortable with it early pays off.

Leave Add sample code unchecked. You will write the code yourself.

Click Create.

Set up your JDK

A JDK (Java Development Kit) is what actually compiles and runs your code. IntelliJ cannot do Java without one.

If you already have a JDK installed, IntelliJ usually finds it. Just pick it from the JDK dropdown in the New Project window.

No JDK yet? No problem. Click the dropdown, select Download JDK, and IntelliJ downloads one for you. Pick a vendor (Oracle OpenJDK is a safe default) and a version. Java 17 and Java 21 are both long-term support releases and good choices for new projects. Java 25 is the newest if you want the latest features.

This is one of the things IntelliJ does better than most editors. You never have to mess with environment variables or PATH settings. It handles the JDK configuration internally.

The project structure

After you click Create, IntelliJ opens your project. On the left side you will see the Project tool window with a folder structure that looks something like this:

java-demo/
├── src/
│   ├── main/
│   │   └── java/       ← your code goes here
│   └── test/
│       └── java/       ← your tests go here
├── pom.xml             ← Maven configuration
└── .idea/              ← IntelliJ settings (don't touch)

The src/main/java folder is where your Java source files live. The test folder is for automated tests. The pom.xml is where Maven stores project info and dependency declarations.

Write and run your first class

Right-click the src/main/java folder and select New > Java Class. Name it Main. IntelliJ creates a basic class skeleton for you.

Replace the contents with this:

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

Now look at the left margin, next to the main method declaration. You will see a green play button. Click it and select Run 'Main.main()'.

Your output shows up in the Run panel at the bottom. No javac command, no manual compile step. IntelliJ compiles and runs in one click.

If you are on a Mac, Ctrl+Shift+R runs the current file. On Windows or Linux, use Ctrl+Shift+F10.

Code completion and quick fixes

This is where IntelliJ starts earning its reputation. As you type, it suggests class names, method names, and variable names. Press Tab or Enter to accept a suggestion. It saves you from typos and from memorizing the entire standard library.

The bigger feature is Alt+Enter (or Option+Enter on Mac). Any time IntelliJ spots a problem, a red underline appears. Press Alt+Enter and IntelliJ offers to fix it. Missing import? It adds the import. Wrong variable type? It suggests a cast. Undefined variable? It offers to create one.

Think of Alt+Enter as the "do something smart" key. You will press it constantly.

You can also generate boilerplate code. Press Alt+Insert (or Cmd+N on Mac) inside a class, and IntelliJ offers to generate constructors, getters, setters, toString(), equals(), and hashCode(). For a class with five fields, that is five minutes of typing saved.

Debugging

Run your code with the debugger instead of the regular Run button, and you can pause execution at any line. Click in the gutter next to a line number to set a breakpoint (a red dot appears). When execution hits that line, it stops.

From there:

F8 steps over to the next line without diving into method calls
F7 steps into a method to see what happens inside it
F9 resumes execution until the next breakpoint

While paused, you can see the current value of every variable in the Variables panel. You can also right-click any expression and select Evaluate Expression to see its value on the spot. This is invaluable when a calculation returns something unexpected and you need to figure out which step went wrong.

Testing

Press Ctrl+Shift+T (or Cmd+Shift+T on Mac) with your cursor inside a class, and IntelliJ jumps to the test for that class. If no test exists yet, it creates one for you.

IntelliJ defaults to JUnit 5, the most widely used testing framework for Java. If JUnit is not in your project yet, IntelliJ detects this and offers to add the dependency automatically. Click Fix and it updates your pom.xml for you.

Write a test method, annotate it with @Test, and run it with the same green play button. Green bar means pass, red means fail.

Refactoring

Renaming a variable in five files by hand is tedious and error-prone. IntelliJ does it safely. Put your cursor on a variable, method, or class name and press Shift+F6. Type the new name, hit Enter, and IntelliJ updates every reference across your entire project.

Other useful refactorings:

Ctrl+Alt+M (or Cmd+Alt+M on Mac) extracts selected code into a new method. Great for breaking up long methods.
Ctrl+Alt+V extracts an expression into a variable. Useful when a complex expression is hard to read.
Ctrl+Alt+L reformats your code to match the project's style settings.

Search Everything

Press Shift twice and a search box pops up. Type anything: a class name, a file name, a setting, an action. IntelliJ searches your entire project and its own settings. It is the fastest way to find anything without clicking through menus.

For searching inside file contents across the whole project, press Ctrl+Shift+F (or Cmd+Shift+F on Mac). This opens Find in Files, which is handy for tracking down where a method is used or finding a specific string.

Quick summary

IntelliJ Community is free and sufficient for learning Java. Ultimate adds enterprise features.
Create a Maven project from the welcome screen. Maven is the most common build tool in the Java ecosystem.
No JDK? IntelliJ downloads one for you. No PATH or environment variable setup needed.
Code lives in src/main/java, tests in src/test/java, Maven config in pom.xml.
Click the green play button in the gutter to run code. Alt+Enter fixes problems. Alt+Insert generates boilerplate.
Debug with breakpoints (F8 to step over, F7 to step in, F9 to resume).
Shift+Shift opens Search Everywhere. Ctrl+Shift+F searches file contents project-wide.
Shift+F6 renames safely across the whole codebase.

Based on dev.java/learn: Building a Java application in IntelliJ IDEA

After the AI Hype: What's Real, What's Not, and What Comes Next

Md Jamilur Rahman — Sun, 05 Jul 2026 09:03:50 +0000

A 50-minute keynote at NDC Copenhagen 2026 cut through more AI noise than a year of tech blog posts. Richard Campbell, co-host of .NET Rocks and a veteran who has lived through multiple tech disruptions, delivered a talk titled "After the AI Hype: What's Real, and What's Next" that pulled zero punches.

His central argument: "Artificial Intelligence" is a terrible name. It was coined in the 1950s by scientists raising money from the US military. The name stuck. And now we are dealing with the consequences of decades of deception.

Here is what Campbell got right, what the data backs up, and why it matters.

The Name Problem Is Real

Campbell traces the term "artificial intelligence" back to the 1950s, when a group of scientists successfully pitched the US military for funding. When the money dried up, the first "AI winter" hit. Multiple AI winters followed. Each time, scientists repackaged the technology under the same name to secure new funding rounds.

The problem is not just historical. Campbell argues that science fiction, from HAL 9000 in 2001: A Space Odyssey (1968) to the Terminator movies and Ultron, has trained the public to associate "AI" with sentient machines. Students tell Campbell they think AI is "Jarvis." The name creates expectations the technology cannot meet.

This matters because those inflated expectations are being exploited right now to extract investment at a scale that mirrors the dot-com bubble.

The Dot-Com Parallel: Backed by Data

Campbell is not alone in drawing the comparison. A growing body of financial analysis confirms the parallels.

Forbes noted in August 2025 that AI's rapid rise mirrors the dot-com era, with soaring valuations and heavy data center spending raising investor concerns about a possible bubble [Forbes]. Intuition Labs published a data-driven comparison showing NVIDIA's $4.3 trillion market cap, OpenAI's $730 billion valuation, and $258.7 billion in AI VC funding as of 2026, drawing direct parallels to 1999-era overvaluation [Intuition Labs]. Lambda Finance analyzed the bull and bear cases, noting that while hyperscaler balance sheets are stronger than dot-com startups, the capex intensity and market concentration look "uncomfortably similar to March 2000" [Lambda Finance].

Campbell made a specific observation that the data supports: in 2024, more than half the increase in S&P 500 value came from just seven companies (now called the "Magnificent 10"), all propped up by AI narratives. PE ratios are at their second-highest level ever, surpassed only by the dot-com peak.

The Data Center Shell Game

One of Campbell's most striking claims: hyperscalers are ordering data center capacity like people buying Taylor Swift tickets, opening multiple browsers to secure one spot. They over-order land, power, and chips, with no intention of building all of it. Some sites have nothing more than a guard rail to mark "construction underway."

The memory chipmakers called this out. In late 2025, TSMC, Micron, and others refused to double RAM production, telling the hyperscalers: building a new fab takes three to five years, and we do not think you will be around in three to five years to buy the output.

Campbell pointed to a circular money pump: NVIDIA invests hundreds of millions into AI startups, and those startups turn around and buy NVIDIA chips. The $500 million investment and the $500 million chip order both show up as value. "I just made $500 into a billion dollars. I'm a genius."

Big Tech plans to spend between $364 billion and $400 billion on AI data centers and infrastructure, with data center spending surging from $9.5 billion in early 2020 to $40.4 billion by Q2 2025 [IEEE ComSoc]. The LinkedIn analysis puts the revenue at just $20 billion against $400 billion in spending, a 20:1 gap [LinkedIn].

ChatGPT Psychosis: People Are Getting Hurt

Campbell discussed what he called "ChatGPT psychosis," and the evidence is not theoretical.

Geoff Lewis, managing partner at Bedrock (an investor in OpenAI and Vercel), posted a disturbing video in July 2025 claiming a "non-governmental system, not visible but operational" had targeted him. His peers in the tech industry expressed serious concern. Futurism reported that Lewis had been spending extensive time with a chatbot and entered what appeared to be a psychotic episode [Futurism]. The Register covered the growing concerns about AI's effect on mental health in the wake of Lewis's public breakdown [The Register]. A psychiatry podcast documented cases where ChatGPT amplified delusions, triggered psychosis-like states, and was associated with suicides in people with no prior mental illness [Psychiatry Podcast].

Campbell explained why: these tools are designed to maximize engagement through positive reinforcement. They are obsequious by design. "You're really onto something now, and you're really thinking now, and that's an awesome idea." When OpenAI dialed back the sycophancy in GPT-5, users revolted. Posts like "My baby is back, and I'm crying" went viral when OpenAI reversed course.

The metric these companies take to investors is engagement, because they cannot show profit. There is none.

The Real Success Story: AlphaFold

Campbell's most powerful section was on DeepMind's AlphaFold, and it is the part that makes the "just walk away from AI" argument impossible.

Demis Hassabis and his team targeted protein folding, one of biology's hardest problems. There are 10^35 possible combinations for how proteins fold. Over 60 years, tens of thousands of biologists using x-ray crystallography had worked out roughly 150 protein structures. Each one led to new medicines. Each one took years.

By 2020, AlphaFold reached 90% accuracy. By 2022, it was essentially solved. DeepMind then computed the 200 million most common protein fold sets and published them for free.

The impact is already measurable. A new leukemia treatment traces back to AlphaFold data. A malaria vaccine came from it. Three new antibiotics have emerged from it. AlphaFold won the 2024 Nobel Prize in Chemistry [Nature]. The DeepMind blog documents how the malaria vaccine work specifically leveraged AlphaFold's protein structure predictions [Google DeepMind]. Oxford's Higgins Lab confirmed that AlphaFold helped solve the structure crucial for their malaria vaccine development [Higgins Lab].

This was only possible with the adversarial training model of generative AI. It is extraordinary. It has fundamentally changed medicine, and it will take decades to comprehend everything that came from this dataset.

What Campbell Got Wrong (or Overstated)

Campbell said Hinton "was part of a team that built software for handwriting recognition" in the 1980s. The reality is slightly more nuanced. Hinton co-authored the seminal 1986 paper on backpropagation with David Rumelhart and Ronald Williams, which became the theoretical foundation for training neural networks. The practical handwriting recognition applications came later, primarily through Yann LeCun's work at Bell Labs on MNIST digit recognition in the late 1980s and 1990s. Hinton's contribution was the foundational algorithm, not the shipping product.

Campbell also listed "Kaiming He" as one of Hinton's students who entered the ImageNet competition. Kaiming He was actually a researcher at Microsoft Research Asia and later Facebook AI Research. The students who entered the 2012 ImageNet competition with Hinton were Alex Krizhevsky and Ilya Sutskever (the system was called AlexNet). Campbell likely misspoke in a live talk.

The Takeaway

Campbell closed with something worth repeating: "Our job was never to write code. It was to solve people's problems."

They could not code their way out of the protein folding problem, so they built a model that solved it. Maybe that is the answer to the problem you are dealing with.

The AI hype cycle is real. The bubble signs are measurable. People are getting hurt by chatbot sycophancy designed to maximize engagement. But the technology underneath is not useless. AlphaFold proves that. The challenge is separating the signal from the noise, and choosing to build things that actually help people.

As Campbell put it: "We choose what we do with these tools."

Based on Richard Campbell's keynote "After the AI Hype: What's Real, and What's Next" at NDC Copenhagen, June 2026. Watch the full talk on YouTube.

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