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

Robert Martin teaches us that codebase is behaviour and structure. While behaviour is something we want the software to do. The structure can be even more important because it defines how easy if possible to evolve the behaviour.

I'm not entirely sure why I had an urge to write this.

This is incredibly interesting.

Now what if you ask it to optimize itself? Instead of just:

  prompt: `Handle this HTTP request: ${method} ${path}`,

Append some simple generic instructions to the prompt that it should create a code path for the request if it doesn't already exist, and list all existing functions it's already created along with the total number of times each one has been called, or something like that.

Even better, have it create HTTP routings automatically to bypass the LLM entirely once they exist. Or, do exponential backoff -- the first few times an HTTP request is called where a routing exists, still have the LLM verify that the results are correct, but decrease the frequency as long as verifications continue to pass.

I think something like this would allow you to create a version that might then be performant after a while...?

You're still operating with layers of lexical abstraction and indirection. Models full of dated syntactic and semantic concepts about software that waste cycles.

Ultimately useless layers of state that the goal you set out to test for inevitably complicates the process.

In chip design land we're focused on streamlining the stack to drawing geometry. Drawing it will be faster when the machine doesn't have decades of programmer opinions to also lose cycles to the state management.

When there are no decisions but extend or delete a bit of geometry we will eliminate more (still not all) hallucinations and false positives than we get trying to organize syntax which has subtly different importance to everyone (misunderstanding fosters hallucinations).

Most software out there is developer tools, frameworks, they need to do a job.

Most users just want something like automated Blender that handles 80% of an ask (look like a word processor or a video game) they can then customize and has a "play" mode that switches out of edit mode. That’s the future machine and model we intend to ship. Fonts are just geometric coordinates. Memory matrix and pixels are just geometric coordinates. The system state is just geometric coordinates[1].

Text driven software engineering modeled on 1960-1970s job routines, layering indirection on math states in the machine, is not high tech in 2025 and beyond. If programmers were car people they would all insist on a Model T being the only real car.

Copy-paste quote about never getting one to understand something when their paycheck depends on them not understanding it.

Intelligence gave rise to language, language does not give rise to intelligence. Memorization and a vain sense of accomplishment that follows is all there is to language.

[1]https://iopscience.iop.org/article/10.1088/1742-6596/2987/1/...

Because nobody actually wants a "web app". People want food, love, sex or: solutions.

You or your coworker are not a web app. You can do some of the things that web apps can, and many things that a web app can't, but neither is because of the modality.

Coded determinism is hard for many problems and I find it entirely plausible that it could turn out to be the wrong approach in software, that is designed to solve some level of complex problems more generally. Average humans are pretty great at solving a certain class of complex problems that we tried to tackle unsuccessfully with many millions lines of deterministic code, or simply have not had a handle on at all, like (like build a great software CEO).

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.