If you had asked me back in early 2025 what the future of web development looked like, I probably would have given you a mix of excitement and mild anxiety. The headlines were everywhere: "AI will replace programmers," "The end of coding," and "Software engineering is dead."
Well, it’s January 2026. I am still here. People still need websites, and my Github repositories are more active than ever. But I have to be honest: the job I am doing today is fundamentally different from the one I was doing twelve months ago.
For years, your value as a developer was tied to how well you knew the syntax. You prided yourself on memorizing the intricacies of Symfony’s event listeners or the latest Next.js routing patterns. If you got stuck, You would spent hours on Stack Overflow. If you needed a complex function, You pieced it together line by line.
Today, that workflow feels ancient.
Over the past year, tools like Cursor and Claude Code haven't just become "assistants", they’ve become an integral part of the workflow. They have shifted my role from a writer of code to more of an architect. I spend less time typing semi-colons and more time thinking about system design, data flow, and user experience.
But is it all sunshine and rainbows? Not exactly. Relying on AI has introduced new challenges, "lazy" habits, and a constant need to double-check if the LLM is actually telling the truth.
Here is a look at how my daily work as a developer has actually changed over the last year, the good, the bad, and the surprisingly human elements that remain.
The Paralysis of Infinite Possibility
Because the barrier to entry for building anything has dropped to near zero, I’ve run into a new problem: Idea Paralysis.
In the past, if I had an idea for a side project, I would filter it through the lens of effort: "Is this worth spending three weekends setting up the auth and database?" Usually, the answer was no. The friction was a natural filter.
Now, that friction is gone. I can spin up a prototype in an hour. This sounds great, but it has clogged my mental bandwidth. Instead of focusing on one high-quality project, I have ten half-finished prototypes because the "cost" of starting is so low. The constraint is no longer coding time; it is decision energy.
Phantom Complexity: Adjusting to "warp speed"
I still haven’t fully adjusted my internal clock.
I’ll look at a task, say, "Refactor the entire billing component to use Stripe’s new API" and my gut reaction is to brace for impact. My brain schedules a full, painful day of reading documentation and fighting errors. I prepare myself for the grind.
Then, I feed the docs to the AI, explain the context, and it’s done in 45 minutes.
It’s a weird form of whiplash. You gear up for a marathon and finish after a 100-meter sprint. It sounds like a luxury problem, but it messes with your sense of accomplishment. You’re left with all this extra time and a nagging feeling: "Is that it? Did I miss something?"
Context is King (and the AI is a literal thinker)
The most critical lesson I’ve learned this year: If you leave a gap in your instructions, the AI will fill it. And usually, it fills it wrong.
Prompting isn't about magic words; it's about rigorous specification. If I ask for a "User Settings Page," the AI will happily give me one. But if I don't specify exactly how i want the layout to be or how i want the data to be saved, it will pick the easiest (often wrong) path.
My workflow has shifted to "Front-loading" the effort. I spend more time writing out the requirements in English before I write a single line of code. I have to brainstorm the edge cases first, because if I don't tell the AI about them, they won't exist.
Strategic Intelligence: The "Thinker" and the "Doer"
I’ve also started treating AI models like a hierarchy of employees.
I don't use the same model for everything.
For Planning: I use the big, expensive "Reasoning" models (like Claude Opus 4.5 or Gemini 3 Pro). I use them to architect the solution, plan the database schema, and spot potential pitfalls. They are slow and expensive, but they think.
For Execution: Once the plan is solid, I switch to the fast, cheaper models (like Cursor's Composer 1 or Gemini 3 Flash) to actually write the code.
Separating "Thinking" from "Typing" has been a game changer for keeping costs down and quality up.
The "IKEA Effect" and the Loss of Satisfaction
This is the hardest part to admit. Sometimes, building a whole app feels… less satisfying than it used to.
There is a psychological concept called the IKEA Effect: we place a disproportionately high value on things we partially created ourselves. The struggle is the value.
When you spend three days fighting a complex React re-rendering bug and finally solve it, you get a massive dopamine hit. You feel like a wizard. You earned that feature. When you ask an AI to fix it and it works instantly, the result is the same (working code), but the emotional payoff is gone.
I’m building better software faster than ever, but I sometimes miss the "craftsmanship" of hand-chiseling the code. It’s a trade-off I’m still learning to accept.
Conclusion: The New Normal
So, has AI changed my work? It has turned me from a bricklayer into a foreman.
I am more productive, yes. But I also have to be more disciplined, disciplined about which ideas to pursue, disciplined about testing the output, and disciplined about finding satisfaction in the product rather than the process.
The code is cheaper. But the thinking is more valuable than ever.