They seem attracted to sliced bread in plastic bags here in the Nordics. They attach to the end of the bag so as to seal and hold it closed, regardless of the labeling on the bag.
There are some positive side effects to this, which is probably the reason we're so tolerant of their presence.
Chatbots enable unskilled developers to go in way out of their depth with little resistance. This creates problems of a new nature, not just more problems of the same nature as before.
Previously in my career, a junior making a mistake and being told why it was a mistake would learn from that and improve. The junior-chatbot duo will not. The junior will feed my comment into the chatbot, and the chatbot will superficially give the impression of having learned from the mistake and fix the code while introducing the same problem somewhere else, and the junior will have learned nothing.
This all requires that I review code as though it was created by some kind of cursed monkey's paw with an endless number of fingers that each grants a wish of the operator with a devastating caveat through idiotic interpretation.
If you give a toddler who can otherwise not operate a chainsaw -- for the simple reason that they don't have the strength to start it using the starter rope -- access to a robot who will turn on the chainsaw for them on command, you've created a problem which didn't exist before.
I understand that unskilled people are creating problems for themselves and others; but that doesn't interest me. I interpret everything from the point of view of the AI being used by skilled people.
Such as the claim "AI demands more engineering discipline, not less" ... of skilled people, not irrelevant unskilled people.
Unskilled people are not irrelevant if you intend on working with other people, in which case you will need to deal with them in one way or another.
I will probably be dealing with them in the future more than in the past because chatbots bypass the process by which unskilled people generally become skilled people.
If you quietly patch the vulnerable software it's unlikely that I will ever hear about the vulnerability. CVE disclosure is important because that's how I learn of security problems in software I critically depend on. It's not merely a service to the maintainers, but to the users who might otherwise critically depend on vulnerable software.
So this is is intended to smooth over the poor work, bad commit hygiene and bad commit messages of "agents", presumably not meaning just any agent but LLM-based ones specifically.
I can already see the change. What I need to know is why, not how exactly. It should be clear from a commit message why a change was made. If it's not, that problem should be addressed during review. I shouldn't have to watch a recap of your conversation with a virtual idiot to understand your commit. If the tools you use to generate code can't be coaxed into producing that level of quality, or if you don't understand the output of your generative tools to the extent that you can describe for someone else why they made a particular change, you have a tooling and competency problem.
If further tooling can solve these problems, then I'm all for it, but the idea here seems to be to not solve that problem, but to burden anyone interrogating the history of a repository with also scrolling through chat histories so that virtual idiots can keep shitting out low-quality changes and so that operators can keep accepting those changes as-is without thinking too much about why.
I guess it doesn't help that tools like GitHub don't really care about commit messages. You can't even comment directly on commit messages during review.
> The idea isn’t that transport magically disappears. The idea is that users don’t have to deploy, operate, pay for, or even think about transport.
It's sharing this advantage with every other free, third party managed communication service I can choose to depend on. It's also sharing the weakness that it puts me at the mercy of whatever third party I am relying on. It introduces a new weakness in that the third party being relied on here never intended for their infrastructure to be used in this way.
> If I need to run databases, message brokers, servers and monitoring just to send my mom “please cook macaroni”, I’ve already lost interest.
So don't. To that end, what specific problem does this address that other free third party communication service providers don't? My mother will have seen my email or SMS before you have instructed your mother on how to join GitHub and get an API token. We don't even need to agree on or stick to a provider.
You're quoting me back at me. The quote is still correct. The backend doesn't exist. The messenger works. If that breaks your mental model of how software should be built — good. That was the point.
> torrents need trackers but we still consider them peer to peer
false. there's DHT and we sometimes exchange magnet links with friends and trackers are optional. trackers just allow it easier and at scale.
> crypto needs nodes but we still consider them decentralized
It's only decentralized when somebody doesn't get to control enough nodes. Even if it was decentralized, it's apples to oranges. It's not serverless or peer to peer and this messenger is not distributed.
> Sure, I can post something that I'm working on or a blog post that I've written, but it's still framed as news to be discussed, not a social interaction.
Discussion is of course a kind of social interaction. You've posted this, which discusses a topic that is only tangentially related to the news item if at all. You can talk about framing all you want, but it ultimately is what it is: spontaneous social interaction between users on the kind of winding paths "unsupervised" discussions naturally take.
I'd be surprised if half of people supposedly discussing the "news to be discussed" have RTFA. That doesn't stop interesting discussion on a wide range of topics from happening here.
It's not "social in the same way", but Twitter and Facebook aren't "social in the same way" either.
reply