71–80 of 234 posts
The whole premise of the post, that coders remember what and why they wrote things from 6 months ago, is flawed. We've always had the problem that understanding while writing code is easier than understanding code you've written. This is why, in the pre-AI era, Joel Spolsky wrote: "It's harder to read code than to write it."
The whole premise of the post, that coders remember what and why they wrote things from 6 months ago, is flawed. We've always had the problem that understanding while writing code is easier than understanding code you've written. This is why, in the pre-AI era, Joel Spolsky wrote: "It's harder to read code than to write it."
For example, handwritten code also tended to be reviewed manually by each other member of the team, so the probability of someone recalling was higher than say, LLM generated code that was also LLM reviewed.
Also, you can ask the coding agent for help at understanding it, unlike the old days when whoever wrote it is long gone.
And now programmers experience what is like to be a user, trying to comprehend the system on their computer screen. I propose a new paradigm: programmer experience, PX. So, code generated by AI ideally would follow the rules of PX. Whatever those may turn out to be.
Not to disagree with anything the article talks about but to add some perspective... The complaint about "code nobody understands" because of accumulating cognitive debt also happened with hand-written code. E.g. some stories: - from https://devblogs.microsoft.com/oldnewthing/20121218-00/?p=58... : >Two of us tried to debug the program to figure out what was going on, but given that this was code written several year…
Great article. I agree with the argument. But to offer a counter argument, would the same thing not have happened with the rise of high level languages? The machine code was abstracted away from engineers and they lost understanding of it, only knowing what the high level code is supposed to do. But that turned out fine. Would llms abstracting the code away so engineers only understand the functionality (specs, tests…
It did not turn out fine. Fortunately no one took it seriously, and at least seniors still have an intuitive model of how the hardware works in their head. You don't have to "see" the whole assembly language when writing high level code, just know enough about how it goes at lower levels that you don't shoot yourself in the foot.
When that's missing, due to lack of knowledge or perhaps time constraints, you end up on accidentally quadratic or they name a CVE after you.
I think we might as well just go all in at this point: "LGTM, LLM". The industry always overshoots and then self-corrects later. Therefore, maybe the right thing to do is help it get to a more sane equilibrium is to forget about the code altogether and focus on other ways to constrain it / ensure correctness and/or determine better ways to know when comprehension is needed vs optional. What I don't like is the imposs…
Every one of us is a pioneer if we choose to be. We have only scratched the surface as an industry.
This happened to me yesterday. I give a junior engineer a project. He turns it around really quickly with Cursor. I review the code, get him to fix some things (again turned around really quickly with Cursor) and he merges it. I then try a couple test cases and the system does the wrong thing on the second one I try. I ask him to fix it. He puts into cursor a prompt like "fix this for xyz case" and submits a PR. But…
This is like our whole technological society: many people only comprehend a small part of it at a time and only sketches of how other parts work