How I Use AI Day to Day

By Ryan Mason · July 11, 2026

A practical look at how I use AI as a software developer.

This is for any software developer who is AI-curious but wants to cut through the BS by hearing from a real person using it every day.

Who am I

I'm Ryan. At my day job I work as a senior software developer and team lead. We make internal web apps that support the building and selling of widgets.

We use modern Angular, dotnet, and SQL Server. We use Azure DevOps to manage work items, pull requests, repos, and CI/CD. I currently use the Zed editor, since my work laptop sucks and Zed is less resource intensive than VS Code.

Outside of my day job, I have a company called Tequirk. I make websites using Vue deployed to Cloudflare, cross-platform apps using Expo and React Native, and browser extensions.

Why did I write this?

Someone asked me how I'm using AI and I wanted to turn incoherent rambling into coherent rambling.

An overview, with some boundaries

I'd like to start with some throat clearing and boundary setting so we can actually get somewhere and not be dead on arrival.

Here's what I don't want to talk about:

1. Ethics, morality, and ocean boiling

Here's what I do want to talk about:

1. Being practical
2. What I use
3. How I use it
4. How the team uses it
5. How I've heard of people using it
6. How I think you could use it

A couple of things to keep in mind. First, this is just another tool. It is not a magic bullet. Not magic at all, actually. Second, this is my experience. I'm actively using it to do a thing. The things I say are not academic studies, they're just the things I use and see every day. Lastly, language is hard. I might use words that sound like I'm anthropomorphizing it. Sorry; blame the limits of English and my vocabulary.

Where did I start?

I started using AI with GitHub Copilot's autocomplete. Later VS Code added a chat feature that was context-aware. This evolved into "agent mode" where you could have it edit code for you.

After that, my day job bought me a license for Claude Code and I haven't looked back.

What is Claude Code, and how do I use it?

I have to tell you what Claude Code is first, and then I'll explain how I use it. You can skip this if you already use it.

I use Claude Code. The Claude Code CLI is a harness. I run Claude from my source directory so it has access to all of our repos.

The setup is something like:

1. Make an account
2. Download and install the CLI using their instructions
3. Open a terminal and invoke it from whichever folder you want it to have access to
4. Log in
5. Start a conversation

Models

The harness lets you choose which model to use. Models change the capability and the context window size. The context window is the amount of text you can fit into a conversation.

Anthropic models, from least to most capable, are Haiku, Sonnet, Opus, Fable. I use the latest version of Opus.

The harness

The harness gives the model access to:

1. System prompts
2. Memories
3. Skills
4. MCPs (Model Context Protocol)
5. Tools

All of this put together is an agent.

System prompts

Some are built into the harness and some you define yourself. Mine contains general info about who I am, how I fit into the organization, and the projects I work on, including their domain and tech. These are Markdown files in your Claude folder.

Memories

Memories are snippets of context included in each conversation. Claude can decide to remember things on its own, or you can ask it to remember something.

Skills

Skills are JIT (just-in-time) context. The frontmatter (name and description) is always loaded. The full skill only loads when invoked via slash command, when you ask, or when Claude decides it applies. This helps avoid system-context bloat.

MCPs

I don't think MCPs used to be JIT, but I think most harnesses lazy load them now. MCPs are APIs your model can access. Some are built in, like file system and shell access. Others are installed, like Jira and Playwright. I use the defaults, Playwright (browser automation and testing), and ADO (work items, PRs, docs and wiki).

Tools

Tools are like API endpoints an MCP server exposes:

• Read or write a file
• Get a work item
• Create a PR

Access controls

MCPs can be configured to allow only specific tools. By default, harnesses prompt before letting a model use potentially harmful tools.

Putting it together

My daily skills

I built my own skills to describe workflows that use tools in a specific way.

/work-on takes an optional work item ID, then pulls ADO info, reviews code, drafts a plan, gets my approval, makes changes, builds, and tests. It contains our coding guidelines, including common patterns and examples.

/review-pr takes a PR ID, then pulls info, assigns me as reviewer, switches branches, reviews the code, builds, and tests with Playwright. It contains our PR review checklist.

Both skills reference two others. /query-db interacts with my local copy of production via sqlcmd. /start-dev covers how to build, test, and run our apps using node or dotnet.

How I build skills

Two ways. I can describe it to Claude and have it draft the skill. Or I can have a conversation while working, then ask Claude to create a skill from what we did.

Sometimes skills hit rough edges, but you can refine them over time. For example, Claude didn't know the DB schema and kept querying the wrong table. You can fix it by editing the skill file manually, or by describing the fix and asking Claude to update the skill. In this case, I asked it to update the skill to grep the databases repo for the table schema before writing queries.

This lets you iterate toward reliability.

My workflow

1. Pick a work item.
2. Imagine how I'd implement it, high-level or by looking at code.
3. Start a conversation with /work-on.
4. If Claude's plan is wildly different from mine, figure out why.

That "why" might mean steering, a fresh conversation, a question for the PM, or deciding to do it myself.

This should help you type or grep faster, not ship things you don't understand.

Some devs use a "grill me" skill that prompts Claude to ask you questions and check assumptions before getting started.

Reviewing PRs

For my own PR, I publish a draft, start a new conversation, then run /review-pr against it.

For someone else's PR, I run /review-pr, but in parallel I review the work item and review the PR and diff myself. Then I compare findings with Claude, and usually test together in Playwright.

Determinism and guardrails

AI is non-deterministic, but it can create, update, and use deterministic tools to become more reliable and consistent.

Add guardrails by giving the agent a way to check its work:

• Build
• Test suite
• Linter
• Language-server feedback
• Exploratory testing in Playwright

Run these via steps inside a skill, or via hooks.

Hooks

Hooks fire at points in a conversation's lifecycle: when a conversation starts, when a message is sent, when a skill is called, and so on.

I don't use hooks.

Remote control

Claude Code offers a feature called "remote control", which lets you run Claude on your computer and interact with the session from your phone using the Claude app.

I think dispatch and cowork is similar, but it controls your computer using the UI instead of the CLI.

Context

Running out of context

Harnesses have a "compacting" step that auto-summarizes and starts fresh. I think this is bad: you don't know what details were lost.

Ways to cope:

• Use a larger model
• Break projects into smaller work items
• Stuff context and progress into a spec file (Markdown) and load it in a new conversation

Our team commits big-project spec files to source control. I do this on side projects too.

Two strategies

Single context, single conversation, for simple work items.

"Add a field to a form with a backing database field."

Large context, multi-conversation, spec file, for larger projects.

"Modernize and migrate chunks one step at a time."

Subagents

Harnesses can also avoid bloating context using subagents. Subagents are agent sessions created by agents to work on a task outside the main thread's context window.

Quality

Emergence and domains of applicability

Sometimes you have to reason about how it works under the hood to get better results, and sometimes you have to focus on the emergent behavior.

Patterns and repetition

Agents are great at following established patterns and repetitive tasks:

• Migrating legacy code
• Writing unit tests

Take advantage of this by providing examples, especially combined with guardrails and verification.

Bad context propagates

They also propagate bad context. Code quality matters. Work item quality matters. Bad spelling makes results worse.

Why? I'm not sure, but in my mind, if it predicts the next token, misspelled words sit close to low-quality-code tokens.

Transformation

Agents are good at taking context in one form and translating it to another. This makes them good at:

• Migrating legacy code
• Writing tests
• Summarizing, whether documentation or explaining code to a non-technical audience

Design

Claude Design can generate high-fidelity mockups. Stakeholders iterate on what they actually want faster, with less developer time spent writing throwaway code.

Needle in a haystack

Agents are good at finding one specific thing in a large body of text:

• Spotting a single spelling mistake in a long document
• Locating the one line that matters in a big file or diff
• Catching an inconsistency buried in pages of context

This pairs naturally with a big context window. The more it can hold, the bigger the haystack it can search.

Team onboarding

Not everyone on the team uses AI. It's frustrating when Claude catches trivial PR issues from teammates who aren't using it.

If you're not using AI at all, running a read-only code review is a low impact, high value way to start using it.

Junior devs

I'm not sure how I feel about junior devs using AI tools. I think using it to plan and review might be okay, but I'm concerned that not writing code will prevent learning. On the flip side, I'm not a "the kids should handwrite in cursive" kind of person.

Cost

Claude Code is $20/mo per user. There's a 5-hour token allocation and limit, a 7-day token allocation and limit, and larger models use more tokens.

My experience:

• Sonnet: never hit the 5-hour limit
• Opus: occasionally hit the 5-hour limit
• Never hit the weekly limit with daily use

Velocity

We use story points and track velocity. Developers using AI on our team show a measurable bump in velocity. However, I try to reinvest the time gained to sharpen the saw or touch grass rather than only making number go up.

Word on the street

Organizational skills

Organizational skills are skills shared between users within an organization. I can imagine some being generalizable, but mine are geared toward the way I work. We don't use them.

...I kind of lied. We're working on migrating some old code to a new pattern. We committed a SKILL.md file to source to help with this, we're just not using Claude's "organizational skills" proper.

Agent orchestration

Some people online run multiple agents at once. I don't do this at work. Outside of work, I've used the GitHub Copilot Agent in the GitHub UI. You can assign it a GitHub issue, and then it submits a PR. I've used it to one-shot small changes or code reviews on personal projects.

Worktrees

git worktrees let you create an additional directory for a repo. I found this annoying. Each worktree needs its own npm install for node projects, which costs time and disk space.

pnpm

pnpm (over npm) symlinks node_modules folders for you, which might avoid npm's issues, plus other benefits.

Dev containers

Neither worktrees nor pnpm solves running apps and managing ports. I haven't solved this myself, but I've heard of people using dev containers or VMs, with the bonus of added security and separation from the host machine.

Local LLMs

I don't actively use local LLMs, but I've run them using LM Studio. LM Studio can mock common AI providers, so it could be used for local testing. With the compute resources I have, they are too slow and incapable for any other real use. That being said, this might be another low-friction way to start using AI.

Model routers

Some AI tools use model routers. These attempt to use the least costly model and resources to accomplish your task. I have some feeling that Anthropic uses this in the background during high load. This may just be in my head; we're going on vibes after all.

Questions?

What did you find surprising?

That it works at all.

How has your usage and workflow changed over time?

Autocomplete and chat gave way to agents. Pre-Sonnet 4.6 wasn't great, but everything after has been great.

How are you handling code reviews of generated code? Are devs expected to understand it?

Devs should understand it. AI generated PR descriptions are frowned upon.

Can you show us an example spec?

We use story templates and generally those are the spec. If it is good for new-hire humans, it is probably good for AI.

How do you feel about quality and consistency with existing code?

It pattern matches, so it is better with good patterns and propagates bad patterns.

Are you using it for green or brown field?

Both. Word on the street is that it is better with green, but I argue it is better with brown because there are more examples and more constrains on the solution space.

Thanks!

Be practical with adoption at your own pace. Use it for things you want to use it for, and don't for things you don't.