Comment by ako
4 hours ago
I think we should embrace AI to craft better software. You have a lot of control over the code generated by AI, so all your designs, patterns, best practices can be used in the generated code. This will make us better software craftsmen.
A nice example is guitar building: there's a whole bunch of luthiers that stick to traditional methods to build guitars, or even just limit themselves to japanese woodworking tools.
But that is not the only way to build great guitars. It can be done by excellent luthiers, building high quality quitars with state of the art tools. For example Ulrich Teuffel who uses all sorts of high tech like CAD systems and CDC machines to craft beautiful guitars: https://www.youtube.com/watch?v=GLZOxwmcFVo and https://www.youtube.com/watch?v=GLZOxwmcFVo
Unfortunately, craftsmanship does not come cheap, so most customers will turn to industrially created products. Same for software.
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.
3 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.
I am a craftsman of fine puzzles made from wood and CNC machined metal. I use LLM in lots of ways to help on individual parts of bigger puzzle design projects, like for example to create custom puzzle solver software which can search through large sets of possible notching patterns on wooden sticks in order to find ones that meet some criteria or are optimized in whatever manner I find aesthetically pleasing.
I’ve been writing various single-purpose software tools of these sorts for decades. I would not want to go back to hand-writing them now that I can have agents (cursor, claude code, etc) lay down the algorithmic architecture that I vibe at them, now that I know how to “speak that language” and reliably get the software outcomes that I seek.
I find this similar to how I would not want to spend all day turning the crank handles on a manual milling machine when I can have a CNC mill do it, now that I know how to use various CAM systems well and have the proper equipment.
Given that my overall craft is not limited to just writing code or turning crank handles, I readily embrace any improvements of my workshop “technology stack” so that I can produce higher quality artwork.
I agree. The article's logic is incoherent. It conflates the choice of tools with the decision what product to make and what level of quality to aim for.
If AI can be used to make bad (or good enough) software more cheaply, I have no problem with that. I'm sure we will get a huge amount of bad software. Fine.
But what matters is whether we get more great software as well. I think AI makes that more likely rather than less likely.
Less time will be spent on churning out basic features, integrations and bug fixes. Putting more effort into higher quality or niche features will become economically viable.
I wonder if that's only really true for "pre-LLM" engineers though. If all you know is prompting maybe there's not a higher quality with more focused that can really be achieved.
It might just all meld into a mediocre soup of features.
To be clear not against AI assisted coding, think it can work pretty great but thinking about the implications for future engineers.
>If all you know is prompting maybe there's not a higher quality with more focused that can really be achieved.
That's true of any particular individual but not for a company that can decide to hire someone who can do more than prompting.
>It might just all meld into a mediocre soup of features
I don't think the relative economics have changed. Mediocre makes sense for a lot of software categories because not everyone competes on software quality.
But in other areas software quality makes a difference it will continue to make a difference. It's not a question of tools.