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.
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.
1 reply →