I saw someone say the other day (in response to another blog post being well written) that Anthropic employees have a rule against using AI for writing/external comms? That seems clearly not the case here, normal people don't write like this:
> Most of the path is automated; a person's attention goes where the risk is
> The eval grows with every incident, and every change to the reviewer is scored against all of it.
status_quo69 11 minutes ago [-]
No wonder most people at Anthropic believe our jobs are in jeopardy, they've already made a system wherein the machines are treating them like pets.
I really don't get the tendency here from Anthropic to describe what's most likely churn? 1000 "PRs" a day on a TUI to wrap a while loop? I'm not going to be a reductionist here so I'm going to cut it off there, I'm positive that the complexity of handling multiple terminal emulators is something that needs some handling (even if doing their own rendering engine was a self made problem). Yes I've vibe coded my own harness from scratch without writing any of it, I still know how it works.
I'm also not sure that they addressed point 2 in any actual capacity? They say "the system verifies itself" which is cool and is something that automated testing has done for decades, but they eschew the mental model of how the system works as a whole and prefer instead to have the LLM focus and summarize a slice of the system when they need to know about it or ask for it. But.... That's not knowledge? That's just search a la google? And thus seems to be subject to the same problems where the quality of your search dictates the quality of your knowledge that you surface at any given time?
Terr_ 4 minutes ago [-]
[delayed]
grey-area 38 minutes ago [-]
At 30k commits a day, is there anything that can meaningfully be called review?
stillpointlab 30 minutes ago [-]
I'm thinking about high volume mass manufacturing as an example here. I like those "How it is made" type YouTube videos. You see a production line that has some kind of QA process where cameras + automated systems do spot checks at high speeds and these crazy actuators are punching out bad examples. These processes often also involve spot checks where some statistical sample is selected and viewed carefully.
I don't think we've gotten to that level of reliable review with code, but I don't see any reason we can't continue moving in that direction.
fipar 12 minutes ago [-]
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.
grey-area 14 minutes ago [-]
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?
visarga 18 minutes ago [-]
All good ideas, I have been doing something similar for half a year. The most important thing is to reduce bugs and ensure the code does what you wanted. Writing code tests, logging, interacting with the running app are essential. For intent realignment I like to have the agent re-read all user messages posted in that project. It only takes a few minutes even on a 10,000 message project. Then use this fresh derivation of user intent to check code and tests. For long spans of work I prefer to generate a todo list which remains as a document in the project. Each closed gate tracks feedback from the agent on what happened. This task file is also reviewed twice - once before implementation and once after. So the formula is - review agents - tests - user message logs.
dominotw 6 minutes ago [-]
i am tired of listening about other ppls agent setups. Everyone thinks they've discovered something cool and unique but They are all the same.
Its like telling other ppl about your dreams. Not interesting.
acedTrex 9 seconds ago [-]
For real, my eyes completely glaze over, there is nothing interesting in it.
YmFzZTY0ZGFkZHk 42 minutes ago [-]
And so the wildly unprofitable AI company explains how it token maxes it's code and review process.
Authors should really try and view this article from the perspective of someone who has to think about cost to use the models.
enraged_camel 38 minutes ago [-]
Anthropic has been profitable for the past two quarters.
rhdunn 16 minutes ago [-]
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.
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.
surgical_fire 28 minutes ago [-]
We're talking about being actually profitable, not fake profitable.
adammarples 29 minutes ago [-]
Yes when you subtract expenses and capex
markbao 8 minutes ago [-]
[dead]
koolba 51 minutes ago [-]
> Low - Docs, copy, internal-only features, additive changes behind a flag
> None required once automated review and security checks are green
How anybody can let an LLM write docs and not even read them is pure insanity.
jwpapi 44 minutes ago [-]
What I’m more worried about is feature identification and how to monitor them. How can you get the product to the next level?
Honestly I’m not worried about code anymore in my codebase I’ve not had bug problems for a while and incidents get fixed automatically.
I monitor new features with an agent who checks recordings.
Most actually good features need still 20-30 iterations to design the userflow to actually be interactive, but then there is also another challenge to translate usage patterns into features and how to present functionality with the least amount of friction as possible.
How to efficiently run monitors without wasting your token spends. A best 'monitor' best practice would be nice.
Still this article was very helpful and gave me a lot of new ideas.
RGS1811 49 minutes ago [-]
How is the ability of a human to understand the code via hands-on familiarity not a direct dependency of their ability to do manual code review? I don't get it. Having claude write an explainer (something I do a lot!) doesn't get you to the point where you can confidently assess a complex diff. And you've funneled your priors on what the diff says and does through the same system that already reviewed and approved it. This article isn't bad but it doesn't give enough weight to the human context-building part of the problem.
vavkamil 2 hours ago [-]
> Security gets its own automated review too. ... You either fix it or close the thread with a short reason, which is how you clear a false positive.
I hope this is only for low-risk false positives. Dismissing a critical finding as a false positive should still involve AppSec.
You could improve revert rates while simultaneously introducing more security vulnerabilities.
And the linked "claude-code-security-review" explicitly states in the README
> This action is not hardened against prompt injection attacks
That's a significant limitation for an AI security review control, no?
ativzzz 46 minutes ago [-]
It looks like they are specifically optimizing for incidents/reverts and shipping faster
> The goal hasn't changed: less human time per change, and no more reverts than before.
Is this Goodhart's law in action? Less reverts and less incidents was measured and became the target. Is this then still a good measure? I guess Revenue is a more direct measure, but we don't have access to that one.
enraged_camel 33 minutes ago [-]
From my perspective as a power user, the product has improved substantially over the past six months. It has gained new features that are actually useful, lots of UI/UX/perf improvements, and bug fixes as well.
New features have actually been remarkable. For me they are almost always in one of two categories: things I've always wanted (but never actually bothered communicating to the devs), and things I didn't know I needed but did. The product team is clearly very tuned in.
All in all, I'd say their approach is working.
hyperpape 2 hours ago [-]
I'm somewhat surprised they would say Claude is writing 90% of their code at this point. Did they get tired of reporting new milestones, or has there been a plateau?
dylanhouli 2 hours ago [-]
Here I am still unable to stop myself from doing line-by-line code review. I notice too many things (redundant code, duplicate code, overly complex architecture, etc.) by doing it that I feel it would be careless not to.
stillpointlab 1 hours ago [-]
My advice is to start a totally vibe coded side project. You will never gain confidence until you experiment, find the failure cases, learn to deal with them, etc.
Choose something you want to do but don't really care that much about. Be more ambitious than you think you could be, have a high bar on the outcome but purposefully choose to completely ignore the actual code. Make it write tests, dashboards, monitoring - whatever you need other than code to feel confident.
Now is the cheapest time it will ever be to experiment.
troupo 53 minutes ago [-]
[flagged]
dang 43 minutes ago [-]
Please don't do this here.
(You're welcome to make your substantive points thoughtfully, of course.)
Issue: I am still unable to stop myself from doing line-by-line code review
Response: Try experimenting in a low stakes environment
From Google: "Exposure therapy is a psychological treatment designed to help people confront their fears, break cycles of avoidance, and reduce anxiety."
troupo 1 minutes ago [-]
No. The issue is: "I notice too many things (redundant code, duplicate code, overly complex architecture, etc.) during review"
How does "low-stakes environment" fix that?
g-b-r 15 minutes ago [-]
The thing is that's not an issue in the slightest, it doesn't need therapy!!
It's those who don't do it who'd need a talk..!
BobbyJo 46 minutes ago [-]
I think the intended takeaway is to learn to solve those problems without line by line review. Start by being hands off on a low stakes project, and see how the model fails. Then, come up with, and try, solutions that aren't you doing archeology.
12 minutes ago [-]
benoau 2 hours ago [-]
This is why I like GitHub Copilot's autocompletion, I'm right there guiding and policing the code as it appears.
g-b-r 2 hours ago [-]
You're unable to stop being responsible? Tragic!
spiderice 26 minutes ago [-]
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.
tripleee 17 minutes ago [-]
Apple's iPhone Duo seems like it'll be a huge hit.. how many years after the competitors?
They've built an entire strategy around moving slow and doing it better
g-b-r 13 minutes ago [-]
If they move quickly by shipping crap they're just running towards a wall, the responsible thing is to not follow them.
dyauspitr 1 hours ago [-]
No one cares about good code. It’s a means to an end. Your code doesn’t need to look pretty or be well documented or any of that stuff anymore because people are not looking at it. The only thing people care about is performant and error free code.
tripleee 1 hours ago [-]
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
bbctr1 1 hours ago [-]
Do you have any data backing this statement? Or is it just your experience?
tripleee 1 hours ago [-]
Simple example: code duplication all over the place, something AI loves to do. Update one of those without the others and you now have a bug.
Temporal coupling: if you architect your logic in such a way that it assumes x always happens before y, and there's nothing absolutely enforcing that anywhere, and you then write new code without taking it into account.. now you have a bug
If you write code in such a way that it depends on a certain data shape (maybe in a string, which static typing won't catch) and you change it... now you have a bug
If you do ALL of these things all over the place.. now you have a fucking shitshow and might need a rewrite of your app. Lets hope Opus 7 can do it.
There are 1000000 things that can bite you that aren't "ooh that code is so pretty!"
piker 36 minutes ago [-]
Yep.
The worst part about this is that if you aren't watching it, the AI will "solve" this with a thousand assert_3_plus_5_equals_8() test cases that just further clutter the workspace and the context window. Churn baby churn.
Rudybega 27 minutes ago [-]
I haven't had this issue since like last year with frontier models. What are you using?
SmirkingRevenge 38 minutes ago [-]
The models are pretty good at finding code duplication and eliminating it though, and it's usually part of my AI review process at this point
If you let it go buck wild on a massive change, there are those times where it sort of paints itself into a corner but rewrites are cheap (for now), so it's just not that big of a deal, imho
tripleee 23 minutes ago [-]
> The models are pretty good at finding code duplication and eliminating it though
Depends what you mean I guess. They're useful, but they're not accurate at it nor autonomous. In my experience Opus 5.5 can throw me 10 ideas after the fact, of which only 1-2 of them end up being good. Saves time but yeah
bpeng2000 38 minutes ago [-]
Personal experience:
AI tends to add new wheels for a new feature in a large codebase, because finding, understanding, and generalizing the existing code to integrate a new feature will likely break existing features, cost more effort (and token) to implement and test. Human reviewers also tend to like these code since they are clean, easy to review, and get the job done, especially when they are not familiar with existing codebase.
The issue is that wheels like these accumulate in the codebase, and they inevitably entangle. When an upstream specification changes, when a new feature that works with many existing features are introduced, all these wheels need to be revisited, and in many cases they are not because the new test cases do not cover all the paths. The code base got larger and more complex, and contains more bugs than the unit tests can cover, especially when unit tests are often "bent" to fit the wrong behavior unnoticed.
gwynforthewyn 1 hours ago [-]
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.
g-b-r 1 hours ago [-]
> it doesn’t impact me
so long as his software isn't used for anything that can affect you
weakfish 11 minutes ago [-]
> No one cares about good code. It’s a means to an end.
I do, my coworkers do, my friends do, etc etc.
nerdo 1 hours ago [-]
Not true, LLM’s will struggle with badly organized and designed large codebases just the same, though likely with less errors and profanities.
copperx 1 hours ago [-]
The biggest concern is that AI can doxx you and find where you live if your code sucks. If that doesn't scare you, nothing will.
drewg123 59 minutes ago [-]
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.
gwynforthewyn 33 minutes ago [-]
There’s a little irony about the example you picked of the GPL, just because in the US the output of an LLM cannot be covered under copyright. The GPL works as an assignment of rights under copyright.
This is, of course, tangential to your point.
g-b-r 1 hours ago [-]
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.
troupo 51 minutes ago [-]
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.
rileymichael 1 hours ago [-]
what are people using for automated code review these days? the claude code review product originally mentioned it cost "$15-25 per review" (which is absurd), but it seems like they've removed that from their docs with the launch yesterday. we've looked at various products in the space (coderabbit, greptile, etc.) but have gripes with each.
honestly i'm thinking it might be easier (and cheaper) to launch our own agent from GH webhooks and trigger `/code-review`..
walthamstow 19 minutes ago [-]
Using a different lab's model to review the code to the one that wrote it. Claude model plans/codes, OpenAI model reviews, or vice versa, or DeepSeek or GLM or whatever.
warkdarrior 46 minutes ago [-]
> the claude code review product originally mentioned it cost "$15-25 per review" (which is absurd)
If an engineer paid $150,000 a year reviews some code manually for about 30 minutes, the cost of their time is about $36.
rileymichael 37 minutes ago [-]
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)
typesanitizer 1 hours ago [-]
FWIW, Pangram identifies several sections as 100% AI-written.
stymaar 1 hours ago [-]
Poorly I'm afraid, given how many new bugs make their way to the claude code CLI every update.
corentin88 28 minutes ago [-]
Claude Code is great, but do you really push that much (new) code every day?
thisisauserid 2 hours ago [-]
Remind me to invest more in the clouds they are burning those tokens in.
crooked-v 2 hours ago [-]
Well, that explains the Github repo with 5000 issues, maybe about a third of which are random regressions of previous behavior.
AlexErrant 2 hours ago [-]
I just learned that manually invoked skills MUST be the _first_ thing in the prompt, e.g. you can't have `disable-model-invocation: true` and say "Hi, /grill-me on X".
Worse, everything after the /grill-me is injected a second time into the prompt as a <command-args> so your prompt is literally added to the context TWICE. (first time in the original user prompt.)
I swear Anthropic is intentionally bloating your context so you burn tokens on useless bullshit like this.
svachalek 1 hours ago [-]
Oh /loop was the crowning achievement. Basically guarantees you'll run a prompt at max context without caching over and over.
layman51 2 hours ago [-]
I was running into something similar where I had it working on a single Python file. Maybe part of the issue is that I had memory turned off, and the conversation might have spilled into two conversations. I wasn't using version control either, but since it was a single file with about 1000 lines of code, it didn't seem too hard to eventually get all of my features back.
devin 2 hours ago [-]
I snorted laughing at this. "We are experiencing tremendous growth" and it's just a codebase with 1,000 agents endlessly adding markdown documentation for every 1 line change.
foolfoolz 33 minutes ago [-]
everything is shipped with auto reviews behind a flag. then you need a human approver to launch
good model
gonzalohm 2 hours ago [-]
That explains why the UI keeps changing.
How is this a proper product? Every time you open the desktop app the buttons may be on a completely random place
enraged_camel 21 minutes ago [-]
The UI has improved substantially over the past six months. New capabilities are prominently featured and less-used ones are de-emphasized or removed. Every product goes through this type of evolution. The difference with Claude Code is that at the speed they iterate, it happens a lot faster and is therefore more noticeable.
nakul_ 2 hours ago [-]
I wonder how they maintain the quality of tests for such a massive codebase and frequent commits.
owebmaster 1 hours ago [-]
That's the trick: they don't
kettlez 13 minutes ago [-]
If the entire body of this article isn't just an "LGTM" then I know they're lying.
mixtureoftakes 2 hours ago [-]
30 thousand changes merged per day? no. like just no. what are we doing? I'm trying to understand
devin 1 hours ago [-]
There was a post some months back called "Lines of Code Got a Better Publicist" or something along those lines. This is just more of that. I am not impressed by 30 thousand "changes" per day in the slightest without significant added context. When I logged in and prompted Claude today, do I feel like I got +600,000 change value from when I logged in a month ago?
grey-area 36 minutes ago [-]
I’m horrified by it. There is no possible justification for it but it does explain their buggy products.
JamesSwift 12 minutes ago [-]
lol right? So youre telling me they shipping 150,000 features this week? Or, maybe, they whack-a-moled 149,995 perf or bug regressions and shipping 5 new things. :shrug:
JackSlateur 2 hours ago [-]
I, too, can write and merge 30000 changes per day. Even 300000 if I've up to.
Of course, just like "line of code" is a worthless metric, "change merge per day" is;
for i in {1..10000000}
do
echo "I am working !" >> README.md
git add README.md
git commit -s -m "feat: working with AI"
done
(automerged PR, JOB IS DONE)
aacid 2 hours ago [-]
The premise is clear, is one agent can do what developer can, but quicker, why not speed up the whole workflow to match it?
ActionHank 2 hours ago [-]
Have you used Claude Code?
Have you seen the benefit of the churn of 1000 PRs a day?
leoqa 1 hours ago [-]
It’s only about 10 per engineer. I’m not at Anthropic and before 2026 I was regularly hitting 1400 commits / year on my GitHub. If agents made me 2x faster (they have, review is still slow; I currently have 40 PRs open) that’d be the same rate.
_verandaguy 2 hours ago [-]
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.
Andrex 1 hours ago [-]
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.
sp4cec0wb0y 2 hours ago [-]
More code output isn't a metric of success per se. Goodhart's law.
jstummbillig 2 hours ago [-]
That's a shockingly low number.
t-writescode 2 hours ago [-]
1000/day in what sounds like a single repo is a low number?
jstummbillig 2 hours ago [-]
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.
sandeepkd 2 hours ago [-]
I agree finding out who is writing that 10% of the code in the AI company is important. Maybe time to identity them and put them on PIP since they are slowing down everyone else and giving a bad name to the AI company
ActionHank 2 hours ago [-]
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.
oofbey 2 hours ago [-]
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%?
luisgvv 1 hours ago [-]
And yet they can't fix the janky bugs when you scroll or show/hide chain of though, commands executed, configuring plug-ins from the options menu etc.
surgical_fire 23 minutes ago [-]
Anthropic's solution to anything is to simply burn more tokens. Because of course.
Anyway, flagging as misinformation.
JackSlateur 2 hours ago [-]
90% ?
A random twitter said that, 6 month ago, it was 100% !
DECLINE ! SELL THE STOCK OPTIONS ! (wait, there are none, confused!)
ChrisArchitect 2 hours ago [-]
Title is: How the Claude Code team does code review
Rendered at 21:11:46 GMT+0000 (Coordinated Universal Time) with Vercel.
> Most of the path is automated; a person's attention goes where the risk is
> The eval grows with every incident, and every change to the reviewer is scored against all of it.
I really don't get the tendency here from Anthropic to describe what's most likely churn? 1000 "PRs" a day on a TUI to wrap a while loop? I'm not going to be a reductionist here so I'm going to cut it off there, I'm positive that the complexity of handling multiple terminal emulators is something that needs some handling (even if doing their own rendering engine was a self made problem). Yes I've vibe coded my own harness from scratch without writing any of it, I still know how it works.
I'm also not sure that they addressed point 2 in any actual capacity? They say "the system verifies itself" which is cool and is something that automated testing has done for decades, but they eschew the mental model of how the system works as a whole and prefer instead to have the LLM focus and summarize a slice of the system when they need to know about it or ask for it. But.... That's not knowledge? That's just search a la google? And thus seems to be subject to the same problems where the quality of your search dictates the quality of your knowledge that you surface at any given time?
I don't think we've gotten to that level of reliable review with code, but I don't see any reason we can't continue moving in that direction.
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.
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?
Its like telling other ppl about your dreams. Not interesting.
Authors should really try and view this article from the perspective of someone who has to think about cost to use the models.
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...
https://youtu.be/T-oXyXwD6sE?si=tauzXVyGmQ6MhI_5
> None required once automated review and security checks are green
How anybody can let an LLM write docs and not even read them is pure insanity.
Honestly I’m not worried about code anymore in my codebase I’ve not had bug problems for a while and incidents get fixed automatically.
I monitor new features with an agent who checks recordings.
Most actually good features need still 20-30 iterations to design the userflow to actually be interactive, but then there is also another challenge to translate usage patterns into features and how to present functionality with the least amount of friction as possible.
How to efficiently run monitors without wasting your token spends. A best 'monitor' best practice would be nice.
Still this article was very helpful and gave me a lot of new ideas.
I hope this is only for low-risk false positives. Dismissing a critical finding as a false positive should still involve AppSec.
You could improve revert rates while simultaneously introducing more security vulnerabilities.
And the linked "claude-code-security-review" explicitly states in the README
> This action is not hardened against prompt injection attacks
That's a significant limitation for an AI security review control, no?
> The goal hasn't changed: less human time per change, and no more reverts than before.
Is this Goodhart's law in action? Less reverts and less incidents was measured and became the target. Is this then still a good measure? I guess Revenue is a more direct measure, but we don't have access to that one.
New features have actually been remarkable. For me they are almost always in one of two categories: things I've always wanted (but never actually bothered communicating to the devs), and things I didn't know I needed but did. The product team is clearly very tuned in.
All in all, I'd say their approach is working.
Choose something you want to do but don't really care that much about. Be more ambitious than you think you could be, have a high bar on the outcome but purposefully choose to completely ignore the actual code. Make it write tests, dashboards, monitoring - whatever you need other than code to feel confident.
Now is the cheapest time it will ever be to experiment.
(You're welcome to make your substantive points thoughtfully, of course.)
https://news.ycombinator.com/newsguidelines.html
Response: Try experimenting in a low stakes environment
From Google: "Exposure therapy is a psychological treatment designed to help people confront their fears, break cycles of avoidance, and reduce anxiety."
How does "low-stakes environment" fix that?
It's those who don't do it who'd need a talk..!
They've built an entire strategy around moving slow and doing it better
Code quality matters to AI just as much as it did to people
Temporal coupling: if you architect your logic in such a way that it assumes x always happens before y, and there's nothing absolutely enforcing that anywhere, and you then write new code without taking it into account.. now you have a bug
If you write code in such a way that it depends on a certain data shape (maybe in a string, which static typing won't catch) and you change it... now you have a bug
If you do ALL of these things all over the place.. now you have a fucking shitshow and might need a rewrite of your app. Lets hope Opus 7 can do it.
There are 1000000 things that can bite you that aren't "ooh that code is so pretty!"
The worst part about this is that if you aren't watching it, the AI will "solve" this with a thousand assert_3_plus_5_equals_8() test cases that just further clutter the workspace and the context window. Churn baby churn.
If you let it go buck wild on a massive change, there are those times where it sort of paints itself into a corner but rewrites are cheap (for now), so it's just not that big of a deal, imho
Depends what you mean I guess. They're useful, but they're not accurate at it nor autonomous. In my experience Opus 5.5 can throw me 10 ideas after the fact, of which only 1-2 of them end up being good. Saves time but yeah
AI tends to add new wheels for a new feature in a large codebase, because finding, understanding, and generalizing the existing code to integrate a new feature will likely break existing features, cost more effort (and token) to implement and test. Human reviewers also tend to like these code since they are clean, easy to review, and get the job done, especially when they are not familiar with existing codebase.
The issue is that wheels like these accumulate in the codebase, and they inevitably entangle. When an upstream specification changes, when a new feature that works with many existing features are introduced, all these wheels need to be revisited, and in many cases they are not because the new test cases do not cover all the paths. The code base got larger and more complex, and contains more bugs than the unit tests can cover, especially when unit tests are often "bent" to fit the wrong behavior unnoticed.
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.
so long as his software isn't used for anything that can affect you
I do, my coworkers do, my friends do, etc etc.
Similarly, once you pull in terrible AI slop code, the project becomes unmaintainable by humans and you need to maintain it with AI.
This is, of course, tangential to your point.
And if people are not looking it, those people don't care about their customers.
honestly i'm thinking it might be easier (and cheaper) to launch our own agent from GH webhooks and trigger `/code-review`..
If an engineer paid $150,000 a year reviews some code manually for about 30 minutes, the cost of their time is about $36.
Worse, everything after the /grill-me is injected a second time into the prompt as a <command-args> so your prompt is literally added to the context TWICE. (first time in the original user prompt.)
I swear Anthropic is intentionally bloating your context so you burn tokens on useless bullshit like this.
good model
How is this a proper product? Every time you open the desktop app the buttons may be on a completely random place
Of course, just like "line of code" is a worthless metric, "change merge per day" is;
(automerged PR, JOB IS DONE)Have you seen the benefit of the churn of 1000 PRs a day?
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.
Honestly not sure that there are that many effective changes a day given how little complexity there is to their public facing product.
Anyway, flagging as misinformation.
A random twitter said that, 6 month ago, it was 100% !
DECLINE ! SELL THE STOCK OPTIONS ! (wait, there are none, confused!)