> This is great, your suggestion to replace s3 and ddb is to run some VMs?

Well... yes?

What do you think the AWS S3 and DDB is running on? Fairy dust?

No it’s using an army of extremely well paid engineers, something I guarantee the parent comment has no access to

> No it’s using an army of extremely well paid engineers, something I guarantee the parent comment has no access to

That's a different argument to the one I replied to, and the reply to "they have expensive infra people" is "you have to have expensive product-trained people to use them anyway".

It’s not really a different argument

The suggestion was to replace DBB and S3 with some VMs. Presumably those VMs would be managed by the engineers part of the parent commenter’s organization. They do not have access to as many engineers as AWS, nor do they pay them as well.

Not arguing about cost effectiveness here. Just pointing out how silly it is to suggest that you can replace DDB/S3 with some VMs ran by a midsize organization

It's probably 5 juniors fighting fires in reality and not giving a crap for your service. :P

> Instead of paying several engineers, that you have to vet first, to configure and maintain the services adjacent to your product you can just pay AWS or Azure or someone else to maintain the service.

Your engineers who all have to possess AWS or similar certs before you hire them, work for free?

A move off VPS to managed services doesn't reduce your headcount or labour costs.

You are correct. Someone has to manage and plan the infra. But that is the same for on prem or other non cloud. What you don't necessary need is several database admins, several network admins, several kubernetes admins, etc. I don't necessarily agree, but that is the calculation. Azure hires the 24/7 admins for the service and you pay a bit more to get a share of them. I have heard this argument in person.

I think there is a very narrow space where you need the resources that this provides and it's not yet more cost effective to have your own team of admins. At a certain headcount a the number admins don't matter that much anymore.

> Your engineers who all have to possess AWS or similar certs

If you're using managed services that are so complex you need certified people then you're doing it wrong

> Tiered pricing license... tiering based upon annual company revenues... should start super low for small companies (free for individuals), and jump to thousands of dollars per year for 10+ milion revenue companies.

Too complicated. Make it GPL (not MIT) and offer dual licensing.

Those corps that need it but are GPL-phobic can have a different license, and can pay for it.

> However, that does not carry the premise that humans are any different.

I didn't propose that premise. I state that the output of a compiler is a value while the output of an LLM is a probability.

> > When x is C source, a specific input always results in the same binary artifact being generated.

> Umm. Nope: see GCC flags.

The flags are part of the input, so `f(x) -> y`. You don't get `f(x) -> P(y)`.

You do know the difference between `y` and `P(y)`, right?

> This is true when using compilers as well, right?

No, because ...

> See Reflections on Trusting Trust" by Ken Thompson

That still results in `f(x) -> y`, not `f(x) -> P(y)`.

> What about if we use the same seed for the same input ? Does this count?

It doesn't, because in practice you get different outputs.

Try it with any coding agent you have.

In theory they must be but I guess in practice they are not deterministic. Yea coding agents are horrible 10 parallel agents with the same exact input, they come with very different and sometimes contradicting results. So yea llms are far from being deterministic.

I actually have gone to the AI repeatedly for system design solutions.

Daily.

I think only twice have I agreed with it.

Like the way it will always give you code if you ask, even if the code is crap, it will always give you a design if you ask. Won't be a good design, though.

Didnt work for the prod data that the AI nukes in spite of prompts saying "DON'T FUCKING GUESS", just like that in all caps: https://news.ycombinator.com/item?id=47911524

What makes you think it will work for you?

That I don't let agents run wild in a production environment?

You let them write code that runs in prod, which is the same thing with extra steps.

Unless you review that code carefully, and then we're back to the point about it not saving you any cognitive overhead.

Of course it saves me overhead by not having to read all the necessary docs etc myself and just check the resulting code and not having to type all myself.

> Of course it saves me overhead by not having to read all the necessary docs etc myself and just check the resulting code and not having to type all myself.

That link I posted upthread, the "developer" did not read the docs "because the LLM wrote the code" and hence did not realise that the token they had was a full access token, not a limited access token.

You're now boasting that you also don't have to read the docs because the LLM wrote the code?

I mean, it's literally the cause of their irreversible production deletion, in a link that you replied to, and you state you do the same?

It depends on the project. Anything high stake, I verify myself. But also with simple things it is still way faster having a agent dig through it, quote me relevant sections and me evaluating if it is sound, or not.

>> You let them write code that runs in prod, which is the same thing with extra steps.

The “with extra steps” is doing a lot of work in that sentence.

Yeah, this is what your agents do even before someone tries to trick them into doing something stupid.

Remember this: these things follow instructions so poorly that they nuke everything without anyone even trying to break the prompt. Imagine how easily someone could break the prompt if the agent ever gets given user input.