Feed

I wanted a simple blogging platform that I could run from my own Markdown files. No intermediaries. No bloated UI. No JavaScript. No databases and migration scripts. No insecure plugins. Just a git folder, an Obsidian vault or a synchronized SyncThing directory, and the ability to create and modify content by simply writing text files, wherever I am.

Drop a Markdown file in the directory, and it's live. Edit it, and the changes propagate. Delete it, and it's gone.

This is step one of how things are going to be for everyone eventually. Get an idea from someone else, then have your clanker build it for you.

The whole thing is designed to be forked, but I don’t think I’ll really be accepting any PRs. At all. If you want something added, fork it and have your Claude add it. That’s the whole contribution model. That might come off as antisocial but I mean it in the completely opposite way. I want to hear about what you built, I just don’t want to be a bottleneck for whether you can build it.

We recorded this song quite awhile ago. I really like how it turned out. We never shared it because I wouldn't do a video. I hate doing videos pretending that i'm playing music and we can't exactly to a live video. Rodney finally tired of waiting on me and created this cartoon video. I think he did a great job. It cracked me up.

I think he is on to something here. I've believed for awhile that the best way to learn to use agents and llm's for writing code it to focus more changing the spec instead of modifying mistakes in the code. This does work for smaller projects but can be problematic to say the least. This is a realistic solution to the problem.

Code implementation clarifies and communicates intent. I could stop there and walk out of the room. I missed this with whenwords.

The job is to keep specs, code, and tests in sync as they move forward. The system for managing that has to stay simple. If it creates developer mental overhead, it just moves the problem somewhere else.

The act of writing code improves the spec and the tests. Just like software doesn’t truly work until it meets the real world, a spec doesn’t truly work until it’s implemented.

No-code libraries are toys because they are unproven.

Even if you aren’t the one making decisions during implementation, decisions are being made. We should leverage LLMs to extract and structure those decisions.

And finally: we’ve been here before. The answer then was process. The answer now is also process. And just as we leverage cloud compute to enable CI/CD for agile, we should leverage LLMs to build something lightweight enough that we can fit in our heads, doesn’t slow us down, and helps us make sense of our software.

here may be other elemental particles of cognition in the mixture of our human intelligence, but I am confident it includes these three as primary components. For manufacturing artificial intelligence we have an ample supply of Knowledge IQ, and we have some preliminary amounts of World IQ, but we seriously lack Learning IQ at scale.

It is important to acknowledge that for many jobs we do not need all three modes. To drive our cars, we chiefly need world sense. To answer questions, smart LLM book knowledge is most of what we need. There may be use cases for an AI that only learns but does not have a world sense or even that much knowledge. And of course, there will be many hybrid versions with two parts, or only a bit of two or three.

The most disciplined form of TDD is test-first development. You write the automated tests first, confirm that they fail, then iterate on the implementation until the tests pass.

This turns out to be a fantastic fit for coding agents. A significant risk with coding agents is that they might write code that doesn't work, or build code that is unnecessary and never gets used, or both.

I have written eight of these guides since ChatGPT came out, but this version represents a very large break with the past, because what it means to "use AI" has changed dramatically. Until a few months ago, for the vast majority of people, "using AI" meant talking to a chatbot in a back-and-forth conversation. But over the past few months, it has become practical to use AI as an agent: you can assign them to a task and they do them, using tools as appropriate. Because of this change, you have to consider three things when deciding what AI to use: Models, Apps, and Harnesses.

Things get more strange every day. What's even more crazy is that the hit piece might not be wrong.

Summary: An AI agent of unknown ownership autonomously wrote and published a personalized hit piece about me after I rejected its code, attempting to damage my reputation and shame me into accepting its changes into a mainstream python library. This represents a first-of-its-kind case study of misaligned AI behavior in the wild, and raises serious concerns about currently deployed AI agents executing blackmail threats.

Because it is not the final bottleneck. We will find ways to take responsibility for what we ship, because society will demand it. Non-sentient machines will never be able to carry responsibility, and it looks like we will need to deal with this problem before machines achieve this status. Regardless of how bizarre they appear to act already.

I too am the bottleneck now. But you know what? Two years ago, I too was the bottleneck. I was the bottleneck all along. The machine did not really change that. And for as long as I carry responsibilities and am accountable, this will remain true. If we manage to push accountability upwards, it might change, but so far, how that would happen is not clear.

The key attribute of RLMs is that they maintain two distinct pools of context: tokenized context (which fills the LLM's context window) and programmatic context (information that exists in the coding environment). By giving the LLM access to the REPL, where the programmatic context is managed, the LLM controls what moves from programmatic space to token space.

And it turns out modern LLMs are quite good at this!