What is it? You describe an application you want. With natural language. The bigger the app, the longer description. (Throwing away iterative steps is nonsense, for the same reason why "the code documents itself" is nonsense: It represents what is, not what is supposed to be. Therefore, the complete description is needed to reproduce the app reliably.)
A description of an enterprise project like ours will be quite long - with all the requirements, legal quirks, legacy data, error handling, security...
So such description will need:
- A good structure.
- References between places.
- Error handling description.
- Integrations description.
- Configuration description.
- UI description.
- How you want to test it description.
- Where (and by whom) you want to run it description. etc...
Describing this in (say) English is quite chatty, and it soon, it will actually become quite hard for humans to make any sense of it. So, shorthands will emerge. Like, instead of
On that page I talked about 5 minutes ago, the one with the green button, I actually also want a blue button that is kinda next to it, but no too close, and that one should load 10 or 20 more items from the database, basically what would fit the empty part of the users screen, unless it is full, then at least 10 items. Yeah so the items will come from a list of goods that I have stored.
No I meant, not the products, but what they bought before.
Actually not only they, but also others.
The others can't be named because privacy, so you need to mangle it somehow.
Now please make it related to what they are looking at. Like AMazon does.
... you will probably start writing something like:
data: {
bought_items: History of purchases; stores a reference to the buyer, the product, the date, ...
}
backend { data1 { from: bought_items, time: -3 moths, bought by: ALL, relation: similar by { purpose, design } }
frontend {
table1: ...
buttons:
{ text: "Buy" (but in user's language), visuals: green shiny, action: go to the car, placement: below items }
{ text: "Load similar items", visuals: blue, action: load data1 from backend + append them to the table1 }
}
Well, congratulations - you have invented programming. Just quite shoddy one.
Some people will specialize in those shorthands, giving them advantage over others, because better time to market, maintainability. Congratulations - you have invented programmers.
And then it will iterate to better languages, capable of descripting the desired app closer and closer, with less and less text. Congratulations - you have invented programming languages evolution.
Many times over and over, a new language or platform comes , with a great idea that the old pals made it too complicated, and the youngsters know better. The new is simpler, easier. As the youngsters grow, they hit the reality of the complexity of the business sphere and the enterprise solutions, and start adding features to catch up. It takes a huge amount of talent, work, persistence, luck in commercial acceptance, community support etc. to 1) Get it right for the base, 2) Keep it right while evolving. Take Perl, Ruby, Scala, Erlang, Visual Basic, ObjectiveC, Fortran, Cobol, PHP, Tcl, ...
With "vibe coding", I am almost certain this will happen again, except the setback at the beginning is HUGE, starting with very bad base. And therefore the iteration will be longer, and the wilderness of that will remind us the past 15 years of the Javascript.
At the end, there will be good languages, in many ways fitting well the new tools, likely leaving a lot on the AI to figure out, and that will be considered low-level. But the "irreducible" complexity of what the business wants, the laws dictate, the marketing desires, the designers dream, the users demand, and the developers are capable of deliver, will remain, and will need to be addressed by methods quite similar to what we have now.