Hacker News Reader

Comment by y1n0 | Hacker News Reader

It's all about the test suite. The test suite becomes an executable specification, and the better the spec, the better the results you can get from AI.

View on HN

It's part of it but you need good systems thinking in order to write good tests. The kind of thinking which requires years of software engineering experience to acquire.

Also the architecture really matters now because a poor architecture will lead to more weird edge cases and require more exotic tests to plug all the holes.

The very first thing many people did with AI is start calling the automated tests it writes good enough to capture the desired behavior. Writing tests isn't a whole lot of fun for most, so now the thing that it is supposed to help ensure we're not evolving our software into piles of trash is, in fact, one of the most neglected parts of vibed out codebases.

It really isn't.

It's s about subpar models trained on subpar data doing subpar work.

The only reason why anyone takes it seriously is that we've had a glut of subpar developers for 30 years so it all balances out in the end.

No it really is about the test suite, and provably so. As another poster pointed out, speed is a superoptimization problem and the test suite provides the constraints. If the constraints are appropriately set, even a naive genetic algorithm will eventually improve the outcome over time, provided suitable mixing of the proposal scheme. LLMs provide measurably better proposals than naive approaches, so the entire chain is sound. The issue really is an inability to set appropriate constraints on what the user is looking for, and poor quantification of the multiple objectives one should try to balance in practice. What's great is that's a human problem. Diverting that to the models is obviously a disaster.

I agree that there has been a glut of subpar developers for years, and that has lowered the bar significantly. This is mostly because core values shifted. So let's keep our eyes on what really matters rather than acting elitist.

Tests do not prove the absence of bugs.

I hope you understand the context in which that was said. The point of that statement is that the only way to rigorously verify correctness of a program is by using formal methods. Those are often too difficult to achieve by humans, which is why there is an entire program of developing autoformalization using LLMs. You are supporting what I have said.

In practice, no one rigorously "proves" that their program works at present, and well-written tests do suffice. The definition of "well-written" here is circular, granted, but there isn't really an alternative. Even strong programmers should be writing high-quality testing suites.

Llms are great at converting natural language to a spec because that's a translation from one language to another.

Only a moron would then use them to code up that spec.

The test suite is the same thing as the code, just approached from the other side.

i want the code to do this --> write the code to do this

i want the code to do this --> write the tests to specify this

the hard part is not the code or the tests. it's knowing what 'this' is supposed to be, exactly.

if you have the code, it is trivial to write the tests that will perfectly test the code. if you have the tests, it is trivial to write the code that will perfectly pass the tests.

however, none of this has anything to do with whether the code or the tests are good, and having a bad version of one will not help you write a good version of the other.

It doesn't sound very intelligent to just brute force iterate until you pass all the tests. This sounds like what Rich Hickey called "bashing into the guard rails". Even if we assume the tests suite is perfect and will guide the model to a correct solution, maybe this is one case we really should just say "LLM" rather than "AI".

How do you write a spec for correctness? Only the small and unimpressive programs can be checked exhaustively.

Not true at all! Most of the HTTP APIs, and a good chunk of the webapps, that I've worked on can be defined as a combination of an API spec that carves out valid and invalid behaviors, and a set of behavioral tests for the workflows that the client users care about. Working from a codebase which is generated from a spec document (e.g. OpenAPI or gRPC) and use of tools like https://pkg.go.dev/net/http/httptest and https://bun.com/docs/test/dom makes this a pretty achievable goal in practice.

> Only the small and unimpressive programs can be checked exhaustively.

Even if you assume that statement is true, there are techniques other than exhaustive checking/model checking. Proof assistants/theorem provers/etc. like Rocq/Isabelle/Lean are quite capable of formally verifying programs without needing to exhaustively explore the search space.

I'd question the accuracy of that statement in general as well; model checkers like CBMC/TLA+ are handy for proving properties about interesting systems. The latter, for example, sees use for verifying concurrent/distributed systems, which I think can be reasonably described as more than "small and unimpressive"

You can formally prove the correctness of even massive programs.

It's all now about money extraction from the areas dependant on software, not the sofrware itself.

If you have such a test suite then you really don't need AI to write the code for you.

Writing a benchmark test is about 100x to 1000x easier than writing optimizations. A benchmark test can be as simple as:

    func Benchmark(b *testing.B) {
      for range b.N {
        runCodeUnderBenchmark()
      }
    }

Actually optimizing the runCodeUnderBenchmark() function is far more difficult.

Reply on news.ycombinator.com