Comment by Cthulhu_
4 hours ago
But your comparison is a bit off; you mention CNC machines and the like to build guitars, but those are tools that are still exactly programmed by humans. LLMs on the other hand are probabilistic - you prompt "write me a set of gcode instructions for a CNC to build a guitar body" and wait / hope.
Sure, LLMs as a tool probably have a place in software development, but the danger lies in high volume, low oversight.
But there's people using it large scale to build large applications, time will tell how they work out in the end. Software engineering is programming over time, and the "over time" for LLM based software engineering hasn't been long enough yet.
You have a lot of control over what the LLM creates. The way you phrase your requirements, give it guidance over architecture, testing, ux, libraries to use. You can build your own set of skills to outline how you want the LLM to automate your software process. There's a lot of craftmanship in making the LLM do exactly what you think it needs to do. You are not a victim at the mercy of your LLM.
You are a lead architecture, a product manager, a lead UXer, a lead architect. You don't have 100% control over what your LLM devs are doing, but more than you think. Just like normal managers don't micromanage every action of their team.
> You have a lot of control over what the LLM creates.
No, you don't, you have "influence" or "suggestion".
You can absolutely narrow down the probability ranges of what is produced , but there is no guarantee that it will stick to your guidelines.
So far, at least, it's just not how they work.
> You don't have 100% control over what your LLM devs are doing, but more than you think. Just like normal managers don't micromanage every action of their team.
This overlooks the role of actual reasoning/interpretation that is found when dealing with actual people.
While it might seem like directing an LLM is similar in practice to managing a team of people, the underlying mechanisms are not the same.
If you analyse based on comparisons between those two approaches, without understanding the fundamental differences in what's happening beneath the surface, then any conclusions drawn will be flawed.
---
I'm not against LLM's, i'm against using them poorly and presenting them as something they are not.
I think i have enough control, probably more than when working with developers. Here's something i recently had claude code build: https://github.com/ako/backing-tracks
If you check the commit log, you'll see small increments. The architecture document is what i have it generate to validate the created architecture: https://github.com/ako/backing-tracks/blob/main/docs/ARCHITE...
Other than that most changes start with the ai generating a proposal document that i will review and improve, and then have it built. I think this was the starting proposal: https://github.com/ako/backing-tracks/blob/main/docs/DSL_PRO...
This started as a conversation in Claude Desktop, which it then summarized into this proposal. This i copied into claude code, to have it implemented.
2 replies →
> You have a lot of control over what the LLM creates. The way you phrase your requirements, give it guidance over architecture, testing, ux, libraries to use. You can build your own set of skills to outline how you want the LLM to automate your software process
Except for the other 50% of the time where it goes off the rails and does what you explicitly asked it not to do.