Which features should the software have, how should they function and interact, which tradeoffs to make given the limitations. Stuff like that.
People who were good at those things but lacked training or capabilities to actually write functioning code can now make viable software.
People who were essentially code monkeys who wrote code based off detailed descriptions of what should be done, without much thought of or influence on the higher level issues have to step up or face tough times I think.
Nah, it was mostly writing the code. One can have a very good idea of "what to implement", even on a feature by feature and architecture basis, but still need many man-weeks or months or even years with a large team to make it into code.
>Which features should the software have, how should they function and interact, which tradeoffs to make given the limitations. Stuff like that.
Stuff like that a person can sit down and plan. Which is what the techical lead or software architect role does.
They still needed to work themselves plus anything from a couple to dozens of coders to make it into actual runnable code.
If the industry was just senior tech lead roles, yeah, it would be affected less. But 95% of it is regular coding roles, even mostly boring coding roles.
That's an argument that writing code was the time-consuming part, which is different from it being the difficult part.
That is exactly where the disagreement stems from. That app is a draft version that might work for a couple people. It won't scale. It won't be secure. It won't handle edge cases. It won't be flexible enough to iterate based on customer feedback.
That doesn't mean LLM-assisted code has no value. It does mean the guidance needed to go from "v000.1" to something you could actually build a business upon is still significant.
Will LLMs bridge that gap more in the future? Maybe. But honestly, hopefully not. Instead, I hope they stop just churning out the same CRUD apps and wrappers that we did a few years ago and do something new. Because if all they do is: What humans do, just faster... cool, useful, but not worth all the hype.
LLMs are useful tools. I use them. But just like the hammer that sits on my shelf and also gets used, they are just a tool. They won't be truly interesting (to me, at least) unless they are doing things that humans cannot do.
As if startup code doesn't have the same issues pre-AI? And still they get to billions of valuations with such code.
They can always pay some beefier consultants when they absolutely have to, for scaling it up or hardening it.
That "it won't be flexible enough to iterate based on customer feedback" is more wishful thinking. It would be code like any other code, following some patterns. In fact, the architecture can be fine tuned by the human in the loop anyway - they just wont be needed 5 more humans to assist them to code it.
>Because if all they do is: What humans do, just faster... cool, useful, but not worth all the hype.
That's literally what automation in any field is. Why should be something more, as if this huge breakthrough is already taken for granted within a few years of being available?
That will never happen. Sure, anyone can program something, but to make it professionally there is bar of quality and competition will push most people out. Similarly anyone can write, draw or sing but only a few do it well enough to be paid for it.
And I am old enough to see many tools that allow "anyone to program". They pop up whenever certain standards (like web) become popular, then programming goes in different direction and they vanish in irrelevance. Soon there will be a large set of skill on top of "using AI" and "chat, make me an app" will go out of the window as viable way to make something others want to use and pay for.
Ever seen most high profile apps in the last 10-15 years? Not to mention regular average apps, which still employ millions of people. Or most enterprise software.
Trust me, the "bar of quality" wont be the issue.
No, but the ones I am paying for are few and with rather solid development record. Looking at top android apps, we have some that have very high bar of engineering (firefox, google translate), some just useful dataset (cooking recipes), but again, even the simple ones outcompeted tons of alternatives.
> most enterprise software
I am not saying enterprise software is super complex, but it is very competitive domain.
The assumption there is doing a lot of heavy lifting. You've presented something that's more like a "treatment" for a movie or TV show, rather than anything approximating what's actually happening with LLMs right now, or that can be seen to be happening in the near future based on current trends.
You're right that "[what is not debated is that LLM has changed our industry." Certainly, having a tool that can perform the task of reading all the prior knowledge and documentation and producing simple bits of code that hew to this documentation is transformative. How much someone says LLMs are transforming their workflows depends on how good they were at doing the above task themselves. I've never been good at reading manuals, and reading other people's code - for someone with my brain, having an LLM that can quickly and accurately (enough) answer pointed questions about very carefully constrained problem descriptions is a real boon. It scales me tremendously - projects I had given up on because I couldn't read up and act on the docs for all the different starting pieces have suddenly become something I can imagine at least getting started on.
I still have to plan the project, figure out all the questions at each step to ask about each piece, understand which of the LLM's concerns and objections are valid/relevant enough for me to pursue them, and understand the errors I continue to run into along the way enough to be able to state them clearly back into this "reference finding" mechanism.
The question of "software development" isn't turning into a despairing "What's there left for me to do?", but rather a much more hopeful, "Given that I am past the starting hurdles on so many projects simultaneously, which of these projects should I try to bring to some really interesting point of completion?" Now the constraining limit is more on how well I can conceptualize the underlying problem and less so on how quickly I can recall specific syntaxes for configuring a half-a-dozen different pieces of software.
Simple case in point: I wanted to throw up a web app inside a Docker container in an Ubuntu VPS. I just can't remember all the intermediate steps quickly enough - creating a secure enough deployment user/group setup; making sure Ubuntu is up-to-date; writing the docker-compose.yml file; figuring out what diagnostic commands to run to assess the various errors I run into along the way; working out my DNS and proxy server setup; and so on - even though each one of these is, in the grand scheme of things, a very basic step. Someone who needed to work through this list of steps, who has been creating micro-services using similar workflow templates in their company for 2-3 years, would have had little gain from using an LLM over just doing what to them is muscle memory. For me, it was the difference between, I guess I’ll just have to play with this idea as a toy on my laptop vs. Wow, this is running in the public Internet, with auto deploys from Github, and scheduled jobs running daily web scraping tasks for me while I sleep. And I could get there in maybe an hour’s worth of querying the LLM, reading error messages, and carefully triaging which ones to fix. It’s easy to underestimate just how much domain knowledge is still necessary even in this situation.
To go back to your analogy - now that you have a robot in your restaurant that can be fairly easily tasked by you to, say, make the perfect dough for a simple enough recipe; re-arrange your tables to add 3 more tops; be instructed to call all the butchers in town asking if they have specific cuts of meat; and so on and so forth - what can you, a star restaurateur, chef, food entrepeneur, do more of? It doesn’t mean that running that restaurant suddenly became as easy as the simplest of its composing tasks. The robot is flipping the burgers perfectly now so you can maybe save money hiring someone for that specific task. But the mere act of perfectly flipping burgers still leaves you many, many steps away from satisfying even one evening’s worth of diners.
What happens when there is enormous amount of supply (software) and you're still not capturing the demand? It can be stuck onto less than 5 of the incumbent alternatives. It used to be 90% of tech startups failing it's now 98% and the competition is extremely fierce.
It's was never about the code in the first place.
The software needs to be scalable, and reliable before it can make serious money and it involves constant maintenance and someone to be accountable for that risk. So:
> Assuming software development becomes a commodity and the job becomes something like a fast food job where practically any adult who wants it can do it, what is your next move?
> Anthropic and OpenAI are working hard to redirect the salary you earn to themselves in the form of API costs...
This is now about risk and lets say anyone can use Claude to code which is fine, but I ask you:
Would you hire someone that has built systems before and knows what to build with Claude or a vibe coder with no experience that uses Claude to maintain your software?
Do you want a 1 million dollar incident (experienced software engineer) or a 1 billion dollar incident (vibe coder)?
The worst part is, this isn't theoretical as some companies are now risking their reputation for choosing the latter.
Your response sounds like "if you don't have faith" or something.