3 ms·

It feels like a bell curve: - one big set of users who don't like it because it generates a lot of code and uses its own style of algorithms, and it's a whole

It feels like a bell curve: - one big set of users who don't like it because it generates a lot of code and uses its own style of algorithms, and it's a whole lot of unfamiliar code that the user has to load up in their mind - as you said. Too much to comprehend, and quickly overwhelming. And then to either side - it unblocks users who simply couldn't have written the code on their own, who aren't even trying to load it into their head. They are now able to make working programs! - it accelerates users who could have written it on their own, given enough time, but have figured out how to treat it as an army of junior coders, and learned to only maintain the high level algorithm in their head. They are now able to build far larger projects, fast!

danielbln 1y ago
I'm in that last bracket. I don't really have LLMs do tasks that given enough time and scouring docs I couldn't have implemented myself. I set hard rules around architecture, components, general design patterns and then let the LLM go at it, after which review the result in multiple passes, like I would a junior's code. I could not care less about the minutiae of the actual implementation, as long as it conforms to my conventions and style guides and instructions.
- generalizations 1y ago
  Yeah. I think the trick is, you have to have been capable of doing it yourself, given time. Same as a senior engineer, they have to be capable of doing the tasks they assign to juniors.
leptons 1y ago
More often than not the "AI" generates a large block of code that doesn't work, that I still have to read and understand - and it's more difficult to understand because it doesn't work, which is a huge waste of my time. Then I just end up writing the damn code myself, which I should have done in the first place - but my boss wants me to try using the AI. The only thing the "AI" is marginally good at is as a fancy auto-complete that writes log statements based on the variable I just wrote into the code above it. And even this simple use case it gets it wrong a fair amount. Overall the "AI" is a net negative for me, but maybe close to break-even thanks to the autocomplete.
- generalizations 1y ago
  What "AI" are you using
eikenberry 1y ago
That last bracket is basically the same as the tech based start-up story. You build the projects fast, but you build a ton of tech debt into it that you'll be forced to deal with unless it is a short lived project. Not that this is 100% bad, but something to know going in.
- generalizations 1y ago
  Depends. I think that becomes a question of the quality of the programmer - if they were doing it all themselves, the code quality of the (necessarily much smaller) projects would still vary between programmers. Now that variation is magnified, but if you're very good at what you do, I suspect it is still possible to create those projects without the tech debt. Though at the lower end of that bracket, I'd agree you tend to end up with giant balls of mud.
  - eikenberry 1y ago
    When you play architect and delegate all the work to junior developers it won't matter how good you are, you will incur a lot of tech debt. You simply cannot teach/guide every junior into writing good code as that would take more time than writing it yourself. This fact is baked into the juniors analogy.
    - generalizations 1y ago
      IMHO it depends on how good you are at being a senior programmer / architect. Put the juniors where they can't do harm, and orchestrate them appropriately. The whole point of employing juniors is that you don't assign a senior to rewrite everything they do.

danielbln 1y ago

I'm in that last bracket. I don't really have LLMs do tasks that given enough time and scouring docs I couldn't have implemented myself. I set hard rules around architecture, components, general design patterns and then let the LLM go at it, after which review the result in multiple passes, like I would a junior's code. I could not care less about the minutiae of the actual implementation, as long as it conforms to my conventions and style guides and instructions.

generalizations 1y ago
Yeah. I think the trick is, you have to have been capable of doing it yourself, given time. Same as a senior engineer, they have to be capable of doing the tasks they assign to juniors.

leptons 1y ago

More often than not the "AI" generates a large block of code that doesn't work, that I still have to read and understand - and it's more difficult to understand because it doesn't work, which is a huge waste of my time. Then I just end up writing the damn code myself, which I should have done in the first place - but my boss wants me to try using the AI. The only thing the "AI" is marginally good at is as a fancy auto-complete that writes log statements based on the variable I just wrote into the code above it. And even this simple use case it gets it wrong a fair amount. Overall the "AI" is a net negative for me, but maybe close to break-even thanks to the autocomplete.

generalizations 1y ago
What "AI" are you using

eikenberry 1y ago

That last bracket is basically the same as the tech based start-up story. You build the projects fast, but you build a ton of tech debt into it that you'll be forced to deal with unless it is a short lived project. Not that this is 100% bad, but something to know going in.

generalizations 1y ago
Depends. I think that becomes a question of the quality of the programmer - if they were doing it all themselves, the code quality of the (necessarily much smaller) projects would still vary between programmers. Now that variation is magnified, but if you're very good at what you do, I suspect it is still possible to create those projects without the tech debt. Though at the lower end of that bracket, I'd agree you tend to end up with giant balls of mud.
- eikenberry 1y ago
  When you play architect and delegate all the work to junior developers it won't matter how good you are, you will incur a lot of tech debt. You simply cannot teach/guide every junior into writing good code as that would take more time than writing it yourself. This fact is baked into the juniors analogy.
  - generalizations 1y ago
    IMHO it depends on how good you are at being a senior programmer / architect. Put the juniors where they can't do harm, and orchestrate them appropriately. The whole point of employing juniors is that you don't assign a senior to rewrite everything they do.