Live data from Hacker News

We are retiring our bug bounty program

turso.tech

231–240 of 303 posts

Re: We are retiring our bug bounty program

#231
post #57
post #34

Earlier quoted context omitted.

Moving money is not free, and managing payments/etc can be a huuge headache. Sometimes it’s easy, but sometimes it’s not.

This is one of the cases where crypto works well.

I will include this security project as an addendum to my reply: https://github.com/juli/taint>. Views on crypto can differ dramatically depending on the country you live in.

Re: We are retiring our bug bounty program

#232

Earlier quoted context omitted.

> If you don't ever have a massive PR from a dynamite session, then you cannot ever be better than "average and plodding". That's just cope to avoid learning how to turn a big change into a well organized patch series.

In retort, that's just doubling down that everything should always be average and plodding. I'm not saying one shouldn't learn how to stage large changes into a mature codebase. Sometimes the overhead is very worth it, maybe most times if you're close to the profit center of a faang. But one should understand multiple ways of working, for different situations.

If you can't be arsed to prepare your code for review because it's such a buzzkill to your velocity, why are you even reviewing then? Just push to main.

I'm not being snarky. I put different review standards in place for different repos on my team. Sometimes the standard is no standard. Push to main. Figure it out later.

Re: We are retiring our bug bounty program

#233
post #8

Which goes on to prove that bottleneck isn't in writing the code. It is in reading and understanding the code. We all had that one "productive" engineer in our teams who would write huge PRs that would have large swaths of refactoring whether warranted or not and that was way before anyone even could imagine in their wildest dreams that neural networks could generate that huge amounts of code. The net effect of such…

My whole career I yearned for green field projects but somehow predominantly worked on existing grown code bases and legacy projects. That naturally meant reading and understanding more code than writing. Sometimes my LOC count was even negative, and I was proud of that accomplishment. Now with AI I write even less and I've given up on the dream to gain fulfillment that way. The ability to quickly understand large am…

Statistically speaking, most codebases are brownfield. Without joining a startup, working on a greenfield project is actually a pretty rare treat. And deleting code is wonderful. I'd go as far as to say lines removed is more often than not more valuable than lines added; every line that's no longer in the codebase is code you no longer have to understand or care about. So long as functionality remains intact, of course.

The problem, as I see it, with prolific use of AI to generate code is that it goes in the exact opposite direction. More and more code is bolted on top of existing code, more and more edge-cases, patch-ups, workarounds, etc. accumulate, the codebase grows and grows. In the end, no matter how good you are at understanding "code from questionable sources", you're still a human being. The AI can generate new code at rates several orders of magnitude faster than you can injest and understand it, and when your meat brain becomes exhausted, the machine does not tire. From a business perspective, your employer will weigh their options: they can wait for you to interpret the code and generate good code (whether by hand or by machine + human review).. Or they can just keep pulling the lever on the slot machine until it works well enough to sell. And for the business exec just looking for the fastest path to paydirt, I'm afraid the latter option is going to look way more appealing.

Re: We are retiring our bug bounty program

#234
post #8

Which goes on to prove that bottleneck isn't in writing the code. It is in reading and understanding the code. We all had that one "productive" engineer in our teams who would write huge PRs that would have large swaths of refactoring whether warranted or not and that was way before anyone even could imagine in their wildest dreams that neural networks could generate that huge amounts of code. The net effect of such…

My whole career I yearned for green field projects but somehow predominantly worked on existing grown code bases and legacy projects. That naturally meant reading and understanding more code than writing. Sometimes my LOC count was even negative, and I was proud of that accomplishment. Now with AI I write even less and I've given up on the dream to gain fulfillment that way. The ability to quickly understand large am…

Personally, and this is just my wild guess; I think almost no one is _really_ going to learn to code again. That's not a slight on the next generation or anything; I wouldn't know how to code right now if LLMs existed 25 years ago. I love coding, but it's the _result_ that's the real accomplishment. The journey a bit... but having the result always just sitting there, ready to grab with no effort, is too much temptation to resist.

And as this goes on, folks who can run an LLM _and_ understand/criticize/rework/re-prompt are just going to get more and more scarce. Even using an LLM in my preferred style, where you guide the model through a long series of small steps, will fade away.

Re: We are retiring our bug bounty program

#235

Earlier quoted context omitted.

I don't understand this. If that project is not offering a bug bounty, why are they getting so many PRs? What possible incentive is there to spend real money on tokens just to push junk PRs? Are the PRs spamming a product or something?

They're offering bounties: https://github.com/UnsafeLabs/Bounty-Hunters/issues

To clarify: The fake issues, in the fake repo, have bounty labels.

Re: We are retiring our bug bounty program

#236
post #8

Which goes on to prove that bottleneck isn't in writing the code. It is in reading and understanding the code. We all had that one "productive" engineer in our teams who would write huge PRs that would have large swaths of refactoring whether warranted or not and that was way before anyone even could imagine in their wildest dreams that neural networks could generate that huge amounts of code. The net effect of such…

> Which goes on to prove that bottleneck isn't in writing the code. It is in reading and understanding the code. No, it's that quite literally the PR submissions are SPAMmed. Whoever made them is acting like a SPAMmer, sending out lots of garbage and hoping it sticks. IE, they're not doing their part in reviewing what the AI found and generated.

So you agree. Unless you're using some definition of "reviewing" which somehow doesn't involve "reading and understanding".

Re: We are retiring our bug bounty program

#237
post #8

Which goes on to prove that bottleneck isn't in writing the code. It is in reading and understanding the code. We all had that one "productive" engineer in our teams who would write huge PRs that would have large swaths of refactoring whether warranted or not and that was way before anyone even could imagine in their wildest dreams that neural networks could generate that huge amounts of code. The net effect of such…

> Which goes on to prove that bottleneck isn't in writing the code. It is in reading and understanding the code.

The people AI evangelists often say "typing" instead of "writing code", because they don't really understand -- or it's not lucrative for them to acknowledge -- what makes writing code hard.

We don't just write code to be executed by machines, we also write it to be read by humans. Code reviews, debugging, future changes -- all of these things involve reading and understanding the code someone wrote. And until we have an AI that we can actually hold responsible for its actions, we can't delegate the understanding to it.

Re: We are retiring our bug bounty program

#238
post #8

Which goes on to prove that bottleneck isn't in writing the code. It is in reading and understanding the code. We all had that one "productive" engineer in our teams who would write huge PRs that would have large swaths of refactoring whether warranted or not and that was way before anyone even could imagine in their wildest dreams that neural networks could generate that huge amounts of code. The net effect of such…

I don't understand why one wouldn't just auto reject big PRs and tell them to make smaller ones. Sounds like it's a communication and social problem, not a technological one. Even with AI, just tell it to make smaller self contained PRs. I do this with Claude or GPT models and they do just fine.

It's not a communication problem, it's a scale problem. An AI could spit out dozens more massive PRs in less time than it takes you to even evaluate whether or not the current one is AI.

Re: We are retiring our bug bounty program

#239
post #130

we automated finding bugs. then we automated submitting bugs. now we're automating rejecting submissions. at no point did anyone automate fixing the bugs.

I actually just got a PR from my boss's AI agent. It identified the wrong problem (surface level), and corrected it by corrupting the document data, but making it no longer throw an exception.

Take that clankers

Re: We are retiring our bug bounty program

#240
post #17

Earlier quoted context omitted.

Sounds a like a tactical tornado, made me think of this paragraph: “Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado. The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the…

I have seen precisely zero consequences for these people because they usually leave after not too long and go somewhere else, sometimes for higher pay. The slower folks end up getting the worse code and no raises in exchange for comradery. But also I have no idea how that situation arises unless the slower folks are just auto-approving PRs. You kind of did that to yourself if you let the new person get away with it.

> I have seen precisely zero consequences for these people because they usually leave after not too long and go somewhere else

In my case, it's worse than that. They usually get promotions, raises and move up the ladder. The business only cares about thing: making cash. This means pumping out feature as soon as possible because the sales team closed a million dollar contract, which includes features we don't have.

The engineers who deliver the features are noticed by managers and win big. No one cares about code quality and half the time, the code is rewritten or thrown away anyway..

I'm sure there exists organization where code is treated as art, but I sure as heck haven't worked in one. Over the years, I've given up trying to cleanup crap code, now I just get the work done as best as I can and call it a day.

Post reply on HN