yerik

The fines aren't for 'Prompt Injection' directly, but rather for attempting to undermine the court integrity. It's, for example, the same as attempting to bribe a court official.

But Brasil court doesn't work under precedents. So unless this becomes law, it doesn't change anything for future cases.

I used to leave my computer running 24/7, but then I got another computer to make a server, and it really improved my routine to have a "Shutdown and I'm done with computers for today"

I read the post a few times, but I still have some questions that I feel weren't answered, probably because I lack the deep protocol knowledge. For context I run a 'single-user' Mastodon instance, and I don't really see how that is any different than either the blog or what ATProto offers.

What I'm most confused about is that an 'instance' has just shifted elsewhere. Sure, with AP you have to choose an instance, or just go with the default mastodon.social. AT doesn't seem to have instances but, you have to choose a host, and I suppose there's probably a Bluesky default host. I can't really see how that is any different. You probably could self-host an AT host as much as you can self host an AP instance for yourself (I run mine on a $6/month VPS).

The second point I don't quite get is that these apps don't seem to solve the same issues that instances do, and I believe this is the part where I'm lacking AT Protocol knowledge. If, in running my own host, I need to have software that handles access control, authentication, follows, etc, then I'm running an instance, even if it's called something else. If a host stores only data, then at some other place there is software that handles follows, access control, etc; then that software is equivalent to an instance, even if it's called something else.

When people ask where the AT instances are, I think about it like this: with mastodon (or any other AP app) I control not only my data, but the code that handles it. With ATProto what it seems like to me is that I can control where my data is, but not the code that handles it (considering the main criticism that you can't run bluesky 'instances', even if instances are called something else). That's why I think 'There Are No Instances in atproto' doesn't convice me. There might not be something called instance or it might be broken down in different components, but there is at least something equivalent. If you have a million different hosts but this data is handled by a single component hosted by someone, then you can't really say it's decentralized.

Sure, there are technical differences between both protocols, but from a user perspective without protocol knowledge, it doesn't seem any different from the outside. You download the app and use the default host/instance and if you don't want to be on the default one you have to get technical regardless of which protocol you chose.

One bit of feedback is that the somewhat 'snarky' comments directed at ActivityPub might put off the target audience of the post, that are precisely the people who ask where the instances are. But all in all, I feel the article did a good job of explaining the differences (besides the few points I mentioned earlier) and clarifying that ATProtocol has a clear separation between the data and the presentation of the data. While it's something that AP can do (my instance works with mastodon, with pixelfed, and other 'Apps' and my data is in a machine I control), it's not the default and data tends to be tightly coupled with the big instances.

I like to think in parallel Claude instances the same as software threads. Sometimes adding more threads will make the program faster, but sometimes the overhead of managing them will not be worth it.

I tend to go for parallel agents when the task I have can easily be split into non overlapping chunks, preferably if one chunk doesn't depend on another. Let's say I'm working on a new feature which will require changes to both frontend and backend. I can first define a shared contract between them (how the API endpoint will look, what inputs it will receive, what it will output) and then spin up one agent to work on each separate part.

Or maybe you're refactoring a part of the system that has hard coupling with other components (think maybe a notification system). You could spin multiple agents for each to handle a different coupling point.

In general I think that the same good software engineering practices that help with teams can help with parallel agents. It's important to remember though, with each agent you have more code to review (using shared interfaces could help your review process) and if you don't do a good enough division you'll get a fair share of merge conflicts to fix later. Also it's important to have each agent on it's own git work tree to avoid concurrent edits to the same file

One last workflow I have for parallel agents is getting up to speed on a codebase. I can divide the codebase into discrete groups and ask each agent to read it and report the findings. This one is an easier workflow since it doesn't really matter if the agents overlap on a few files since they aren't editing it.

For me it's been mostly trial and error trying to get to a good balance between multiple agents and the overhead it brings

I've noticed first hand how the scope of responsibilities is broadened by integrating AI on workflows. Personally if feels like a positive feedback loop: I take more responsibilities; since they are outside my scope I have a harder time reviewing AI output; this increases fatigue and makes me more prone to just accepting more AI output; with the increase in reliance on AI output I get to a point where I'm managing things that are way outside my scope and I can't do it unless I rely on AI entirely. In my opinion this also increases Imposter Syndrome effects.

But I doubt companies and management will think for a second that this voluntary increase in "productivity" is any bad, and it will probably be encouraged