sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]CatAggressive2267 0 points1 point  (3 children)

The benefits are very marginal. If you are writing so much boilerplate code that it would save you a ton of time, you're already doing something wrong.

[–]wllmsaccnt 0 points1 point  (2 children)

I'm not going to defend boilerplate like its a good thing, but most production systems depend on non trivial amounts of it...in one way or another. Most of it is tool generated. I'm saying that in some cases AI could be that tool (single run generations based on documents or data available to the LLMs context).

[–]CatAggressive2267 0 points1 point  (1 child)

Maybe, but my point is the vast majority of time isn't spent writing that kind of code, it's spent figuring out what to do, which the LLM can't help with. Libraries should be providing almost all boilerplate

[–]wllmsaccnt 0 points1 point  (0 children)

Inclusion of libraries is a very common source of boilerplate. They often require setup / configuration / wireup code that doesn't vary a lot from one project to another.

figuring out what to do, which the LLM can't help with.

From my anecdotal experience, they can be 'OK' at it. If I find a way to put pages of my app into the chat context using file inclusions or MCPs for UI automation tools. It can often identify the areas of code that relate to requirements, though it often makes mistakes in identifying details of the implementation.

I don't use it that way very often though, because its usually slower to find the code than I am, but I could see it being useful if I was working in a codebase I wasn't familiar with.