371–380 of 483 posts
New policy boils down to "AI or not, it's still your code and you're responsible for it". I can get on board with that.
Earlier quoted context omitted.
It's my understanding that this same debate raged when writing became a thing. Many viewed it with suspicious, or derision, as memorization was the big intellectual thing. So writing and reading back to remember was terrible. It's true it was a dependence, but the value was too high. With reading and writing a person could work on and synthesize from a far wider range of concurrent materials than one could with just…
Yeah, exactly -- when we automated muscles in the industrial revolution, it was fine. Today, we're automating thinking. And, while there are people that still lift weights for fun, it's not needed professionally any more. I think we'll end up in the same place with thinking -- education is probably going to be a hobby, not a requirement.
Earlier quoted context omitted.
I am pretty tired of this analogy because it does not hold up to scrutiny. The purpose of a programming language is to describe a logical routine in deterministic nonambiguous language. A program is a set of nonambiguous instructions. Heightening levels of abstraction traditionally did not result in less understanding of the program's high-level routine. An example: 'read input from CLI, do this specific transform on…
> The prompts are not analogous to a higher level of abstraction in this way; they are analogous to JIRA tickets. Your first prompt could be instructions to guide creation of a spec, which leads to a test suite you personally validate, which leads to code to pass those tests in a deterministic way. Then it is your job to review and QA it until it is quality enough to submit to a peer for code review. There are many m…
Also, the staff engineers who review code all day typically do not really understand the program either. They understand the spec and they have a model of how things should work such that they can answer "should" questions, but they cannot tell you what exactly is going on in the depths of the program; that's not their job. The tools are not capable right now of creating a quality program that the operator only understands at a conceptual level. Again, someone has to actually know, still.
I find AI useful for small shell scripts that you can visually inspect.
I want to make a GIF later, so I'll probably ask Duck.AI how to write the command if the file path to the MKV is X and the timestamps are Y and Z.
Then, I can create my own little tool without downloading some shady binary that slaps a UI on Imagemagik(sp?) or whatever.
I've only played with AI a little bit, with a focus on local LLMs, but even simple things like an anonymous FTP scanner I wrote took a lot longer than someone slightly more skilled than me could have done them in.
Anyways, I always respected how Debian gatekeeps access to the code -- some kinds of gatekeeping are cool and good, and a lot of young folks fight with devs trying to show how smart they are -- I've been guilty of that myself in my youth.
Debian has begun voting on the future of AI/LLM contributions
https://news.ycombinator.com/item?id=49309050
Debian polls its developers on AI: permit or ban?
New policy boils down to "AI or not, it's still your code and you're responsible for it". I can get on board with that.
Well most of the time but either way that’s on me.
Earlier quoted context omitted.
That's a very narrow view. If anyone could vibe code their printer drivers, maybe free software wouldn't have existed, because it would not have been needed in the first place.
Certainly, but if everyone can vibe code their printer drivers then we have free software in the sense of free speech and so users would be developers and the entire need is met. That is wonderful, not awful. If it had happened early enough, code copyright might never have even been possible and no one can deny you your machine because you can just vibe up stuff.
Earlier quoted context omitted.
I'm not convinced it blows up. It might also end up placing a larger burden on contributors, and especially first-time contributors, to provide concise, high-quality documentation that justifies their contribution. I'm thinking of something like: Explain, in at most 300 characters, why we should merge your change, or at least why we should invest the time to read a longer explanation (somethings things ARE complex).…
That doesn't really solve the problem. I've gotten PRs that do do an adequate job of explaining why why something should be implemented. Then I look at the code and it doesn't fully solve the problem, or it does so in a way that will obviously break something else.
Not trying to downplay the time wasted to reject the PR, though.
Earlier quoted context omitted.
> The prompts are not analogous to a higher level of abstraction in this way; they are analogous to JIRA tickets. Your first prompt could be instructions to guide creation of a spec, which leads to a test suite you personally validate, which leads to code to pass those tests in a deterministic way. Then it is your job to review and QA it until it is quality enough to submit to a peer for code review. There are many m…
The reason TDD never really caught on is because it doesn't really work. You don't know in advance what tests need to exist. A test suite is not sufficient to understand the program. Nor is a spec sufficient to understand the program. You have to read the program to understand the program. A spec is English and a test suite is like a converging upper and lower bound to an unknown value. Neither are good enough. Also,…
Regardless, I run a security auditing company where we constantly find severe bugs in human written code proving the engineers writing it had major gaps in their understanding of their own code. And, others have found flaws like that in my own hand written code! We humans are often very blind at seeing the flaws in our own logic and AIs learned from us.
Also, as code reviewers that can spot bugs authors and AIs miss, we are often paid a lot more than the original authors for our time. Also it almost never takes as much time as writing the code in the first place which likely required many round trips with customers to establish needs and fix bugs etc.
Your claims imply that only someone that hand types every semicolon is capable of understanding the code does not hold up even in the pre AI world.
Code review was the most important job in software engineering before AI and that is still true now.