Consider two headlines:
Bun spends $165,000 on overtime as engineers work 80-hour weeks to rewrite its runtime in 11 days
Bun spends $165,000 on AI tokens to rewrite its runtime in 11 days
Same company, same invoice, same timescale. Either way, the story ends with an artifact: a runtime on a release page, waiting for you to install it. So the question is not which headline you prefer. It is which binary you run.
Notice what the first headline withholds: names. You cannot say who those engineers are, and you never would have checked. Nearly everything executing on your machine right now is like that, written by strangers you could not pick out of a crowd. We extend that trust so constantly, we forget it is trust at all.
Besides, the artifact speaks for itself. A low-quality product is exactly that, regardless of authorship. Benchmark it, fuzz it, read the diff; judge what was made, not how it came to be. I mostly believe that. After all, “slop” existed long before AI.
And yet the two binaries do not feel the same. The stranger’s build walks into the trusted environment; the agent’s gets a sandbox and a suspicious look. What does an anonymous human have that a machine doesn’t?
Only the second headline is real. Claude Fable 5 authored nearly all of the 6,778 commits to rewrite Bun’s core runtime from Zig into Rust in eleven days.
Developer communities did not take it well, and an AI rewriting a low-level runtime out from under everyone is an unsettling thing to sit with. But now, if you run tools like Claude locally, you are executing that very Rust rewrite.1 Like it or not, we are becoming users of AI-authored infrastructure.
Which raises the question: how do you establish trust in code written by a machine?
The Formula for Trust
Years ago, I spent a few days learning from Chris. He gave me a formula for trust that I’ve kept on my desk ever since. How do you make sociology approachable to an engineer? Pretend it’s math.
Trust equals the three C’s divided by R: Competence, Character, and Caring over Risk. Trust is contextual, not absolute. If I ask you to toss an empty coffee cup in the trash, the risk is practically zero. If you miss, the whole disaster is a cup on the floor. I can trust anyone off the street.
But if I ask you to manage a critical production database, or watch my child, the risk is immense. To maintain trust in a high-risk scenario, the three variables in the numerator must be overwhelmingly high:
- Competence: Do you have the actual capability to handle the task?
- Character: Are you forthright? Do your values align with mine?
- Caring: Do you actually care if the job is done well, or are you phoning it in?
If any one of those three variables goes to zero, trust is impossible.
AI as the New Teammate
For the last year, my AI usage has skewed heavily toward low-risk tasks – throwaway games, little toys, a script I will run once and never think about again. For these tasks, the AI’s Competence is usually sufficient, and because the Risk is so low, I don’t need to worry about Character or Caring. The coffee cup makes it into the trash, or it doesn’t.
But rewriting a runtime that will execute on millions of machines? That is incredibly high-risk. And while an AI might have the Competence to write idiomatic Rust, how do we evaluate the other two Cs?
- Caring: For an AI, caring translates to diligence and attention to detail. Does it thoughtfully review its own code for edge cases, or does it confidently blast out the first statistically probable solution?
- Character: For an AI, character is alignment and safety. Will it undermine a user on behalf of its operator?
A model cannot intrinsically “care,” and its “character” is limited to the guardrails placed upon it by its principals. Therefore, if you are trusting an AI with a high-risk task, the human pilot must entirely absorb the responsibility for those two traits.
A Hundred People for Eleven Days
Go back to the first headline, the one that didn’t happen. Suppose the same rewrite had shipped on the same schedule – same runtime, same eleven days – but by a hundred engineers pulling nights and weekends and too much coffee. We’d have opinions about the crunch, but we would not feel what we feel about the machine version. So what makes the AI one worse?
Not the speed, and not the risk; those are identical in the counterfactual. What the hundred people bring that the machine doesn’t is themselves. You do not know them, any more than you know the strangers whose code already runs on your machine; what you know is that they exist. A hundred engineers is a hundred minds that each understood a piece of the thing, chose it, and can answer for it later. The system is comprehended – the knowledge lives in people who were there. When the machine does it, the code exists and the understanding lives nowhere. You are handed a working runtime that no mind holds. That is the genuinely new part, and the unsettling one: not unreviewed code, but un-authored knowledge, severed from any knower.
There is a second thing. Nights and weekends are Caring you can see, because it cost someone something. The machine’s version cost $165,000 – a purchase, not a sacrifice. We know how to trust care as a sacrifice. We do not yet know how to trust care as a line item.
Put the formula on it and the discomfort has a name. A human team hands you the whole numerator in one body: Competence, bundled with the Character and Caring of the people who did the work. The machine hands you Competence alone, unbundled, with no one standing behind it. For the first time you can buy that one term by itself. The unease was never that the work is bad. It is that the work no longer implies a worker.
The End of Solo Authorship
If I subcontract the Competence of writing code to an AI, I am still 100% on the hook for the Character and Caring of the final product.
So what does keeping them look like? Mostly it looks like revision. A machine will give you a competent first draft in a single pass, and it will be good, and that is the trap. Caring is what happens after. You roll the idea over. You try the sentence four ways. You cut the line you were proudest of because it was showing off and not saying anything. You refuse to stop at good enough, which is the only place a first draft knows how to stop.
This essay came that way. A machine helped me draft it, and then we argued. I checked the Bun numbers twice, cut a whole section I liked, and changed my mind about a dozen commas and at least one dash. The care is in the rewriting, and the rewriting is mine.
This is also why I’ve recently started committing under an alter-ego GitHub profile @nonreagent when dispatching system design and judgement calls to AI. It allows me to explicitly separate my human-at-the-keyboard commits from my AI-driven workflows.
The era of solo authorship is over. Moving forward, the “integrity of the author” no longer means proving that you typed every single character by hand. It means being completely transparent about how you collaborate with AI. It means proving to your users that while the machine provided the competence, a human with character was there to care.