bze12

I like the distinction between imperative and declarative styles, but I still use imperative chat sessions to work through what the declarative plan should look like. I feel like this approach loses that.

AI has sitzfleisch

https://en.wikipedia.org/wiki/J._Robert_Oppenheimer#:~:text=...

If any fly people read this, could you please add the ability to create custom_api connectors to the api? Sprites are so close to being great for arbitrary secrets proxying. Right now you have to provision everything manually

I’ve been working on a project for this - https://mymachines.dev

It provisions a sprite and spins up Claude code/Codex on it for each session you create. Finishing up an iOS client for it too

This is interesting. I’ve been building a project on top of sprites for the past few months, but I’ve often thought about moving off because it didn’t feel like fly was devoting enough attention to it. The changelog is sparse and their developer discord is kinda dead. So it’s good to hear they’ll be prioritizing it going forward

By the harness I believe he means the entire end-user product experience, not specifically the harness code. I’ve mostly stuck with codex because their Mac app is better and I’ve gotten used to running automations through it. The more workflows they can build around this (design tools, collaboration, etc), the better chance of lock-in.

He talks about this in another recent essay https://stratechery.com/2026/anthropics-safety-superpower/

> If you own the user touchpoint, then you have meaningful lock-in, and the best way to own the user touchpoint is to be the canvas for everything they need to do. This, by extension, means that the frontier labs are on a collision course with software companies: it’s software that owns the user touchpoint, and it’s in the frontier labs’ long-term interest to not simply be a commodity input into software but to simply replace software outright.

The book Boom argues something similar

https://press.stripe.com/boom

I mostly lament the simplification of app icons as an artistic loss, not as a usability loss. Shameless plug, but I made a project based on the idea of icons as pure art with no utility https://www.benedelste.in/post/__001

They've gone too far on enforcing uniformity of icons and abusing liquid glass, but I disagree that arbitrary shapes were better. All the random icon shapes looked cool in isolation, but were harder to scan at a glance. The uniform squircle is a useful constraint.

I wouldn't mind if they allowed something similar to that audio hijack icon, where you require the rounded rect as the guiding frame but are allowed to have some elements protruding out of it. But completely arbitrary shapes are too jarring imo.

“Build vs buy” assumes that there are only two parties. If it’s easier to build internally, then it’s easier for a 3rd party competitor to enter the market and bid the price down. I think the "zone of viability" is real, it just narrows and shifts downward.

The author hints at this in a footnote: > It does, however, pencil out to use a different product instead. In this particular case, it’s easy: use Linear instead of Jira.

I agree. I followed this article for a repo I'm working on, and I had a very hard time inferring how, specifically, they implemented "providers" and enforced import layers. A sample repo would've been nice.

Isn’t this very similar to cloudflare durable objects & workflows?

Comparing fixed costs to revenue? Even if it’s cumulative this seems like a disingenuous framing

It mostly feels like they’re just converging on each other. The latest Claude Mac app release pushed a new UI that looks almost exactly like Codex’s.

> This part is especially fascinating to me, since it turns an optimization done out of technical necessity into a gameplay feature.

Reminds me of blood moons in Zelda https://www.polygon.com/legend-zelda-tears-kingdom/23834440/...

It doesn’t even go upside down once, let alone 4 times

Apple mostly cares about legibility and consistency in icons now, not art. All the new iOS features like tints and liquid glass don't lend themselves well to intricate designs. It's disappointing, but I tend to agree that the skeuomorphic icons are harder to read.

From their icon guidelines: "Embrace simplicity in your icon design. Simple icons tend to be easiest for people to understand and recognize. An icon with fine visual features might look busy when rendered with system-provided shadows and highlights..." https://developer.apple.com/design/human-interface-guideline...

Self plug, but I made an app related to this - it's a conceptual art gallery for app icons. I thought it would be an interesting experiment to remove the functional premise and just let an icon be a decorative symbol. It's called 001 (https://001.graphics)

I don’t feel great about this ruling. Whatever a “reasonable” fee is supposed to mean, Apple will interpret it to some ridiculous amount. Before the ban, they tried to charge 27%

Yes exactly. Not nfts, just collectibles within the app.

I’m working on a concept art gallery for app icons: https://001.graphics

I think app icons are an underrated artistic format, but they’ve only been used for product logos. I made 001 to explore the idea of turning them into an open-ended creative canvas. There are 99 “exhibit spaces” in the gallery, and artists can claim an exhibit to install art within. Visitors purchase limited-edition copies of pieces to display as the app’s icon, the art’s native format.

It’s a real-money marketplace too - the app makes money by taking commission of sales (Not crypto). I like economic simulation games and I think the constraints here could be interesting.

I’m currently looking for artists to exhibit in the gallery, if anyone is interested, or knows someone who may be, please let me know!

This post was definitely written by an llm.

Nonprofits are major targets of card testing fraud, I wonder if that is related

They’re folding the nft department into contemporary art. But I wouldn’t say the first interpretation is invalid either.

Oh I see, the original article didn’t use this syntax.

iOS default animation speed is 350 ms, at least for SwiftUI. This has always felt a bit too slow. And recent system animation changes felt gratuitous to me (opening the action bar on iMessage for example).

OTOH this article is basically downstream of Apple’s interface design philosophy.

Why do we still have to write `catch let error as SystemError`? Why can't the error be inferred to have the type thrown by the function? I've always found swift's error handling syntax to be awkward

This video gives a good overview https://www.youtube.com/watch?v=5xEi8qg266g

Nice! I was already considering using reducto api. Will give this a try

Their entire setup was egregious.

They charge 27% for purchases made using external payment processors. Including Stripe fees that's net-zero (not even accounting for any chargeback risks). They severely limit how you can display the external purchase link too, and display an obnoxious warning screen when you tap it.

I would be surprised if a single developer adopted it.

https://developer.apple.com/support/storekit-external-entitl...

Do you use firebase?