Whether covered under fair use or not, the laws around copyright today did not anticipate this use case. Congress should pass laws that clarify how data is and isn’t allowed to be used in training AI models, how creators should or shouldn’t be compensated, etc - rather than speculating whether this usage technically does or doesn’t comply with the law as-is.
I make about $4,000 per million streams on Spotify for the tracks I’ve released independently. For label releases I make less, but the label promotes them so that sometimes results in more net revenue. I have a bit over 10M Spotify streams over the last 3 years.
Also, Spotify promotes my music via editorial playlists and algorithmic (eg Radio or Discover Weekly), so I’m probably making a lot more total revenue than I would have on iTunes.
Not sure if this is what you're implying, but I think it's a mistake to think of YC as a monolithic organization that makes decisions by saying, "idea X is good, we should fund teams doing it."
More likely, each of the teams doing each of these startups interviewed with completely different partners who had no idea of the other startups even existing, and in that interview, they thought the founders seemed solid and had thought through their idea well, and chose to fund it. It's even possible some of the people doing these ideas came up with the idea after they got into YC (i.e. they pivoted) - some of the most successful YC startups were companies that pivoted mid-batch (e.g. Brex).
In general YC doesn't want multiple shots on goal in a specific market area. They want as many shots on goal as possible among great founders in general.
And similarly to climate, many people who signed this letter are academics who do not appear to have any financial incentive to push for government regulation.
The richest person in the world, Elon Musk, is a climate entrepreneur who got there in part due to climate-driven government subsidies. Just because someone made money off it though does not mean that climate change is a fake concern.
(Airplane founder here) Airplane isn't YC backed. Though interestingly my prior startup, Heap, went through YC and has tons of YC-backed competitors (Amplitude, Mixpanel, Posthog, etc).
Personally I like that YC remains agnostic to the ideas and is willing to back competitors because it ultimately means more great startups get funded. Later-stage investors care more about conflicts because being involved at the level of taking a board seat matters a lot more for conflicts.
At this point they've backed 1000s of companies; if they had to vet that entire list for conflicts to back their next batch it would be incredibly difficult. Also, given the stage they're investing at, tons of companies pivot and end up competing even if they didn't start out that way.
Yes, Cowen argues against the idea we can anticipate consequences of technological change, and the specific consequence he focuses on is the idea of existential risk stemming from AI. He says because technology is unpredictable, we shouldn’t try to predict the type of risk imposed by AI, and we should mostly just accept that this change will happen and cope with it afterward. This stance is what I was arguing against in the post.
> But to wish to halt AI advancement requires an unhealthy mix of pessimism and overconfidence in your predictive powers.
That’s perfectly valid! No one is obligated to respond or engage with any specific argument. But my point was that if you do choose to engage, saying “the world didn’t end before so it will be fine now” is invalid.
Thanks for taking the time to read the article and comment. Appreciate your feedback. As you point out, my last couple paragraphs were somewhat speculative and handwav-y. Do you have an alternative viewpoint on what allows LLMs to be able to somewhat accurately answer complicated math questions, despite lacking an explicitly programmed math solver? It sounds like you may be better informed than me–would love to hear your thoughts.
> that the author clearly didn't read. I guess there's too many scary maths for a "layman".
No need for the personal attack. I did read the paper and the math in the paper is not particularly complicated.
California and New York law states that you have to include salary ranges in job posts, from my understanding, so it might be worth checking their job board to see if they list them there.
We’re doing pretty well! The majority of people using Airplane aren’t comparing it to Retool or any other products, but rather to building internal tools in-house. Since Airplane takes a code-based approach there are lots of eng teams that try it out who would never otherwise consider the low-code/no-code platforms. So there’s a lot of addressable market.
Glad you liked Heap :) That was a much more crowded market!
I cofounded Airplane.dev which you may want to look at. Everything you build in Airplane is normal JS/Python/React etc code that you can store in your codebase, version control, setup environments against, etc.
Neat idea–Spotify seems to be proliferating a massive amount of playlists for every conceivable mood, genre, decade, country, etc in an attempt to seemingly capture what this tool can do automatically. I think a lot of the Spotify "official" playlists are actually partially or completely algorithmically driven as well based on your personal listening history.
I co-founded Airplane.dev, which a lot of companies use as a much simpler, serverless, user-friendly alternative to cron: https://www.airplane.dev/schedules
We have companies running hundreds of concurrent schedules on our platform. Send me a note at [email protected] if you'd like to chat about it.
Agree with this post. Low-code lets a non-engineer build 80% of an app quickly, but then ultimately that last 20% requires engineering work and it ends up taking more total eng/IT time to create something far less maintainable and useful.
I think the best low-code platforms are ones that are ultimately built on top of code (eg Webflow, where the underlying representation is normal HTML/CSS/JS). I wrote a blog post about how I think low-code platforms are broken and how they could be fixed: https://www.airplane.dev/blog/how-to-fix-low-code-with-more-...
> That’s why we don’t believe in low/no-code tools: they get you to 50% of what you want quickly, but you generally aren’t able to customize the last 50%, and have to build from scratch to get to an ideal outcome.
Agree - low-code software has tons of problems that all stem from things not being expressible in code (hard to version control, hard to do code reviews, too much vendor lock-in, etc).
It's interesting to see Retool say this in a blog post, since their core offering (the UI builder) is built as a proprietary low-code platform with an underlying domain-specific language. I co-founded a company called Airplane.dev which takes a much more code-based approach to building UIs, workflows, and other internal tools due to these pain points with existing low-code platforms.
With this launch it seems like Retool is taking some design cues from Airplane (or maybe just independently coming to the same conclusions). We've had a code-based Workflow/Cron tool for about a year now. I'm excited to play with Retool's version and see how it compares.