Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When AI writes the software, who verifies it?

leodemoura.github.io

Post reply on HN
Print view View original

291–300 of 309 posts

Re: When AI writes the software, who verifies it?

#291

Post by GuB-42 »

9rx wrote: post #286
GuB-42 wrote: post #284

Earlier quoted context omitted.

Tests are not any more or any less of a spec than the code. If you are implementing a HTTP server for instance, RFC 7231 are your specs, not your tests, not your code. I would say that which come first between specs and code depend on the context. If you are implementing a standard, the specs of the standard obviously come first, but if you are iterating, maybe for a user interface, it can make sense to start with th…

> RFC 7231 are your specs It is more like a meta spec. You still have to write a final spec that applies to your particular technical constraints, business needs, etc. RFC 7231 specifies the minimum amount necessary to interface with the world, but an actual program to be deployed into the wild requires much, much more consideration. And for that, since you have the full picture not available to a meta spec, logicall…

> The much more likely scenario is that the code is right, but a mistake in the test leads it to not test anything.

What I usually do to prevent this situation is to write a passing test, then modify the code to make it fail, then revert the change. It also gives an occasion to read the code again, kind of like a review.

I have never seen this practice formalized though, good for me, this is the kind of things I do because I care, turning it into a process with Jira and such is a good way to make me stop caring.

Re: When AI writes the software, who verifies it?

#292

Post by HWR_14 »

roadbuster wrote: post #139

> The Claude C Compiler illustrates the other side: it optimizes for > passing tests, not for correctness. It hard-codes values to satisfy > the test suite. It will not generalize. This is one of the pain points I am suffering at work: workers ask coding agents to generate some code, and then to generate test coverage for the code. The LLM happily churns out unit tests which are simply reinforcing the existing behavi…

> The icing on the cake is that LLMs are producing so much code that humans are just rubber stamping all of it.

I don't understand the value of that much code. What features are worth that much more than stability?

Re: When AI writes the software, who verifies it?

#296

Post by 9rx »

GuB-42 wrote: post #291
9rx wrote: post #286

Earlier quoted context omitted.

> RFC 7231 are your specs It is more like a meta spec. You still have to write a final spec that applies to your particular technical constraints, business needs, etc. RFC 7231 specifies the minimum amount necessary to interface with the world, but an actual program to be deployed into the wild requires much, much more consideration. And for that, since you have the full picture not available to a meta spec, logicall…

> The much more likely scenario is that the code is right, but a mistake in the test leads it to not test anything. What I usually do to prevent this situation is to write a passing test, then modify the code to make it fail, then revert the change. It also gives an occasion to read the code again, kind of like a review. I have never seen this practice formalized though, good for me, this is the kind of things I do b…

> I have never seen this practice formalized though

Isn't that what is oft known as mutation testing? It is formalized to the point that we have automation to do the mutation for you automatically.

Re: When AI writes the software, who verifies it?

#297

Post by GuB-42 »

9rx wrote: post #296
GuB-42 wrote: post #291

Earlier quoted context omitted.

> The much more likely scenario is that the code is right, but a mistake in the test leads it to not test anything. What I usually do to prevent this situation is to write a passing test, then modify the code to make it fail, then revert the change. It also gives an occasion to read the code again, kind of like a review. I have never seen this practice formalized though, good for me, this is the kind of things I do b…

> I have never seen this practice formalized though Isn't that what is oft known as mutation testing? It is formalized to the point that we have automation to do the mutation for you automatically.

Thank you, I wasn't aware of this, this is the kind of thing I wish people were more aware of, kind of like fuzzing, but for tests.

About fuzzing, I have about 20 years of experience in development and I have never seen fuzzing being done as part of a documented process in a project I worked in, not even once. Many people working in validation don't even know that it exists! The only field where fuzzing seems to be mainstream is cybersecurity, and most fuzzing tools are "security oriented", which is nice but it doesn't mean that security is the only field where it is useful.

Anyways, what I do is a bit different in that it is not random like fuzzing, it is more like reverse-TDD. TDD starts with a failing test, then, you write code to pass the test, and once done, you consider the code to be correct. Here you start with a passing test, then, you write code to fail the test, and once done, you consider the test to be correct.

Re: When AI writes the software, who verifies it?

#298

Post by salawat »

roadbuster wrote: post #139

> The Claude C Compiler illustrates the other side: it optimizes for > passing tests, not for correctness. It hard-codes values to satisfy > the test suite. It will not generalize. This is one of the pain points I am suffering at work: workers ask coding agents to generate some code, and then to generate test coverage for the code. The LLM happily churns out unit tests which are simply reinforcing the existing behavi…

Mwahahahahaha! Suffer, devs, SUFFER! KNOW MY PAIN!

Ah hem... Welcome to the wonderful world of Quality Assurance, software developing audience. That part of the job, after you yeet your code over the fence, where the job is to bridge the gap between your madness, and the madness of the rest of the business. Here you will find: frustration, an ever present sense the rest of the world is just out to make your life more difficult, a creeping sense of despair, a hot ice pick in the back of your mind every time the language model does something syntactically valid, but completely nonsensical in the real world, the development of an ever increasing time horizon over which you can accurately predict the future, but no one will believe you anyway, a smoldering hatred of the overly confident executive with an over developed capacity for risk tolerance; a desire to run away and start a farm, and finally, a fundamental distrust of everything software, and all the people who write it.

Don't forget your complimentary test framework and swag bag on your way out, and remember, you're here forever. You can try to check out, but you can never leave.

Post reply on HN