> Having something that can generate code reliabily (which these things can barely do even with an expert at the wheel) doesn't address any of the actual hard problems we deal with on a daily basis.
Not understanding that is something I've been seeing management repeatedly doing for decades.
This article reads like all the things I discovered and the mistakes the company I worked for made learning how to outsource software development back in the late 90s and early 2000s. The only difference is this is using AI to generate the code instead of lower paid developers from developing nations. And, just like software outsourcing as an industry created practices and working styles to maximise profit to outsourcing companies, anyone who builds their business relying on OpenAI/Anthropic/Google/Meta/whoever - is going to need to address the risk of their chosen AI tool vendor ramping up the costs of using the tools to extract all; the value of the apparent cost savings.
This bit matches exactly with my experience:
"The trouble comes in that most people don't know what code needs to be created to solve their problem, for any but the most trivial problems. Who does know what code would be needed to solve complex problems? Currently that's only known by software developers, development managers and product managers, three job classifications that are going to be merging rapidly."
We found that assuming the people you employ as "developers" weren't actually also doing the dev management and product management roles was wrong. At least for our business where there were 6 or 8 devs who all understood the business goals and existing codebase and technology. When we eventually;y got successful outsourced development working was after we realised that writing code from lists of tasks/requirements was way less than 50% of what our in-house development team had been doing for years. We ended up saving a lot of money on that 30 or 40% of the work, but 60 or 70% of the higher level _understanding the business and tech stack_ work still needed to be done by people who understood the whole business and had a vested interest in the business succeeding.
> assuming the people you employ as "developers" weren't actually also doing the dev management and product management roles was wrong.
Also in the mix: Stuff involving B2B customers and integrating systems, where "developer" blurs a bit with sales-engineer or consultant, ex:
* Be on a call to ask significant questions (grounded in reading the code) to determine what the customer's real problem is.
* Help craft diplomatic but accurate explanations of what's going wrong.
* Explain what bugs or changes you can do for them versus which parts are fully on their end, sometimes with "here's what I think your engineers should consider doing" advice.
Not always fun, but sometimes enlightened self-interest means I'd rather spend an 1 hour being "one of our developers" in a customer-meeting, as opposed to 6 hours discovering everything is actually working as-intended and the customer just misunderstood what feature they were using.
Not understanding that is something I've been seeing management repeatedly doing for decades.
This article reads like all the things I discovered and the mistakes the company I worked for made learning how to outsource software development back in the late 90s and early 2000s. The only difference is this is using AI to generate the code instead of lower paid developers from developing nations. And, just like software outsourcing as an industry created practices and working styles to maximise profit to outsourcing companies, anyone who builds their business relying on OpenAI/Anthropic/Google/Meta/whoever - is going to need to address the risk of their chosen AI tool vendor ramping up the costs of using the tools to extract all; the value of the apparent cost savings.
This bit matches exactly with my experience:
"The trouble comes in that most people don't know what code needs to be created to solve their problem, for any but the most trivial problems. Who does know what code would be needed to solve complex problems? Currently that's only known by software developers, development managers and product managers, three job classifications that are going to be merging rapidly."
We found that assuming the people you employ as "developers" weren't actually also doing the dev management and product management roles was wrong. At least for our business where there were 6 or 8 devs who all understood the business goals and existing codebase and technology. When we eventually;y got successful outsourced development working was after we realised that writing code from lists of tasks/requirements was way less than 50% of what our in-house development team had been doing for years. We ended up saving a lot of money on that 30 or 40% of the work, but 60 or 70% of the higher level _understanding the business and tech stack_ work still needed to be done by people who understood the whole business and had a vested interest in the business succeeding.