I love to code. I code a lot. Over the past few years, I’ve been an eager adopter of Cline, Roo, and Amazon Q CLI. I’ve also been experimenting with Kiro, Cursor, Copilot, and Claude on the side. From these experiences, I’ve developed a few personal guidelines for using AI coding tools effectively.

Only ask AI to do things I already know how to do

I take ownership of any code I produce. So, I don’t ask AI to help me write code unless I could have written it myself. That said, AI is much faster at typing than I am, so if it can do something I already know how to do, I’ll absolutely let it.

This includes knowing how to research to find an answer. I use AI as a research companion to help me find resources when I need to learn something new. Then I apply that learning to guide my AI coding agents more effectively.

No “vibe” coding

AI can generate huge volumes of code in autopilot mode. I like the mental model behind Kiro’s spec-driven coding: set a goal, think about the end state, and break the work into smaller steps. That said, I’m not a fan of Kiro’s “autopilot” mode. No matter how well I’ve written a spec, AI still needs supervision to produce results I’m happy with.

So, I don’t code in a “fire-and-forget” way. I tried this many times, but I ended up spending just as much time undoing or discarding code generated en masse by an autopilot agent.

Ask AI to do small, specific tasks

As of Nov. 2025, even the best coding models (like Sonnet 4.5) still appear to perform best on small, well-scoped tasks. I’ve found Roo’s boomerang tasks to be a great way to break larger tasks into steps AI can manage well.

AI automates but does not think

I resist the temptation to delegate “thinking” to the AI. I treat AI like an autocomplete engine on steroids. It may look like it’s thinking, but it’s not capable of true critical reasoning. I use it to automate tasks, but I stay in charge and make sure it’s doing what I actually need.