haglin

> AI rarely seems to write better code than humans.

That's my experience as well.

AI does a decent job of reviewing and finding bugs, but it has no concept of what makes code good or bad - too much state, convoluted logic, no invariants, unnecessary methods, poorly defined abstractions, not relying on fail-fast etc.

It's similar to work from a junior developer with little experience maintaining code over a longer period of time.

If you want to describe the limitations of today’s LLMs, "frozen brains" might be a better metaphor than "stochastic parrots". They can’t learn continuously as we do, which makes it hard for them to invent entirely new concepts - like calculus.

I work on OpenJDK, so I may be biased, but I’ve also found that JFR works really well with LLMs.

  $ java -XX:StartFlightRecording:maxsize=10M,filename=dump.jfr -jar app.jar

  $ jfr view all-views dump.jfr > report.txt

  $ jfr print dump.jfr > all.txt

Then ask Codex, or whatever AI tool you use, to analyze report.txt for issues and use all.txt to dig deeper, if needed.

I find inheritance works best when you model things that don't exist in reality, but only as software concepts, for example, an AbstractList, Buffer or GUI component.

It would be in the "Files changed" section on GitHub, not in the git history. If you don't want to see the context, you can turn it off.

Splitting up a PR is a lot of work, especially if you want each commit to compile, but it would be great if you could categorize changes using 5–10 colors and then have checkboxes that you can toggle to hide code corresponding to a color.

What each color means would depend on the PR, but, for instance, yellow = refactoring, brown = test code, blue = drive-by fix, orange = more efficient data structure etc.

The colors and their meanings could be set by either the author or the reviewers. It would be similar to the file checkboxes that exist today, but in this case, it would be per concept, not per file.

JFR only samples running Java methods.

I would guess at least some of the bottlenecks are in hardware, the operating system or in native code (including the JVM) in this case.

"Left unquestioned, assumptions and expectations could have caused us to miss one of the most impactful changes we’ve made to our operational defaults in a decade"

Two years it too short.

The reason I now use gmail and not hotmail is because Microsoft did a similar thing 20 years ago. When I lost my hotmail account, I thought I might as well use gmail from now on. Reason I didn't log into my hotmail account was because I used the mail address I got from the university.

An alternative to avoid safepoints (only samples executing threads)

    var r = new RecordingStream();
    r.enable("jdk.ExecutionSample").withStackTrace().withPeriod(Duration.ofMillis(1));
    r.onEvent("jdk.ExecutionSample", e -> {
        store.addSample(e.getStackTrace().getFrames());
    });   
    r.startAsync();
    ...

There are multiple ways to represent an optional value, for example:

1) an empty list/array 2) throw an exception if the return value is missing. 3) -1

Optional can be used as a better alternative in all these cases. It's not just null.