A major trend of this year has been vibe coding – using LLMs to create software from the ground up, without a human ever interacting with the source code directly.

The current consensus is that vibe coding isn’t quite ready yet for developing critical production software. But while those issues are being worked out, we can start thinking about what the next thing after vibe coding could look like. One question that comes to mind: Why even bother with creating source code in the first place?

Auto-regressive transformers are the ideal simulation machine. LLMs in particular excel at mimicry, at pretending to be whatever persona they were exposed to in their training data. For the most part, the simulation is that of a human in various text-producing roles. Be it as the author of a book, a contributor to Wikipedia, a commenter on Reddit, or an ever-helpful assistant in a chat session.

However, LLMs are also quite adept at simulating machines of the non-biological kind. Jonas Degrave wrote about this eerie ability of LLMs back in the days of GPT 3.5 in his 2022 article on Building A Virtual Machine inside ChatGPT . In his article, Jonas showed that ChatGPT could pretend to be a Linux terminal quite convincingly. Not only that, it happily mimicked executing Python code, or browsing websites through lynx and curl (to note: in those days, ChatGPT didn’t have any “tools” to actually perform any of these feats). Of course, the contents of any internet access observed within this Linux terminal session were not real – they were in fact hallucinated to the most plausible continuation that the LLM was capable of producing.

Cutting out the middle man – code-less vibe-“coding”

If LLMs can just pretend to be a piece of software, then why even bother with creating that piece of software in the first place? Why have an LLM generate code first, when it can just make things up as the user interacts with the application?

I implemented (well, vibe-coded) and illustration of this idea, which you can download from the following link:

-> Mirage (Github)

When using Mirage, you just tell it in a short description what kind of app you’d like to use. The app you request does not need to exist as “real” code-based software. It can be anything you’d like it to be.

Here you can see Mirage hallucinate a to-do manager:

Can it hallucinate a Linux terminal? Sure can!

Mirage works by taking your app description and then having an LLM generate a plain HTML (+ embedded CSS) to render that app’s initial view.

Once you click a button in your app or enter text into one of its input fields, that interaction is sent back to the LLM, with a request to generate an updated HTML view showing the new state of the app. And so on and so forth. Besides the HTML, which really is just an efficient way for the LLM to get a user interface to appear on your screen, there is no code that ever gets generated1. All the behaviors and functionalities of your app are made up by the LLM as you use it.

The many benefits of hallucinating software

Hallucinating apps like this has many immediate benefits!

For one, you don’t have to worry about bugs in your code. No compilation errors to battle with. Your software will never crash with a hard to decipher stack trace. In general, the LLM will try its very best to make the app behave just the way you’d expect it to. Or at least the way it expects you to expect it to.

Another big benefit of hallucinated software is that you never have to properly plan out or think through your software design ahead of time. You don’t like what your app did? Just tell the LLM to do something different and it will comply. Your hallucinated app will morph under your command like a shapeshifter – no pesty source code to refactor or maintain every time you want to change how your app works. Heck, you can even change the app in the middle of using it. In a sense, hallucinated software is the ultimate malleable software!

Of course, this wouldn’t be an honest article if I wouldn’t also mention some, well, limitations of this approach:

1. There’s no real persistence to talk about. Any data you enter in your app just lives in the LLM’s context. In the current version of Mirage, that means that it’s gone as soon as you close your browser tab or shut down the backend server.
2. Your app won’t always be reliable. Sometimes it won’t do the thing it claims to do. Sometimes it will forget or modify your data. In general, it’s not exactly what one might call “deterministic”. But then again, what did you expect when I told you that your app was being hallucinated?
3. There’s several limitations which are not limitations of the approach in principle, but rather limitations of its current implementation in Mirage:

• The only supported input modalities are clicks on UI elements and text inputs. You can’t draw, pan or drag.
• There is no compaction or optimization of the LLM context – once you reach the maximum context length, your app will stop working. Any data you put into it will be gone at that point. You might call it data loss, but I prefer to think of it as built-in data lifecycle management. (Such advanced features would require a lot of vibe-coding to get to work in a code-based app!)
• No error handling to speak of. If something goes wrong, expect your app to just become non-functional. You might or might not see an error message be printed out in the backend.
• Mirage currently hard-codes Claude Haiku 4.5 as its model. Though popping in other LLMs should be easy.

1. Generating app views is quiite slow. Not something I’d ever want to* actually* interact with. Once we get widely available text diffusion models (e.g. Gemini Diffusion) this might change. (I applied a 4x speedup to the generation periods in the videos in this post. Here’s the above to-do manager example without any speedup.)
2. Ok, ok, this is really just a toy and proof of concept. But it’s kinda fun, isn’t it?

Realtime modification

Mirage provides two features that can help you morph your software as you go:

1. While using your app, you can send a request to make a change to the LLM in the text field at the bottom of the screen. The LLM will take your feedback into consideration and update your app right away. If you’re used to conventional vibe coding or, well, coding, you might wonder what happens to your data when you transform your running app like that. Rest assured – there are no data migrations to worry about. The LLM will do its absolute best (or, let’s be honest, make a haphazard attempt) to carry over any existing state as your app changes.
2. Your app got stuck or you modified it into a state that you’re not happy with? Just use the handy time-travel slider to revert back to a previous state. Then click the “Fork” button to fork off a new tab from there. Multiverse interpretation of quantum software mechanics for the win!

Pro tip: If you prefer making classic code-based software using AI-assisted coding, but still want to experience the power of time travel and forking, you might want to check out the forking feature in Sculptor!

Additional examples

Another interesting benefit of hallucinated software is that such software can leverage the full power of LLM’s natural language understanding capabilities. Here’s Mirage hallucinating a LISP interpreter that doesn’t require you to be proficient in LISP – you can just talk to it in regular English (or another language of your choice), and it will translate your requests automatically into LISP code.

You can also do fun UI styles. Here’s a file manager in the look of a Windows 95-era program. Note how it also makes up a matching text editor and pre-populated file contents as needed.

What interesting apps can you think of? Let me know in the comments!

Join me!

I’m a researcher at Imbue. If you’re interested in figuring out how AI agents can benefit everyone, and in shaping the future of AI-driven software development (largely still code-based, for the time being), check out our Careers page!

Footnotes

1. You could imagine a future version of mirage avoid HTML altogether and use an image generation model (diffusion-based or otherwise) to render pixels directly to your screen. There are a few such efforts for generating game worlds already! ↩︎