3 ms·

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.

• moron4hire 1mo ago
  If you have such a test suite then you really don't need AI to write the code for you.
  • thorian1828i03 1mo ago
    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.
• jongjong 1mo ago
  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.
• devin 1mo ago
  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.
• archargelod 1mo ago
  How do you write a spec for correctness? Only the small and unimpressive programs can be checked exhaustively.
  • thorian1828i03 1mo ago
    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 https://pkg.go.dev/net/http/httptest and https://bun.com/docs/test/dom https://bun.com/docs/test/dom makes this a pretty achievable goal in practice.
  • aw1621107 1mo ago
    > 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"
  • rfgplk 1mo ago
    You can formally prove the correctness of even massive programs.
• zx8080 1mo ago
  It's all now about money extraction from the areas dependant on software, not the sofrware itself.
• noosphr 1mo ago
  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.
  • deleted 1mo ago
    [deleted]
  • hodgehog11 1mo ago
    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.
    • adamddev1 1mo ago
      Tests do not prove the absence of bugs.
      • hodgehog11 1mo ago
        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.
• deleted 1mo ago
  [deleted]
• globular-toast 1mo ago
  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".
• mlsu 1mo ago
  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.