2026-04-03 12:28:34
Written as part of the Inkhaven Residency program.
As previously mentioned, research feedback I give to more junior research collaborators tends to fall into one of three categories:
In each case, I think the advice can be taken to an extreme I no longer endorse. Accordingly, I’ve tried to spell out the degree to which you should implement the advice, as well as what “taking it too far” might look like.
I talked about doing quick sanity checks in a previous piece. Here, I talk about the second piece of advice: saying precisely what you want to say.
The second most common feedback is that you should write down precisely what you want to express.
One of the most common interactions I have with junior researchers goes as follows: I read a draft section of their research writeup. This often consists of many paragraphs detailing various seemingly disconnected ideas, as well as 5-10 different figures. I’m confused about what the point of the section is. I ask them what exactly they’re trying to say in the section. They give me a very cogent and concise statement of what the takeaways should be. I suggest that they should write that down, and include it prominently somewhere in that section.
Sometimes, the problem is that people don’t know what point they’re trying to make. But maybe around half the time, the people I talk to already know what they want to say with a section of text – they just haven’t said the point anywhere in the section!
The advice here is simple: figure out what point you’re trying to make, and feature it prominently. As an example, if your blog post’s main claim is that AI models can be dangerous before public deployment, then consider titling it something like “AI models can be dangerous before public deployment”, or, at the very least, saying that clearly and in as many words in the introduction.
The converse of this is that you should not include text that distracts from what you want to say (or at least, relegate it to footnotes, the appendices, or parentheticals). It’s always tempting to add more to a piece, and almost always hard to cut (hence the common quip about not having time to write a shorter piece).
Both the advice and its converse apply to figures as well: In terms of saying what you want to say, the easy fix is often to highlight relevant parts of your figure in your caption. Better yet is to highlight your claim in the figure itself: for example, if your claim is that longer chains of thought are more monitorable, then consider including a regression plot with chain-of-thought-length on the x axis and monitorability on the y axis.

If your claim is that vaccines are effective at reducing the incidence of measles then consider making a heatmap of measles cases over time, with the date the vaccine was introduced clearly delineated. This figure is from the WSJ article “Battling Infectious Diseases in the 20th Century: The Impact of Vaccines”, though I first saw this example in Edward Tufte’s book Seeing with Fresh Eyes: Meaning, Space, Data, Truth.[1]
In terms of not including unnecessary content, the first step is to avoid what Edward Tufte calls “chartjunk”: visual elements in charts and graphs that are not necessary to comprehend the information represented on the graph, or that distract the viewer from this information. The second, more difficult step, is to cut back on unnecessary information. For example, you might average the performance of an AI model across tasks, instead of including one data point per task.

Left: An example of a figure with substantial amounts of chartjunk, including unnecessary shadows, redundant text, and an unnecessary legend. Right: the same figure without said chartjunk. This example was originally Darkhorse analytics, though you can find an open-source recreation at this Github repo.
Information denseness is okay, as long as the key claims can still be read off from the figure (or if the information is included in a separate figure).
Taking this too far. Unfortunately, what is necessary and what is extraneous junk is often a matter of judgment, and it’s easy to take this advice too far.
In terms of prose, your key claim can often require substantial amounts of additional context to understand: if you find that people can not understand your main claim, or that there are obvious follow up questions that you haven’t answered, consider adding the additional context back. Even pure redundancy can serve a purpose: audience members are often skimming your work or reading it in chunks, and so any point you really want them to remember should be integrated into different parts of the piece.
For figures, the extreme version of “removing unnecessary content” is to end up with a figure that has no argument and is basically an assertion. Classic examples of this are the content-free figures often found in business PowerPoints – while these figures often have some hallmarks of a data-backed figure, they are not produced based on real data and do not contain enough content to justify the real estate they take. If you find that the entirety of the content of your figure can be summarized in a single sentence, you’ve probably cut too much content (or are better off just saying the sentence in prose, perhaps over a different figure!).

Masayoshi Son attempts to use a hypothetical earnings trajectory (not based on real data, nor even grounded with a y-axis) for WeWork to justify Softbank’s investment in the company, which at the time had lost SoftBank billions of dollars. Source.
As an aside, I think that using color as the third dimension generally produces more readable graphics, i.e., heatmaps are often superior to 3d charts.
2026-04-03 12:14:53
This year's Spring ACX Meetup everywhere in Massapequa.
Location: 47 Clinton PL., Massapequa, NY 11758 - https://plus.codes/87G8MG4G+53
Please rsvp to gabeaweil at gmail dot com so I know how many people to expect.
Contact: [email protected]
2026-04-03 12:14:50
This year's Spring ACX Meetup everywhere in Charlotte.
Location: Cordelia Park (or nearby cafe The Hobbyist or nearby food hall Optimist Hall if raining/cold/etc.) - https://plus.codes/867X65PM+W3
Contact: [email protected]
2026-04-03 10:40:28
Open source components are getting compromised a lot more often. I did some counting, with a combination of searching, memory, and AI assistance, and we had two in 2026-Q1 ( trivy, axios), after four in 2025 ( shai-hulud, glassworm, nx, tj-actions), and very few historically [1]:
Earlier attacks were generally compromises of single projects, but some time around Shai-Hulud in 2025-11 there started to be a lot more ecosystem propagation. Things like the Trivy compromise leading to the LiteLLM compromise and (likely, since it was three days later and by the same attackers) Telnyx. I only counted the first compromise in chain in the chart, but if we counted each one the increase would be much more dramatic. Similarly, I only counted glassworm for 2025, when it came out, but it's still going.
In January I told a friend something like: "I'm surprised we're not seeing more AI-enabled cyberattacks. It seems like AIs have gotten to the point that they'd really be helping bad actors here, but it all still feels pretty normal and I don't understand why." While it's always hard to call the departure of an exponential from a noisy baseline, if this is AI helping with attacks we should expect this rate of increase to continue.
Other data points that have me expecting security to get worse before it gets better:
Linux is seeing a large increase in real security reports:
We were between 2 and 3 per week maybe two years ago, then reached probably 10 a week over the last year with the only difference being only AI slop, and now since the beginning of the year we're around 5-10 per day depending on the days (fridays and tuesdays seem the worst). Now most of these reports are correct, to the point that we had to bring in more maintainers to help us.We're seeing the defender side, but attackers can use the same tooling.
Claude Opus 4.6 seems to be actually good at finding and exploiting holes:
When we pointed Opus 4.6 at some of the most well-tested codebases (projects that have had fuzzers running against them for years, accumulating millions of hours of CPU time), Opus 4.6 found high-severity vulnerabilities, some that had gone undetected for decades.
AI agents eagerly pull in unvetted dependencies if they seem like they'd solve the problem at hand, and while humans do this too the agents massively speed up this process.
But I do think it will get better: while I'm not an expert here, I see many factors that favor defenders:
I think it's pretty likely that security bugs in major software are for the first time being identified faster than they're being written.
Checking package updates for vulnerabilities was never something most people did, but automated systems could plausibly do it well.
Most programmers are pretty terrible reviewing code in enough detail to notice something underhanded, but LLMs excel at this kind of attention to detail.
Developer education is hard, model education is much less so. I remember how long it took for SQL injections to go from a known attack to something most programmers knew not to do; it's way easier to keep LLMs from doing this.
Dependency cooldowns are very simple, but would help a lot.
Migration to more robust systems is more automatable. Automated conversion from C to Rust, switching to TrustedTypes, etc.
I wish defenders in biology had the same structural advantages!
[1] Here's my attempt at earlier years, all with a bar of "compromise
of a widely used open-source trust path that forced action well beyond
the directly compromised maintainer or project":
2026-04-03 09:47:50
(This is a light edit of a real-time conversation me and Victors had. The topic of consciousness and whether it was the right frame at all often came up when talking together, and we wanted to document all the frequent talking points we had about it, so we attempted in this conversation as best we could to cover all the different points we had before)
2026-04-03 09:00:39
I am dumb. I regularly perform actions I don't endorse, and these sometimes end up working out badly. Just yesterday, I spent half of the day carefully avoiding writing my first Inkhaven daily post, despite this being necessary for my continued existence in America (aside from the evident embarrassment of being the very first person to get kicked out of the program). My brain knows that this avoidance is bad, but procrastinates anyway, and apparently this is a perfectly normal thing to have happen.
This seems like a strange state of affairs, but I think it can practically be solved (at least somewhat) by thinking differently about what we mean when we say "I know X". In "Thinking, Fast and Slow", a book I have not read, Nobel prize winner Daniel Kahneman apparently talks about our brains having 2 systems, system 1 and system 2 (which seems like an eminently sensible way to name them). System 1 is fast and intuitive, it does things like walking, catching balls and basic arithmetic like 2+2. Just about anything you don't have to think about is system 1. The main reason is that anything you do think about is system 2. Calculus, which socks to put on this morning and hiding their holes are all system 2.
For the purpose of this article, I will be using a categorisation which is fairly similar. I am going to call anything which you need to think explicitly your "conscious mind" and anything you don't your "subconscious". I hope the psychology nerds in the comments find this acceptable.
In any case, with this framing in mind, the question of whether you know something becomes ambiguous: does "you" refer to your conscious, your subconscious or both together? Hmm. Seems like we have our concepts muddled. Yesterday I knew I should write, but didn't. When I look at a large chocolate bunny on Easter Sunday, I know I shouldn't eat the entire thing in one sitting, but do. When I see a bottle of vodka on the shelf, I know I shouldn't down it in one, but...
In each of these situations, the things I am driven to do by my unthinking subconscious are different from the carefully thought-out actions my conscious mind gives me. I think these are all situations where saying "I know I shouldn't do this" muddies the water. Sure, "you" know, if you restrict "you" to the part of you which thinks thoughts out loud in your mind. The rest of you just wants to eat chocolate.
And this is fine. You have 2 systems of thought, and they do different jobs, but your system 1 is trained by your system 2, and you need to think about them separately if you want the training process to go well. I find the best way to go about this is to treat your subconscious like a dog: when you do good things like go on a run, eat healthy food or successfully roll out of bed, give your brain a treat. How do you give your brain a treat you ask? Celebrate! Give a little fist pump, a little yes I did it. This will train your subconscious to do the things you want it to, and be a good boy.
When your dog does something bad, you don't treat this as you having done something wrong - dogs are going to go for a swim in a muddy puddle from time to time. You can decrease the frequency with training, but the point is that it's fundamentally a training thing, and you should be thinking about trying to get the incentives right to convince him to rinse off properly rather than rub the mud on the sofa.
Dogs recognise locations. If you regularly go for a walk in a particular spot, he gets ready for walkies. Hanging around by the treat tin gets him salivating. Hanging out around the vet's makes him nervous. Going for a walk every day at 6am means he'll be ready to walk at 6am, and feeding him at 7am means he'll be hungry at 7am.
Telling your dog how to jump through a hoop is entirely ineffective. You need to show him how to do it in small steps until he appreciates that these steps will get him a treat. Don't give him a treat tomorrow, give him a treat immediately after he goes through the hoop. Dogs have short memories. Obey these tips and treat your dog well and he will be a good boy.
And a good boy will treat you well back.