I’ll say that the parent comment is correct and explain why I think it’s correct.
Amazon has demonstrated a preference for “unregretted attrition” (URA). URA is the name for what happens when engineers exit the company and Amazon is happy that they do. The exit can either be due to a PIP failure (performance improvement plan) or just unhappiness with the company. If you believe URA works well, then URA is how Amazon gets rid of low-performing employees. If you are like me, then you believe that URA is mostly explained by the following factors:
- Failure of Amazon to successfully develop engineers. A good company will turn engineers into better engineers, and Amazon gets rid of them instead, which is inefficient. The attrition is only unregretted because Amazon was not competent enough to develop these engineers into better engineers.
- Consequences of poor culture, causing good engineers to mentally check out and eventually leave. The attrition is only unregretted because the good engineers will care less and therefore look like bad performers, when they’re good performers in a bad environment.
- A way for Amazon to avoid paying out stock grants at the 2-year mark (which is when you get most of your stock grants at Amazon). The attrition is only unregretted because somebody at Amazon cares more about the short-term bottom line.
- A way for managers to exercise control over employees they don’t like. The attrition is only unregretted because Amazon’s decisions about employee performance are based on bad data provided by managers.
I won’t share stories here but the targets are around 5% per year, maybe a little higher.
Meta also does something like 5% in unregretted attrition a year. I just don't know why you think AMZN wouldn't include those people in layoffs preferentially to higher performers.
During my time at Meta, they were teaching the engineers a lot, spent a lot of effort on proper onboarding, allowed changing teams at least once a year (more often with longer tenure), and otherwise seemed to make it easier for an engineer to find a better place in the Meta's structure instead of leaving.
I’m happy to throw an LLM at our projects but we also spend time refactoring and reviewing each other’s code. When I look at the AI-generated code I can visualize the direction it’s headed in—lots of copy-pasted code with tedious manual checks for specific error conditions and little thought about how somebody reading it could be confident that the code is correct.
I can’t understand how people would run agents 24/7. The agent is producing mediocre code and is bottlenecked on my review & fixes. I think I’m only marginally faster than I was without LLMs.
> with tedious manual checks for specific error conditions
And specifically: Lots of checks for impossible error conditions - often then supplying an incorrect "default value" in the case of those error conditions which would result in completely wrong behavior that would be really hard to debug if a future change ever makes those branches actually reachable.
I always thought that the vast majority of your codebase, the right thing to do with an error is to propagate it. Either blindly, or by wrapping it with a bit of context info.
I don’t know where the LLMs are picking up this paranoid tendency to handle every single error case. It’s worth knowing about the error cases, but it requires a lot more knowledge and reasoning about the current state of the program to think about how they should be handled. Not something you can figure out just by looking at a snippet.
Training data from junior programmers or introductory programming teaching material. No matter how carefully one labels data, the combination of programming’s subjectivity (damaging human labeling and reinforcement’s effectiveness at filtering around this) and the sheer volume of low-experience code in the input corpus makes this condition basically inevitable.
Garbage in garbage out as they say. I will be the first to admit that Claude enables me to do certain things that I simply could not do before without investing a significant amount of time and energy.
At the same time, the amount of anti-patterns the LLM generates is higher than I am able to manage. No Claude.md and Skills.md have not fixed the issue.
Building a production grade system using Claude has been a fools errand for me. Whatever time/energy i save by not writing code - I end up paying back when I read code that I did not write and fixing anti-patterns left and right.
I rationalized by a bit - deflecting by saying this is AI's code not mine. But no - this is my code and it's bad.
> At the same time, the amount of anti-patterns the LLM generates is higher than I am able to manage. No Claude.md and Skills.md have not fixed the issue.
This is starting to drive me insane. I was working on a Rust cli that depends on docker and Opus decided to just… keep the cli going with a warning “Docker is not installed” before jumping into a pile of garbage code that looks like it was written by a lobotomized kangaroo because it tries to use an Option<Docker> everywhere instead of making sure its installed and quitting with an error if it isn’t.
What do I even write in a CLAUDE.md file? The behavior is so stupid I don’t even know how to prompt against it.
> I don’t know where the LLMs are picking up this paranoid tendency to handle every single error case.
Think about it, they have to work in a very limited context window. Like, just the immediate file where the change is taking place, essentially. Having broader knowledge of how the application deals with particular errors (catch them here and wrap? Let them bubble up? Catch and log but don't bubble up?) is outside its purview.
I can hear it now, "well just codify those rules in CLAUDE.md." Yeah but there's always edge cases to the edge cases and you're using English, with all the drawbacks that entails.
I have encoded rules against this in CLAUDE.md. Claude routinely ignores those rules until I ask "how can this branch be reached?" and it responds "it can't. So according to <rule> I should crash instead" and goes and does that.
The answer (as usual) is reinforcement learning. They gave ten idiots some code snippets, and all of them went for the "belt and braces" approach. So now thats all we get, ever. It's like the previous versions that spammed emojis everywhere despite that not being a thing whatsoever in their training data. I don't think they ever fixed that, just put a "spare us the emojis" instruction in the system prompt bandaid.
This is my biggest frustration with the code they generate (but it does make it easy to check if my students have even looked at the generated code). I dont want to fail silently or hard code an error message, it creates a pile of lies to work through for future debugging
Writing bad tests and error handling have been the worst performance part of Claude for me.
In particular writing tests that do nothing, writing tests and then skipping them to resolve test failures, and everybody's favorite: writing a test that greps the source code for a string (which is just insane, how did it get this idea?)
Seriously. Maybe 60% of the time I use claude for tests, the "fix" for the failing tests is also to change the application code so the test passes (in some cases it will want to make massive architecture changes to accomodate the test, even if there's an easy way to adapt the test to better fit the arch). Maybe half the time that's the right thing to do, but the other half the time it is most definitely not. It's a high enough error rate that it borderlines on useful.
Usually you want to fix the code that's failing a test.
The assumption is that your test is right. That's TDD. Then you write your code to conform to the tests. Otherwise what's the point of the tests if you're just trying to rewrite them until they pass?
We have more necessary expenses, but the cost of computers, phones, and phone plans is so low. The expensive stuff is rent, transportation, food, childcare, and healthcare.
If a historian is going to uncover personal accounts from 2026, then they’ll be full of people who are struggling to make ends meet but are still drowning in a sea of inexpensive consumer electronics.
The expenses you're mentioning were also present in the past. Their cost or percent of revenue cost may have increased but this is covered ostensibly by inflation measurements. But the introduction of entirely new defacto necessities is not covered.
Of course inflation measurements are also flawed but that once again gets back into the broad point about how the reality of people is so much more relevant than any given number, especially once those numbers become seen as a goal to maximize, at any cost.
> O’Neill fears that the result will be a “bubble machine”—a winner-take-all system that inflates already large companies, blind to whether they’re actually selling more widgets or generating bigger profits.
Part of the problem is that if you look at the stellar long-term performance of indexes, they are largely explained by a small number of stocks in the index that perform extremely well… but you don’t know ahead of time which stocks those are. If you want the performance of the S&P500, you need a similarly diversified portfolio, the theory goes. It is hard to get a portfolio with that kind of diversity unless you buy index funds.
That diversification is a bit of a smoke-screen though. The most popular index funds are cap-weighted. This causes the allocation of capital within the fund to become increasingly dominated by those few winner-take-all companies.
When index funds grow to huge levels of assets under management, their own asset allocations come to make up a significant portion of the market cap of the stocks in the portfolio. Thus the cap-weighted investment strategy becomes a self-fulfilling prophecy.
> Thus the cap-weighted investment strategy becomes a self-fulfilling prophecy.
Either you’re doing the math wrong or you’ve skipped some steps.
Let’s say you have companies X and Y, each with 50% of the market. X is a winner, and the stock price goes from $10 to $45. Y is a loser, and the stock price drops from $10 to $5. The new weight is X=90% and Y=10%.
But this cannot be a self-fulfilling prophecy for index funds, because the index funds do not have to buy or sell any shares of X or Y to keep up (I mean rebalance, specifically). In this scenario, the index funds are just holding. (By “holding” I mean “not rebalancing”.)
This is… an oversimplified scenario. But it illustrates the problem here with the “index funds cause a small number of stocks to be winners” theory. There are alternative theories that make sense, but not this one.
(What makes the scenario more complicated is when you think of buybacks, dividends, delisting, etc.)
Obviously, but the point here is that cap-weighted index funds convert new money into buyers-at-any-price of their components.
When they're more concentrated in specific holdings, and have enough new money, wouldn't that artificially support higher prices for those holdings (above what the market would otherwise bear)?
Why not flip the argument, and say that the index fund is propping up stock B because of it's buy-at-any-price nature? What makes you think that valuing it at 10% of A isn't higher than what the market will actually bear?
The sensible and consistent way to this is that... Index funds don't really have any effect on relative stock prices. If stock A is overvalued or undervalued, it's due to active investors being morons.
Don't index funds trail market changes though? I thought their allocations are reactive. In other words, the Mag 7 are being bid up by people trying to beat the market. I don't see how index funds could move prices.
I do understand how they can stabilize allocations where they are, which I think is the concern. Zombification rather than a positive feedback loop.
And anyone who thinks they can consistently predict who will be among the 4% is... mistaken. Diversification is how one manages risk when a system has a power law distribution of outcomes.
Trying to beat the market is playing a zero sum game. Someone has to lose for you to win. I understand savvy winners add information, but most winners are just lucky and it still makes me uneasy to play a zero sum game.
When you simply try to match the market, you float on the tide that mostly raises all boats and sometimes lowers them. That sits much better with me.
Yes, my understanding is that the cost of missing out on those companies that are providing the returns is much more costly than investing in a company that is NOT generating those returns.
In other words, the risk is to miss the winners, not that you will invest in a loser.
The problem is that it is very hard to predict the winners, so it is best to invest in all companies to make sure you have the winners
> Once an AI can reliably regenerate an implementation from specification…
I’m sorry but it feels like I got hit in the head when I read this, it’s so bad. For decades, people have been dreaming of making software where you can just write the specification and don’t have to actually get your hands dirty with implementation.
1. AI doesn’t solve that problem.
2. If it did, then the specification would be the code.
Diffs of pure code never really represented decisions and reasoning of humans very well in the first place. We always had human programmers who would check code in that just did stuff without really explaining what the code was supposed to do, what properties it was supposed to have, why the author chose to write it that way, etc.
AI doesn’t change that. It just introduces new systems which can, like humans, write unexplained, shitty code. Your review process is supposed to catch this. You just need more review now, compared to previously.
You capture decisions and specifications in the comments, test cases, documentation, etc. Yeah, it can be a bit messy because your specifications aren’t captured nice and neat as the only thing in your code base. But this is because that futuristic, Star Trek dream of just giving the computer broad, high-level directives is still a dream. The AI does not reliably reimplement specifications, so we check in the output.
The compiler does reliably reimplement functionally identical assembly, so that’s why we don’t check in the assembly output of compilers. Compilers are getting higher and higher level, and we’re getting a broader range of compiler tools to work with, but AI are just a different category of tool and we work with them differently.
>If it did, then the specification would be the code.
Except you can't run english on your computer. Also the specification can be spread out through various parts of the code base or internal wikis. The beauty of AI is that it is connected to all of this data so it can figure out what's the best way to currently implement something as opposed to regular code which requires constant maintenance to keep current.
At least for the purposes I need it for, I have found it reliable enough to generate correct code each time.
What do you mean? I can run English on my computer. There are multiple apps out there that will let me type "delete all files starting with" hacker"" into the terminal and end up with the correct end result.
And before you say "that's indirect!", it genuinely does not matter how indirect the execution is or how many "translation layers" there are. Python for example goes through at least 3 translation layers, raw .py -> Python bytecode -> bytecode interpreter -> machine code. Adding one more automated translation layer does not suddenly make it "not code."
I mean that the prompt is not like code. It's not a set of instructions that encodes what the computer will do. It includes instructions for how an AI can create the necessary code. Just because a specification is "translated" into code, that doesn't mean the input is necessarily code.
What is conceptually different between prompts and code? Code is also not always what the computer will do, declarative programming languages are an example here. The only difference I see is that special precaution should be taken to get deterministic output from AI, but that's doable.
A prompt is for the AI to follow. C is for the computer to follow. I don't want to play games with definitions anymore, so I am no longer going to reply if you continue to drill down and nitpick about exact definitions.
If you don't want to argue about definitions, then I'd recommend you don't start arguments about definitions.
"AI" is not special-sauce. LLMs are transformations that map an input (a prompt) to some output (in this case the implementation of a specification used as a prompt). Likewise, a C compiler is a transformation that maps an input (C code) to some output (an executable program). Currently the big difference between the two is that LLMs are usually probabilistic and non-deterministic. Their output for the same prompt can change wildly in-between invocations. C compilers on the other hand usually have the property that their output is deterministic, or at least functionally equivalent for independent invocation with the same input. This might be the most important property that a compiler has to have, together with "the generated program does what the code told it to do".
Now, if multiple invocations of a LLM were to reliably produce functionally equivalent implementations of a specification as long as the specification doesn't change (and assuming that this generated implementation does actually implement the specification), then how does the LLM differ from a compiler? If it does not fundamentally differ from a compiler, then why should the specification not be called code?
It's commonplace for a compiler on one computer to read C code created on a second computer and output (if successfully parsed) machine code for a third computer.
You can't run most of what you would probably consider "code" on your computer either. C, Python, Rust, ... all have to be translated into something your computer can execute by compilers and interpreters.
On the other hand no current LLM can implement complex software from specification alone, especially not without iterating. Just today I realized how laughable far we are, after having fought GPT-5.1-Codex-Max for way longer than I should have over correctly implementing a 400 line python script for wrangling some git repositories. These things are infuriatingly bad as soon as you move away from things like web development.
The s-, i-, and r-processes do however follow the same mechanism at the most fundamental level, even if it results in wildly different production paths. I think the author was simplifying for an audience unfamiliar with the details, for whom this distinction is less important.
(And I say that despite my own work and usual eagerness to tell people all about it!)
Soundbars are usually a marginal improvement and the main selling point is the compact size, IMO. I would only get a soundbar if I was really constrained on space.
Engineering tradeoffs--when you make speakers smaller, you have to sacrifice something else. This applies to both soundbars and the built-in speakers.
I agree that speaker tech has progressed slowly, but cars from 20 years ago? Most car audio systems from every era have sounded kinda mediocre at best.
IMO, half the issue with audio is that stereo systems used to be a kind of status symbol, and you used to see more tower speakers or big cabinets at friends' houses. We had good speakers 20 years ago and good speakers today, but sound bars aren't good.
On the other side being I needed to make some compromises with my life partner and we ended up buying a pair HomePod mini (because stereo was a hard line for me).
They do sound pretty much ok for very discreet objects compared to tower speaker. I only occasionally rant when sound skip a beat because of WiFi or other smart-assery. (Nb: of course I never ever activated the smart assistant, I use them purely as speakers).
I already think that markdown is barely ok for writing documentation, and the experience of plugins in mdBook is why I tell people not to use it (edit: it = mdBook). The base flavor of mdBook is minimalistic. Maybe that’s a good thing, that you’re given a minimalistic markdown as a starting point? But if it’s minimalistic, then it’s certainly missing some things that I’d want to use in the documentation I write, and the experience of using plugins is, well, not very good.
My current recommendations are MkDocs (material theme), Jekyll, and Docusaurus. Hugo gets a qualified recommendation, and I only recommend mdBook for people who are doing Rust stuff.
Can you speak on what features were missing ootb and which plugins respectively gave you trouble? I'm not sure how "people who are doing Rust stuff" would specifically get more out of it either? Are you implying you cant just use the tool/plugins without familiarity in Rust? This is not my experience.
What is missing from markdown?
mdbook also uses in some parts the GH flavored one, so you can create notes [1] and similar. On top of that, you can add support for Mermaid.
Personally, I don't think you need more than that for 90% of the documentation, but I'm happy to hear more about your use case.
Markdown is devalued as a format because of the bizarre shortage of Markdown VIEWERS. You find Markdown documents in every open-source project, and you always wind up viewing them with all the embedded formatting characters. Why?
Why provide documentation in a format that is so poorly supported by READERS? Or, to respect the chicken-&-egg problem here: Why is there such a shortage of Markdown viewers?
Every time this comes up, respondents always cite this or that EDITOR that has Markdown "preview." NO. We're not editing the documentation; we're just reading it. So why do we have to load the document into an editor and then invoke a "preview" of it? Consider how nonsensical the term "preview" is in that case: What are we "previewing" its appearance in, given the dearth of Markdown readers?
Amazon has demonstrated a preference for “unregretted attrition” (URA). URA is the name for what happens when engineers exit the company and Amazon is happy that they do. The exit can either be due to a PIP failure (performance improvement plan) or just unhappiness with the company. If you believe URA works well, then URA is how Amazon gets rid of low-performing employees. If you are like me, then you believe that URA is mostly explained by the following factors:
- Failure of Amazon to successfully develop engineers. A good company will turn engineers into better engineers, and Amazon gets rid of them instead, which is inefficient. The attrition is only unregretted because Amazon was not competent enough to develop these engineers into better engineers.
- Consequences of poor culture, causing good engineers to mentally check out and eventually leave. The attrition is only unregretted because the good engineers will care less and therefore look like bad performers, when they’re good performers in a bad environment.
- A way for Amazon to avoid paying out stock grants at the 2-year mark (which is when you get most of your stock grants at Amazon). The attrition is only unregretted because somebody at Amazon cares more about the short-term bottom line.
- A way for managers to exercise control over employees they don’t like. The attrition is only unregretted because Amazon’s decisions about employee performance are based on bad data provided by managers.
I won’t share stories here but the targets are around 5% per year, maybe a little higher.
reply