> And how is this different from just calling the libraries in the right way to make it adhere to stakeholder requirements?
In that you need humans that can understand stakeholder requirements, constraints of the ___domain, and limits of existing software, so that they can write the necessary glue to make everything work.
Thing is, LLMs know more about every ___domain than any non-expert (and for most software, "___domain experts" are just non-___domain-expert programmers who self-learn enough of it to make the project work), and they can understand what stakeholders say better than other humans can, at least superficially. I expect it won't take long until LLMs can do all of this better than an average professional.
(Yes, it may take a long time before an LLM can replace a senior Googler. But that's not the point. It's enough for an LLM to replace an average code monkey churning out mobile apps for brands, to have a huge chunk of the industry disappear overnight.)
Paul Graham argued that if you act like the average startup, you'll get the same results as the average startup. And the average startup fails.
It follows that if you want to have success, you need to do something new which hasn't been done before.
> LLMs know more about every ___domain than any non-expert
As soon as you're creating something new, or working in a niche field, LLMs struggle.
So do junior developers. But they learn and get better with time. While onboarding a junior developer requires more effort than doing the work yourself, it's worth it in the long run.
IMHO, that's the largest issues LLMs have today. They can't really adapt and learn "in the field". We build a lot of workarounds with memory to circumvent that, but that too only works until the memory exceeds the context.
I've tried using ChatGPT, Copilot, custom GPT 4o models and Cursor. The task they did best at was generating a simple landing page (though they struggled with tailwind 4, cursor spent almost 8 hours debugging that issue).
With tasks that require more niche ___domain knowledge, it went much worse. Cursor finished some of the tasks I gave it, but it took over 10x more time than a junior developer would've spent, and I had to constantly babysit it the entire time, providing context, prompting, writing cursor rules, prompting again, etc. The others failed entirely.
If I start working on an unfamiliar task, I read all the docs, write some notes for myself, maybe build some sample projects to test my understanding of the edge cases. Similarly, if faced with a new task, I build some small prototypes before committing to a strategy for the actual task.
Maybe ML agents would fare better with that approach, instead of today's approach of just creating a mess in the codebase like an intern.
In that you need humans that can understand stakeholder requirements, constraints of the ___domain, and limits of existing software, so that they can write the necessary glue to make everything work.
Thing is, LLMs know more about every ___domain than any non-expert (and for most software, "___domain experts" are just non-___domain-expert programmers who self-learn enough of it to make the project work), and they can understand what stakeholders say better than other humans can, at least superficially. I expect it won't take long until LLMs can do all of this better than an average professional.
(Yes, it may take a long time before an LLM can replace a senior Googler. But that's not the point. It's enough for an LLM to replace an average code monkey churning out mobile apps for brands, to have a huge chunk of the industry disappear overnight.)