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.

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?