jspdown

In that case yes I think that can be of real value.

AI code review is nice to have an additional pair of eyes but it doesn't substitute to the maintainer eyes. A big part of a review is deciding if you want that change merged in. Not because of the immediate code but what it means to the project to bring this in.

AI code review, to my eyes, just reduce the number of bugs, they do not shorten the review time. Otherwise, it means you are compromising on the direction of the project.

I help maintain a big project as well and I can totally relates what the author is describing.

The amount of security advisories and PRs opened is getting out of hands. This is no longer just spell check PRs that you can merge in less than 1 minute of review. Often that's going to be supposed perf improvement, attempts at fixing things that are not broken, or submitting completely new features.

These relatively low effort PRs takes a lot of effort to review or even just to filter out.

How could it take less effort to maintain a fork? You have to merge the upstream in every week and fight endlessly on conflicts with your patches.

I never had so little free time as I have these days. Most of my time is spent at work or with my lovely family.Love my family, and work is great.

The thing is that, probably like many of you, I love going deep in a side project, even if it lands nowhere. With so little time, working on them has become a very frustrating activity.

This is where I found my trap... do more with very little time by delegating to an LLM. You get dopamine shots, the feeling of achieving something but the cognitive dept is just crazy. So much that the activity becomes almost meaning less. After couple of months doing this, I'm not even sure it's a good use of this time. I get very little satisfaction on the long run.

I don't have a solution to this problem, not even sure there one. I think I have to accept that this is an activity that takes time, and only time gives the real gratification.

This is a very good analogy. You have to do way more effort to make sure it's correct than if you have asked it yourself with a controlled context. I generally don't want to feel lucky when I ask questions to coworkers.

I very much like Go's simplicity, but nils are terrible. Pointers carry 3 different intents that are not encoded in the code:

- Optionality

- Mutability

- Memory optimisation

I agree with the author that when the pointer is here for mutability or to limit copies you need to check nullity at the outer layer. But for optionality you need to check it each time you access that value.

Sometimes the intent is not clear and you are forced to check nullity everywhere. An Option type fixes this but it's not idiomatic Go code and forces to wrap every thing you call

Who is going to maintain all these forks? The person forking it has no community and can't realistically be an expert in all of these domains.

So no, it doesn't "work", it just worked at some point in the past.

I find this kind of rewrite both disrespectful and completely useless. Useless because the difficulty isn't getting to a working state but maintaining it. You now have to build a community around it to make any of this worthwhile. What would this software be worth if security issues weren't patched and bugs weren't fixed? You can't do this alone. And I find it disrespectful because people have spent decades building this, and you're taking all that collectively built knowledge to create something that will compete with the project itself.

I hope people will restrain themself from doing this at least in the name of good ethic. I fear this is going to hurt OSS a lot.

I hope people will hold back from this, if only out of respect for the work that came before. I fear it could do real damage to OSS. It would discourage the maintainers whose effort makes any of it possible.

At this stage, AI is no longer a tool that enhances your ability to ship code, it has replaced you entirely in that role. You don't control what is shipped, and you can't verify if it's correct. That's a serious problem! As software engineers, we remain accountable for code we no longer fully understand.

Then, what comes next feels less like a new software practice and more like a new religion, where trust has to replaces understanding, and the code is no longer ours to question.

Don't you need to obtain consent before filming random people in the street? I already feel uncomfortable when someone takes a photo in public and I happen to be in it, but this type of device takes things to an entirely different level. With smart glasses, there's no visible cue that you're being recorded. No phone held up, no camera in sight. I'm questioning the legality of this in Europe, where privacy laws tend to be stricter. In the meantime, should I just assume that anyone wearing these glasses is always filming? And would I be within my rights to ask them to stop the moment I notice them?

I've been using Claude for a little over a year, but the recent events with DoW are making me want to explore European alternatives. I'm willing to give Devstral 2 a try, but I'm not sure what to expect. In terms of tool calling and coding abilities, should I expect something closer to Sonnet 3.5 or to Sonnet 4.5?

Domestic mass surveillance might feel tolerable when you live in the country conducting it. But how would you feel about other countries adopting similar policies, and thereby mass-surveilling the American people? Because that's exactly what these policies authorize when applied to the rest of the world.

On my personal coding agent I've introduced a setup phase inside skills.

I distribute my skills with flake.nix and a lock file. This flake installs the required dependencies and set them up. A frontmatter field defines the name of secrets that need to be passed to the flake.

As it is, it works for me because I trust my skill flakes and skills are static in my system: -I build an agent docker image for the agent in which I inject the skills directory. -Each skill is setup when building the image -Secret are copied before the setup phase and removed right after

All in all, Nix is quite nice for Skills :)