3 ms·

I work in Enterprise IT, I'm the CTO of a small business. People executing small scripts all over the place sounds to me like the stuff of nightmares. Especiall

I work in Enterprise IT, I'm the CTO of a small business. People executing small scripts all over the place sounds to me like the stuff of nightmares. Especially locally, but even if it's run online in a safer environment, as long as it causes side effects in other systems, the risk is massive. And if it doesn't cause side effects, well, chances are the program is worthless. Also, I've already seen this story play out with low-code. The pitch was the same, nearly line by line: "citizen developers will be able to solve so many problems by themselves at the edges of enterprise". It didn't take. Most users could not learn the technologies, but much more importantly: they did not even know how to verbalize their requirements. Take my word for it, most people do not want to design solutions, and of those that are willing, only a small subset is able.

rfoo 1y ago
> I've already seen this story play out with low-code. The pitch was the same That's the point. Unlike low-code or no-code bullshit, this somehow worked. People "magically" want to design solutions, and are able to, now. > People executing small scripts all over the place sounds to me like the stuff of nightmares. Me too. However, watching how eager people want to (and they indeed can!) make progress with these LLM generated horror, I believe it's time to give up and start designing secure systems despite the existence of massive slightly broken scripts.
- aerhardt 1y ago
  > People "magically" want to design solutions, and are able to, now. I agree that LLMs lower the barrier significantly compared to low-code/no-code, but most people are not able to design solutions because they lack the business analysis skills and are not detailed-oriented enough to follow through with the specification of requirements. Let's not even talk about the discipline to carry out maintenance over a working project in the face of changing requirements. Even if we agree that LLMs move a lot of the work up the stack towards business analysis / product ownership / solution design, my experience in Enterprise IT in companies ranging from small to gigantic is that users do not magically become BAs / POs / PMs. There's a reason those are professionalized and specialized roles. I wouldn't mind being proven wrong, it's not like I feel personally threatened or anything. I feel it's the integrity of the systems I oversee that would be threatened. > I believe it's time to give up and start designing secure systems OK, well I'm not going to bear that responsibility for that, I have enough on my plate as it is. I'm not allowing an arbitrary sales rep to interact with our production Salesforce instance by automated means, period. Even if they have the proper permission levels configured to a tee in Salesforce, I can think of a thousand ways they could badly mess up their own slice of data. Interacting with the local machine: also potentially a supermassive black hole of vulnerabilities. Some of them possibly more serious than data loss, such as the syphoning of data to malicious actors. If someone can think of secure ways for citizen devs to interact with critical enterprise systems via scripting, then fine. I'll sit here waiting!
danny_codes 1y ago
Hmm I feel like this could work but we (SWE professionals) would need to provide a secondary private API surface that assumes the user is hostile. IE if you want to automate something that interacts with any private software it’d have to be treated like an adversary. I guess in the long run it could become worthwhile, but it’ll be a long road to get there

rfoo 1y ago

> I've already seen this story play out with low-code. The pitch was the same That's the point. Unlike low-code or no-code bullshit, this somehow worked. People "magically" want to design solutions, and are able to, now. > People executing small scripts all over the place sounds to me like the stuff of nightmares. Me too. However, watching how eager people want to (and they indeed can!) make progress with these LLM generated horror, I believe it's time to give up and start designing secure systems despite the existence of massive slightly broken scripts.

aerhardt 1y ago
> People "magically" want to design solutions, and are able to, now. I agree that LLMs lower the barrier significantly compared to low-code/no-code, but most people are not able to design solutions because they lack the business analysis skills and are not detailed-oriented enough to follow through with the specification of requirements. Let's not even talk about the discipline to carry out maintenance over a working project in the face of changing requirements. Even if we agree that LLMs move a lot of the work up the stack towards business analysis / product ownership / solution design, my experience in Enterprise IT in companies ranging from small to gigantic is that users do not magically become BAs / POs / PMs. There's a reason those are professionalized and specialized roles. I wouldn't mind being proven wrong, it's not like I feel personally threatened or anything. I feel it's the integrity of the systems I oversee that would be threatened. > I believe it's time to give up and start designing secure systems OK, well I'm not going to bear that responsibility for that, I have enough on my plate as it is. I'm not allowing an arbitrary sales rep to interact with our production Salesforce instance by automated means, period. Even if they have the proper permission levels configured to a tee in Salesforce, I can think of a thousand ways they could badly mess up their own slice of data. Interacting with the local machine: also potentially a supermassive black hole of vulnerabilities. Some of them possibly more serious than data loss, such as the syphoning of data to malicious actors. If someone can think of secure ways for citizen devs to interact with critical enterprise systems via scripting, then fine. I'll sit here waiting!

danny_codes 1y ago

Hmm I feel like this could work but we (SWE professionals) would need to provide a secondary private API surface that assumes the user is hostile. IE if you want to automate something that interacts with any private software it’d have to be treated like an adversary. I guess in the long run it could become worthwhile, but it’ll be a long road to get there