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.