Readit Newssrvaroa commented on Dependency injection frameworks add confusion rednafi.com/go/di_framewo... · Posted by u/ingve
Looking forward to someone writing the Spring equivalent this on the JVM
srvaroa commented on AI generated code will choke delivery pipelines varoa.net/2025/04/07/ai-g... · Posted by u/srvaroa
You're not the first person to equate "typing more code faster" with velocity, productivity, execution speed, or whatever you want to call it.
Even for Luu, typing speed is important not for generating more faster, it's about being able to accomplish the important tasks that are a part of the job in less time.
I'm sure many people have equated "typing code faster" with velocity, productivity, and execution speed. But I am not doing it.
I'm saying that given N developers, if they all type code faster, you get more code. From the linked text: "Will this translate into a net increase of actual value or just an accumulation of slop and technical debt? Regardless of the answer, there will be more raw code."
The argument I'm making is based on more volume of code. Not on quality, value, etc. of whatever that code is doing.
On your point about nobody having thought "my problem is that can't type fast enough". The problem "shit, I'd know what I want, I'd rather spend 10 minutes typing than 1 hour" is real. An LLM allows you to say "I want a piece of code that does X" and it hydrates that into the 500 lines of code. You materialize the thing faster.
Now. Yes we can go back to your point. Was that idea good? Is the code good enough? etc. Those are valid questions, but orthogonal to my point. My point is not about the quality of outputs etc. It's about "this thing helps you churn more code, and throw it to the systems that digest code".
srvaroa commented on AI coding mandates are driving developers to the brink leaddev.com/culture/ai-co... · Posted by u/bluefirebrand
srvaroa commented on AI coding mandates are driving developers to the brink leaddev.com/culture/ai-co... · Posted by u/bluefirebrand
"When AI is able to deliver coding tasks based on a prompt, there won’t be enough copies of the Mythical Man Month to dissuade business folks from trying to accelerate road maps and product strategies by provisioning fleets of AI coding agents."
Submitted yesterday, but no luck :D
srvaroa commented on AI generated code will choke delivery pipelines varoa.net/2025/04/07/ai-g... · Posted by u/srvaroa
Starting from the premise that an LLM can take a few bullet points and turn them into a 3000 word email,
what is the expected result of giving it a few lines of code to complete?
Has any programmer ever thought, "my problem is that can't type fast enough"?
I guess yes? https://danluu.com/productivity-velocity/
Hi, Renovate author/maintainer here.
The affected repo has now been taken down, so I am writing this partly from memory, but I believe the scenario is:
1. An attacker had write access to the tj-actions/changed-files repo
2. The attacker chose to spoof a Renovate commit, in fact they spoofed the most recent commit in the same repo, which came from Renovate
3. Important: this spoofing of commits wasn't done to "trick" a maintainer into accepting any PR, instead it was just to obfuscate it a little. It was an orphan commit and not on top of main or any other branch
4. As you'd expect, the commit showed up as Unverified, although if we're being realistic, most people don't look at that or enforce signed commits only (the real bot signs its commits)
5. Kind of unrelated, but the "real" Renovate Bot - just like Dependabot presumably - then started proposing PRs to update the action, like it does any other outdated dependency
6. Some people had automerging of such updates enabled, but this is not Renovate's default behavior. Even without automerging, an action like this might be able to achieve its aim only with a PR, if it's run as part of PR builds
7. This incident has reminded that many people mistakenly assume that git tags are immutable, especially if they are in semver format. Although it's rare for such tags to be changed, they are not immutable by design
>7. This incident has reminded that many people mistakenly assume that git tags are immutable, especially if they are in semver format. Although it's rare for such tags to be changed, they are not immutable by design
IME, this will be more "learned" than "reminded". Many many people set up pipelines to build artefacts based on tags (e.g. a common practise being "on tag with some pattern, then build artefact:$tag") and are just surprised if you call out the flaws.
It's one of many practises adopted because everyone does it but without basic awareness of the tradeoffs. Semver is another similar case of inherited practise, where surprisingly many people seem to believe that labelling software with a particular string magically translates into hard guarantees about its behaviour.