The way we phrase anger with AI doesn't convey the structural realities of what's going on in the knowledge work chain. Gen Z aren't suddenly becoming anti-tech they are acting financially rationally to protect their own economic future.
In the past there was an implicit contract for white-collar employment that was based on the concept of earned experience through a period of manufacturing type work. You enter your profession by performing uninteresting, low-paying manufacturing tasks (such as, writing boilerplate type code or performing low-level quality assurance) while you gain domain expertise and gain the perspective necessary to perform high-value work at a higher level.
LLMs are now exceptionally good at consuming the 20% of an employees entry-level responsibilities.
What I see happening in the enterprise is that management is using AI to justify pulling the ladder up behind them and closing the door behind them. When a senior engineer's or senior analyst's productivity has increased by 30% due to using LLMs, the executive's response is typically not great, we have more time to work on bigger projects, but instead great, we can freeze junior hiring for 2 years.
The entry-level positions in the labor force are being automated, causing seriously low access to those roles for the Gen Z workforce. On the other hand, most senior-level positions are not being available to Gen Z workers as they lack the skills and experience required to qualify for those positions.
Stagnation in the adoption of artificial intelligence (AI) technology is the direct result of having no entry or junior level employees to work underneath senior staff members, causing a bottleneck for seniors. Employees generating raw output with AI technology have to check the results (output) for accuracy before integrating into work systems and processes as there are no entry-level employees to provide assistance to senior workers.
Gen Z workers do not dislike the tool (AI) however, they do not like how the tool is being implemented and used currently. Currently, the implementation of AI is driven by cost cutting in terms of labor rather than being focused on providing training and developing Gen Z's human capital for future use.
I don’t know about this. After some time sitting with it, I think that mid level and senior ICs - especially those slow to adapt - are going to be at risk of getting replaced by entry level “AI native” kids. Net on net it probably washes out to “normal” patterns of turnover and hiring once things settle.
Think “Smithers, we need to hire some of these kids who know computers!” Only fast forward about 30 years and str.replace(“computers”,”agents”).
That would only be true is AI usage experience was equivalent to domain experience, especially since the former keeps getting easier. If anything, companies might want to hold onto their seniors and midlevels, because they collectively decimated the process of creating new ones by refusing to hire and train younger workers. If later down the line they have a need for someone young and AI-experienced, they could just reach out into the endless job market and scoop up as much as they like.
In some ways domain experience can be a hindrance, with ingrained pathways and practices shaped by constraints that no longer apply. My personal opinion is that you probably want a mix of domain experts who are enthusiastic about AI and some kids who are free of preexisting dogma, and are willing challenge assumptions and try out things that the old heads might chafe at.
An example from software engineering is that all production code should undergo meticulous human review. Saying “no” to this sounds crazy to an experienced SWE, but might not actually be that crazy.
I think the constraints will remain in some fields, especially where there is a high price to pay for mistakes and consequently additional regulation. You can't vibe review code that will run on medical equipment, aircraft systems or industrial machinery. It doesn't matter how few people work in these fields, the fact that they shut off the tap to making new domain experts, while everyone and their grandma is learning to use AI will mean that the experts will eventually be at a shortage after retirements, while the enthusiastic AI users will be very abundant and underpaid.
Pretty sure the article explicitly stated the resentment is due to their clearly stated concerns continually being explained away.
Was your intention to be an example for resentment? Or are you an AI model demonstrating the embodiment of deserving of the resentment?
A voice is being demanded. Being louder and longer is exhausting to endure. Stop rewording and reworking the reasons into something with shape and direction, that only serves to strip the voice demanding being heard. It was written as it was meant. Slop is worse than a carbon copy, of a copy, of a copy.
I don't understand what you found to be so outrageous in the parent comment. The report addresses both emotional impressions of AI use and fears of it impacting the job market. As someone from gen Z, I don't like the average quality of slop that's being pumped into the internet and further diluting it, but my bigger concern is not living under a bridge in a few years time.
A couple of years ago, we experienced a silent data corruption incident in our checkout process due to this specific edge case.
A user would generate the idempotency key by loading the front-end application, adding item(s) to their cart, submitting their order but timing out. The user would then navigate back to the front-end application and add another item and submit the order again. Since the user is submitting an identical idempotency key to the same transaction, our payment gateway would look up the request/transaction by idempotency key and see in its cache that there was a successful (200 OK) response to the previous request. The user now believes they purchased three items, however, our system only charged and shipped on two of the orders.
Consequently, the lesson we take away from the aforementioned incident is idempotency keys are really composite keys (Client_Provided_Key + Hash(Request_Payload)).
If a system receives an identical idempotency key (but with a different request payload) the idempotency key should be rejected with a 409 Conflict response with a message similar to "Idempotency key already used with different request payload". Alternatively, some teams argue it should be returned with a 400 Bad Request response. Systems should never return a failed cache response or replace old entries of data.
This article explains how to unlock your flow. The final idempotent key will not be located until the first request completes, but will rather exist when the request is in progress.
To safely accomplish your goal, you have to follow the following steps:
1. Acquire a distributed lock on the idempotent key.
2. Check for the existence of a key in your persistent store.
3. If an existing key is found, verify the hash of the payload against the hash for the payload type. If the hashes do not match, return a 409 error.
4. If the hashes match, look up the status of the payload. If the status shows COMPLETED in the persistent store, return the cached response. If the status shows PENDING in the persistent store, return a 429 Too Many Requests to the user or hold the connection open until the request reaches a PENDING state.
5. After processing the request, save the response to the persistent store before releasing the lock.
While this may look simple on paper, creating a distributed locking state machine for a single API endpoint is typically how developers have their first aha moments with idempotency. Becoming idempotent is often an enormous architectural shift and not just a middleware header check.
This is incredibly poor advice. The bug was clearly in the client code, which did not understand the purpose or usage of the idempotency key. The API itself probably had a design flaw as well - it sounds like it needed a session or transaction id to serve the purpose you mentioned. That is not what an idempotency key is for.
An API should follow its documented behavior. This is both a specification and a contract. If the docs for the API say that a duplicate idempotency key will receive a 409, and do not mention message hashes, then they need to follow that spec because the client may specifically depend on it. For example if the order was processed and the cart is resent with the same key but an additional item, client does not want another order with the duplicate items in the first one. They want an error.
If the docs do not accurately describe the behavior of the idempotency key, the client should find another provider.
> While this may look simple on paper, creating a distributed locking state machine for a single API endpoint is typically how developers have their first aha moments with idempotency. Becoming idempotent is often an enormous architectural shift and not just a middleware header check.
Yes, when you expand the scope of your API implementation beyond its contract you take on a virtually unbounded amount of edge cases that not only must you solve, but that your customers must guess at how you are solving.
I'm guessing that your API required the idempotency key. I think that is could be risky because it means developers will simply provide a value for it without understanding the purpose, or thinking through the implications. You really only want them using it if they understand the problem it is solving.
Hashing message content could be an alternative behavior that it makes sense to support by default for apps that don't supply an idempotency key. As long as you document it.
Sounds like an interesting case of incorrectly trusting user input.
The idempotency key should have been viewed as the untrustworthy hint it really is. Then you can decide whether an untrustworthy hint is what you really need. At that point I'd hope someone on the team says "This is ordering - I think we need something trustworthy"
> Consequently, the lesson we take away from the aforementioned incident is idempotency keys are really composite keys (Client_Provided_Key + Hash(Request_Payload)).
Did the postmortem result in any other (wider) changes/actions, out of curiosity?
No idea if this was anything like what happened your case, and probably going off on a tangent, but I've seen so many cases where teams are split into backend and frontend, and they stop thinking about the product as a single distributed system (or, it exacerbates that lack of that thinking from before). Frontend often suggest "Oh we can just create an idempotency key" and any concerns from backend are dismissed. If they implement it incorrectly, backend are on the wrong 'team' to provide input.
I wholeheartedly agree. Luckily it is a lot easier to reliably run a distributed KV store that only needs to lock the idempotency key over relatively short times rather than a whole database with millions of records or make arbitrary systems idempotent.
> 5. After processing the request, save the response to the persistent store before releasing the lock.
Save only if the operation succeeds. It's meaningless to cache a failure, subsequent retries will result in failure from the cache.
Frankly you guys are overengineering the whole thing. We use the concept only for network outages i.e. it is only on timeout that we want to guard against fultilling duplicate request for the same operation.
Congrats on destroying the purpose of Idempotency Keys.
Ask yourself, why not just `Hash(Request_Payload)`? That'll give you half of what you need to know about why the Idempotency Key header is useful in the first place.
The other half you already know? You just described your bug, it's a bug, on your front-end, this has nothing to do with idempotency; if anything, the system is performing as expected.
If your requests do something different, they should have different Idempotency Keys. <- this brings down TFA and most of the comments here. I guess those are the perils of vibecoding.
There is a major disconnect in that people think token usage is exclusively tied to human typing rates...it isn't true. When software developers evolve to using self-managing CLI tools (like Claude Code - the source article mentions this), they are not merely chatting; they are unleashing loops of agency.
When you enter one single inquiry of "find and fix the memory leak in the billing service" you are not submitting just one single inquiry. The tool is searching through an entire code repository for relevant code, pulling 15 related files into context (easily 200k+ tokens) proposing a fix, running the test suite and failing, taking an entire stack trace of errors into context and looping to keep iterating towards the solution.. In that process you can loop multiple times (10+) in a very short period of times (within 5 minutes). While you grab a cup of coffee you will have consumed $20 in token usage. At the enterprise level (like with Uber) when you multiply that out by thousands of software developers using it as a personal shell tool your budget disappears very very quickly.
And on your point about the junior developer: Comparing $100,000/year in tokens to hiring a junior developer is such a ridiculous false equivalency that even makes you question whether they even understand how to make such a comparison.
The cost to a business of one junior engineer with a $100,000 salary is not just the $100,000 in salary but also an additional $40,000+ in benefits and taxes, as well as in hardware.
Also, you are disregarding another cost of hiring junior engineers that is their mentorship cost. Each week, your senior and staff engineers spend hours mentoring junior engineers by reviewing their code, pairing with them, and unblocking their progress. Mentoring requires a substantial amount of time and will be expensive to your business.
The return on investment (ROI) for the $10,000 monthly expenditure on tokens is not so much about replacing the junior engineer with the AI. Instead, the ROI is that your senior engineers can use the huge amount of compute power to create boilerplate and tests, and refactor their code 3x quicker than if they had to mentor junior engineers. In addition, LLMs do not sleep, require one-on-ones, or leave for another company for 20% more pay in 18 months, when the value to the code base made them an asset to your business.
Lastly, the main reason that Uber has problems with their AI business is that due to the UX of these agentic tools, developers think of the API calls made to the AI as free and as a result, treat them like a basic grep command.
I know that there is a lot of noise right now about AI doing science but this genuinely looks like a milestone.
Physics tl;dr:
Fast Radio Bursts carry more energy in a millisecond than the Sun produces in three days, but their exact emission mechanism is still an open problem. They analyzed data across four independent repeating FRB sources (from FAST, the Allen Telescope Array, and Effelsberg, reduced by three independent pipelines). It found that the adjacent drift-rate mode ratio recurs at 2.456 ± 0.094.
The cross-source scatter is an incredibly tight 3.8%. If this holds up, it means the factor of ~2.5 between adjacent drift-rate modes isn't a localized quirk of one neutron star it’s a measurable, falsifiable signature of magnetar magnetosphere geometry across cosmic distances. As they put it: "That would be physics."
The AI/Epistemology tl;dr:
What makes this impressive for me isn't just that an AI found a pattern, but how it did the science. They built a system called Primus and they ran a continuous research process from hypothesis to verified result. The hypothesis and analysis window were pre-registered and locked before validating data was inspected. The pipeline survived a pre-registered Monte Carlo falsification test at empirical p≤5×10^−4 against three distinct unimodal null hypotheses.
The system had to navigate statistical identifiability conditions and astrophysical emission models to arrive at this.
They’ve open sourced the full code,
We've seen AI solve known math problems and fold proteins, but an AI acting as a principal investigator formulating a novel hypothesis, pre-registering the falsification criteria, and discovering a new physical invariant feels like a massive step toward actual automated AI research.
Honestly it took me a bit to process. An AI system did the full analysis end-to-end hypothesis, clustering on 978 bursts, wrote the paper. Not assisted. Actually did it. Found a subpopulation at 9.2 sigma, interprets it as two emission regions in a magnetar. Passed 3 rounds of peer review at ApJ before the editor paused production over disclosure, not the science itself. MNRAS, A&A, arXiv all passed too, each for separate reasons.
What got me: they openly say 2 of 6 robustness tests didn't pass (alt algorithms, permutation). Right there in the methods. That's not what you do if you're trying to hide something. Honestly don't know where I land on the AI as author thing.
It’s really fascinating electrons took 60 years to go from chip to a smart device and if photons follow the same thing then we just fired the starting gun. It’s really interesting to see tantala material takes a single laser color in and spits out to a full rainbow.
Honestly that footnote really stood out to me too! the spiral search detail makes the whole system feel a lot more alive than I expected like it’s actively hunting for the star rather than just pointing and hoping.
