Obviously I could just better review my own code, but that’s proving easier said than done to the point where I’m considering going back to vanilla Code.
I think about coding assistants like this as well. When I'm "ahead of the code," I know what I intend to write, why I'm writing it that way, etc. I have an intimate knowledge of both the problem space and the solution space I'm working in. But when I use a coding assistant, I feel like I'm "behind the code" - the same feeling I get when I'm reviewing a PR. I may understand the problem space pretty well, but I have to basically pick up the pieced of the solution presented to me, turn them over a bunch, try to identify why the solution is shaped this way, if it actually solves the problem, if it has any issues large or small, etc.
It's an entirely different way of thinking, and one where I'm a lot less confident of the actual output. It's definitely less engaging, and so I feel like I'm way less "in tune" with the solution, and so less certain that the problem is solved, completely, and without issues. And because it's less engaging, it takes more effort to work like this, and I get tired quicker, and get tempted to just give up and accept the suggestions without proper review.
I feel like these tools were built without any sort of analysis if they _were_ actually an improvement on the software development process as a whole. It was just assumed they must be, since they seemed to make the coding part much quicker.
It also doesn't help reviewing such code that sometimes surprisingly complex problems are solved correctly, while there's surprisingly easy parts that can be subtly (or very) wrong.
A hard pill to swallow is that a lot of software developers have spent most of their careers "behind the code" instead of out ahead of it. They're stuck for years in an endless "Junior Engineer" cycle of: try, compile, run, fix, try, compile, run, fix--over and over with no real understanding, no deliberate and intentional coding, no intimacy, no vision of what's going on in the silicon. AI coding is just going to keep us locked into this inferior cycle.
All it seems to help with is letting us produce A Lot Of Code very quickly. But producing code is 10% of building a wonderful software product....
Makes you look more efficient but it doesn't make you more effective. At best you're just taking extra time to verify the LLM didn't make shit up, often by... well, looking at the docs or the source.. which is what you'd do writing hand-crafted code lol.
I'm switching back to emacs and looking at other ways I can integrate AI capabilities without losing my mental acuity.
I mean, I generally avoid using mocks in tests for that exact reason, but if you expect your AI completions to always be wrong you wouldn't use them in the first place.
Beyond that, the tab completion is sometimes too eager and gets in the way of actually editing, and is particularly painful when writing up a README where it will keep suggesting completely irrelevant things. It's not for me.
Yea, this is super annoying. The tab button was already overloaded between built-in intellisense stuff and actually wanting to insert tabs/spaces, now there are 3 things competing for it.
I'll often just want to insert a tab, and end up with some random hallucination getting inserted somewhere else in the file.
But still there is too much noise now. I don't look at the screen while I'm typing so that I'm not bombarded by this eager AI trying to distract me with guesses. It's like a little kid interrupting all the time.
Also telling it not to code, or not to jump to solutions is important. If there's a file outlining how you like to approach different kinds of things, it can take it into consideration more intuitively. Takes some practice to pay attention to your internal dialogue.
aw yeah; recently I spent half a day pulling my hair debugging some cursor-generated frontend code just to find out the issue was buried in some... obscure experimental CSS properties which broke a default button behavior across all major browsers (not even making this up).
Velocity goes up because you produce _so much code so quickly_, most of which seems to be working; managers are happy, developers are happy, people picking up the slack - not so much.
I obviously use LLMs to some extent during daily work, but going full-on blind mode on autopilot gotta crash the ship at some point.