You knew the right thing to do for years. The only thing that changed was the cost of doing it.
I knew about git worktrees for years.
Read about them. Understood the concept. A complete copy of your repository that lets you work in isolation. Multiple branches, multiple experiments, no risk of overwriting each other. The theory was sound. The documentation was clear. I had no questions about what they did or why they were useful.
I just never used them.
The reason was always the same. Too much setup. Too much overhead. Too complicated for what I was working on. My projects were small. I was the only contributor. Nobody was forking my repos or raising pull requests. Why bother with a professional workflow when a fancy FTP server gets the job done?
Sound familiar?
The Excuse
Every developer has a list. You know the one. The things you know you should do but have not done. Better testing. Better documentation. Better workflow. Better architecture. You have read the blog posts. You have watched the talks. You understand the theory. You just have not implemented it.
The reasons are always the same. Too much effort. Too small a project. Not enough time. Maybe next sprint. Maybe when the project gets bigger. Maybe when there are contributors. The maybes never end.
The thing about “maybe” is that it is comfortable. It costs nothing. It does not require you to change anything. You can acknowledge the right thing to do and then continue doing the wrong thing, guilt-free, because you told yourself you would do it later.
I was doing exactly that with worktrees. And with issue tracking. And with pull requests. And with adversarial reviews. I knew they were the right thing to do. I had read about all of them. I just had not implemented any of them because the implementation cost was too high for what I perceived as a small project.
What Changed
I started using AI agents to write code for me.
Not as a replacement for my own work. As a partner. I give it a task, it writes the code, I review the output. That is the workflow. Simple enough.
But here is what I did not expect. The AI did not just write code. It lowered the barrier to adopting practices I had been deferring for years.
I told the agent I needed worktrees. It did not just implement them. We talked about it first. I shared what I observed about our current workflow. The gaps. The friction. The things that were breaking. The agent proposed solutions. I pushed back on some of them. We revised. We iterated.
The first version of the worktree workflow was not right. Tests were not syncing to the worktree. The node_modules directory was not available. I had to dig into how worktrees actually worked before I understood the problem. I read the documentation. I realised that worktrees follow the .gitignore rules, which meant I needed to symlink the directories that were excluded. That was not something the agent told me. That was something I figured out by reading.
We revised the workflow. Then we revised it again. We documented it. We created scripts to automate the setup. Then the scripts needed fixes. We ran into issues where the agent would skip the worktree step entirely. I had to ask why.
It took about a week of discussion, implementation, friction, reading, and revision before the workflow became solid.
The AI did not make it easy. It made it possible. There is a difference.
The Chain Reaction
Once the first domino fell, the rest followed.
Worktrees meant I could run multiple agents without them overwriting each other. That meant I could dogfood my own tool. That meant I could stress-test it in the hardest possible scenario: building the tool that builds the tool. That meant I found bugs I would never have found in normal use. That meant the tool got better. That meant I could use it on other projects.
One deferred practice, adopted, unlocked a chain of capabilities I did not have before.
And here is the part that surprised me. I did not need a better model. I did not need a faster machine. I did not need a new framework. I needed to stop deferring. The AI just made it easier to stop.
The Pattern
This is not about worktrees. This is not about my tool. This is not about AI coding agents.
This is about the gap between knowing the right thing to do and actually doing it. That gap exists in every developer’s workflow. The testing you have not set up. The documentation you have not written. The architecture you have not refactored. The monitoring you have not added. The deployment pipeline you have not automated.
You know these things matter. You have known for years. The reason you have not done them is not ignorance. It is cost. The perceived effort of implementation outweighs the perceived benefit, especially for small projects, especially when you are the only contributor, especially when things are working well enough.
AI does not change the benefit. It changes the cost. The practices you have been deferring because they were too much work might now be a conversation away.
What Are You Deferring?
That is the question I am asking myself now. Now that I have seen the pattern once, I cannot unsee it.
What else have I been putting off? What other best practices have I rationalised away with “too small a project” or “maybe later”? What other capabilities am I leaving on the table because the implementation cost was too high yesterday?
I do not have the full list yet. But I am looking.
If you are reading this and recognising yourself, I have one suggestion. Do not try to fix everything at once. Pick one thing. The one you have been deferring the longest. The one you know is right but have not done. Then ask the AI to help you implement it.
You might be surprised at how little it actually costs.
This post is part of my ongoing series on working with AI coding agents. The previous post, When the Agent Codes Faster Than You Can Review, covered the three techniques I am using to move from Level 2 to Level 3 in my agentic coding workflow.