I’m not sure how to start this post, because there is so much to say.

Actually, that’s exactly how I started a blog post in February 2023, writing about burnout and the beginning of what Farrah and I called our “Grand Adventure.” Back then, I described burnout as “waking up everyday, and wishing I could do anything other than my current work” and struggling to focus on even simple tasks. Major accomplishments provided “the most fleeting sense of satisfaction, usually lasting no more than a minute.”

This summer has been different. I’ve had more than one Saturday when I woke up at 5:30am with some idea in my head and stopped coding at 10pm with hardly a break. The difference isn’t just that I’m working on my own project now - it’s that I’ve discovered a way of building software that actually feels productive and fun.

Back in May 2023

During our travels, I finally broke through my AI skepticism and spent a day testing whether ChatGPT could actually write software. I asked it to implement Conway’s Game of Life in Python, expecting to be disappointed. To my surprise, it produced working code, and over several hours I was able to prompt it through adding features.

But the experience felt strained. I described it as feeling “like a product manager” - feeding requirements and bug reports to ChatGPT, then waiting for changes. If my prompts were even slightly ambiguous, the results were generally an unusable mess. The user experience of copy-pasting code around made it feel a bit like working with a better StackOverflow. It was impressive but clunky.

Two years later, everything changed.

Building plonk

About a month ago, I decided to take Claude Code for a spin on a personal project. I’d been frustrated with managing my development environment across multiple machines and wanted a tool to synchronize packages and dotfiles. I called it “plonk.”

Note:

plonk solves my problems, it may not solve anyone elses. I personally can recommend both chezmoi and dotter as excellent tools that were inspirations for plonk.
Additionally, there are whole webpages of resources like https://dotfiles.github.io/utilities/ listing excellent dotfile managers. So if you don’t like plonk, use one of these, or build your own like I did.

The development process was unlike anything I’d experienced in decades of programming. In just one month, plonk went from initial commit to version 0.10.0 - a production-ready tool with comprehensive documentation, test coverage, and architectural polish that would have taken me many months to achieve coding alone.

Looking at the git history tells the story: 709 total commits, with 513 of them marked as AI-assisted collaborations. That’s a 72% collaboration rate.

How it feels different now

The biggest change from my 2023 ChatGPT experiment is that working with Claude Code now feels like collaborating with a capable junior-to-mid-level developer rather than directing a task-completion system. Someone who’s a code workhorse but sometimes overeager about adding “helpful” features.

I was so surprised by this improvement that I initially let the agent add lots of “helpful” ideas that turned out to be classic YAGNI (You Aren’t Gonna Need It) violations. But here’s the thing: I could make these mistakes quickly with the agent, and I was also able to refactor my way out of messes and learn from my mistakes at the same pace.

This led me to develop much more thorough planning phases for bigger features while letting agents handle straightforward fixes directly. I also had to establish strict rules - my CLAUDE.md file became crucial for maintaining quality and preventing problematic behaviors like adding emojis to everything, implementing helpful features without asking, or leaving work half-done.

Some rules were domain-specific: plonk manages packages and dotfiles, so running plonk itself in tests would break my development environment. I learned this the hard way more than once.

The interview technique

One of my better process innovations was having Claude Code interview me about the functionality I expected from each plonk command and how I expected it to work internally. (I’m the first person to think of this ever. Right?) This created the behavioral documentation that guides plonk’s development today.

This technique worked better than traditional spec writing because the AI asked clarifying questions I wouldn’t have thought to address upfront. Some of these questions led me to think in totaly new directions, while others were clarifying questions that a human would have easily surmised. Sometimes frustrating, and othertimes wildly insightful.

When implementation isn’t the bottleneck

Some number of years ago, I realized that often the most valuable contribution to a team or business was deleting code, simplifying systems, or not writing code at all. I’ve been reflecting on this a lot lately.

Now that I can easily tackle projects I previously considered too time-consuming, the new challenge is deciding what not to build. With AI removing implementation friction, the critical skill becomes choosing what deserves to exist rather than figuring out how to build it.

That said, when I really like an idea, branching to prototype something is now very low effort. Instead of debating whether something is worth the time investment, I can just try it.

The great refactoring

My last 16-hour coding day perfectly illustrates this new capability. Plonk had accumulated complexity and half-built features to the point where the codebase had grown to a bloated 25,000 lines of poorly organized Go, that looked a lot like Java if you squinted, with barely functional tests. The complexity had grown so unwieldy that I was having trouble getting agents to write any code that didn’t break five core features.

In that single day, I stripped all the accumulated cruft, reducing the codebase by 50%, and rebuilt the actually useful features into clean, well-organized architecture. I’d have been hard-pressed to get those results coding by myself for a month.

Is it my code?

The question of code ownership comes up frequently in discussions about AI-assisted development. I think asking whether AI-generated code is “mine” is a bit like asking whether the binary produced by a compiler is “my” code.

The answer is both yes and no. Using Claude as both research tool and coding assistant suggests the answer leans more toward “yes” than it would for purely mechanical compilation. The AI doesn’t just translate my instructions - it helps me think through problems, suggests approaches I hadn’t considered, and implements solutions that often surprise me.

But fundamentally, it’s still tooling - sophisticated tooling that happens to communicate in natural language rather than through syntax and APIs. Or at least, that’s how it seems today. Ask me in a week and I might have a different answer.

Learning more, not less

One unexpected side effect has been a dramatic increase in my learning velocity. Not necessarily because I’m learning faster than I would without AI, but because the excitement of what’s suddenly possible has inspired me to spend much more time exploring.

I’ve been diving deep into context engineering, prompt engineering, LLM architectures, and coding agent behaviors. The AI didn’t just make me more productive - it rekindled my curiosity about software development itself.

What I don’t know yet

I only started using AI coding tools at work about three months ago, and I’ve been using Claude Code for personal projects for just one month. I’ve been so absorbed in building plonk that I haven’t had time to be distracted or lose motivation.

I don’t know yet if this will sustain or what it means for how I approach work long-term. I don’t know if the prototype velocity will eliminate the decision paralysis I described in my burnout post, or if new forms of analysis paralysis will emerge when everything seems possible.

What I do know is that for the first time in years, I’m waking up excited about the code I’m going to write today. Instead of struggling to focus on tasks and feeling exhausted after completing them, I’m finding flow states that last for hours and leave me energized rather than drained.

Whether this represents a temporary honeymoon with new tooling or a more fundamental shift remains to be seen. But the journey from burnout through skeptical experimentation to productive partnership has already been worth it.

One final parting thought for you. When I first heard the term “vibe coding” I thought to myself, “this has got to be the single stupidest techy buzz phrase I’ve heard since serverless”. I’m not sure what we can call this kind of programming that will be less cringe, but whatever we call it I’m finding it both fun and productive.