[rafaelmn]

> Using LLMs to bootstrap development in unfamiliar frameworks is a valuable approach when balanced with pragmatic engineering principles. While framework idioms are important, they're secondary to delivering working, maintainable software that solves real problems.

Except that using the original approach would make it hard to navigate the project after a few weeks of development - duplicate logic all over, inconsistency in duplicates, bugs. Rewriting the code to actually use the framework as intended let me progress much faster and reuse the code.

And as someone who has had gigs with 6 different languages/stacks at this point, and played with probably as much on the side - that's a nice sentiment in theory but doesn't reproduce in practice. There's definite learning curve when using a new stack/language - sure your experience makes that curve different to a newbie, but in my experience it's going to be a few months until you can move as quickly as you can with a stack you're familiar with.

[exhaze]

That’s a nice generalization from a single data point but the problem here is that I have experience with… 10-15? across 7 companies in my career and it’s worrying to me to hear you say it takes you a few months - especially in today’s world where you can rapidly accelerate your rate of learning and understanding of existing idioms within a framework/specific codebase with LLMs.

As LLM capabilities and context windows advance, if you’re blaming the LLM for this it means you don’t know how to use it.

Sorry, but there is too much empirical evidence of this both from first-hand experience as well as what I’ve seen from many other practitioners who started with the question of “how can I improve this?” instead of “this sucks”.