prasadvara

If I am not wrong, orgs build vs buy for the most part is NOT impacted by AI cycle.

For the most part business care about, is this our core capability OR not?? If core, yes build is what preferred. If not, buy is preferred. Where few occasions they deviate from this due to, to be frank non-technical reasons.

In Software world, building is not the costly, maintaining it is - and this cycle of AI developed software is NOT proven yet. So, so far my understanding is nothing changed in that area.

Curious - if you measured any quality side of this? not just PRs and velocity. Some of the tradeoffs like Github are not really related to AI capabilities, isn't it?

Interesting idea. Did you run any comparison analysis between dockerized vs brewlet??

Curious about what motivated you to pursue this approach.

This slop is one of the very frustrating experiences with AI. To address this, I had to set a global rule - Results summarized max 5 sentences, expand only if asked.

depproof | Part-time B2B Sales Lead | REMOTE (US) | Part-time | Equity + commission | https://depproof.com

Most of the code a team ships is third-party, and scanners flag hundreds of vulnerabilities in it. depproof tells you which few attackers are actually exploiting, so you fix those first. It runs inside your own environment, and your code never leaves.

We're a small, founder-led company looking for a part-time sales lead who has sold to security or engineering teams: running first conversations, shaping the pitch, and closing our first customers.

You may reach out to me at: prasadv at depproof.com

This is great writeup, can we do a cross comparison with "human" experts?? whether models perform better OR worse??

The tools were sold on speed and quality, and they deliver both.

I think "quality" side depends on LOT of tuning you would need to keep in place. Quality might be good if you are dealing with single project, when you hare more than one repo to deal with, things need real attention and observed that quality goes down significantly.

The ongoing theme of all these responses was shifting the blame to the consumer.

As expected. I think consumers also need to push back on these practices, but the problem is, majority of consumers are tech savy but not privacy savy.

Reducing the number of clicks doesn’t necessarily improve interaction.

I think this is half true and depends on you are dealing with vetrans or new users. Once you are used, people just click as many as needed, but when user is new to the UI, every click becomes a question and resistance.

If you are upcoming developer, nothing wrong in vibe coding in my opinion as long as you take time to understand what is being done by the model. One suggestion I have is, make sure ask/explore alternative approach of solving the same. This helps you to understand and eventually judge what fits in given scenario. Good luck!

Make sense, most of the consumers/users of this tech not much into privacy, like any other gadgets at home.

Correct, that is what confused me, how SBOM came into the picture, now got it, thanks!

This is unfortunately becoming latest theme. Get the credentials one or otherway from maintainer and use it to distribute the malware.

I feel that when we opt for row level security we are fundamentally moving away from CRUD principles and maybe not a good candidate in RDS. I have used this approach lock the rows from UI modifications, but felt like awkward way of restricting.

You don't need an SBOM or anything fancy to get started

-- Curious how this avoids SBOM need?

Isn't this going to introduce the dependency of domain management? I understand the positive side of it, but put some infra level manamgment layer to individual Open Source devs, just a thought. But yeah, positives vs negatives weigh and pick.

It’s super lightweight and incredible.

As long as the phase of the software and users are lighweight - agree these internal tools can be built, but as scale comes that is when the challenges show up is what I have observed.

Where internal tools shine is internal operational workflows that are being done manually.

This is the key distinction people need to understand, until then it just piles up and lot of companies main business is not software, something else.

Curious what use cases this tool serves? Could you help with an example? Thanks!