> Steer away from skills like web development that are clearly getting eaten by LLMs
On the contrary, here in my corner of EU nearly 60% of new jobs are frontend or full stack.
Anything else left is mostly SAP consultant or DevOps.
I think, the whole WebDev is dead end is just false lies to dissuade new entrants. Literally most successful business with a digital solution is web stuff with some automation that would otherwise be ms excel sheets shared via email.
Also this whole panic over LLM is overblown, I know of some brilliant experienced people in other professions like Electronics, Mechatronics, Aerospace, Material Science and literally all of them are finding the job market “very difficult at the moment”. It is the bad global mood in general used deceptively by opportunists to spread false fears of their LLM/AI.
At the end of the day, an insurance seller has hundreds of concerning reasons to convince you why everything is dangerous around you and you really need their product. Now apply that to AI sellers.
Web element feel similar to PHP or wordpress development in 2010.
There are millions of small businesses that demand wordpress websites, but the barrier to entry to support and build systems got very low very quickly. Professional developers were competing with high school students and offshore devs for work.
As a backend Developer, I can now build websites easily with Claude and react. I think web development, especially front end, will be like knowing HTML and CSS in 2015. Like everyone should know it, and thus not even worth putting on your resume.
Genuine question: why do you think LLMs will be able to handle frontend development in a way they won’t be able to handle backend development? I assume you’re talking about real companies, not toy projects or websites for restaurants or whatever.
Well, "frontend development" means a million different things, but LLMs are very good at flexbox and grid (and I'm not).
With backend I find they're good at the really high level (give me the options for architecture and their pros and cons) and doing something small and precise (gimme a function `List (Maybe a) -> List a`). The stuff in-between I have to handle myself.
LLMs are good enough to solve my problems with flexbox. I gave a LLM a small self-contained flexbox-puzzle which I couldn't solve, and it solved it. The CSS it produced did the thing I asked.
> If you aren't good at something you are not qualified to say that LLMs are good at it
Hard disagree: Even if you aren't good at writing a function like `List (Maybe a) -> List a`, you can easily say whether the LLM suggestion was good or not.
If you aren't good at playing the game of go and a program beats you giving you nine handicap stones, probably the program is good at it. Many similar examples.
> If you aren't good at playing the game of go and a program beats you giving you nine handicap stones, probably the program is good at it. Many similar examples
This doesn't follow at all, maybe you just really suck.
It is entirely possible that a game AI that you find impossible to beat is trivial to beat for almost anyone with more experience than you have
Yes, there are chess engines that can beat the best chess players
However, most people couldn't possibly tell the difference between playing against the best chess engine in the world or a novice difficulty chess AI, because most people suck at chess
"It is better than I am" is a terrible metric to use to judge when you suck at that thing
I think the person above was alluding to the idea that the determination of whether or not LLMs are good at frontend development is the idea that frontend development is flexbox. That's like me saying "LLMs will replace all developers who work with databases because Claude was able to spit out a really complex SQL query."
The question isn't "is frontend simpler than backend?" (which I don't think is as simple as you make it out to be). The question is "can LLMs replace frontend developers?"
I think it's a bit like Squarespace. The lowest possible tiers of developers will be replaced. Anything complex enough to be beyond the scope of a hobbyist isn't able to be replaced with an LLM.
lol I wish. The problem is not the inherent complexity but the accidental complexity. FE has a big chunk in the second. You won’t get your budget to rewrite three accidental complexity you find in the wild
Developing, managing, and operating distributed systems infrastructure has way less training data available than webdev. And it doesn’t translate in to pithy interpreted language one-liners.
There's another factor here I forgot to mention - web development, as a specialization, tends to be paid less and has a lower career ceiling in many companies than backend and infra engineering. This is a personal observation on my part but I've seen many other people remark on this. True full stack engineering, I think, is reasonably safe from the robots at the moment.
If someone likes building products, I'd basically recommend that they not go 100% full-bore on frontend engineering, definitely go for "full-stack", and accept that a lot of frontend code is trivia that you can just ask the LLM for these days. I would also recommend that they develop solid product management and UX skills.
Anecdotally, I work on backend/cloud and my senior frontend engineers do earn not as much as I do, but close… and their environments are always less stressful (major outages are not caused by frontends usually and when so, reverting to the last stable commit is enough since frontends are stateless; their toolset is narrower than mine, so yeah they need to jump between frontend frameworks but that’s fine… me in the meantime need to jump between backend frameworks, dbs, k8s, distributed system knowledge, unix tooling, OS/TCP/IP, etc)
> a lot of frontend code is trivia that you can just ask the LLM for these days
If you're building CRUD yes. If you're doing anything remotely complex or novel, LLMs fall apart, much like they do for complex backend tasks. There's a lot of cool, highly customized stuff you can build with JS, and LLMs don't do a very good job at general problem solving.
They're still helpful for writing small, specific functions, or providing high level guidance
Certainly. Front-end and UX skills go together. Front-end dev as a beginner → UX → PM later, would provide the same salary as back-end dev -> DevOps / K8s.
> Steer away from skills like web development that are clearly getting eaten by LLMs.
You had it going well there but then had to ruin it with a take like that.
If you’re talking about your trivial, github-filled example scenarios of frontend, sure. But then we could say the same for all other roles, including backend logic that’s regurgitated all the time.
Like with everything else, the non-trivial bits need work and skills.
I'd personally try to stay away from anything built this way, if I can get a whiff of it (and it's not super hard to find the slop right now). But, even if learn to agree on this for the share of throwaway apps or internal tools that might not need sophistication or care, my point was that the same take applies to the backend side as well and I'd argue that's a more at-risk domain since data is usually in a serializable format to be fed into LLMs and doesn't have the challenges of visual input.
> Look for work in major U.S. tech hubs like the Bay Area. Pay is better and network effects are strong, so your next job will be easier to get.
Jobs and the network effects happen all across the country. As you get older and maybe don't want the grind, or have a family, or just want a better work/life balance, this will become apparent.
Basically, always have at least two people who will support you for your next job.
There are plenty of tech hubs besides the Bay Area, that's for sure. But I can tell you that when I moved from a small company in a small economy to a moderately-well known startup in the Bay, the rate at which recruiters contacted me jumped from maybe a few times a year to multiple times per week. And after a few years, many of my coworkers started their own companies and invited me to join them.
By contrast, I have very talented friends who did not make the jump to work at a tech hub, and they don't have the same kind of network or opportunities.
With that said, I very much agree with you about wanting work life balance, making sure there are people who will support you in your next job, etc. However, I think that this is much easier to optimize for when you do have an established career and an extensive network already.
You've undeniably right about how there have been spheres of influence where people and capital come together. Every area of the United States has some kind of forced name of "Silicon *" for a reason.
I just don't think this will be true in the future. Move where you want to, maybe have to work harder to break through, but that was also true in the Valley.
Good advice in general. I would add - try to pick a skill which gives you a deep understanding in something fundamental which will always be relevant, rather than a particular shiny tech.
I would love the bay area, but unfortunately it is extremely inaccessible for me and others once you have a family. Trying to find a place to live in a good school district seems like it takes minimum $2M for a house. Renting is less long term secure when trying to maintain consistency for kids. That's not even get into earthquakes and wildfires!
If you’re usual child-raising age then you probably have 6-10 years of experience, and there should be lots of jobs that pay $500k in the Bay Area. Buying a $2m house on that salary is pretty doable.
$500k would likely be a staff level salary offer. I think a senior role around $350-400k is probably more likely as a new hire coming in which is definitely great money, but still hard to take a $20k+ monthly mortgage with! Especially since a lot of that salary is variable equity income which can go down (ask me how I know!!)
Amazingly enough, I and millions of other developers have managed to find jobs outside of the Bay Area.
Personally, I’ve been finding jobs quite easily 10x since 1996 - the last 2 in 2023 and last year.
> Look at the requirements for your dream job and figure out what you need to learn to qualify.
Those jobs in the Bay Area mostly require you to “grind leetCode” and system design. They really don’t require you to know the latest frameworks, databases, Kubernetes, etc
Hey, as I said in another thread, I did not start out working in the Bay, and ended up here somewhat by accident. It shocked me how much easier it was to find good jobs here, and I'll stand by that. With that said, of course I say this with no judgment to anyone not in the Bay or other tech hubs, it's friendly advice from personal experience.
> Those jobs in the Bay Area mostly require you to “grind leetCode” and system design. They really don’t require you to know the latest frameworks, databases, Kubernetes, etc
Hmm, it sounds like you have a negative opinion of Bay Area jobs in general. I'm asking people to first figure out what work sounds interesting to them, and then learn the relevant skills. If you have the skills, the Bay Area probably has the right job, too. Of course these jobs also exist elsewhere, I'm not sure why I'm triggering this reaction...
I agree, that is how many big tech interviews look. I've done 'em too. If one's dream job is a generic, mid-level role at BigTech, then the path is clear - get very good at Leetcode and system design, and flag down a recruiter.
My dream jobs tend to be more eclectic, and not necessarily at giant companies. I'm more interested in getting really skilled at a particular type of technology and being hired to work on that. And this kind of targeted recruitment still exists at big companies, too.
But also Leetcode doesn't scare me too much, so maybe I'm dismissing it too easily. I've done a lot of those problems over the years, and I'm FAR from great at them but it's never been the blocker to a particular role in practice.
Most people’s “dreams” have nothing to do with working. Their dream is to have a combination of shit ton of money appear in their bank accounts every pay period and stock to appear in their brokerage account every vesting period.
True there are some who want to win the lottery and accept less than their market rate in exchange for “equity” in a non public company that will statistically be worthless.
Coding interviews are definitely is still the part of the process you have to pass unless you are a very well known big deal in the industry.
BigTech companies want versatile developers who can move around as necessary.
There are no “inside tracks” for 99% of positions aside from probably acquihires.
You go through the grind regardless. Open source contributions really don’t mean that much.
> Most people’s “dreams” have nothing to do with working. Their dream is to have a combination of shit ton of money appear in their bank accounts every pay period and stock to appear in their brokerage account every vesting period.
Yes.
It took me two years to have the illusion shatter and realize that I simply do not want to work. Imagine spending 8 hours a day plus commute sitting on your ass and writing corporate emails, and calling that self-realization. Or imagine grinding hard for a pay 50% higher than the security guard who's just playing video games, so that you feel like you're above the minimum-wage workers, but in reality you can't escape the poverty either.
I consider myself incredibly lucky to be working in a company where people who give a fuck are a minority, so there's very little pressure to actually do anything, while the pay is decent. I use some of my extra time to do some physical and mental exercise, so that my body doesn't collapse when I finally get to retire, and the rest is just spent watching porn. Being a motivated high-achiever taught me that the more you have, the more you expect, leaving you perpetually dissatisfied. The only way to be happy in life is to say "I'm staying here, this is comfy".
I'm trying to save and invest as much money as I can, so that before my body deteriorates due to aging, I might enjoy some time not having to worry about forces beyond my control or understanding carelessly ruin my life. I'm not planning to do anything spectacular once I get to retire. I'm just going to watch TikTok and I'm going to be happy.
It seems like you're really focused on the interview process for a small number of very large tech companies. My experience doesn't match yours - I have been recruited to a specific BigTech team based on my background, and the interviews were more focused on specific skills than leetcode. But it seems like most BigTech interviews probably are coding/system design.
With that said, I have tended to interview more at scaleups/late-stage startups in recent years, and it's been very rare to see a truly leetcode-heavy interview process. These are positions that pay comparably to big tech, although the equity is generally more risky. But I've also been able to cash out some startup equity, so maybe my experience is not representative again...
> Most people’s “dreams” have nothing to do with working
This line always seems like a cop-out to me. Almost all of us have to work, and it takes a huge amount of our time. And for many of us in the tech industry, we have been intrinsically interested in this tech since we were kids, and have specific stuff we'd prefer to work on. Can we just accept that certain work is going to be more interesting for certain people, and that they might want to steer their careers in that direction, especially if it pays better?
By pay similar to BigTech do you mean the cash you get paid at a startup/scale up is similar to cash + liquid public RSUs?
Equity in private companies especially in today’s climate is statistically meaningless.
And if you look at the companies that pay the most + have the largest number of opportunities, they are the “small number” of BigTech companies
And back to the Bay Area argument. Most of the major public tech companies have offices all over the US that pay the same with a much lower cost of living.
Stripe has given their employees a chance to sell their equity via a tender offer. SpaceX I’m not sure
There has to be a market of people who actually want to buy the equity and the company has to allow it. In the case of “scale up” early startups - the type the original commenter said he works for - usually either there is no one that wants to buy the equity or it’s a steep discount
Let me try to state your overall point, as I understand it:
"The primary goal of a tech career is generally to get a high-paying, low-risk job. Many of those jobs are in Big Tech. You should optimize for getting one of those jobs (but ideally not in the Bay Area, because it has a high cost of living.) To do that, you should primarily focus on grinding Leetcode and system design, because those are what Big Tech will evaluate you on. There are no loopholes worth speaking of, and you will be competing with many other engineers for the same positions."
Feel free to correct me if I'm not getting it right. I have no particular issue with someone whose career strategy is the one above. It's actually important information for someone to learn, especially if they come from a small town, like I did, where Google et al. never darken your door.
However, that approach is not a common one in my community. Instead, I see people who exited startups as founders or early employees, people who had particular skills directly recruited by BigTech and others, people who worked at private companies with regular internal liquidity events. People who worked on stuff, by and large, that was interesting to them. People who have plenty of job opportunities, and don't feel like they're one of a thousand people competing for each position. By and large, I prefer this approach.
Again, we can look at statistics instead of suffering from survivorship bias. The vast majority of employees in startups will not see outsized gains from exits especially in todays climate where the IPO market is dead and acquisitions are going for much less.
> They really don’t require you to know the latest frameworks, databases, Kubernetes, etc
The latest "framework, databases" are constantly changing. Being good at leetcode and system design is a better signal (ofcourse, not perfect) than knowing specific tools.
Being good at system design implies you are aware of tradeoffs across various systems, and that coupled with willingness to grind means you can at pick up new tools and probably deliver on projects. I have used 13 languages and an equally absurd amount of tools across 4 orgs in my 5 YOE at FAANG. It's constant learning, or you're out basically. Doesn't make sense to quiz on anything specific. The interview process is quite fair actually.
Leetcode is only a useful problem to ask if the candidate has not encountered that problem before and has not practiced leetcode. Otherwise it is exactly as good a signal as knowing some arbitrary framework or database.
"Grind" just means "memorize a bunch of stuff for later regurgitation", which is the same thing as is demonstrated by memorizing the API for some arbitrary database or javascript framework.
Willingness to "grind" is a positive signal for people hiring developers in the same way that low critical thinking skills is a positive signal for people hiring law enforcement officers, and results in a team of similar quality.
Leetcode is a standardized test that shows your ability to write code, grind and pattern match in a very complicated space. It is not possible to memorize solutions to all problems. There are way too many problems in this space. All the people complaining about leetcode are a prime example of this. It takes a lot of time and background knowledge to learn all the algorithms, data-structures, and problem-solving patterns... to get good to the level where you can ace FAANG and trading interviews with a high probability. It's a more useful metric than memorizing specific APIs which is not standardized, has basically no/simple pattern matching, and does not really test coding skills. There are also too many frameworks, and this just doesn't stand the test of time. People would need to constantly re-learn frameworks for interviews.
Most companies have been using leetcode and system design for dozens of years for a reason. It's not changing anytime soon.
Also, leetcode can be really fun :) if you remind yourself to be truly curious about the problem.
I'm mostly thinking of frontend dev work, but also some types of light backend work that you might see in a CRUD app. And listen, I've done that work, I've done a lot of it, and I saw that it's mostly a career dead-end, becoming more and more automated/copiloted away. It's not a career moat to be a mid-level React developer. By contrast, some things I think are worth pivoting into include infrastructure, databases, data engineering, stats, etc, and I've spent the last few years pivoting into those areas.
An interesting counter-point is that if you have great product and design skills, this is a great time to learn frontend development, because it's more accessible than ever and can supercharge your existing skills. But the days of being a pure frontend coder are probably fading.
> By contrast, some things I think are worth pivoting into include infrastructure, databases, data engineering, stats, etc
I can't imagine why if LLMs can magically solve web development (which can be complex as hell depending on the app) they wouldn't be able to solve infrastructure, database or data engineering.
I somewhat agree that our career moats were hurt (though not as much as you seem to believe in my opnion) but that's happening across the board.
I'm my view, the core of front-end work was always the UI "User Interaction".
Yes some can be solved by designers, but I believe there will still be a big market for designer-programmers.
The programmers that understand design, interaction, pixels and colors will still be of great value.
But if you don't really care about how stuff looks or can't tell a difference between an animation at 25fps vs 50 fps, it is a good sign it is time to try something else.
AI will simply refine your skillset. A backend programmer will have more time to think about architecture, a data engineer/scientist will have more time to think about maths. Or in essence "what am I trying to achieve". And it is up to you to step up to it.
I rather think of this generation with hordes of "coders, writing code" as an anomaly.
Probably not, but if you are the UI developer that gets annoyed by it every time you open the application, it means you are probably in the right place.
Front-End interfaces can be as complex (or more complex) than Back-End/infra/analytics/etc... At the end of the day, it is all about data and the front-end needs to maintain state. If your interface is complex, your state will also be complex.
Theoretically - yes, practically, on average, any of the things you’ve listed is far, far, far more complex than your average frontend that is basically glue between “real” logic and user.
If you are doing CRUD simple data apps, I don’t get why your backend will be complicated. Sure the industry has complicated stuff (aws & friends) for complexity sake but that doesn’t mean you have to go down that rabbit hole.
Front-End is complex which is why we have 36362 libraries to solve the same problem and still move user interfaces sucks.
I'm not a fan of the "front vs back" dichotomy. Chrome is just another box as far as my responsibilities and goals are concerned, but it always feels like there's a mental handoff switching to this one context.
To be brutally honest, LLMs aren't very good at solving novel problems, they aren't very good at integrating business context, and they make many small mistakes. That's why they are a good fit for frontend development! Frontend features are
1. often quite deterministic (well-defined specs and mockups from product managers) and
2. repetitive (95% of all frontend features have already been built many times in the training set) and
3. small mistakes often don't really matter much, the page will just be slightly degraded. Speed of development usually beats perfection.
So you can often say "hey, Claude, here is the exact feature I want, this has been done many times before, can you update the codebase to mostly do that?" And Claude can do that in a lot of cases now, and will probably continue to get better at it over time.
By contrast, infrastructure work tends to be more complex and higher stakes (a small mistake can cost you a lot of money or downtime). Also you usually aren't optimizing as much for a large number of small features. So there's just not as much value, and much more danger, in turning an LLM agent loose on this stuff.
This is an extremely dumb take, I’ve worked on both areas before and I could say that infra work is mostly repeated and needlessly complex config sprayed into git. LLMs have seen enough of that to make head or tails of it by the way you’re characterizing frontend dev.
The important part is NOT auto-generating repetitive configs; it's about the effort and skill required to verify that output. On the frontend, we have an easy feedback loop to preview the effects before deploying. That also helps us produce lots of training data for frontend LLM output.
On the backend, there is substantial risk with infra changes - you could drop the database, block production traffic, etc. etc. You can't just vibe code the infra configs and hope for the best, you need someone who understands the output well enough that they could have written it themselves. That means that LLMs are at best a modest productivity boost for infra engineers right now. It's also much harder to simulate the output of LLM infra changes compared to running a browser, so it's more expensive to get training data to boost the next version of the model's performance.
> On the frontend, we have an easy feedback loop to preview the effects before deploying
There are many ways to introduce subtle bugs into your system, I don't think the risk is that low in the front end. I'd agree with your take if LLMs were reliable, but they're not - especially on big codebases. A broken form is downtime just like a broken API endpoint, the damage is the same.
I understand where you're coming from, there's the sense that front end work is "less important" than backend work in some places, but honestly every company that cares about its product shouldn't really adopt this philosophy.
Product work is super important - it's something I care about a lot. I think it's just different from infra work, like comparing woodworking tools to a dump truck. You're going to do a lot of fine-grained feature work with your woodworking tools, and if you scuff something up or break a piece, that's not too disastrous and can be fixed. But the dump truck can, like, destroy your warehouse, throw your inventory on to the highway, or explode. Even if there's a similar error rate in the auto-woodworking-tools to the self-driving-dump-truck, the dump truck's mistakes are too risky.
We should probably also distinguish overall quality from error rate. If the woodworking tools are producing crappy stuff, then there's no reason to use them at all. But if they produce mostly nice stuff, fast, but occasionally break a piece, they might be really useful.
You once again seem to be thinking of trivial examples of frontend to say there is an “easy” way to verify the loops. I really wish it were that simple for anything reasonably complex I encountered that were customer-facing — often filled with plugins/apps/micro-frontends/libraries owned by other teams etc or clients. I also think if it were that simple, companies wouldn’t be popping up every now and then trying to solve challenges in this space w.r.t validating flows, interactions/animations are smooth and ensuring some weird stuff isn’t happening across all the browsers the customers of your product are using. But there are a lot of them gunning for a piece of the pie, more since the LLM frenzy. And this is largely just web stuff I’m talking about, I’m sure similar complexity exists for mobile apps if we are to count that also into the equation.
Re: backend risks, I once again think you try to rub this off by equating all of backend development is done the way you’re talking about — to perfection, with backups, tests for those backups and all that. I’m sorry to burst your bubble here but if we’re thinking about the same kind of scrappy development you’re talking for frontend, the backend side is about as bad or worse (given how critical you think all of this is, which I agree with). I doubt the backend engineers are sitting there, carefully reading manuals and crafting code instead of vibecoding.
> You can't just vibe code the infra configs and hope for the best, you need someone who understands the output well enough that they could have written it themselves.
It’s not vibecoding but I’ve seen engineers in this role google, copy-paste and modify configs and scripts that run multi-million dollar workflows which somehow worked at the end of the day. I bet LLMs can do a much better job than that, don’t you?
> It's also much harder to simulate the output of LLM infra changes compared to running a browser, so it's more expensive to get training data to boost the next version of the model's performance.
I disagree. It’s much, much harder to go and debug why your customer on X OS, Y Browser and Z GPU (to simplify) is seeing glitches when others are not. Sometimes that leads you to browser bugs. I am yet to see any AI-loop based tools come close to tackling the kind of real-life, serious prod-driven challenges. If you think running a browser is all it takes, I can say something dumb like “running a container is all it takes” but see how stupid that sounds? :)
And it’s also silly to think UI mistakes don’t have real-world implications. There are countless examples for this already — broken purchase flows resulting in losses, frustrated customers unable to complete their work and leaving apps, incorrect request flows causing small/big DDoS, sometimes even stuff that might lead to lawsuits.
——
I feel you have a bleak view of frontend as a whole or you never worked with teams who do a good job or you have been conned by the chest-thumpers who have been saying for years and YEARS that frontend development is pointless, not real CS and have zero value. Oh, and that JavaScript is not a serious language — classic!
If I saw backend/infra engineering the same way based on the # of devs and teams I had to hand-hold and # of their mistakes I had to help fix while working as a front-end engineer, I’d be shitting on them too. But I know better to see that there’s a right way to do it.
> I feel you have a bleak view of frontend as a whole
First of all, let me say, I love frontend. I spent probably a decade building products and tools almost entirely on the frontend. I enjoy interfaces and workflows and visualizations. I don't want you to feel like I'm attacking frontend or frontend developers.
> often filled with plugins/apps/micro-frontends/libraries
> It’s much, much harder to go and debug why your customer on X OS, Y Browser and Z GPU
Second of all, it sounds like you're doing some pretty complicated stuff! And that you care a lot about how your work affects people. That's awesome. I don't think LLMs are particularly close to automating web development done at this level.
Here's where I'm coming from: A shockingly large amount of interesting frontend work can now be done, reasonably well, by an LLM. Sure, it's no staff frontend engineer, but you now have people who can't code at all who can dream up little apps and have the LLM actually just build it for them, something actually useful. That is absolutely incredible to me.
I also see the momentum here - if there is any area of software engineering that the model companies are trying to automate, it is frontend engineering. Will they get all the way there? Eh... probably not. But it's going to keep getting better. I think this will make the best frontend engineers much faster and more productive, and will probably make the field more competitive as a result. People will need to learn entire new workflows to stay at the top of the field, and there's no guarantee on how good AI will get. Candidly, I just don't see the same momentum for AI in the database/infra space, and speaking personally, I thought it was the right move to shift in that direction.
> I enjoy interfaces and workflows and visualizations. I don't want you to feel like I'm attacking frontend or frontend developers.
I hope you mean that but it's hard to see it that way based on your original comment and responses. The trope of "frontend is not a serious job" has been infuriatingly going on for a long time before LLMs took the center stage and that seeps out of the things you've said so far.
But, I'm glad if you mean what you said above.
> Here's where I'm coming from: A shockingly large amount of interesting frontend work can now be done, reasonably well, by an LLM. Sure, it's no staff frontend engineer, but you now have people who can't code at all who can dream up little apps and have the LLM actually just build it for them, something actually useful. That is absolutely incredible to me.
And this is where I'm coming from, based on your original reductive narrative on LLMs overtaking frontend and that the field is somehow at risk — if you feel the same way, you can apply these _exact_ arguments to a _shockingly_ large portion of backend too. I could say most are just glorified spreadsheets. Moreover, a lot of startups just use one of the "serverless" platforms and won't think twice about database, devops, security, authn/authz until they hit an escape velocity.
But I personally think meaningful engineering solving real-world problems at scale that is meant to be an enjoyable experience for the user should be well thought through, end-to-end, regardless of the smaller scopes within.
> Candidly, I just don't see the same momentum for AI in the database/infra space, and speaking personally, I thought it was the right move to shift in that direction.
Partly, I think you are probably forgetting that a lot of these startups promising all of this also promise the backend stuff, even if you might disagree with the choice of tech stack (usually React/Next w/ Supabase/Planetscale/Firebase) and the deployment environment (usually something like Vercel). And the reason why the frontend part is front and center is because... well... that's what the users ultimately interact with. They don't give two shits about the stack (front & back) as long as the product works and works well. But it'd be naive to think this didn't involve all the automated code being spit out on the backend side as well.
And let's forget AI for a moment, by this line of thinking, a large portion of the backend engineering you talk about have been available in simplified forms via serverless offerings or via low-code offerings. Same for databases, including branching and claims of seamless migrations and backup. So, maybe you should have started panicking way before modern LLMs hit the scene? :)
But you probably won't because like me, you realize it's not that simple and it's not always practical. Same reason why I am not using Framer/v0/<insert fancy new tool here> to build a non-trivial front-end app with growing complexity.
I'm a cautious optimist in this space. I do think the tech we got so far is cool and groundbreaking and I use them extensively for noodling. But at the end of the day right now, they're still tools. We are seeing the AI leaders shifting goalposts every day, complain about lack of data etc. and I honestly believe we are many more breakthroughs away from getting to the dream world you're thinking of, especially when broadly generalizing things.
> Aside: I'm also pretty sure you can find plenty of "AI" companies promising automated DevOps/Backend/Database etc. just within https://www.ycombinator.com/companies (try keyword searches).
> The trope of "frontend is not a serious job" has been infuriatingly going on for a long time before LLMs took the center stage and that seeps out of the things you've said so far.
Eh, sorry I came across that way. To me, seeing a complex system visualized, making it interactive, is just so beautiful. That's a big part of why I got into frontend in the first place. I wouldn't take anyone seriously who doesn't think frontend is a serious job.
I also suspect that you are doing more complex, and finely judged frontend work than I did - I took a peek at your public profile ;). So it's not surprising that we have different impressions. If someone is building a frontend that needs to work seamlessly for billions of people across many devices, that sounds incredibly challenging and frankly I've never even tried to do that so I can't even comment on it.
But, I would say that a lot of the frontend work that I find interesting can now be automated with LLMs. Historically, I've tended to build internal tools that usually had a fixed runtime environment and small number of users. So I'm not as worried about the fine points of the web, but about creating a lot of features and interactivity in a particular, easily tested environment. I would wager that the average frontend developer is doing work somewhere in between the two of us.
> you can apply these _exact_ arguments to a _shockingly_ large portion of backend too
Hmm, I think we just disagree here. I think a lot of my view comes down to how frontend ultimately needs to collapse into something that can be visualized and interacted with, and this helps force the state to evolve in sane ways. On the other hand, I think backends quickly grow from a spreadsheet to insane, highly-dimensional, highly-coupled nightmares that no one can really visualize anymore, first at the logic level and later at the architecture and schema levels.
Ultimately LLMs are helpful when they can sort of grok the overall structure and plan of your code and add stuff helpfully to it. I think that LLMs have more public examples of frontend codebases and that helps them follow the overall structure a bit better. In my experience, LLMs are doing a bit better in trying to add small features to large frontend codebases than to large backend codebases, probably for this reason.
Finally, you can often define what changes are wanted on the frontend fairly precisely. A series of mockups plus descriptions of the interactions carries a lot of detail. On the other hand, backend changes often interact implicitly with unstated business context that you can't get solely from the backend code itself (this become particularly tough when you try text-2-SQL, for example.) So I think many backend and architectural changes have inherently vague specifications that need to lean heavily on context that's not captured in the ticket.
None of this is meant to undermine the seriousness or difficulty of frontend as a profession. But it is still my opinion that, on average, LLMs have a better chance of doing useful things on the frontend than the backend.
I thought about this a bit more, and I think the boundary between front end and backend can be a bit artificial. Theoretically, one could do highly complex state management and data flows on the front end, even run your own database, etc. Not to mention complex dependency trees. All of this can and does happen, but in my mind this starts to leak into what I’d consider backend work anyway, just coincidentally happening in the browser. And I don’t think LLMs are particularly good at automating any of that.
But I think there is a huge chunk of work, which most people think of as front end, which is displaying pre computed data according to a particular pattern, and providing hooks into the backend for additional interactivity. I think that this piece can be largely done by LLMs now.
LLMs are not the threat right now. Mismanagement of the United States and a 2008 style recession (but without the TOGA power of the SaaS/cloud boom. AI is swimming naked financially) are the biggest threat for your career and employment in 2025.
Less data to train on? Github et all are awash in front end code but the stuff most enterprises run on is locked away and not accessible to the AI companies.
Realistically, you need to bootstrap your experience in these areas. Pick an area to focus on and put your own time into learning it. My rule of thumb is that you need about 100 hours of personal study to get to "smart intern" level in a particular tech skill, given that you're already a professional developer. I typically bootstrap a skill by picking a textbook to work through and combining it with personal projects and adjacent reading as it comes up. Usually after ~100 hours or so you will be able to arrange an internal transfer to work on that stuff in your day job.
I see the evolution, atleast until things get drastic, to be where the interviewer will allow LLM use and observe how fast you can deliver the objective while dealing with hallucinations etc.
On avoiding web dev: I get the concern, but I wouldn't write it off completely. LLMs are changing the game, but they're not replacing deep expertise in architecture, scalability, or understanding real-world business constraints
I don't think they meant architecture, scalability, or understanding real-world business constraints
I think they meant literally web developers, or, aka, frontend folks doing html and css.
I've worked on backend systems that run web sites and apis, for over a decade, and I've never once referred to myself as a web dev. That title has always been frontend specific imo
Good advice -> but is an error or blindness
> * Steer away from skills like web development that are clearly getting eaten by LLMs.
funny enough all the hyped YC / Bay area startups don't make as much as your typical CRUD webapp.
Devs we tend to be attracted to tech. but what makes good tech doesn't mean it's a good business. That's why your typical bay area startup depends on vc funding & will likely spend 10 years without being cash flow positive.
* Try to get at least one job offer every year, even if you don't accept it.
* Look at the requirements for your dream job and figure out what you need to learn to qualify.
* Pick one skill and get very good at it. Spend an hour a day on it for a year.
* Steer away from skills like web development that are clearly getting eaten by LLMs.
* Look for work in major U.S. tech hubs like the Bay Area. Pay is better and network effects are strong, so your next job will be easier to get.