There's this concept in aviation of "ahead of or behind the plane". When you're ahead of the plane, you understand completely what it's doing and why, and you're literally thinking in front of it, like "in 30 minutes we have to switch to this channel, confirm new heading with ATC" and so forth. When you're behind the plane, it has done something expected and you are literally thinking behind it, like "why did it make that noise back there, and what does that mean for us?"
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.
That's a great analogy. For me it is a very similar feeling that I get ripped out of "problem solving mode" into "code review mode" which is often a lot more taxing for me.
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....
This is such a great analogy! Exactly how I feel when using AI tools. I have had some incredibly productive conversations about high-level design where I explain my goals and the approaches I'm considering. But then the actual code will have subtle bugs that are hard to find.
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.