2026-09-10
I wouldn’t consider myself to be an early adopter of AI. My own timeline for it probably matches the way I’ve adopted any other tool: incremental steps at first to gauge usefulness and capability, followed by accelerating upgrades to every part of my workflow.
When I first started using AI, agents weren’t a thing. What now feels like basic AI autocomplete was revolutionary at the time. The computer figured out what I was going to write and wrote it for me. I started with GitHub’s Copilot, but my dependence on it was never complete because it struggled to produce code in the context of the wider project. Hence, when I started working at Teldio, I opted not to use any AI at all.
Eventually, one of the higher ups offered anyone in the development team a free Claude subscription. Thinking back to how Copilot was useful for me before, I thought I would take advantage. However, I wasn’t interested in the new “agentic” stuff at all. It seemed a bit out of control, and I didn’t want the machine making decisions for me. So I asked instead for a Cursor subscription. Cursor looked like a better, more integrated version of Copilot.
For a long time, I was perfectly content with Copilot. It greatly reduced the tedium of writing basic code while letting me still have complete control over what was written. While I was working this way, agentic AI slowly crept up to becoming extremely powerful. The first moment that piqued my interest on agents was when another employee starting building incredibly complex programs with it. But it wasn’t just the building of them that was interesting to me, it was how they were able to debug and get the AI to update it easily.
I asked for a Claude subscription and was granted it. I tried using it the same way I use Cursor, but I wasn’t able to since Claude does not have an autocomplete mode. I was frustrated, but in retrospect this was the single best limitation that Anthropic could’ve instituted. It forced me to think about code in the terms of what I wanted done, rather than the details. Claude is powerful enough to write things correctly without micromanagement, and it can learn the way you want things done with memories, skills, and AGENTS.md files.
I always read all the code that Claude writes, mostly focusing on the right patterns being used, user experience, and testability. I love how easy it is that I can tell it to generate mock data, build programs with interfaces that actually plug into real tests rather than their use being purely theoretical.
The final step for me is adding up all my experience and processes with AI to be able to maximize my productivity. I’ll detail the practical reality of that in the next section. I now can work on multiple things at once, be able to deploy and test my code in hostile environments easily, and remain confident throughout.
To start off, AI use doesn’t mean you should give up your tools. An incremental approach is usually better than trying to change everything at once. For example, work for me used to begin with opening VSCode (insert editor of choice here) and setting up a branch. Nowadays, I give Claude a link to the GitHub issue, tell it “vscode.”, and it opens up VSCode on a worktree for it. I still get the benefit of my preferred environment while not having to manage it myself.
Tip: use your AGENTS.md file to get your AI to understand what you want. My workflow above is only possible because Claude knows that when I provide a link with the word “vscode”, it means it shouldn’t do anything other than set up a worktree and open my editor.
Take this a step further and let the AI handle re-building and deploying your features. Especially if your feature requires work on an external system - as these environments are usually the most annoying to deal with. If SSH access is not possible, or Claude doesn’t have the right permissions, you can still make it easy for yourself. Tell Claude to drop a shell script that you can then run directly on the machine with admin permissions. I recently had to work on a program that needed to run on a Windows machine under another service, and there was no easy way to let Claude run directly on the machine. Instead, I setup SMB, gave Claude the permissions to deploy, and I manually re-ran a deployment script directly on the machine.
In the spirit of the incremental approach, a great way to find things to automate is to reach for it whenever you get annoyed. In the example above, setting up branches and my dev environment was what annoyed me and that is a signal that the process is a good candidate to automate.
Once the AI is already handling your dev environment, getting it to handle the work itself is usually straightforward. I gave it the issue and it opened VSCode and a worktree, so the AI itself is also ready to start working! This is a great way to start a hybrid approach to development: such as if you want to experiment with the code yourself before directing Claude, or if you want to scaffold an approach.
In my opinion, what makes code review a slog is reading carefully line-by-line to ensure correctness. For the most part, modern AI agents are actually better at doing this than I am. They can detect issues, run experiments, and write tests way faster than I can. Why is this significant? It allows me to focus on what is, frankly speaking, more fun about code review: asking questions about whether the particular solution is the right one, about the overall design decisions that have been taken, and about user experience.
Tip: use worktrees! It allows you to keep a canonical main version of what you’re working on in a separate folder, and work on multiple features at once on the same repo. The annoying part of worktree management can be handled by the AI. I can review someone’s code while working on a feature at the same time using worktrees.
For testing, it’s always good to start with a mock-heavy approach. That means you should ask Claude to create code with interfaces, which allows consumer code to easily replace the given package with test data that is either generated or produced from real API responses. Alternatively, you can create a mock server that you test your client against. Go has the very useful httptest.Server that helps with this approach.
The following tips are useful when working on a UI:
When working on code directly, ask the agent to either build tests for your code, or fix tests that stopped working with your changes. If I’m working on a feature that breaks tests, I typically ignore them until I’m done and ask the agent to clean up. It can infer what the new design is meant to be and update the tests accordingly.
Hopefully my history of how I started using AI proves useful, along with the tips I’ve listed above. Not much else to say, thanks for reading!