6 ms·

>infrastructure, databases, data engineering, stats Why would those areas be less exposed to the "LLM threat"?

ozim 2y ago
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.
tibbar 2y ago
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.
- sangeeth96 2y ago
  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.
  - tibbar 2y ago
    > 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.
    - weatherlite 2y ago
      > 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.
      - tibbar 2y ago
        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.
tonyedgecombe 2y ago
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.
nextts 2y ago
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.

ozim 2y ago

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.

tibbar 2y ago

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.

sangeeth96 2y ago
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.
- tibbar 2y ago
  > 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.
  - weatherlite 2y ago
    > 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.
    - tibbar 2y ago
      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.

tonyedgecombe 2y ago

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.

nextts 2y ago

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.