> I mean, git is just as "local-first" (a git repo is just a directory after all), and the standard git-toolchain includes a server, so...
It isn't though, Fossil integrates all the data around the code too in the "repository", so issues, wiki, documentation, notes and so on are all together, not like in git where most commonly you have those things on another platform, or you use something like `git notes` which has maybe 10% of the features of the respective Fossil feature.
Email isn't a wiki, bug tracking, documentation and all the other stuff Fossil offers as part of their core design. The point is for it to be in one place, and local-first.
> My answer to this is to often get the LLMs to do multiple rounds of code review
So I am supposed to trust the machine, that I know I cannot trust to write the initial code correctly, to somehow do the review correctly? Possibly multiple times? Without making NEW mistakes in the review process?
Sorry no sorry, but that sounds like trying to clean a dirty floor by rubbing more dirt over it.
It sounds to me like you may not have used a lot of these tools yet, because your response sounds like pushback around theoreticals.
Please try the tools (especially either Claude Code with Opus 4.5, or OpenAI Codex 5.2). Not at all saying they're perfect, but they are much better than you currently think they might be (judging by your statements).
AI code reviews are already quite good, and are only going to get better.
Why is the go-to always "you must not have used it" in lieu of the much more likely experience of having already seen and rejected first-hand the slop that it churns out? Synthetic benchmarks can rise all they want; Opus 4.5 is still completely useless at all but the most trivial F# code and, in more mainstream affairs, continues to choke even on basic ASP.NET Core configuration.
> It sounds to me like you may not have used a lot of these tools yet
And this is more and more becoming the default answer I get whenever I point out obvious flaws of LLM coding tools.
Did it occur to you that I know these flaws precisely because I work a lot with, and evaluate the performance of, LLM based coding tools? Also, we're almost 4y into the alleged "AI Boom" now. It's pretty safe to assume that almost everyone in a development capacity has spent at least some effort evaluating how these tools do. At this point, stating "you're using it wrong" is like assuming that people in 2010 didn't know which way to hold a smartphone.
Sorry no sorry, but when every criticism towards a tool elecits the response that people are not using it well, then maybe, just maybe, the flaw is not with all those people, but with the tool itself.
> Spending 4 years evaluating something that’s changing every month means almost nothing, sorry.
No need to be sorry. Because, if we accept that premise, you just countered your own argument.
If me evaluating these things for the past 4 years "means almost nothing" because they are changing sooo rapidly...then by the same logic, any experience with them also "means almost nothing". If the timeframe to get any experience with these models befor said experience becomes irelevant is as short as 90 days, then there is barely any difference between someone with experience and someone just starting out.
Meaning, under that premise, as long as I know how to code, I can evaluate these models, no matter how little I use them.
Luckily for me though, that's not the case anyway because...
> It’s about “if you last tried it more than 3 months ago,
...guessss what: I try these almost every week. It's part of my job to do so.
Implementation -> review cycles are very useful when iterating with CC. The point of the agent reviewer is not to take the place of your personal review, but to catch any low hanging fruit before you spend your valuable time reviewing.
> but to catch any low hanging fruit before you spend your valuable time reviewing.
And that would be great, if it wern't for the fact that I also have to review the reviewers review. So even for the "low hanging fruit", I need to double-check everything it does.
That is not my perspective. I don't review every review, instead use a review agent with fresh context to find as much as possible. After all automated reviews pass, I then review the final output diff. It saves a lot of back and forth, especially with a tight prompt for the review agent. Give the reviewer specific things to check and you won't see nearly as much garbage in your review.
Well, you can review its reasoning. And you can passively learn enough about, say, Rust to know if it's making a good point or not.
Or you will be challenged to define your own epistemic standard: what would it take for you to know if someone is making a good point or not?
For things you don't understand enough to review as comfortably, you can look for converging lines of conclusions across multiple reviews and then evaluate the diff between them.
I've used Claude Code a lot to help translate English to Spanish as a hobby. Not being a native Spanish speaker myself, there are cases where I don't know the nuances between two different options that otherwise seem equivalent.
Maybe I'll ask 2-3 Claude Code to compare the difference between two options in context and pitch me a recommendation, and I can drill down into their claims infinitely.
At no point do I need to go "ok I'll blindly trust this answer".
Humans do have capacity for deductive reasoning and understanding, at least. Which helps. LLMs do not. So would you trust somebody who can reason or somebody who can guess?
People work different than llms they fond things we don't and the reverse is also obviously true. As an example, a stavk ise after free was found in a large monolithic c++98 codebase at my megacorp. None of the static analyzers caught it, even after modernizing it and getting clang tidy modernize to pass, nothing found it. Asan would have found it if a unit test had covered that branch. As a human I found it but mostly because I knew there was a problem to find. An llm found and explained the bug succinctly. Having an llm be a reviewer for merge requests males a ton of sense.
LLMs have been marketed for years, with great meadia fanfare, as being almost magical, something that can do the job of software engineers. Every week, the hype is driven further.
This matters. When people get told everyday that XYZ is magic, some will believe so, and use it as if it is magic.
What's your point? Because people smoke cigarettes, people who buy unrelated things should be punished? Or because a store sells cigarettes, stores in general shouldn't be paid for what they sell? Or is the time and effort to find vulns valueless?
No, the implication that "THING" is the cause of something and therefore something needs to be done must withstand the scrutiny of "other THINGS" also causing that thing, and therefore the solution is attacking either only one cause or not the real root cause.
The fact that bad reports have to be triage doesn't change with AI. What changed is the volume, clearly. So the reasonable response is not to blame "AI" but to ask for help with the added volume.
If HN gets flooded by AI spam, is the right response shutting down HN? spam is spam whether AI does it or a dedicated and coordinated large numbers of humans do it. The problem doesn't change because of who is causing it in this case.
The change in volume was the tipping point between bug bounties being offered and devs being able to handle bad reports, and bug bounty nixed because devs no longer willing to handle the floos.
And the root cause for the change in volume is generative AI.
So yes, this is causally related.
> The problem doesn't change because of who is causing it in this case.
Wrong.
Because SCALE MATTERS. Scale is the difference between a few pebbles causing a minor inconvenience, and a landslide destroying a house.
So whatever makes the pebbles become a landslide, changed the problem. Completely.
How can you say "wrong." and then go on to say scale matters, that means scale is the problem, not who is reporting it, you contradicted yourself.
We're in agreement that it is a scale issue. When something needs to scale, you address the scale problem. Obviously the devs can't handle this volume, and I agree with that there too. Our disagreement is the response.
I guarantee that if they asked for volunteers they'll get at least 100 within a week. They can filter by previous bug triage experience and experience with C and the code base. My suggestion is to let people other than the devs triage bug reports, that will resolve the scale problem. curl devs never have to see a bug not triaged by a human they've vetted. There is also no requirement on their part to respond to a certain number of bug reports, so with or without help, they can let the stack pile up and it will still be better than nothing.
Scenario 2: US troops land and would now have to deal with some NATO soldiers.
Regardless of how many NATO soldiers we're talking about, the geopolitical stakes in S2 are orders of magnitude higher than in S1. And so is the political backlash, problems at home, reasons for other nations to respond, etc.
So yes, these few troops, being there, in an official capacity as a NATO deployment no less, matters. Alot.
> He said he had yet to find anyone who could refute this.
Which is why it's so important for people understand the Principle of Parsimony (aka. Occams Razor), and Russels Teapot.
Also, refuting it is rather easy, and doesn't even require modern technology, Henry Cavendish performed the experiment in 1797 [1]. Nothing in the experimental setup would change if all involved objects expanded.
> The mixed capitalizing based on function privacy, to me, is awful
Awful compared to ... what? `private` and `public` keywords? Ugly hacks like pythons `_` and `__`?
> it just feels very hacked together
> the wonky generics
What exactly about the generics is "wonky"? "Wonky" is not a term defined in any programming textbook I ever read. And languages are not designed on feelings, especially when the design goal is to be as pragmatic as possible, as is the case in Go.
And btw. 99% of the time tuples are used, it's as a stand-in for multiple-returns. E.g. Python does that. Go simply has...multiple returns.
> and enums,
Outside of language-enthusiasm with matching and whatnot (which more often than not is used because it looks cool rather than being useful), the most common (and again, 99%) use of enums, is to give names to magic values. Go has that covered:
type Color string
const (
RED Color = iota
GREEN
BLUE
)
> the bolted on module system
Pray tell what exactly is "bolted on" about modules? They are simply an extension of the import system, nothing more, nothing less.
> the annoying error handling
The "annoying" thing about it is that it's explicit and forced. Both of which are positives as far as I'm concerned, because I AM FREKKIN DONE with shitty 10-mile stacktraces because some joksters library threw an "exception" 400 layers down in some sub-sub-sub-sub transient dependency lib.
