I disagree. Assuming code complexity is roughly fixed, more sophisticated code analysis will result in a smaller surface area for bugs. Bugs will still be found, but there will be less bugs to be found and less opportunities to exploit.
I'd expect the bigger shift to be toward secure-by-construction building blocks: less custom code that needs to be audited from scratch, and more hardened or verified components where common bug classes are already designed out.
I disagree. I routinely hit the 5 hour limit on Pro with Opus 4.7 just trying to have it do one design task or comprehensive code review on a large PR, and the worst part is, the overhead and bringing all that context back into another 5 hour window blows through 30%+ of my 5 hour usage limit.
Claude absolutely improves code review quality, but it still misses a lot. It's a second pair of eyes, it doesn't replace/remove the work you have to put in to fully review the code yourself.
It's like saying that you code reviewed faster just because someone else also reviewed the code, that's not how it works.
Agree, and with CC my volume and quality of PR review has substantially increased since 4.5. Without CC for review we would have a ridiculous bottleneck in our dev/qa pipeline.
Yes, and it is extremely expensive. This is a well-known design problem in database engines.
The computational cost of context-switching threads at yield points is often many times higher than the actual workload executed between yield points. To address this you either need fewer yield points, which reduces concurrency, or you need to greatly reduce the cost of yielding. An async architecture reduces the cost of yielding by multiple orders of magnitude relative to threads.
> The computational cost of context-switching threads at yield points is often many times higher than the actual workload executed between yield points.
I would they this often is 1% of cases. As for Rust ecosystem, it doesn't make much case to add so much complexity and inconvenient abstractions to cover 1% of use-cases.
It approaches 100% of cases for systems that care about software performance, since software performance is bandwidth bound. If almost everyone agrees that software performance is optimally fast already then I agree with you.
The vast, vast majority of programmers are going to be writing software where there are only a handful of threads (if that). The "I need thousands of concurrent executions" case is simply not relevant to most people.
Do lots of deep research and code reviews on large legacy codebases. I've created lots of documentation to reduce token consumption but it's still a lot of token consumption.
Lately I've been using claude mainly to design plans and do code reviews while Codex does all the implementation. Having two very different models helps to work out any weird quirks one might have.
It's more accurate to say that RAG is alive and well and is just incorporated into the agent's responsibility, it's just one more tool that it can call on instead of the user manually doing it.
reply