4 ms·

> I'd love to see examples of issues that are so big that they warrant reverting to manual coding Ah I see your org hasnt yet had an outage caused by a bad LLM

by jofzar 5mo ago

> I'd love to see examples of issues that are so big that they warrant reverting to manual coding Ah I see your org hasnt yet had an outage caused by a bad LLM code push.

latentsea 5mo ago
This shouldn't actually change virtually anything. We had this happen recently, and were able to rollback within minutes. Devs hand-coding stuff breaks things too. If you already have good observability, fast rollback processes, and feature flag new changes plus do % based rollouts to limit the blast-radius, then it's more or less the same.
c0rruptbytes 5mo ago
sounds like bad deployment practices - canaries, guardrails, fast rollbacks, ring based promotions, cell based architecture, blah blah etc... humans write bad code too, there should be systems in place to protect it from releasing
- theojulienne 5mo ago
  I think people spend way too much time trying to say that LLMs are bad / shouldn't be used / etc because the LLM can't get it right the first time and/or makes mistakes. I think this is because we all hope that software/computers work like this in an ideal world, and LLMs are software. This is the wrong mental model. The way to think about an LLM is like a human: prone to following bad examples if it sees them, needs guardrails to catch mistakes, needs code review. It also needs access to what "correct" looks like: architectural design documents, skills that explain each type of change, etc. It needs prompting/skills telling it to follow a safe workflow, telling it to consider how a safe rollout would work, what a safe rollback would look like, what the performance implications are - just like a human. The nice thing is that you now have a very knowledgable assistant that can help write additional guardrails that would have always ended at the bottom of your backlog. Perhaps it used to take many hours to research and understand how to write a custom linter to catch a specific coding pattern. Today, ask Claude to do it and an hour later you'll have a custom linter rule for your language of choice, guaranteeing the same mistake can't happen again because CI will block it.
bluegatty 5mo ago
"Ah I see your org hasnt yet had an outage caused by a bad LLM code push" "We went back to shovelling by hand because someone ran over the pole with the front-loader, even though he had no experience driving it." This is definitely user error; obviously it's a hard tool to wrangle but it's entirely possible to use it safely.

by jofzar 5mo ago

> I'd love to see examples of issues that are so big that they warrant reverting to manual coding Ah I see your org hasnt yet had an outage caused by a bad LLM code push.

latentsea 5mo ago

This shouldn't actually change virtually anything. We had this happen recently, and were able to rollback within minutes. Devs hand-coding stuff breaks things too. If you already have good observability, fast rollback processes, and feature flag new changes plus do % based rollouts to limit the blast-radius, then it's more or less the same.

c0rruptbytes 5mo ago

sounds like bad deployment practices - canaries, guardrails, fast rollbacks, ring based promotions, cell based architecture, blah blah etc... humans write bad code too, there should be systems in place to protect it from releasing

theojulienne 5mo ago
I think people spend way too much time trying to say that LLMs are bad / shouldn't be used / etc because the LLM can't get it right the first time and/or makes mistakes. I think this is because we all hope that software/computers work like this in an ideal world, and LLMs are software. This is the wrong mental model. The way to think about an LLM is like a human: prone to following bad examples if it sees them, needs guardrails to catch mistakes, needs code review. It also needs access to what "correct" looks like: architectural design documents, skills that explain each type of change, etc. It needs prompting/skills telling it to follow a safe workflow, telling it to consider how a safe rollout would work, what a safe rollback would look like, what the performance implications are - just like a human. The nice thing is that you now have a very knowledgable assistant that can help write additional guardrails that would have always ended at the bottom of your backlog. Perhaps it used to take many hours to research and understand how to write a custom linter to catch a specific coding pattern. Today, ask Claude to do it and an hour later you'll have a custom linter rule for your language of choice, guaranteeing the same mistake can't happen again because CI will block it.

bluegatty 5mo ago

"Ah I see your org hasnt yet had an outage caused by a bad LLM code push" "We went back to shovelling by hand because someone ran over the pole with the front-loader, even though he had no experience driving it." This is definitely user error; obviously it's a hard tool to wrangle but it's entirely possible to use it safely.