4 ms·

One article said secure software was here because of AI, this one says it can now be performant. Yet when I ask for code it writes, by default, both slow and i

One article said secure software was here because of AI, this one says it can now be performant. Yet when I ask for code it writes, by default, both slow and insecure code that mostly works. Kinda. As I try to get AI to rewrite it into more secure, less bloated and optimized code is when it starts to randomly crash. Then I read articles about how AI is "moving too fast" and cry.

y1n0 2mo ago
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 2mo ago
  If you have such a test suite then you really don't need AI to write the code for you.
  - thorian1828i03 2mo 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 2mo 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 2mo 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 2mo ago
  How do you write a spec for correctness? Only the small and unimpressive programs can be checked exhaustively.
  - thorian1828i03 2mo 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 2mo 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 2mo ago
    You can formally prove the correctness of even massive programs.
- zx8080 2mo ago
  It's all now about money extraction from the areas dependant on software, not the sofrware itself.
- noosphr 2mo 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 2mo ago
    [deleted]
  - hodgehog11 2mo 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 2mo ago
      Tests do not prove the absence of bugs.
      - hodgehog11 2mo 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 2mo ago
  [deleted]
- globular-toast 2mo 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 2mo 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.
SadErn 2mo ago
I feel like I’m reading a post from 2025 instead of one written three minutes ago. People get entrenched in closedminded thinking. My guess is that this has been your canned spasm for the past year. Repeating these things won’t make them true or protect your job. You protect your job by learning how to use new tools as the technology advances. This sort of lazy thinking isn’t acceptable anymore. Whether this is a reflexive Luddite response or a reflection of your work ethic, neither is a good look. > Yet when I ask for code Engineers don't ask a tool to write code.
- hollowturtle 2mo ago
  > Repeating these things won’t make them true or protect your job. Most of these things are just true as of today. > You protect your job by learning how to use new tools as the technology advances. Sure and the more you learn the more you see how hyped they were and reality untangle > Engineers don't ask a tool to write code. And what they ask? They create loops or graphs? These tools ultimately vomit code anyways
  - SadErn 2mo ago
    [dead]
calvinmorrison 2mo ago
I cannot imagine how nitpicky people are. AI went from 'good autocomplete' to 'I just tell it to do an entire thing and it does it and it works the first try'. Maybe pick languages that are more boring. That's what works for me. It worked for hiring crappy outsourced programmers and it works for AI. It seems to do well with PHP - no long running processes / side effects. it works great with golang, simple language spec, and a very common style of writing.1
- paulddraper 2mo ago
  The goal posts always move
petra 2mo ago
Regarding speed - now it takes much less learning to use a fast web framework(like Meteor), this means web based software will be more performant. Regarding security - i wonder: can we develop a framework that is responsible to 100% of the security, with zero responsibility for security on the app developer?
etoxin 2mo ago
[dead]
jayd16 2mo ago
Aha, the problem is you're asking for code that works.
bitwize 2mo ago
Skill issue. The fact is that with the right spec, agentic guardrails, and evals, frontier models can now one-shot secure, performant code. This is the job of software engineering now. Learn to properly use the tools for the job.
- hollowturtle 2mo ago
  Very much not a skill issue; even with the best spec, guardrails and evals, frontier models will just do the hell they want. > one-shot secure, performant code. I call it reverse skill issue; it feels secure and performant because you can't verify properly, it feels right but it's actually broken in many nuanced ways. You can measure performance and produce a broken measurement as well. It's not as simple as you make it
  - deleted 2mo ago
    [deleted]
- baliex 2mo ago
  Color me sceptical but I’d say that’s a bold claim. Can you give a concrete example of that being the case? I’d love to see the prompt and harness. And understand the scale of problem you’re talking about solving with a one-shot approach. How long will it take to write the right spec? How will you know ahead of time that the spec is correct? Which agentic guardrails do you mean? How can they be set up? - I’d say the job of software engineering is still firmly being able to stand by the work you present and being reasonably confident that it’s correct according to yours and others’ understanding of the problem you’re attempting to solve.
  - bitwize 2mo ago
    > I’d say the job of software engineering is still firmly being able to stand by the work you present and being reasonably confident that it’s correct according to yours and others’ understanding of the problem you’re attempting to solve. Indeed. But how you came by that code has changed completely. If you still want to be able to produce at scale, at the speeds customers have come to expect now, you've got to use LLMs.
phucphungbk 2mo ago
[flagged]

y1n0 2mo ago

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 2mo ago
If you have such a test suite then you really don't need AI to write the code for you.
- thorian1828i03 2mo 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 2mo 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 2mo 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 2mo ago
How do you write a spec for correctness? Only the small and unimpressive programs can be checked exhaustively.
- thorian1828i03 2mo 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 2mo 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 2mo ago
  You can formally prove the correctness of even massive programs.
zx8080 2mo ago
It's all now about money extraction from the areas dependant on software, not the sofrware itself.
noosphr 2mo 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 2mo ago
  [deleted]
- hodgehog11 2mo 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 2mo ago
    Tests do not prove the absence of bugs.
    - hodgehog11 2mo 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 2mo ago
[deleted]
globular-toast 2mo 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 2mo 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.

SadErn 2mo ago

I feel like I’m reading a post from 2025 instead of one written three minutes ago. People get entrenched in closedminded thinking. My guess is that this has been your canned spasm for the past year. Repeating these things won’t make them true or protect your job. You protect your job by learning how to use new tools as the technology advances. This sort of lazy thinking isn’t acceptable anymore. Whether this is a reflexive Luddite response or a reflection of your work ethic, neither is a good look. > Yet when I ask for code Engineers don't ask a tool to write code.

hollowturtle 2mo ago
> Repeating these things won’t make them true or protect your job. Most of these things are just true as of today. > You protect your job by learning how to use new tools as the technology advances. Sure and the more you learn the more you see how hyped they were and reality untangle > Engineers don't ask a tool to write code. And what they ask? They create loops or graphs? These tools ultimately vomit code anyways
- SadErn 2mo ago
  [dead]

calvinmorrison 2mo ago

I cannot imagine how nitpicky people are. AI went from 'good autocomplete' to 'I just tell it to do an entire thing and it does it and it works the first try'. Maybe pick languages that are more boring. That's what works for me. It worked for hiring crappy outsourced programmers and it works for AI. It seems to do well with PHP - no long running processes / side effects. it works great with golang, simple language spec, and a very common style of writing.1

paulddraper 2mo ago
The goal posts always move

petra 2mo ago

Regarding speed - now it takes much less learning to use a fast web framework(like Meteor), this means web based software will be more performant. Regarding security - i wonder: can we develop a framework that is responsible to 100% of the security, with zero responsibility for security on the app developer?

etoxin 2mo ago

[dead]

jayd16 2mo ago

Aha, the problem is you're asking for code that works.

bitwize 2mo ago

Skill issue. The fact is that with the right spec, agentic guardrails, and evals, frontier models can now one-shot secure, performant code. This is the job of software engineering now. Learn to properly use the tools for the job.

hollowturtle 2mo ago
Very much not a skill issue; even with the best spec, guardrails and evals, frontier models will just do the hell they want. > one-shot secure, performant code. I call it reverse skill issue; it feels secure and performant because you can't verify properly, it feels right but it's actually broken in many nuanced ways. You can measure performance and produce a broken measurement as well. It's not as simple as you make it
- deleted 2mo ago
  [deleted]
baliex 2mo ago
Color me sceptical but I’d say that’s a bold claim. Can you give a concrete example of that being the case? I’d love to see the prompt and harness. And understand the scale of problem you’re talking about solving with a one-shot approach. How long will it take to write the right spec? How will you know ahead of time that the spec is correct? Which agentic guardrails do you mean? How can they be set up? - I’d say the job of software engineering is still firmly being able to stand by the work you present and being reasonably confident that it’s correct according to yours and others’ understanding of the problem you’re attempting to solve.
- bitwize 2mo ago
  > I’d say the job of software engineering is still firmly being able to stand by the work you present and being reasonably confident that it’s correct according to yours and others’ understanding of the problem you’re attempting to solve. Indeed. But how you came by that code has changed completely. If you still want to be able to produce at scale, at the speeds customers have come to expect now, you've got to use LLMs.

phucphungbk 2mo ago

[flagged]