4 ms·

I find that highly unlikely, coding is the AIs best value use case by far. Right now office workers see marginal benefits but it's not like it's an order of mag

I find that highly unlikely, coding is the AIs best value use case by far. Right now office workers see marginal benefits but it's not like it's an order of magnitude difference. AI drafts an email, you have to check and edit it, then send it. In many cases it's a toss up if that actually saved time, and then if it did, it's not like the pace of work is break neck anyway, so the benefit is some office workers have a bit more idle time at the desk because you always tap some wall that's out of your control. Maybe AI saves you a Google search or a doc lookup here and there. You still need to check everything and it can cause mistakes that take longer too. Here's an example from today. Assistant is dispatching a courier to get medical records. AI auto completes to include the address. Normally they wouldn't put the address, the courier knows who we work with, but AI added it so why not. Except it's the wrong address because it's for a different doctor with the same name. At least they knew to verify it, but still mistakes like this happening at scale is making the other time savings pretty close to a wash.

nradov 8mo ago
LLMs might not save time but they certainly increase quality for at least some office work. I frequently use it to check my work before sending to colleagues or customers and it occasionally catches gaps or errors in my writing.
- toraway 8mo ago
  But that idealized example could also be offset by another employee who doubles their own output by churning out lower-quality unreviewed workslop all day without checking anything, while wasting other people's time.
  - sunrunner 8mo ago
    Something I call the 'Generate First, Review Never' approach, seemingly favoured by my colleagues, and which has the magical quality of increasing the overall amount of work done through an increased amount of time taken by N receivers of low-quality document having to review, understand and fact check said document. See also: AI-Generated “Workslop” Is Destroying Productivity [1] [1] https://hbr.org/2025/09/ai-generated-workslop-is-destroying-productivity https://hbr.org/2025/09/ai-generated-workslop-is-destroying-...
  - bartread 8mo ago
    Yeah, but that's no different from any other aspect of office work, and more conventional forms of automation. Gains by one person are often offset to some extent by the laziness, inattentiveness, or ineptitude of others. What AI has done is accelerate and magnify both the positives and the negatives.
sanex 8mo ago
Not all code generates economic value. See slacks, jiras, etc constant ui updates.
- fakedang 8mo ago
  That makes it a perfect use case for AI, since now you don't need a dev for that. Any devs doing that would, imo, be effectively performing one of David Graeber's bullshit jobs.
- cucumber3732842 8mo ago
  High quality code that does exactly what it needs to do and well and that makes various actors and organizations far more efficient at their jobs... but their jobs are of negative economic value overall.
majormajor 8mo ago
Coding is a relatively verifiable and strict task: it has to pass the compiler, it has to pass the test suite, it has to meet the user's requests. There are a lot of white-collar tasks that have far lower quality and correctness bars. "Researching" by plugging things into google. Writing reports summarizing how a trend that an exec saw a report on can be applied to the company. Generating new values to share at a company all-hands. Tons of these that never touch the "real world." Your assistant story is like a coding task - maybe someone ran some tests, maybe they didn't, but it was verifiable. No shortage of "the tests passed, but they weren't the right test, this broke some customers and had to be fixed by hand" coding stories out there like it. There are pages and pages of unverifiable bullshit that people are sleepwalking through, too, though. Nobody already knows if those things helped or hurt, so nobody will ever even notice a hallucination. But everyone in all those fields is going to be trying really really hard to enumerate all the reasons it's special and AI won't work well for them. The "management says do more, workers figure out ways to be lazier" see-saw is ancient, but this could skew far towards "management demands more from fewer people" spectrum for a while.
- t43562 8mo ago
  Code may have to compile but that's a lowish bar and since the AI is writing the tests it's obvious that they're going to pass. In all areas where there's less easy ways to judge output there is going to be correspondingly more value to getting "good" people. Some AI that can produce readable reports isn't "good" - what matters is the quality of the work and the insight put into it which can only be ensured by looking at the workers reputation and past history.
  - naasking 8mo ago
    > since the AI is writing the tests it's obvious that they're going to pass That's not obvious at all if the AI writing the tests is different than the AI writing the code being tested. Put into an adversarial and critical mode, the same model outputs very different results.
    - disiplus 8mo ago
vrighter 8mo ago
Code is much much harder to check for errors than an email. Consider, for example, the following python code: x = (5) vs x = (5,) One is a literal 5, and the other is a single element tuple containing the number 5. But more importantly, both are valid code. Now imagine trying to spot that one missing comma among the 20kloc of code one so proudly claims AI helped them "write", especially if it's in a cold path. You won't see it.
- lock1 8mo ago
  > Code is much much harder to check for errors than an email. Disagree. Even though performing checks on dynamic PLs is much harder than on static ones, PLs are designed to be non-ambiguous. There should be exactly 1 interpretation for any syntactically valid expression. Your example will unambiguously resolve to an error in a standard-conforming Python interpreter. On the other hand, natural languages are not restricted by ambiguity. That's why something like Poe's law exists. There's simply no way to resolve the ambiguity by just staring at the words themselves, you need additional information to know the author's intent. In other words, an "English interpreter" cannot exist. Remove the ambiguities, you get "interpreter" and you'll end up with non-ambiguous, Python-COBOL-like languages. With that said, I agree with your point that blindly accepting 20kloc is certainly not a good idea.
  - vrighter 8mo ago
    Tell me you've never written any python without telling me you've never written any python... Those are both syntactically valid lines of code. (it's actually one of python's many warts). They are not ambiguous in any way. one is a number, the other is a tuple. They return something of a completely different type. My example will unambiguously NOT give an error because they are standard conforming. Which you would have noticed had you actually took 5 seconds to try typing them in the repl.
    - lock1 8mo ago
      > Those are both syntactically valid lines of code. (it's actually one of python's many warts). They are not ambiguous in any way. one is a number, the other is a tuple. They return something of a completely different type. You just demonstrated how hard it is to "check" an email or text message by missing the point of my reply. > "Now imagine trying to spot that one missing comma among the 20kloc of code" I assume your previous comment tries to bring up Python's dynamic typing & late binding nature and use it as an example of how it can be problematic when someone tries to blindly merge 20kloc LLM-generated Python code. My reply, "Your example will unambiguously resolve to an error in a standard-conforming Python interpreter." tried to respond to the possibility of such an issue. Even though it's probably not the program behavior you want, Python, being a programming language, will be 100% guaranteed to interpret it unambiguously. I admit, I should have phrased it a bit more unambiguously than leaving it like that. Even if it's hard, you can try running a type checker to statically catch such problems. Even if it's not possible in cases of heavy usage of Python's dynamic typing feature, you can just run it and check the behavior at runtime. It might be hard to check, but not impossible. On the other hand, it's impossible to perform a perfectly consistent "check" on this reply or an email written in a natural language, the person reading it might interpret the message in a completely different way.

nradov 8mo ago

LLMs might not save time but they certainly increase quality for at least some office work. I frequently use it to check my work before sending to colleagues or customers and it occasionally catches gaps or errors in my writing.

toraway 8mo ago
But that idealized example could also be offset by another employee who doubles their own output by churning out lower-quality unreviewed workslop all day without checking anything, while wasting other people's time.
- sunrunner 8mo ago
  Something I call the 'Generate First, Review Never' approach, seemingly favoured by my colleagues, and which has the magical quality of increasing the overall amount of work done through an increased amount of time taken by N receivers of low-quality document having to review, understand and fact check said document. See also: AI-Generated “Workslop” Is Destroying Productivity [1] [1] https://hbr.org/2025/09/ai-generated-workslop-is-destroying-productivity https://hbr.org/2025/09/ai-generated-workslop-is-destroying-...
- bartread 8mo ago
  Yeah, but that's no different from any other aspect of office work, and more conventional forms of automation. Gains by one person are often offset to some extent by the laziness, inattentiveness, or ineptitude of others. What AI has done is accelerate and magnify both the positives and the negatives.

sanex 8mo ago

Not all code generates economic value. See slacks, jiras, etc constant ui updates.

fakedang 8mo ago
That makes it a perfect use case for AI, since now you don't need a dev for that. Any devs doing that would, imo, be effectively performing one of David Graeber's bullshit jobs.
cucumber3732842 8mo ago
High quality code that does exactly what it needs to do and well and that makes various actors and organizations far more efficient at their jobs... but their jobs are of negative economic value overall.

majormajor 8mo ago

Coding is a relatively verifiable and strict task: it has to pass the compiler, it has to pass the test suite, it has to meet the user's requests. There are a lot of white-collar tasks that have far lower quality and correctness bars. "Researching" by plugging things into google. Writing reports summarizing how a trend that an exec saw a report on can be applied to the company. Generating new values to share at a company all-hands. Tons of these that never touch the "real world." Your assistant story is like a coding task - maybe someone ran some tests, maybe they didn't, but it was verifiable. No shortage of "the tests passed, but they weren't the right test, this broke some customers and had to be fixed by hand" coding stories out there like it. There are pages and pages of unverifiable bullshit that people are sleepwalking through, too, though. Nobody already knows if those things helped or hurt, so nobody will ever even notice a hallucination. But everyone in all those fields is going to be trying really really hard to enumerate all the reasons it's special and AI won't work well for them. The "management says do more, workers figure out ways to be lazier" see-saw is ancient, but this could skew far towards "management demands more from fewer people" spectrum for a while.

t43562 8mo ago
Code may have to compile but that's a lowish bar and since the AI is writing the tests it's obvious that they're going to pass. In all areas where there's less easy ways to judge output there is going to be correspondingly more value to getting "good" people. Some AI that can produce readable reports isn't "good" - what matters is the quality of the work and the insight put into it which can only be ensured by looking at the workers reputation and past history.
- naasking 8mo ago
  > since the AI is writing the tests it's obvious that they're going to pass That's not obvious at all if the AI writing the tests is different than the AI writing the code being tested. Put into an adversarial and critical mode, the same model outputs very different results.
  - disiplus 8mo ago

vrighter 8mo ago

Code is much much harder to check for errors than an email. Consider, for example, the following python code: x = (5) vs x = (5,) One is a literal 5, and the other is a single element tuple containing the number 5. But more importantly, both are valid code. Now imagine trying to spot that one missing comma among the 20kloc of code one so proudly claims AI helped them "write", especially if it's in a cold path. You won't see it.

lock1 8mo ago
> Code is much much harder to check for errors than an email. Disagree. Even though performing checks on dynamic PLs is much harder than on static ones, PLs are designed to be non-ambiguous. There should be exactly 1 interpretation for any syntactically valid expression. Your example will unambiguously resolve to an error in a standard-conforming Python interpreter. On the other hand, natural languages are not restricted by ambiguity. That's why something like Poe's law exists. There's simply no way to resolve the ambiguity by just staring at the words themselves, you need additional information to know the author's intent. In other words, an "English interpreter" cannot exist. Remove the ambiguities, you get "interpreter" and you'll end up with non-ambiguous, Python-COBOL-like languages. With that said, I agree with your point that blindly accepting 20kloc is certainly not a good idea.
- vrighter 8mo ago
  Tell me you've never written any python without telling me you've never written any python... Those are both syntactically valid lines of code. (it's actually one of python's many warts). They are not ambiguous in any way. one is a number, the other is a tuple. They return something of a completely different type. My example will unambiguously NOT give an error because they are standard conforming. Which you would have noticed had you actually took 5 seconds to try typing them in the repl.
  - lock1 8mo ago
    > Those are both syntactically valid lines of code. (it's actually one of python's many warts). They are not ambiguous in any way. one is a number, the other is a tuple. They return something of a completely different type. You just demonstrated how hard it is to "check" an email or text message by missing the point of my reply. > "Now imagine trying to spot that one missing comma among the 20kloc of code" I assume your previous comment tries to bring up Python's dynamic typing & late binding nature and use it as an example of how it can be problematic when someone tries to blindly merge 20kloc LLM-generated Python code. My reply, "Your example will unambiguously resolve to an error in a standard-conforming Python interpreter." tried to respond to the possibility of such an issue. Even though it's probably not the program behavior you want, Python, being a programming language, will be 100% guaranteed to interpret it unambiguously. I admit, I should have phrased it a bit more unambiguously than leaving it like that. Even if it's hard, you can try running a type checker to statically catch such problems. Even if it's not possible in cases of heavy usage of Python's dynamic typing feature, you can just run it and check the behavior at runtime. It might be hard to check, but not impossible. On the other hand, it's impossible to perform a perfectly consistent "check" on this reply or an email written in a natural language, the person reading it might interpret the message in a completely different way.