← Back to context

Comment by throw-the-towel

2 days ago

> People who acknowledge the quality problem, but think they can deal with it by applying more AI to the output.

Brute Force: if it doesn't work, you're just not using enough.

What if they're right though?

It does not have to be brushed away as "brute force" necessarily. We can, and do, build more reliable systems out of less reliable components. In fact, most industrial engineering accepts some defect rate and builds margins around it.

Software is no different. Even without AI, you already have buggy compilers and buggy OSes and buggy libraries. You just tend to accept the risk because you have some idea of what the failure modes are and can work around it or manage the risk in some other way (buy literal insurance.)

  • > you already have buggy compilers and buggy OSes and buggy libraries.

    Which run, I must add, on effectively infallible hardware. Most of the software straight up assumes that the CPUs and the RAM will function perfectly and don't bother even trying to detect such failures (unless those failures manifest themselves in a catastrophic manner, the show will simply go on).

    So in effect, we also can, and do, build less reliable systems out of more reliable components, and that's how software is different.

    • >Which run, I must add, on effectively infallible hardware.

      Keyword: effective. Hardware is also built on top of components with error tolerances. What do you think ECC memory is for? Or why chips have "yields" and parts that were "turned off" while shipping? Or how thermal throttling happens? Or CPU clocks, which have jitter to be corrected, and tons of other examples, all the way to transistors and capacitors.

      And let's not even get into HDs and SSDs.

      2 replies →

    • I am not sure if I correctly understood your point. On one dimension, you are basically hinting at another anecdote that proves my point: hardware failure (specifically bit flip in non-ECC memory) is pretty much guaranteed to happen at scale, but people are mostly okay with absorbing that risk. I feel you are overselling the hardware reliability story. For sure, we can build less reliable systems out of reliable components. That goes without saying, and no, that's definitely not software specific. Almost by default most composite systems are less reliable than their primitives (simple example would be nailing two pieces of wood) unless specific care is taken to build in those guardrails or redundancies. The point, however, is it is possible, and there is a vast precedent for it.

    • You should talk to an electrical engineer or materials scientist about how reliable transistors emerge from noisy voltages in wires.

There are other places where some process has an error rate and you make up for that error rate by doing the work more than once and then comparing results. For example, I've heard in a video that satellites and other space craft often have 3 or 4 processors and compare the results to make sure there were no errors due to radiation. Similarly, we have RAID arrays that store data multiple times because disks can fail. So, even if AI has a failure rate of like 20%, maybe you can make up for that by running the same prompt multiple times with slight variations or with different models, comparing the results and choosing the best.

I've seen it turn right in business contexts. Sometimes you can even lower your standard of "good enough" and find quantity has a quality all its own.

But it requires taste and engineering to do it right, and on the right things. It'll be an interesting few years.

  • I think it also requires someone who knows just enough to be able to navigate between those ideas that will set you back and those which will propel you forward. At the end of the day, you still need some human filter.

they are right. bad output is user error. there, am i suiting the role appropriately? i do like 65% believe that, fwiw.