AI actually is decently good at updating docs. But the kinds of problems that are being described in this thread, like documentation that varies wildly in tone and target audience or that describes different versions of the same service, or where how to do something is covered across multiple semi-overlapping pieces of documentation (some of which are up to date and some of which are not) are all a real strong indicator of inadequate centralized ownership of the docs. And the AI ain't gonna update the docs if nobody tells it to. (And AI still requires a great deal of micro-management to be used effectively in docs authorship.)
It depends. For stuff like npm packages, where the downstream consumers have to make a conscious decision about whether to adopt the update or not, I absolutely think it's worth getting it right, especially for major version bumps. I myself am the user of an open source code gen tool that does not have comprehensive changelogs, and it makes me want to tear my hair out because we can never be confident when upgrading whether or not we're going to end up with changes that will break our workflows or our customers' workflows.
But for consumer apps, honestly, maybe not? Even at companies that do good consumer changelogs, they're generally considered marketing content. Other posters in this thread made the points that most people updating consumer apps are not even going to see the changelog message, and that app stores have effectively punished companies for providing detailed changelogs by holding app store releases over them.
And given that for larger companies so many of them are actually controlling their feature releases on the backend and not on the client side (you might add the capability for a feature on the client months before you actually set the rollout to 100%), trying to convey those updates in the client-side changelog can be hard to do in a way that consumers will understand and can often generate a lot of confusion and support tickets. After all, we don't expect a changelog entry every time a website updates, and I feel like every day mobile and desktop apps are getting closer and closer to that category.
Changelogs are really difficult to do properly. The concept of a "release" is fuzzy in a world of continuous deployment, and feature flags and experiments mean that different customers are seeing different features. The release of the client that can support the feature is often very divorced from the enablement of the feature. This is not a new phenomenon and has been something we struggled with way back in 2013 in my first SaaS job. Even if you do have a defined set of changes, the way modern software releases work means that the changelog is often the only reason to collect and document those all in one place, and not always a sufficiently compelling one to justify gathering and coordinating this information across teams in a large organization.
Anyway, time to go go see if Claude's done drafting that changelog I asked it to do...
The GitHub bot situation is so frustrating! A good ~50% of community traffic on our repos is spam and bots and to report them I have to fill out a lengthy form and MAYBE GitHub will ban them six weeks later. And I also can't tell whether our repos are being used (and thus worth investing in): GitHib only shows two weeks of traffic data and what they do have is completely useless because they can't filter out bot traffic.
This rule of thumb, when used correctly, is supposed to refer to womens' dress straight sizes. As in, for an average height woman, losing 10 lbs is roughly equivalent to going from a size 8 to a size 6. It doesn't refer to clothing that is sized as "medium", "large", etc. (I did not read the article; it seems from the quote that the author was using this rule of thumb inappropriately and out of context.)
These are really good changes for your overall health, but what I hear anecdotally is that a lot of the young adults diagnosed with colon cancer don't have traditional colon cancer diet/lifestyle risk factors. There's even a theory that healthy activities like long distance running might be contributing to cancer risk.
I think what you're missing is that prior to the acquisition, Anthropic was a customer of Stainless. They did not need to "rummage through [their] data and workflows" to understand the quality of their product.
You totally could, but the purpose of the OpenAI/Plaid integration is to help you analyze your spending and finances with OpenAI (using it as a budgeting/financial planning app), so if your spending isn't actually in the account you connected, it's not going to give you any value.
This is a common belief, but the CFPB has stated your bank is still legally required to make you whole in the event of fraud even if you handed over your username and password to a third party, and that any bank TOS stating otherwise are not valid. This is covered on the CFPB Electronic Fund Transfers FAQ, under the Error Resolution: Unauthorized EFTs, Question 8: https://www.consumerfinance.gov/compliance/compliance-resour...
We just this week launched a new sign-up flow to make it waaaay easier for non-businesses to use Plaid, I posted some details below.
Actually, as part of publicizing our new hobbyist-friendly onboarding, we're looking to work with hobbyists who have created Plaid-powered apps and would be interested in making a short video about their app and their Plaid experience to potentially be featured on the Plaid blog -- if you're interested, shoot me an email at ahoffer@plaid.com and I can send you the details.
So you don't have to be a business to use Plaid, but you do have to be a business to buy Plaid via the Sales channel rather than via the self-serve channel. Admittedly, when folks reach out to Sales and ask to buy Plaid and are told they're not eligible because they're not a business, this nuance is sometimes not communicated very well (or at all). We're working on it. :-)
In fact, we actually just this week launched a new sign-up flow to make it waaaay easier for non-businesses to use Plaid, so try checking it out -- after you go to dashboard.plaid.com and create an account, you should see a "Free trial" button show up on the homepage with a link to use the hobbyist onboarding flow.
Plaid has a pay-as-you-go option that's only about $2/month for this use case. (I believe the current rack rate PAYG pricing is 30 cents per month per connected bank login).
Thanks for the details! Glad to hear you've got full Production access -- if any of the security attestation requirements seem unreasonable for your use case, feel free to reach out to us directly (you can email me at ahoffer@plaid.com and let me know you're the person in this thread) so we can look into it.
Plaid does support personal use (including personal use access for Chase). I'd actually be interested in seeing where you saw that it doesn't support Chase for personal access so I can make sure our messaging is clear and consistent on that front!
It's true that the current onboarding flow is not designed for personal use cases; we're currently in the middle of revamping it to make it less onerous for non-business users. In the meantime, I recommend you just fill out the questionnaire as well as you can. We know that some of the questions don't really make sense in a personal use context -- just try to answer them to the best of your ability and you should be fine.
Plaid does have products that do request bank credentials, but those products are not used for age verification. It's very common that a given customer-facing flow will use multiple Plaid products together to handle multiple different customer needs, so it's likely that the flow you were working with was using multiple Plaid products and requesting bank credentials, but for a different reason than to perform age verification (for example, KYC + bank account ownership verification or KYC + bank account validity verification).
I work at Plaid. Plaid's KYC product doesn't ask for bank login credentials. (EDIT: I originally had a line in here saying "nor do any of our competitors' KYC products, that I know of." but then someone in this thread linked to Stripe documentation saying that Stripe does use this method of age verification in Australia, so TIL.)
My heuristic is that if your interlocutor asks follow-up questions like that with no indication of why (like “why do you want to do X?” rather than “why do you want to do X? If the answer is Y, then X is a bad approach because Q, you should try Z instead”) then they are never going to give you a helpful answer.
I work at Plaid, so this got me curious about who their provider was -- per Wikipedia, Mint used Intuit's internal account aggregation tools from ~2010-2024. It's possible that Mint swapped out to some other third party provider and Wikipedia doesn't know about it, but based on both internal and external records, I'm pretty sure it wasn't Plaid. (Intuit's Credit Karma, which was marketed to Mint customers as a replacement after Mint shut down, does use Plaid.)
From the article, it's not clear that the prevailing reasonable meaning was Connected Parties. In fact, it sounds like the author thought the meaning was connected parties -- otherwise he would not have bothered to disclose the relationships of the two shareholders who were connected parties (lowercase) but not Connected Parties (uppercase).
These were popular at my workplace maybe seven years ago, and while I was into the idea at first, IMO it was impractical most of the time. Turns out it's a pretty unreasonable burden to place on people that they should read and follow instructions in a document in order to communicate with someone and to personalize their work approach for every person they interact with.
The main context these make sense in is when written by a manager (or maaybe by a direct report for their manager). They can be useful to establish expectations for a team around things like "is it ok to message me on the weekend" and "here's what you should have prepared for our 1:1s".
The context isn't fully spelled out, but Powell is describing the inspiration for "The Interrogative Mood: A Novel?" Those lines are the beginning of his novel and the novel itself is entirely in the form of questions.
I can't speak to the Plaid/Square integration specifically and why transaction history is requested in that case, but in general, a common reason Plaid would want transaction history for an ACH transfer is to do risk assessment for ACH returns. The product marketing page for Signal explains what the merchant is getting out of it: https://plaid.com/products/signal/
It's not. But an article explaining the real reasons why your resume was immediately thrown out (you have none of the required qualifications; you live in Australia and the job is only open to US applicants; you applied for the same position a month ago and were rejected then) would be too boring, I guess.
I work at Plaid. The basic, non-discounted rate for the Transactions API is like 30 cents per connected account per month (or 45 cents per month if you're buying some optional add-ons to go with it), and any customer the size of Intuit would definitely be getting some kind of huge volume discount. I can't speak for other companies in this space, but I assume they have similar pricing.
I work at Plaid and I think that pricing info is a bit off — assuming we’re talking about just the APIs for transactions data (which is what the budgeting apps typically use) and these prices are in USD, even customers who don’t qualify for any volume discounts are paying closer to 30-45 cents per month per connected account. (Volume discounts then can start to kick in starting at a total API spend of $300 / month -- the higher the monthly API spend, the greater the discount percentage.)
All banks work in the free Development environment, but for banks on OAuth, including Chase, you need to go through the Production approval vetting as a pre-requisite. Once you've been approved for Production (and if applicable for the given bank, gotten your security questionnaire approved as well -- I think Chase requires this) you can then access those banks in Development for free.
I will say that while annoying (especially for Chase, which has the most paperwork-type requirements for developers) this process should be totally doable for solo developers. You can put your own name as the legal entity name if you don't have a company. The Master Services Agreement (MSA) sounds scary but is just the contract between you and Plaid -- the legalese laying out what you're paying for, what Plaid is providing, and the rights and obligations of both parties. And when it comes to the security questionnaire, fill it out as accurately as you can, but you don't need to stress over it -- Plaid doesn't expect a solo hobbyist to have the same security measures as, like, a publicly traded company.