falcor84

Willison chose this task because (unlike actual images of pelicans) is was clearly not in training data, but could be reasoned about and composed from what's there. But just like those "how many golf balls can you fit in a 747?" interview questions, it should now be retired.

Thanks for clarifying, I suppose I mostly agree, and also hope that misbehaving companies will be punished.

With that said, I'm very concerned that the coming decade will be a bumpy ride for all of us.

> I've always viewed Obsidian as the inverse of an open core product.

I'd like to hereby propose the "open shell" development model.

I suppose that's not what you meant, but I love the idea of "Lars Von Trier" as a persona being good cinema.

At the very least, it made me understand that I need him to appear as himself in the next Death Stranding game.

I don't get it. How is knowing that AI itself will not take responsibility or that it will not indemnify its users make your decade any better? Is your line of reasoning that using AI will very likely prove to be a bad idea in the long term and thus perfectly rational people with the same priors as yours will abstain from training or utilizing AI?

Where is the "cannot" coming from?

The only underlying rule that I see is: the more complex a task is, the lower the probability of success. That's it. And it's the same exact rule that applies to humans. The difference though is that we're seeing an exponential growth in AI capabilities, which are then rapidly disseminated on a scale of months, and we don't see such capability increases in humans.

As I see it, anyone whose mental model is built on what AI can or cannot do is going to have a very bumpy decade.

Agreed. Very firmly in level 2, and going well into level 3 too.

For example, I've had quite a few situations when I asked Claude Code to do some manual work for me, assuming it would do manual edits across several files, but it instead decided to write a script, and even a small test suite for it. It's a small encroachment so far, but I don't see any limitation for it gradually taking on actual product decisions.

Wait, why? This is exactly what I as a human would have said in this situation.

Or if you're referring to how the OP still decided to go ahead, I've seen AIs go ahead on impractical courses of action many times, and surprisingly succeed on some of them.

No, not yet astronomically richer. I'm working on it, but a part of the reason why I haven't yet broken all my bones from repeatedly diving into a pool of money is The Red Queen's Race. With how much easier it is to write code and realize your vision, coupled with how jaded we've all become, the bar is just much higher. But I'm pretty certain that if I had this sort of capability even just 3 years ago, and others didn't, I would have been like a Kryptonian under a yellow sun.

I don't know what frustrations you have, but the impact of Claude (and particularly Claude Code) on my productivity over the last year has been astronomical. If there wasn't this fierce competition, and I had to pay 10 times as much, I still gladly would.

Yeah, no, I absolutely agree with you that TFA is not an examplar of good writing. But would just argue that the problem has little to do with these snowclone patterns or the rule of 3, and a lot more with the actual substance not fitting the form, and arguably not being substantive at all.

I'm all for rejecting bad writing and bad reasoning, but just wouldn't us as a community to get into the habit of rejecting otherwise good writing just because it's AI-ish.

But LLMs were literally evolved via RLHF to write in a way that humans find agreeable. Can't we just move past this aversion and accept "writing like an LLM" as generally good writing style advice?

There's the classic article by Matt Ringel and Tom Limoncelli back from 1999:

https://www.usenix.org/legacy/event/lisa99/full_papers/ringe...

Why is it a red flag?

How is it different from any other purely stylistic rules such as Strunk and White's prohibitions against split infinitives and the passive voice, which we've left far behind us? Why shouldn't people just write however feels natural to them as long as the message is clear?

Ah, thanks for clarifying. But still, my understanding is that military personal are generally aware of their nationalistic-mortality (for lack of a better term) when they are in active duty, but expect to relinquish that mortality risk after they leave the military.

Has that changed in any way? Maybe I'm naive, but it seems to me that there was always a massive distinction between a service member who is currently serving, regardless of whether it's a combat or hq role, and a veteran.

I'm not sure what you mean. From what I see and conversations I've had with service members, joining the military still absolutely entails awareness (if not quite preparedness) that the person may die for their nation. Are you arguing that people in Hezbollah or the IDF are not aware of this reality?

In all seriousness, why should anyone care?

I always found software IP to be absurd, but this is a particularly absurd situation. We're talking here about a small utility tool implemented from scratch and open sourced, with no apparent intent to make any money from it.

Are you concerned about the "encumberence" of using "unlicensed" tools to manipulate .doc, or .pdf, or .mp3 files?! Well I'm not, and if anyone ever tried to sue me for improper access to their proprietary formats, I'll show them some old testament impropriety.

When, and what?

Sorry for taking this on such a weird tangent, but I've been reading the Culture stories and my immediate thinking was - why not? Missiles fly for a relatively long time compared to human decision making, let alone compared to optimized AI agents. There's notechnical barrier to having the missile be controlled by a conversational AI to which the intended recipient could appeal, negotiating with it to change its course.

I'm obviously not arguing that this is a good idea, but I wouldn't be that surprised if this is the future trajectory (sorry for the pun) of "smart weapons".

Sorry to say that I don't understand where "important" came from. You gave examples on how LLMs can make learning to code more productive, but there's essentially nothing there about importance. The closest seems to be this:

> There is a perception that you can just prompt an LLM and ship an app. Yes, you can produce something. But what you have is an artifact, not software. The moment you need to tweak it, if you don't understand programming, you are stuck.

But it's unsubstantiated (I personally have seen coworkers with no proper coding skills iterate quite effectively), and even if there is a real limitation at the moment, you would need to do a lot more work to show that the issue is fundamental and won't be fully addressed by Claude 5 with the "I deal with the goddamn customers so the engineers don't have to" skill.

At best, even if we were to accept that LLM-based AIs will never do good software engineering, then at most you get to "LLMs make learning to code as important" ; I don't see how you can get to "more important".

For what it's worth, I personally think you might be right in your claim, but you need to engage with the actual issue in order to argue against it.

Attestation is a service, like every other service. Why should it necessarily be free? Especially now that we all know that "free" on the web means ads & tracking?

I think we should just accept that some things should cost a bit of money and move the discussion to "how much should it cost", rather than trying to sweep economics under the rug.

As I see it, living requires money. If we have people on this planet that are too poor to digitally prove that they're alive, then we need to figure out a way to distribute the Earth's wealth more equally in general, rather than to require hardware attestation, which seems to be worse on essentially every metric, including inequality.

I'm as biased against cryptocurrency as everyone, but couldn't we have the requestor do a bit of mining work to mint that initial id? I mean, if the service is actually making a bit of money from each request, the need for rate limiting just vanishes, right?

> The cost will exponentially increase over time and the systen will eventually collapse.

From what I'm seeing in the numbers, the big problem of the coming century is population collapse. Maybe I'm just too much of a believer in the intermediate value theorem, but I'm sure there has to be a way to arrive at a society with a sustainable usage of resources.

> Having a job that they dislike is far better than losing one because of AI whatever that means.

Is it really worse even if "whatever it means" is living in a post-scarcity society where everyone can shareel in the fruits of the AI's labor?

I'm not saying that's where this are necessarily going. But I am saying that that's what we should be aiming for, rather than trying to preserve the status quo.

I know it's a very controversial stance, but I'm of the full opinion that in a world where a codebase can be entirely automatically regenerated from a test suite, code style and "maintainability" become concepts with negative utility in anything beyond an artisinal project. And I think that what we'll need to define and stand behind is going to be just the test suite and other "boundary conditions".

> Do not buy anything new, especially graphics cards. Buy on Ebay but avoid bidding wars.

And what then? If you did manage to convince everyone to stop buying consumer graphics cards, wouldn't Nvidia just reasonably dedicate 100% of its resources to AI?

It seems pretty clear to me that "coding" as such is pretty much solved. It's just that software engineering isn't, and these advancements have put a spotlight on the difference between the two.

I think that's actually a decent use case for Chrome's new local model - you'd have your own system prompt to render their "bullet points" in whatever style you like.

I'm not sure, but my understanding is that GitHub historically focused more on open source, with PRs being mainly across repos of unrelated users, such that there's more of a distance to "pull" across, while Gitlab was always mainly targeting companies, where people typically use branches in the same repo, so it's just a nearby merge.

In other words, I see a pull request in an open source project to be just "I have something nice in my fork, do you think it'll be useful upstream?", which is acceptable to reject, whereas in a team setting it's "I have a feature that I think is ready to merge - give it a look and see if I missed something before we put it in".