| It doesn't really matter. The point is, new technology arrived that allowed developers to do much more. Existing programmers hemmed and hawed about it because it threatened their egos, making easy what they once found very difficult. But the sensible engineers adopted the technology. AI may not be deterministic, but on small to medium-sized tasks it produces more correct code, more reliably, faster than a human developer does. By any objective measure, not adopting it is professional irresponsibility. |
| |
| ▲ | bigstrat2003 4 hours ago | parent | next [-] | | Nice rhetorical sleight of hand, trying to paint your opponents as ego-driven and senseless. But LLMs are not compilers. They cannot be relied upon to work correctly, and indeed can be relied upon to introduce bugs that a human would never introduce. The situation is different, therefore the reactions are different. > AI may not be deterministic, but on small to medium-sized tasks it produces more correct code, more reliably, faster than a human developer does. That is not remotely true. | |
| ▲ | skydhash 4 hours ago | parent | prev | next [-] | | > AI may not be deterministic, but on small to medium-sized tasks it produces more correct code, more reliably, faster than a human developer does. By any objective measure, not adopting it is professional irresponsibility. How do you define correctness for any given task? If you know the correct logical process for any given process, writing it in code is just a matter of typing. The issue is that the human author, even when assisted by AI tools, does not know what is the correct algorithm for the task. In most cases, the output is probable code, not correct code. | |
| ▲ | teiferer 4 hours ago | parent | prev [-] | | I believe we are at a crossroads here. The key question is: Do we want (desire or require) humans to understand the implementation? If the answer is no, then AI agents producing code faster and "more correct" (in some arguably questionable sense but let's fly with the assumption for a moment) should be embraced fully. Take the humans out of the loop, why review code, if there is a problem later then just ask the next AI agent to fix it. Similar to not looking at generated code by a compiler. Iterate fast, don't look back. Some code bases and some entire companies have adopted this view. If the answer is yes then we need to keep the human in the loop, ensure they have enough understanding to maintain the thing, review all the code etc. AI is just another tool to produce the code which ultimately the human still owns. Many code bases follow this philosophy. It seems to me that the discussion always ultimately falls on one of these two sides. They are incompatible but you need to pick one. Depending on which you pick, it is easy to predict how you argue in such discussions. | | |
| ▲ | skydhash 3 hours ago | parent [-] | | > The key question is: Do we want (desire or require) humans to understand the implementation? Understanding the implementation is not the root cause here. The actual issue is that all software are built for a particular needs which is human related. In most software, the cost mostly decays to a constant value unless that need has changed or an external event has occurred. Embracing AI fully is keeping the software in constant flux as it can’t guarantee it will actually follow the requirements and the platform specs. Any prompt has a non zero chance to introduce regressions and breaking changes, disrupting the workflow of the users. The tools to write the code does not matter to the user just like the hammer does not matter to the person that needs a home. But if your tools results in a badly constructed house that always needs repair and what not, expect complaints. | | |
| ▲ | teiferer an hour ago | parent [-] | | > Embracing AI fully is keeping the software in constant flux as it can’t guarantee it will actually follow the requirements and the platform specs. Any prompt has a non zero chance to introduce regressions and breaking changes, disrupting the workflow of the users. You can pin down existing expected behavior pretty well with automated test cases and even bringing formal verification into the mix. Using LLMs to create those, it's not even a major cost factor. Then you are safe from such regressions. Just like when humans make changes. So, I don't see how this is introducing a difference. > The tools to write the code does not matter to the user just like the hammer does not matter to the person that needs a home. But if your tools results in a badly constructed house that always needs repair and what not, expect complaints. Indeed. Though I don't see the connection to my point. |
|
|
|
