Not even front end, unless it literally is a dumb thin wrapper around a back end. If you are processing anything on that front end, AI is likely to fall flat as quickly as it would on the backend.

based on what?

My own experience writing a web-based, SVG-based 3D modeler. No traditional back end, but when working on the underlying 3D engine it shits the bed from all the broken assumptions and uncommon conventions used there. And in the UI, the case I have in mind involved pointer capture and event handling, it chases down phantoms declaring it's working around behavior that isn't in the spec. I bring it the spec, I bring it minimal examples producing the desired behavior, and it still can't produce working code. It still tries to critique existing details that aren't part of the problem, as evidenced by the fact it took me 5 minutes to debug and fix myself when I got tired of pruning context. At one point it highlighted a line of code and suggested the problem could be a particular function getting called after that line. That function was called 10 lines above the highlighted line, in a section it re-output in a quote block.

So yes, it's bad for front end work too if your front end isn't just shoveling data into your back end.

AI's fine for well-trodden roads. It's awful if you're beating your own path, and especially bad at treading a new path just alongside a superhighway in the training data.

it built the meat of the code, you spent 5 minutes fixing the more complex and esoteric issues. is this not the desired situation? you saved time, but your skillset remained viable

> AI's fine for well-trodden roads. It's awful if you're beating your own path, and especially bad at treading a new path just alongside a superhighway in the training data.

I very much agree with this, although I think that it can be ameliorated significantly with clever prompting

I sincerely wish that had been the case. No, I built the meat of the code. The most common benefit is helping to reducing repetitive typing, letting me skip writing 12 minor variations of `x1 = sin(r1) - cos(r2)`.

Similar to that, in this project it's been handy translating whole mathematical formulas to actual code processes. But when it comes out of that very narrow box it makes an absolute mess of things that almost always ends in a net waste of time. I roped it into that pointer capture issue earlier because it's an unfamiliar API to me, and apparently for it, too, because it hallucinated some fine wild goose chases for me.

wrt unfamiliar APIs, I don't know if this would have worked in your case (perhaps not) but I find that most modern LLMs are very comfortable with simply reading and using the docs or sample code here and now if you pass them the link or a copy paste or html containing the relevant info

> I had actually done this before a few years ago, so I knew exactly what I wanted

Oh :) LLMs do work sometimes when you already know what you want them to write.

> that kind of code is just too formulaic, transactional and often boring to do

No offense, but that sounds like every programmer that hasn't done front-end development to me. Maybe for some class of front-ends (the same stuff that Ruby on Rails could generate), but past that things tend to get not boring real fast.

I do a fair amount of dashboards and data handling stuff. I don’t really want to deal with React/Vue at all, and AÍ takes most of the annoyance away.

> I had actually done this before a few years ago, so I knew exactly what I wanted

Why not just use the one you already wrote?

> Why not just use the one you already wrote?

Might be owned by a previous employer.