start with opening up codex or whatever you use. type "make me a calculator app". get your calculator app in an hour or whatever.
it's fair to describe this process as taking an idea and getting a program.
start with opening up codex or whatever you use. type "make me a calculator app". get your calculator app in an hour or whatever.
it's fair to describe this process as taking an idea and getting a program.
What sort of 'app'? A native program for given OS and arch? A webapp? What sort of calculator: scientific, graphic, or just a very simple children's calculator? Does it have large buttons optimised for touchscreens/mouse? Or do we optimise UX for user who types with a physical keyboard?
Sure, you can boil any software 'idea' down to a single short sentence, provided your idea was so simple that virtually any output satisfies it. And if virtually any output satisfies your 'idea', what was its value in the first place? Was there not already some FOSS that satisfied the same requirements long before AI came on the scene?
I've found from my vibecoding experiments I always end up needing to define the exact idea so tightly that my prompt length almost matches the final code length. I often find myself 'programming' in some sort of light pseudocode and letting the agent fill out the details. Any higher level and it doesn't really capture what I want - not due to LLM limitations but the ability for the AI to not read my mind.
It's not an appropriate equivalence because there's too much variation in the outcome that cannot be meaningfully controlled with the same leverage.
If what you were saying were true - there would be 100% not Software Developers anywhere, and Product Managers would be churning out new products daily. But it's not the case.
By now, is your Markov chain still a Markov chain, or does it have another name?
People love to discuss semantics. Yes, *today* a competent product manager enters requirements and - if not too complex - the llm will shit, review, debug, fix an application. That is the reality today. Not in 2031.
Only developers think that in most cases, the hard part is code. Its never been.
The correct way to think about this:
The hard part is ensuring the product does not exhibit undesired behaviours. Writing code is one possible tool for ensuring this. Replacing writing code with LLMs only works to the extent that LLMs accurately predict your definition of 'undesired'. The more unique and innovative your product, the more likely the LLM prediction is to be inaccurate.
They suck at spelling too ;)
The hard part is knowing what behaviours you want it to have, in the context of what is possible and what is not.