That sounds like you're fresh out of college. Copilot is great at scaffolding but doesn't do shit for bug fixing, design, or maintenance. How much scaffolding do you think a senior engineer does per week?
That sounds like you're fresh out of college. Copilot is great at scaffolding but doesn't do shit for bug fixing, design, or maintenance. How much scaffolding do you think a senior engineer does per week?
Maybe take a look at tools like aider-chat with Claude 3.5 Sonnet. Or just have a discussion with gpt-4o about any programming area that you aren't particularly familiar with already.
Unless you literally decided you learned everything you need and don't try to solve new types of problems or use new (to you) platforms ever..
I just read the manual.
I once worked with someone who was brilliant, but fell apart when we tried to do pair-programming (acturial major who had moved into coding). The verbal communication overhead was too much for him.
I've always thought of software development as an inherently solo endeavor that happens entirely inside of one's own mind. When I'm faced with a software problem, I map out the data structures, data flows, algorithms and so on in my mind, and connect them together up there. Maybe taking some notes on a sheet of paper for very complex interactions. But I would not really think of sitting down with someone to "chat" about it. The act of articulating a question "What should this data structure look like and be composed of?" would take longer than it would take to simply build it and reason about it in my own brain. This idea that software is something we do in a group socially, with one or more people talking back and forth, is just not the way I operate.
Sure, when your software calls some other person's API, or when your system talks to someone else's system, or in general you are working on a team to build a large system, then you need to write documents and collaborate with them, and have this back-and-forth, but that's always kind of felt like a special case of programming to me.
The idea of asking ChatGPT to "write a method that performs a CRC32 on a block of data" seems silly to me, because it's just not how I would do it. I know how to write a CRC function, so I would just write it. The idea of asking ChatGPT to help write a program that shuffles a deck of cards and deals out hands of Poker is equally silly because before I even finished writing this sentence, I'm visualizing the proper data structures that will be used to represent the cards, the deck, and players' hands. I don't need someone (human or AI) to bounce ideas off of.
There's probably room for AI assistance for very, very junior programmers, who have not yet built up the capability of internally visualizing large systems. But for senior developers with more experience and capability, I'd expect the utility go down because we have already built out that skill.
Chat interface is annoying, though. Because it's natural language, I have to type a lot more, which is frustrating - but on the other hand, because it's natural language, I can just type my stream of thought and the LLM understands it. The two aspects cancel out each other, so in terms of efficiently, it's a wash.
Sr. Eng adopted copilot and sung it's praises a lot faster then the jr engineers. Especially when working on codebases with less familiar languages.
And yes cursor AI/copilot helps with bugs as well.
It works because when you have a bug/error message, instead of spending a bunch of time on Google/searching on stack overflow for the exact right answer, you can now do this:
"Hey AI. Here is my error message and stack trace. What part of the code could be causing it, and how should I fix it".
Even for debugging this is a massive speed up.
You can also ask the AI to just evaluate your code. Or explain it when you are trying to understand a new code base. Or lint it or format it. Or you can ask how it can be simplified or refactored or improved.
And every hour that you save not having to track down crazy bugs that might just be immediately solvable, is an hour that you can spend doing something else.
And that is without even getting into agents. I haven't figured out yet how to effectively use those yet, and even that is making me nervous/worried that I am missing some huge possible gains.
But sure, I'll agree that of all you are doing is making scaffolding, that is a fairly simply usecase.
That's not how I work since I stopped being a junior dev. I might google an error message/library combination if I don't understand it but in most cases, I just read the stacktrace and the docs, or maybe the code.
I don't doubt that LLMS can be quite useful when working with large, especially foreign, codebases. But I have yet to see the level of "if you don't use it you're not an engineer" some people like to throw around. To the contrary, I'd argue if you rely on an LLM to tell you what you should be doing, you aren't an engineer, you are a drone.