How my AI usage has evolved since the initial public release of Claude Code
February 2025 - November 2026
Indicates commentary and additional material from Claude
Claude Code was the shot heard round the world of AI accelerated software development. Since it showed up, it seems that the discipline continues to evolve at a pace that can at times feel difficult to keep up with. I thought it would be a good exercise to take my eyes off of the frontier for a while and reflect on more than a year of software development with agents.
Prior to the release of Claude Code, I had been copy/pasting code from Claude chats into EmacsA text editor that has kept evolving since the 1970s, because its users can extend it in code until it does almost everything. so frequently that I started to wish for the model to be able to edit my code directly. I tinkered with a few open-source repos, but I didn't get any satisfying results or have the time to work on a solution myself. The idea was in the air, and Boris Cherny of Anthropic plucked it out and ran with it. Claude Code was born.
Feb to Sep 2025
Directing Claude one change at a time and reviewing each one.
At that time, frontier models were obviously not good enough to entrust the development of an entire component to them, especially not a critical one. I was doing foundational work on a distributed systems project where concurrency and the correct application of cryptographic primitives were essential. Even then, I found that I usually preferred to direct Claude to make a change, review it, and then either give feedback or make manual edits myself. Occasionally, I would spin up additional agents for research or planning next steps.
This felt like significant leverage, but the scope of what I was attempting was still relatively normal for an experienced engineer. I was happy that my ambitious side project had suddenly become much more tractable, but uncertain how the model's coding capabilities would evolve and at what speed. In any case, I was already convinced that coding with agents would change our profession forever, but felt some level of cognitive dissonance due to the fact that most of my colleagues had not yet seriously engaged with it.
Oct 2025 to Jan 2026
Claude Code at work, and planning starts to matter more than writing code.
By fall of 2025, more and more developers were becoming fully AI-pilledConvinced, often suddenly, that AI changes everything. and starting to understand the ways in which this technology changes everything, and perhaps also the ways in which it doesn't (yet?). I was able to begin using Claude Code at my job. Suddenly, all of those ideas that had accumulated in my notes and in my head over the years but had never been prioritized for implementation got an agent assigned to them. I began to feel that I needed a much better way to keep track of and execute all this additional work. Steve Yegge arrived just in time with beads in October, an agent-first issue tracker that lives in git repos. Despite being inspired by the idea, I had the intuition that it would be important to fully own the organization and orchestration of my work going forward. I also understood that it would become much more common to "remix" open-source code rather than always making direct use of it. I built a system based on a beads-like foundation that allowed me to plan work together with an agent while seeing the DAGDirected acyclic graph: tasks joined by one-way links with no loops, so the order of the work is always clear. representing my intent update in realtime. The natural next step was to make it so that I could launch and monitor work directly from that DAG view as well.
What is a DAG-based issue tracker?
When Anthropic released Opus 4.5 in November, it started feeling like the planning and orchestration work was becoming more important to the software development process than writing code. The time horizon of tasks that could be delegated to agents increased dramatically, and as a result it became pragmatic to run more agents in parallel. Yegge understood this as well, and demonstrated how to put a miniature society of agents to work with Gas Town. At the time, I felt that it contained many good ideas but was too chaotic to adopt wholesale. There were some areas in which I was willing to apply patterns that would come to be associated with "software factories", but I knew it was important to maintain a grasp over the core of the system I was building.
What is a software factory?
At the same time, Geoff Huntley's "ralph loop" technique was taking off. Unlike Gas Town, this is a single powerful primitive which can be almost instantly applied to a wide range of problems that would otherwise take an inordinate amount of time to solve. I began ralphing my way through massive refactoring and greenfield implementation tasks. The process of software development was clearly moving up a level of abstraction: instead of engineering the product directly, we were increasingly engineering the processes to produce and maintain products with AI.
What is a ralph loop?
Jan to Sep 2026
Building a tool for colleagues, then leaving to take the idea further.
Coming into 2026, I felt like I had seen the future and that it was now time to work on showing it to my colleagues. It felt impossible to communicate how effective certain tools and techniques could be without sounding like an insane person to those who remained inexperienced and skeptical. Meanwhile, early adopters were delegating more and more of their digital life to their OpenClaw instance and learning to deal with the resulting risks and benefits. While I wasn't one of them, I understood the appeal of having a persistent agent that communicates at a high level of abstraction. Instead of watching every code change scroll past, you delegate more and focus on outcomes, and your agent alerts you on your phone when something needs your attention. At the time, I was about halfway to having a lot of the same functionality in my own system, and like with Gas Town, I preferred to simply adopt the good ideas into a system that I could trust rather than directly adopting someone else's vibe-codedWritten by an AI from prompts, with nobody reading the code. tool.
What is a persistent agent?
By March, I had put together a tool that could finally bring some of these capabilities to my colleagues at Ableton. I reasoned that, while experienced engineers are often reluctant to take advice about workflows, designers and product owners would be overjoyed if they were able to change the product themselves rather than waiting for someone to pick up a JIRA ticket. I automated the setup of development dependencies for Ableton's flagship products and integrated Claude Code and git into a simple UI that allowed users to create and share prototypes with Claude.
It quickly gained momentum, and for the first time in a long time I experienced the satisfaction of being able to build software for a small group of people who I actually knew and could talk to in order to get immediate feedback. Somewhat unexpectedly, I also began preferring to do more of my own product development work using the tool that I'd built and began entertaining the idea that the roles of product manager, designer, and engineer were converging to the single role of the builder, who would handle all aspects of the product development process in an AI-native IDEIntegrated development environment: the application a developer writes and runs code in.. Compared to developing within a strictly divided corporate structure for a mass, mostly anonymous audience, this felt like liberation.
I found myself no longer interested in continuing to help develop Ableton's products myself, and instead I started dreaming of bringing a similar experience to people in other domains, to companies of all shapes and sizes. I decided to leave the company while continuing to work on the tool part-time as a freelancer.
Sep to Nov 2026
Independent work on a fleet that lands and validates agents' work.
Since then, I've been happily using my additional free time to focus more on my own product development infrastructure, open-sourcing small bits and pieces of it while keeping the bulk of it in a private monorepoOne repository that holds many projects.. That work sped up with the release of Astra, Fable, and Opus 5.5, which felt like a step-change similar to the Opus 4.5 release. Opus 5.5 no longer merely gets tasks done but frequently does them in exactly the way that I intended, and in rare cases, it does even better than that. The reduced demand on my attention has made it possible for me to put much more inferenceRunning a trained AI model to get an answer, usually paid for by use. to productive use, and I can no longer afford to pay for as much inference as I could effectively utilize. There was a moment where CPU time and disk space usage from Rust builds were the bottleneck in my workflow, so in response I leaned into making 0k.computer capable of mustering machines into a fleet that continuously lands and validates agents' work.
All of this serves a larger goal: to accomplish the work of a company with no SaaSSoftware as a service: software rented by subscription and run by its vendor. and no data silos that hold back AI-accelerated processes. 0k.computer already does the work of GitHub, Linear, Jira, and Confluence for me, and it is growing to cover Google Docs, Google Drive, Dropbox, Gmail, Google Calendar, Slack, Tailscale, and ultimately Zoom, Granola, and the holy grail, Emacs. Cloud inference will likely be the last thing to go, and I'm excited by the work of Nous Research and Actual Computer on open models and local inference.
In this landscape, I believe the only reliable way to continue to make a living as a software developer is to deploy secret weapons of product development excellence. 0k.computer is my secret weapon, and I only want to put it in the hands of people I trust. Even so, I will keep publishing key slices of my work, both to give back to the open-source foundations that made it possible and to start building a network effect around its multiplayer features. While I explore new paradigms and attempt to push the limits of what's possible with the freedom of my independent work, I still work with Ableton as a client, and they benefit from what I learn and the tools I publish as open source.
If you're interested in hiring me, please reach out at hello@lanespangler.com.