What if AI is not accelerating us but keeping us exactly where we are

Muhammad Niaz Ali — Thu, 23 Apr 2026 16:40:26 +0000

I have been thinking about this for three months now.

Not constantly but enough that it started affecting how I work. How I open my editor. How I reach for AI or decide not to.

The question is simple but the answer scares me.

Is artificial intelligence helping us build the future or is it just making us extremely efficient at staying in the present?

Let me explain with something that happened last week.

I needed to implement a file upload feature with drag and drop support. Nothing complicated. A few megabytes limit. Image preview. Progress indicator. Standard web stuff.

I opened Copilot and wrote a comment saying implement file upload with drag drop and preview.

Within seconds it gave me a complete component. React based. Using react-dropzone. Tailwind for styling. It worked on the first try.

I felt good. Productive. Fast.

Then I stopped and asked myself a question. Would I have written it the same way if AI did not exist?

The answer was no.

I would have thought about alternatives. Maybe vanilla JavaScript to keep dependencies low. Maybe a web component for reusability across projects. Maybe even a simple form with server side handling because the upload volume is low.

But AI did not show me any of those options. It showed me the most common solution from its training data. React. React-dropzone. Tailwind. The path of least resistance.

And I took it without questioning.

That is when the thought really settled in. AI is not just helping me write code faster. It is quietly narrowing the range of solutions I consider.

This matters more than we think because software development has always moved forward through friction.

Think about the early days of jQuery. It solved real problems. Cross browser inconsistencies were a nightmare. jQuery made them go away. But then people started using jQuery for everything even when the native DOM API was perfectly fine. The friction was gone so the exploration stopped.

The same thing happened with Bootstrap. Every site looked the same because it was easy. Not because it was the best choice for every project.

We eventually moved past both. But it took years of friction and frustration to push people toward better alternatives.

Now imagine that same dynamic but amplified by a thousand because AI can generate complete features in seconds. The cycle of comfort and stagnation could compress from years into months.

I am not saying AI is bad. I use it daily and I would not want to go back. But I am noticing patterns in my own behaviour that make me uncomfortable.

The first pattern is that I rarely search for documentation anymore. I just ask the AI. It gives me an answer and I move on. But here is the problem. When I read documentation I used to discover things I was not looking for. Alternative APIs. Deprecation warnings. Examples that sparked new ideas. That serendipity is completely gone.

The second pattern is that I stopped reading error messages carefully. Before AI I would see an error and spend time understanding the stack trace. The state of my application. The root cause. Now I just paste the error into the chat and apply the fix. It works but I learn almost nothing from the experience.

The third pattern is the most dangerous one. I noticed that my pull requests are becoming more similar to each other. Same patterns. Same abstractions. Same folder structures. The uniqueness is fading. My code is starting to look like everyone elses code.

Some people would say that is a good thing. Consistency across teams. Lower cognitive load. Easier onboarding for new developers.

But I wonder if we are losing something valuable. The weird solutions that turn out to be brilliant. The unconventional architecture that scales better than anyone expected. The mistakes that teach us more than the successes.

These things do not come from taking the first answer AI gives you. They come from exploration. From trying something that might fail. From spending time in the discomfort of not knowing.

The problem is that AI is so good at removing discomfort. And discomfort has always been the engine of progress.

Let me go back to the 2011 example that Sylwia mentioned in her recent post because it fits perfectly here.

Imagine you are a developer in 2011. You have access to an AI trained on all the web development knowledge that existed at that time. PHP templates. Server side rendering. Simple JavaScript. A bit of jQuery.

You need to build a web application with real time updates. The AI gives you a solution using long polling. It works. It is stable. It matches the patterns in its training data.

Would you ever push yourself toward WebSockets? Would you experiment with something that barely exists yet when the current approach already works?

Probably not. You would ship the long polling solution and move on to the next task.

And that is exactly the point. AI does not just give us answers. It gives us answers that are anchored in the past. It shows us what has worked not what could work.

This becomes even more visible when you work with newer technologies.

I recently tried to use AI for WebGPU development. The results were terrible. Wrong API names. Mixed up WGSL syntax. Complete confusion about memory management. I had to debug everything manually just like I did ten years ago.

But here is what is interesting. As more people use WebGPU and more code appears on GitHub the AI will get better at it. Within a year or two it will generate clean WebGPU code just like it generates React components today.

And when that happens developers will adopt WebGPU faster. Not because they explored it and found it superior but because the AI made it easy. The convenience came first. The adoption followed.

Is that a problem? I am not sure.

On one hand faster adoption of good technology is a win. On the other hand the reason for adoption becomes convenience rather than genuine need. We use things because they are easy not because they solve a real problem better than the alternatives.

This is how trends are born and how they die. The same mechanism that popularised React could also keep it alive far longer than it should be. Not because React is still the best choice for every project but because AI keeps recommending it and developers keep accepting the recommendation.

The feedback loop is powerful but subtle.

AI learns from existing code. It recommends patterns from that code. Developers implement those patterns. Those implementations become new training data. The patterns get reinforced. Breaking out of the loop becomes harder over time.

This is not a conspiracy. It is just statistics. The most common solution gets more common. The less common solution gets forgotten.

Experienced developers might resist this pull. They have the context to know when AI is suggesting something suboptimal. They can push back and ask for alternatives.

But junior developers do not have that context. They trust the AI because it has been right so many times before. They do not know when it is leading them toward a mediocre solution because the mediocre solution works well enough.

This creates a generation of developers who are extremely productive at building standard things and completely lost when faced with novel problems.

I have seen this happen with developers who started their careers after ChatGPT became mainstream. They are fast. Incredibly fast. But when something breaks in a non standard way they freeze. The AI cannot help because the pattern does not exist in its training data. And they never learned how to debug without AI because they never had to.

This is the real risk in my opinion. Not that AI will replace us. But that it will change what competence looks like. The skills that made a great developer ten years ago are not the same skills that make a great developer today. And we have not yet figured out what the new skills should be.

Is it prompting? Is it code review? Is it knowing when to ignore the AI? I do not have a clear answer.

But I know that the developers who will thrive in the next five years are not the ones who use AI the most. They are the ones who use AI the smartest. Who know when to accept the suggestion and when to close the chat and think for themselves.

That ability to choose between convenience and curiosity might end up being the most valuable skill of all.

So back to the original question. If AI existed in 2011 would we have built the modern web faster or would we still be sitting comfortably in index dot php.

I think the answer depends on how many developers would have had the courage to ignore the AI and explore anyway.

And that number might be smaller than we want to admit.

What do you think. Would you have been the one to close the chat and try something new or would you have shipped the PHP solution and called it a day.

AI is not just making us faster. It is narrowing the range of solutions we consider. The convenience removes the friction that has always driven innovation. Junior developers are especially at risk because they trust AI outputs without having the context to question them. The real skill of the future is knowing when to ignore the AI and think for yourself.

One useState or seven Not the real question The real question is are you modeling states or just flipping booleans

Muhammad Niaz Ali — Thu, 23 Apr 2026 14:11:52 +0000

I see this everywhere in production codebases

Four separate states loading error data success gives you sixteen possible combinations Half of them are impossible like loading true and error not null at the same time But JavaScript doesn’t care about impossible states It just renders garbage on screen

Here is why this happens because developers think in booleans like is it loading is there error instead of thinking in states like what stage is the async process in right now

Here is how you fix it Use a discriminated union One object with a status field that can be idle loading success or error TypeScript then won’t let you render data unless status is success Zero invalid states Zero bugs from impossible combinations

Here is when to use what For simple stuff like dark mode just use useState For async state without caching like form submit use discriminated union with useReducer For server state with caching and background refetch use React Query For complex related state like a filter panel use useReducer

React Query is great for server state But using it for a modal submit button is overkill Using seven separate useStates for a simple fetch is asking for bugs

Maturity is knowing the difference

What is your go to pattern for async state in React

DEV Community: Muhammad Niaz Ali

What if AI is not accelerating us but keeping us exactly where we are

One useState or seven Not the real question The real question is are you modeling states or just flipping booleans