DEV Community: Muhammad Azlaan Zubair

Frontend Is Easy… Until You Actually Build Something

Muhammad Azlaan Zubair — Mon, 22 Jun 2026 16:31:52 +0000

Every frontend developer has heard some variation of these:

"It's just a screen."
"Backend does the real work."
"AI can generate that."
"Just use ShadCN."
"Just copy the component."
"It's just a checkbox."

And every frontend developer silently smiles because they know where this story is headed.

Because somewhere, deep inside Jira, a "simple checkbox" is preparing to ruin someone's week.

The Great Myth: Frontend Being Easy

People outside frontend often imagine our job like digital LEGO.

Problem	Solution
Need a modal?	Copy one
Need a button?	ShadCN has it
Need a table?	AI can generate it
Need a form?	There are 37 libraries for that

Everything looks simple.

Until somebody says:

"Can we add a checkbox?"

And suddenly four days disappear from your life.

Ask me how I know.

The Story: "It's Just a Checkbox"

At my previous company, we were building a project management platform for a large auditing firm.

One day our PM asked for a checkbox on a senior consultant's dashboard.

"It's just a checkbox. You can probably do it in two hours. In fact, I'm giving you the whole day so you can test it too."

According to her, she was being generous.

Honestly, I thought the same.

How hard could a checkbox be?

Turns out my assumptions needed debugging.

Day 1: The Checkbox Doesn't Exist For Everyone

Turns out the checkbox wasn't for every senior consultant.

It should only appear if:

The project belongs to a certain client type or exceeds a revenue threshold.
The project is active.
The project belongs to a specific category.
The consultant is responsible for that project.
A few other client and project conditions are satisfied.

Okay.

Not terrible.

Just some filtering and conditions.

Still sounds like a checkbox.

Right?

Wrong.

Day 2: Clicking It Doesn't Actually Do Anything

Checking the box wasn't the feature.

The checkbox generated a request that needed approval from the consultant's senior manager.

Now we're talking about:

New API endpoints
New request states
Approval workflows
Error handling
Loading states
Notifications

Funny enough, the checkbox itself became the least interesting part.

Day 3: Management Doesn't Like Delays

Then another requirement appeared.

Senior managers didn't want requests piling up while they weren't around.

So the checkbox should only be visible when the corresponding manager was actively using the application.

Not online recently.

Not active today.

Actively connected.

At that moment.

Because if the manager wasn't available, consultants shouldn't create requests that would just sit waiting.

Which meant we needed real-time presence.

Not for chat.

Not for notifications.

For a checkbox.

Day 4: Congratulations, You've Built a System

By this point, we had:

Modified database models
Added new API contracts
Introduced new frontend states
Defined new data flows
Added presence tracking
Maintained socket connections
Managed synchronization between users
Tested edge cases
Handled loading, errors, and race conditions

And somewhere in the middle of all that…

There was a checkbox.

Thirty hours later, the feature was done.

Not because drawing a checkbox takes thirty hours.

Because business rules do.

The Funny Thing About Frontend

Frontend isn't difficult because buttons are hard.

The complexity comes from translating business requirements into behavior.

Every "simple" feature eventually turns into:

What if they're offline?
What if two users click simultaneously?
What if permissions change?
What if the API is slow?
What if the socket disconnects?
What if this user shouldn't even see the button?

The UI is where all these questions become visible.

Backend systems have complexity.

No doubt.

But frontend absorbs complexity coming from users, business rules, permissions, accessibility, responsiveness, loading states, and ever-changing requirements.

And unlike backend, everyone sees frontend.

Which means everyone has opinions about it.

Including people who think AI can replace it because it generated a pretty card component once.

"Just Use ShadCN"

I love ShadCN.

And I use AI daily.

Component libraries are amazing because they remove boring work.

But they don't solve business problems.

ShadCN gives you a checkbox.

It doesn't tell you:

Who should see it
When it should disappear
Which projects qualify
How approvals flow
How real-time presence works
What happens when connections fail
How state should synchronize

The hard part was never drawing the box.

It was understanding what the box actually meant.

AI Can Generate Components. It Can't Generate Context

AI is fantastic at generating buttons, forms, and layouts.

But business logic lives inside conversations.

Inside assumptions.

Inside requirements nobody mentioned until Wednesday afternoon.

And every developer knows this magical sentence:

"Oh, one more thing..."

Those four words have probably consumed more engineering hours than TypeScript errors.

So Is Frontend Easy?

Honestly?

Yes.

Right up until you actually build something.

Then you realize frontend isn't really about pixels.

It's about translating human chaos into something people can click.

And somehow making it feel simple.

Maybe that's why the best frontend work looks easy.

Not because it is.

But because somebody spent four days making a checkbox feel like a checkbox.

Fellow frontend developers, what's your "simple checkbox" story?

Is Overthinking a Red Flag? We Put AI Reasoning to the Test.

Muhammad Azlaan Zubair — Thu, 18 Jun 2026 19:22:57 +0000

Everyone says they want a partner who communicates.

Nobody says they want one who writes a 2,000-word essay before deciding where to eat.

And somewhere along the way, we started assuming the same thing about AI.

Bigger Brain, Bigger Bill

Reasoning isn't free.

Every extra thought means:

More tokens
More GPU time
More waiting
More electricity
More cost

Your wallet notices.

The environment notices.

Nobody talks about this part because "Consumes 3× more electricity" isn't exactly a sexy launch slogan.

The Question That Started Bothering Me

The question wasn't:

Can AI think harder?

It was:

Does thinking harder guarantee better results?

Those are very different questions.

And the answer turned out to be much messier than I expected.

More Thinking Doesn't Automatically Mean Better Thinking

Humans already know this.

We've all met that friend who turns a simple text message into a crime investigation.

Sometimes overthinking creates clarity.

Sometimes it creates noise.

Apparently computers aren't exempt.

Computers are fascinating and mildly offensive.

Complexity Has a Cost

We celebrate intelligence.

But we rarely celebrate efficiency.

Which is weird because engineers spend their entire careers optimizing things.

Nobody proudly announces:

Look! I made it slower!

Yet somehow we've become comfortable with:

More parameters
More chains of thought
More compute
More waiting

As if complexity itself is proof of quality.

Maybe we've confused effort with effectiveness.

Humans do that too.

Better Prompts Can Matter More

Another surprise:

Sometimes better instructions improve outputs more than additional reasoning.

Not bigger models.

Not longer chains of thought.

Just clearer communication.

Which honestly feels very human.

Maybe intelligence isn't only about thinking harder.

Maybe it's about asking better questions.

The Carbon Question Nobody Likes Talking About

Longer reasoning means more computation.

More energy.

More heat.

More emissions.

Multiply that by millions of requests and suddenly "thinking harder" becomes more than a technical decision.

It becomes an efficiency problem.

And maybe an environmental one too.

So, Is Overthinking a Red Flag?

Not always.

Complex problems deserve deep thinking.

But not every problem needs a philosophical debate.

Sometimes speed matters.

Sometimes efficiency matters.

And sometimes the answer produced in 5 seconds is nearly identical to the answer produced in 50.

Which raises an uncomfortable question.

Maybe the goal isn't building AI that thinks harder.

Maybe it's building AI that knows when to stop thinking.

Humans struggle with that.

Maybe machines do too.

That wasn't the answer I expected.

And honestly, that's the fun part.

One More Thing 📚

I spent way too much time chasing this question, and somewhere along the way it turned into a research paper.

If you're curious about the numbers and the more technical details, you can find them there. This post is really about the strange ideas, surprising observations, and all the little "Wait… what?" moments I ran into along the way.

Zubair, M. A., Bouchelligua, W., Danish, S., Ahmad, S., & Ksibi, A. (2026). Evaluating AI Reasoning and Prompt Engineering in Automated Test Case Generation: A Comparative Study of GPT-4o, O1 Models, and Human QA. Applied Soft Computing, 201, 115708. https://doi.org/10.1016/j.asoc.2026.115708

Apparently, "Wait… what?" is a valid research methodology.

And honestly, that's the fun part.