5 ms·
I just don't buy it. This is the classic non-programmer's view of programming productivity. It is really easy to dash off hundreds of lines a day. Doing so feel
by asfginoinio 3y ago
I just don't buy it. This is the classic non-programmer's view of programming productivity. It is really easy to dash off hundreds of lines a day. Doing so feels great, but is in fact massively counterproductive. The hard work of software development benefits from deep thought, not shallow. Ten lines of well-tested, peer-reviewed code are more valuable than ten thousand lines of crud. Any time a programmer complains something will slow down their work, that's a point in its favor.
"AI"-based static analysis tools might be valuable. If I ever see "AI"-based code generation on a project I run before I get stuck cleaning up the mess.
- deleted 3y ago[deleted]
- tredre3 3y agoConversely I think you express the view of a non-ai-assisted programmer. LLMs don't just dash out hundreds of lines of code. They can take a concept and break it down into concrete steps or even a fully planned architecture for you. That's literally the hard work you describe. AI can do it beautifully, it just needs a human capable of critical thought to steer it (human understanding of the subject at hand is merely a bonus, not a requirement).
- t1mmen 3y agoHard agree. I’ve been at this for 22+ years now, and GPT4 by my side has made me AT MINIMUM 2x as productive; on a good day, 5x. The separation will very clearly be “legacy devs” vs “AI-powered devs”. I’ve spent a tremendous amount of time thinking about how the problems should be solved on my current project — big picture, and small. Once the system design became clear, about 80% remains as “just write the damn code” type work. I outsource about 70% of that to GPT, while keeping my focus on the important parts; the right abstractions, modular and self-contained functions, good naming and function signatures, making sure it all works and makes sense in harmony. I don’t care (too much) about the inner workings of every function, so long as the abstraction and usage of it is great (and well tested). Refactoring, if ever needed, is trivial then. My overall work has never been better. Anybody dismissing AI for any level of programming is doing themselves a huge disservice.
- physicles 3y agoI've also been in industry for ~17 years and coding for a decade or so before that, but I'd seriously sit down and watch an hour long video of someone just using AI to work on a large existing system. Virtually all the AI coding content out there is about building something new from scratch. Could elaborate more on your workflow? Do you use Copilot, or just GPT4? Are you copying and pasting large blocks of existing code to hint at how things should fit together, or do you describe how the existing code is structured in English? Do you find yourself decomposing your work differently so as to fit your new AI workflow?
- t1mmen 3y agoI use both Copilot and chat with GPT4. For now, it’s mostly copy/pasting large blocks of pre-existing code, types, etc. I have a pre-defined prompt set up to explain how to behave, languages I know, libraries in use, naming conventions, how to respond, etc. I talk GPT as if it’s a skilled colleague who’s got memory issues. When it forgets, I remind it with stuff like “this is our current code now, remember X, Y, Z” I’ve become an even bigger fan of small, compostable functions that do one thing very well. GTP excels at that, both writing and testing them. I don’t involve it much for architecture and high-level design atm (mostly because I got that part solved on my current project). I tend to have a design in mind, give GPT the overview of how it fits together with mock code, and ask it to review with me, propose other paths we could take, etc before proceeding to implement. One function at the time, with tests. When refactoring happens, it’s usually isolated to a few hundred lines at most. When tests fail, directly or indirectly, I give it the full output and ask it to debug and fix. I find this helps GPT remember the code’s responsibilities when it gets lost/forgets. It also helps me avoid regressions when GPT returns functions that miss use cases we had covered before. I keep long running chat threads — weeks at times, hundreds or even thousands of messages. The longer we go, the better it tends to perform (web app performance, even on an M2 Studio, does suffer after a while though) At worst, GPT is a fantastic rubber duck. At best, it’ll help me see superior approaches and solutions I wouldn’t have considered, AND give me perfect code in seconds. Once tooling gets really good, and AI can understand the whole code base/database/infra… we’ll probably be in real trouble.
- loandbehold 3y agoAgree. I've been using ChatGPT4 occasionally to write separate self contained pieces of code. It's amazing how good it is. The limitation right now is that you can't load your whole repo into it. So it's limited to small self contained pieces of code. You can give it functions it can call in the input, but still it's very limited right now. Once someone figures out how to load whole repo into it you will basically be able to assign tasks/bugs to it and it will create a PR for you. So you will only need to review PRs written by AI.
- weatherlite 3y ago> Once someone figures out how to load whole repo into it Yep that's the crux of the issue I agree. It's not just one repo, any well established org has millions of lines of code - can ChatGPT handle that kind of context size without any human directing it ? It's basically having an LLM trained specifically on your company data, and having it retrained constantly since the data keeps changing - what are the costs of that? We'll see.
- malux85 3y agoI get what you're saying about 10 lines of well-tested vs 10,000 lines of crud, but this hyperbole is also a false dichotomy. GPT-4 and Copilot absolutly makes me more productive as a programmer, wiring all the tests, getting maybe 80% of them right and then I fix them up. I am not producing 10,000 lines of crud, but I AM producing 1000 lines of test-covered code, I'm doing the hard bits, and the AIs are doing the menial parts. I am by far the most productive programmer on the team however you measure it (we have about 60 different metrics available to management) and a large part of this is be having enough energy to always be attacking the hard problems, because I am not wasting mind power and time writing the trivial bits that can be automated. Does it get it right every time? Nope. Does it make hilariously wrong mistakes? Yep, about once or twice a day! Is it worth it? Absolutly.
- dx034 3y agoI'm completely with you. But 60 metrics for management to track programmers? That honestly doesn't sound like a great work environment.
- malux85 3y agoIt is great, I use them to self improve all the time, I like things that are critical of me, or show me where I am weak. Everyone (including management) is aware of all of the tropes and cliches about how metrics cease to be good when they become targets and how metrics can be gamed blah blah blah - we all know that - and have imbibed that, but the rationale is that more (but imperfect) visibility is better than no visibility or solely subjective interpretations. As long as all metrics are assumed to be wrong until proven correct, with some digging, some thorough analysis and a judicious and abundant use of the benefit of the doubt, I find them really helpful.