I found the article interesting, but I agree with you. Good programmers have to and can debug other people’s code. But, to be fair, there are also a lot of bad programmers, and a lot that can’t debug for shit…
Comment on I Went All-In on AI. The MIT Study Is Right.
dsilverz@calckey.world 6 days ago
@AutistoMephisto@lemmy.world @technology@lemmy.world
I used to deal with programming since I was 9 y.o., with my professional career in DevOps starting several years later, in 2013. I dealt with lots of other's code, legacy code, very shitty code (especially done by my "managers" who cosplayed as programmers), and tons of technical debts.
Even though I'm quite of a LLM power-user (because I'm a person devoid of other humans in my daily existence), I never relied on LLMs to "create" my code: rather, what I did a lot was tinkering with different LLMs to "analyze" my own code that I wrote myself, both to experiment with their limits (e.g.: I wrote a lot of cryptic, code-golf one-liners and fed it to the LLMs in order to test their ability to "connect the dots" on whatever was happening behind the cryptic syntax) and to try and use them as a pair of external eyes beyond mine (due to their ability to "connect the dots", and by that I mean their ability, as fancy Markov chains, to relate tokens to other tokens with similar semantic proximity).
I did test them (especially Claude/Sonnet) for their "ability" to output code, not intending to use the code because I'm better off writing my own thing, but you likely know the maxim, one can't criticize what they don't know. And I tried to know them so I could criticize them. To me, the code is.. pretty readable. Definitely awful code, but readable nonetheless.
So, when the person says...
The developers can’t debug code they didn’t write....even though they argue they have more than 25 years of experience, it feels to me like they don't.
One thing is saying "developers find it pretty annoying to debug code they didn't write", a statement that I'd totally agree! It's awful to try to debug other's (human or otherwise) code, because you need to try to put yourself on their shoes without knowing how their shoes are... But it's doable, especially by people who deal with programming logic since their childhood.
Saying "developers can't debug code they didn't write", to me, seems like a layperson who doesn't belong to the field of Computer Science, doesn't like programming, and/or only pursued a "software engineer" career purely because of money/capitalistic mindset. Either way, if a developer can't debug other's code, sorry to say, but they're not developers!
Don't take me wrong: I'm not intending to be prideful or pretending to be awesome, this is beyond my person, I'm nothing, I'm no one. I abandoned my career, because I hate the way the technology is growing more and more enshittified. Working as a programmer for capitalistic purposes ended up depleting the joy I used to have back when I coded in a daily basis. I'm not on the "job market" anymore, so what I'm saying is based on more than 10 years of former professional experience. And my experience says: a developer that can't put themselves into at least trying to understand the worst code out there can't call themselves a developer, full stop.
JuvenoiaAgent@piefed.ca 6 days ago
dsilverz@calckey.world 6 days ago
@JuvenoiaAgent@piefed.ca @technology@lemmy.world
Often, those are developers who "specialized" in one or two programming languages, without specializing in computer/programming logic.
I used to repeat a personal saying across job interviews: "A good programmer knows a programming language. An excellent programmer knows programming logic". IT positions often require a dev to have a specific language/framework in their portfolio (with Rust being the Current Thing™ now) and they reject people who have vast experience across several languages/frameworks but the one required, as if these people weren't able to learn the specific language/framework they require.
Languages and framework differ on syntax, namings, paradigms, sometimes they're extremely different from other common languages (such as (Lisp (parenthetic-hell)), or.asciz "Assembly-x86_64"), but they all talk to the same computer logic under the hood. Once a dev becomes fluent in bitwise logic (or, even better, they become so fluent in talking with computers that they can say41 53 43 49 49 20 63 6f 64 65without tools, as if it were English), it's just a matter of accustoming oneself to the specific syntax and naming conventions from a given language.
Back when I was enrolled in college, I lost count of how many colleagues struggled with the entire course as soon as they were faced by Data Structure classes, binary trees, linked lists, queues, stacks... And Linear Programming, maximization and minimization, data fitness... To the majority of my colleagues, those classes were painful, especially because the teachers were somewhat rigid.
And this sentiment echoes across the companies and corps. Corps (especially the wannabe-programmer managers) don't want to deal with computers, they want to deal with consumers and their sweet money, but a civil engineer and their masons can't possibly build a house without willing to deal with a blueprint and the physics of building materials. This is part of the root of this whole problem.floofloof@lemmy.ca 6 days ago
The hard thing about debugging other people’s code is understanding what they’re trying to do. Once you’ve figured that out it’s just like debugging your own code. But not all developers stick to good patterns, good conventions or good documentation, and that’s when you can spend a long time figuring out their intention. Until you’ve got that, you don’t know what’s a bug.
fruitycoder@sh.itjust.works 5 days ago
That feels like the trap here. There is no intention, just patterns.
Munkisquisher@lemmy.nz 6 days ago
When the cost to generate new code has become so cheap,and the cost of devs maintaining code they didn’t write gets higher. There’s a huge shift happening to just throw out the code and regenerate it instead. Next year will be the find out phase, where the massive decline in code quality catches up with big projects.
MangoCats@feddit.it 5 days ago
where the massive decline in code quality catches up with big projects.
That’s going to depend, as always, on how the projects are managed.
LLMs don’t “get it right” on the first pass, ever in my experience - at least for anything of non-trivial complexity. But, their power is that they’re right more than half of the time AND when they can be told they are wrong (whether by a compiler, or a syntax nanny tool, or a human tester) AND then they can try again, and again as long as necessary to get to a final state of “right,” as defined by their operators.
The trick, as always, is getting the managers to allow the developers to keep polishing the AI (or human developer’s) output until it’s actually good enough to ship.
The question is: which will take longer, which will require more developer “head count” during that time to get it right - or at least good enough for business?
I feel like the answers all depend on the particular scenarios - some places some applications current state of the art AI can deliver that “good enough” product that we have always had with lower developer head count and/or shorter delivery cycles. Other organizations with other product types, it will certainly take longer / more budget.
However, the needle is off 0, there are some places where it really does help, a lot. The other thing I have seen over the past 12 months: it’s improving rapidly.
Will that needle ever pass 90% of all software development benefitting from LLM agent application? I doubt it. In my outlook, I see that needle passing +50% in the near future - but not being there quite yet.
Jayjader@jlai.lu 6 days ago
Given the stochastic nature of LLMs and the pseudo-darwinian nature of their training process, I sometimes wonder if geneticists wouldn’t be more suited to interpreting LLM output than programmers.
dsilverz@calckey.world 6 days ago
@Jayjader@jlai.lu @technology@lemmy.world
Given how it's very akin to dynamic and chaotic systems (e.g. double pendulum, whose initial position, mass and length rules the movement of the pendulum, very similar to how the initial seed and input rule the output of generative AIs) due to the insurmountable amount of physically intertwined factors and the possibility of generalizing the system in mathematical, differential terms, I'd say that the more fit would be a physicist. Or a mathematician. lol
As always, relevant xkcd: https://xkcd.com/435/
jj4211@lemmy.world 6 days ago
An LLM can generate code like an intern getting ahead of their skis. If you let it generate enough code, it will do some gnarly stuff.
Another facet is the nature of mistakes it makes. After years of reviewing human code, I have this tendency to take some things for granted, certain sorts of things a human would just obviously get right and I tend not to think about it. AI mistakes are frequently in areas my brain has learned to gloss over and take on faith that the developer probably didn’t screw that part up.
AI generally generates the same sorts of code that I hate to encounter when humans write, and debugging it is a slog. Lots of repeated code, not well factored. You would assume of the same exact thing is fine in many places, you’d have a common function with common behavior, but no, AI repeated itself and didn’t always get consistent behavior out of identical requirements.
His statement is perhaps an over simplification, but I get it. Fixing code like that is sometimes more trouble than just doing it yourself from the onset.
Now I can see the value in generating code in digestible pieces, discarding when the LLM gets oddly verbose for simple function, or when it gets it wrong, or if you can tell by looking you’d hate to debug that code. But the code generation can just be a huge mess and if you did a large project exclusively through prompting, I could see the end result being just a hopeless mess.v frankly surprised he could even declare an initial “success”, but it was probably “tutorial ware” which would be ripe fodder for the code generators.