Hacker News Reader

Comment by ibejoeb | Hacker News Reader

Wow:

    In this role you will:
    - Design and build agentic AI systems that analyze, generate, and validate...
    - Build agentic architectures that compose specialized AI agents dynamically...
    - Build AI-driven continuous validation frameworks powered by agentic workflows and large language models that autonomously manage...

This is invoicing? If ever there was a domain that was purely deterministic, you'd hope it was invoicing.

View on HN

When I was at AWS, they famously required an extensive "CoE", correction of errors, or post-mortem, in an instance of over-charging a customer $0.26.

The idea is that if we can make small billing mistakes like that, we can make large billing mistakes, and need to invest in the correctness of the systems powering billing.

I have great respect for the engineering culture within AWS during those times. I am glad to have left before seeing it degrade and decline.

The irony is, the only purely deterministic thing, will be token consumption...

I severely doubt the world ever gets to such a point that the entire world melts into AI hallucination. And token consumption depends on so many other things, it's not all that deterministic either.

(token usage) is trending towards predictability for a lot of reasons. it's not deterministic but it's getting easier to reason about usage.

How can a random generator be deterministic?

Truth is, you can never know: https://imgur.com/random-number-generator-bwFWMqQ

I’m not so sure about that. I can see a real rationale for creating sanity checks using AI to more quickly/proactively catch pathological billing issues before they become HN nightmare stories. They wouldn’t replace billing code, but there are many ways that stupid customer mistakes can cause real costs to Amazon that either have to be refunded and absorbed by Amazon or paid by the customer causing a negative opinion of AWS. If a billing AI watching costs in realtime could detect, say, a lambda loop in the first 10 min and either alert the customer or kill it, that would make AWS feel a lot safer to use. Enumerating these conditions and fixing them individually is a task that Amazon has proven incapable of achieving. An AI watchdog layer might be the perfect shortcut to addressing all of these problems at once. Because it’s well-trodden territory that AWS has so many multi-thousand dollar foot guns that make it really scary to use as a hobbyist or small business on a tight budget.

> I can see a real rationale for creating sanity checks using AI to more quickly/proactively catch pathological billing issues before they become HN nightmare stories

Right, so invoicing is still a deterministic problem. You can bolt whatever on but in the end it's just product x price x units

This is exactly the sort of thing that’s not possible, though. An AI will not be able to detect a “lambda loop” because it will look exactly like a “successful lambda rollout”. This sort of watchdog would just as likely shut down the wrong things and make AWS feel a lot less safe.

It doesn’t matter which domain it is, AI should be utilized at anomaly / patterns detection and prototyping, with goal of a prototype to become coded as discovered pathway.

I don’t understand why companies still place AI in their system at authority-forming level, if anything it should sit at least behind single guard / validator that is explicitly coded and tested, never in front of presentation layer.

This is like half of all job listings I've read recently. And it's a decent amount of fintech that's like this.

Probably not actually. Transferring one kilobyte across a network link has such a low value that the billing costs of aggregating it cost more than the revenue.

So instead you take a probabilistic approach - charge the user for a megabyte of data transfer 0.1% of the time, and bill nothing 99.9% of the time.

Now the typical cost is the same, the users bill is probably accurate to the cent, but you have divided the number of billing records by 1000.

The way you describe requires somehow counting every bit but somehow discarding most which is obviously nonsense.

This seems statistically invalid insofar as it will tend to overbill potentially by a lot on the minority of cases.

Don't you know how much of the pipe is occupied by a given customers code at any given time or what data is being sent

You have to do it when the customer list is too big to keep a counter per customer.

No you don't

A probabilistic counter per customer is also a counter per customer. Still, probabilistic billing is an amusing thought though.

I don't know how cloud services count usage, but this is certainly not true for telco. I manage several fleets of hundreds/thousands of SIM cards (mostly IoT/M2M applications), and almost every provider counts the data traffic per byte. Different business and use case, I know, but still.

Reply on news.ycombinator.com