General knowledge is unpredictable. If you want to treat human diseases, explore the natural world, because a huge portion of the pharmacopea we have is in some way directly derived from general knowledge - the taxane family is derived from yew, sometimes when you explore easter island you find rapamycin, penicillin is a very old story of accidental primary research, it goes on and on. And many of the synthetics we have now are adaptations of an older drug with negative side effects to manage the side effects.
My trial of the all potato diet was directly responsible for identifying a significant health issue and improving my life. It also really, really did not feel good at all, and I did not lose any weight. Call it a case study N=1
And, as with many things, as soon as you stop forcing yourself past the point of ease and fluency, you somehow both enjoy it more and also are more effective.
I agree that AI isn't human, but why does that necessarily mean it's a problem? The analogy I use is watching an octopus juggle - just because it's better than a human can ever be, definitionally, doesn't mean it's a problem or replacing people.
I think the impulse to use AI to replace human effort in cases where it's not drudgery, like art, math, etc is the issue, more than the fact that AI isn't human. Let AI do AI things, and humans do human things. I honestly hope that when everything shakes out we have a lot more room in the world for people doing things that are uniquely human, or amazing new collaborations that let humans do things they've never been able to do before.
I think there's a chain of trust. The sensor signs raws, and the private cloud takes signed raws, does minimal processing so they're at least coherent, and re signs that output (maybe even including the original signed raw as well in the image file).
How would the server know that the request is coming from a real iPhone?
This is a pretty standard application of trusted computing and can be done entirely on the iPhone. A server would only possibly be needed for anonymization (while retaining key revocation capabilities if a key does end up leaking), but there are serverless ways to do even that (TPMs have supported these for a while now).
It wouldn't, but you could validate that a particular picture was created at a particular time, and had not changed, for example, especially with metadata that you may not want to share but that establishes certain parameters like gps coordinates. A lock, rather than an end-to-end pixel signature, which shows what was contemporaneous rather than exact provenance. If an event happened on day 0000-00-00 00:00:00am, but your photo was taken at some other time, it casts doubt.
I think a big part of validation for things like these are just "could it have been modified since Z event happened", because Z was not something people paid attention to before.
That's a good point, You might still be able to trick the cloud to sign your photos, but that's something they could patch in updates without losing control of the key. They could have the server only sign photos taken on the latest ios version.
And honestly you could have a similar antitampering oracle that was at least obscured, in terms of "we've detected tampering but won't tell you how or why", which is frustrating but I have to imagine that 99.9%+ of images are clean.
Good list. And if you support both portrait and landscape, you need to support twice that, and you need to be able to switch on the fly.
But for the apps that don't currently support both orientations, it's possible they don't have support for switching aspect ratio on the fly. This design might help with those apps not completely breaking when folding/unfolding.
Yeah to be fair I'm all for the 1/sqrt(2) aspect ratio, I just think it's funny that it's treated as some kind of holy design constraint when they're all over the map on phone sizing :)
And the extra irony is I'm currently shipping an app that doesn't deal well with different size phones (just pads the edges), heh, so do as I say, not as I do.
The other thing that I think a lot of people run into is that they launch it into a completely human-built system with hundreds of thousands of lines of code and expect run #1 to be perfect.
You have to change the system so that the AI understands it, via establishing what your beliefs are, how those are reflected in values (especially important if you have e.g. compliance needs), how those values are reflected in the operational and strategic levels, and then a variety of tactical behavior coaching. For example, I ban 2>/dev/null - super tactical, and I say I value simplicity over covering every edge case - a very broad generalization.
I think this really was a relevant issue around a year ago, give or take, maybe a year and a half now.
But with current models you actively have to sabotage the context to get this kind of behavior, or dramatically underspecify (3 words versus 2-3 sentences)
That was my experience with Claude when my vibe-coded project was small.
But now that I've been working on it a month and there's a lot of documentation, it's pretty clearly ignoring parts of the documentation and parts of the code. It will come up with some ridiculous statement about how something works, and I'll challenge it, and it'll admit I'm right.
It definitely reads more documentation than any programmer I've ever worked with (myself included) but because it doesn't have a memory other than the documentation, it still makes mistakes like that.
I haven't turned on "memory" or tried it with Codex, so I don't know how that'll change soon, though.
Yeah the biggest task these days that I do manually is curating the documentation. AGENTS.md in every major directory, and a variety of reference docs that are explicitly referenced in those files.
# See DOC-ITEM-NAME
DOC-ITEM-NAME.md
When referencing documents, always use the exact syntax See <TAG> - this is enforced by a lint on precommit
And those doc items are basically all of the values, architectural, strategic, and tactical items. It's a poor man's in-repo RAG but it's shockingly effective, especially if you keep them small. I may migrate some/all of them to skills over time, but I usually update them biweekly, and I only allow agents to make small edits or propose new notes. And typically I go through and delete or curate any agent edits before merge.
Depending on language I've seen this scale past multiple millions of lines of code, as long as you pair it with all of the linting and tooling that you can possibly build.
reply