Comment by OccamsMirror
18 hours ago
You are abdicating your responsibility, which is fine for toy apps for yourself, but less fine when people expect that 2fa implementation to protect their accounts.
18 hours ago
You are abdicating your responsibility, which is fine for toy apps for yourself, but less fine when people expect that 2fa implementation to protect their accounts.
I think it's the opposite, with the right guideance, testing, frameworks, and using the top models today, implementing something with AI is most of the times better than what most developers would do.
I basically only manually test e2e myself, other tests are automated, code review is automated. I can tell the model to test for me too specific things or to add tests for specific potential issues, performance benchmarks, compared different implementations, etc.
The focus is a lot more around the code than on the code.
2 things.
1. If what you say is working, you have a working software factory that should be capable of matching the output of dozens of engineers.
What very impressive externally verifiable results have you had with this?
2. If you are working in software with plenty of customers, my strong suspicion is that there are people on your team who are looking at the code who furiously trying to reign in your output.
I make my own software, so no team to look over the code or be bothered by it. I don't even know how "vibe-coding" works in a team environment, because for me now it feels like it's "ideas to app" directly, so dumping by brain/ideas directly into a functional product.
I think this one is really cool[0], will be a free piano learning app. I do have other projects, but they are all at around 80% too, because some systems are shared amongst the projects and have to be finalized too (i.e. now I'm implementing my own transactional/marketing email service on top of Amazon SES, I need it before releasing ultimidi so people can register and receive email confirmations).
[0]: https://game.ultimidi.com
4 replies →
> What very impressive externally verifiable results have you had with this?
I notice this weird hostility whenever the topic of AI coding comes up and it's never made much sense to me. If someone told me about their new method for practicing guitar I'd feel like a real tool if I demanded they prove it for me then and there.
People don't owe you their "very impressive externally verifiable results" - /u/XCSme already posted their app in another comment, it looked fine to me.
You've made your ideological position very clear here, you don't need to keep heaping it on.
3 replies →
> with the right guideance, testing, framework
But you didn't write or read any of the tests so how do you know they are accurate?
You don’t, that’s why in agentic world your codebase is only as good as what you can prove. For this reason, you’re going to see more languages evolving feature like capability permission, effect/coeffect types, refinement types, formal verifiers, strict type checkers, static analysis and so forth. Tests are only a small part of the verification. These ideas are old and have sat outside of the mainstream coding world, but the value proposition in the ai age has changed enough their relevance is renewed.
Not arguing for not reading test code. A lot can be achieved by instructing agents to balance out the testing pyramid with the right amount of fast end to end tests, property based tests for the right things, parametrized example based tests. Ensuring the local and CI has the right mix of tests running at right time. On projects where I have less time to review AI generated code I channel my anxiety into setting up guardrails and processes for the agents and then force them to bump up against them. In the end I view it as creating frameworks which allow me to outsource some of my attention to the agents, so that I can claw back some of that time to go set up more guardrails for more agents who are working on something else.
I genuinely believe that the multiple dedicated agents reviewing security will do a better and faster job than me and than 99.99% of people.
You're acting as if code was incredibly secure before LLMs because humans were reviewing it.
I trust a modern model implementing a standard feature like this much more than 99% of the people I've worked with.
People bash LLMs for overengineering but for this it's what you want. Taking extreme edge-cases into account that a human would never bother with and obsessing over security.
That’s not what you want at all.
I mostly vibe coded a queuing system to replace something we’re using at work (last week. Spent about $1500). Then I meticulously went through the code.
It was much harder to review because it was ultra defensive and included guards for tons of edge cases that weren’t possible.
Unnecessary abstractions for possible extension later. Useless indirection. Probably 3x as much code as there would have been if I’d written it by hand.
I didn’t one shot this. I kept a pretty tight leash on the AI. I had probably a dozen markdown files with of plans that I created over hours of back and forth with the AI and reviewed before each implementation round. I had automated reviews and quality gates etc…
What I found in review was that it was full of very subtle bugs that would have bitten hard in prod. Committing offsets asynchronously that would lead to dropped messages. Clock drift bugs that would lead to dropped messages or write amplification storms. Lack of back pressure in some stages of the pipeline that would cause notes to get silently OOM killed. Weird over-insistence on never crashing in most places that would mask systemic errors.
If I’d just shipped it without review, it would have mostly worked. But at the scale it’s going to be used (tens of thousands of messages per second) it would have caused production issues for months while we tracked down each of these issues.
> included guards for tons of edge cases that weren’t possible
It's not possible until it is. This is the justification lazy developers like we all are have been using leading to bugs down the road. This glorification of hand-made code is strange, like we weren't writing dirty code full of shortcuts and hacks all the time.
1 reply →
The issue with LLM guarding isn't that it's "excessive" in outputting edge case handling, it's that the result often ends up just suppressing an error that actually indicates there is a bug or that should be handled elsewhere in a different way.
While I've definitely experienced it I don't think this is as much of a problem anymore. It's very easy to add an instruction to projects where you want every error to lead to a top-level throw rather than be handled. I also find that when it does try to mitigate it does so gracefully with a path you would actually make if you had infinite time, but your instinct tells you it's overkill.