4 ms·

Just like someone who can figure out how to write code to solve a problem can do it while other programmers say it's not possible and just do it some other way,

by j45 1y ago

Just like someone who can figure out how to write code to solve a problem can do it while other programmers say it's not possible and just do it some other way, the same is true of AI. One of the major issues I'm seeing is how much technical people haven't been involved in the application of AI, which leaves non-technical people to pontificate and try. With any new tech, after the hype is gone, what remains, is adopted and used. The internet, social media, smartphones, all seemed foreign. LLMs are no different. They will solve things other things haven't before. LLMs are only as good as the users using it. Users only get better at using AI but putting in the repetitions. It's not a tool that's alive or a psychic.

cshores 1y ago
I generally agree, but I think there is a real disconnect. Middle and upper management often do not understand how developers and engineers are actually supposed to use these tools. For example, I work in operations, so most of what I touch is bash, Ansible, Terraform, GitHub workflows and actions, and some Python. Recently, our development team demonstrated a proposed strategy to use GitHub Copilot: assign it a JIRA ticket, let it generate code within our repos, and then have it automatically come back with a pull request. That approach makes sense if you are building web or client-side applications. My team, however, focuses on infrastructure configuration code. It is software in the sense that we are managing discrete components that interact, but not in a way where you can simply hand off a task, run tests, and expect a PR to appear. Large language models are more like asking a genie. Even if you give perfectly clear instructions, the result is often not exactly what you wanted. That is why I use Copilot and Gemini Code Assist in VS Code as assistive tools. I guide them step by step, and when they go off track, I can nudge them back in the right direction. To me, that highlights the gap between management’s expectations and the reality of how these tools actually work in practice.
nativeit 1y ago
LLMs are very different. All of the other things you mentioned found wide, eager adoption among the broader public within two years.
- nativeit 1y ago
  They were/are also profitable.

by j45 1y ago

cshores 1y ago

I generally agree, but I think there is a real disconnect. Middle and upper management often do not understand how developers and engineers are actually supposed to use these tools. For example, I work in operations, so most of what I touch is bash, Ansible, Terraform, GitHub workflows and actions, and some Python. Recently, our development team demonstrated a proposed strategy to use GitHub Copilot: assign it a JIRA ticket, let it generate code within our repos, and then have it automatically come back with a pull request. That approach makes sense if you are building web or client-side applications. My team, however, focuses on infrastructure configuration code. It is software in the sense that we are managing discrete components that interact, but not in a way where you can simply hand off a task, run tests, and expect a PR to appear. Large language models are more like asking a genie. Even if you give perfectly clear instructions, the result is often not exactly what you wanted. That is why I use Copilot and Gemini Code Assist in VS Code as assistive tools. I guide them step by step, and when they go off track, I can nudge them back in the right direction. To me, that highlights the gap between management’s expectations and the reality of how these tools actually work in practice.

nativeit 1y ago

LLMs are very different. All of the other things you mentioned found wide, eager adoption among the broader public within two years.

nativeit 1y ago
They were/are also profitable.