Hacker News Reader

Comment by teiferer | Hacker News Reader

> 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.

View on HN

> You can pin down existing expected behavior pretty well with automated test

Test cases are sample based, they do not take care of the whole range of input and output. Type checking in the other hand are set based and sometimes the types are too coarse. In both instances, you need to carefully choose your axiomatic foundation, and if you can do that, that means you’re already aware of both programs and solution. As defining the problem is a major step in problem solving.

> Indeed. Though I don't see the connection to my point.

A lot of AI proponents are touting the tools as better hammers while purposely not saying anything about the house. You need to show how it can help with building a new house and not gush that it’s a new shape, different from all the other hammers in history.

So the focus on line of codes, number of PRs, all the harness talks,… is worth nothing if better software can’t be built.

> Test cases are sample based, they do not take care of the whole range of input and output.

Indeed, but they are not random or arbitrary. They are typically the inputs that matter, and if chosen carefully then they cover all interesting/relevant inputs from the vast space. If you want to make things water tight, you use formal verification like I mentioned earlier (of which type checking is just a lightweight variant, in a sense) but for general screwups that's not even necessary. If tests are chosen well then the code must be formed very weirdly to produce bugs that the tests would not find.

> They are typically the inputs that matter, and if chosen carefully then they cover all interesting/relevant inputs from the vast space.

The thing is you can have code that passes the tests, but are wrong for the general cases. With manual coding, you will have the knowledge that the code is about right, then add test cases to precisely check that intuition.

Like being aware that you used a linear function so as soon as 2 points in the test are ok, the code is right. But if you don’t read the code and have not noticed the quadratic function, your test cases will pass while the code is incorrect.

That's right. But isn't it conceivable that the entity (human or LLM) which adds a quadratic function also takes that into account? Oh, earlier it was a linear function so 2 test cases were enough, now it is quadratic and I need to add a test case, and all of that flags that something extraordinary might be going on requiring extra attention. At least we are already far removed from accidental screwups.

If anything then I would expect a human to be more susceptible to such an error than a coding agent. At least frommy experience from how they deal with (admittedly test-heavy) code bases.

(But again, if unsure, add a formal correctness proof for a few more extra tokens if that makes you sleep better at night.)

Reply on news.ycombinator.com