Show HN: Why write code if the LLM can just do the thing? (web app experiment)

I tried this too! Where every button on the page triggered a get or post request, but the consistency between views was non existent lol, every refresh showed a different UI Definitely fixable with memory for the views and stuff though but keeping it pure like this is a very cool experiment. Since yours is using a actual storage maybe You could try also persisting page code or making the server stateful and running eval() on generated code. Love this

With no routes, no controllers, no business logic, how can the capability exist? These are the core components of a web app and require extensive coding. I know we might eventually get there but not with the present state of technology. There is something fundamental missing about "intelligence" which must be solved before AGI can be approached, throwing more money and nVidia chips at the problem can only take you so far.

Nice experiment!

I'm using a similar approach in an app I'm building. Seeing how well it works, I now really believe that in the coming years we'll see a lot of "just-in-time generation" for software.

If you haven't already, you should try using qwen-coder on Cerebras (or kimi-k2 on Groq). They are _really_ fast, and they might make the whole thing actually viable in terms of speed.

You could also ask why use AI when writing the code is trivial?

Good work. I've been thinking about this for awhile and also experimenting with letting the LLM do all the work, backend logic plus generating the front-end and handle all front-end events. With tool use and agentic loops, I don't see any reason this can't work where it meets the latency needs (which hopefully could be improved over time).

But you're still generating code to be rendered in the browser. Google is a few steps ahead of this: https://deepmind.google/discover/blog/genie-2-a-large-scale-...

huh okay, so, prediction: similar to how interpreted code eventually was given JIT so that it could be as fast as compiled code, eventually the LLMs will build libs of disposable helper functions as they work, which will look a lot like “writing code”. but we’ll stop thinking about it that way

Just in time UI is incredibly promising direction. I don't expect (in the near term) that entire apps would do this but many small parts of them would really benefit. For instance, website/app tours could be just generated atop the existing ui.

This is brilliant. Really smart experiment, and a glimpse of what might - no what will be possible. Ignore the cynics. This is an absolutely brilliant thought experiment and conversation starter that lets us look ahead 10, 20, 50 years. This, IMHO, is the trajectory the Web is really on.

CSV is a lot lighter on tokens, compared to json, so it can go further, before a LLM gets exhausted.

Here's why I don't get why people are badmouthing AI assist tools from Claude for Excel to Cursor to any new AI assist tool.

Why not try it out, and if it doesn't work for you or creates more work for you, then ditch it. All these AI assist tools are just tools.

Maybe next step is have the llm create persistent tools from the queries it uses most often.

Everyone seems to be missing the point. Using an LLM to perform book keeping like this is akin to a business in the dot-com era hiring a programmer to help them go online. But since it's an LLM, the next step would be different. The LLM might initially do all the actions itself, but eventually it should train optimised pathways just for this purpose. It would become an app that isn't actually written out in code. Or alternatively, the LLM might actually dump its optimized logic into a program that it runs as a tool.

Yes, why not burn a forest to make a up of tea, if we can fully externalise the cost.

Even if LLMs do get 10x as fast, that's not even remotely enough. They are 1e9 times as compute intensive.

From openapi restful spec to claude code spec files. I mesn GraphQL kind of was pushing us towards a better rest / web API that doesnt necessarily constrain traditional APIs.

I think what your missing bud is that "writing the code" is caching for the LLM. Do you think caching is going away?

It's all fun & games until the D part of CRUD hits.

This definitely has that “toy” feel to it that a lot of eventually mainstream ideas have. It can’t work! But… could it?

Because it can't, and may never be able to. The lack of progress on making LLMs actually useful is not encouraging for future prospects of advancement, but we shall see I guess.

If anyone is interested in a CRUD serverless backend, I built https://saasufy.com/

I'm looking for users who want to be co-owners of the platform. It supports pretty much any feature you may need to build complex applications including views/filtering, indexing (incl. Support for compound keys), JWT auth, access control. Efficient real-time updates. It's been battle tested with apps with relatively advanced search requirements.

Amazing. This is the Internet moment of AI.

The Internet took something that used to be slow, cumbersome, expensive and made it fast, efficient, cheap.

Now we are doing it again.

What happens when you separate the client and the server into their own LLMs? Because obviously we need another JS framework.

Why have an internet connection when your local LLM can just speak the HTTP protocol?

> ANTHROPIC_MODEL=claude-3-haiku-20240307

Why?

Amazing! Very similar approach, would love to heae what you think: https://github.com/gerkensm/vaporvibe

Code is just ‘compiled’ intelligence.

> why generate code at all?

but you are still generating code....?

Everything in engineering is a tradeoff.

Here you’re paying for decreased upfront effort with per-request cost and response time (which will go down in future for sure). Eventually the cost and response time will both be low enough that it’s not worth the upfront effort of coding the solution. Just another amazing outcome of technology being on a continual path of improvement.

But “truly no-code” can never be deterministic - even though it’ll get close enough in future to be indistinguishable. And it’ll always be an order of magnitude less efficient than code.

This is why we have LLMs write code for us: they’re codifying the deterministic outcome we desire.

Maybe the best solution is a hybrid: after a few requests the LLM should just write code it can use to respond every time from then on.

So basically we need a JIT compiler for LLMs.

You just justified the mass layoffs for me

"What hardware giveth, software taketh away." IOW this is exactly how things will work once we get that array of nuclear powered GPU datacenters.

Why not use the code… as a memory?

I’ve been doing this for more than a year now, including APIs.

Where it breaks down is in the repeatability of experience from user user. It needs to have instructions that define the expectations of user experience across many people. Which ends up being a spec in code or code as spec.

Imagine if your door were to be generated every time you used it. The doorknob, key, even hinges would be different each time.

Ultimately, it is a new way to provide functionality but doesn’t quite remove all the code.

Honestly if you ask yourself this you need to understand better why clients pay us.

I can't see myself telling a client who pays millions a year that their logo sometimes will be in one place and sometimes in another.

The fatal problem with LLM-as-runtime-club isn’t performance. It’s ops (especially security).

When the god rectangle fails, there is literally nobody on earth who can even diagnose the problem, let alone fix it. Reasoning about the system is effectively impossible. And the vulnerability of the system is almost limitless, since it’s possible to coax LLMs into approximations of anything you like: from an admin dashboard to a sentient potato.

“zero UI consistency” is probably the least of your worries, but object permanence is kind of fundamental to how humans perceive the world. Being able to maintain that illusion is table stakes.

Despite all that, it’s a fun experiment.

like how moving money atomically between 2 remote databases was a solved problem then some guy said, "Yes but let's reinvent that using blockchain!" and all the dystopic effects the world has seen since. indirectly leading to the overinvestment in massive amounts of GPU hardware which then got repurposed by the AI/LLM folks. funny that

Honestly if you ask yourself this you need to understand better why clients pay us.

I can't wait to build against an API whose outputs can radically change by the second!

Usually I have to wait for the company running the API to push breaking changes without warning.

if only was performance... it's a fucking wastage of energy and water.

> When inference gets 10x faster, maybe the question shifts from "how do we generate better code?" to "why generate code at all?"

Because we live on a planet with finite resources and running certain problems in an LLM is probably one of the most computationally expensive ways of solving them?

> Why write code if the LLM can

I mean, I'll do the stuff I'm confident I can do, because I already can.

I'll let the AI do the stuff where I'm confident it can't fuck shit up.

I tried Xcode's built-in ChatGPT integration and Claude for some slightly-above-basic stuff that I already knew how to do, and they suggested some horribly inefficient ways of doing things and outdated (last year) APIs.

On the other hand, what I presume is Xcode's local model is nice for a sort of parameterized copy/paste or find/replace though: Slightly different versions of what I've already written, to reduce effort on bothersome boilerplate that can't be eliminated.

Another version of this question: why have high level languages if AI writes the code abd tests it?