I don't think we actually disagree here. I also think it is valuable, but it's also what often makes it difficult.

> The biggest value of doing code reviews is in ensuring maintainability of the code (1. someone else can understand it, 2. it is readable and 3. can be evolved in the future) — everything else is downstream from that.

Agree very much with that (with the slight caveat that it is not always the biggest value, just an important one).

I also agree that merge requests should be short and understandable in 10 minutes, but IME this happy state often does not obtain in practice. It shouldn't, but it often does, whether it's mission creep, whether it's turning out that a change is more complex than originally imagined, or whether it is unavoidably complex and cannot be broken down further.

I actually dislike traditional code review. In part this is because most of our code review tools are very cumbersome to use (GitHub's and GitLab's web interfaces in particular).

But also because humans aren't all that great at code review when it comes to correctness and security. Part of the problem is that you don't have access to the author's mental model for non-trivial changes and have to reconstruct it, otherwise your understanding of the program logic will be inadequate.

The problem is that purely agentic code review has orthogonal problems, and typically remains subpar when it comes to judging architecture and design considerations, compared to human reviewers. Both false positives and false negatives also remain a concern.

My best results so far have been with agent-assisted code review in a proper IDE, helping you to quickly construct a mental model and to analyze the underlying logic (in addition to having agents do a first pass for correctness issues).

I personally have had good success with using agents as virtual pair programmers following some simple rules for how to make that process productive, but that is a very, very different approach. One that recognizes that both humans and agents are prone to errors and attempts to mitigate the problem rather than expecting it will magically work out through the power of AI.

If you want to go all the way, a fully formalized specification is not less work than writing the software, though the potential promise of LLMs for formal methods is interesting.

But for any informal specs, no matter how detailed, while LLMs can be very capable when it comes to avoiding surface errors when translating them into code (e.g. they're more likely than human programmers to write code that compiles on first try), they still don't have a mental model, and most of the problems I've seen are IMO results of that and they increase with the scale of the project.

Really? That's not my experience. In fact, I've experimented quite a bit with spec-driven design where the LLM does not just get a prompt, but an (informal) spec, often with design considerations included. And yet, regardless of the power of the model, I've never seen them autonomously deliver what I'd consider a finished product.

There are always edge cases that are not properly taken into account, architectural oopsies, performance issues, duplicated code, and other problems, that then need to be identified and fixed, unless it's throwaway software (e.g. a one-off script or some quick experiment).

This is not to say that agents aren't extremely powerful (as I think they are, they do often blow my mind) but the prompt-and-forget approach is IME not a productive use of them for software that is meant to last. This may change in the future, but for now, fully or largely autonomous agentic work does not seem to be the road to quality.

Anthropic is a different story, but I think it may still be possible via the Claude ACP agent (JetBrains' support of ACP is generally pretty good; I use it with anothe harness for open weight models regularly).

While this is trivially true, the question is if these remaining use cases that separate frontier models from non-frontier models bring in enough revenue to offset the massive spending of the frontier labs.

The European Council does nominate the candidate and infamously in 2019 overrode the informally agreed on spitzenkandidaten process, by which the nominee of the political group (EU Parliament equivalent of parties) with the most seats should have gotten the nomination.

That said, the EU Parliament is not bound by the nomination. It can very obviously reject any candidate it doesn't like, though of course the dynamics of candidate selection are heavily influenced by the European Council's nomination power.

But yes, there's nothing per se undemocratic about it and I'm a bit bewildered by people asking for direct election of the President rather than cleaning up the existing process, given that most EU member states elect their heads of government indirectly.

1. Identifying the cause of poor performance. 2. Implementation. 3. Architectural impact (performance is a classic case of a cross-cutting concern)

(I am specifically leaving out the case of realtime systems, hard or soft, where additional factors come into play.)

But the article seems to focus entirely on the second aspect, while largely ignoring the other two.

Most performance bugs are not difficult to fix [1, 2], but can sometimes be hard to identify. Implementation effort is not the driving limitation in those cases.

Conversely, other performance improvements may affect the overall design, e.g. 27% of all bugs identified in [3].

Having an obvious, self-contained optimization target with a benchmark where algorithmic optimization within a module is also the key problem seems to be the exception, not the rule.

Also, not all performance issues are created equal. Many have trivial cost.

In contrast, some of the most challenging performance issues are the ones that affect the design and architecture of the system. After all, the hard part of software engineering is not writing a small, self-contained application. It's managing system complexity, while maintaining (in the words of Fred Brooks) conceptual integrity. Fixing performance issues is at least in this regard not fundamentally different from fixing other software defects.

Unfortunately, this is an area that is also full of trade-offs, such as performance vs. architectural simplicity, or performance in one part of the system vs. performance in another part, all of which requires judgement.

For example, you may need to bypass an abstraction boundary or reorganize abstraction boundaries to improve performance. Or you may have to special-case something while keeping duplicated code at a minimum and easy to maintain.

This is not to say that agents cannot help here, too. In fact, agents can be very helpful at e.g. identifying bottlenecks that are not directly visible in a profiler or can be used quickly do comparative evaluations of the various options for an architectural change. But solving these issues is not, like with the regex example in the article, about hillclimbing towards better performance, but involves a combination of puzzle-solving and design skill, IMHO.

And finally, even a self-contained algorithmic improvement may come with an increased maintenance burden, especially around edge cases and through increased code complexity.

[1] Jin, Guoliang & Song, Linhai & Shi, Xiaoming & Scherpelz, Joel & Lu, Shan. (2012). Understanding and Detecting Real-World Performance Bugs. Sigplan Notices - SIGPLAN. 47. 10.1145/2345156.2254075.

[2] Selakovic, Marija & Pradel, Michael. (2016). Performance issues and optimizations in JavaScript: an empirical study. 61-72. 10.1145/2884781.2884829.

[3] Zhao, Yutong & Xiao, Lu & Bondi, André & Chen, Bihuan & Liu, Yang. (2023). A Large-Scale Empirical Study of Real-Life Performance Issues in Open Source Projects. IEEE Transactions on Software Engineering. 49. 924-946. 10.1109/TSE.2022.3167628.

Not necessarily. Even near the frontier, we don't really have a total ordering of capabilities, but a partial order. And even frontier models make plenty of mistakes. Combined with the randomness inherent in searching large codebases for vulnerabilities or correctness issues, it is entirely plausible that even much weaker models (and GLM-5.2 isn't even weak) can stumble upon issues that stronger models missed.

My current hypothesis – for which I have only limited evidence, unfortunately – is that it is better to have multiple reasonably powerful (but not necessarily frontier) models looking for issues than just one very powerful one. And even then you're likely to miss out on some issues.

You have to consider that having an LLM scan for vulnerabilities is hardly infallible. It is a search guided by heuristics and given a large enough codebase, it is unlikely to identify all vulnerabilities.

Personally, I've had Fable 5, GPT 5.6 Sol, and GLM 5.2 all looking for correctness issues in an old abandoned WIP codebase of mine and all of them found some that the others hadn't discovered. Now, correctness issues aren't the same as vulnerabilities, but the same principle about using heuristics to find defects applies.

"(1) It is prohibited to possess, manufacture, make available on the market, import, or otherwise bring within the territory to which this Act applies, telecommunications equipment that, by its appearance, purports to be another object or is disguised as an object of everyday use and that, because of these circumstances or because of the way it functions, is particularly suited and intended to intercept, without that person’s knowledge, the non-publicly spoken words of another person or to record images of another person without that person’s knowledge."

IANAL, but this sounds like it's directly applicable.

Violations can be punished with up to two years in prison or a fine.

[1] https://www.gesetze-im-internet.de/ttdsg/__8.html

What makes this analysis tricky is disposable vs. discretionary income. The US clearly comes out on top when it comes to disposable income (labour is taxed too much in Germany compared to capital income and wealth).

The picture gets more complicated when you look at discretionary income, which also accounts for regular bills, such as rent, college tuition, out of pocket expenses for health care, childcare, and such. All the taxes you pay in Germany do also pay for something, after all. There is unfortunately very little data for this type of comparison.

I used to think that also, probably because FAANG salaries had skewed my perception, but after looking at the data, this does not seem to be actually true, at least not in general.

For example, Germany has a somewhat higher annual median gross salary for full-time employees than the US (PPP-adjusted, BLS/DESTATIS salary data, OECD PPP values).

Of course, this is the median salary. America absolutely offers higher salaries at the top end (and I mean much higher, often by a factor of 2-3 for highly qualified professionals, such as software engineers and doctors). But that also means correspondingly lower salaries at the low end. And of course, labor is taxed heavily in Germany, so discretionary/disposable income may look different in the end on a case-by-case basis.

It is still very worrying and the unfortunate result of a lot of things going wrong at the cabinet level.