Incredible. Every Single Take on AI is Wrong.

For the past 6 months, I've been reading on-and-off the flurry of blog posts and articles written by very experienced software developers on AI, and the overwhelming feeling I get is, that they are all wrong.

I don't have the inclination to write a treatise countering all the things people are saying, but I do have three articles for which I want to simply document agree/disagree on the various points being made. If only to document my own beliefs, so I can check a year or so in the future and check how badly I was off.

My AI Skeptic Friends Are All Nuts

This article is divided into sections, which is very convenient.

1. level setting — agree, you have to re-evaluate because LLMs have drastically improved this year
2. the positive case — agree, this is probably the strongest argument for LLM-assisted coding
3. but you have no idea what the code is — mostly agree, you must read all the code
4. but hallucination — idiotic argument
5. but the code is shitty, like that of a junior developer — idiotic argument #2
6. but it’s bad at rust — what even is this saying? wrong.
7. but the craft — applies only in some situations, and author doesn't see that
8. but the mediocrity — same as 7
9. but it’ll never be AGI — agree
10. but they take-rr jerbs — presented annoyingly, but directionally correct. there are always more things for people to do.
11. but the plagiarism ­— offtopic, and the author should not have delved into this at all
12. positive case redux — ah now your motte becomes clear, and it's bullshit. social pressure does not an argument make.
13. but i’m tired of hearing about it — oh please just... no

Overall, garbage article. Don't read it, except maybe sections 1, 2, 3, 9.

Contra Ptacek's Terrible Article On AI

 This is a response to the previous article. As you might guess, I disagree with this one too.

1. Immediate Red Flags — disagree, over-generalizing, nit-picking
2. Trash-Tier Ethics — agree! but also tbf, copyright has nothing to do with ethics. it is not a natural law.
3. Why The Appeals To Random Friends? — too long, but yeah same argument as me
4. Is AI Getting The Right Level Of Attention? — TOO LONG, but agreed
5. These Executives Are Grifting Or Incompetent — over-generalized again, but this is true of some execs, yes
6. Killing Strawmen — agree, same argument as me stated differently
7. Why The Half-Hearted Defense Of Artists? — offtopic, i will ignore again

Overall, fine, more like a rant than anything else, and doesn't acknowledge the correct parts of the first article, which is a shame. But I guess most people on the internet write when they feel strongly about something, and that cannot lead to good analysis.

AI Mania Is Eviscerating Global Decision-Making

Same author again. Same problem of writing only when he feels strongly on a subject, and making too many generalizations. Let's <ol> again:

1. AI Investments Are Generally Total Failures — agree, although many people will correctly disagree because it does not apply to their AI investments because it generalizes too much
2. Heretics Will Be Shot — only at some high-profile large companies, again generalizing from his own experience without trying to understand the shape of his filter-bubble
3. AI Demos Are The Mind-Killer — agree on the facts, but get off your high-horse. your refusal to take money just tells me you're living in luxury and nothing else.
4. Executives, Game Theory, and The Emperor’s Clothes — good, concise, and correct. this is how every single hype cycle in big tech functions. burn this in your memory, and see it happen every decade.
5. You Must Be This AI-Native To Ride —  only applicable to big tech. this sort of dumb thinking is actually good for the rest of us. if big tech didn't have dozens of achilles' heels like this, they would be unstoppable.
6. Navigating AI Mania — obviously correct, unless some architectural change happens in LLMs that drastically improves their real-world capabilities, not just in benchmarks

Overall a good article, you should read it, and skim when it gets too verbose and makes sweeping generalizations.

I just recalled, there is a good article on AI-assisted coding that I think everyone should read. And it's this one by danluu: https://danluu.com/ai-coding/ . I generally agree with everything listed in it, with reservations around the "no code review" parts.

You might notice that I didn't talk about any articles that are frothing-at-the-mouth regarding AI (in either direction). Those people aren't worth reading at all.

Well that's all I had folks. Hope you enjoyed this. 

An Esoteric Type of Memory "Leak"

A little while ago, my colleague Sebastian started complaining about OOMs caused by Evolution taking up tens of gigabytes of memory. We discussed using sysprof to debug it, but it was too busy a time for Sebastian to set aside a few hours to do that.

Funnily enough, the most efficient fix at the time was to buy more RAM, since rust-analyzer was also causing OOM issues.

A few weeks went by. Restarting Evolution had become a daily ritual for Sebastian. 

Then, on a whim, I decided investigating this might be a good test for an LLM.

I updated my Evolution git repo, built it, and started up Claude Code in the source root. This was the only prompt I supplied: 

Find memory leaks in Evolution, current sourcedir. Particularly leaks that could accumulate over several hours. A colleague has a leak that slowly accumulates memory usage to several GB over the course of a day, requiring a restart of Evolution. That is the main focus, but we can fix other leaks in the process.

I wish I was lying, but that was all Claude Code needed to find the problem: Evolution just needed to call malloc_trim(0) from time to time.

I refused to believe it at first. I was only convinced when we saw the memory drop after running gdb -p $(pidof evolution) -batch -ex "call malloc_trim(0)" -ex detach

This seems absurd! Doesn't glibc reclaim freed memory from time to time?

Yes, it does. It calls sbrk() to do that. However, sbrk() can only reclaim free memory at the top of the heap, since it simply moves the program break downward to do so. malloc_trim(0) calls sbrk() and then also calls madvise(..., MADV_DONTNEED) on the free pages, which allows the kernel to reclaim them.

So if you have 10GB of unused memory followed by 4 bytes allocated at the top of the heap, your RSS is >10GB, even if you're using a few hundred megs. Till you call malloc_trim(0).

Note that you can only get into this situation if you have hundreds of thousands of small allocs/deallocs happening repeatedly. If your alloc is >128KB, mmap() is used for the allocation, and none of this applies.

Coincidentally, GLib's use of GSlice for GObject allocations was masking this issue in the past, but GSlice has been a no-op for some time now (for good reasons). Ideally, Evolution should not be using GObject for such ephemeral objects.

Lesson learned: if you have memory usage issues and you suspect fragmentation, try malloc_trim(0) before you go thinking about fancy allocators.