Feeling this for myself has only reinforced my belief that these models constitute an addictive substance.

As I felt myself bored to tears in this process, I realized that if this is what becomes of software development, not only will it be a terrible occupation,

There's a fundamental problem with these tools beyond the capacity of any deployment strategy to solve: the tool requires expertise to validate, but its use diminishes expertise and stunts its growth

the way mistakes can compound make this a dangerous proposition. This all worked with my small project, but a bigger one, with more dependencies or more complex project structures, would likely flummox the models. And reviewing changes across a more complex codebase becomes at once more difficult and more critical as the project size increases.

Programming agents might work, but there are a lot of ways they can go wrong. The amount of guardrails necessary to keep the model in check doesn't scale. The more steps of a process rely on generative output, the higher the potential for error and catastrophic failure. Any process that involves these models must strive to maximize determinism and minimize model variance.

The help that showed up I turned to generative models not only as an experiment, but out of desperation. I had a need for code that did not exist. Nobody was going to help me build it, nor should I expect help for a project such as this. In the past, I would have cobbled together something quick-and-dirty, probably at the expense of my mental and physical health to get it done. This time, I had another option. In this limited scope, the model was beneficial to all involved: myself, TTI's community, and my family

More plainly: I have no reason to expect this technology can succeed at the same level in law, medicine, or any other highly human, highly subjective occupation.

The "works" in "it works" is scoped strictly to coding tasks. I have no evidence, and seemingly no one else does, that the same kind of success is available outside the world of highly structured language with deterministic outputs.

One time, during a security fix, the model's code introduced a non-obvious DoS vector. Well, obvious from the perspective of how the code would be deployed, but not from the code itself. That's exactly why reading each change was so important. Once the issue was pointed out, the model produced code that both addressed the security issue and avoided the DoS.

I do know the code very well by way of careful reading of the code, the relevant libraries' documentation, and the proposed changes during the code's creation. But that safety comes down to human discipline. It is entirely possible (probable?) to take the easy road and trust the model to do the right thing.

In this case, I was the audience rather than the author. I had to back my way into understanding the code, carefully reading and understanding the structure after it had been built. This is much more common for developers who work on large teams or with codebases they didn't build themselves. I have not had as much experience with that kind of development, so this all felt a little awkward.

Although I read each proposed change, knowing the codebase deeply was much more challenging. When I write a new application myself, I'm building an elaborate house of cards in my head, a gossamer structure of interlinked ideas and goals. It's a story I'm telling myself in code—and ultimately, a story I share with users.

Methodology To maximize determinism, each step of the build used test-driven development (TDD). Using the Markdown planning file as a starting point, the model generated tests for functions that would define the features, then implemented each in turn. After each coding round, cargo check and cargo test were run to confirm compilation and test passing. I reviewed every line of code the model generated. For initial drafts, very little had to change. Now to be fair, this is not a particularly complex app. It's basic CRUD app with some specialized requirements. Still, getting it all right, including auth and data handling, really mattered. After the initial drafting phase, I went through the entire app and made a list of tasks for improvement/change in the codebase. This TODO.md became the new starting point for model context in plan creation. Unexpectedly, as items were addressed in the document, the model updated the file with checkmarks and details of implementations. This was not an instruction I gave the model, but it was behavior I liked, since it created a trail of accountability. After all the features I wanted were functional, context was cleared entirely and new instructions were provided to the model. Instead of acting as a software developer, I instructed the model to perform as a security auditor and secure code expert, finding vulnerabilities in the code and recommending remediations. The findings would be written to a FINDINGS.md file, keeping with our established "Plan, Document, Execute, Log" pattern established in earlier rounds.

I've experienced this myself on some of my more ambitious vibe-code-adjacent projects. I've been experimenting with prompting entire new features into existence without reviewing their implementations and, while it works surprisingly well, I've found myself getting lost in my own projects. I no longer have a firm mental model of what they can do and how they work, which means each additional feature becomes harder to reason about, eventually leading me to lose the ability to make confident decisions about where to go next.

OpenHands: Capable but Requiring InterventionI connected my repository to OpenHands through the All Hands cloud platform. I pointed the agent at a specific issue, instructing it to follow the detailed requirements and create a pull request when complete. The conversational interface displayed the agent's reasoning as it worked through the problem, and the approach appeared logical.

When an agent doesn't deliver what you expected, the temptation is to engage in corrective dialogue — to guide the agent toward the right solution through feedback. While some agents support this interaction model, it's often more valuable to treat failures as specification bugs. Ask yourself: what information was missing that caused the agent to make incorrect decisions? What assumptions did I fail to make explicit?This approach builds your specification-writing skills rapidly. After a few iterations, you develop an intuition for what needs to be explicit, what edge cases to cover, and how to structure instructions for maximum clarity. The goal isn't perfection on the first try, but rather continuous improvement in your ability to delegate effectively.

One effective technique for creating comprehensive specifications is to use AI assistants that have full awareness of your codeba

A complete task specification goes beyond describing what needs to be done. It should encompass the entire development lifecycle for that specific task. Think of it as creating a mini project plan that an intelligent but literal agent can follow from start to finish.

we tend to underspecify because we're exploring, experimenting, and can provide immediate course corrections. We might type a quick prompt, see what the AI produces, and refine from there. This exploratory approach works when you're actively engaged

The fundamental rule for working with asynchronous agents contradicts much of modern agile thinking: create complete and precise task definitions upfront. This isn't about returning to waterfall methodologies, but rather recognizing that when you delegate to an AI agent, you need to provide all the context and guidance that you would naturally provide through conversation and iteration with a human developer.

The ecosystem of asynchronous coding agents is rapidly evolving, with each offering different integration points and capabilities:GitHub Copilot Agent: Accessible through GitHub by assigning issues to the Copilot user, with additional VS Code integrationCodex: OpenAI's hosted coding agent, available through their platform and accessible from ChatGPTOpenHands: Open-source agent available through the All Hands web app or self-hosted deploymentsJules: Google Labs product with GitHub integration capabilitiesDevin: The pioneering coding agent from Cognition that first demonstrated this paradigmCursor background agents: Embedded directly in the Cursor IDECI/CD integrations: Many command-line tools can function as asynchronous agents when integrated into GitHub Actions or continuous integration scripts

isn't just about saving time — it's about restructuring how software gets built.

several of these tasks running in parallel, each agent working independently on different parts of your codebas

why asynchronous agents deserve more attention than they currently receive, provides practical guidelines for working with them effectively, and shares real-world experience using multiple agents to refactor a production codebase.

asynchronous coding agents represent a fundamentally different — and potentially more powerful — approach to AI-augmented software development. These background agents accept complete work items, execute them independently, and return finished solutions while you focus on other tasks.

I have yet to try a local model that handles Bash tool calls reliably enough for me to trust that model to operate a coding agent on my device.

My excitement for local LLMs was very much rekindled. The problem is that the big cloud models got better too—including those open weight models that, while freely available, were far too large (100B+) to run on my laptop.

The year of programming on my phone # I wrote significantly more code on my phone this year than I did on my computer.

The year of vibe coding # In a tweet in February Andrej Karpathy coined the term “vibe coding”, with an unfortunately long definition (I miss the 140 character days) that many people failed to read all the way to the end:

There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like “decrease the padding on the sidebar by half” because I’m too lazy to find it. I “Accept All” always, I don’t read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I’d have to really read through it for a while. Sometimes the LLMs can’t fix a bug so I just work around it or ask for random changes until it goes away. It’s not too bad for throwaway weekend projects, but still quite amusing. I’m building a project or webapp, but it’s not really coding—I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.

The year I built 110 tools # I started my tools.simonwillison.net site last year as a single location for my growing collection of vibe-coded / AI-assisted HTML+JavaScript tools. I wrote several longer pieces about this throughout the year: Here’s how I use LLMs to help me write code Adding AI-generated descriptions to my tools collection Building a tool to copy-paste share terminal sessions using Claude Code for web Useful patterns for building HTML tools—my favourite post of the bunch. The new browse all by month page shows I built 110 of these in 2025!

I love the asynchronous coding agent category. They’re a great answer to the security challenges of running arbitrary code execution on a personal laptop and it’s really fun being able to fire off multiple tasks at once—often from my phone—and get decent results a few minutes later.

Vendor-independent options include GitHub Copilot CLI, Amp, OpenCode, OpenHands CLI, and Pi. IDEs such as Zed, VS Code and Cursor invested a lot of effort in coding agent integration as well.

The major labs all put out their own CLI coding agents in 2025 Claude Code Codex CLI Gemini CLI Qwen Code Mistral Vibe

You need three things. A Mac with Xcode, which is free to download. A $99 per year Apple Developer account. And an AI tool that can write code based on your descriptions.

Writing a good CLAUDE.md