There's nothing incoherent with these laws. This entire comment, however, is incoherent. So much so, I have no clue if there's a point being made in here.

> because they are attempt to import assumptions about human nature and behavior which are not just a little false, but so false as to obliterate any remaining value the rules have.

Nope. You must've read a completely different article.

[EDIT] I'll try to make this comment have a bit more substance by posing a question: how would you back up your claim about incoherence? What are the assumptions about human nature that are supposedly false?

Did you fully read the original thing? No demands were being made, or I didn't read it that way. It was simply a suggestion for a better way of interacting with AI, as it stated in the conclusion:

"I am hoping that with these three simple laws, we can encourage our fellow humans to pause and reflect on how they interact with modern AI systems"

Sure, (many/most) humans are gonna do what they're gonna do. They'll happily break laws. They'll break boundaries you set. Do we just scrap all of that?

Worthwhile checking yourself here. It feels like you've set up a straw man.

> There is no finite set of rules that can constrain AI systems to make them "safe". I don't have a proof, but I believe that "AI safety" is inherently impossible, a contradiction of terms. Nothing that can be described as "intelligent" can be made to be safe.

If we want to talk about "disagree with this framing", to me this is the prime example. I'm struggling to read it as anything other than defeatist or pedantic (about the term "safe"). When we talk about something keeping us "safe", we're typically not saying something will be "perfectly safe". I think it's rare to have a safety system that keeps you 100% safe. Seat belts are a safety device that can increase your safety in cars, but they can still fail. Traffic laws are established (largely) to create safety in the movement of people and all the modes of transportation, but accidents still happen.

I'm not an expert on this topic, so I won't make any claims about these three laws and their impact on safety, but largely I would say they're encouraging people to think critically. I'd say that's a good suggestion for interacting with just about anything. And to be clear, "critical thinking" to me means being skeptical (/ actively questioning), while remaining objective and curious.

Not a real argument or anything, but I'm reminded of the episode of The Office where Michael Scott listens to the GPS without thinking and drives into the lake. The second law in the article would have prevented that :)

> It’s easier to understand a statechart than many other forms of code.

There's a lot of arguable quantifiers here, but when I was started at https://gadget.dev (no longer working there), we started with hierarchical statecharts as a way for users to specify their behaviour (with the ability to customize transitions with code snippets). No matter what we did, users just found it incredibly confusing. This was with a customer based that had decent spread across the "how technical are you" spectrum.

Did we do a poor job of introducing it to the user? Maybe. We were forced to switch everything over to flat code though.

> As complexity grows, statecharts scale well.

I think there's a big asterisk on this one, likely. I had to undo a lot of unfortunate statechart code that was introduced for some of the backend of gadget, and I consider myself a pretty good programmer. Perhaps it's just the difference in paradigm, or the accidental complexity of how we worked with xstate, but I reduced 1000+ lines of very hard to read and extend statechart code to a few hundred lines of imperative code, with some hardcoded states. It was actually easier and faster for me to do this than fix bugs that existed somewhere in there (I tried, and failed).

Every engineer at the company (it's a small company :P) agreed that it was substantially easier to read and understand.

I think this perhaps echoes things said elsewhere here, like dflock's comment on the boundary between "xstate" and "not xstate".

All that being said, I'll restate: I love the idea of statecharts, I just have scars from dealing with them. I think they were perhaps applied in situations where the benefit was low, and the overhead of understanding the bits and bobs of xstate was too high of a cost for any perceivable benefit it may have offered.

> It’s worth noting that you’re already coding state machines, except that they’re hidden in the code.

I will say that this is a great point that may often be overlooked.

When I interview candidates, one problem I enjoy doing (and they do too!) is "let's try building vim" problem. We build out a few basic commands — move left, move right, replace character under cursor — to edit a string of text. The candidates that do the best often see how parsing can be encoded in a state machine and plan with that in mind. They perhaps still just encode it as if/else statements with a state variable, but that still gives the better outcome. Something like this:

      0-9
   ---------
   |       |
   |       v        hj
   |-- (number N) -----> move N spaces
           |
           |   r
           ------> (read char c) ---> replace N characters with c

As mentioned, I've experienced it too many times where not addressing a question/concern I put on the pull request led to outages that could have been avoided. I think it's typically a certain personality. It's not a common occurrence, but I have experienced it.

One thing not mentioned is how important it is to acknowledge the comments too. People are taking their time to review your PR, and not even giving a reaction will make the commenter question whether or not it was even received. I'm not looking to throw my thoughts out into the aether. That's what microblogging platforms are for!

I can't tell you how many times I got no response/acknowledgement on a comment that actually surfaced something critical. I haven't been keeping track, but I think my comments could have prevented dozens of outages at this point. It's quite exhausting. In my own experience, the worst offenders of this are senior devs.

> Why approve, if I’ve left comments that I think are worth implementing? > > Because I trust my team. I know that my comments will be considered, and if they’re useful, implemented.

I do this a lot too. It's critical that PR authors don't burn that trust either. If they make substantial changes that warrant another review, I hope they do request it. Too many times in my career have colleagues just went ahead and made bad changes after my approval that I would have easily caught, merge, and things go

High trust, high alignment environments move so fast, and you know when you're in one and know when you have your colleagues' trust. It feels really good!