HN user

raviparikh

1,838 karma

Founder @ https://www.airplane.dev/ - developer platform for building internal tools

Prev founder @ https://heap.io/

Posts108
Comments100
View on HN
www.airplane.dev 3y ago

Airplane Autopilot: Build internal tools faster with an AI coding assistant

raviparikh
3pts0
aisafety.info 3y ago

AI Safety FAQ

raviparikh
1pts0
yoshuabengio.org 3y ago

AI Scientists: Safe and Useful AI?

raviparikh
2pts0
www.oneusefulthing.org 3y ago

It is starting to get strange

raviparikh
3pts0
www.cnbc.com 3y ago

JPMorgan Chase takes over First Republic after bank failure

raviparikh
2pts0
www.neelnanda.io 3y ago

Concrete Steps to Get Started in Transformer Mechanistic Interpretability

raviparikh
1pts0
www.airplane.dev 3y ago

AI represents a new type of platform risk to startups

raviparikh
1pts1
www.theverge.com 3y ago

AI suggested 40k new possible chemical weapons in just six hours

raviparikh
44pts46
www.alignmentforum.org 3y ago

Concrete Open Problems in Mechanistic Interpretability

raviparikh
1pts0
marginalrevolution.com 3y ago

The Nuclear Non-proliferation Treaty and existential AGI risk

raviparikh
1pts0
www.airplane.dev 3y ago

What generative AI can and can’t do

raviparikh
2pts1
www.forourposterity.com 3y ago

Response to Tyler Cowen on AI Risk

raviparikh
1pts0
ravisparikh.substack.com 3y ago

AI as smart as humans would be the most powerful entity in the world

raviparikh
1pts0
twitter.com 3y ago

Task-Driven Autonomous Agent

raviparikh
2pts0
www.forourposterity.com 3y ago

Nobody’s on the Ball on AGI Alignment

raviparikh
3pts0
www.reuters.com 3y ago

U.S. Copyright Office says some AI-assisted works may be copyrighted

raviparikh
2pts0
ravisparikh.substack.com 3y ago

The world can only end once

raviparikh
33pts64
worldspiritsockpuppet.substack.com 3y ago

Let's think about slowing down AI

raviparikh
3pts0
www.seedchecks.com 3y ago

Seed Checks

raviparikh
3pts0
www.airplane.dev 3y ago

No-code has no future in a world of AI

raviparikh
3pts0
arxiv.org 3y ago

Conversational Interaction with a Large Language Model for Software Development

raviparikh
3pts0
www.airplane.dev 3y ago

Ways to extend your company's runway without a layoff

raviparikh
2pts0
luttig.substack.com 3y ago

Is AI the New Crypto?

raviparikh
3pts5
twitter.com 3y ago

Using the new language model Claude to build an in-editor coding assistant

raviparikh
2pts0
www.washingtonpost.com 3y ago

Palantir Failed to Spot Pattern in SPAC Debacle

raviparikh
3pts0
www.sensible.so 3y ago

Sensible.so makes documents as accessible to software as APIs

raviparikh
2pts0
wp.nyu.edu 3y ago

More NLP Researchers Should Engage with AI Safety Concerns

raviparikh
3pts0
www.airplane.dev 3y ago

Airplane.dev raises $32M in Series B funding

raviparikh
90pts56
twitter.com 3y ago

Newsom signs California's biggest zoning reform into law

raviparikh
2pts0
steve-yegge.medium.com 3y ago

I left Google to join Grab (2018)

raviparikh
3pts2

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.

(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.

I'm one of the co-founders at Airplane - if you end up evaluating it, feel free to send me a note at ravi@airplane.dev if I can help.

I think there’s an opportunity to integrate LLMs so that non technical users can build on top of it using natural language.

We're currently working on this!

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.

I did not argue for this in my article!

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.

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.

To add on to what Josh said, the main value of Airplane is that we automate a lot of things that would normally require you to write a lot more additional code. So for example, if you build an admin panel using Airplane instead of doing so from scratch, we'll provide the following for you:

* A rich React component library that's optimized for internal tooling (tables, charts, etc) * Permissions, audit logs, and approval flows that are easily configurable * Integrations into various systems that an internal tool would normally have to integrate with (e.g. identity providers like Okta, Slack for notifications, etc)

So if you'd expect building that admin panel to take a few days or weeks of work, ideally with Airplane we can reduce that down to a few hours instead.

At a high-level, yes - the "scripts to apps / workflwos" tagline that Windmill advertises on their homepage is something Airplane does as well. That was what we initially launched with about a year ago. We also now support the ability to create more complex UIs in Airplane as well.

So for example, if you wanted to create an admin panel / customer dashboard at your company that has the following functionality, you could do all of this in Airplane:

* Display customer data that's retrieved from a SQL query or REST endpoint

* Allow users to select customers and view more details about their usage

* Have a button next to each customer that says "delete customer" which kicks off a Python script that deletes that customer's data

To add on to what Josh said, using Airplane for scheduling gets you a number of benefits over cron:

- Serverless - no need to maintain a cron server or worry about where the job is running

- Notifications - get notified in Slack or email if a failure happens

- Logging - we'll record every run, what happened, etc

- There are also a bunch of convenience features as well, e.g. having a native SQL integration so if you just want to run e.g. a query on a schedule, you can do so in minutes of work.

Thanks for the feedback. I'm Josh's co-founder Ravi.

There are several open source React libraries out there for tables, chart components, etc that I'd encourage checking out. But the key other thing that Airplane gives you, above and beyond a component library, is a deep integration with Airplane tasks (Lambda-like functions) that Josh mentioned above. So you can create a Table component where the data is populated by the results of running one of these functions, or a Button that triggers execution of these, etc. It would be hard to provide an OSS version of tasks since a big part of the value is the hosting/execution/etc, and Views primarily makes sense as integrated with that.

At a high level, the purpose of all of this is to save developer time. An admin panel that takes days or weeks to create ideally can be built in hours using Airplane. Using a high-quality component library can speed up that process, but the additional primitives that Airplane provides out of the box ideally should speed it up significantly more.

From a pricing perspective our Free tier is pretty generous and there are several startups using Airplane for free.

Appreciate you taking a look and sharing your thoughts!

I'm Ravi, Josh's co-founder at Airplane. Really appreciate the feedback!

I agree that there's a big market for GUI builders for rapid prototyping as you mention. Retool takes a great approach there, and we're very much not trying to copy them. Rapid prototyping likely won't be one of the main use cases for Airplane.

Instead, people are using Airplane to build more durable internal tools (eg admin panels), and for these use cases, we have many early users who prefer our code-based approach because they can version control it, extend it, etc. There's a lot less vendor lock-in than you get with using GUI-based platforms for building internal tools. We're not trying to compete with those platforms; instead, we're aiming to be adopted by a developer who prefers to build internal tools in-house, and sees Airplane as a much faster way of accomplishing that goal.

Thanks for taking a look!

Exactly my point. Maybe I got lucky, but to have gotten that lucky in the first place, I'd have to have world-class running speed at all.

Generating image compositions sounds fairly difficult to do by random. If you took 3 different objects and randomly placed them in a square canvas, the odds that they'd look reasonably placed seem pretty low. So 3/5 correct seems like a non-trivial accomplishment.

If you flip a penny 5 times and get 5 heads, you need to calculate that the chance of getting that particular outcome is 1 in 32. If you conduct the experiment often enough, you’re going to get that, but it doesn’t mean that much. If you get 3/5 as Alexander did, when he prematurely declared victory, you don’t have much evidence of anything at all.

This doesn’t make much sense. The task at hand is in no way equivalent in difficulty to flipping a coin. This is kind of like saying, “if you beat Usain Bolt in a race 3/5 times, that doesn’t mean anything; it’s like getting 3/5 coin flips to be heads.”