Question:
Which sense does it make to still asking LLMs coding agents to generate code in languages created to be edited by humans in those languages.
The source of the browser centered web was about pages source files easily editable by humans in text editors. We are still targeting our generated "applications" to those languages and what they have evolved to for our implementations.
What about an intermediate "agent application language", auditable by humans, representation generated by the agents model and then compiled in, still browser centric, I think about WASM here.
And what about if this agent "application language" could leverage natively AI models inference / agentic capabilities providing prompted / generated applications with those capabilities.
Maybe I'm missing something, comments are welcome. Thanks!
Sebastián.
PS:
I was refining the conversation with two of the most used AI assistants. Please take a look at the second prompt responses on both:
https://share.gemini.google/LC0W27sQoPAd
https://chatgpt.com/share/6a2c26c5-eab0-83e9-a20b-f4f5807e8e26
This proposes an homoiconic (code as data) RDF/XML stack where the model representation layers (human, agent, runtime) are serialized as graphs, as is depicted by the AIs prompted about that themselves.
They both seem to agree that graph layers with those three levels of abstraction can lead to a semantic-bytecode layer execution level (triples or quads ASTs encoding). All ontology-driven, deterministically processable by an AI and, for all, humanly auditable and visualizable by existing tools.
An integration stack needing some capability just needs to semantically query a deployed application used commonly aligned ontologies. Runtime (execution) could be just a matter of stream-processing raw RDF / Graph data (and code) and perform transformations given those capabilities.
More info at:
https://sebxama.blogspot.com/2026/05/microservices-agentic-infrastructure.html
Comments
Post a Comment