Ask HN: Is AI code verification becoming your main bottleneck?
I am a beginner in programming and honestly I have been using AI to code a lot but I am scared to ship because of the countless stories of AI code silently breaking, AI code not being reliable long term and all that.Please share your stories with me how you handle AI code reliability and verification and what I can do to be more confident before I ship
This may not be a popular opinion but I’ll say it anyways. I’ve done a lot of this and am sharing anecdotal information.
The claims that AI writes inefficient code may often be right. If and when it’s an observed problem, you can use AI to improve performance.
The claim that AI writes insecure code is probably also correct. You’ll want better safeguards here based on your product. The infrastructure you choose to deploy on can help as well - the LLM can help you design for this.
The claims that AI will delete your database are unlikely and an indication that permissions were too loose. You can also sandbox the code which runs. Again, AI can help you design this.
This is not an endorsement to blindly deploy code you haven’t verified.
My feedback is to be as optimistic as possible. Learn where the edges are. Find ways to patch them systematically. And let your confidence grow or shrink from your own experience.
Thanks, this is a really helpful perspective. I think I’ve been letting the scary stories make AI coding seem more dangerous than it might actually be.
I like the idea of learning where the edges are and letting my confidence come from my own experience. I’m definitely going to start paying more attention to what actually goes wrong in the code I’m building instead of just worrying about what could go wrong.
After code review is done, I once run relayevals.com right before I merge to double check. It gives you a clear PASS/BLOCK verdict to tell you whether the code is merge ready.
I know the founders personally, do try if you're curious.
This is super helpful, thank you! I've heard of CodeRabbit but didn't know about RelayEvals. I'll definitely look into them.
Since you use both, I have a quick beginner question: Does RelayEvals actually catch those 'silent' logic bugs I'm scared of (like breaking a hidden edge-case), or does it mostly just check if the code is well-written? What is the main thing you still have to manually double-check even after they both give it a PASS
Congrats and welcome to the wonderful world of ports.
I would say yes, verifying that the code not only does what you expect but also doesn't do anything of the things you do not expect, is the main bottleneck.
That is: do-all-the-things, please, and don't-do-all-the-non-things, as well.
Ideally, one can reason through their application at a high-level and have a "spec" or specification that the LLM can build from and check against.
You can also have the LLM go back through and tell you about any vulnerabilities you need to address before shipping.
I don't know exactly what you are shipping, but in general: never give the LLM root access or command-line access in a deployed app. Give it the minimal permissions necessary to accomplish its work/role. Pin versions [if you're working with version 5, explicitly say that, rather than just using the "latest" one since that's a moving target].
Some things are not obvious until deployed to a live environment, so do thorough testing. You can have an LLM generate test cases and run a "test suite" to check your code does all-the-things and none-of-the-non-things [undesirable outcomes] this way.
But again, when you have many moving gears finally coming together in a product, in a real, online environment, your best bet is doing lots of testing first to give yourself confidence you've caught most of the edge-cases, and that there are no "catastrophic" edge-cases lurking, unaccounted for.
If you still have any specific questions or want to zoom in on any aspect of software creation, please ask us
Thanks, this is really helpful. I never thought about the “doesn’t do anything I didn’t expect” part. That actually seems harder to verify than just checking if the feature works.
When you say you use specs, tests and LLM reviews before shipping, how do you personally know when you’ve tested enough to actually feel confident shipping? Is there a point where you just have to trust it and ship?
The claims that AI writes inefficient code may often be right. If and when it’s an observed problem, you can use AI to improve performance.
The claim that AI writes insecure code is probably also correct. You’ll want better safeguards here based on your product. The infrastructure you choose to deploy on can help as well - the LLM can help you design for this.
The claims that AI will delete your database are unlikely and an indication that permissions were too loose. You can also sandbox the code which runs. Again, AI can help you design this.
This is not an endorsement to blindly deploy code you haven’t verified.
My feedback is to be as optimistic as possible. Learn where the edges are. Find ways to patch them systematically. And let your confidence grow or shrink from your own experience.
I like the idea of learning where the edges are and letting my confidence come from my own experience. I’m definitely going to start paying more attention to what actually goes wrong in the code I’m building instead of just worrying about what could go wrong.
After code review is done, I once run relayevals.com right before I merge to double check. It gives you a clear PASS/BLOCK verdict to tell you whether the code is merge ready. I know the founders personally, do try if you're curious.
Otherwise coderabbit should do the trick for you.
I would say yes, verifying that the code not only does what you expect but also doesn't do anything of the things you do not expect, is the main bottleneck.
That is: do-all-the-things, please, and don't-do-all-the-non-things, as well.
Ideally, one can reason through their application at a high-level and have a "spec" or specification that the LLM can build from and check against.
You can also have the LLM go back through and tell you about any vulnerabilities you need to address before shipping.
I don't know exactly what you are shipping, but in general: never give the LLM root access or command-line access in a deployed app. Give it the minimal permissions necessary to accomplish its work/role. Pin versions [if you're working with version 5, explicitly say that, rather than just using the "latest" one since that's a moving target].
Some things are not obvious until deployed to a live environment, so do thorough testing. You can have an LLM generate test cases and run a "test suite" to check your code does all-the-things and none-of-the-non-things [undesirable outcomes] this way.
But again, when you have many moving gears finally coming together in a product, in a real, online environment, your best bet is doing lots of testing first to give yourself confidence you've caught most of the edge-cases, and that there are no "catastrophic" edge-cases lurking, unaccounted for.
If you still have any specific questions or want to zoom in on any aspect of software creation, please ask us
When you say you use specs, tests and LLM reviews before shipping, how do you personally know when you’ve tested enough to actually feel confident shipping? Is there a point where you just have to trust it and ship?