frontend role shift
some reflection and ideas
There’s a lot going on around the frontend role today - ai ai ai, easy code generation, simple div centring and adding color to buttons, loudly raising questions like: will it even exist in few years or would it be totally replaced by pRoMpT engineers?
And even though some of you are smiling at the nonsense, others are slightly worried (as llm-tools getting really good), something we can all agree on, the role is definitely shifting. you don’t spend so much time today finding some strange lint issue or framework nuances on stackoverflow, you just asking directly llm on your closest chat window, and it speeds up the process significantly. Or you’ve definitely felt how much mental overload decreased by just clicking tab-tab on cursor. Things are speeding up a lot. But where does that leave us?
When Code Gets Cheap, Questions Get Expensive
Generating code gets cheaper and faster nowadays, anyone can open an LLM chat and ‘write code’ - and that’s actually great. We shouldn’t worry, because writing software was never only about writing code, it was always about problem solving. Solving people’s needs with code. That’s not going anywhere. The upside: with correct usage of new tools, we have more time to think on what and why we are solving right now. Instead of wrestling with X we have more time to build quality solutions.
This shift is also changing how we’re perceived. sean goedecke nails the new reality:
Providing value to the company gets you rewarded
Not providing value to the company gets you punished
“Value to the company” means furthering the explicit plans of your company’s executives
So the most crucial skill now is asking the right questions. It relates to everything that we are doing. and It’s important to ask yourself daily to align with goals. The questions depend on where you are, but start with something like:
what are you trying to solve?
why does it matter?
who cares about it?
what’s the biggest impact you can have?
By asking the right questions, you create a better plan, which results in better planning of task you are solving, decrease failure and increase quality of your product. And of course, in addition to that you can delegate a lot to agents.
So delegate 80% of your work to preparation and 20% for execution.
llm shift
I see a lot of devs still looking on llm tools as some kind of temporary fun stuff to test, or just very smart google search without ad (for now), where you ask questions and grab snippets - basically fancy autocomplete.
But in January 2026, it’s a lot more than that. I won’t give you a list of top-1000 LLM-prompt-that-you-should-know-in-2029 - just some thoughts and ideas that i heard recently and would like to hear them from someone else too.
with having llm companion around you, you could decrease mental overload, and you should use that. delegate more (agents), use tabs autocompletion (try cursor if you haven’t), ask more frequently, focus only on what’s important.
want tips for mental alignment with LLMs? Start here,
you can do more now. If you didn’t have time for X before, now you can do it. storybook? tests (unit e2e etc) - try to do more, we finally have time for that one extra thing that we haven’t enough time to do before.
don’t delegate thinking process to llm’s, it’s great tools for learning and delegating boilerplate things, but there risk that you’ll get dumber.
don’t let llm’s guess, they cannot do it. instead figure out what is context engineering.
start with smaller chunks of work, don’t go with build me a new browser.
Here’s an example: how I recently figure out how to simplify the way we are write e2e tests in the team.
Before: Get ticket → manually figure out what the feature does → write test cases → write tests. Each step required deep mental effort and took a lot of time to be frankly, and I, as probably you, not a big fan of writing tests.
Now: Get ticket → ask agent to generate feature doc (using a custom prompt) → ask agent to write test cases from the doc (using a custom prompt) → ask agent to plan and implement tests, with examples and context. (using a custom prompt)
I emphasize plan here - it lets me review what’s about to happen and gives the agent a chance to ask clarifying questions.
What we get back - way less mental overload, faster flow and ways to automate even more.
What Comes Next
I think we’re slowly moving from domain specialization (FE, BE, etc.) to something more product-focused. Not full-stack for the sake of it, but actually understanding the whole problem - the why, not just the how.
Companies are asking a fair question: why hire a domain specialist when I can hire someone who does both? Frontend role won’t die, but yeah, more will be expected from us with that extra time.
To sum up this article reflection I would post Eren Bali quote that I saw on twitter:
