![]() | No ratings.
There's a huge push for developers to use AI in their coding. Is there a benefit? |
After over 40 years programming computers, I've finally learned something new, and it's all thanks to AI. Recently, I've been seeing blog posts from Microsoft touting Copilot for developers. Blog posts are coming fast and furiously about how to leverage AI to make better programs faster. Nice thought, but look at these blog questions! Each blog purports to pose an AI solution to a problem by first stating the problem to be solved as a question. Here are three I just encountered in the past month: Roadmap for AI in Visual StudioIn this blog post, they're talking about their ongoing commitment to providing AI "agentic" experiences. In other words, have AI act as your personal programmer. First, to be honest, I haven't tried their Copilot service. But that's because of two things:
Why would I want to trust years-worth of programming effort to an AI "agent" with editing capability? I wouldn't even do that with an experience human, let alone an error-prone entity, even if it were a savant. (For a human review, they get a copy, not edit access.) "We've been listening to your feedback on Agent Mode and Chat..." Really? That's nice to hear. It's nice that you're promising faster performance, because you're right. The IDE has slowed to a crawl lately. It can take five seconds just to switch to editing a different page in an already open frame! And that's when I haven't enabled Copilot! No thanks, I've already improved the performance. I dug around the settings and found how to uninstall Copilot. Speed returned. They're asking for feedback. What could I possibly say? "I don't want this crap on my computer" will just be ignored, so no feedback given. This probably goes for a huge number of programmers, but they won't realize it, they'll just blindly continue to develop this insane system. Boost Your Copilot Collaboration with Reusable Prompt Files"Writing effective prompts for AI tools can be time-consuming and challenging." That's how they open this one. Really? You mean I can't just say, "Write me a new program that will generate thousands of dollars in profits every day by solving a problem for people," and having everything done for me? This goes back to my oft-stated complaint about programming, particularly programming with teams of programmers. By the time I write, edit, and explain complete analysis documentation on what I need a module to do, I could have just written the code myself. That actually was part of my approach when I did write with a team. I'd write the top-level code, calling on routines that weren't even written yet. Then I'd tell someone on the team to write that routine that doesn't exist. The name and parameter list should be sufficient to understand what it's supposed to do. A programmer can take it from there. But they often can't. This blog post goes on to explain the same problem with AI. Sure, I could write a prompt and have Copilot generate C# code to do whatever it is that I want done - provided it is extremely simple, like "Add two variables and multiply the result by the average price of beans on the Chicago commodities market." Come to think of it, that might be too complex. Anyway, my point is that writing the prompt is like, um, writing the code in Visual Basic. You know, the language you decided to stop supporting when you moved decision making to India? So, what's their solution? Reusable prompts! No, I'm not kidding. Now, you can store your well-written prompts - you know, the ones where the AI actually wrote some good code - so you can just repeat the prompt again when you need the same code in another project or procedure. Wow! Reusable prompts! Who'd have thunk it? Oh, wait, isn't that like the reusable code we've been supposedly using for decades? I wrote some complex data calculation functions back in the '80s that took care of a lot of calculations needed in finance having to do with time. It took a week to write it and make sure it was 100% accurate. I didn't just test a random number of computations, I tested each and every single calculation for 1950-2050 just to make sure I'd be dead before a problem surfaced. Once I finished that code, I created something called a "compile unit." My colleagues weren't even aware of that file type. What it did was to make that function automatically available on a system wide basis to any program that knew he function name. Reusable code. We never wrote another date calculation. But, you know what? It took a month before my boss accepted the idea. He was highly skeptical since he didn't understand the code - he just had to trust it. And that's with him knowing me and my skill level. He knew I wouldn't present something I didn't think was 100% complete. Copilot doesn't do that. It writes "suggested code." It's up to you to read the code and tweak it before using it. Again, I'll just write my own. And forget "reusable prompts." I've got reusable code. Make Sense of Your Output Window with Copilot"Ever found yourself staring at the Output Window, overwhelmed by endless lines of logs and cryptic messages?" Actually, no, I haven't. I know that the issue I need to pay attention to is in one of two places: Either it is one line before the first complaint the Output Window lists (70% probability) or the first line the Output Window lists (30% probability). Do you know how I know that? Experience. Comprehension. Knowledge of the design of the code. In other words, because I wrote it. ConclusionSo, what is this epiphany that happened to me today? I found out that I am not a developer. For the recent past, "software engineers" have been going by the name "developer." But I'm finding that most "developers" know little about actual logic and what goes on inside the machine. When I started, "software engineers" started out as "programmers." We'd be given the name of a project or routine, its stated goal, and the information available to it (parameters). The programmer would then write the computer code (sometimes directly into binary machine language) to accomplish the goal of the routine. A programmer did not need to know why the routine was needed, only what it was to do. A programmer may not even be aware of the complexities of the system. Not his job. Not his problem. Once you became a proficient programmer, you would then be promoted to "Systems Analyst." The analyst would write those routine briefs for the programmers. An analyst would know the big picture. He would only write code if it were complex - like the original program that calls all of those routines - or if the routine was over the programmer's head. Or, of course, if he is writing the entire system himself... From what I see, developers don't even understand what an analyst knows intuitively. Today's developers sometimes don't even have rudimentary skills needed by a programmer. So, I am not a developer. I never have been, and I never will be. I am a Systems Analyst. So, Microsoft, please don't bog my editor down with "intelligence" that isn't even close to my own skill level. Google, please stop asking me (on every fifth Google search) if I would like to use "AI mode." The answer is no. It will always be no. When I have a question, I will check the documentation. If I don't find an answer there, I'll go on StackOverflow.com and ask my colleagues if they've encountered a similar problem and if they found a solution. By the way, Stack Overflow has also banned AI responses from their site. I guess they're not developers either. |