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 :)

I pay a Max subscription since a long time, I like their model but I hate their tools:

- Claude Desktop looks like a demo app. It's slow to use and so far behind the Codex app that it's embarassing.

- Claude Code is buggy has hell and I think I've never used a CLI tool that consume so much memory and CPU. Let's not talk about the feature parity with other agents.

- Claude Agent SDK is poorly documented, half finished, and is just thin wrapper around a CLI tool…

Oh and none of this is open source, so I can do nothing about it.

My only option to stay with their model is to build my own tool. And now I discover that using my subscription with the Agent SDK is against the term of use?

I'm not going to pay 500 USD of API credits every months, no way. I have to move to a different provider.

It's not HTML purism. It's simply recognizing that HTML and CSS have evolved a lot and many things don't need (or are close to not need) JS anymore. This shouldn't be taken as an anti-JS article, everyone benefits from these gradial improvements. Especially our users who can now get a uniform experience.

My bad, in the context of the article you are definitely right.

I think I was biased by the fact that this argument was used in an HN comment where people tend to be heavy users of LLM based agents.

This article compares a single ChatGPT query against 1h of video streaming. Not apple to apple comparison if you ask me.

Using Claude Code during an hour would be more realistic if they really wanted to compare with video streaming. The reality is far less appealing.

You can type Option+Enter. A more standard Shift+Enter would have been better but until then that's the best we have

I suppose yes. That's actually what happened with distributed rate-limit.

Looks like it's OpenAI response to Google's Agent Payment Protocol (AP2) but without the micro transaction part.

Do you mind telling us a bit more? I never used OpenCode, what makes it better in your opinion?

There's a bit of UI around it where you can accept the plan. I personally stopped using it and instead moved to a workflow where I simply ask it to write the plan in a file. It's much easier to edit and improve this way.

I'm wondering if it's not just: spawn multiple time the same prompt and take the best

Thanks for the detailed feedback. This is exactly the kind of input we need.

We're going to work through these points with the team. Appreciate you sticking with Traefik despite the documentation friction.

Traefik maintainer here.

A significant portion of TraefikLabs' engineering team and maintainers are French. Before each new release, the team holds polls and spirited debates to determine which cheese would be the perfect fit for the version name.

Staying true to French culinary tradition, the enterprise versions are given wine codenames, with each wine carefully selected to pair perfectly with its corresponding cheese release.

Traefik maintainer here.

You are right, Traefik is fundamentally built around the concept of "providers," which are external systems from which Traefik obtains routing configuration and service/server definitions.

These providers can range from dynamic service discovery systems (like Docker, Kubernetes, Consul) to static configuration sources (file-based configs, HTTP APIs, etc.). The provider architecture is what makes Traefik particularly well-suited for containerized and cloud-native environments where services are ephemeral and discovery is crucial.

Traefik maintainer here.

Traefik is a reverse proxy and load balancer that automatically discovers services and configures routing rules dynamically through integration with various configuration sources such as container orchestrators (Docker, K8s, Nomad, Consul, ECS, ...)

As of today, Traefik is not a web server.

Traefik maintainer here.

I can confirm that bring-your-own certificates, ACME, and mTLS are all included in the OSS version. For enterprise users, Traefik Hub also provides seamless integration with HashiCorp Vault.

Regarding the cache middleware: like many of our more advanced middlewares, you have two options. You can use a community-maintained plugin (such as Souin), or your organization can purchase an enterprise license to access TraefikLabs' officially maintained built-in middleware as part of Traefik Hub API Gateway or Traefik Hub API Management.

Traefik maintainer here.

Documentation quality has been a common complaint. Previously, we only provided reference documentation and relied on the community to create tutorials and guides.

Based on feedback like yours, we've completed documentation rewrite. Have you had a chance to review the new version? Your feedback is taken very seriously, so we'd greatly value your thoughts on these improvements.