4 ms·

We’re perhaps talking about very different levels of ‘programming’. Just in the sense of ‘expressing what you want a computer to do’, Think about a thing someo

We’re perhaps talking about very different levels of ‘programming’. Just in the sense of ‘expressing what you want a computer to do’, Think about a thing someone needs to do in an office somewhere. ‘Get all the data from the excel file attached to this email, find the CRM record for each company listed and make a list of the ones whose data needs updating’. That’s the kind of thing you can ask John in accounting to spend a day doing. Or you can write a script. Try to express in precise unambiguous code exactly how you want to accomplish it and spend a couple of days debugging it. Or you can ask an LLM with some tool access to do it and maybe it’ll give you a list in a few minutes. And if you need to do that same task every week: either John gets good at doing it, or he gets bored and quits; if you made a script you have to keep bug fixing it and dealing with the changes in the excel file, and eventually someone tells you that it really needs to be implemented in The System so you file a Jira ticket and a product owner comes out and writes down your user story and six months later you get a web form you can upload your excel attachments to that sometimes produces the list of clients to update… But if you asked the LLM to do it… you just ask it do it again the next week. This is the bit that maybe programmers haven’t quite realized yet: if I can get an LLM to just do that task, I don’t need to go and get someone to build some software to do it. I can get the computer to do it myself.

SoftTalker 3y ago
Yes, the LLM will give you an answer. Are you verifying that what the LLM tells you is correct? How would you even know?
- taneq 3y ago
  Same goes for John though, doesn't it?
  - SoftTalker 3y ago
    Yes, it does, but John is the subject matter expert and is at least in theory able to verify that the results are correct.
    - jameshart 3y ago
      No, John is four years from retirement and he sometimes doesn’t sleep that well. He has a lot on his mind what with the layoffs recently. Maybe you got him on a good day though.
  - marcosdumay 3y ago
    A random John has a much better track record of getting the result right instead of making it all up. And you can tell John to be extra careful (in fact, if he has a bit of experience, you won't have to tell this either) and he will be. While if you tell the LLM to be extra careful, it may track intermediate steps better or just make some other answer up. And yeah, this is very likely intrinsic to the architecture we use on our LLMs.
  - MrJohz 3y ago
    This is true, and a good reason why automation is so valuable. It's not just the speed, but also the reproducibility. If the script goes wrong, it will go wrong in a predictable way that can be investigated and debugged. If John goes wrong, he will go wrong sporadically and without any clear reason - maybe he was tired one day, or maybe he got an important phone call in the middle of the task another. With AI (or at least the versions of it that we're looking at today) we get the speed of a script with the "programmability" of a person, but the question still remains what sort of failure mode we can expect - predictable like a script, or unpredictable like a person. Right now, it's looking like LLM failures tend to be fairly unpredictable (in the sense that a prompt can give a good response one day and a bad one the next based on difficult-to-explain factors).
brokenkebaby 3y ago
The part about script is very stretched, let's face it. I'm not denying that asking in natural-ish language maybe more comfortable for some operations, but when something becomes repetitive (and most things people do for money are) a script run hands down wins over telling the same phrase everyday
JohnBooty 3y ago
This is the bit that maybe programmers haven’t quite realized yet: if I can get an LLM to just do that task, I don’t need to go and get someone to build some software to do it. I think everybody understands that part, and that the cynicism/skepticism is about LLMs' ability to deliver on that aspect of it. Part of training John, or writing a script, or telling an LLM, is handling all of the edge cases that exist in even a "simple" import job. - What to do if there is a duplicate record? Create a dupe? Do an upsert? If data conflicts how we decide which version "wins?" - What about fuzzy dupes? Two records that are probably identical but not really the same, probably due to typos or slightly different accent characters, etc - "find the CRM record for each company listed" <-- okay, and what if the record doesn't exist? fail? - Is the import job an all-or-nothing thing? In other words should we wrap everything in a transaction and back it out if there's a single failure? Or do we keep going? Do we log failures? Email somebody? - If we're wrapping the whole job in a transaction, should we lock out the users while this is happening so they don't see stale data? Do we notify them? Do we just do it in the middle of the night? - Should we log changes to an audit table for debugging purposes? - What if the import file is invalid? Do we log, email, etc? etc etc etc. Like Visual Basic, Excel macros, etc I think LLM will enable some non-programmers to do scripty, programmery stuff and I think that is excellent. But anything really robust (and honestly, "simple" import jobs are often critical path and therefore need to be fairly robust) is going to require some rigor. A person telling LLM what to do is still going to need to address all of those edge cases and then some. It's also very unclear to me how we'll debug LLM-managed processes. When things go wrong, how do we determine what/when/why? And in fact, how do we determine LLM-managed processes are correct in the first place? These particualr concerns seem completely solvable, but they will need to be solved.

SoftTalker 3y ago

Yes, the LLM will give you an answer. Are you verifying that what the LLM tells you is correct? How would you even know?

taneq 3y ago
Same goes for John though, doesn't it?
- SoftTalker 3y ago
  Yes, it does, but John is the subject matter expert and is at least in theory able to verify that the results are correct.
  - jameshart 3y ago
    No, John is four years from retirement and he sometimes doesn’t sleep that well. He has a lot on his mind what with the layoffs recently. Maybe you got him on a good day though.
- marcosdumay 3y ago
  A random John has a much better track record of getting the result right instead of making it all up. And you can tell John to be extra careful (in fact, if he has a bit of experience, you won't have to tell this either) and he will be. While if you tell the LLM to be extra careful, it may track intermediate steps better or just make some other answer up. And yeah, this is very likely intrinsic to the architecture we use on our LLMs.
- MrJohz 3y ago
  This is true, and a good reason why automation is so valuable. It's not just the speed, but also the reproducibility. If the script goes wrong, it will go wrong in a predictable way that can be investigated and debugged. If John goes wrong, he will go wrong sporadically and without any clear reason - maybe he was tired one day, or maybe he got an important phone call in the middle of the task another. With AI (or at least the versions of it that we're looking at today) we get the speed of a script with the "programmability" of a person, but the question still remains what sort of failure mode we can expect - predictable like a script, or unpredictable like a person. Right now, it's looking like LLM failures tend to be fairly unpredictable (in the sense that a prompt can give a good response one day and a bad one the next based on difficult-to-explain factors).

brokenkebaby 3y ago

The part about script is very stretched, let's face it. I'm not denying that asking in natural-ish language maybe more comfortable for some operations, but when something becomes repetitive (and most things people do for money are) a script run hands down wins over telling the same phrase everyday

JohnBooty 3y ago

This is the bit that maybe programmers haven’t quite realized yet: if I can get an LLM to just do that task, I don’t need to go and get someone to build some software to do it. I think everybody understands that part, and that the cynicism/skepticism is about LLMs' ability to deliver on that aspect of it. Part of training John, or writing a script, or telling an LLM, is handling all of the edge cases that exist in even a "simple" import job. - What to do if there is a duplicate record? Create a dupe? Do an upsert? If data conflicts how we decide which version "wins?" - What about fuzzy dupes? Two records that are probably identical but not really the same, probably due to typos or slightly different accent characters, etc - "find the CRM record for each company listed" <-- okay, and what if the record doesn't exist? fail? - Is the import job an all-or-nothing thing? In other words should we wrap everything in a transaction and back it out if there's a single failure? Or do we keep going? Do we log failures? Email somebody? - If we're wrapping the whole job in a transaction, should we lock out the users while this is happening so they don't see stale data? Do we notify them? Do we just do it in the middle of the night? - Should we log changes to an audit table for debugging purposes? - What if the import file is invalid? Do we log, email, etc? etc etc etc. Like Visual Basic, Excel macros, etc I think LLM will enable some non-programmers to do scripty, programmery stuff and I think that is excellent. But anything really robust (and honestly, "simple" import jobs are often critical path and therefore need to be fairly robust) is going to require some rigor. A person telling LLM what to do is still going to need to address all of those edge cases and then some. It's also very unclear to me how we'll debug LLM-managed processes. When things go wrong, how do we determine what/when/why? And in fact, how do we determine LLM-managed processes are correct in the first place? These particualr concerns seem completely solvable, but they will need to be solved.