jaggederest

My tongue in cheek immediate assumption was "so it's a guerrilla PR firm?"

Do you have any analytic basis to make that assertion? I haven't found that to be true, it'd be more accurate in my experience to say that LLM code has different issues than the code humans write.

I think of it as a tradeoff between creativity and specificity. Every instruction you give reduces creativity, and at best, increases specificity (I imagine a lot of prompts like "make no mistakes" do literally nothing but pollute context, but I haven't evaled them)

So if you're doing something very ordinary, fewer instructions result in better results. If you're doing something fairly off-piste, you have to give instructions to that effect and accept less creativity. For situations where you want it to do something extremely specific, tons of instructions and accept that you're going to get much closer output but much worse "intelligence"

Another way to think about it is Type 1 and Type 2 errors or sensitivity and specificity from statistical testing - do you want an agent that solves any problem but goes off the rails 10% of the time, or do you want an agent that can only solve 10% of the problems but nails them 100% of the time (sensitivity and specificity, respectively)

I've gone back over most of my contributions to open source using LLMs and honestly, even though it was my best work at the time, there are big gaps that they find right away.

The myth that we've been shipping perfect code for years, but you can't trust LLMs, is just subjective blindness. People can't see the issues that they can't see, definitionally.

You can absolutely use the exact techniques we used to use in "the old days" to produce reliable code with LLMs generating most of it. The issue is, it's really not a lot less conceptual and intellectual effort than in "the old days", at root. You speed up the programming part, but the rest is still a hard slog, so nobody is out here doing really thorough testing in ways we used to dream of.

I feel like I may have communicated poorly. I mean that, ultimately, any recursively self improving intelligence would be limited by the power cord, and as such, the idea that it would permanently escape human control seems somewhat silly.

Need a sheriff agent, who surely won't be bribed by the criminal agents and descend into corruption...

Money can be exchanged for goods and services. I think the real constraint is actually physics, nominally energy, which is what a big chunk of the operational cost comes down to. I'm already basically assuming the next 20 years of fab time is set aside to feed the beast, so the capital cost is "give me all the processing and memory you have"

Even better, use some kind of local-ci runner that does deterministic builds from a dependency graph. No changes, no build, massive parallelism if you want it

hoist by our own strategic export controls, rip

> Nothing prevents anyone from opportunistically pre-generating and timestamping millions of permutations of fake kompromat and then selectively revealing the one that turns out to be useful after the fact.

If you're doing server-side timestamping and someone is sending millions of items, I think you just ban them. Apple accounts are free but not inexpensive.

Cutting the ziptie is half the fun! Just be glad it's not shrink wrapped or clamshelled ;)

Proper flaking: https://www.youtube.com/watch?v=TbxMyytWw60

Ziptie once coiled, attach label for what format / length.

Bag cables with the same connectors. If you have more than fit in a gallon ziploc you should probably reduce them.

Bonus if you hang them on a pegboard so you can see them with big clear labels on each bag.

Edit: and shrinkwrapped labels on each end (e.g. 12345-USBC-2m) for double bonus points so that you never have to trace a cable to find the other end.

Kintsugi is another reference. I think the Japanese cultural appreciation of made things with genuine flaws, wabi-sabi, is another good one.

At this point I believe that, ironically, writing (and other arts broadly) may be one of the last fields in which humans are truly permanently superior, because writing is ultimately an expression of humanity, and we built systems that are now exceeding that bar in a way that makes it hard for them to communicate back to "regular people". Feels flat, uncanny valley.

Nothing fancy, just metabolic syndrome, I'm afraid.

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.

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.

Prior discussion: https://news.ycombinator.com/item?id=32110792

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.

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.

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.

Given the whole private cloud bit, I am assuming they keep the private keys server side and never let them out.

in this thread many people have clearly never developed for iOS

Here's just the screen sizes, not even taking into account actual resolution:

    iPhone (2007)     3.5" 74.0 × 49.3    36 cm²
    iPhone 5          4.0" 88.6 × 49.8    44 cm²
    iPhone 12 mini    5.4" 124.5 × 57.5   72 cm²
    iPhone Duo, cover 5.4" 113.4 × 77.2   88 cm²
    iPhone 6 Plus     5.5" 121.8 × 68.5   83 cm²
    iPhone X          5.8" 133.7 × 61.8   83 cm²
    iPhone Air        6.5" 150.0 × 69.1  104 cm²
    iPhone 18 Pro Max 6.9" 159.2 × 73.3  117 cm²
    iPhone Duo, inner 7.6" 157.6 × 111.5 176 cm²

Now, you can leave out a few of those as hopelessly obsolete like the OG iphone, 5, 12 mini, arguably the x, but it's still a pretty wide selection.

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.

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)

Clear context, revert the commit, change the prompt or documentation, try again.

At this point it very dramatically is more reliable and predictable than any human I've worked with.

Do you know anyone who actually reads and adheres closely to all of the documentation every time it's changed?

I've been seriously considering getting a tattoo saying "commit to the bit". I find that's both one of my strengths and something I value a lot. It's a kind of anodyne to this problem - do your analysis, make the best choice you can, and then commit fully instead of relitigating, until the next time arises when you need to think carefully again. You'll know when it's time.

So, if I'm building, say an iOS app, I have a) the code itself (swift/react native), b) the internal test suite (unit tests), and c) the e2e test suite with something like XCUITest that drives the physical development phone, plus d) the backend (which has similar tests but is basically a mirror, so I won't elaborate)

So when you're creating a (and hopefully b), you use one model with one context, and then you might use some other model to implement c. I kind of round robin the models and present them with seperate context - so for example I don't build a, b, and c together, I build a plus some b, then later go for a pass over b and c together, then maybe I used c to drive improvements in a, and I vary between openai and anthropic models as I do.

Heres an example set of minimal prompts:

a-focus:

implement feature <x> based on #ticket in github, be sure to reference the engineering standards documents and the swift and react native skills as needed

b-focus:

improve test coverage in the repo for <subsystem z> to ensure that <feature x> is covered completely, and fix any outstanding gaps or omissions in that feature as you go (standard references above)

c-focus (possibly in a separate repo):

You are creating a black box xcuitest to drive a physical phone for testing <feature x>, here is the user specification and known issues, create failing tests for each known issue and an overall robust suite to ensure any user facing or ui issues are caught