My experience with actually trying this is that current LLMs benefit greatly from having a framework to build on.

More code in the context window doesn't just increase the cost, it also degrades the overall performance of the LLM. It will start making more mistakes, cause more bugs, add more unnecessary abstractions, and write less efficient code overall.

You'll end up having to spend a significant amount of time guiding the AI to write a good framework to build on top of, and at that point you would have been better off picking an existing framework that was included in the training set.

Maybe future LLMs will do better here, but I wouldn't recommend doing this for anything larger than a landing page with current models.

Why not code in assembly?

I kid but any reason you can think of applies to app development too.

1. Good abstractions decrease verbosity and improve comprehension

2. Raw HTML/CSS/JS are out of distribution just like assembly (no one builds apps like this)

3. Humans need to understand and audit it

4. You'll waste time and tokens reinventing wheels

This inuitively makes sense. LLMs mimic human behavior and thought, so for all the reasons you'd get lost in a pile of web spaghetti or x86, so would an LLM.

A few reasons:

1. Unlimited projects: when you spin up traditional backends, you usually use VMs. It's expensive to start many of them. With Instant, you create unlimited projects

2. User experience: traditional CRUD apps work, but they don't feel delightful. I you want to support features like multiplayer, offline mode, or optimistic updates, you'll have to write a lot more custom infra. Instant gives you these out of the box, and the agents find it easier to write than CRUD code

3. Richer features: sometimes you'll want to add more than just a backend. For example, maybe you want to store files, or share cursors, or stream tokens across machines. These often need more bespoke systems (S3, Redis, etc). Instant already comes with these out of the box, and the agents know how to use them.

There are a few demo sections in the post that show this off. For example, you can click button and you'll get a backend, without needing to sign up. And in about 25 lines of code, you'll make a real-time todo app.

simple. you reduce the surface that you need to manage and shift that responsibility to the framework.

choose a good one and your can save you and your llms 1000s of decisions and future maintenance overheads.

frameworks exists because they scale.

Echoing other thoughts here but also, it's like getting your first 10,000+ lines of output code for 0 token cost, and no prompting effort, no back and forth or testing etc.

Just jump straight to business logic, scaffolding is done for you already.

I think in your question as well is an idea that apps from now on will be bespoke, small and unique entities but the truth is we are still going to be mostly solving already solved problems, and enterprise software will still require the same massive codebases as before.

The real win of frameworks is they keep your workers, AI or human, constrained to an existing known set of tools and patterns. That still matters in long term AI powered projects too. That and they provide battle hardened collection of solutions that cover lots of edge cases you would never think to put in your prompts.

It probably has more to do with the body of knowledge it draws on than the suitability. I assume it burns more tokens to stay vanilla, as more effort is involved in implementing patterns more readily available "off the shelf".

Its build in guard rails.

Its potentially also reduced context it has to know.

Its also a very good way to scale. Lets build a very small and well tested library for x, llm uses x for case y. it doesn't have to worry about x, its content, its security.

same reasons human do. context and abstraction.

validation -- you're using already validated components instead of relying on the LLM to create them and ensure they are validated

You don't necessarily, but each token costs money for the AI to spit out. And probably more money when that output is used as input later. Delegating to a library makes sense financially.

[dead]