Hacker News Reader

Comment by tibbar | Hacker News Reader

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.

View on HN

> 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.

    > can't tell a difference between an animation at 25fps vs 50 fps

Is this commercially relevant for 99% of UIs?

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.

>infrastructure, databases, data engineering, stats

Why would those areas be less exposed to the "LLM threat"?

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.

> This is an extremely dumb take

...ouch! ;)

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.

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.

Amount of quality fronted code in public repositories, blogs etc. is much higher. Then even if it is not in the repo it is available via browser.

Backend code is much less available as a training set.

Because LLMs are dog shit. There I said it.

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.

> infrastructure, databases, data engineering

I work as a backend dev, without an opportunity to work on these at my current company. How do I learn and showcase these skills effectively. Thanks!

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 highly recommend csprimer for this.

https://csprimer.com/

Or if you want to just use books go with:

https://teachyourselfcs.com/

Reply on news.ycombinator.com