5 ms·

>For most uses the truck is better than the horse. I think you're talking past the author here, who says: >By not leaning into LLMs I’ve given myself the room

>For most uses the truck is better than the horse. I think you're talking past the author here, who says: >By not leaning into LLMs I’ve given myself the room to specialise in a smaller set of skills. So far that conscious decision is working out well, and I remain confident about my job security. "Most uses" might mean boilerplate and simple frontend work that LLMs can do easily because it's formulaic and doesn't require much creativity. OP is simply not doing that type of work. I don't think anyone sane is really claiming 100x or 1000x speedups anymore. Most people I talk to who use LLMs are closer to 1.5 or 2. Because their job is not mostly boilerplate, there is simply not that much room to be improved.

deleted 1mo ago
[deleted]
bensyverson 1mo ago
It’s not about speed-ups, it’s the fact that I’ll attempt a project far more ambitious than I would have in the past. Over the past two months I’ve built out a very complex web app for a client. Without the aid of AI it would be far smaller, simpler and less capable. And honestly I probably wouldn’t have agreed to take on the job in the first place.
- lproven 1mo ago
  > far smaller, simpler and less capable So, better, in other words?
  - bensyverson 1mo ago
    Sure, in the same way that nano is better than Microsoft Word. Unfortunately, sometimes nano is not enough. In the case of this client project, we are only now getting to enough functionality to be generally useful. The complexity that exists in the project is necessary complexity. A lot of coders are simply wrong about complexity, and feel it can always be reduced.
    - lproven 1mo ago
      Complexity in software in general is an evil thing, to be feared and fought and avoided at all costs. Niklaus Wirth pointed this out over 30 years ago… https://ieeexplore.ieee.org/document/348001 https://ieeexplore.ieee.org/document/348001 … and it has grown exponentially worse since. I think that the software world ought to fear and dread complexity, the same way that the Unix designers feared and dreaded verbosity. « Note the obsessive use of abbreviations and avoidance of capital letters; this is a system invented by people to whom repetitive stress disorder is what black lung is to miners. Long names get worn down to three-letter nubbins, like stones smoothed by a river. » https://web.stanford.edu/class/cs81n/command.txt https://web.stanford.edu/class/cs81n/command.txt We ought to be religiously obsessive about avoiding it. In the end, everyone would benefit thereby.
pydry 1mo ago
there's no real difference between an excess of boilerplate and slop. if your job is just writing boilerplate you're probably doing it badly. if your app is so simple that really all you need to do is sling boilerplate then it might suffice but it's probably still the most unreliable way to develop that software. if flakiness, bugginess and unreliability are all fine then yea, boilerplate away.

deleted 1mo ago

[deleted]

bensyverson 1mo ago

It’s not about speed-ups, it’s the fact that I’ll attempt a project far more ambitious than I would have in the past. Over the past two months I’ve built out a very complex web app for a client. Without the aid of AI it would be far smaller, simpler and less capable. And honestly I probably wouldn’t have agreed to take on the job in the first place.

lproven 1mo ago
> far smaller, simpler and less capable So, better, in other words?
- bensyverson 1mo ago
  Sure, in the same way that nano is better than Microsoft Word. Unfortunately, sometimes nano is not enough. In the case of this client project, we are only now getting to enough functionality to be generally useful. The complexity that exists in the project is necessary complexity. A lot of coders are simply wrong about complexity, and feel it can always be reduced.
  - lproven 1mo ago
    Complexity in software in general is an evil thing, to be feared and fought and avoided at all costs. Niklaus Wirth pointed this out over 30 years ago… https://ieeexplore.ieee.org/document/348001 https://ieeexplore.ieee.org/document/348001 … and it has grown exponentially worse since. I think that the software world ought to fear and dread complexity, the same way that the Unix designers feared and dreaded verbosity. « Note the obsessive use of abbreviations and avoidance of capital letters; this is a system invented by people to whom repetitive stress disorder is what black lung is to miners. Long names get worn down to three-letter nubbins, like stones smoothed by a river. » https://web.stanford.edu/class/cs81n/command.txt https://web.stanford.edu/class/cs81n/command.txt We ought to be religiously obsessive about avoiding it. In the end, everyone would benefit thereby.

pydry 1mo ago

there's no real difference between an excess of boilerplate and slop. if your job is just writing boilerplate you're probably doing it badly. if your app is so simple that really all you need to do is sling boilerplate then it might suffice but it's probably still the most unreliable way to develop that software. if flakiness, bugginess and unreliability are all fine then yea, boilerplate away.