Absolutely. Merely being a member of the business class does not magically mean one has the ability to specify business requirements much less product specifications. These are *not* the people I'm talking about now having superpowers.
I am picturing people who blend high level engineering and product skills, ideally with business sense.
> Merely being a member of the business class does not magically mean one has the ability to specify business requirements much less product specifications
Is this not why COBOL failed? Common Business-Oriented Language sure does look much more like natural language than a lot of other code, but it could never solve the abstraction needed to do the complex things.
I don't think LLMs will ever get rid of coders. Business people can no more tell an LLM what to build than they can a team of programmers. I've long argued that the contention between the "business monkeys" and "coding monkeys" is a good one. That the former focuses on making money and the latter focuses on making a better product. The contention is good because they need each other (though I do not think the dependence is symmetric).
Maybe one day AI will get there, but I don't see how it does without achieving AGI. To break down intent. To differentiate what was asked from what was intended. To understand the depth and all the context surrounding the many little parts. To understand the needs of the culture. The needs of the users. The needs of the business. This is all quite complex and it's why the number of employees typically grows quite rapidly.
How do we move forward without asking how we got here? Why we got here? How optimizing for decades (or much longer) led us to these patters. Under what conditions makes these patterns (near) optimal? I've yet to see a good answer to how LLMs actually address this. If typing was the bottleneck I think we would have optimized in very different ways.
My intuition tells me that llm’s combined with SWE’s with really amazing fundamentals will kill the code monkeys.
And frankly? That’s the best outcome. Code monkeys (in my view that’s an individual who writes out code just to complete a jira ticket) are a liability. Not only that but each additional person you have in an org means more noise creation.
If this forces the code monkeys to level up to compete… again a good thing.
The code base should not be elongated nor complicated. I’m not even a SWE by trade, rather a CEO, and this is my preferred outcome.
I am picturing people who blend high level engineering and product skills, ideally with business sense.