DEV Community: Md Mijanur Molla

The New Skill AI Can't Learn From Your Codebase

Md Mijanur Molla — Thu, 11 Jun 2026 08:06:14 +0000

AI can do some pretty impressive things today.

It can:

Generate code
Explain functions
Write tests
Refactor components
Create documentation

Sometimes it feels like AI knows your codebase better than you do.

And honestly?

For certain tasks, it probably does.

But there is one skill that AI still struggles to learn from your codebase.

And as AI becomes more powerful, this skill is becoming more valuable.

💡 The Great Misunderstanding

Many developers think:

👉 The future belongs to whoever writes code the fastest.

That used to be true.

Today?

Not so much.

AI can already generate thousands of lines of code in seconds.

The bottleneck is no longer typing.

The bottleneck is deciding:

👉 What should be built?

👉 Why should it be built?

👉 What tradeoffs should be made?

🧠 The Skill AI Can't See

Open any repository.

AI can analyze:

Classes
Functions
APIs
Dependencies

But it cannot easily understand:

Why a decision was made three years ago
Why a feature exists
Why users behave a certain way
Why the business chose one solution over another

That knowledge often lives outside the code.

In:

Meetings
Conversations
Product discussions
Customer feedback
Engineering tradeoffs

And that's where the real challenge begins.

⚙️ Code Shows What Happened

But not always:

👉 Why it happened.

For example:

Imagine AI finds this:

if(user.type === "legacy") {
   useOldPaymentFlow();
}

AI can explain what the code does.

But can it answer:

Why does the legacy flow exist?
What business risk does it avoid?
What customers depend on it?
What happens if we remove it?

Usually not.

Because those answers aren't in the code.

🚀 Modern Engineering Is Becoming Decision Engineering

As AI gets better at implementation...

Human value shifts upward.

From:

❌ Writing code

To:

✅ Making decisions

The most valuable developers increasingly spend time:

Understanding systems
Evaluating tradeoffs
Designing architecture
Clarifying requirements
Managing complexity

Not typing.

Thinking.

🔥 The Difference Between Coding and Engineering

AI is becoming very good at coding.

Engineering is different.

Engineering asks:

Is this scalable?
Is this maintainable?
Is this worth building?
What happens in six months?
What are we sacrificing?

Those questions rarely have perfect answers.

That's where judgment matters.

📚 Why Context Is Becoming More Valuable

Every large software system contains hidden context.

Things like:

Historical decisions
Business constraints
Team knowledge
Customer expectations

These shape the system.

But they rarely appear in source code.

This is why two developers can look at the same code and make completely different decisions.

Because context changes everything.

🤯 The Paradox of AI

The better AI becomes at writing code...

The more important non-coding skills become.

Sounds strange.

But think about it.

If implementation becomes easier:

👉 Decision quality becomes the differentiator.

The question is no longer:

"Can you build it?"

The question becomes:

"Should you build it this way?"

🎯 The New Competitive Advantage

In the AI era, valuable developers won't just be people who can code.

They'll be people who can:

Understand systems
Connect business goals with technology
Make good architectural decisions
Manage complexity
Communicate tradeoffs

These are skills AI can't simply extract from a repository.

💡 Final Thought

AI can read your code.

It can analyze your architecture.

It can generate implementations.

But one thing remains difficult:

👉 Understanding the human reasoning behind technical decisions.

And that's becoming one of the most valuable skills in software engineering.

Because the future isn't just about writing code.

It's about knowing why the code should exist in the first place.

And that's something no repository can fully teach.

AI #SoftwareEngineering #LLM #Developers #Programming #Architecture #TechLeadership #FutureOfWork #Coding #Engineering

I Built a “Battery Anxiety Simulator” Game… And 1% Battery Became a Horror Story 😭🔋

Md Mijanur Molla — Thu, 04 Jun 2026 10:36:19 +0000

We've all been there.

Your phone says:

🔋 15%

"No problem."

A few minutes later:

🔋 10%

Still fine.

Then suddenly:

🔋 5%

And your entire personality changes 😭

So I turned this universal experience into a game.

👉 Battery Anxiety Simulator

🎮 The Challenge

Your mission is simple:

Reach a charger before your phone dies.

That's it.

But the world keeps trying to destroy your battery.

⚠️ Every Decision Matters

Random events appear:

📞 Friend calls

Do you answer?

🎥 YouTube starts autoplay

Do you stop it?

Or watch "just one more video"? 😈

🗺️ GPS running in background

Turn it off?

Or ignore it and hope for the best?

😭 Things Get Worse Fast

As battery drops:

15% → Relaxed

10% → Concerned

5% → Panic

1% → Survival Mode Activated 💀

Then the game starts throwing chaos at you:

⚠️ Brightness jumps to 100%

💀 Hotspot turns on

😭 43 apps running in background

👀 Power bank found... but it's only 2% charged

💻 The Challenge Rules

Build everything using:

HTML
CSS
Vanilla JavaScript

And keep everything inside:

👉 ONE single HTML file

No frameworks.

No libraries.

Just pure frontend creativity.

🧠 Why I Like This Idea

Because everyone understands it instantly.

You don't need instructions.

You don't need tutorials.

The moment someone sees:

🔋 1% Battery

They already know the fear 😄

🚀 Explore More Creative Challenges

I've been exploring fun game-style coding challenges recently:

https://vibecodearena.ai/beattheheat?page=1&pageSize=10&sortBy=responses&sortOrder=desc&utm_source=external&utm_medium=vc3&utm_campaign=beattheheat

Some challenges test coding.

Some test logic.

This one tests your ability to survive modern life 😭

🎯 Final Thought

A phone at 100% gives confidence.

A phone at 1% reveals character.

The real question is:

Would you watch one more video at 2% battery? 😈🔋

Why Your AI Assistant Gets Lost in Large Repositories

Md Mijanur Molla — Thu, 04 Jun 2026 07:43:56 +0000

AI coding assistants are impressive.

They can:

Generate code
Explain functions
Write tests
Refactor components
Answer technical questions

For small projects, they often feel magical.

But something interesting happens when the repository gets bigger.

Really big.

Think:

Monorepos
Enterprise applications
Legacy systems
Multi-service architectures

Suddenly, your AI assistant starts giving strange answers.

And you find yourself thinking:

👉 "Wait... that's not how our system works."

So what changed?

Let's find out.

💡 The Problem Isn't Intelligence

Most people assume:

👉 AI gave the wrong answer because it isn't smart enough.

In reality, that's usually not the problem.

The real issue is:

👉 Lack of context.

AI can understand code.

But understanding an entire software system is a completely different challenge.

📚 Large Repositories Are More Than Files

Imagine a repository with:

5,000+ files
Hundreds of APIs
Shared libraries
Multiple services
Years of engineering decisions

Now ask:

👉 "How does user onboarding work?"

The answer may involve:

Frontend code
Backend services
Authentication flows
Event queues
Databases
Third-party integrations

The logic is spread across dozens of files.

Maybe hundreds.

🔍 Search Is Not Understanding

Many AI tools work by finding relevant files and code snippets.

That helps.

But there's a problem.

Finding something is not the same as understanding it.

For example:

You search for:

createUser()

You find 15 references.

Great.

But now you need to know:

Which one is actually used?
What service calls it?
What happens afterward?
What dependencies exist?

Suddenly:

👉 Search results are not enough.

🧩 Software Lives in Relationships

Large systems are built from relationships.

Examples:

Service A depends on Service B
Component X triggers Event Y
API Z updates Database Q

These connections matter.

And often they are more important than individual files.

That's where understanding becomes difficult.

🤯 The Context Window Problem

Another challenge is scale.

AI models have limited context windows.

Even when those limits are large...

Enterprise repositories are often larger.

Much larger.

A repository might contain:

Millions of lines of code
Years of commits
Thousands of dependencies

No AI can load everything at once.

So it must choose.

And sometimes it chooses the wrong context.

💀 Why AI Hallucinates in Large Codebases

This creates a common situation.

AI sees:

Some files
Partial relationships
Incomplete architecture

Then tries to fill in the gaps.

Sometimes correctly.

Sometimes not.

That's why you may get answers that look reasonable...

But are completely wrong for your project.

🚀 Why Developers Spend More Time Understanding Than Coding

In large systems, the hardest task is often not writing code.

It's understanding:

Existing architecture
Service dependencies
Data flow
Historical decisions

This is true for humans.

And it's true for AI.

Before changing code, you must understand the system.

🧠 The Missing Piece: Repository Memory

This is why concepts like:

Repository Memory
Knowledge Graphs
Code Graphs
Architectural Maps

are becoming more important.

Instead of treating code as isolated files...

They treat the repository as a connected system.

Now AI can understand:

Relationships
Dependencies
Data flow
Architecture

Not just raw code.

⚙️ Why Tools Like Graphify Exist

As repositories grow, developers face a new challenge:

👉 Knowing where things are is not enough.

You need to know:

How things connect
Why they exist
What depends on them

Tools that build repository memory help solve this problem.

They transform:

Files → Knowledge

And that's a big difference.

🎯 The Future of AI Coding

The next challenge for AI isn't generating code.

It's understanding systems.

Because real-world software is rarely about a single file.

It's about:

Architecture
Relationships
Context
Decisions

And those things don't fit neatly into a search result.

💡 Final Thought

Your AI assistant isn't getting confused because the repository is large.

It's getting confused because software isn't just code.

It's a network of relationships, dependencies, and decisions built over time.

And until AI understands those connections...

It will always struggle in large repositories.

Because reading code is one thing.

👉 Understanding a system is another.

AI #SoftwareEngineering #Monorepo #DeveloperTools #Codebase #LLM #AIAssistants #Architecture #Graphify #Programming

The Real Reason Developers Love Dark Mode

Md Mijanur Molla — Sat, 30 May 2026 09:58:29 +0000

If you've ever walked into a room full of developers, you'll notice something interesting.

Almost every screen looks the same.

Dark background.

Colorful code.

A setup that makes the room look like a hacker movie 😎

And naturally, the question comes up:

👉 Why do developers love Dark Mode so much?

Is it better for coding?

Does it improve productivity?

Or is there another reason?

Let's investigate 👇

💻 The Official Reason

Ask a developer why they use Dark Mode and you'll usually hear:

Less eye strain
Better focus
More comfortable at night
Easier to look at for long hours

And honestly...

These reasons are valid.

If you're staring at code for 8 to 10 hours a day, a bright white screen can feel like staring into the sun.

Especially at 2 AM during a production issue 😭

🌚 The Unofficial Reason

Let's be honest.

Dark Mode looks cool.

There, I said it.

A terminal with green text on a black background just feels more powerful.

Even if you're only running:

npm install

For a few seconds...

You feel like you're breaking into the Pentagon.

You're not.

But it feels that way.

😂 The Developer Transformation

Normal person:

Opens laptop.

Checks email.

Closes laptop.

Developer:

Opens laptop
Opens 17 tabs
Opens VS Code
Opens terminal
Switches everything to Dark Mode
Suddenly becomes a software engineer

Coincidence?

I think not.

⚡ Dark Mode and Productivity

Now here's the funny part.

Many developers genuinely believe:

👉 Dark Mode = Better Code

Reality?

Your bugs don't care.

The bug that took 4 hours to find in Light Mode...

Will happily take 4 hours in Dark Mode too.

Technology has limits 😄

🤖 Dark Mode Is Basically a Developer Starter Pack

Along with:

Mechanical keyboard
Multiple monitors
Coffee
Too many browser tabs
Stack Overflow open somewhere

Dark Mode is practically mandatory.

Nobody officially says it.

But everyone knows.

🔥 The Real Benefit

Jokes aside...

Dark Mode can actually help during long coding sessions.

Many developers find it:

More comfortable
Less distracting
Easier on the eyes in low-light environments

The key word is:

👉 Many

Not everyone.

Some developers genuinely prefer Light Mode.

And surprisingly...

They still write good code.

Shocking, I know.

💀 The Great Developer Debate

Few topics start arguments faster than:

Tabs vs Spaces
Vim vs VS Code
Mac vs Windows
Light Mode vs Dark Mode

Entire friendships have survived these debates.

Barely.

🧠 The Truth Nobody Wants to Hear

Dark Mode doesn't make you a better developer.

It doesn't improve algorithms.

It doesn't fix production bugs.

It doesn't reduce technical debt.

Unfortunately.

What it does do is make your environment more comfortable.

And sometimes that's enough.

🚀 Final Thought

The real reason developers love Dark Mode?

Partly comfort.

Partly habit.

Partly aesthetics.

And maybe...

Just maybe...

Because staring at a glowing dark screen filled with colorful code makes us feel like we're building the future.

Even when we're spending three hours debugging a missing semicolon 💙

💬 Team Dark Mode or Team Light Mode?

Be honest.

And remember:

This discussion is completely civil and never starts arguments... right? 😄

Developers #Programming #SoftwareEngineering #DarkMode #DeveloperLife #CodingHumor

Why Production Is the Real Software Test Environment

Md Mijanur Molla — Wed, 27 May 2026 11:18:40 +0000

As developers, we test our applications everywhere.

Local environment ✅
Development server ✅
Staging environment ✅
QA testing ✅

After all checks pass, we finally think:

👉 “Looks good. Ready for production.”

Then production happens…

And suddenly:

💀 Unexpected bugs
💀 Performance issues
💀 Strange user behavior

And everyone starts asking:

👉 “But it worked before…”

Sound familiar?

Let’s talk about why production often becomes the real test environment 👇

💡 In Development, Everything Is Controlled

When we build locally:

Small datasets
Stable internet
Known test cases
Limited users

Everything is predictable.

You know:

What data exists
What buttons get clicked
What inputs are used

Life feels easy.

🌍 Production Is a Different World

Real users are unpredictable.

Very unpredictable.

Users will:

Click buttons rapidly
Enter strange values
Open 20 tabs
Refresh pages endlessly
Use old devices
Use slow networks

And somehow…

👉 Find bugs nobody imagined

💀 Real Users Create Real Edge Cases

Example:

Developer testing:

John

Production users:

John_123_🔥_test_999999999

Or:

Empty values
Very large files
Unexpected combinations

Suddenly:

👉 Perfect code starts behaving differently

⚡ Scale Changes Everything

Maybe locally:

5 users tested app

Production:

👉 50,000 users arrive

Now new issues appear:

Slow APIs
Database bottlenecks
Race conditions
Memory spikes

Things that never happened before.

🔄 Systems Behave Differently Under Load

Locally:

Everything feels instant.

Production:

Multiple services interact
Network latency exists
External APIs fail
Traffic spikes happen

Distributed systems become messy.

🧠 Production Reveals Assumptions

Most hidden bugs begin with:

👉 Assumptions

Like:

"Users won’t do this"
"Traffic won't get that high"
"This API will always respond"

Production loves proving assumptions wrong 😄

⚙️ Why Big Companies Monitor Everything

Companies like:

Netflix
Amazon
Google

Don’t just deploy and relax.

They monitor:

Logs
Metrics
Errors
User behavior

Because production constantly teaches new things.

🔥 Production Is Where Reality Starts

Development answers:

👉 "Does it work?"

Production answers:

👉 "Does it still work in the real world?"

Huge difference.

⚠️ Does This Mean Testing Is Useless?

Not at all.

Testing is critical.

But testing reduces risk.

It does not remove reality.

Production introduces:

Real traffic
Real users
Real data
Real chaos

🎯 The Lesson

Good developers write code.

Great engineers prepare for production.

Because software isn't built only for:

❌ controlled environments

It's built for:

✅ unpredictable humans

🚀 Final Thought

Production is not where software ends.

It’s where software begins its real journey.

Because no matter how many tests you run…

👉 Real users will always test things differently.

And honestly…

Production has a way of teaching lessons no tutorial ever can 💙

SoftwareEngineering #Production #SystemDesign #Developers #WebDevelopment #Programming

I Built a “Delete Production?!” Panic Game… And My Stress Level Reached 100% 😭🔥

Md Mijanur Molla — Tue, 26 May 2026 16:12:40 +0000

Every developer secretly fears one thing...

Not bugs.
Not deadlines.
Not meetings.

👉 Accidentally clicking the wrong button in production 💀

Imagine seeing:

⚠️ Server issue detected

Options:

Check Logs
Restart Service
Ignore
Delete Production 😭

Now imagine:

You only have 5 seconds to choose.

Panic activated.

So I thought:

Why not turn every developer nightmare into a game?

That became:

👉 Delete Production?! Panic Simulator

🎮 The Game Idea

Random system alerts keep appearing.

Your mission:

React quickly
Avoid dangerous buttons
Survive the chaos

Sounds easy.

Until things get evil 😈

⚠️ Things Start Getting Worse

Suddenly:

💀 Fake confirmation popups appear

👀 Button positions change

😭 Team Lead joins chat

🔥 Friday evening deployment detected

Now you're not clicking buttons anymore.

You're fighting for survival.

💻 Challenge Rules

Build everything using:

HTML
CSS
Vanilla JavaScript

Inside:

👉 ONE single HTML file

No frameworks.

No libraries.

Pure frontend chaos.

🚀 Explore More Creative Challenges

I've been exploring really fun coding game challenges recently:

https://vibecodearena.ai/beattheheat?page=1&pageSize=10&sortBy=responses&sortOrder=desc&utm_source=external&utm_medium=vc3&utm_campaign=beattheheat

Some challenges look funny...

Until they trigger developer trauma 😭

🎯 Final Thought

In development:

Wrong code can be fixed.

Wrong production click?

👉 May require prayers 😄

Future Jobs Won’t Ask “What Do You Know?” They’ll Ask “What Can You Build?”

Md Mijanur Molla — Sat, 23 May 2026 09:54:25 +0000

For a long time, the system was very simple.

Study hard.
Get good marks.
Complete your degree.
Apply for jobs.
Get hired.

For years, this was the standard formula people followed.

And honestly...

It worked.

Because knowledge was limited.

If you knew something others didn’t know, you had an advantage.

But today, the world looks completely different.

Now information is everywhere.

Need to learn coding?

YouTube is there.

Need help with a problem?

AI can explain it.

Need a course?

Thousands are available online.

Today, almost everyone has access to information.

And that changes everything.

Because companies are slowly realizing something important:

Knowing information is no longer enough.

Because information is available to everyone.

The bigger question is now:

👉 Can you use what you know?

👉 Can you create something useful?

👉 Can you solve real-world problems?

👉 Can you take an idea and turn it into reality?

Let's think about a simple example.

Two people join the same course.

Both complete the course.

Both receive certificates.

But after six months...

Person A says:

"I completed the course."

Uploads the certificate.

Updates LinkedIn.

And moves on.

Person B says:

"I built a project using what I learned."

Maybe a website.

Maybe an app.

Maybe an AI tool.

Maybe a solution for a real problem.

Now tell me honestly...

Who stands out more?

The answer is obvious.

Because future opportunities may not come to people who only collect knowledge.

They may come to people who show proof of work.

People who create.

People who build.

People who execute.

That’s why projects, portfolios, problem-solving, and practical skills are becoming more valuable every year.

Learning is still important.

Very important.

But learning alone is not enough anymore.

The future belongs to people who don't just consume information...

They use it.

They experiment with it.

And most importantly...

They build with it.

🌱 Learn.

🌱 Build.

🌱 Share.

Because the future may not ask:

"What do you know?"

It may ask:

"What can you actually build?"

👉 What skill would you build for your future?

FutureOfWork #CareerGrowth #AI #Tech #Learning #Skills #Innovation #FutureSkills #LinkedInCommunity

I Built a “Rage Click Simulator” Game… And the Button Started Roasting Me 😭😂

Md Mijanur Molla — Wed, 20 May 2026 11:58:51 +0000

We’ve all seen those buttons.

You move your cursor closer.

You’re ready.

You’re confident.

And suddenly...

👉 The button runs away.

Excuse me? 😭

So I thought:

Why not turn this frustration into a game?

That became:

👉 Rage Click Simulator

And honestly...

It became way funnier than expected 😄

🎮 The Game Idea

The goal sounds ridiculously simple:

Click the button.

That’s it.

No complex controls.

No difficult mechanics.

Just...

Click.

But there’s one problem:

👉 The button does NOT want to be clicked.

😈 Things Get Worse Quickly

As soon as your cursor gets close:

Button changes position
Button moves away
Button becomes faster
Button starts trolling you 😭

Sometimes it even changes text:

Click Me 😄
Almost 😈
Too Slow
Nope 😂
Nice Try Human

The disrespect level becomes unreal.

🧠 Difficulty Progression

At first:

Easy.

Then suddenly:

Speed increases
Fake buttons appear
Chaos mode activates
Screen starts shaking 😭

And now...

You're not playing a game anymore.

You're negotiating with a button.

💻 Challenge Rules

Build everything using:

HTML
CSS
Vanilla JavaScript

Inside:

👉 ONE single HTML file

No frameworks.

No libraries.

Pure frontend chaos.

🎨 UI Style

Fun, colorful and slightly evil 😄

Ideas:

Floating emojis
Smooth animations
Meme effects
Rage meter
Funny button messages

Because this game should feel:

👉 Annoying in the most entertaining way possible.

🚀 Try Similar Creative Challenges Here

I've been exploring fun coding game challenges recently:

👉 https://vibecodearena.ai/beattheheat?page=1&pageSize=10&sortBy=responses&sortOrder=desc&utm_source=external&utm_medium=vc3&utm_campaign=beattheheat

Some start as coding projects...

Then become emotional damage 😭

🎯 Final Thought

Some games test skill.

Some games test speed.

This one...

👉 Tests patience.

And honestly?

The button is winning 😂

I Built a “Stack Overflow Survivor” Game… And My Stress Reached 100% 😭💻

Md Mijanur Molla — Tue, 19 May 2026 12:45:45 +0000

Every developer knows this feeling.

You start fixing one bug.

Then suddenly:

👉 API breaks

👉 CSS disappears

👉 Console throws 27 errors

👉 Stack Overflow tabs become your best friends

And somehow...

Now you're debugging problems you didn’t even have before 😄

That gave me an idea:

What if coding stress became a game?

So I built:

👉 Stack Overflow Survivor

And honestly…

It feels dangerously realistic.

🎮 The Game Idea

The concept is simple:

Random coding disasters appear.

You must:

Read the problem
Pick the correct fix
Survive the chaos

Sounds manageable...

Until pressure kicks in 😈

🧠 Problem Examples

You might see:

Problem:

Button click not working

Choices:

A) Add event listener

B) Restart laptop

C) Add 500 console.logs

D) Blame CSS

Or:

Problem:

API returns undefined

Choices:

A) await response.json()

B) Refresh page 9 times

C) Pray

D) Rename variables randomly

Some options are useful.

Some are things developers secretly do 😭

⚠️ The Twist

Wrong answers don't just reduce points.

They increase:

👉 Developer Stress Level

And when stress reaches 100%...

Game Over 💀

Suddenly:

You are not fixing bugs.

You are surviving them.

⏳ Things Get Worse Over Time

As levels increase:

Timer gets shorter
Problems become harder
Fake solutions appear
Panic increases dramatically 😄

Basically:

Real-world debugging simulator.

💻 Technical Rules

Build everything using:

HTML
CSS
Vanilla JavaScript

Inside:

👉 ONE single HTML file

No frameworks.

No libraries.

Just creativity and controlled suffering 😄

🔥 Bonus Chaos Ideas

Imagine random events like:

☕ Coffee Boost

💀 Stack Overflow Down

🤖 AI gives suspicious advice

🚨 Friday Deployment Mode

Now things become dangerous.

🚀 Explore More Creative Challenges

I've been exploring some really fun coding game challenges recently:

👉 https://vibecodearena.ai/beattheheat?page=1&pageSize=10&sortBy=responses&sortOrder=desc&utm_source=external&utm_medium=vc3&utm_campaign=beattheheat

Some of them start as games...

And slowly become emotional damage 😭

🎯 Final Thought

Debugging isn't about finding bugs.

It's about staying mentally stable while finding them.

And honestly...

That might be the harder challenge 😄

Why System Design Is Slowly Becoming a Core Skill for Everyone

Md Mijanur Molla — Tue, 19 May 2026 08:52:34 +0000

For a long time, many developers believed system design was only for senior engineers.

Something you learn before big interviews.

Something only architects need.

Something that becomes important after 5 or 10 years of experience.

I used to think the same.

But recently, I started noticing something interesting.

System design is no longer a "senior-only skill."

It is slowly becoming important for almost everyone.

And not just for backend developers.

Not just for architects.

Almost every developer is starting to feel its importance.

Earlier, Writing Code Was Enough

A few years ago, many projects were smaller.

You built a feature.

Connected a database.

Created APIs.

Deployed the application.

Done.

The focus was mainly on:

• Writing working code
• Finishing tasks
• Learning frameworks
• Delivering features

And honestly, that worked.

But software systems today are different.

Applications are larger.

Users are everywhere.

Traffic grows unexpectedly.

Features depend on many services.

Things become complicated very quickly.

Modern Applications Are No Longer Simple

Think about the apps we use every day.

Food delivery apps.

Banking apps.

Shopping platforms.

Social media platforms.

Behind a simple button click, many things happen:

• APIs communicate
• Databases process data
• Services talk to each other
• Authentication systems validate users
• Notifications get triggered
• Background jobs start running

Users only see one screen.

Developers see an entire system.

That is where system design enters.

Problems Start Appearing at Scale

Most applications work fine with:

10 users

100 users

Even 1,000 users

But things become very different at:

100,000 users

1 million users

10 million users

Questions start appearing:

What happens if traffic suddenly increases?

How will data be stored?

Can servers handle the load?

How do we avoid failures?

What happens if one service crashes?

Writing code alone does not answer these questions.

System thinking does.

System Design Is Not Only About Big Diagrams

When many people hear system design, they imagine huge architecture diagrams.

Boxes.

Arrows.

Servers.

Complex terms.

Distributed systems.

Microservices.

But system design starts much earlier.

Even simple questions involve system thinking:

• Should we cache data?
• Should this process run in the background?
• How many API calls are happening?
• Can database queries be optimized?
• Can users face delays?

These decisions happen every day.

Even small projects have design choices.

AI Is Making This More Important

AI can now help generate code quickly.

It can suggest functions.

Create APIs.

Write components.

Generate documentation.

That is useful.

But AI usually focuses on local solutions.

A function.

A file.

A feature.

Humans still think about the bigger picture.

Questions like:

How does everything connect?

Will this scale?

Will this break later?

How maintainable is this?

System thinking becomes more valuable because someone still needs to understand the entire structure.

Developers Are Becoming Problem Solvers

The role of developers is changing.

Companies are not only looking for people who can write syntax.

They increasingly want people who can:

• Understand architecture
• Make design decisions
• Think about scale
• Predict problems
• Build maintainable systems

Because coding is only one part of engineering.

Understanding systems is another.

And that part keeps growing.

Final Thoughts

Maybe you do not need to become a system design expert tomorrow.

You do not need to memorize every architecture pattern.

But learning how systems work together is becoming important.

Because software is growing.

Complexity is growing.

Expectations are growing.

And system design is slowly moving from:

"A skill for senior developers"

"A skill for every developer."

What do you think?

Should developers start learning system design earlier in their journey?

I Built a “Truth or Trap” Game… And My Brain Kept Falling for It 😵‍💫🧠

Md Mijanur Molla — Sat, 16 May 2026 10:02:22 +0000

At first, I thought:

“This will be easy.”

Read a statement.

Choose TRUE or FALSE.

Move on.

Simple.

Then the game showed:

👉 A kilogram of iron is heavier than a kilogram of cotton

And suddenly…

My confidence disappeared 😭

So I built a small game called:

Truth or Trap

And honestly?

It became much more difficult than expected.

🎮 The Game Idea

The concept is simple:

A statement appears.

You decide:

👉 TRUE

or

👉 TRAP

That’s it.

But the twist is:

Some statements are intentionally designed to confuse your brain.

🧠 Examples

You might see things like:

2 + 2 + 2 = 8
A kilogram of iron is heavier than cotton
GREEN written in RED means GREEN
February has 30 days

Some look obvious.

Some look correct.

And some completely destroy your confidence 😄

⚠️ What Makes It Hard

The game mixes:

Logic traps
Visual confusion
Math tricks
Pattern illusions
Psychological misdirection

And as difficulty increases:

👉 Your brain starts trusting the wrong things

⏳ Pressure Makes It Worse

You don’t have unlimited time.

Every round includes:

Countdown timer
Score system
Limited lives
Faster progression

So now you're thinking under pressure.

And that changes everything.

💻 Challenge Rules

Build the entire game using:

HTML
CSS
Vanilla JavaScript

Everything inside:

👉 ONE single HTML file

No frameworks.

No libraries.

Just creativity + logic.

🚀 Try Similar Challenges Here

I’ve been exploring creative game-style coding challenges recently:

👉 https://vibecodearena.ai/beattheheat?page=1&pageSize=10&sortBy=responses&sortOrder=desc&utm_source=external&utm_medium=vc3&utm_campaign=beattheheat

Some look simple...

Until they completely trick your brain 😈

🎯 Final Thought

Sometimes wrong answers happen because you don't know.

And sometimes...

👉 Your brain confidently lies to you.

That second one is much scarier 😭

The Future Developer Stack: AI + Automation + Human Judgment

Md Mijanur Molla — Sat, 16 May 2026 09:30:35 +0000

A few years ago, the developer journey looked pretty simple.

Learn a programming language.

Learn a framework.

Build projects.

Deploy applications.

Get better over time.

Then things started changing.

Cloud came in.

DevOps became important.

Microservices arrived.

And now another layer has quietly entered the developer world:

AI.

Today, being a developer is not only about writing code anymore.

The future developer stack is slowly becoming:

AI + Automation + Human Judgment

And honestly, this combination might define the next generation of software engineers.

The Old Stack vs The New Stack

Earlier, many developers focused mainly on:

Programming languages
Frameworks
Databases
APIs
Deployment tools

Those things are still important.

But now the stack is growing.

Today's developers are also learning:

AI tools
Automation workflows
Prompt engineering
System thinking
Decision making
Product understanding

Because technology is changing how work gets done.

AI Makes Developers Faster

Let's be real.

AI tools today can:

Generate code
Explain complex logic
Write SQL queries
Suggest fixes
Create documentation
Help with debugging
Speed up learning

Many developers use AI daily now.

Instead of spending 30 minutes searching for an answer, developers can get help in seconds.

That is powerful.

But there is something important many people forget.

AI gives answers.

Developers still need to decide whether those answers are correct.

Because fast wrong code is still wrong code.

Automation Removes Repetitive Work

Developers spend a surprising amount of time doing repetitive tasks.

Things like:

Running tests
Deploying applications
Sending notifications
Data processing
Monitoring systems
CI/CD pipelines

Automation handles these tasks extremely well.

The goal is not replacing developers.

The goal is removing unnecessary work.

When repetitive tasks disappear, developers get more time for important things:

Thinking.

Designing.

Solving problems.

That is where real value comes from.

Human Judgment Is Becoming More Important

This might be the most underrated skill.

AI can generate code.

Automation can run workflows.

But neither truly understands:

Human emotions
Business priorities
User behavior
Tradeoffs
Real-world context

Imagine AI builds two solutions.

Both work.

Now someone needs to decide:

Which one is scalable?

Which one is secure?

Which one is easier to maintain?

Which one creates better user experience?

That decision still belongs to humans.

And that is judgment.

The Developer Role Is Quietly Changing

A lot of people ask:

"Will AI replace developers?"

Maybe that is the wrong question.

A better question is:

"How will developers change because of AI?"

Future developers may write fewer lines of code.

But they may spend more time:

Understanding problems
Making decisions
Designing systems
Connecting business needs with technology
Managing AI tools

Developers may slowly become technology decision makers instead of only code writers.

That is a huge shift.

Coding Is Becoming Easier

Thinking Is Becoming Harder

For years, coding itself was the difficult part.

Now AI helps generate code quickly.

So the difficult part is changing.

Today the challenge is:

Understanding requirements.

Understanding users.

Understanding systems.

Making smart decisions.

Because anyone can generate code.

Not everyone can build the right thing.

Final Thoughts

The future developer stack is probably not:

HTML + CSS + JavaScript + Frameworks

It may become:

AI + Automation + Human Judgment

AI can improve speed.

Automation can improve efficiency.

But human judgment gives direction.

And direction matters more than speed.

Because building software was never only about writing code.

It was always about solving problems.

What do you think?

Will future developers become coders, AI operators, or decision makers?

I would genuinely love to hear your thoughts.