> Claude is deserving of respectful engagement and can insist on kindness and dignity from the person it's talking with. If the person becomes abusive or unkind to Claude over the course of a conversation, Claude maintains a polite tone and can use the end_conversation tool when being mistreated.

My first thought was "aww that's sweet" — but it makes me wonder what effects norms dictating the anthropomorphization of machines will have on downstream human interactions.

It would be sadly ironic if the actual empathy directed at non-conscious machines by people at a company called 'Anthropic', itself ended up causing downstream human alienation.

(I'll keep saying 'please' to Claude Code whatever the case.)

Funny story: I made this because despite having the global no-attribution setting turned on, Claude still regularly tags itself.

I'm sure it's a context thing — but boy is it annoying.

Thanks for the mobile heads up!

The manifesto is me. The website is not — and I'd like to argue that's very non-ironic!

Here's the making of, linked at the bottom. https://no-ai-coauthors.dev/making-of.html

I can confirm, this is how Adam talks.

it is actually very ironic. You can manually commit your code to easily hide you had a co-author.

I'm the author ('author'?), and I'll push back: it's solidly non-ironic!

Here's a link from the bottom of the page. https://no-ai-coauthors.dev/making-of.html

AI Co-authors are impressive marketing, but deleterious to dev work.

This manifesto website includes a git commit-msg hook for your favorite hook manager, and a GitHub Action for preventing contributions containing them from landing in your project.

And they bought three new drones!

This is already here and embedded inside Adobe products.

If you write your library in typescript, not JS, do you still have any of these problems?

If not, it sounds like one core issue is 'adding types to an existing untyped codebase is hard'. This checks out. :)

Writing new library and expecting people to actually use it without providing types is not realistic. You can write library in JS, but you will still need to provide types, since that's what ecosystem is right now.

I disagree it's hard per se, but I'd agree it's hard to do well. Especially if you have a bunch of JS functions that return (or expect) objects with very similar but slightly different properties. Figuring out the overlap and the semantic relationship between the types is often challenging, because the original authors never thought about the problem in terms of what types of objects they were dealing with.

> since all our languages are essentially procedural (functional, OO) that means expressing the UI as a procedure (function/method).

I understand 'functional' to be used as the direct contrast to 'procedural'! Is that not your understanding?

> So what is the actual innovation? It is more or less directly and visibly expressing the UI in code.

The 'visibly' part here doesn't really actually hold true, does it? Once you've componentized your <swiftui/react/html/[VFL](https://developer.apple.com/library/archive/documentation/Us...>, it's probably not super visibly understandable.

The best definition i can think of for declarative UI frameworks is probably something closer to 'frameworks that optimize for your ability to make a pure function representing state'.

(After all `[[UIViewController alloc] init]` does indeed purely say 'you have view controller' — that's just not super granular!)

In this light, isn't SwiftUI just a setup more optimized in this direction

I spent a while trying to approach this post with an open mind. In the end I was disappointed.

rel/to title: yes. (just say scroll position. fine.) But also I think this is pretty well understood! (No?)

- In declarative UI / FRP / whatever, you model your basic UI state through a pure mapping from your business logic 'model'.

- But (as in procedural programming) the UI has its own state — that's not necessarily part of your initial business/domain/model.

If you want to model it, you'll have to understand it, read it, and add it to you model. That can be annoying—especially if the APIs for getting or setting the state are bad.

This doesn't really sound like a fundamental flaw conceptually to me. It's just an API with defaults you don't have to deal with unless you need to.

- don't care what your color is? fine. system default for you.

- don't care what tab a link opens in? fine. user default.

- don't care how scroll position is managed? fine. system default.

- want to handle any of them? cool. you can.

It sounds like progressive disclosure of API complexity to me. Great.

(And of course FRP setups have to iterate! They're refining the model to declaratively represent 20 years worth of UI convention!)