joshma

Founder @ https://airplane.dev here - putting in a shameless plug for Airplane, where you _do_ write code from scratch. :) I think it depends on the builder and use case, and it's not a fit for everything, but our users like / need to manage their tooling as code and are more productive for it.

It's interesting because we came to a different conclusion with Autopilot[0] - context and learning is incredibly important for result quality, and gpt4 doesn't (yet) support fine-tuning but will soon, and we'll definitely be taking advantage of that. Not just for quality, but also for speed (less time spent gathering context and processing input tokens).

My view is, everyone has access to chatgpt and github copilot, and so the idea is to provide value in excess of what chatgpt/copilot can do. Part of that is embedding it in the UI, but (especially for internal tools, which tend to be shorter) the improvement isn't huge over copy/paste or using copilot in vs code.

However, beyond UI integration, we can intelligently pull context on related files, connected DBs/resources, SDKs you're using, and so on. And that's something chatgpt can't do (for now). The quality of response, from what we saw, dramatically improved with the right docs and examples pulled in.

And yes, gpt4 does much better on JS (React specifically) and Python. It's just whatever it's trained on, and there's a ton more JS/Python code out there.

[0] https://www.airplane.dev/autopilot

2 - correct, depending on the task type we still call through to node etc. But the CLI also provides a dev UI and other niceties specific to Airplane.

3 - correct, the code is built and pushed to us, similar to Heroku.

Our value prop ultimately is that 1) you can build tools like admin dashboards, data migration scripts, one off devops operations, etc, into production grade web apps and 2) you can do this using code!

cron is a popular starting point on Airplane! We see our users creating tasks that are semi automated, but then adding manual tasks later (but then automating those tasks as well). The nice property of Airplane is that it's very composeable and extensible over time.

(Appreciate the feedback! We clearly need to continue to improve how we explain the product. :))

It's probably easiest to explain in terms of what a developer does on Airplane:

1. Dev writes code (e.g. see our Getting Started for views[0]) - this can be simple Python scripts, JS views, shell scripts, etc.

2. Dev uses the `airplane` CLI locally to run and test the code

3. Dev runs `airplane deploy` or pushes to GitHub to deploy the code to Airplane

4. Dev's teammate (or dev) can now visit app.airplane.dev to run the code (views, tasks, runbooks) - the execution defaults to Airplane's servers, but you can also use our self-hosted agents[1] to move the execution (data plane) to your own cloud environment.

It's similar to GitHub actions in architecture (but for a different domain).

[0] https://docs.airplane.dev/getting-started/views

[1] https://docs.airplane.dev/self-hosting/agents

(I'm one of the founders at Airplane.) It started as a reference to "lightweight control plane[0] for your company" - but also the domains were loosely available.

[0] https://www.cloudflare.com/learning/network-layer/what-is-th...