There's a mental process in which a programmer understands the problem, the context in which the problem happens, as well as the solution to it, codified by -- code.
In this framework, the code is just a byproduct of the understanding.
Whenever understanding is more refined -- either by better understanding the domain or by better modelling the solution as a formal system -- code gets changed.
But code changes are just instantiations of changes in understanding, in the underlying theory of what is happening, and why certain things are done this way, and why certain things are done that way.
Vibecoding
Vibecoding, understood as shipping code one hasn't even read, is the exact opposite.
There's perhaps an argument to be made that generating code and then understanding it, modifying it, and only then shipping it, is compatible with theory building.
But vibecoding as such, where you ship an entire app or multiple apps without reviewing how they were built, and why certain choices were made, is not compatible with this view, unless you significantly dilute what a theory is.
Since you don't know how the problem was solved, why certain architectural choices were made, why this function was used and not that function, why this library, and not that one, and so on -- you don't have an underlying theory, and therefore a formalization of the solution for the problem that was solved.
You just know that it was solved, or wasn't solved.
Proliferation of code
GPTs, or generative pre-trained transformers generate text, and in the case of coding agents, they generate code.
It is exceedingly rare for a coding agent to delete code, but it is very frequent for them to generate code.
This may change in the future, but the overall trend with coding agents is more code, not less.
If you don't use a coding agent, but instead have a theory of the problem and a theory of the solution in your head, with time, your codebase is also expected to grow.
As you encounter new edge cases, new aspects of the problem, it is expected that you will express your theory with more words, because you will add more detail, this detail reflecting your more detailed understanding.
Coding agents will add much more code, and with much greater frequency than humans will.
Coding agents will also train human operators (of the vibecoding variety) to expect code generation as normal, which will mean that this code generation is not a once type of deal.
Code generation will thus beget more code generation, increasing the size of the codebase significantly.
This increase is, of course, not followed with a deeper understanding and a more developed theory.
The theory was never there -- except maybe represented in the weight activations of an LLM, but that is also doubtful -- so there's no depth to be added.
Therefore:
Much more code.
Still no theory.
Context windows
I said before that LLMs are very additive creatures, and that they rarely delete code.
They are also creatures with limited context windows.
I want to be clear that this is only the current state of how they are.
It is entirely imaginable that later generation LLMs will end up generating fewer tokens net (meaning that they will more frequently remove code and rewrite things to fit an underlying theory better).
But it doesn't seem the case today.
Likewise, context windows grow.
We may see extremely large context windows in the future.
With those two epistemic disclaimers out of the way, I claim that this proliferation of code will lead to slower progress on any given vibecoded project once it reaches a certain level of complexity, measured in the number of tokens representing the codebase.
So, if an underlying "theory" (if there ever was such a thing when vibecoding) used by an LLM has created a codebase, after a sufficient number of iterations, it will be very difficult for a new instantiation of an LLM to accurately grasp what the theory of that codebase is.
It simply will not fit the context window, and README files are of limited use.
The larger the codebase, and more self-contained, the more expressed this problem will be.
Presumably contract-based codebases could be different, where there are encapsulated units of meaning and you can make changes to each service or module without having to understand the entirety of it.
However, it seems that the overall understanding of the problem-space and how it has been solved (formalized as code) will not be available, even if modularity partially solves the problem.
Therefore, the older and bigger and more vibecoded a codebase gets, the more difficult will it be to add new functionality or change existing functionality without breakages.
Vibecoding will therefore almost immediately create legacy projects, legacy projects meaning projects where there's little theory to rely on and you risk breakages by making changes.
Longevity
Business relationships are usually built with longevity in mind.
When a business buys a service, whether this is API access or a SaaS product, or anything else, there's an implicit understanding that this product will be maintained.
Often, there's an explicit understanding as well.
Maintenance and improvement of a product are in fact the cornerstone of business relationships.
It's not enough to deliver something that works at a given point in time, it is expected that you will also grow that thing, that you will shape it to cover specific problem areas of different customers, and that you will ensure it is free from vulnerabilities, and more.
Vibecoded solutions, built with modern LLM, work almost immediately, at least for certain use cases.
You can in fact not even look at code and just ship it, and it's probably going to work out fine.
If you pair it with some tests, and some documentation, you could very well have a product that someone will buy.
But the question is: what happens in, say, five years?
If you keep vibe-adding features, and somehow keep getting customers to pay for this thing, what happens once the codebase becomes so complex that an LLM cannot fit it inside its "brain"?
And this isn't just about context windows -- even if context windows were to grow at a rate sufficient for ingesting extremely large codebases, there's still the issue of a lack of theory underlying the problem.
The gambit for vibecoders, at least those that don't intend to pull out after a year or two in business, is that AI tools will grow in a) context window sizes and b) general intelligence capable of theory building at least as fast as they grow their codebases.
This may happen, or may not happen, but it's definitely a gambit.
Predictions
My prediction is that LLMs won't follow with context windows and complete understanding capable of sufficient theory building as fast as they will generate code.
This in practice means that I predict that companies employing the vibecoding paradigm will hit a wall in growth, sales, relationship building, and longevity.
A vibecoding company is therefore a company I would short.
The more vibey it is, the shorter the position I would take.
I need to figure out how I should best formalize this as a formal prediction that can be judged true or false, but this is how I am thinking about it at this moment.
Theory building
Programming is theory building [1] .
There's a mental process in which a programmer understands the problem, the context in which the problem happens, as well as the solution to it, codified by -- code.
In this framework, the code is just a byproduct of the understanding. Whenever understanding is more refined -- either by better understanding the domain or by better modelling the solution as a formal system -- code gets changed. But code changes are just instantiations of changes in understanding, in the underlying theory of what is happening, and why certain things are done this way, and why certain things are done that way.
Vibecoding
Vibecoding, understood as shipping code one hasn't even read, is the exact opposite.
There's perhaps an argument to be made that generating code and then understanding it, modifying it, and only then shipping it, is compatible with theory building.
But vibecoding as such, where you ship an entire app or multiple apps without reviewing how they were built, and why certain choices were made, is not compatible with this view, unless you significantly dilute what a theory is.
Since you don't know how the problem was solved, why certain architectural choices were made, why this function was used and not that function, why this library, and not that one, and so on -- you don't have an underlying theory, and therefore a formalization of the solution for the problem that was solved.
You just know that it was solved, or wasn't solved.
Proliferation of code
GPTs, or generative pre-trained transformers generate text, and in the case of coding agents, they generate code.
It is exceedingly rare for a coding agent to delete code, but it is very frequent for them to generate code.
This may change in the future, but the overall trend with coding agents is more code, not less.
If you don't use a coding agent, but instead have a theory of the problem and a theory of the solution in your head, with time, your codebase is also expected to grow.
As you encounter new edge cases, new aspects of the problem, it is expected that you will express your theory with more words, because you will add more detail, this detail reflecting your more detailed understanding.
Coding agents will add much more code, and with much greater frequency than humans will. Coding agents will also train human operators (of the vibecoding variety) to expect code generation as normal, which will mean that this code generation is not a once type of deal. Code generation will thus beget more code generation, increasing the size of the codebase significantly.
This increase is, of course, not followed with a deeper understanding and a more developed theory. The theory was never there -- except maybe represented in the weight activations of an LLM, but that is also doubtful -- so there's no depth to be added.
Therefore:
Context windows
I said before that LLMs are very additive creatures, and that they rarely delete code. They are also creatures with limited context windows.
I want to be clear that this is only the current state of how they are. It is entirely imaginable that later generation LLMs will end up generating fewer tokens net (meaning that they will more frequently remove code and rewrite things to fit an underlying theory better). But it doesn't seem the case today.
Likewise, context windows grow. We may see extremely large context windows in the future.
With those two epistemic disclaimers out of the way, I claim that this proliferation of code will lead to slower progress on any given vibecoded project once it reaches a certain level of complexity, measured in the number of tokens representing the codebase.
So, if an underlying "theory" (if there ever was such a thing when vibecoding) used by an LLM has created a codebase, after a sufficient number of iterations, it will be very difficult for a new instantiation of an LLM to accurately grasp what the theory of that codebase is.
It simply will not fit the context window, and README files are of limited use.
The larger the codebase, and more self-contained, the more expressed this problem will be.
Presumably contract-based codebases could be different, where there are encapsulated units of meaning and you can make changes to each service or module without having to understand the entirety of it.
However, it seems that the overall understanding of the problem-space and how it has been solved (formalized as code) will not be available, even if modularity partially solves the problem.
Therefore, the older and bigger and more vibecoded a codebase gets, the more difficult will it be to add new functionality or change existing functionality without breakages.
Vibecoding will therefore almost immediately create legacy projects, legacy projects meaning projects where there's little theory to rely on and you risk breakages by making changes.
Longevity
Business relationships are usually built with longevity in mind.
When a business buys a service, whether this is API access or a SaaS product, or anything else, there's an implicit understanding that this product will be maintained.
Often, there's an explicit understanding as well.
Maintenance and improvement of a product are in fact the cornerstone of business relationships.
It's not enough to deliver something that works at a given point in time, it is expected that you will also grow that thing, that you will shape it to cover specific problem areas of different customers, and that you will ensure it is free from vulnerabilities, and more.
Vibecoded solutions, built with modern LLM, work almost immediately, at least for certain use cases.
You can in fact not even look at code and just ship it, and it's probably going to work out fine.
If you pair it with some tests, and some documentation, you could very well have a product that someone will buy.
But the question is: what happens in, say, five years?
If you keep vibe-adding features, and somehow keep getting customers to pay for this thing, what happens once the codebase becomes so complex that an LLM cannot fit it inside its "brain"?
And this isn't just about context windows -- even if context windows were to grow at a rate sufficient for ingesting extremely large codebases, there's still the issue of a lack of theory underlying the problem.
The gambit for vibecoders, at least those that don't intend to pull out after a year or two in business, is that AI tools will grow in a) context window sizes and b) general intelligence capable of theory building at least as fast as they grow their codebases.
This may happen, or may not happen, but it's definitely a gambit.
Predictions
My prediction is that LLMs won't follow with context windows and complete understanding capable of sufficient theory building as fast as they will generate code.
This in practice means that I predict that companies employing the vibecoding paradigm will hit a wall in growth, sales, relationship building, and longevity.
A vibecoding company is therefore a company I would short. The more vibey it is, the shorter the position I would take.
I need to figure out how I should best formalize this as a formal prediction that can be judged true or false, but this is how I am thinking about it at this moment.
https://pages.cs.wisc.edu/~remzi/Naur.pdf ↩︎