"Tbf, it's worth pointing that many large legacy systems already work like that (sort of), with "Claude" replaced by "whoever happens to be maintaining it this year".

The real difference as I see it is that in the human maintained old style system, the human would take things slowly and ensure they understand any changes. Claude let loose will just say "yes, I know how to do this" and bork the system, because it doesn't have a concept of humbleness in the face of complexity!

most large software companies are already too large for anyone to have a complete mental model of.

The idea that someone at say, Google, will be able to fit even half of the system architecture in their heads is not realistic. It also hinges on being able to find and understand the right slice of the system in any situation.

But we have all sorts of guardrails to make that easy - i.e logs, traces, etc

>The software they develop around their model is, relatively, trivial

30,000 changes a day is not my idea of trivial.

I mean, sure we can assume that (although the Anthropic article from the other day say that claude mostly builds Claude) but this is the Claude Code team which, I again am assuming so I could be wrong, focuses on the TUI/CLI interface to those models, not necessarily the models themselves. That coupled with the fact that this is how a large portion of their clientele interact with their moat, it would be odd to me if they didn't apply significant work towards this thing to keep the hype or productivity train moving

When I worked at Facebook (pre LLM) we were around 50-100k per day. I imagine it's much higher now (quantity, probably not quality).

Fair enough, I did invent the 1000 a day because the article was vague, I'll edit my submission accordingly to also be vague

Exactly. What they’re doing, repeatedly, is setting a narrative that this is how software engineering should be. Always be reliant on tokens. Don’t worry about uptime or errors - agents can address it, don’t worry about security - agents can address it, don’t worry about code comprehension - agents will always be there for you.

I've definitely picked up some weird claudeisms. I even know the em-dash keyboard shortcut now.

Yuuuup. Which I guess makes it even harder to detect what's AI and what's not.

It's a bit more subtle than things like "it's not X, it's Y". And even that isn't "wrong", it's just the way AI talks, and therefore an indicator that the author offloaded their thinking to an agent. I've read so much Claude output that it's easy for me to recognize its voice, the same way I could recognize a friend's voice in writing. The examples I quoted are a weird kind of circuitous sentence structure with a certain shape and rhythm that scream Claude to me. Here is how I might rewrite them in human speak:

> Most of the path is automated; a person's attention goes where the risk is

--> We automate as much as possible, focusing human attention on risky parts

> The eval grows with every incident, and every change to the reviewer is scored against all of it.

--> We run reviewer evals against every incident

But that's just my interpretation and my voice. I can't know for sure what the authors would have said if they took the time to write it themselves.

It feels like it's trying to sell you something in every sentence.

I really like those videos too, but a very big difference is, in manufacturing QA, the system outputs a very high number of copies of a very small number of possible types, so spot checks work fine from an operations research point of view, as the variance in output has a known upper bound.

For code, I think things go in the opposite direction: the system outputs artifacts that are all different among themselves (even more so now that we no longer distribute software via physical copies. Well, bits are always physical, but I mean we no longer ship floppies/CDs/DVDs).

That said, at least in my experience, code review has never been a direct part of factory-line-type QA. That QA is typically done by treating software as a black box and just verifying that it complies with a spec (often times based on a very loose definition of "spec" ...), and this is something that works equally well regardless of whether a human or a machine wrote the software. The type of QA that is done (among other things) by code reviews is checking whether the software's design is such that it will be economically feasible to maintain and extend it, for example.

The one part the code reviews takes a part of (but is in no way error-free) and that you just can't do with black-box testing (or it is much harder to do) is to look for things like backdoors. As our industry moves more towards "agents write software and tests validate that it works," I think a lot about "Reflections on Trusting Trust" and the new and wide attack surface added by people no longer reading the code shipped on their behalf.

That’s a category error. Software isn’t stamping out the same part again and again; if it were review would be simple. Analogies often mislead.

Of course Anthropic would love you to think you are heading towards that future so we have to bear in mind their livelihood depends on LLMs being the future of work and 30k changes a day being normal.

But why would we want 30k changes a day in a given product, what possible justification could there be?

Those manufacturing videos are of someone making the exact same thing over and over. Months and years of testing go into ensuring that there is no change in the system, and continuous monitoring is put in place so that if any changes slip in, it can be undone. The design is set in stone, as it should be, and variations are bugs. There are months to years of cheap prototypes, iteration, design changes, pipeline tuning, and verification to ensure that nothing will need to change for the next million items.

If you want a software analogy to those devices getting churned off the assembly lines, it's the TCP streams coming out of your network card, with crazy checksums punching out bad packets.

We're orders of magnitude better at reliability with code, but we're regressing on that metric rather quickly. And the comment above deeply misunderstands both manufacturing and software.

Those machines are not doing design work. They automate production of designs that had long development and testing lifecycles. Code is design. The compiler is the automated production process.

Honestly systems like this resemble real engineering more than manual human review does

"Anthropic told investors that it will profit on a measure called adjusted operating income.

"According to the report, adjusted operating income excludes stock-based compensation, which is not unusual for technology companies. However, the report also quotes its gross margins - above 80% - exclude revenue shared with distribution partners, as well as the cost of training its models."

From https://www.morningstar.com/news/marketwatch/2026091414/the-...

How so? Can you link to the numbers?

Antropic's revenue is up [1], [2], [3] and if you calculate adjusted operating income (by excluding most expenses like training costs) then by that measure it is profitable. However, if you factor in all the numbers it is operating at a loss.

[1] https://finance.yahoo.com/technology/ai/articles/anthropic-v...

[2] https://fortune.com/2026/09/29/anthropic-leaked-ipo-prospect...

[3] https://www.cnbc.com/2026/10/15/anthropics-third-quarter-rev...

Source? Only reports I’ve seen was they were profitable for one month in last quarter due to xAI discount of renting out colossus . Be interested to learn otherwise.

Profitable as in after expenses.

https://youtu.be/T-oXyXwD6sE?si=tauzXVyGmQ6MhI_5

That's factually incorrect, and shouldn't be allowed here.

We're talking about being actually profitable, not fake profitable.

“I think that, every time you see the word EBITDA, you should substitute the words "bullshit earnings.” ― Charles T. Munger

And what they're reporting is adjusted even further than EBITDA

Yes when you subtract expenses and capex

I used to keep a dream journal because I thought it might be interesting to recall all of my dreams.

Eventually I did, but it was hours and hours of effectively random stuff happening that I had to write down or dictate with speech to text.

It was a waste of time and I'm now glad I forget almost all of my dreams. My point is even my own dreams are uninteresting.

I'm not that interested in my own agent setup either - usually the tools become better on their own after a few months and render it all obsolete.

Much like the output of agents themselves

So true.

For real, my eyes completely glaze over, there is nothing interesting in it.

I'm curious what has improved so much. To me Opus 5.5 is very good but so was 4.6. I try to forget the versions in between...

not even one tangible example?

My interest is mostly from the management perspective -- in 2025 I have seen a prime example when a heavily vibe-coding team chugged out half-baked products that other teams later had to deal with and this was not pretty and created all sorts of interpersonal issues; the same I fear may be happening here as well.

I'm looking at Claude Code and they chug releases daily and sometimes more often then this, if someone has to stop and code a critical path by hand or smth I'm wondering how this is handled.

--

On a separate topic, the "llm freaks" -- I know you intended this as an insult, but I'm actually proud to be called a freak again, and I thought this is the place where freaks are discussing things.

I did this, but now I have a useful piece of software that I have zero clue regarding how it works. My only chance of "maintaining" it is giving it to another LLM to explain.

I am happy that I have a useful tool, but it simply isn't maintainable without a machine or me investing much time to understand it.

I don't see how the former is a sensible future for humanity. I am happy to say I won't be releasing this software I've created (I will find it useful myself), but deferring all understanding to a black box seems a poor future for brain activity.

I've been working on a large (~10MLOC) mostly vibe-coded project for months now. It's actually quite frustrating:

* The agent will fix a bug when I tell it to, but only in exactly one place. I'll notice that another place has that bug later and have to redo it. It's the sort of thing that I would know to check for if I were fixing it myself. Yes, I can ask it to look elsewhere for similar bugs, but even that's not super reliable.

* The user-facing text it generates is just as awkward as ever. I have to rewrite all of it, and sometimes it slips through. It's also hard to write text when you don't know what the code is actually doing.

* It doesn't have a good model of what kind of information is relevant to humans. It's just as likely to produce a paragraph of random jargon as a clear explanation of what's actually going on. It shows excessive detail for things that don't matter, and not enough detail for things that do. For example, it doesn't understand that $0 can logically mean "null" in terms of how humans think about things (e.g. "This item is free" vs. "This item is $0").

I kind of wish I hadn't gone down this path but now it's far too late, I can't really manually maintain this amount of slop. I'm quite sad if this is going to be the end state of this profession.

I have done this. It's exactly the reason I went back to doing code review. I don't look at the code with a fine toothed comb, but it does help me catch bad patterns early.

I've done this, and always get subpar results. I cant get the LLM to make the minor tweaks I want to see, and now I have no mental model of the code to make the fix myself. Sometimes they arent minor things.

Ridiculous suggestion. If someone already takes issue with ai generated code (as well they should, it often is _still_ pretty bad), getting them to write more of it is useless.

Additionally, do you really believe that 'Now is the cheapest time it will ever be to experiment'? Why so? Because of token prices? Not a good omen if so.

[flagged]

Is it responsible to move slowly when your competitors are moving quickly? Depends on how your competitors perform. If they perform well, then your "responsibility" suddenly becomes your extinction.

People saying this are telling on themselves that they have no idea what quality code is. It's not about looking pretty or nice variable names.

Code quality matters to AI just as much as it did to people

Literally 50 years of engineering history and culture cares about whether code is good. There are libraries worth of books about it, not as a means to an app but for its own beauty. Just read “The Elements of Programming Style”, for example.

Do what you want, write apps with AI and don’t review code, it doesn’t impact me. The claim that no one cares about good code is demonstrably false, and that’s all I’m objecting to.

Not true, LLM’s will struggle with badly organized and designed large codebases just the same, though likely with less errors and profanities.

> No one cares about good code. It’s a means to an end.

I do, my coworkers do, my friends do, etc etc.

Good code is a means to the end of the code being error (and vulnerability) free, maintainable and performant.

And if people are not looking it, those people don't care about their customers.

The way you phrase it makes me realize its almost like a GPL contamination. Eg, once you pull in GPL code, your project is infected and can never use a BSD (or other GPL incompatible) license.

Similarly, once you pull in terrible AI slop code, the project becomes unmaintainable by humans and you need to maintain it with AI.

Code that isn't duplicated in 15 places, that doesn't read the whole database to fetch just 1 record, that doesn't do 15 database reads where one would suffice, that uses an optimized algorithm instead of an exponential one recreated badly from scratch... all that is also good code, and is just as important in LLM-slop era.

No code is error free. All code will need a fix of some kind eventually. When it does, it's better that the internals are not a total mess. In the same way that you don't want the insides of your car to be total alien nonsense either.

this: gh actions using an opencode harness (so we can use cheap models through OpenCode Zen). With the right model, and the right, scoped access, it's just a prompt away.

bugbot was costing us $1k per month for a small team. EVEN IF we decide to go with a paid or say something like GPT Sol for our custom harness it'll cost us maybe $100. We've already implemented all of bugbot's interesting features like cross-PR memory.

the cool thing is we can leverage this for things that bugbot cannot do. Just today I added a security-reviewer action reusing almost all of the code that we wrote for the code reviewer.

I do it this way too. I think having the same lab's model review the code in a fresh session also helps, so I use both: I generally start a new Claude Code and a Codex and have them review the code with a focus on 3 things: 1. bugs, 2. cut corners, 3. code style.

This generally works for me. I think a solid spec is the key for the models to review against. I ask them to follow the spec, and if the spec doesn't say, follow first principles.

Also, if there is a user experience change, they need to notify me.

How about your pattern?

in a vacuum, sure. the average pull request will have multiple commits once opened (i.e. to address feedback or perhaps it was opened too early), each triggering a review. it's very easy to rack up $100+ per pr (and an eng may open a dozen prs in a single day)

You can call it however you want, but in the end it is just poor engineering. Imaging building a bridge that needs construction every week

Oh /loop was the crowning achievement. Basically guarantees you'll run a prompt at max context without caching over and over.

I have done exactly this as recently as yesterday, so I’m not sure why it doesn’t work for you.

I’m horrified by it. There is no possible justification for it but it does explain their buggy products.

Have you used Claude Code?

Have you seen the benefit of the churn of 1000 PRs a day?

Right, but why do things this fast to begin with, especially for a product that's already publicly available?

I don't want to use a product that shifts under me as I use it several times a day. I want a product that actually moves slowly and works very reliably.

As an end user: why would I care about how many hundreds of releases a month are being pushed if maybe 1% of them have features I care about?

Speed is not the product.

More code output isn't a metric of success per se. Goodhart's law.

Humans don't operate at AI speeds. We're making the car go from 0 to 5000 mph in 1 second and the drivers are turning to goo in the seat.

I am not sure what it is you are saying. What I am saying: I would have supposed that Claude writes 99.x% of Claude's Code code, and that ~no code at Anthropic is written by humans anymore.

The 30,000 number in the blog is the number of changes landing per day, not per month!

to achieve what?

Honestly not sure that there are that many effective changes a day given how little complexity there is to their public facing product.

No. 90% sounds like a low number. That implies something else is writing 10% of the code? People? Other models? What on earth is writing that other 10%?