It could also be as simple as the technology adjacent people developing tools via LLM that somehow end up in the critical path of some business function and now it needs to be supported by someone.

I’ve seen the same happen with insane spreadsheets.

As empowering as something like Claude code can be, leaving development to developers means the output is inherently supported by the organization long term.

I am co-teaching an AI course for college business students. We decided to use Claude Code and Visual Studio since the space is moving so quickly and we thought understanding some of the fundamentals is the most value they could get from the course.

It was the right choice. But many of the rough edges of the terminal do surface and confuse non technical people.

> which leads to the actual problem I think.

Getting there faster with less knowledge of coding isn't the problem.

Pre LLMs, the main barrier to producing software for non-tech people was writing the code, literally. With LLMs, this barrier is now gone. This results in a much larger volume of slop than before. And then the real barrier shows up -- understanding, fool-proofing and maintaining that code. Code is cheap, show me how it runs in prod.

Like it's great that quants can iterate on their ideas much faster now. But GS is saying they shouldn't leave their sandbox.

Maybe there is an irony in that LLM with coding harness could be a step in the right direction for operational domain experts to solve business problems while maintaining high standards for legal/compliance/regulatory/reputational and prd-deployment concerns.

User scripts that turn into applications that need production support are often consequential and business-differentiating since they do the things that can't be bought off the shelf and effectively encode tacit knowledge.