The thing about boilerplate is that a good library or framework makes it optional, and / or automatically written.
I'd much rather django-admin startproject, npm init, or meteor create and get deterministic output than prompt an LLM and get who knows what.
In a mature web ecosystem, boilerplate is minimal. I worry now that we've given this task to LLMs, less development effort will go into startproject-esqe CLIs and good opinionated defaults.
I wonder this in general, what's the impetus for writing new frameworks and such? Are we already seeing a slow down in that space? HN front page certainly paints that picture.
You're better off plonking down an existing framework and getting all the structural boilerplate benefits the LLM can leverage.
LLMs are far better at frameworks they have a lot of training data for, if have been around for a while. They write more idiomatic, ecosystem friendly code. Does that still matter?
I feel like, if an LLM can one-shot a say 500 LOC project from a single-line prompt, and doesn't require the user to make any choices, and the result is actually acceptable, then 499 of those LOC are definitionally "boilerplate". They have been demonstrated, by this process, to have no more design-information content than the prompt, except perhaps a few constants where effectively random / statistically likely values were good enough.
> In a mature web ecosystem, boilerplate is minimal.
I don't think I even have words for my level of disagreement here.
> I worry now that we've given this task to LLMs, less development effort will go into startproject-esqe CLIs and good opinionated defaults.
I certainly hope not. I feel like an LLM-powered project could very much benefit from having those kinds of pieces to work with.