Wow, interesting to see such a diametrically opposed view. We’ve banned merge commits internally and our entire workflow is rebase driven. Generally, I find that rebases are far better at keeping Git history clean and clearly allowing you to see the diff between the base you’re merging into and the changes you’ve made.
"Clean" is not the same as "useful". You have to be really, really disciplined to not make a superficially looking "clean" history which may appear linear but which is actually total nonsense.
For example, if one is frequently doing "fix after rebase" commits, then they are doing it wrong and are making a history which is much less useful than a seemingly more complicated merge based history. Rebased histories are only clean if they also tell a true story after the rebase, but if you push "rebase fixes" onto the end of your history, then it means that prior rebased commits no longer make any sense because they e.g. use APIs that aren't actually there. Giving up and squashing everything to one commit is almost better in this case because it at least won't throw off someone who is trying to make sense of the history in the future.
I think that rebasing has won over merges mostly because the tools for navigating git histories suck SO HARD. I have used Perforce at a previous job, and their graphical tools for navigating a merge based history are excellent and were really useful for doing code archeology.
Generally our pattern is that every PR gets rebased into sensible commits. So in a way we are doing "squash commits" but the method is an interactive rebase. This keeps our history very pretty and clean, and simultaneously easy to grok and navigate.
Yes, I prefer that approach as well because it allows the person who authored the change to do all the work of deciding how to resolve conflicts up front (and allows reviewers to review that conflict resolution) instead of forcing whoever eventually does the merge to figure everything out after the fact. It also removes conflicts from the history so you never have to think about them later after the rebase/merge process is finished.
In a way, this may be a good thing for the 'compliance' ecosystem because it will prompt people to actually read the report and check the evidence, as opposed to trusting a badge.
If you read through the report PDFs of affected companies, you'll find a lot of stock wording and phrases that don't even make sense.
YC has funded both Vanta and OneLeet. It's a shame they also funded a hype machine like Delve.
I would recommend both Vanta and OneLeet as good quality tools to work with, having used both. The founders of OneLeet are very accessible, and Vanta has all the integrations you would need as both a small startup and an enterprise-grade player.
Secureframe and Drata are other tools in a similar class that are also legitimate.
This is clearly false from what I've seen. If you read the source Substack article and look through the list of auditors they have, it is impossible to trace down who the US-based CPA is that's issuing the report. These firms, for all intents and purposes, do not really exist. They use shell addresses in Wyoming and Texas that are registered agent offices, etc.
But really all you have to do is look at the reports themselves. They are so shoddily written that it's hard to believe any legitimate firm would issue them. If you Ctrl F for Clueley in this thread, you will see my comment with a sample excerpt from the assertion of management for one of their reports.
Present assurance definitely exists in the US. Outside of delve, I have seen their reports for vanta and it’s the same. it was 95% policy inspections and 5% loooked at a GRC tool.
I assume you mean this "Prescient Assurance? As detailed in this section of the post?
6.7 Misled auditor - Prescient
With this conclusion:
Looking at that report, there are clear signs that Delve either knowingly misled Prescient, or that Prescient accommodated Delve’s deficient process. Given their reputation and by the small number of Delve/Prescient reports out there, I’m assuming it is the former.
I've used Prescient in the past and found them on par with others. Policy evidence is at most about 30%. Everything else is show-don't-tell. Either live screen shares, screenshots, non-policy documentation, or evidence from a shared vendor that's integrated into the environments and security tools (like Drata).
There's a deep lack of accountability here for their marketing statements. For example, "get SOC 2 compliant in days," which I would consider to be false advertising.
That, plus their willingness to arrange an essentially fraudulent auditor network (try to find who the real CPA is behind Accorp, for example), and also massively upcharge the prices of the SOC reports that they offered as a bundled service within the platform. There was no separation here. Del is the transfer agent. Del was always the intermediary and the transfer agent. There is no independence in their default auditor relationships.
At very best, this is a massive AICPA transgression.
At worst, blatant fraud.
I would wager that discovery would show the latter.
What's more surprising to me, as a layperson, is that I found this out and investigated their shady auditor network in late December. It didn't take much work.
Insight Partners invested in a 32 MILLION DOLLAR ROUND without any apparent shred of due diligence. What does that say about the VC market writ large?
Delve did not even try to fake the reports well. They could have used AI tooling to write somewhat plausible Assertions of Management, but they just dropped in clear form submissions to the reports they provided. Here is an example from Cluely:
> We have prepared the accompanying description of Cluely, Inc., system titled "Cluely is a desktop AI assistant to give you answers in real-time, when you need it." throughout the period June 27, 2025 - September 27, 2025(description), based on the criteria set forth in the Description Criteria DC Section 200 2018 Description Criteria for a Description of a Service Organization’s System in a SOC 2 Report (description criteria).
> The description is intended to provide users with information about the "Cluely is a desktop AI assistant to give you answers in real-time, when you need it." that may be useful when assessing the risks arising from interactions with Cluely, Inc. system, particularly information about the suitability of design and operating effectiveness of Cluely, Inc. controls to meet the criteria related to Security, Availability, Processing Integrity, Confidentiality and Privacy set forth in TSP Section 100, 2017 Trust Services Principles and Criteria for Security, Availability, Processing Integrity, Confidentiality and Privacy (applicable trust services criteria).
I mean, just re-read this sentence:
> The description is intended to provide users with information about the "Cluely is a desktop AI assistant to give you answers in real-time, when you need it." that may be useful
It makes no sense at all.
Someone implemented the code to automate this report mill, and didn't think to even smooth it out with an LLM! There was clear intent here.
To imagine that an auditor reviewed and stamped this as a coherent body of work beggars belief.
Hit piece or not, the blatantly fraudulent behavior displayed by Delve is reprehensible.
And they didn't even try. Read this management assertion for one of the (known) affected companies:
> We have prepared the accompanying description of Cluely, Inc., system titled "Cluely is a desktop AI assistant to give you answers in real-time, when you need it." throughout the period June 27, 2025 - September 27, 2025(description), based on the criteria set forth in the Description Criteria DC Section 200 2018 Description Criteria for a Description of a Service Organization’s System in a SOC 2 Report (description criteria).
> The description is intended to provide users with information about the "Cluely is a desktop AI assistant to give you answers in real-time, when you need it." that may be useful when assessing the risks arising from interactions with Cluely, Inc. system, particularly information about the suitability of design and operating effectiveness of Cluely, Inc. controls to meet the criteria related to Security, Availability, Processing Integrity, Confidentiality and Privacy set forth in TSP Section 100, 2017 Trust Services Principles and Criteria for Security, Availability, Processing Integrity, Confidentiality and Privacy (applicable trust services criteria).
Respectfully, I think there may be an issue with your voting ring detection, which is that if multiple people try to submit the same article and are redirected to an existing post and they upvote it, that might be setting off the voting ring alert. Can you check that?
Yes, but your team claimed this set off "voting ring" behavior [0] and it was suppressed for nearly a day because of that. I am very curious how you determine what is, or is not, "voting ring" behavior. I believe Dang is responding in another thread about that.
Obviously we don't publish how HN's voting ring detector works. If we did, it would quickly stop working.
What matters in this case is (1) it's a software penalty that has nothing to do with the content of a story, (2) moderators didn't touch the submissions or even know they existed, and (3) once we did know that they existed, we merged the threads and placed the story on the frontpage - that is, we went out of our way to give this story more attention, not less - in keeping with the principle explained here: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu....
reply