Launch HN: Optic (YC S18) – Automate Routine Programming
Hi — I’m Aidan YC (S18), the founder of Optic (https://useoptic.com). We’re building a smarter code generator that helps developers write and maintain the tedious parts of their codebase. Optic is fully open source (https://github.com/opticdev) and all our code is MIT licensed.

A really simple use case that Optic enabled for some of our early users is keeping their backend and frontend in sync. Optic can read the endpoints in a backend and use that to generate the HTTP requests on the frontend. It even maintains that code over time so if the backend is updated, a pull request is generated to update the networking code. You can test that here: https://github.com/acunniffe/optic-networking-code-demo.

We have also had teams configure Optic to:

- Write/Maintain standard tests for their React components
- Migrate to GraphQL by generating wrappers for each endpoint
- Generate/Maintain CRUD routes from models
- Wrap their Tensorflow models in APIs

There’s a checkered history of optimism and failure around automated programming and many tools have promised to make developers' lives easier. In each generation of programmers there’s an acknowledgement that much of the code we write is routine, but none of the solutions have caught on. I failed once before when I founded Dropsource. While we built that product into one of the most popular tools for non-programmers to build mobile apps, we failed at our goal of building a tool we ourselves or other developers would use.

I left the company and went into research mode for around 18 months. A lot of the automated programming projects do their functional job well, but when it come time to integrating into a developer’s workflow they are littered with tradeoffs. Automation isn’t worth it if it means giving up control, rewriting lots of code, rebuilding your app visually, describing your project in some foreign dsl, or becoming tied to a vendor. Many of these projects haven’t caught on because the tradeoffs of using them have been too high.

When I started working on this problem again I was determined to get the developer experience right. For me this meant making Optic:

- work with your existing code
- plug in to your favorite IDE
- useful throughout the lifetime of your project

I knew that whatever product I ended up building would need to interface with source code so I started building an API for code that let you:

GET JSON objects describing different types of code. Powered by a regex like pattern matcher we wrote that walks AST Trees.

PUT new values of the same shape back to update the code. This was the hardest part by far. We ended up training decision trees on different programming languages using the raw code and the resulting AST tree as input. We use these models to regenerate code in the smallest sections possible so formatting and manual changes are preserved.

POST new code into the project. This was actually the easiest. A generator can be reformulated as a Parser + Mutator so we bootstrapped all the generation in Optic by combining the GET / PUT functionality.

This API was really powerful and it became the foundation of Optic. Generating code, doing transformations, syncing projects — all Optic’s major features are built on top of this API. It’s such a solid foundation (you get parsing, generating and the round-trip problem in a box) that I believe a lot of new meta-programming tools will be built on our platform. Our work is open source (https://github.com/opticdev) and there will always be a free-forever version available. We plan to make money from some specialty features aimed at larger teams.

It’s still the early days but we hope to build Optic into a valuable open source resource that improves the workflow of developers and their teams. I’m looking forward to hearing your feedback, experiences and ideas for tasks we should automate. Thanks!