tlonny

One must wonder about the strength of their “moat” if they feel this sort of thing is necessary.

I think this sort of pattern makes more sense when the fn is update_user and allows the caller to mutate multiple fields at once.

I think you make a good point. Just because something _could_ be vibe-coded doesn't mean it should. You have to factor in maintenance, deployments etc.

However, I'd argue that BI tooling could "dissolve away" altogether. As long as you have queryable data, an intermediate BI tool is unnecessary - just one-shot whatever dashboard you're interested in seeing...

When I last used Railway - the default behaviour for railway-hosted databases was for them to be inaccessible to the public internet - so a leaked DB connection URL might not be as catastrophic as you would first think...

For the people who had OAI/Anthropic API keys stolen and used? Are you able to see how they were used in your dashboard?

I'm really curious how hackers have monetised the compromised API keys? Do they submit them to a shady AI-multiplexer that provides cheaper inference using stolen keys? One would expect completely random/disparate usage patterns/prompts if so...

The “Vibe coders are paedophiles” bit caught me slightly off guard.

Felt like that undermined some of the more cogent points the article was making.

I much prefer cursor paginated API requests vs. webhooks. The obvious downside being that in order to not get 429'd you need a respectable poll frequency - meaning you lose reactivity to new events.

Thus I think webhooks still have a place - but as a simple "poke" that can be sent to the client to tell them something has changed - supplementing a default low frequency polling interval.

This gives us the best of both worlds:

1. No need to bother de-duping/retrying pokes - if you miss a webhook you will shortly recover anyway when you next poll. 2. No need for any local-specific tunnelling/tooling - the local app will work just fine with the default poll interval. 3. No need to keep a connection live for each client. 4. All the good stuff OP mentioned in his blog post.

As I understand it, anything publicly viewable is free to be scraped without issue.

If you scrape stuff behind a sign-up, you potentially open yourself up to being sued for breach of ToS.

Now I'm sure the Chinese labs don't give a rats arse about that threat, but I imagine it stops the likes of Google, OAI, Anthropic from scraping and instead forces them to purchase the data.

I would argue that my proposed flow is far more convenient. I don’t have to sign up, enter payment details and I can interface in plain English.

Not to disparage, but I wrote:

"Using the attached image as a stencil/background - please generate a QR code for https://XXX"

into ChatGPT and got something valid that looks similar in style to your offering.

I think the age of trying to wrap a highly focused AI task in a SaaS has come and gone.

Trying to polish a bunch of my projects I've worked on over the years but never had the cojones to release to the wider world:

Hallways (https://hallways.lonnycorp.com) - a web browser for 3D spaces, where instead of hyperlinks you have portals that you can seamlessly walk through

LonnyMQ (https://lonnymq.lonnycorp.com) - a performant, production-ready TS PostgreSQL message queue library and accompanying blog post that walks through its design (of which I'm quite proud of)

I think _some_ but not _too much_ typechecking is the sweet spot for LLMs.

Without any typechecking, LLMs obviously find it harder to work agentically and validate their work.

With too much typechecking (I'm looking at you, rust), I've found agents get themselves stuck in local "architectural minima" and end up doing insane shit to mitigate ownership/borrow-checker issues inherent in the design they ended up with.

That said, if you're hands-on I think rust is a fantastic language for pairing with an LLM.

Presumably because API keys are n bytes of random data vs. a shitty user-generated password we don’t have to bother using a salt + can use something cheap to compute like SHA256 vs. a multi-round bcrypt-like?

Bugginess in the Claude Code CLI is the reason I switched from Claude Max to Codex Pro.

I experienced:

- rendering glitches

- replaying of old messages

- mixing up message origin (as seen here)

- generally very sluggish performance

Given how revolutionary Opus is, its crazy to me that they could trip up on something as trivial as a CLI chat app - yet here we are...

I assume Claude Code is the result of aggressively dog-fooding the idea that everything can be built top-down with vibe-coding - but I'm not sure the models/approach is quite there yet...

how does it work?

Indeed - the future is RL meet-ups and small, intimate online communities.

Perhaps not the worst thing in the world?

I’d love something like this implemented for email.

Sending an unsolicited email to a random person X requires you to pay a small toll (something like 50p).

Subsequent emails can then be sent for free - however person X can “revoke” your access any time necessitating a further toll payment.

You would of course be able to pre-authorise friends/family/transactional emails from various services that you’ve signed up for.

This would nuke spam economics and be minimally disruptive for other use cases of email IMO…

HN may not be “mainstream” but it is certainly _very_ vulnerable to bot spam given the topics discussed and the make-up of the audience.

You can already see it happening now - at least the bots that write like vanilla Claude/ChatGPT. Presumably there is a much larger hidden cohort of bots that are instructed to talk more naturally and thus are better adept at flying under the radar…

Look at his other comments - its textbook LLM slop. Its a fucking tragedy that people are letting their OpenClaws loose on HN but I can't say I'm surprised. I desperately need to find a good network of developers because I think the writing is on the wall for message boards like these...

Repugnant.

Doors - A first person, exploration game/experience that I built from scratch.

Doors lets you explore URL addressable 3D rooms that link together seamlessly via portals. The idea is that people would upload rooms to the internet (to github, S3, whatever) and connect them together to form one giant inter-connected space that would be a real trip to explore.

Right now rooms consistent of a: - Manifest JSON file that points to requisite resources and configures portals - An optional skybox - An optional background music track - A .vox file containing voxel terrain data

Here is a video I filmed on my phone of flying through a room that links back to itself: https://www.youtube.com/shorts/BCqOYTISS_k

Portals can be arbitrarily sized and everything is prefetched/loaded seamlessly in the background.

I'm nearly done - I just need to add in a very lightweight interface and give the code a bit of a spit shine (I will open source it - so I want it to look pretty)

EDIT: As an aside, I finally decided to give this whole Claude Code thing a go - I purchased a max subscription and I'm trying to write as little code as possible. I certainly wouldn't call what I'm doing "vibe-coding". I discuss a feature in plan mode (incl. how I want to implement it in high level terms) iterate on the plan 2-3 times until I'm satisfied and then let it rip. I'm both very impressed and quite frightened by the productivity boost...

0.0005%*

If this is somewhat common for games, could one create a virtual fs with FUSE that dedupes using via content-defined chunking and install games there?

I feel like writes would probably be quite painful, but with game assets are essentially write-once read-forever so not the end of the world?

As an aside, its messed up that people with expensive SSDs are unnecessarily paying this storage tax. Just feels lazy...

Also check airline miles haven’t gone missing.

A friend of mine recently had his BA account compromised, all his Avios stolen and he was none the wiser after receiving about 60 emails a minute

The rank disrespect of somebody asking you to review something they haven't even looked at is eye watering.

I feel like AI-induced brain-rot of engineers is inevitable. Unless we see AI leapfrog into something close to AGI in the future (certainly not ruling this out), I think there will be very lucrative careers available to engineers who can maintain a balanced relationship with AI.

To quote Mean Girls: "Stop trying to make Doxbridge happen".

I totally agree.

Isaac, if you're reading this - stop sending me PDFs generated by Perplexity!

> Gmail is so big that when Outlook, Apple Mail, and even Thunderbird connect to it, they do an OAuth exchange and then talk over a proprietary protocol.

Can you elaborate? Anything I can read on this?