DEV Community: Safiullah Korai

Google I/O 2026 Made Me Realize the Future of Software May Not Have Traditional Apps

Safiullah Korai — Wed, 27 May 2026 15:00:00 +0000

I’m Safiullah Korai, though many know me as Shahzaib. I’m a Software Engineer and full‑stack Flutter developer, building production apps and sharing what I learn along the way. So when I sat down to watch the Google I/O 2026 keynote, I wasn’t just curious about the latest AI announcements. I was trying to understand what they might mean for developers like me. Halfway through the recap, I paused the video and replayed a few demos again.

Not because they were difficult to understand.

Not because the technology looked unrealistic.

But because something about the direction felt strange.

For years, software development has revolved around interfaces. Developers build screens. Designers craft user flows. We optimize layouts, animations, responsiveness, and interactions because software depends on users constantly moving through products manually.

You open an app.

You click buttons.

You navigate screens.

You manually complete tasks.

That has been the structure of software for decades.

But this keynote quietly suggested something different.

Instead of humans constantly moving through software, software is starting to move around humans.

And honestly, I think that changes everything for developers, designers, and builders.

The Biggest Shift Was Not AI Models. It Was AI Behavior.

While most people focused on Gemini models, token numbers, and benchmarks, the more interesting thing was how AI behaved throughout the keynote.

Gemini Spark, AI Search, generated workflows, and contextual interfaces all pointed toward the same direction: software is becoming proactive instead of reactive.

The “weekend planner” demo looked simple at first glance, but it may have been one of the most important moments in the keynote. Search combined maps, reservations, schedules, recommendations, calendar information, and contextual reasoning into something that no longer felt like a traditional search result.

It felt like a temporary application generated specifically for one user at one moment.

That idea stayed in my mind because it challenges one of the biggest assumptions frontend developers have always worked with: the idea that we build fixed interfaces for everyone.

But what happens when interfaces become dynamic?

What happens when AI starts generating experiences based on intent instead of predefined screens?

The future may slowly move away from:

one interface for millions of users

toward:

millions of interfaces generated for individuals

And if that happens, the role of developers and UI designers changes completely.

What Happens to Flutter Developers and UI Designers?

I do not think frontend development is disappearing.

And honestly, I do not think UI designers suddenly become irrelevant the way people online often claim whenever a new AI demo appears.

But I do think the value is shifting.

AI is becoming very good at generating layouts, reusable components, responsive screens, boilerplate code, and even user flows. The repetitive part of interface work will probably become increasingly automated over time.

But products were never successful only because their buttons looked nice.

The developers and designers who remain valuable will be the people who deeply understand:

Human behavior
Systems
Communication
Psychology
Product thinking
User experience

Because when AI can generate interfaces automatically, the real challenge becomes creating experiences that actually feel intuitive and meaningful.

As someone building with Flutter, this honestly feels less like the death of frontend development and more like the evolution of it.

The future frontend developer may spend less time manually building every screen and more time designing systems that intelligent software can adapt dynamically around users.

Ironically, AI may automate parts of design while making creativity even more important.

The Shift From Assistants to Agents Changes Software Entirely

One thing that stood out repeatedly during the keynote was the shift from assistants to agents.

That difference matters more than people think.

An assistant waits for commands.

An agent operates continuously.

Gemini Spark organizing tasks, updating documents, monitoring information, and working in the background even after the laptop closes did not feel like a chatbot anymore. It felt like the beginning of persistent digital systems operating quietly around users.

And if software starts becoming agent-driven, then many products may stop competing for attention and start competing for integration into AI workflows instead.

That changes how developers think about:

APIs
Automation
Interoperability
Context-awareness
Product architecture itself

The internet slowly starts shifting from “apps people use” toward “systems AI coordinates.”

Developers May Need to Rethink What Building Software Means

The Antigravity demo made this shift even clearer.

Watching AI agents collaborate to build parts of an operating system honestly felt less like autocomplete and more like a preview of where software engineering workflows are heading.

Not because developers are suddenly unnecessary.

But because the role itself is evolving.

For years, developers were valued mostly for implementation. Now I think the industry is slowly moving toward valuing systems thinking, architecture, communication, creativity, problem solving, and the ability to guide intelligent systems effectively.

As someone still learning and building every day, I genuinely think upcoming developers should pay attention to this shift early.

Memorizing syntax alone will not be enough anymore because AI is already becoming capable of generating large portions of implementation.

But clear thinking still matters.

Taste still matters.

Judgment still matters.

Creativity still matters.

Maybe more than ever.

Software Is Quietly Becoming AI-Native

Another reason this keynote felt important was because AI no longer looked like a feature being inserted into products. The products themselves are becoming AI-native systems.

Search is changing.

Commerce is changing.

Creative workflows are changing.

Software development itself is changing.

And I honestly think we are only seeing the beginning of that transition.

The future internet may not revolve around apps the same way today’s internet does. It may revolve around intelligent systems quietly handling complexity for users in the background while interfaces become lighter, more adaptive, and sometimes almost invisible.

That is both exciting and slightly uncomfortable to think about as a developer because nobody fully knows what building software will look like five years from now.

But after watching Sundar Pichai and the rest of the keynote, one thing feels very clear:

The way we build software is changing much faster than most people realize.

Watch the Demos Yourself

A lot of AI discussions online simplify announcements into headlines and short clips, but watching the actual demos gives much better context, especially if you are a developer, UI designer, founder, student, or someone trying to understand where technology is heading next.

Watch the short 15-minute recap first

Watch it Here. The recap is perfect for quickly understanding the major announcements and overall direction without spending hours watching the full keynote.

Then watch the full keynote for the deeper technical context

Watch it Here. The full keynote helps you notice smaller details around AI agents, generated interfaces, developer workflows, infrastructure, and how Google is positioning AI across its entire ecosystem.

🧭 Want to Learn Smarter as a Developer?

I write about Flutter, developer mindset, and learning techniques. Follow me here for more practical tech learning insights.

✍️ Written by Safiullah Korai — Flutter Developer, Tech Writer & Lifelong Learner

Why Developers Can No Longer Afford to Be Invisible Online

Safiullah Korai — Tue, 19 May 2026 15:00:00 +0000

I’m Safiullah Korai, though many know me as Shahzaib.

I’m a Software Engineer and full‑stack Flutter developer who started sharing my journey online not so long ago. Over time, by consistently documenting what I was learning and building, something interesting happened: my name began to show up. If you search Safiullah Korai on Google, you’ll see a knowledge panel, a quiet snapshot of my work and background. That small digital footprint now gives a strong first impression of credibility and consistency, even before someone reads a single article. I’ve experienced firsthand how the internet has become the new resume, and I want to share why developers can no longer afford to stay invisible.

There was a time when a one-page resume carried most of the weight in a developer’s career.

A degree, a few technical skills, some project titles, and maybe an internship or two were enough to apply for opportunities. The process was simple. You submitted a CV, waited for a response, and hoped someone noticed your application among hundreds of others.

But the internet changed that system completely.

Today, before many recruiters even open your resume, they search your name.

They look at your GitHub.

Your LinkedIn.

Your projects.

Your articles.

Your online presence.

And whether we realize it or not, all of these things together now communicate far more than a traditional resume ever could.

The internet has quietly become the new resume.

A Resume Tells People What You Did. The Internet Shows How You Think.

This is the biggest difference.

A resume is compressed information. It lists technologies, experiences, and achievements in short bullet points. Useful, but limited.

The internet, on the other hand, creates context.

A GitHub profile shows how you build.

A technical article shows how you explain ideas.

A portfolio reveals your design sense.

A project walkthrough demonstrates problem solving.

Even a thoughtful post can reflect curiosity and consistency.

These things feel more human than a PDF attachment.

Instead of simply claiming skills, you demonstrate them publicly.

That changes how people perceive you.

Visibility Matters More Than Ever

The tech industry has become incredibly crowded.

Every day, thousands of developers:

Learn new frameworks
Build projects
Apply for internships
Complete online courses

Skill alone is no longer enough to stand out.

Visibility matters.

This does not mean becoming an influencer or chasing viral content. It simply means making your work discoverable. Because if nobody can see what you are learning or building, opportunities have very little to connect with.

The internet rewards visible effort.

Not always immediately.

Not always dramatically.

But consistently over time.

Student Developers Have More Opportunity Than Ever

One of the most interesting shifts in tech is that students no longer need years of experience to build credibility.

In the past, students often had to wait until graduation before being taken seriously. Today, a student developer with:

A strong GitHub profile
Thoughtful technical writing
Visible projects
Consistent learning posts

can stand out globally before earning a degree.

That is powerful.

The internet removes geographic limitations in a way traditional resumes never could. A student from a small city can now share ideas, contribute to communities, and connect with developers around the world.

Talent is no longer limited to physical spaces.

Your Digital Presence Builds Trust Before Conversations Begin

One underrated benefit of an online presence is trust.

Imagine two developers applying for the same opportunity.

The first submits only a resume.

The second submits a resume, but also has:

Technical articles
Project case studies
Open-source contributions
Visible learning progress
Thoughtful online engagement

Who feels more real?

The second developer already communicates motivation, consistency, and initiative before the interview even begins.

This is what the internet does well. It provides evidence beyond self-description.

Anyone can write “passionate developer” on a resume.

But public work proves it.

Learning in Public Creates Opportunity

One reason the internet has become such a powerful professional tool is because of discoverability.

When you share your journey online, people begin finding your work naturally.

Sometimes it happens quietly:

Someone bookmarks your article
Another developer follows your progress
A recruiter notices your projects
A founder discovers your posts
A community invites you to contribute

Most opportunities online do not arrive dramatically.

They grow gradually through repeated visibility.

This is why learning in public matters so much. It creates a trail of growth that people can follow over time.

I explored this idea in depth in my article Why Learning in Public Accelerates Growth as a Developer, which explains how sharing your journey speeds up your growth and compounds your learning.

GitHub Alone Is Not Enough Anymore

For years, developers were told:

“Just build projects.”

Projects still matter deeply, but the ecosystem around them matters too.

A strong project with:

Clear documentation
A project breakdown article
Screenshots
Lessons learned
Deployment links

feels much more complete than code sitting silently in a repository.

The internet rewards communication as much as creation.

This is becoming increasingly important because software development is collaborative by nature. Companies value developers who can:

Explain ideas clearly
Document processes
Communicate decisions
Share knowledge effectively

Technical skill opens doors. Communication keeps them open.

Personal Branding Is Really About Documentation

The phrase “personal brand” often feels uncomfortable to developers.

It sounds overly corporate or performative.

But meaningful personal branding is usually much simpler than people think.

It is not about pretending to be perfect.

It is about documenting real growth consistently.

When you share:

What you are learning
What you are building
What challenges you faced
What insights you gained

you slowly build a digital identity around curiosity and growth.

Over time, people begin associating your name with certain interests, technologies, or ideas.

That association becomes valuable professionally.

I wrote about this in even more depth, specifically for students, in an article called How Student Developers Build a Personal Brand That Opens Doors. It explains why starting early matters and how small acts of sharing can compound into opportunities long before graduation.

The Internet Rewards Consistency More Than Perfection

Many developers delay posting online because they feel unprepared.

They think:

Their projects are too small
Their writing is not good enough
Their skills are not advanced enough

But the internet rarely rewards perfection in the long term.

It rewards consistency.

Developers who consistently share useful ideas, progress updates, and learning experiences often build stronger reputations than those who wait endlessly for the “perfect” moment.

Growth becomes visible through repetition.

And visible growth builds credibility.

Writing Has Become a Career Advantage

Technical writing is no longer a niche skill.

It is becoming a competitive advantage.

Developers who write online demonstrate:

Clarity of thought
Communication skills
Teaching ability
Problem-solving mindset

A well-written article can sometimes create more professional opportunities than a certificate.

Why?

Because it shows applied understanding instead of passive completion.

This is why more developers are starting blogs, publishing tutorials, and documenting their journey publicly.

Writing scales knowledge beyond conversations.

I’ve written more about the deep reasons writing matters for developers in an article called Why Every Developer Should Write.

Online Presence Changes Networking Completely

Traditional networking often depended on physical access:

Conferences
Universities
Workplaces
Events

The internet changed that.

Now, a thoughtful article or project can start conversations with people you have never met.

Developers connect through:

Communities
Comments
Sewsletters
Social platforms
Shared interests

This type of networking feels more natural because it grows around ideas instead of forced introductions.

Your work becomes the conversation starter.

Being Invisible Has Become a Disadvantage

This may sound harsh, but it is increasingly true.

A talented developer with no visible presence often gets overlooked compared to someone slightly less experienced but highly visible online.

Not because visibility replaces skill.

But because visibility helps people discover skill.

The internet cannot recognize what it cannot see.

This is especially important for:

Students
Self-taught developers
Junior engineers
People without traditional connections

An online presence creates access that did not exist before.

You Do Not Need Thousands of Followers

One misconception about building an online presence is that success depends on large audiences.

It does not.

You do not need viral posts or massive followings.

A small but genuine network of developers, readers, and collaborators can create meaningful opportunities over time.

Quality of connection matters more than quantity of attention.

The goal is not internet fame.

The goal is professional discoverability.

How to Start Building Your Online Presence

You do not need a complicated strategy.

Start small.

You can:

Share project progress
Write technical articles
Post lessons learned
Contribute to open source
Explain concepts you recently learned
Create a portfolio website

The important part is consistency.

Do not wait until you feel fully prepared. Most developers never reach that feeling anyway.

If you want a practical, step‑by‑step guide to get started with technical writing, my article How to Start Technical Writing as a Developer walks you through everything from picking a topic to hitting publish.

And if you’re unsure where to publish your first piece, I’ve written a calm guide called Where to Write as a Developer to help you choose the right platform.

Final Thoughts

A resume still matters.

But it is no longer the full picture.

Today, your online presence often communicates more than your formal application ever could. It shows how you think, what you care about, how consistently you learn, and whether you are actively growing.

The internet has become the place where developers build reputation before opportunity arrives.

And the people benefiting most from this shift are not necessarily the smartest developers.

Often, they are simply the ones willing to stop building in silence and start sharing their journey publicly.

Because in a world where visibility creates connection, the internet is no longer just a place to browse.

For developers, it has become the new resume.

🧭 Want to Learn Smarter as a Developer?

I write about Flutter, developer mindset, and learning techniques. follow me for more practical tech learning insights.

✍️ Written by Safiullah Korai — Flutter Developer, Tech Writer & Lifelong Learner

How Student Developers Build a Personal Brand That Opens Doors

Safiullah Korai — Fri, 15 May 2026 15:00:00 +0000

For a long time, I thought personal branding was something only experienced professionals cared about.

Founders had personal brands. Senior engineers had personal brands. Creators with thousands of followers had personal brands.

Students did not.

At least that is what I believed.

As a student developer, I assumed my only responsibility was to learn, build projects, and someday apply for jobs. I thought visibility could wait until I became “good enough.”

But the internet works differently now.

I’m Safiullah Korai, though many know me as Shahzaib. I’m a Software Engineer and full‑stack Flutter developer, and I began my own journey not so differently from where many students are right now. Over time, by consistently sharing what I learned and documenting my growth, something interesting happened, my name started showing up. If you search Safiullah Korai on Google or If you click here, you’ll find a knowledge panel, a simple snapshot of my work and background. That small digital footprint now gives a strong impression of credibility and consistency, even before someone reads a single article. I’ve explored this idea before in an article called Why Learning in Public Accelerates Growth as a Developer, which explains why sharing your process matters. Today I want to talk about how that same habit shapes something even more lasting that is your personal brand.

Today, some of the most recognizable developers online are not industry veterans. They are students documenting their learning journey, sharing projects, writing articles, participating in communities, and consistently showing up online.

That realization changed how I viewed growth in tech.

A personal brand is no longer about fame or self-promotion. For developers, it is becoming a digital representation of your curiosity, consistency, and learning journey.

And the best time to start building it is much earlier than most people think.

What Personal Branding Actually Means

The phrase “personal brand” often sounds more complicated than it really is.

People imagine aggressive self-promotion, fake motivation posts, or constantly trying to look successful online. That is not what a meaningful personal brand is.

For a student developer, a personal brand is simply the public trail of your growth.

It is:

the projects you build
the ideas you share
the problems you solve
the communities you contribute to
the way you communicate online

Whether you intentionally build it or not, your online presence already tells a story about you.

The question is whether you want that story to exist by accident or by design.

The Internet Has Become the New Resume

There was a time when resumes carried most of the weight in tech hiring.

Now, people often search your name before reading your CV.

They check:

your GitHub
your LinkedIn
your articles
your projects
your online presence

This changes everything for student developers.

You no longer need years of experience to stand out. You can demonstrate curiosity, consistency, and communication publicly while still learning.

A student with visible work often attracts more attention than someone with stronger skills but no visible presence.

Because visible effort builds trust.

You Do Not Need to Be an Expert to Start

This is the biggest reason most students hesitate.

They think:

“I do not know enough yet.”

But personal branding in tech is not about pretending to be an expert. In fact, people often connect more deeply with learners because the journey feels relatable and honest.

You do not need mastery to share:

what you are learning
what you are building
what confused you
what you recently understood

Some of the best developer content online comes from people documenting progress in real time.

Growth itself becomes valuable content.

Consistency Matters More Than Perfection

One polished post will not build a meaningful presence.

Consistency will.

This is important because many students overthink visibility. They spend weeks trying to create the “perfect” project or write the “perfect” article before posting anything publicly.

Meanwhile, another student simply shares small progress consistently and slowly becomes recognizable.

The internet rewards repeated presence.

Not because algorithms are magical, but because trust forms gradually. When people repeatedly see someone learning, building, and improving, they naturally start remembering them.

That recognition compounds over time.

Your Journey Is More Relatable Than You Think

Experienced developers sometimes explain things from a level that feels intimidating to beginners.

Student developers have an advantage here.

You still remember confusion clearly.

You understand what it feels like to struggle with:

Git commands
state management
deployment issues
debugging errors
imposter syndrome

That perspective is valuable because thousands of other students are going through the same experience right now.

When you share honestly, people connect with authenticity much more than perfection.

Building in Public Creates Opportunities

One of the most surprising things about personal branding is how opportunities begin appearing indirectly.

Not dramatically.

Quietly.

Someone reads your article and sends a message. Another student asks to collaborate. A community notices your consistency. A recruiter sees your project walkthrough. A founder discovers your profile through a shared post.

None of these opportunities are guaranteed.

But none of them happen if your work remains invisible.

Personal branding increases discoverability. It allows your work to travel beyond your immediate circle.

And over time, that visibility matters.

Writing Is One of the Strongest Branding Tools

Many developers think personal branding only means social media content.

But writing remains one of the most powerful ways to build credibility online.

When you write:

tutorials
reflections
project breakdowns
learning experiences

you demonstrate much more than technical skill.

You show:

communication ability
clarity of thought
consistency
curiosity

A well-written article can create stronger professional credibility than dozens of random posts.

This is why technical writing is becoming such an important skill for developers.

I’ve written more about the deep reasons writing matters in an article called Why Every Developer Should Write. If you want a practical, step‑by‑step way to get started, my guide How to Start Technical Writing as a Developer walks you through everything from picking a topic to hitting publish. And if you are unsure where to share your first piece, I have a calm guide titled Where to Write as a Developer that helps you choose the right platform.

Communities Matter More Than Followers

A common mistake student developers make is focusing too much on numbers.

Followers feel important because they are visible metrics. But meaningful growth usually comes from communities, not audiences.

A small group of genuine developer connections is more valuable than large numbers without engagement.

Communities expose you to:

collaboration opportunities
mentorship
accountability
feedback
friendships

The internet becomes much more powerful when you stop treating it like a performance stage and start treating it like a place to connect.

Personal Branding Helps You Discover Yourself

One underrated benefit of sharing online is self-discovery.

When you consistently post projects, articles, or insights, patterns begin appearing.

You notice:

which technologies excite you
what kinds of problems interest you
which topics you naturally enjoy discussing

Over time, your online presence becomes a reflection of your interests.

This clarity is valuable because many student developers feel overwhelmed by endless career paths in tech.

Documenting your journey helps you understand your own direction more clearly.

You Are Building Reputation Before You Need It

Most people wait until they urgently need opportunities before trying to build visibility.

That approach is stressful.

Personal branding works best when built gradually over time. A strong online presence compounds slowly, similar to learning itself.

If you consistently share for months or years, people begin associating your name with:

learning
consistency
helpfulness
growth

Then, when opportunities eventually matter more, you are not starting from zero.

Your reputation already exists.

The Fear of Judgment Never Fully Disappears

One honest reality about sharing online is this:

It can feel uncomfortable.

You may worry:

your work is not impressive enough
people will judge beginner mistakes
nobody will care what you post

Almost every developer who shares online experiences this at some point.

But over time, you realize something important.

Most people are too focused on their own journey to constantly judge yours.

And the few who genuinely care about learning and growth usually respect honesty far more than perfection.

A Simple Way to Start

You do not need a complicated strategy.

Start small.

You can:

share project screenshots
write short learning posts
publish technical articles
explain concepts you recently learned
document project progress

The goal is not to impress people immediately.

The goal is to create momentum.

Personal Branding Is Really About Documentation

The phrase “building a personal brand” sounds intimidating because it feels corporate and calculated.

But for student developers, it is often much simpler than that.

You are not creating a fake identity.

You are documenting real growth.

That mindset changes everything.

Because suddenly, you no longer need to appear perfect. You just need to appear genuine.

Final Thoughts

A personal brand is not built in a week.

It is built slowly through visible consistency.

Every article, project, reflection, and shared lesson becomes part of a larger story. Over time, that story begins opening doors you cannot predict in advance.

The students who benefit most from the internet are usually not the ones who quietly wait until they feel fully prepared.

They are the ones willing to learn publicly, contribute consistently, and document the journey while it is still unfolding.

And in today’s world, that visibility can become one of the most valuable assets a developer builds before graduation.

🧭 Want to Learn Smarter as a Developer?

I write about Flutter, developer mindset, and learning techniques. Follow me here for more practical tech learning insights.

✍️ Written by Safiullah Korai — Flutter Developer, Tech Writer & Lifelong Learner

Why Learning in Public Accelerates Growth as a Developer

Safiullah Korai — Wed, 13 May 2026 15:00:00 +0000

For a long time, I believed learning had to happen quietly.

I thought real developers studied in silence, solved problems alone, and only shared polished results once they became “good enough.” So I kept everything to myself. The bugs I fixed, the concepts I struggled with, the projects I abandoned halfway through. None of it existed publicly.

My name is Safiullah Korai, though many know me as Shahzaib. I’m a Software Engineer and full‑stack Flutter developer, building production apps, experimenting with architecture, and navigating the quiet challenges of growing in tech.

Over time, I started noticing something interesting.

The developers growing the fastest were not always the most talented. They were often the ones documenting their journey openly. They shared small discoveries, lessons from failed projects, confusing bugs, and things they had just learned hours earlier.

At first, I did not understand why that mattered. Then I tried it myself.

One small post turned into a conversation. That conversation turned into consistency. And consistency slowly changed how I learned, how I thought, and how I approached growth as a developer.

Learning in public is not a trend. It is one of the most effective ways to accelerate improvement in tech.

Most Developers Learn in Isolation

Programming is already a mentally demanding field. Most of the process happens alone. You spend hours reading documentation, debugging errors, experimenting with code, and trying to connect concepts that initially feel disconnected.

The strange part is that none of this effort is visible.

People usually only see finished projects, successful launches, or polished portfolios. They do not see the confusion behind them. Because of that, many developers underestimate their own progress. They feel stuck even while improving because their growth has no visible record.

Learning in public changes this dynamic completely.

Instead of treating learning as a private process hidden behind a screen, you begin documenting it. You create a trail of progress, and over time that trail becomes valuable not just for others, but for yourself as well.

Learning in Public Does Not Mean Pretending to Be an Expert

One of the biggest reasons developers hesitate to share online is the belief that they need to know more first.

They think technical writing, posting online, or explaining concepts is reserved for experts with years of experience. But learning in public was never about pretending to have mastery. In fact, its value comes from honesty.

You are not positioning yourself as someone who knows everything. You are simply documenting what you are discovering along the way.

That distinction matters.

There is something incredibly relatable about a developer explaining a concept they just learned yesterday. The explanation is fresh. The confusion is still remembered. The language feels accessible instead of intimidating.

Ironically, beginners often explain things better for other beginners because they still remember what it felt like not to understand.

Explaining Ideas Forces Deeper Understanding

One of the most surprising benefits of learning in public is how much it improves understanding.

Reading documentation can create the illusion of knowledge. Watching tutorials can make concepts feel familiar. But the moment you try to explain something in your own words, the gaps in your understanding become obvious.

Writing a post about state management, for example, forces you to organize your thoughts clearly. You begin asking yourself questions you might otherwise avoid:

Why does this pattern exist?

What problem does it actually solve?

How would I explain this to someone newer than me?

That process sharpens thinking.

You stop passively consuming information and start processing it actively. Over time, this habit compounds. Concepts become easier to retain because you engaged with them deeply instead of skimming through them quickly.

If you want to put that clarity into a consistent writing practice, my guide How to Start Technical Writing as a Developer walks through the practical side, from picking your first topic to building a habit that sticks. But the deeper transformation happens right here, in the space where confusion turns into clarity.

The Internet Rewards Developers Who Share

There are millions of developers online, but only a small percentage consistently share what they learn.

That creates an interesting opportunity.

The internet naturally amplifies visible effort. When you post about your projects, lessons, experiments, or challenges, people begin associating your name with growth and consistency. You become discoverable.

This is important because opportunities rarely appear in isolation anymore.

A recruiter may discover your article. Another developer may connect with your learning journey. A founder may notice how clearly you communicate technical ideas. None of this happens if your work stays invisible.

The internet cannot reward what it cannot see.

Learning in public increases the surface area of luck. It allows opportunities to find you through the trail you leave behind.

Feedback Speeds Up Growth

Learning alone has limitations.

When you only rely on your own perspective, mistakes stay hidden longer. You may spend days solving something inefficiently without realizing there is a simpler approach.

Public learning introduces feedback into the process.

Someone reading your article might suggest a better solution. Another developer may point out an edge case you missed. A more experienced engineer may offer insight that changes how you think about a problem entirely.

This feedback loop is incredibly valuable.

You improve faster because your learning process becomes collaborative instead of isolated. Over time, those small corrections and discussions significantly shape your technical growth.

Documentation Becomes a Long-Term Asset

Most developers forget more than they realize.

A bug fixed three months ago feels obvious at the time, but surprisingly difficult to remember later. The same applies to concepts, workflows, and solutions.

Learning in public solves this problem naturally because your content becomes a searchable archive of your own journey.

Your articles, notes, and posts turn into personal documentation. Instead of relearning the same lessons repeatedly, you build a knowledge base that grows with you.

Years later, you may revisit something you wrote as a beginner and realize how far you have come. That perspective is motivating in ways most developers underestimate.

Confidence Comes From Visibility, Not Perfection

A lot of developers wait to feel confident before sharing online.

But confidence rarely appears before action. It usually appears because of repeated action.

The first post feels uncomfortable. The second feels slightly easier. Eventually, sharing becomes normal. You become more comfortable expressing ideas, discussing technical topics, and communicating your thoughts publicly.

This confidence extends beyond writing.

It improves interviews, collaboration, presentations, and even problem solving because communication itself becomes a practiced skill rather than an afterthought.

And in the tech industry, communication is often more valuable than people realize.

Learning in Public Helps You Find Your Direction

In the beginning, most developers explore everything.

Frontend, backend, mobile apps, AI, cybersecurity, design systems. The possibilities are endless, which often creates confusion.

But something interesting happens when you consistently share what you are learning.

Patterns begin to appear.

You notice which topics excite you enough to write about repeatedly. You notice what kinds of problems naturally capture your attention. Over time, your public learning journey starts revealing your interests more clearly than any career plan ever could.

That clarity matters.

Because growth becomes easier once you know what genuinely interests you.

It Is Not About Building an Audience

One misconception about learning in public is that it is mainly about gaining followers.

That mindset usually leads to frustration.

The real value is not the audience itself. It is the transformation that happens during the process. You become more reflective, more intentional, and more articulate. You learn to organize ideas clearly and communicate them effectively.

An audience may eventually come as a result of consistency, but it should not be the primary goal.

Growth should be.

If you are still looking for the deeper reasons why writing and sharing quietly change everything, I explored that in Why Every Developer Should Write. Not for attention, but for the clarity and inner confidence that compound over time.

How to Start Learning in Public

The best way to start is also the simplest.

Do not try to sound impressive. Do not try to teach advanced concepts immediately. Just document what you are already learning.

a bug you solved
a lesson from a project
a concept you finally understood
a mistake that taught you something useful

Small insights are enough.

Consistency matters far more than complexity.

If you are wondering where to actually put those small insights so they get seen without feeling scattered, I wrote a calm guide on choosing your first platform called Where to Write as a Developer. It helps you pick a home that matches your style and then grow from there.

Final Thoughts

Learning in silence feels safe because nobody can judge unfinished progress. But silence also slows growth. It keeps your ideas untested, your work invisible, and your journey disconnected from the larger developer community.

Learning in public changes that.

It transforms learning from a private struggle into a shared experience. It improves understanding, creates opportunities, builds confidence, and connects you with people walking similar paths.

Most importantly, it reminds you that growth does not need to wait until you become an expert.

Sometimes growth accelerates the moment you decide to stop hiding the process.

🧭 Want to Learn Smarter as a Developer?

I write about Flutter, developer mindset, and learning techniques. Follow me here for more practical tech learning insights.

✍️ Written by Safiullah Korai — Flutter Developer, Tech Writer & Lifelong Learner.

Why Every Developer Should Write: The Skill That Quietly Changes Everything

Safiullah Korai — Sun, 10 May 2026 13:27:50 +0000

I did not plan to become someone who writes.

I was just trying to survive as a developer.

There were days when nothing made sense. Errors that felt personal. Concepts that refused to stick. Tutorials that skipped the exact step I needed.

And then there was silence.

No one talks about how confusing this journey can be in the beginning. Or how often you doubt yourself when things do not work.

So one day, after solving a small problem, I wrote about it.

Not because I thought it was important.

But because I did not want to forget how I solved it.

That simple act changed more than I expected.

I’m Safiullah Korai, some of you might know me as Shahzaib.

I am a Software Engineer and full-stack Flutter developer.

Over the past few years, I have spent countless hours building mobile applications, experimenting with architecture, and chasing that balance between simplicity and scalability. And quietly, almost without me noticing, writing became the thread that held the learning together.

Here’s why.

Writing Is How You Make Sense of What You Learn

As developers, we consume a lot.

Documentation. Tutorials. Videos. Codebases.

But consumption alone creates an illusion of understanding.

You feel like you know something until you try to explain it.

Writing forces a different level of thinking.

When you sit down to write, you realize:

Where your understanding is weak
What you cannot explain clearly
Which parts you skipped while learning

It is uncomfortable.

But it is honest.

Writing turns passive learning into active understanding.

It slows you down just enough to actually think.

You Forget More Than You Think

There is a harsh truth in development.

You forget fast.

That bug you solved last month

That concept you finally understood

That workaround you discovered

It fades.

And when it comes back, you start from zero again.

Writing creates a memory that does not fade.

Your articles become your personal knowledge base.

Instead of searching the internet again, you search your own work.

And sometimes, your past self becomes your best teacher.

Writing Builds Confidence Without Noise

Many developers struggle with confidence.

Not because they are not capable

But because they have no visible proof of their progress

Writing changes that.

Each article is evidence.

Evidence that you learned something

Evidence that you can explain it

Evidence that you are growing

You do not need to announce it loudly.

Your work speaks quietly.

Over time, that quiet confidence becomes stronger than any external validation.

You Do Not Need to Be an Expert to Help Someone

There is a common belief that stops many developers from writing.

“I am not experienced enough.”

But think about this.

The person who is one step ahead of you is often more helpful than the expert who is ten steps ahead.

Because they remember the struggle.

They remember the confusion.

They explain things in a way that makes sense to beginners.

Your knowledge may feel small to you.

But to someone else, it is exactly what they need.

Writing Connects You With People You Have Never Met

Most of us write code in isolation.

Even in teams, deep work is often solitary.

Writing changes that.

When you publish something, you are starting a conversation.

Someone reads it in another city

Another student learns from it

Another developer relates to your struggle

And sometimes, they respond.

A comment. A message. A simple “this helped me”.

That moment feels different.

Because your work reached beyond your screen.

Opportunities Do Not Always Come From Code Alone

We like to believe that code speaks for itself.

Sometimes it does.

But often, it does not.

People cannot see how you think just by looking at your repositories.

Writing makes your thinking visible.

It shows:

How you approach problems
How you explain ideas
How you learn and adapt

This matters more than we admit.

Many opportunities come not because you are the best coder in the room, but because you can communicate clearly.

Writing proves that skill.

Writing Creates a Long-Term Asset

Most of what we do as developers is temporary.

Projects get archived

Code gets replaced

Technologies change

But writing stays.

An article you write today can still help someone a year later.

Or even five years later.

It becomes a part of your digital presence.

A small piece of work that keeps working for you.

This is what makes writing powerful.

It compounds.

It Helps You Find Your Direction

In the beginning, many developers feel lost.

Too many options

Too many technologies

Too many paths

Writing helps you notice patterns.

You start seeing:

What topics you enjoy writing about
What problems you like solving
What kind of work excites you

Over time, this shapes your direction.

Not through pressure.

But through reflection.

Writing Is a Form of Thinking

We often treat writing as an output.

Something you do after learning.

But writing itself is thinking.

Clear writing requires clear thought.

If your writing is messy, your understanding is probably messy too.

This is not a criticism.

It is a tool.

Writing helps you organize your thoughts.

It forces structure.

And that structure improves how you approach problems in code as well.

It Slows Down a Fast World

The tech world moves fast.

New frameworks

New tools

New trends

It is easy to feel like you are always behind.

Writing creates a pause.

It gives you a moment to reflect.

To understand what you learned instead of rushing to the next thing.

That pause is valuable.

Because depth matters more than speed.

You Start Leaving a Trail Behind You

Most developers move forward without leaving anything behind.

No record of what they learned

No trace of their journey

Writing changes that.

It creates a trail.

If someone follows that trail, they can see:

Where you started
How you improved
What you explored

That trail tells a story.

And stories are powerful.

It Is Not About Going Viral

One of the biggest misconceptions is that writing is about reach.

Views

Likes

Followers

Those things are unpredictable.

And they are not the point.

The real value of writing is not in how many people read it.

It is in what it does to you.

How it sharpens your thinking

How it documents your growth

How it connects you with the right people

Even if one person benefits from your article, it matters.

The First Step Is Smaller Than You Think

You do not need a perfect idea.

You do not need a big audience.

You do not need confidence.

You just need to start.

Write about something simple.

Something you learned today

Something that confused you yesterday

Something you finally understand

That is enough.

Final Thoughts

Writing will not make you an expert overnight.

It will not guarantee success.

But it will change how you learn, how you think, and how you grow.

Quietly.

Gradually.

Consistently.

And one day, you will look back and realize that writing was not just something you did alongside coding.

It was one of the reasons you became better at it.

🎙️ Listen to the Podcast Version

HackerNoon turned this article into a podcast episode.

If you prefer listening instead of reading, you can listen here:

Podcast Link

And if you feel that quiet itch to start but the first step still looks blurry, I put together a companion guide that might help. It is called…

How to Start Technical Writing as a Developer: A Practical Guide to Sharing What You Know.

In it, I walk through the whole process in plain steps like picking a topic, structuring an article, hitting publish, and building a rhythm that actually sticks.

This piece was the why. That guide is the how.

Thanks for reading! I write about Flutter, AI in dev, and learning smarter as a developer. Follow for more!

✍️ Written by Safiullah Korai — Flutter Developer, Tech Writer & Lifelong Learner.

How to Start Technical Writing as a Developer: A Practical Guide to Sharing What You Know

Safiullah Korai — Sat, 09 May 2026 18:04:29 +0000

I did not start writing because I loved writing.

I started because I was stuck.

There was a bug I could not solve. I spent hours searching, reading half-written blog posts, digging through outdated documentation, and scrolling endless forum threads. Eventually, I figured it out. But something stayed with me. The next developer should not have to struggle like this.

So I wrote my first article.

It was not perfect. It was not polished. But it helped someone. That one response changed everything.

I’m Safiullah Korai, some of you might know me as Shahzaib.

I am a Software Engineer and full-stack Flutter developer.

Technical writing is not about being a writer first. It is about being a problem solver who documents the journey.

If you are a developer wondering how to start technical writing, this guide will walk you through it in a practical, honest way.

Why Developers Should Write

Before we talk about how, we need to talk about why.

I have explored this in more depth somewhere else. I wrote an entire article on the quiet, lasting reasons writing matters for a developer. Not fame or followers, but clarity, growth, and a career that compounds over time.

Technical writing is one of the highest leverage skills a developer can build.

If you want to sit with the why before jumping into the steps, you can read it here:

Why Every Developer Should Write

But for now, here is the short of it.

It forces you to think clearly. It exposes gaps in your understanding. It helps you build a public presence without chasing trends.

More importantly, it compounds.

One article can bring opportunities months later. A series of articles can define your expertise.

You are not just writing for others. You are building a long-term asset for yourself.

Step 1: Start With Problems You Have Already Solved

The biggest mistake beginners make is trying to write about advanced topics too early.

You do not need to write about complex system design or distributed architecture. You just need to write about something you recently learned.

Think about:

A bug you fixed A concept you finally understood A tool you recently explored A mistake that taught you something

Your first audience is your past self.

If your past self would have found your article useful, you are on the right track.

Image Idea Prompt

A developer sitting at a desk with multiple tabs open, looking confused, then a second frame showing clarity with a single clean document.

Step 2: Focus on Clarity Over Complexity

Many developers think writing needs to sound technical to be valuable.

That is not true.

The best technical writing is simple, clear, and direct.

Avoid unnecessary jargon. Break ideas into smaller pieces. Use examples wherever possible.

Instead of saying:

“State management is essential for scalable applications.”

Say:

“When your app grows, managing data becomes messy. State management helps you organize and control that data.”

Clarity builds trust.

Step 3: Use a Simple Structure

A good article is not random thoughts. It has a clear flow.

Here is a simple structure you can follow:

Introduction: Explain the problem and why it matters.
The Challenge: Describe what made this problem difficult.
The Solution: Walk through how you solved it step by step.
Key Learnings: Highlight what readers should take away.
Conclusion: Wrap up with a final thought or encouragement.

This structure works because it mirrors how developers think.

Step 4: Write Like You Speak

One of the biggest shifts you need to make is this:

Stop trying to sound like a textbook.

Write like you are explaining something to a friend.

Use natural sentences. Keep paragraphs short. Avoid overly formal language.

Instead of:

"This article aims to elucidate the implementation process..."

Say:

"In this article, I will show you how I implemented this."

Your writing should feel human, not robotic.

Step 5: Show, Do Not Just Tell

Technical writing is not about explaining concepts only. It is about demonstrating them.

Whenever possible, include:

Code snippets
Step-by-step instructions
Real examples
Screenshots or diagrams

This turns your article from theory into practice.

Step 6: Build a Writing Habit

Writing once is easy. Writing consistently is what creates impact.

You do not need to publish daily. Even one article per week is enough if you stay consistent.

Start small:

Set a weekly goal
Maintain a list of ideas
Write even when it feels imperfect

Consistency beats perfection every time.

Step 7: Choose the Right Platforms

Where you publish matters, especially in the beginning.

Here are some strong platforms for developers:

Medium
Hashnode
Dev.to
HackerNoon
Substack

Each platform has its own audience. You can start with one and expand later.

Publishing across multiple platforms can increase reach, but focus on quality first.

If you want to understand the differences more clearly, like what type of content fits where and how to pick your first home without overthinking it, I wrote a separate guide on exactly that. It is called...

Where to Write as a Developer

Feel free to read it now, or come back to it later.

Step 8: Learn Basic SEO

If you want people to find your articles, you need to understand basic SEO.

Focus on:

Clear, searchable titles
Relevant keywords
Structured headings
Descriptive introductions

For example:

Bad title:

“My Experience with Flutter”

Better title:

“How I Built My First Flutter App: A Beginner’s Guide”

Think about what someone would search on Google.

Step 9: Edit Ruthlessly

Your first draft is not your final draft.

Good writing is rewriting.

After finishing your article:

Remove unnecessary words
Simplify long sentences
Fix grammar issues
Improve flow

Read your article out loud. If something sounds awkward, it probably is.

Step 10: Accept Imperfection

Your first few articles will not be perfect.

That is expected.

You might feel:

Your writing is not good enough
Your ideas are too simple
Nobody will read it

Ignore that.

Every experienced writer started the same way.

The goal is not perfection. The goal is progress.

Step 11: Build Your Personal Brand

Technical writing is more than just sharing knowledge. It is also about building your identity.

Over time, your articles will reflect:

What you are learning
What you care about
What you specialize in

This becomes your personal brand.

When someone searches your name, your work speaks for you.

Step 12: Engage With Your Audience

Publishing is only half the process.

Engagement matters.

Respond to comments
Answer questions
Connect with other writers
Share your articles on social platforms

This builds a community around your work.

And community creates opportunities.

Step 13: Turn Writing Into Opportunities

Technical writing can open doors you did not expect.

It can lead to:

Freelance writing gigs
Speaking opportunities
Open source contributions
Job offers

Companies value developers who can communicate clearly.

Writing proves that skill.

Common Mistakes to Avoid

Let’s be honest about a few traps:

Trying to Be Too Advanced

You do not need to impress. You need to help.

Writing Without Structure

Unstructured content confuses readers.

Ignoring the Reader

Always ask: who is this for?

Overcomplicating Language

Simple writing is powerful writing.

A Simple Starting Plan

If you are still unsure where to begin, follow this:

Day 1: Pick a topic you recently learned

Day 2: Outline your article

Day 3: Write the first draft

Day 4: Edit and improve

Day 5: Publish

That is it.

Do not overthink it.

Final Thoughts

Technical writing is not reserved for experts.

It is built by learners.

Every time you solve a problem, you have something worth sharing.

The real difference between developers who write and those who do not is simple.

One group documents their journey.

The other forgets it.

If you start today, a year from now you will not just be a developer.

You will be a developer with a voice.

And in today’s world, that makes all the difference.

Thanks for reading! I write about Flutter, AI in dev, and learning smarter as a developer. Follow for more!

✍️ Written by Safiullah Korai — Flutter Developer, Tech Writer & Lifelong Learner.

Where to Write as a Developer: A Calm Guide to Choosing Your First Platform

Safiullah Korai — Sun, 03 May 2026 19:15:53 +0000

When developers decide to start writing, the first confusion is not what to write.

It is where to write.

There are too many platforms. Everyone recommends something different.

Some say start on Medium. Others prefer Dev.to. Some suggest owning your audience through Substack.

The truth is simpler than it looks.

You do not need the perfect platform.

You need a starting point.

I’m Safiullah Korai, though many know me as Shahzaib. I’m a Software Engineer and full‑stack Flutter developer, building real production apps, experimenting with architecture, and focusing on modern, scalable mobile solutions. Along the way, writing became a quiet part of my growth, and figuring out where to publish was one of my earliest stumbling blocks.

Each platform has its own audience, its own culture, and its own advantages. If you understand how they work, you can use them intentionally instead of randomly posting everywhere.

This article will help you do exactly that.

The Reality: Platforms Matter, But Not as Much as You Think

Before we go into each platform, there is one mindset shift you need.

Your growth will not come from the platform alone.

It will come from:

Consistency
Clarity
Relevance

A good platform amplifies your work.

It does not replace it.

So instead of chasing reach, focus on writing something useful. Then use platforms to distribute it.

Start With One Platform, Not Five

Many developers make this mistake.

They write one article and try to publish it everywhere at once.

Medium, Dev.to, Hashnode, LinkedIn, Substack.

The result is predictable.

No traction anywhere.

Instead:

Pick one platform
Learn how it works
Build momentum

Then expand.

Focus first. Scale later.

Medium: The Best Place to Start Writing

If you are starting from zero, Medium is one of the easiest platforms to begin with.

Why Medium Works

Medium already has an audience.

People come there to read.

This means you do not need to bring your own traffic in the beginning.

It also has strong distribution. If your article performs well, it can reach beyond your followers.

What Kind of Content Works

Beginner-friendly guides
Personal experiences
Clear, structured tutorials
Thoughtful reflections on learning

Medium readers value clarity and storytelling.

How to Leverage It

Write strong titles that match search intent
Focus on readability and structure
Use proper headings and spacing
Publish consistently

Do not try to game the algorithm.

Write something genuinely useful.

Dev.to: The Developer Community Hub

Dev.to feels different from Medium.

It is more community-driven.

More raw. More direct.

Why Dev.to Works

Developers are not just readers here.

They are participants.

They comment, share, and engage actively.

If your article resonates, you will get feedback quickly.

What Kind of Content Works

Practical tutorials
Code-heavy explanations
Real-world problem solving
Honest experiences

This is not the place for overly polished writing.

Authenticity performs better.

How to Leverage It

Use relevant tags (very important)
Engage with comments
Share your learning journey
Be consistent with topics

Dev.to rewards developers who show up regularly.

Hashnode: Build Your Own Developer Identity

Hashnode is where writing meets ownership.

It gives you a personal blog with your own domain if you want.

Why Hashnode Works

You are not just writing on a platform.

You are building your own space.

This matters long term.

Because you control your content and your brand.

What Kind of Content Works

Technical deep dives
Series-based content
Long-form tutorials
Personal learning journeys

Hashnode readers are more focused and technical.

How to Leverage It

Set up your custom domain early
Create content series
Build a niche (Flutter, backend, AI, etc.)
Treat it like your personal blog

Think long term here.

HackerNoon: High-Quality, Editorial-Driven Writing

HackerNoon is not like other platforms.

It has an editorial process.

Your article is reviewed before publication.

Why HackerNoon Works

It builds credibility.

Being published here signals quality.

It also reaches a professional, tech-focused audience.

What Kind of Content Works

Well-structured technical articles
Insightful industry perspectives
Case studies
In-depth guides

This is not the place for rushed content.

How to Leverage It

Follow their submission guidelines carefully
Focus on clarity and originality
Write complete, polished articles
Choose strong, relevant topics

Think quality over quantity.

Substack: Own Your Audience

Substack is different from all the others.

It is not just a publishing platform.

It is a relationship platform.

Why Substack Works

You build an email list.

That means you own your audience.

No algorithm decides whether people see your content.

What Kind of Content Works

Personal insights
Learning reflections
Weekly updates
Deep thinking pieces

Substack is more personal than technical.

How to Leverage It

Write consistently (weekly works well)
Focus on connection, not perfection
Share your journey honestly
Build trust over time

Growth is slower, but stronger.

Publishing Across Platforms: When and How

Once you are comfortable with one platform, you can expand.

But do it strategically.

Step 1: Choose a Primary Platform

This is where you publish first.

Step 2: Repurpose, Do Not Copy Blindly

Adapt your content slightly for each platform.

Step 3: Maintain Consistency

Do not abandon your main platform while expanding.

Step 4: Focus on Quality First

More platforms do not mean more impact if the content is weak.

A Practical Strategy You Can Follow

If you are starting today, this works well:

Week 1-4:

Write only on Medium or Dev.to

Week 5-8:

Start publishing the same content on Hashnode

Month 3:

Submit your best article to HackerNoon

Month 4+:

Start a Substack newsletter

This approach builds both reach and ownership.

Common Mistakes to Avoid

Publishing Everywhere Too Early

You lose focus and consistency.

Ignoring Platform Culture

Each platform has its own expectations.

Writing Only for Algorithms

Readers can feel it.

Not Engaging With Audience

Writing is not one-way communication.

Final Thoughts

Platforms are tools.

Not shortcuts.

They can amplify your work, but they cannot replace it.

Start small.

Pick one platform.

Write something useful.

Then keep going.

Over time, you will not just grow on a platform.

You will grow beyond it.

If you are still exploring why writing matters in the first place, I wrote a piece on that too: Why Every Developer Should Write.

And if you want a hands‑on guide that walks you through picking a topic, structuring an article, and hitting publish, How to Start Technical Writing as a Developer covers all the practical steps.

This article gave you the where to write. Those two give you the why and the how to write.

Thanks for reading! I write about Flutter, AI in dev, and learning smarter as a developer. Follow for more!

✍️ Written by Safiullah Korai — Flutter Developer, Tech Writer & Lifelong Learner.

The Gap Between Design and Development Is Finally Closing

Safiullah Korai — Mon, 13 Apr 2026 18:38:57 +0000

There has always been a quiet gap in software development.

Designers create beautiful interfaces in Figma.

Developers then try to recreate those designs inside Visual Studio Code.

And somewhere in between, things break.

Spacing becomes slightly different.

Components get renamed.

Colors change a little.

Buttons look right but behave wrong.

I’m Safiullah Korai (also known as Shahzaib), a Software Engineer and full-stack Flutter developer.. I work on real production apps, experiment with app architecture, and focus on building modern, scalable, and maintainable mobile solutions.

This problem has existed for years.

But something interesting just happened.

A New Loop Between Design and Code

Recently, GitHub introduced a new integration that connects:

GitHub Copilot
Visual Studio Code
Figma

Together.

Not as separate tools.

But as a continuous loop between design and development.

The key piece behind this integration is something called the Figma MCP Server.

With it, developers can now do something that previously felt impossible.

Code and design can now move both directions.

What This Actually Means for Developers

Imagine this workflow.

A designer creates a UI in Figma.

Instead of manually studying the design and rebuilding it from scratch, a developer can now:

✅ Pull the design context directly into their code using GitHub Copilot.

✅ Generate UI based on that design.

✅ Send the working UI back to Figma as editable frames.

✅ Let designers adjust the layout again.

✅ Pull those updates back into the code.

And the cycle continues.

Design → Code → Design → Code.

A real loop.

No More “UI Drift”

If you have ever worked with designers, you probably know this situation.

The design file says one thing.

The production app shows something slightly different.

That difference is often called UI drift.

It happens because design tools and development tools live in separate worlds.

Now those worlds are starting to connect.

Developers can work inside VS Code, while designers continue working inside Figma, but both are now connected through Copilot and the MCP server.

How the Figma MCP Server Works

The setup is surprisingly simple.

Install the Figma MCP Server
Connect your Figma account
Use GitHub Copilot inside VS Code

After that, Copilot can:

Pull design context from Figma
Generate UI code based on that design
Send rendered UI back to Figma as editable frames

Designers can then tweak the layout, spacing, or components.

Developers pull those updates again.

And the loop continues.

Why This Matters in the AI Era

We are entering a time where design tools and coding tools are slowly merging.

AI is no longer just helping developers write code.

It is helping connect the entire product workflow.

From design to development.

From idea to interface.

Tools like GitHub Copilot are no longer just autocomplete for code.

They are becoming bridges between creative work and engineering work.

And that changes how teams build products.

What This Means for Future Developers

If you are learning development today, something important is happening.

The role of developers is shifting.

You are no longer just writing code line by line.

You are working with:

AI assistants
design systems
automated UI generation
connected workflows

Understanding how tools connect together will become just as important as knowing a programming language.

A Small Thought Before You Go

I still remember when building UI meant staring at a design file and translating pixels into code manually.

That was the normal workflow.

But now things are changing.

Design talks to code.

Code talks back to design.

And the gap between the two is finally closing.

The real question now is simple.

What will developers build when this friction disappears? 👀

Inspired by the GitHub announcement about the Figma MCP Server.

Thanks for reading! I write about Flutter, AI in dev, and learning smarter as a developer. Follow for more!

✍️ Written by Safiullah Korai — Flutter Developer, Tech Writer & Lifelong Learner.

In the AI Era, The Real Skill Is Not Overthinking

Safiullah Korai — Tue, 10 Mar 2026 15:00:00 +0000

This article is 1st part of the Thinking in the AI Era series, where we explore clarity, focus, and building in a world full of digital noise.

A few years ago, choosing a skill felt simple.

You picked something.

You learned it.

You improved with time.

But today things feel different.

The moment someone opens YouTube, Twitter, or any tech blog, they see hundreds of opinions.

Learn AI.

No, build SaaS.

No, become a creator.

No, learn prompt engineering.

No, build startups.

No, learn Web3.

Within ten minutes, a beginner already feels confused.

Suddenly the problem is not lack of opportunity.

The problem is too many opportunities.

And somewhere in this noise, people begin to do something dangerous.

They start overthinking everything they think.

Hey, I’m Safiullah Korai (also known as Shahzaib), a Software Engineer and full-stack Flutter developer. I work on real production apps, experiment with app architecture, and focus on building modern, scalable, and maintainable mobile solutions.

This idea reminded me of a powerful concept from the book Don’t Believe Everything You Think by Joseph Nguyen.

The book explains something simple but life-changing.

Not every thought in your mind deserves to be believed.

And in the AI era, this lesson matters more than ever.

The Problem Is Not AI. It Is Our Thinking.

People often say the tech world is changing too fast.

New tools appear every month.

AI models improve.

Frameworks evolve.

Careers shift.

But the real challenge is not technology.

The real challenge is what happens inside our minds.

A developer today might think:

Should I continue learning Flutter?

Should I switch to AI engineering?

What if this skill becomes useless?

What if someone else is already ahead?

These thoughts keep appearing again and again.

Soon the person stops building anything.

They are not stuck because of lack of skill.

They are stuck because of too much thinking.

Overthinking Creates Problems That Do Not Exist

Our mind is very good at imagining problems.

It creates future scenarios that may never happen.

What if I choose the wrong path?

What if AI replaces this skill?

What if I fail?

But most of these are not real problems.

They are stories created by the mind.

The truth is simple.

Nobody knows the future.

Not developers.

Not experts.

Not influencers.

The only thing anyone can do is choose something and move forward.

The Internet Made Thinking Infinite

Before the internet became so powerful, information was limited.

You had fewer opinions.

Fewer tutorials.

Fewer career choices.

Now everything is available.

Thousands of videos.

Thousands of blog posts.

Thousands of opinions.

Tools like ChatGPT can answer almost any question instantly.

While this is amazing, it also creates a new problem.

Too much advice.

When you keep consuming advice all day, your mind keeps comparing every possible path.

And when every path seems important, none of them gets started.

Builders Think Less. They Build More.

If you observe people who actually succeed in tech, you will notice something interesting.

They do not spend months deciding the perfect path.

They start.

They build small things.

They experiment.

They fail and learn quickly.

Instead of thinking for weeks, they write code.

Instead of worrying about the future, they build the present.

Action gives them something thinking never can.

Experience.

Clarity Does Not Come From Thinking

This is one of the biggest misunderstandings people have.

They believe clarity comes from thinking harder.

But that rarely works.

Clarity comes from doing something.

If you are unsure about Flutter, build five small apps.

If you are curious about AI, experiment with a simple project.

If you want to start writing, publish a few articles.

After action, the mind becomes clear.

Without action, confusion grows.

The Simple Rule for the AI Era

The internet will keep giving you new trends.

Every day there will be something new to learn.

A new framework.

A new tool.

A new opportunity.

If you try to analyze every option, you will never move forward.

So here is a simple rule that might help.

Think less.

Build more.

Consume less.

Create more.

The people who will thrive in the AI era are not the ones who think the most.

They are the ones who start before they feel ready.

A Small Personal Reflection

When I started learning Flutter, I had similar thoughts.

Should I learn something else instead?

Should I move to another technology?

Is this the right path?

These questions kept appearing.

But eventually I realized something simple.

Thinking about different paths never helped me.

Building things did.

Every small project removed a little confusion.

Every experiment created a little clarity.

The Quiet Truth

Your mind will always generate thoughts.

Some useful.

Some unnecessary.

But you do not have to believe every thought you think.

Sometimes the best decision is not the perfect decision.

Sometimes the best decision is simply this.

Choose something.

Start building.

And let the noise of the internet stay where it belongs.

Outside your mind.

Thanks for reading! I write about Flutter, AI in dev, and learning smarter as a developer. Follow for more!

✍️ Written by Safiullah Korai — Flutter Developer, Tech Writer & Lifelong Learner.

How Flutter Developers Can Use Stitch to Build Client Apps Faster in 2026

Safiullah Korai — Mon, 09 Mar 2026 15:00:00 +0000

AI-driven app design process

A client once told me:

“I don’t care how it looks. I just want an app like Uber, but for groceries.”

No wireframes.

No design system.

No brand guide.

Just an idea.

I’m Safiullah Korai (also known as Shahzaib), a Software Engineer and full-stack Flutter developer. I work on real production apps, experiment with app architecture, and focus on building modern, scalable, and maintainable mobile solutions.

If you are a Flutter developer, you’ve probably been there.

You know how to build logic.

You know how to manage state.

You know how to connect APIs.

But when it comes to design, clients often expect you to magically “make it look good.”

That is where AI tools like Stitch are quietly changing the game.

The New Reality for Flutter Developers

In 2026, being “just a developer” is not enough.

Clients expect:

• Clean UI

• Modern design

• Fast turnaround

• App Store ready polish

But many clients do not hire a UI/UX designer. They come with only a product idea.

Instead of struggling inside design tools for hours, you can now use Stitch to generate professional UI drafts in minutes, then refine them inside Figma before building them in Flutter.

This is not about replacing designers.

It is about empowering developers when designers are not available.

(Client Idea to Flutter App Workflow)

What Is Stitch in Simple Terms?

Stitch is an AI-powered design tool that creates user interfaces from text prompts or sketches.

You can type:

“Create a food delivery app home screen with categories, search bar, and featured restaurants.”

Within seconds, it generates UI screens.

Not rough sketches.

Actual structured layouts.

You can export them to Figma or even generate frontend code.

For a Flutter developer, this means you no longer start from a blank screen.

(Stitch Prompt Interface to Generate Mobile App UI)

(UI Screens Design generated by Stitch)

Scenario 1: Client Has an Idea but No Design

Let’s say your client says:

“I want a fitness app where users can track workouts.”

That is it.

Instead of guessing layout structures, you can:

Step 1 :

Prompt Stitch with a detailed description.

Step 2 :

Generate 3 to 5 UI variations.

Step 3 :

Show those options to the client.

Suddenly, the conversation becomes visual.

Instead of abstract discussion, the client reacts to real screens.

This reduces confusion and saves revision cycles.

Multiple UI Variations from One Prompt (The Previous Design)

Scenario 2: You Are Building Your Own Product

If you are building your own SaaS or mobile app, design often becomes the bottleneck.

You delay launching because “UI is not ready.”

With Stitch:

• Generate MVP screens quickly

• Validate idea with users

• Improve design later

Speed matters in early-stage products.

Stitch helps you move from idea to prototype faster.

How to Integrate Stitch into a Flutter Workflow

Here is a practical workflow you can follow:

Step 1: Define the Core Features

List main screens:

• Home

• Login

• Profile

• Dashboard

Step 2: Prompt Stitch Clearly

Be specific about:

• Theme

• Layout type

• Target audience

• Platform type (mobile or web)

Example prompt:

“Design a clean mobile banking app home screen with balance card, recent transactions, and bottom navigation.”

Step 3: Export to Figma

Import the design into Figma for:

• Adjusting spacing

• Fixing typography

• Aligning brand colors

• Creating reusable components

Step 4: Translate to Flutter Widgets

Now you rebuild the design using:

• Scaffold

• Column

• Row

• ListView

• Custom widgets

Instead of designing from imagination, you replicate from a visual reference.

This improves visual consistency.

(Stitch Design Export to Figma)

Why This Is Powerful for Freelancers

If you are a freelance Flutter developer, this approach gives you an edge.

You can:

• Deliver design mockups faster

• Impress clients with visual proposals

• Reduce back-and-forth revisions

• Increase perceived professionalism

Many freelancers lose projects because their UI mockups look weak.

Stitch helps you present polished drafts early.

How This Can Increase Your Freelance Income

Using AI-assisted UI tools like Stitch is not just about speed.

It is about positioning yourself as a more complete solution for clients.

Here’s how it directly impacts your freelance income:

1. Faster Proposals

Instead of sending text-only proposals, you can attach quick visual mockups generated with Stitch.

Clients understand visuals better than descriptions.

This increases your chances of closing deals.

2. Faster Mockups

What used to take 1–2 days of rough layout experimentation can now take 30 minutes.

Less design struggle means more billable development time.

3. More Clients Impressed

When a client sees multiple UI variations early, you look organized and professional.

Perception matters in freelancing.

Higher perceived expertise = higher rates.

4. Shorter Revision Cycles

Visual alignment happens earlier in the project.

Fewer misunderstandings.

Fewer redesign requests mid-development.

That means:

• Less unpaid rework

• Faster project completion

• More projects per month

And more projects per month means higher overall income.

But Be Careful

AI generates layouts.

It does not understand:

• Real user psychology

• Accessibility deeply

• Long-term product strategy

• Complex UX flows

You still need judgment.

Do not blindly implement everything AI generates.

Use it as a starting point.

You are still the decision maker.

“AI Suggests. Developer Decides.”

Does This Replace Learning UI/UX?

No.

If anything, it makes learning UI/UX more important.

When you understand:

• Spacing

• Hierarchy

• Color balance

• Typography

You can guide AI better.

A developer who understands design fundamentals will use Stitch far more effectively than someone who only types random prompts.

Final Thoughts

Flutter makes building cross-platform apps easier.

Stitch makes designing those apps faster.

Together, they reduce friction between idea and execution.

If your client brings only a concept, you no longer need to panic about design.

You can:

Generate

Refine

Build

Deliver

The future of development is not developer versus designer.

It is human plus AI.

And if you learn how to combine tools like Stitch with your Flutter skills, you will not just build apps.

You will build them smarter.

Thanks for reading! I write about Flutter, AI in dev, and learning smarter as a developer. Follow for more!

✍️ Written by Safiullah Korai — Flutter Developer, Tech Writer & Lifelong Learner.

Stitch vs Figma: Is AI Replacing UI/UX Designers in 2026?

Safiullah Korai — Sun, 08 Mar 2026 15:00:00 +0000

I still remember the first time I opened Figma.

A blank canvas.

A few frames.

Some rectangles pretending to be buttons.

That was design.

You dragged. You aligned. You adjusted spacing. You changed fonts. You argued with padding. Slowly, a screen was born.

Now imagine typing one sentence:

“Create a modern fintech dashboard with a dark theme and analytics cards.”

And within seconds, full screens appear. Clean layout. Color palette ready. Buttons styled. Even code generated.

That is what Google Stitch is doing.

And if you are into UI/UX, product design, or frontend development, this moment matters.

During this journey, I have worked closely with designers, design systems, and handoff workflows.

I have seen how much time goes into turning ideas into real interfaces.

And I have also seen how small design decisions can completely change the quality of a product.

So when I saw Google introduce Stitch, an AI-powered design tool that generates complete UI screens from text prompts and images, I immediately realized something important.

This is not just another design tool.

The Shift No One Saw Coming

For years, tools like Figma have been the home of designers. From wireframes to polished UI, everything lived there. Teams collaborated. Developers inspected designs. Startups launched products.

Then AI entered the room.

Google introduced Stitch, an AI-powered design tool that generates user interfaces from text prompts and images.

Not templates.

Not partial layouts.

Complete screens.

And suddenly, the design process feels different.

Design process with AI and UI tools

What Exactly Is Stitch?

Stitch is an AI design tool that lets you describe an interface in plain language. It then generates UI screens based on your description.

You can:

• Type a prompt

• Upload a sketch

• Upload a screenshot

• Ask for multiple variations

• Export to Figma

• Export frontend code

Instead of manually building every card, button, and section, Stitch handles the first draft.

It feels like brainstorming with a machine.

(SCREENSHOT 1: Stitch Prompt Input Interface)

(SCREENSHOT 2: Generated UI Variations from Same Prompt)

Why This Feels Different From Other AI Tools

We have seen AI image generators. We have seen AI code assistants.

But Stitch sits in a powerful position.

It connects design and development.

It does not just generate a picture. It creates structured UI layouts that can move into Figma or directly into code.

That reduces the gap between idea and execution.

For startup founders, solo developers, and product teams, that speed matters.

But Where Does Figma Stand Now?

Here is the important part.

Figma is not disappearing.

Figma is still where serious design work happens.

Collaboration

Design systems

Component libraries

Prototyping

Team feedback

Developer handoff

Even if Stitch generates the first version, designers still refine inside Figma.

Think of it like this.

Stitch gives you a strong first draft.

Figma helps you perfect it.

(SCREENSHOT 3: Stitch Design Import into Figma)

A Realistic Workflow in 2026

Let’s imagine you are building a fitness app.

Step 1 :

You prompt Stitch:

“Create a mobile fitness app home screen with workout stats and a progress chart.”

Step 2 :

Stitch generates 3 design variations.

Step 3 :

You export the best version to Figma.

Step 4 :

Inside Figma, you adjust spacing, improve typography, fix accessibility, align with brand colors.

Step 5 :

You export assets or code.

This workflow can save days in early design stages.

But it does not remove the need for design thinking.

Is AI Replacing UI/UX Designers?

This is the question everyone is asking.

The short answer is no.

AI can generate layouts.

It can suggest colors.

It can create structured components.

But it does not understand:

• Real user pain

• Accessibility depth

• Cultural context

• Business goals

• Long term product strategy

Design is not just pixels. It is problem solving.

Stitch accelerates the process. It does not replace the human behind it.

Why Developers Should Care

If you are a Flutter developer, React developer, or frontend engineer, this shift is important.

Instead of waiting days for UI drafts, you can prototype faster.

You can validate ideas earlier.

You can even generate quick UI concepts for client pitches.

Stitch lowers the entry barrier for clean interface design.

But you still need design sense to choose what actually works.

The Bigger Picture: AI + Design Is Just Beginning

We are moving into a phase where:

• AI generates first drafts

• Designers refine

• Developers implement faster

• Iterations happen quicker

The distance between idea and product is shrinking.

And that is exciting.

Because the faster you test ideas, the faster you learn.

Should You Learn Figma in 2026?

Yes.

More than ever.

AI tools will come and go.

But understanding layout, hierarchy, spacing, typography, and user behavior will always matter.

Tools change.

Principles stay.

If you know design fundamentals, you can use Stitch better than someone who only knows prompting.

“Tools Change. Principles Stay.”

Final Thoughts

When I first opened Figma, design felt manual and slow.

Today, with Stitch, design feels instant.

But here is the truth.

Speed is powerful.

Understanding is powerful.

Together, they are unstoppable.

Stitch is not the end of UI/UX design.

It is the beginning of a new design workflow.

And if you learn how to combine AI with real design thinking, you will not just survive this shift.

You will lead it.

Thanks for reading! I write about Flutter, AI in dev, and learning smarter as a developer. Follow for more!

✍️ Written by Safiullah Korai — Flutter Developer, Tech Writer & Lifelong Learner.

In the Era of AI, Why Do I Still Choose Flutter?

Safiullah Korai — Wed, 04 Mar 2026 15:20:00 +0000

Everywhere I look in 2026, the conversation is the same.

AI is writing code.

AI is designing UI.

AI is debugging errors.

AI is generating entire applications in minutes.

Sometimes I open my laptop, scroll through tech news, and wonder the same thing many developers are quietly thinking.

If AI can build apps, why should anyone still learn Flutter?

Why invest time in mastering app development at all?

It is not a silly question.

It is a serious one.

And as someone who builds products for a living, I had to answer it for myself first.

A Small Flashback

There was a time when building an app meant choosing sides.

If you wanted an iPhone app, you learned one language.

If you wanted an Android app, you learned another.

If you wanted a web app, that was a different world entirely.

Development was divided. Time was divided. Teams were divided.

Then tools started changing.

And one of the tools that changed everything for me was Flutter.

Hello, I am Safiullah Korai. I am a Software Engineer and a full stack Flutter developer. Over the past few years, I have spent countless hours building mobile applications, experimenting with architecture, fixing real production bugs, and understanding what makes modern app development efficient and scalable.

I have seen trends come and go.

But AI feels different.

It feels bigger.

So the real question is not whether AI is powerful.

The real question is this:

Where do developers stand in this new era?

AI Is Powerful. But It Is Still a Tool.

I use AI almost every day.

I use it to brainstorm ideas.

I use it to speed up repetitive code.

I use it to review logic.

It saves time.

But I have noticed something important.

AI can generate.

It cannot take responsibility.

When an app crashes in production, AI does not answer to users.

When architecture decisions fail at scale, AI does not sit in meetings explaining tradeoffs.

Developers do.

AI can give you a starting point.

It cannot give you ownership.

And that difference matters.

Apps Need Structure, Not Just Screens

Yes, AI can generate UI screens.

But can it:

Design scalable architecture for a startup expecting growth?
Decide performance tradeoffs for low-end devices?
Plan state management for complex flows?
Think long-term about maintainability?

Not independently.

That responsibility still belongs to someone who understands systems.

And this is where Flutter still matters.

Flutter gives you control over structure. Over layout behavior. Over state flow. Over platform integration.

It is not just about writing widgets.

It is about understanding how everything connects.

In the AI era, speed is increasing.

But deep understanding is still rare.

And rare skills always carry value.

Why I Still Choose Flutter Specifically

There are many frameworks available.

So why Flutter?

Because Flutter represents efficiency without sacrificing control.

I can build for Android, iOS, Web, and Desktop using one codebase.

I can prototype quickly.

I can iterate fast.

When AI reduces thinking time, Flutter reduces production time.

Together, they create leverage.

And leverage is what modern developers need.

The Difference Between Code and Product Thinking

Building an app is not just writing functions.

It involves:

Understanding user behavior
Designing intuitive navigation
Handling edge cases
Planning for scale
Shipping updates safely

AI can assist with fragments of this.

But someone still needs to see the full picture.

When I build an app, I am not just writing code. I am solving a real problem for real users.

Flutter is the toolkit.

AI is the assistant.

I remain the architect.

And that mindset changes everything.

The Human Edge in 2026

In 2026, the competitive advantage is no longer typing speed.

It is judgment.

Knowing:

When to optimize
When to simplify
When to ship
When to refactor

AI does not carry responsibility.

Developers do.

And the deeper your fundamentals, the more powerful AI becomes in your hands.

Without fundamentals, AI suggestions feel confusing.

With strong Flutter fundamentals, AI becomes a multiplier.

Why App Development Still Matters

Some people believe AI will eliminate developers.

What I see instead is a shift.

Repetitive low-skill work is shrinking.

High-understanding product-focused work is growing.

Businesses still need:

Mobile apps
SaaS dashboards
Customer platforms
Internal systems

Those problems did not disappear.

AI accelerates building.

It does not replace ownership.

If you deeply understand Flutter, you are not just someone who copies code.

You are someone who can turn ideas into usable digital products.

That skill remains relevant.

Choosing Flutter in the AI Era Is Not Fear. It Is Strategy.

For me, choosing Flutter today is not about ignoring AI.

It is about combining forces.

Flutter gives me structure.

AI gives me acceleration.

I do not fight AI.

I build with it.

The developers who will win in this era are not the ones afraid of automation.

They are the ones who understand systems deeply enough to guide automation.

Final Thoughts

AI is changing how we write code.

It is not changing why we build software.

People still need solutions.

Businesses still need products.

Users still need smooth experiences.

Flutter remains a practical and efficient way to build those experiences across platforms.

And if you truly understand it, AI becomes your assistant, not your replacement.

If you want to build with clarity instead of confusion, I am currently covering 100 Flutter widgets in my series, Flutter Code & Concepts. The goal is simple. Strong fundamentals. Clear understanding. Practical knowledge.

The tools are evolving.

The builders still matter.

And I choose to be one of them.

🧭 Want to Learn Smarter as a Developer?

I write about Flutter, developer mindset, and learning techniques. Follow me here on Medium for more practical tech learning insights.

✍️ Written by Safiullah Korai — Flutter Developer, Tech Writer & Lifelong Learner.