Feed

I expect that the following is going to get worse before it gets better.

Many of us got hit by the agent coding addiction. It feels good, we barely sleep, we build amazing things. Every once in a while that interaction involves other humans, and all of a sudden we get a reality check that maybe we overdid it. The most obvious example of this is the massive degradation of quality of issue reports and pull requests. As a maintainer many PRs now look like an insult to one's time, but when one pushes back, the other person does not see what they did wrong. They thought they helped and contributed and get agitated when you close it down.

I often feel like this as well. I think however that the truth is that what we now consider code quality isn't as important as we think it is.

Or maybe some of us are genuinely losing the plot, and we won't know which camp we're in until we look back. All I know is that when I watch someone at 3am, running their tenth parallel agent session, telling me they've never been more productive — in that moment I don't see productivity. I see someone who might need to step away from the machine for a bit. And I wonder how often that someone is me.

I'm more worried about the need to step away from the computer. Not because of the code quality issue but more from the addiction part of it. So far there is always some new feature, some new tool or some new idea. The kind of thought process it takes to dream up what to do is less daunting than writing the code by hand. I personally have to make myself stop. I don't really get worn out working this way. I get sleepy.

1994: The web browser Netscape Navigator introduces encrypted HTTPS (HTTP over SSL) protocol that shows a warning when used, so people can make an informed decision to be secure or not by doing their own research.

The world is going to look a lot like Core Wars – millions of AI agents will be competing against one another in a variety of domains, ranging from cybersecurity to economics, and will be optimizing themselves in relation to achieving certain competitive criteria. The result will be sustained, broad evolution of AI systems and the software harnesses and tooling they use to get stuff done. This means that along with human developers and potential AI-designed improvements, we'll also see AI systems improve from this kind of broad competitive pressure.

Jobs go away, but humans don't: Another way to put this is, when a task gets automated it's not like the company in question suddenly fires all the people doing that job. Consider ATMs and banking – yes, the 'job' of doling out cash rapidly transitioned from people to machines, but it's not like the company fired all tellers – rather, the companies and the tellers transitioned the work to something else: "Under a separable task model, this [widespread deployment of ATMs doing cash-handling tasks] should have produced sharp displacement," they write. "Yet teller employment did not collapse; rather, the occupation shifted toward "relationship banking" and higher-value customer interaction".

This is the way. I've been doing something similar with my homelab. I built an entire documenation repo that does nothing but tell the clanker how to manage my homelab.

Don't try this at home... er actually only try this at home.

Skills solve this problem. They are instructions that the AI decides when to use, and they contain not just prompts, but also the sets of tools the AI needs to accomplish a task. Does it need to know how to build a great website? It loads up the Website Creator Skill which explains how to build a website and the tools to use when doing it. Does it need to build an Excel spreadsheet? It loads the Excel skill with its own instructions and tools. To make another movie reference, it is like when Neo in the Matrix gets martial arts instructions uploaded to his head and acquires a new skill: "I know kung fu." Skills can let an AI cover an entire process by swapping out knowledge as needed. For example, Jesse Vincent released an interesting free list of skills that let Claude Code handle a full software development process, picking up skills as needed, starting with brainstorming and planning before progressing all the way to testing code. Skill creation is technically very easy, it is done in plain language, and the AI can actually help you create them (more on this in a bit).

Why is verification so important? Because, if you tell an agent to do something that it can't independently verify, then—just like a human developer—the best they can do is guess. And because agents work really fast, each action based on a guess is quickly succeeded by an even more tenuous guess. And then a guess of a guess of a guess, and so on. Very often, when I return to my desk after 30 minutes and find that an agent made a huge mess of the code, I come to realize that the AI didn't suddenly "get dumb," but rather that an application server crashed or a web browser stopped responding and the agent was forced to code speculatively and defensively.

This gives me an eerie feeling. In most movies where the world ends there’s a bit at the beginning of the movie where one or two people point out that something bad is going to happen – an asteroid is about to hit the planet, a robot has been sent back in time to kill them, a virus is extremely contagious and dangerous and must be stamped out – and typically people will disbelieve them until either it’s a) too late, or b) almost too late. Reading papers by scientists about AI safety feels a lot like this these days. Though perhaps the difference with this movie is rather than it being one or two fringe characters warning about what is coming it’s now a community of hundreds of highly accomplished scientists, including Turing Award and Nobel Prize winners.

Today, in-context learning is a standard trick in any context engineer’s toolkit. Provide a few examples illustrating what you want back, given an input, and trickier tasks tend to get more reliable. They’re especially helpful when we need to induce a specific format or style or convey a pattern that’s difficult to explain1.

When you’re not providing examples, you’re relying on the model’s inherent knowledge base and weights to accomplish your task. We sometimes call this “zero-shot prompting” (as opposed to few shot2) or “instruction-only prompting”.

You can’t rely on vibes to understand these patterns, and you can’t rely on general benchmarks to reveal them. You need to systematically test your AI on the actual work it will do and the actual judgments it will make. Create realistic scenarios that reflect your use cases. Run them multiple times to see the patterns and take the time for experts to assess the results. Compare models head-to-head on tasks that matter to you. It’s the difference between knowing “this model scored 85% on MMLU” and knowing “this model is more accurate at our financial analysis tasks but more conservative in its risk assessments.” And you are going to need to be able to do this multiple times a year, as new models come out and need evaluation.

Personhood basically comes down to the ability to blame and sanction someone – or some thing – for causing physical or economic damage. AI systems, while they are going to be often operated by and on behalf of people, may also need to be treated as distinct entities for the simple reason that as people build and deploy AI agents, the chain of custody between a person and their agent could become very hard to suss out.