Hacker News Reader

Comment by user34283 | Hacker News Reader

I'd go further and say vibe coding it up, testing the green case, and deploying it straight into the testing environment is good enough.

The rest we can figure out during testing, or maybe you even have users willing to beta-test for you.

This way, while you're still on the understanding part and reasoning over the code, your competitor already shipped ten features, most of them working.

Ok, that was a provocative scenario. Still, nowadays I am not sure you even have to understand the code anymore. Maybe having a reasonable belief that it does work will be sufficient in some circumstances.

View on HN

This approach sounds like a great way to get a lot of security holes into your code. Maybe your competitors will be faster at first, but it’s probably better to be a bit slower and not leaking all your users data.

I'm mostly thinking about the frontend.

If I had a backend API that was serving user data, I'd of course check more carefully.

This kind of mistake always seemed amateurish to me.

Fair enough. I would still personally feel uneasy about it, but I guess it’s alright if it works for others.

How often do you buy stuff that doesn't work, and you are OK with the provider telling you "we had a reasonable belief that it worked"?

How are we supposed to use software in healthcare, defense, transportation if that's the bar?

There's a lot of functionality in the frontend that I am building that I did not review. If it worked in testing, that's good enough.

You're free to review every line the model produces. Not every project is in healthcare or defense, and sometimes different standards apply.

I’m assuming you work in a setting where there is a QA team?

I haven’t been in such a setting in 2008 so you can ignore everything I said.

But I wouldn’t want to be somewhere where people don’t test their code, and I have to write code that doesn’t break the code that was never tested until the QA cycle?

No, in my day job I obsess over every line I add, although there is QA.

In my side project I'm building a frontend that, according to me, is the best looking and most feature rich option out there.

I find that I'm making great progress with it, even when I don't know every line in the project. I understand the architecture and roughly where what functionality is located, and that is good enough for me.

If in testing I see issues with some functionality, I can first ask the model to summarize the implementation. I can then come up with a better approach and have the model make the change. Or alternatively I edit some values myself. So far it wasn't often that I felt the need to write more than a few lines of code manually.

Reply on news.ycombinator.com