A Year of Using AI Coding Assistants in My Daily Work

I've been using AI coding assistants for about a year, starting with GitHub Copilot and mostly choosing Claude models. They've become part of my development work, both at the office and on personal projects. I'm only now starting to write about that experience.

This is a record of the way I work at the moment. I'm still adjusting it as the tools change and as I get a better sense of what information an assistant needs from me.

Starting with Copilot

Copilot was my starting point, and I still like it. Having an assistant available alongside the code made it a natural tool to reach for during development. Claude models have been my main choice through much of that time.

My current and recent tools include Claude Code with Opus 5 and 5.5, and Sonnet 5 and 5.5. More recently, I've also been using Codex with GPT-6.1 Sol for some UI work on personal projects. Those are the tools I'm describing now; I haven't been using those exact versions for the entire year.

I don't have a permanent ranking of them. A useful question for me is whether I can explain the task clearly, follow the changes, and get to a result I can verify.

Giving the task a useful starting point

One habit I've developed is spending more effort on context before asking for an implementation. That includes what the project does, which parts matter to the task, and what must continue working afterward.

For a UI change, that could mean explaining which layout needs attention, which interactions must stay the same, and what should happen on smaller screens. For a backend change, it could mean identifying the API contract, access rules, and failure cases that need to be preserved. Those details give the assistant something concrete to work within.

I want the request to describe enough of the expected result that I can judge the implementation afterward. The same habit applies to a new feature, a bug fix, or routine maintenance.

I still expect the assistant to inspect the code. The context I provide should help it find the right starting point, while the repository supplies the actual implementation details.

Using plan mode before implementation

For work with open questions, I use plan mode to discuss the approach before implementation. I ask the assistant to inspect the relevant code, ask me about unclear requirements, and suggest an approach. Claude Code's plan mode supports exploring a change and reviewing a plan before edits begin. The controls vary between tools, but the conversation is the important part of my workflow.

I expect that discussion to take more than one round when the task needs it. I answer questions, question the assistant's suggestions, and ask for the plan to be revised. Before coding, I check that it describes the behavior I actually want, fits the existing code, and includes a way to verify the result.

For example, a proposed filter needs decisions about empty results, invalid input, and how it interacts with pagination. Catching a wrong assumption in the plan is easier than discovering it after several parts of the implementation depend on it.

In my experience, this back-and-forth gives me better results and cuts down on debugging caused by misunderstood requirements. The questions need to move the plan forward; repeating an already answered question adds little. Once the important decisions are clear, I move into implementation.

Looking at the result myself

UI work needs a visual review. That means looking at heading wraps, spacing, alignment, mobile behavior, and whether interactions feel right in the running application.

A successful build doesn't tell me whether a screen is clear or comfortable to use. Screenshots and the running application give me something specific to respond to. I can point to a gap that feels too large or an interaction that needs another pass.

Behavior needs its own checks too. For an API change, I want to know how existing callers behave, whether validation works, and what happens when a dependency fails. I compare the result with the agreed plan and investigate differences. Those checks matter even when the visible change is small.

Carrying useful context between sessions

I've also started putting more of the repeatable guidance into project instructions and reusable skills. The stack, conventions, constraints, and verification commands belong somewhere a new session can find them. That gives it a starting point without another long explanation of the same requirements.

During long sessions, I use compaction at useful stopping points so I can continue with a shorter account of the work. The important details are the decisions, completed changes, checks, and remaining tasks. I still need to check that those details survived the summary.

These habits apply to both office work and personal projects. The information I can share with an assistant still depends on the project's access and confidentiality requirements.

Beginning to write it down

The part I want to document is how these tools fit into ordinary engineering work: explaining a task, keeping changes within scope, checking the result, and maintaining enough context to continue.

I've written more about the project rules I give my assistants and how I manage token usage. Both grow out of the same day-to-day habit of making the work easier to understand before asking an assistant to change it.