Live data from Hacker News

AI is forcing us to write good code

bits.logic.inc

151–160 of 229 posts

Re: AI is forcing us to write good code

#151

Earlier quoted context omitted.

I think the phase change hypothesis* is a bit wrong. I think it happens not at 100% coverage but at, say, 100% MC/DC test coverage. This is what SQLite and avionics software aim for. *has not been confirmed by a peer-reviewed research.

What's MC/DC?

Modified Condition/Decision Coverage

It's mandated by DO-178C for the highest-level (Level A) avionics software.

Example: if (A && B || C) { ... } else { ... } needs individual tests for A, B, and C.

Test #,A,B,A && B,Outcome taken,Shows independence for

1,True,True,True,if branch,(baseline true)

2,False,True,False,else branch,A (A flips outcome while B fixed at True)

3,True,False,False,else branch,B (B flips outcome while A fixed at True)

Re: AI is forcing us to write good code

#152

Earlier quoted context omitted.

I think the phase change hypothesis* is a bit wrong. I think it happens not at 100% coverage but at, say, 100% MC/DC test coverage. This is what SQLite and avionics software aim for. *has not been confirmed by a peer-reviewed research.

What's MC/DC?

Modified Condition/Decision Coverage (MC/DC) is a test coverage approach that considers a chunk of code covered if:

- Every branch was "visited". Plain coverage already ensures that. I would actually advocate for 100% branch coverage before 100% line coverage.

- Every part (condition) of a branch clause has taken all possible values. If you have if(enabled && limit > 0), MC/DC requires you to test with enabled, !enabled, limit >0, limit - Every change to the condition was shown to somehow change the outcome. (false && limit > 0) would not pass this, a change to the limit would not affect the outcome - the decision is always false. But @zweifuss has a better example.

- And, of course, every possible decision (the outcome of the entire 'enabled && limit > 0') needs to be tested. This is what ensures that every branch is taken for if statements, but also for switch statements that they are exhaustive etc.

MC/DC is usually required for all safety-critical code as per NASA, ESA, automotive (ISO 26262) and industrial (IEC 61508).

Re: AI is forcing us to write good code

#153
post #44

This is sort of why I think software development might be the only real application of LLMs outside of entertainment. We can build ourselves tight little feedback loops that other domains can't. I somewhat frequently agree on a plan with an LLM and a few minutes or hours later find out it doesn't work and then the LLM is like "that's why we shouldn't have done it like that!". Imagine building a house from scratch and…

I don't understand why the experience you describe would lead you to conclude that LLMs might be useful for software development.

The response "that's why we shouldn't have done it like that!" sounds like a variation on the usual "You're absolutely right! I apologize for any confusion". Why would we want to get stuck in a loop where an AI produces loads of absolute nonsense for us to painstakingly debug and debunk, after which the AI switches track to some different nonsense, which we again have debug and debunk, and so on. That doesn't sound like a good loop.

Re: AI is forcing us to write good code

#154
post #143
post #134

There's a catch with 100% coverage. If the agent writes both the code and the tests, we risk falling into a tautology trap. The agent can write flawed logic and a test that verifies that flawed logic (which will pass). 100% coverage only makes sense if tests are written before the code or rigorously verified by a human. Otherwise, we're just creating an illusion of reliability by covering hallucinations with tests. A…

Well, we let humans write both business logic code and tests often enough, too. Btw, you can get a lot further in your tests, if you move away from examples, and towards properties.

Can you give an example (pun not intended) of testing with properties?

Re: AI is forcing us to write good code

#155
post #134

There's a catch with 100% coverage. If the agent writes both the code and the tests, we risk falling into a tautology trap. The agent can write flawed logic and a test that verifies that flawed logic (which will pass). 100% coverage only makes sense if tests are written before the code or rigorously verified by a human. Otherwise, we're just creating an illusion of reliability by covering hallucinations with tests. A…

You could mitigate that risk by using different agents (versions, companies).

Re: AI is forcing us to write good code

#156
post #44

This is sort of why I think software development might be the only real application of LLMs outside of entertainment. We can build ourselves tight little feedback loops that other domains can't. I somewhat frequently agree on a plan with an LLM and a few minutes or hours later find out it doesn't work and then the LLM is like "that's why we shouldn't have done it like that!". Imagine building a house from scratch and…

> This is sort of why I think software development might be the only real application of LLMs outside of entertainment. Wow. What about also, I don't know, self-teaching*? In general, you have to be very arrogant to say that you've experienced all the "real" applications. * - For instance, today and yesterday, I've been using LLMs to teach myself about RLC circuits and "inerters".

It’s somewhat delusional and potentially dangerous to assume that chatting with an LLM about a specific topic is self-teaching beyond the most surface-level understanding of a topic. No doubt you can learn some true things, but you’ll also learn some blatant falsehoods and a lot of incorrect theory. And you won’t know which is which.

One of the most important factors in actually learning something is humility. Unfortunately, LLM chatbots are designed to discourage this in their users. So many people think they’re experts because they asked a chatbot. They aren’t.

Re: AI is forcing us to write good code

#158
post #116

Earlier quoted context omitted.

> people are very annoyed with Apple pushing for signing off the resulting product. Apple is very much welcome to push for signing off of software that appears on their own store. That is nothing new. What people are annoyed about is Apple insisting that you can only use their store, a restriction that has nothing to do with safety or quality and everything to do with the stupendous amounts of money they make from it…

It's literally the case of Apple requiring signing the binary to run on the platforms they provide, Apple doesn't have say on other platforms. It is a very similar situation with local governments. Also, people complain all the time about rules and regulations for making stuff. Especially in EU, you can't just create products however you like and let people decide if it is safe to use, you are required to make your p…

[deleted]

Re: AI is forcing us to write good code

#159
post #116

Earlier quoted context omitted.

> people are very annoyed with Apple pushing for signing off the resulting product. Apple is very much welcome to push for signing off of software that appears on their own store. That is nothing new. What people are annoyed about is Apple insisting that you can only use their store, a restriction that has nothing to do with safety or quality and everything to do with the stupendous amounts of money they make from it…

It's literally the case of Apple requiring signing the binary to run on the platforms they provide, Apple doesn't have say on other platforms. It is a very similar situation with local governments. Also, people complain all the time about rules and regulations for making stuff. Especially in EU, you can't just create products however you like and let people decide if it is safe to use, you are required to make your p…

> Maybe in the future if your software leaks sensitive information for example, you may end up being investigated and fined

This is already the case in the UK, and the EU too as far as I’m aware.

Re: AI is forcing us to write good code

#160
post #134

There's a catch with 100% coverage. If the agent writes both the code and the tests, we risk falling into a tautology trap. The agent can write flawed logic and a test that verifies that flawed logic (which will pass). 100% coverage only makes sense if tests are written before the code or rigorously verified by a human. Otherwise, we're just creating an illusion of reliability by covering hallucinations with tests. A…

All the problems you list are true, but the solutions not so much.

I've seen this problem with humans even back at university when it was the lecturer's own example attempting to illustrate the value of formal methods and verification.

I would say the solution is neither "get humans to do it" nor "do it before writing code", but rather "get multiple different minds involved to check each other's blind spots, and no matter how many AI models you throw at it they only count as one mind even when they're from different providers". Human tests and AI code, AI tests and human code, having humans do code reviews of AI code or vice-versa, all good. Two different humans usually have different blind spots, though even then I've seen some humans bully their way into being the only voice in the room with the full support of their boss, not that AI would help with that.

Post reply on HN