How the Claude Code team does code review
claude.dev
claude.dev
Similarly, Anthropic can afford to do this because they have virtually unlimited tokens and labs to train models for their specific usecase. The rest of us need code comprehension lest we become dependent on continuous supply of tokens (which is a state these labs badly want to achieve)
So, unless you work at a lab, or have unlimited tokens guaranteed through the life of your company, it would do both the company and you good to continue to read the code and not let these 30k PRs per engineer be the norm.
An excerpt from the article makes my point
> Nobody on the team keeps a complete mental model of Claude Code in their head, and we don't think anyone needs to. When someone wants to understand a part of the codebase, they ask Claude to write an explainer for exactly that slice. It takes minutes and reflects the code as it is today.
Think I'm good on taking advice from companies that aren't making money.
Because "pacing the frontier" is more about flipping on the money printer switch than it is about safety.
If their Claude is the same as our Claude, then this is a joke. Claude’s writing style is insidiously mind numbing. It takes constant pushing to get it to explain things in digestible English.
At least Opus 5.5 does that. Its writing is better than that if other models, though. I had other models explain stuff in an undigestable language, technically correct, but practically not what anything is about.
Another thing is that it's very good at creating diagrams (I think someone wrote a skill for it so maybe not by default). I usually find the diagrams are even more valuable than the text.
Honestly I was skeptical but you really can just point Claude at some code and ask it to make a markdown + SVG explainer and it will do a shockingly good job.
I'd still rather read human documentation, but even before AI almost nobody writes any - especially for internal code. And they certainly don't make great diagrams.
If it was an exception only… but it is so common that I had to put ASD-STE100 into instructions to have precise answers.
Which is fine, whatever, I guess this is how I pay the mortgage off instead of having any clue what the hell Claude is actually writing. Hopefully I can semi-retire soon and go study dunnarts or take up welding or something else that's more rewarding than this nonsense.
For sufficiently large codebases in large organization that is how it has been with humans, who come and go. In many respects, What Anthropic is doing is a massive upgrade from the status quo.
Jesus. Give me 1 billion dollars and I'll keep your entire codebase in my head + personal notes for you until I die. Hell, I'll even force my descendants to do the same. Now _that's_ an improvement.
Another challenge is getting developers to stop assuming they know what the code does without reading it! Having AI “fact check” various documents against the source will help immensely.
> 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'm starting to worry about being gradually affected by AI's style through heavy use. It will make me so sad if one day my written piece sent to others is considered to be AI-generated, while it's written with real effort trying to make it sound natural.
I think when you repeatedly expose and immerse yourself to such a degree in reading and writing language, it brushes off on oneself. So I could also absolutely believe someone from Anthropic wrote this.
> This is not a cryptographic break, new attack, or weakness in the ECDSA curves.
It's only a claudeism when it says "X is not a Y" when no reasonable person would have been expecting that X could be a Y.
> Gradual release > The latest channel first; the stable channel trails it
Such an awkward, Claude-ish way of saying it
> 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.
I really don't get the tendency here from Anthropic to describe what's most likely churn? A high pressure amount of changes/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?
N.B. Changed "1000 PRs" to "A high pressure amount" to be vague since the article is vague here on what CC undergoes.
This is the crux. Take pause, because hidden here is a sea-change in our fundamental trust model of software...
There is no longer anyone to turn to if this system breaks by, eg, having a critical bug that no one can figure out. No causal model in anyone's head that can be appealed to, to slowly and methodically debug. By design, the system is too large for that, and everything hinges on Claude itself being able to find and understand the right slice of the system in any situation. As long as that very new invariant holds, everything will be all right. If it fails catastrophically, there is no recovery. You are the owner of a recovered alien spacecraft with tech you have no hope of understanding.
The new trust model is: We trust Claude to always understand the system enough to debug anything or make any reasonable change we could want. The risk might be worth the reward. But it's worth explicitly laying out the deal we're making.
Tbf, it's worth pointing out 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!
I love this phrase, and I think it captures the difference between the "60 years of legacy code" mentioned elsewhere here, and the vibe-coded monstrosity that we all know we're going to be encountering in the next 5 years. The fact that there were human brains with intent making all the little (short-sighted, myopic, ignorant, etc) changes in the legacy code means that you DO have at least some shot of gaining enough context to make safer changes.
There is no real intent in LLMs and particularly in blind vibe coding, so you'll end up reading stuff that works, or appears to work, but there was no human brain behind the change for you to model and thus predict.
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
At this point, why even bother with source code? Source code is designed for humans to comprehend. If humans are no longer the intended audience, why not have machines output and maintain some more efficient intermediate representation of computer programs?
Thank you! This is a huge sticking point for me. There is no knowing the code without experiencing the code. If nothing else, you have to read the tests to know they verify what you think they do. Even then, you might know it does what you want, but can’t know it doesn’t do anything it shouldn’t.
There are no shortcuts to true understanding.
I know some people will groan hearing the phrase again, but: "Reverse centaur." A centaur is a synergistic combination of two things, but now those things are in the wrong position: The human is the computer's tool.
Naturally, how "wrong" it is tends to depend on whether you ask the people who do all the work or the people who own all the computer-capital.
There's clearly enormous (human) work that goes in to building and tuning their models.
The software they develop around their model is, relatively, trivial. It's not clear that enormous amounts of (human) energy need to go in to that code.
It seems largely a function of applying human energy towards the things that are marginally most important to generating you money and putting you in front of competitors.
30,000 changes a day is not my idea of trivial.
From the article, the 30,000 changes a month are in the monorepo, and Claude Code is in a separate repo. So it’s not the TUI that has 1,000 PRs a day.
I could easily see 1,000 PRs a day on the backend. Big tech was doing more than that pre-AI.
I guess it wouldn't be surprising for people prone to AI psychosis to be attracted to working at the frontier labs, resulting companies that are heavily in the throes of mass AI psychosis.
Being tongue-in-cheek here.
Authors should really try and view this article from the perspective of someone who has to think about cost to use the models.
I'm glad they're doing this, because it lets me see an extreme of LLM development.
Compare that to the cost of human code review which can take up a third of an engineer’s time. You’re looking at $50-100K a year per engineer fully loaded in code review costs.
If AI assists in code review (not even replaces – we still do human review ourselves), you could spend thousands a month per engineer and still come out ahead.
Ironic that this comment talks about cost without weighing the numbers.
> 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.
I disagree. Many of us have an emotional attachment to the way we do things and have difficulty letting go. Anthropic is showing a different way of doing things. And I am not going to judge them too harshly if the final output is good. I use Claude Code every day. And it is good. Ahead of the pack.
Yes, this is a different way of doing things, and it's clearly working for them, but there is no direct line between that and a "ahead of the pack" product.
- How was this approved for SOC2 compliance? Our SOC2 reviewer explicitly mentioned that all code needs to reviewed by at least one other human before it goes to production. Claude Code says they are SOC2 compliant (https://code.claude.com/docs/en/security).
- This assumes all engineers will not do anything malicious. What is preventing a Claude engineer from spying on their ex's or some other companies Claude searches by pushing malicious code? Recently an OpenAI engineer was caught planting a recording device at their own office.
Obviously no amount of training will make AI human but: how is this different from you being the leader of a team whose output you own and are accountable for?
It takes a while to settle in and play deliberately. I also need to switch gears because bots play much differenly than human opponents - they don't fall for bait, they don't have time pressure at all, they don't leave pieces uncovered by accident.
I think of coding with AI is similar, you need to have a framework where you build understanding along the way from plan to review. It is untenable to roll out a 6000 line feature then try to review it, even if the LLM is happy to do things that way, mere mortals can't keep up. But if you stay in your lane and code solidly, AI can be a straight speed boost. I feel like most people despairing over handing the reins to AI simply haven't found their personal sweet spot.
Although, following Anthropic’s ethos and taking this to its conclusion, I’m not even sure why they need human reviewers at all. What, they bring in a human to look at a diff of an “important” section of code that was written by agents and has changed a dozen times since last week through 12 PRs of churn? Obviously they don’t know what’s going on. So what’s a human to do? Do what the other approvers (if any) did: fire up a Claude to command it “verify this change has no regression; check carefully for edge cases”, then come back after a half hour of High Thinking to see “Change is clean (with some non-blocking findings below, in order of significance)” and click Approve. Not sure what the purpose of the human is in such a process.
Now we’re just going to outsource our capacity to design and review because it’s faster that way, as if the thing that was wrong with the software industry was that releases weren’t being pushed out often enough.
That’s not how rates work
Regressions are usually the absolute worst.
Up to now we've just been eating shit on the DX side as far as regressions in Codex and Claude Code because everything is all "go-go-go OMG I don't want to fall behind" and also.. Access to new models is tied to harness updates.
But a ton of industries have users that are not so willing to eat the regressions in the name of more features and changes than they can keep up with.
Edit: Also moving too fast.. You may have been less likely to "get it right" than ever before leading to design churn. Again, depending on industry and users, they may not be very tolerant to releasing the 5th complete overhaul of some feature in so many weeks..
PS: I really want to know what is the churn rate (and the cost per LOC) here. My gut is saying the cost per LOC is insane, and they are basically rewriting over and over the same code.
Agree that 30k PR alone doesn't mean much, but there aren't other details on what's inside. Based on I saw on how LLM programming works, it's hard to believe that there are single-line fixes. If I have to bet I'd bet on 200 LOC on average, that is 6M/day. Even if only a small portion reach production, it's still insane.
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?
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.
It does make me wonder what on earth they are working on. Feels like most of their products could be basically finished already.
On the other hand Spotify somehow employs 3000 programmers, and that's just a music player.
Nobody on the team keeps the mental model of Claude Code as it is today in their head, so nobody on the team is able to reason and decide about Claude Code in the future, is that right? So no long term architecture strategy can exist as no current architecture understanding exists. While it seemingly does work for a system which is a TUI, would the same be true for a complex distributed system today?
And now this. Suffice to say, my efforts did not bear fruit. I feel more isolated than ever before.
Nowadays I'll ask a question to, for example, try to understand why was a particular abstraction chosen, and I'll get a response from a robot, sometimes without even a disclaimer that the response came from a robot (it's still somewhat easy to spot due to the shape and style of the prose).
It does make me feel like there is nobody on the other side, especially working remotely, so I think I relate to your feeling of isolation.
Sometimes I care about how some change impacts the broader application moving forward, not really the specific technical tradeoffs for one construct or another, and that's, more often than not, very lacking.
Opus 5.5 is obviously stellar but come on what are you doing lol
If it detects they aren't paying attention, fall asleep, or haven't approved enough PRs per hour; off the work at the factory.
The less you understand code, the more you're impressed by coding chatbots - in part because you're less likely to read the bot's code, and if you do, less likely to realise how poor it is. Code gets judged good simply because it exists and costed little to create.
Its like telling other ppl about your dreams. Not interesting.
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.
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.
Human contributions to issues, comments or submissions, were drowning in a sea of AI vomit. Tons of the issues had those AI issue submissions with the classic confidence of having identified the problem, but that smell I know a lot of us recognize of it not actually knowing what the problem is at all because it hadn't failed to fix it 5 times yet.
their claude code changelog 'fixed' % over time.
https://i.imgur.com/KJcem6c.png
I believe their peak month was >13k issues opened, but worth bearing in mind: "This issue has been automatically locked since it was closed and has not had any activity for 7 days.".
Some of the most capable engineers in the world high on their own supply… I have no doubt they think this is aspirational but even as I know LLMs will forever change how we code, I’m not entirely sure 30,000 PRs for a coding agent is a volume that makes any sense.
I would love to create agentic feedback loops like this but my project (and probably a lot in the software industry) are compiled. Compiling not only takes a lot of time, but we have to carry around nearly 200 GBs in toolchain dependencies, require access to license servers for 3rd party software used in the toolchain and to run the full integration test suite on the project can take hours even with parallel testing in the VM while using multiple VMs. And these VMs aren't small, 64 core/128GB. So outside of unit tests, we can't really merge code fast and test it with high confidence without spending an absolute absurd amount on VMs in order to enable the agents to move quickly.
> additive changes behind a flag
That's low risk when the flag is off. Is there suddenly proper code review before the flag gets turned on? That's when the risk is actualised.
Also, when they say "risk" - risk of what? Bugs and security incidents? What about other risks: future rework, slowdown of development, obfuscation of bugs, abstractions that will end up being made leaky to work etc. Are these all not considered because they are confident Claude can manage all of that?
So many questions
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.
What are llm freaks in such a hurry for? Its like everyone is manically racing towards a finish line without realizing the finish line is you out of a job. Its like everyone is excited to be completely obsolete and poor.
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.
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.
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.
* 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.
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.
Code quality matters to AI just as much as it did to people
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.
And if people are not looking it, those people don't care about their customers.
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 not HN-worthy
I have some bad news about that "monorepo" designation.
honestly i'm thinking it might be easier (and cheaper) to launch our own agent from GH webhooks and trigger `/code-review`..
So dbs, seed files, etc, and then just a review prompt and some skills and a few scripts.
It triggers on a new published PR or if tagged @bot-name. It's way better than the other services we've tried (which was admittedly ages ago) because you can get it to work exactly how you want it and it's dead simple.
With Codex, for the time being at least, you can use a subscription, so it's basically free if you're already paying for one. But on API pricing it's still not too bad as it doesn't produce that much output.
I set this all up in about half a day. Codex does 99% of the heavy lifting.
If an engineer paid $150,000 a year reviews some code manually for about 30 minutes, the cost of their time is about $36.
During my evals on my own 3 agents that review in parallel they are much more cost efficient and cover 75% issues. Even on model like haiku it’s better score than default. Multiple passes or raising effort will cover 90+. And this was tested on large diff, about 3500 LoC changes
It's pretty effective and lets you do nice stuff like compare the code to the tickets, reply to comments and stuff like that.
The post explicitly says they use codeowners to require a human in the loop for billing related code.
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.
Personally, I find Claude's degenerate urge to just spew uncontrollable amounts of code quite counterproductive. Yes I get it, you get paid by the token. I'd like to see more reasoning, more understanding, and less generating.
Truth is, we are still very very far from actual AI software engineering. Some people are working on useful tooling, and (predictably, like anything good and useful) it is taking a long time. LLMs are great, and hopefully they will help us accelerate building the tools that bring this profession to the next level.
30k PRs in a month (or whatever) is not the brag they make it out to be.
How is this a proper product? Every time you open the desktop app the buttons may be on a completely random place
I'm really happy with Pi agent harness and last time I checked I could do everything CC can with my set of Chinese flash model coded Pi extensions.
https://en.wikipedia.org/wiki/Crossing_the_Chasm#/media/File...
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
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.
> ...Architecture that sets a pattern others will copy...
I'm happy that even Anthropic agrees this is best left to humans.
So code review has become newspeak for “testing” and “education”?
Well not really testing. We the users are the testers and it falls to lucky us to really discover and find the errors, edge cases and security issues. The consequence of the rush to continually release…
Is the AI advance in the field of software testing nothing more than “now an AI agent can do a code review?”.
I think a lot of people like myself still want to feel in the loop but I don’t have the right tools to stay on top of the (generally good, productive, and still thoughtful) contributions from peers anymore.
How is it calibrated? Do you rank every file in the project by their criticality? Do you train a classifier? Do you base it on some heuristic like number of downstream files affected?
* They can afford frequent CC incidents since their value is having the best models, and 95%+ uptime is still OK-ish.
* The core functionality of CC (the harness "agentic loop") is simple, an if that works then for most purposes CC works.
* CC just stores a bunch of config and history files, there isn't any financial or irreversible safety loss if they mess it up once in a while.
Once you work on something where a minor slipup can result in a huge real world mess, then I don't see how their approach can work.
I used to do it but now I only review code organization and structure.
Mostly I define the product behavior I want and discuss the technical implementation beforehand.
Once that's in a spec I let it build in my durable implementation engine. Automated verification, review rounds from different agent types across different models, issues triaged into meaningful clusters and flagged for false positives before finally being fixed.
That loops until the code is up to spec.
There is no special secret, LLMs need repetition and multiple passes.
They'll one shot bigger and bigger things in their default harnesses but they'll be filled with issues no matter what.
Eventual productization will probably make that effort meaningless but hey. whatever. I'm too old to sell my ass for cash too.
They heavily use Claude for both code generation and code review of Claude's own code and related tooling. Is that not functionally Claude running recursive loops to improve the next version of Claude?
Github Repo: https://github.com/vs4vijay/prx
On the other hand, I would have expected Anthropic to have a drastically more elegant SDLC.
> THE SCARCE RESOURCE: HUMAN TIME AND ATTENTION
This workflow may not be accessible to token poor teams. Though I’m not all the way through the post, so I don’t know if token scarcity is even acknowledged.
Vibe-coding complex software can work, but it's going to take a really disciplined team to manage this properly, like in this article.
I've written a harness myself and fair enough, it's more complicated than you might expect.. but surely at this point the claude CLI is pretty stable, and this must mainly be a ridiculous amount of test churn.
Or maybe their team of clankers is just creating busy-work to make the humans think they're essential. That's not unheard of in the human behaviours that they're trained on.
A random twitter said that, 6 month ago, it was 100% !
DECLINE ! SELL THE STOCK OPTIONS ! (wait, there are none, confused!)
Not only that, but AI is categorically terrible at ux review. I don’t mean aesthetics, I mean attention flow, workflow in general and what the user anticipates as a logical path to feature discovery and exploration. Increasingly, features are hidden behind workflows that meet a single use case but fail to be universally logical or in many cases, even accessible at all outside of the test case.
So, people… use AI in code review. It’s actually pretty great at it if you do it right, and you can ship better software with fewer bugs than ever before. But please, don’t pressure your ux guy to “10x” with AI. In fact, now that you are “10x”ing your development cycle, you are probably going to need to hire -more- ux developers if you don’t want your product to feel like slop even if it’s gold under the hood.
Honestly not sure that there are that many effective changes a day given how little complexity there is to their public facing product.
good model
I vibe coded my harness that is superior to CC in functionality, and it still doesn't flicker.
I don't need to hear their bullshit.
Anyway, flagging as misinformation.
Over the last few years we have added mcp tools, memory graph, md files and skills, automated everything to the point that on desktop the system runs itself, besides proceed/approved/explain.
We have 100's of PRs/jobs/projects and Claude builds down the list automated and only asks a few questions point form if needed.
Very impressive now, compared to 6 months ago.
You can view it if interested: www.vekmem.com