[foota]

I was sort of thinking about a similar idea recently. What if you wrote something like a webserver that was given "goals" for a backend, and then told agents what the application was supposed to be and told it to use the backend for meeting them and then generate feedback based on their experience.

Then have an agent collate the feedback, combined with telemetry from the server, and iterate on the code to fix it up.

In theory you could have the backend write itself and design new features based on what agents try to do with it.

I sort of got the idea from a comparison with JITs, you could have stubbed out methods in the server that would do nothing until the "JIT" agent writes the code.

[vincentjiang]

Fascinating concept, you essentially frame the backend not as a static codebase, but as an adaptive organism that evolves based on real-time usage.

A few things that come to my mind if I were to build this:

The 'Agent-User' Paradox: To make this work, you'd need the initial agents (the ones responding and testing the goals) to be 'chaotic' enough to explore edge cases, but 'structured' enough to provide meaningful feedback to the 'Architect' agent.

The Schema Contract: How would you ensure that as the backend "writes itself," it doesn't break the contract with the frontend? You’d almost need a JIT Documentation layer that updates in lockstep.

Verification: I wonder if the server should run the 'JIT-ed' code in a sandbox first, using the telemetry to verify the goal was met before promoting the code to the main branch.

It’s a massive shift from Code as an Asset to Code as a Runtime Behavior. Have you thought about how you'd handle state/database migrations in a world where the backend is rewriting itself on the fly? It feels to me that you're almost building a lovable for backend services. I've seen a few OS projects like this (e.g. MotiaDev) But none has executed this perfectly yet.

[barelysapient]

It’s funny I’ve been pondering something similar. I’ve started by writing an agent first api framework that simplifies the service boundary and relies on code gen for sql stubs and APIs.

My next thought was to implement a multi agent workforce on top of this where it’s fully virtuous (like a cycle) and iterative.

https://github.com/swetjen/virtuous

If you’re interested in working on this together my personal website and contact info is in my bio.

[timothyzhang7]

The "JIT" agent closely aligns with the long-term vision we have for this framework. When the orchestrating agent of the working swarm is confident enough to produce more sub-agents, the agent graph(collection) could potentially extend itself based on the responsibility vacuum that needs to be filled.