DEV Community: Muhammad Azlaan Zubair

The Biggest Thing I Learned at a Hackathon Had Nothing to Do with AI

Muhammad Azlaan Zubair — Tue, 29 Sep 2026 16:13:19 +0000

For most of my career, I thought software engineering was primarily about building things.

Choosing the right architecture.
Writing clean code.
Designing scalable systems.
Picking the right framework.
Optimizing performance.

Like many engineers, I believed the difficult part was implementation.

Recently, that belief changed.

Not because I suddenly became a better programmer.

But because I realized I had been asking the wrong first question.

Instead of asking,

"How do we build this?"

I should have been asking,

"Should this be built at all?"

That sounds like a small difference.

It isn't.

It completely changes how you think about engineering.

Engineers Love Solutions

Give engineers a problem and we'll immediately begin designing the solution.

We'll sketch architectures.
Compare frameworks.
Debate databases.
Experiment with AI models.
Think about scalability before we've even validated the need.

It's what we're trained to do.

Building systems is exciting.

But somewhere along the way, many of us become obsessed with solving problems before we've determined whether they're important enough to solve.

That's a dangerous habit.

Technology doesn't create value by existing.

It creates value by solving meaningful problems.

The Question That Changed My Thinking

During a recent hackathon, mentors kept asking questions that had almost nothing to do with technology.

Instead they asked:

Is this problem actually worth solving?
How many people experience it?
How often does it happen?
What does it cost the business today?
How much operational effort does it create?
If you improve this process by just 5%, what changes?

Those questions were surprisingly difficult to answer.

Not because they required technical knowledge.

Because they required understanding the business.

For the first time, I realized that software is only one piece of a much larger equation.

Code Is Becoming Easier

Today, AI can generate:

Boilerplate code.
Scaffold applications.
Write APIs.
Generate tests.
Explain unfamiliar frameworks.

Even complex implementation tasks are becoming significantly faster.

The cost of writing software is falling.

The availability of software engineers continues to grow.

In many cases, implementation is no longer the primary bottleneck.

The bottleneck is knowing what deserves to be built.

Better tools. Three people digging for gold in a mountain. Two are polishing expensive tools while one person studies a map pointing toward the richest vein of gold." width="800" height="450">

Great Startups Don't Win Because They Write Better Code

History is full of companies that didn't invent new technology. They identified better problems.

Uber didn't invent GPS.
Stripe didn't invent online payments.
Airbnb didn't invent booking systems.

They recognized friction that millions of people experienced and built products that removed it.

Technology was the enabler.

Problem selection was the advantage.

The bigger the problem, the bigger the opportunity.

Every Problem Is Not Equal

This is something I wish I had understood earlier.

Two applications may require the same amount of engineering effort.

One might save ten minutes for fifty people each month.

Another might save thirty seconds for ten million people every day.

Technically, they could be equally difficult.

Economically, they're worlds apart.

That's why the first responsibility of an Engineer, especially if you want to build products or startups, isn't writing code.

It's understanding the magnitude of the problem.

Ask questions like:

How many people are affected?
How frequently does it occur?
What is the financial cost?
What is the operational cost?
What is the human cost?
What happens if this problem disappears tomorrow?

Only after those answers become clear should technology enter the conversation.

Engineering Is Becoming More About Judgment Than Coding

I don't believe software engineering is disappearing. Far from it.

Reliable software still requires engineering judgment, careful design, testing, security, maintainability, and countless trade-offs that no prompt can eliminate.

But I do believe the value of engineers is shifting.

As implementation becomes faster, the ability to identify meaningful problems, understand users, evaluate trade-offs, and connect technology to business outcomes becomes increasingly valuable.

The engineer who only knows how to build will always be useful.

The engineer who knows what to build and why will shape products, companies, and industries.

What Changed for Me

I still enjoy building software. I probably always will.

But these days, I find myself spending more time asking questions before opening my editor.

Is this solving a real problem?
Who benefits?
How much value does it create?
Is this the highest-impact use of our time?

Because writing software is no longer the hardest part.

Choosing the right problem might be.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

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.