I was standing in the hardware store holding a dead coin cell, squinting at it, trying to remember if the Lutron dimmer in my hallway takes a CR2032 or one of the other fourteen round silver batteries that all look exactly the same. So I guessed. I bought two of the wrong one. Classic.

Here is the thing about a house. You slowly learn a thousand tiny facts about it. The vent sizes. The filter part numbers. The spa was installed in some year you’ll never remember. The good info is scattered across manuals in a junk drawer, an email from the installer, a photo of a model plate you took and never looked at again. By the time you actually need a fact, it’s gone.

I finally fixed it. Not with an app. With a folder.

The idea I borrowed

Earlier this year Andrej Karpathy posted a little pattern he called an “LLM wiki.” Instead of the usual retrieval setup where you chop documents into chunks and stuff them in a vector database, you just keep a folder of Markdown files that the AI itself writes and maintains. The model builds the connections once, when it learns something, instead of re-deriving them every single time you ask. The internet looked at it and went “wait, it’s just a folder? why did we ever do the other thing.”

Then Google Cloud made it official. On June 12 they published the Open Knowledge Format, or OKF. It’s a tiny, vendor-neutral spec: a directory of Markdown files, one concept per file, a bit of YAML at the top, an index, links between them. No database. No SDK. Readable by a human and by any agent. That’s the whole thing.

So I pointed it at my house. The project is called Abode 101.

What I actually built

Abode 101 is an OKF folder about my home. There’s a file for the Lutron dimmer, one for the swim spa, one for the HVAC vents, one for the smoke alarms. There’s an index.md the AI reads first so it knows where to look. To use it, I don’t open an app. I just talk to it in Claude Code.

you ▸ what's the battery for the Lutron dimmer?
abode ▸ Panasonic CR2032, per the install guide (page 10).

That’s the fact I drove to the store without. Now it’s one question away, and it tells me where it got the answer.

But a folder of files just sitting there is a filing cabinet. The magic is in two things the bare spec leaves out.

Thing one: the loop

OKF standardizes the files. It says nothing about keeping them fresh. Karpathy’s original idea had the AI do the maintaining, and that’s the part I cared about most, so I built it back in as a set of playbooks.

I capture a thing by telling it “I bought X,” or by dropping a manual, a receipt, or a photo of a label into an inbox folder. It reads whatever I throw at it, pulls out the real specs, and files them. Then overnight it does the boring homework I never do. It looks up the filter I just bought, finds the replacement part, figures out how often it needs changing, and adds a reminder. I wake up and my house knows more than it did when I went to bed.

Thing two: it refuses to guess

This is the part I’m proud of. Every exact fact carries its source and a confidence level. A battery type from the manufacturer’s manual is “verified” and it gets cited. A spec from a random Amazon listing is “reported” and ranked lower. And when I ask something it doesn’t actually know, it says so.

you ▸ what size is the kitchen toe-kick vent?
abode ▸ Not recorded. It's marked TODO, needs measuring. I won't guess.

An AI that says “I don’t know” instead of inventing a confident wrong number. For house facts, where the wrong answer means a second trip to the store or a part that doesn’t fit, that refusal is the feature.

I ran a little eval suite over it to make sure. Twenty-one questions, answered cold. It got the exact facts right, with sources, and on the three questions it shouldn’t know, it refused all three. That’s the behavior I want from something I’m going to trust with my house.

Why a folder beats an app

I could have built a slick app with a database. I’m glad I didn’t. The folder is portable, it diffs in version control, it works with any model, and I own it. There’s no service to shut down, no export button I’ll go hunting for in five years. When the next better model comes out, I point it at the same folder and it just works. Try that with your smart-home app from 2014.

Get it

I open-sourced the framework. The structure, the agent instructions, the playbooks, even the eval harness are all in the repo. My actual house data stays on my machine, gitignored, because you do not need to know my spa’s gallon count. You fork it and fill it with your own home.

→ github.com/nothans/abode101

Go give your house a memory. And maybe check what battery your dimmer takes before you drive to the store. Just a thought…

He didn’t say that. He left and started building something else.

GitButler raised $17 million to rethink version control from scratch. When the person who built the cathedral starts drawing blueprints for something new, you should probably look at the blueprints.

In a recent interview with a16z, Chacon laid out the problem in terms that made me stop scrolling. GitHub was designed for humans. Specifically, for humans working at human speed. And that assumption is baked into everything.

The Pull Request Was Built for People

Here’s the deal with pull requests. They assume someone will read them.

You open a PR. A teammate gets a notification. Maybe today, maybe tomorrow. They click through, scan the diff, leave a comment or two, approve it, and you merge. The whole cycle takes hours or days. Sometimes weeks if the reviewer is busy or the PR is big enough to trigger “I’ll get to it later” energy.

This works when your team is five humans shipping a few PRs a day. It even works at scale, if the scale is more humans. GitHub handled that part beautifully. Issues, reviews, discussions, profiles, stars. The social layer that made open source collaboration feel natural.

But pull requests were never designed for a teammate that generates 200 of them before lunch.

What Happens at a Thousand PRs Per Week

Stripe merged over a thousand agent-generated pull requests in a single week. Let that number sit for a second.

A thousand PRs. In one week. From AI agents.

Now picture yourself as the human on that team. Your GitHub notification count doesn’t just go up. It becomes meaningless. The PR queue isn’t a todo list anymore. It’s a firehose pointed at your inbox.

Code review breaks first. Be honest: when you do code review, do you really read every line? Chacon asked this same question in the interview and the answer is what everyone already knows. Not always. Not even close. At a thousand PRs per week, “cursory glance” becomes “triage by title.” You’re not reviewing code. You’re reviewing your faith in the system that generated it.

Commit history breaks next. Git log becomes a wall of “fix: update component” and “refactor: apply suggestion” with no narrative thread. The story of how your codebase evolved disappears under a flood of mechanical changes. git blame points to an agent. The context that used to live in commit messages evaporates.

Notifications break last, because they were already broken. But now they’re broken at scale. The signal-to-noise ratio doesn’t degrade gracefully. It collapses.

Chacon put it simply in the interview: the whole model assumes human-speed collaboration. When you introduce participants that work at machine speed, the model doesn’t bend. It shatters.

The Pull Request Is the Wrong Unit

Here’s the question I keep coming back to: what replaces the pull request?

Not “how do we make pull requests better for agents.” That’s the wrong question. That’s like asking how to make horse-drawn carriages faster when someone just showed you an engine.

The pull request is a unit of collaboration designed around a specific workflow. One person makes changes. Another person reviews those changes. They discuss. They merge. It’s turn-based. It’s sequential. It’s fundamentally a conversation between two humans about a diff.

When the “person” making changes is twelve agents working in parallel, and they’re generating changes faster than any human can read them, the conversation model doesn’t apply. You don’t need a better conversation. You need a different unit of work.

Chacon’s answer at GitButler is interesting. They built what he calls a “mega-merge” system where multiple branches coexist in a single working directory. Agents can see what other agents are doing in real time. Conflicts surface before they happen, not after someone tries to merge.

That’s a version control answer. But the platform question is bigger. What does the server-side look like? What does collaboration look like when most of the participants aren’t human?

What the Next Platform Actually Needs

I don’t know what the next GitHub looks like. Nobody does. But I can see the shape of the requirements from here.

Real-time conflict detection, not post-merge. GitHub tells you about conflicts when you try to merge. By then, someone (or some agent) has already done the work. In a world with twelve agents writing code simultaneously, you need to know about conflicts as they form. Not after.

Agent provenance. Which agent wrote this code? What prompt generated it? What was the reasoning chain? Right now, the best you get is a commit message that says “Generated by Claude” or “Co-authored-by: Copilot.” That’s like listing “computer” as the author. You need the full trail: the intent, the context, the decision points.

Review at the intent level, not the diff level. Humans shouldn’t be reading thousand-line diffs generated by agents. They should be reviewing the intent: “I asked the agent to refactor the auth module to use JWT instead of session tokens.” Did it do that? Did it break anything? Let another agent verify the diff. The human reviews the goal.

Trust scores on commits. Not every change carries the same risk. A CSS color change and a database migration are not equal. The platform should know this. Flag the high-risk changes for human review. Let the low-risk ones flow through with automated verification.

Parallel visibility. If three agents are working on the same codebase, each one should know what the others are doing. Not through pull requests after the fact. In real time. This is what GitButler’s mega-merge is trying to solve at the local level, but it needs to exist at the platform level too.

None of this looks like a pull request queue. It looks more like air traffic control. Multiple things moving at once, a human watching the board, stepping in when something looks wrong.

The Builder’s Question

GitHub won because it made one thing simple: collaborating on code with other humans. The entire product was built around that idea. It worked brilliantly for twenty years.

The next platform will win by making a different thing simple: collaborating on code with a mixed team of humans and agents. That’s a different design problem. The social features that made GitHub great (profiles, stars, discussions, PR reviews) were designed for people who have attention spans, opinions, and feelings. Agents have none of those.

Chacon said something in the interview that stuck with me. He said the constraint isn’t “can we produce the code” anymore. It’s “can we agree on what we want.” The bottleneck moved from implementation to communication. From typing to thinking.

If that’s true, the next collaboration platform isn’t optimized for code review. It’s optimized for intent. For specification. For making sure twelve agents and three humans are all building the same thing.

I don’t know who builds it. Maybe GitButler expands into the server side. Maybe someone we haven’t heard of yet starts from scratch. Maybe GitHub pivots faster than Chacon expects.

But I’m pretty sure of one thing. When it arrives, it won’t look like a pull request queue.

It’ll look like something we don’t have a name for yet.

FlexGen is an open source collaboration among the LMSys community, Stanford, UC Berkeley, TOGETHER, and ETH Zürich.

The high computational and memory requirements of large language model (LLM) inference traditionally make it feasible only with multiple high-end accelerators. FlexGen aims to lower the resource requirements of LLM inference down to a single commodity GPU (e.g., T4, 3090) and allow flexible deployment for various hardware setups. The key technique behind FlexGen is to trade off between latency and throughput by developing techniques to increase the effective batch size.

The key features of FlexGen include:

 High-Throughput, Large-Batch Offloading
Higher-throughput generation than other offloading-based systems (e.g., Hugging Face Accelerate, DeepSpeed Zero-Inference). The key innovation is a new offloading technique that can effectively increase the batch size. This can be useful for batch inference scenarios, such as benchmarking (e.g., HELM) and data wrangling.

 Extreme Compression
Compress both the parameters and attention cache of models, such as OPT-175B, down to 4 bits with negligible accuracy loss.

 Scalability
Comes with a distributed pipeline parallelism runtime to allow scaling if more GPUs are available.

 Limitations
As an offloading-based system running on weak GPUs, FlexGen also has its limitations. The throughput of FlexGen is significantly lower than the case when you have enough powerful GPUs to hold the whole model, especially for small-batch cases. FlexGen is mostly optimized for throughput-oriented batch processing settings (e.g., classifying or extracting information from many documents in batches), on single GPUs.

Learn more by checking out the FlexGen GitHub project and read the supporting paper.

I had to make some updates for jQuery and Bootstrap. “Software” does not age well. Even a lowly app like mine sitting in a GitHub repository needs attention to make sure they work.

Here are some features of the IoT Debugger App:

• ThingSpeak Data Logger and Channel Browser
• Particle.io Webhooks Manager
• Settings are saved in LocalStorage
• Built using HTML5, Bootstrap, and jQuery

I now host a demo of the app using GitHub Pages. Even if you don’t want to download the app and run it yourself, you can just point your browser to https://nothans.github.io/iot-debugger/app/thingspeak.html and use it from there. To use the app, start by entering a channel number. If the channel is public and has data, you should start seeing data on your screen. You can try ThingSpeak channel 1417. This is the channel that stores the CheerLights colors. Use the app to explore your channel data.

Feel free to suggest new features, submit bugs, and make your own changes. That is the awesome thing about open source. We are building this together. See you on GitHub.

Features of IoT Debugger

• ThingSpeak Data Logger
• Particle.io Webhooks Manager
• Settings are saved in LocalStorage
• Built using HTML5, Bootstrap, and jQuery
• Open Source!

Demo and download the source code for IoT Debugger on GitHub.

My super simple solution for tracking server disk space is to use Windows PowerShell and ThingSpeak. I went to the trouble of releasing the code to GitHub so that you can try this out for yourself. This can be used on any Windows Server as long as you can execute PowerShell scripts. ThingSpeak gives you a place to store data from anything. In this case, I am sending my disk-free space to ThingSpeak once per day by scheduling a Windows Task.

Check out the open-source code on GitHub!