When tractors were invented, there was a notable reduction in human employment in agriculture in the USA. From a research paper (https://faculty.econ.ucdavis.edu/faculty/alolmstead/Recent_P...):

> The lower-bound estimate represents 18 percent of the total reduction in man-hours in U.S. agriculture between 1944 and 1959; the upper-bound estimate, 27 percent

I'm not seeing that with LLMs.

According to Wikipedia, the Ivel Agricultural Motor was the first successful model of lightweight gasoline-powered tractor. The year was 1903. You're like someone being dismissive in 1906 because "nothing happened yet".

I started reading the article and immediately got hit by the incorrect statement in the opening:

> If AI agents help each support employee handle 30% more tickets, that's like adding 30 new hires to a 100-person team, without the cost.

I think this is an oversimplification designed to make LLMs seem more profitable than they actually are.

This is an article written by a company/llm trying to justify huge increases to the pricing structure.

Oh! Yknow that thing we were charging you $200 a month for now? We're going to start charging you for the value we provide, and it will now be $5,000 a month.

Meanwhile, the metrics for "value" are completely gamed.

The price will be what you are willing to pay. No justification required, excepting for fairness (info asymmetry and what else?). It is written by me. Unfunded bootstrapped !!call it dire straits.

> Meanwhile, the metrics for "value" are completely gamed.

Well, of course. One of the huge advantages of agents is that they will actually help you to almost any extent game metrics.

Unlike people, who have ...

:)

At the same time, I actually wouldn’t mind a world in which AI agents cost $5000 a month if that’s what companies want to charge.

I feel like at some level that would remove the possibility of making a “just as good as humans but basically free” arguments and move discussion in the direction that feels more productive: discussing real benefits and shortcomings of both. Eg, loss of context with agents vs HR costs with humans, etc…

If the AI does all the easy tickets, there's no easing in new hires, so that process is going to be more expensive, so I better get discounted for that hit.

If there is zero slack, and only the hardest parts, this is no longer the job it was before. Salaries will have to go up, or retention will go down. In addition these jobs could already be awful when there was some slack, removing all slack tasks to AI is going to make them miserable so average customer interaction once they get to a human agent is probably going to be worse so your customer satisfaction will take a hit. So I better get discounted with that reputational hit.

It's like the 'have AI pick the tomatoes it can, and the field worker the rest'. Picking the easy tomatoes is factored into the job. Having the ai pick the easy ones could break the whole model. Of having zero slack for the workers could break them and result in no one showing up to jobs where AI has done the easy picking.

One reason slack exists is because of capacity and utilization, less slack -> higher wait times in peak times.

Is slack intended for Employee welfare? Come on, we are talking corporate here.

The support services are already regimented - L1, L2 etc. I am not a fan of AI either, but it may be a new reality.

You sound incredibly short sighted. Yeah slack and making sure people don't just get unwinnable tickets all day is important for retention. And if your company needs more than warm bodies reading a script, yeah, you account for it.

Most machinery you can't run 100% capacity. Most machinery you can't run 24/7. You schedule load. You schedule downtime. And the higher the capacity, the more the machine costs. If you aren't aware of this for your people you are failing at your job.

Not sure I follow. But, the first paragraph is interesting.

You are saying, employees stick around if they are given easy tickets, and companies care about passing along easy tickets so warm bodies do not churn.

That will be a big claim.

oversimplified surely, sweeping assumptions....

As much as I hate the assumptions, the worst case scenario is that AI is surely affecting some jobs.

But I'm sure that 30% employee is more valuable than just calling API in one month. So the price is too high.

Productivity continues to increase but we are employing more people, not less

Of course, there is displacement. Jobs evolve.

TL;DR: on-call manages acute issues, documents steps taken, possibly farms out immediate work to subject matter experts. Rate on-call based on traces they leave behind. Separate on-call with same population, but longer rotation window handles fixes. Rate this rotation based on root cause reoccurrence and general ticket stats trendlines.

Longer reply:

I have on-call experience for major services (DynamoDB front door, CosmosDB storage, OCI LoadBalancer). Seen a lot of different philosophies. My take:

1. on-call should document their work step by step in tickets and make changes to operational docs as they go: a ticket that just has "manual intervention, resolved" after 3 hours is useless; documenting what's happening is actually your main job; if needed, work to analyze/resolve acute issues can be farmed out

2. on-call is the bus driver, shouldn't be tasked with handling long term fixes (or any other tasks beyond being on-call)

3. handover between on-calls is very important, prevents accidentally dropping the ball on resolving longer time horizon issues; handover meetings

Probably the most controversial one: separate rotation (with a longer window - eg. 2 week) should handle tasks that are RCA related or drive fixes to prevent reoccurrence

Managers should not be first tier on any pager rotation, if you wouldn't approve pull requests, you shouldn't be on the rotation (other than as a second tier escalation). Reverse should also hold: if you have the privilege to bless PRs, you should take your turn in the hot seat.

Thanks for being here over the years. The faces changed some, stayed the same some, but it’s good people and good conversation!

May you all have a happy new year, and many more!

Tossing mine in the pot too: make + pandoc: https://ordecon.com/2020/07/pandoc-as-a-site-generator/index...

I've been playing around with a limited PCB autorouter for mechanical keyboards. You feed it a KLE layout file, and it spits out a KiCad PCB, layout map for QMK firmware, and various SVG cuts for case machining.

How would this work against scrapers that are based on driven anpproved browser instances, eg. something like Selenium?

The browser instance knows it is being driven by an automation agent. If you so wanted, you can actually comment out the code that does that in the browser's code but since this new setup will enable the page to check if you compiled your own browser, they'll be able to incorporate the "isUnderAutomation" flag under the attestation data and that's sealed because you can't build your own browser and have it attest.

The length of a law doesn’t reduce its murkiness - in fact it makes it more pronounced. That is why (in the common law systems) there is so much discussing and re-discussing of topics that plenty of other cases already covered, using new approach angles. If you make laws longer and more complex, you only make them serve more those that have the budget to explore all branches of the decision tree.

I mean, sure. Corruption exists. But the that's another issue entirely. Your comment doesn't add to the question of the GP - "does the existence of edge cases make implementing a law extremely difficult?" The answer is no. You could probably outline all the exceptions and applications of such a law in a few pages.