We are living in a totally bonkers time.
At one point seemingly out of nowhere he pointed out on his screen share "Look at how many tokens I've used this month. I run so much Opus." It was a number that was offensively large.
I remember thinking "That's a really odd flex, this crap is so expensive the fact that you use so much should be a red flag"
He demonstrated a number of Claude Code use cases he had to manage and tweak AWS infrastructure that made me, the old greybeard sysadmin older than the internet think "You've used AI to do something that was a single command."
So this story makes sense. They were being encouraged to just blast away at it six plus months ago.
But if you hit "tab" it'll claim that as an AI-edited line, LOL.
(A lot of the rest of it is stuff I could already have been doing just as fast if I'd ever bothered to learn to use multiple cursors, learned vim navigation, or set up some macros—I never did because my getting-code-on-the-screen speed without those has never been slow enough to hold anything up, in practice)
Probably there is no dichotomy going on and it depends on multiple factors, but it seems so weird to see reports that are so different between each other.
If you are making extremely specific, high quality products over a long time window and your founders are deeply experienced in that field of engineering, then no, you don't need agentic engineering and probably want very little llm code in general (outside of some boilerplate, internal toolings, etc).
This is work related. So you can't expect everyone to have the same input demands or output expectations.
> Probably there is no dichotomy
It's literally staring you in the face.
As time passes and the layers of abstraction pile up, later generations won't understand the underlying layers of the abstraction. This is a huge weakness in our systems development -- and a huge potential attack surface for adversaries.
Yes, and that’s a good thing! This is in fact where a lot of AI value lies. You dont need to know that command anymore - knowing the functional contract is now sufficient to perform the requisite work duties. This is huge!
Of course I lose about as much time as I save to its fuck-ups, so I'd still have been better off learning to actually use a text editor properly. Though (as I mentioned in a another post) part of why I've never done that in 25ish years of writing code for pay is that my code-writing speed has never been too slow for any of the businesses I've worked in, i.e. other things move slowly enough it never mattered.
A coworker created a shared Claude Code skill in our repo.
It's obviously something that can be done as a python or bash+jq script and run deterministically.
Instead we use natural language and waste tokens for that.
I use the shit out of opencode to do things as a force multiplier, not as a way to keep me from knowing what its doing.
The point at which we're optimizing for "we don't need to know that anymore" is the point at which everything blows up, because agentic work is not fully deterministic, models hallucinate even simple things.
Blindly relying on your agent weapon of choice to just do the right thing because you didn't take the time to understand how the lego fits together is an actual problem.
I find it hard to read "You can do things without knowing things" as a positive improvement in work, society, life, anywhere
Quite frankly it was embrassing. We've had tools for static analysis for ages. Use them.
Someone with better knowledge could work 100x faster using 100x fewer resources. They did it the slow, expensive way but at least didn't have to think? Odd flex.
If AI breaks production this way, you just tell AI to fix it! And look, now you've consumed tokens twice. Think on that and I'll see you at the end-of-year performance review.
This reminds me of the story of how the USSR nearly made whales extinct to meet a quota for whale meat that nobody wanted to eat.
How are we sliding face first into “snowpiercer but dumber”?
Now, they might be; they've certainly used silly metrics in the past (LoC, commit count, etc.) without ever fully acknowledging it. But I don't believe that it's as simple as more tokens = more better.
The problem explodes at any company that puts up a token use leaderboard or hints that they might do layoffs for engineers that refuse to use AI tools. This triggers a race to use as many tokens as possible to stay ahead.
Anecdotally, the problem is worst among devs who read a lot of social media. Twitter, Threads, Mastodon, LinkedIn, and others are filled with recycled viral stories about companies going AI-native and firing people who don't use enough AI. Anxieties are high right now so nervous developers see this and think they must burn tokens faster than their peers to avoid an inevitable culling.
Big companies have thousands of leaders. Many good, many bad.
They're using tokens for pointless stuff right now in order to figure out use cases where it helps. You can't do that without also learning where it doesn't help.
My company is doing the same thing.
[1] https://locusmag.com/feature/cory-doctorow-full-employment/
This isn't like that, as it isn't funded through taxes. This is private companies experimenting with their money, and risking downstream cost increases that may cause people to go elsewhere, as they do when they try anything new.
This is much better than just funding people regardless of productivity through forced taxes.
[0] https://nintil.com/the-soviet-union-achieving-full-employmen...
Either way, I don't know what this has to do with Amazon getting workers to use AI more, which is what my comment was addressing.
This is simply not true, especially when you consider the massive amounts of government support so many parts of this "experiment with their own money" is getting. As a Utah resident its extremely evident in how forcefully they're pushing through what will be one of the largest datacenters in the world despite near universal disapproval from the citizens.
I don't think USSR poverty rates surpassed those of Tsarist Russia that preceded them. To their credit, I think ideologic competition between capitalist and communist blocks was part of what allowed improvement of life conditions of workers in capitalist countries, after WWII. Fear of revolutions avoided one-percenters taking all productivity gains in the period. They had to share some to keep guillotines away. As soon as things went south in the USSR, from the 70s onwards, and capitalism took over the whole world, lacking any sort of viable extant competition, we reverted back to the old norm, the workers were denied their share of the productivity gains since then, and here are us now. A regime premised on free competition was undermined by lack of competition to itself.
There's definitely some pressure from managers when they hear about N00% productivity boosts in internal presentations, but where I am at they would figure out if you were making up tasks rather than working pretty quickly and the pressure comes from aggressive deadlines and a shift from the yearly OP1 process to a more agile one.
One person I've talked to has someone in their org who is running GasTown and chews through tokens 24/7. They don't contribute very much, but they're comfortably in the #1 spot.
But the thing is, the problem is the person, not the technology. He was already like this before LLMs. He would "refactor" repos into smaller repos, and all of a sudden all of the code has his name. If you just skim, it looks like he build a huge chunk of the codebase in the company. He also has a history of saying no to stuff I want to do, then he does it himself. Also nitpick my PRs to no end (or straight says he doesn't think he should do that thing) and then he turns around and implements it himself. He doesn't copy paste my code, but he does re-implement himself the same ideas that he just said no to after my PR was open. Very smart guy, very dishonest. But he's good at being dishonest. If you ask him about it he says "oh I just though that this way would be more organized" or something like that. From the outside you could make the argument that one way is better than the other (for reasons I would claim are irrelevant), so it's not obvious that he's being dishonest. But since I see 100% of what he does, it's entirely clear to me that this is a pattern.
EDIT: just remembered another one. One time I asked him to take a specific week of holidays. He didnt say "no" but he did mention that we're under a lot of pressure to deliver The Thing, and if I would delay my holidays. I said "No, I'm not going to delay them", so he approved it. Then when the time came around, he took holidays in the same week. On this one I didn't challenge him, I already know him well enough to know the truth which is he's no ashamed to ask from others things that he would never himself accept.
Of course at some point the 'benefit' is outweighted by the 'negatives', e.g people making up work. Tokens used is about as useful a measure of productivity as 'hours in office'.
EDIT: My use-case still have relatively low token usage though lol
Add a pre-commit hook to re-create the diagrams on every commit (in case anything changed, of course), that way you can really burn tokens and look good to management.
I asked Alexa (on the amazon web page) about it and it couldn't tell me which carrier had the items or why they were delayed, directed me to a non-existent phone number and then denied it had done so. The customer service bot I was eventually redirected to was even worse, and started telling my that items would be delivered both tomorrow and by May 27 in the same message. Finally I got human intervention, who said the items would arrive tomorrow and that the delivery status had been updated, but the order page still says they're arriving at the end of next week.
Choosing to wait for the PIP instead, if $EMPLOYER goes this way. Tell me the work I'm not doing and how pieces of ~~flair~~, sorry, tokens might help. Or don't, I don't care.
For companies doing this there is no 'justify the expenditure'. Employees are being praised for high expenditure, regardless of actual outcome.
Leadership see the problem as 'people resisting AI'. Embracing AI is seen as the solution, and token usage is seen as the measure of success.
I'm also hesitant to 'go for the gold' because it only means more B2B monopoly money, juiced stats, or expectation. Or, God forbid, become the resident Token Expert. That praise you mention is exactly what I don't want!
Slack will start serving porn next.
If I own part of a company, and I spend money on their goods, and a result their revenues climb and consequently my valuation does too - then my firm value will be higher.
This would also explain the gung-ho approach. Some pretty devious financial engineering akin to arbitrage
Have heard very similar stories to what the article describes. There were also outright revolts from tech folks being forced to use Amazon’s own shit self-built AI vs Claude Code and other top-tier products.
Given Amazon’s early start with Echo and Alexa they should have absolutely dominated this AI revolution but have been scrambling in a panic ever since ChatGPT showed up on scene and always seem two steps behind the market.
It all paints a picture inside Amazon of clueless leaders at the top and mobs of others below them just gaming the system so a silly dashboard looks green. “Day 2” has arrived.
I thought they just want to show up to others(especially non tech guys) that they spent high, so they know more about AI
I've chosen the wrong profession.
This is the new tap-in tap-out!
Anthropic sends .gguf and a claude-serve binary?
2. this may be ok. A good way to learn a piece of software or tool or process is to play with it. We learn lots of general knowledge through play and experimentation. Heck we get better at musical instruments by playing on them.
Mandates are kind of dumb in many ways. But they will force the issue of discovering whether anything useful can come from AI other than coding.
If you can't change your company, change your company!
No, they don’t.
I think the company realizes this and is actively trying to avoid this, since for the new tools there isn't a leaderboard.
Burn resources at all costs to appear productive and use proxy metrics to measure success.
Fire productive employees to ensure we have resources to fund the proxy metrics.
AI slop fool’s gold is the product.
> AI slop fool’s gold is the product.
juniors who are stuck on ai and cant learn is the real product imoEvery time I see "not... but..." I suspect an AI article. Not sure if this is the case here.
This is analogous to measuring productivity by LoC output.
True, but it looks like productivity to people whose own productivity is measured by how busy their subordinates appear to be.
> But a representative for Amazon said that there is no such company-wide metric for AI usage, nor are there internal leaderboards where employees are measured against each other. Rather, employees are able to view their own AI usage on personal dashboards.
Such a bullshit statement. There is a _global_ dashboard that ranks Kiro/QuickSuite (formerly Amazon Q) usage per-employee based on tokens. The dashboard itself is in QuickSight (well, that also became part of QuickSuite anyway).Not only the data is open to anyone, you can clearly sort by rank, daily/weekly/monthly/yearly usages. Current and former employees included. (By internal alias).
Moreover, there is an internal "awards" system that shows up in PhoneTool profile, each employee gets "awarded" of Kiro/AmazonQ/Quicksuite titles like "Blaze", "Thunderstorm", etc. You can see other recipients of the same award just by clicking on it.
Note: PhoneTool is an internal profile directory where you can look up other employees as oneself...
---On the side, I know several people who cannot produce proper code themselves, or integrate to anything on their own. Those who need constant hand-holding keep producing immense amount of stuff with Kiro/AmazonQ, over-ranking SDEs nowadays. (these are not SDEs, more of SysDev, Support Engineers and TPMs). This itself is not a specifically good or a bad thing. But once they stack-rank based on the token usage, I am pretty sure "good" engineers who put effort into writing "good" code will rank worse than people who does not put effort into "concise" solutions. Therefore, quality will eventually detoriate. And it will be too late once the leadership realizes what has been going on. (Well, they already seen the Amazon-Q/Kiro related outages and keep denying it...)
Like I tell my kids: If every experiment you do succeeds, you aren't trying hard enough.
that and make sure the tools are actually up treating amazon internal as real customers.
its hard to stay excited about the tools when they can be down for a week because kiro launched.
Such a bullshit. There is (was) Amazon Q (Now QuickSuite) leaderboard which is a Quick Sight dashboard. Moreover, each PhoneTool
I believe there has to be some downward pressure on these executives to take these decisions but I would like to know where it's coming from exactly and what's the logic behind them. Is it some big institution like Blackrock which has leverage on many of these companies? That's always been my bet but I never knew for sure.
Tokens is just yet another proxy for business value.
The problem they face is if everybody is judge by business value in dollars, crappy managers are the first to go
The original (third reich): "Wheels must roll for victory!"
It will end in the same manner.
I wonder when we'll see our first "My startup went bankrupt on AI use" post. Amazon is being dumb but at least they can afford it.
How are people burning through hundreds/thousands of $ of tokens a week/month?
What am I doing wrong.
This is an early symptom of the future devaluation of the skill of developing software. The value is going down because there is too little software developing work for the number of people who currently can do it.
theres so much work available that teams try to avoid taking stuff on as much as possible.
the bottleneck to building more is almost certainly the cross team coordination
likely the best place add agents too. an llm tpm would be super handy tool to scale amazon productivity, rather than coding agents.