What Changed in My Workflow After Using Claude Code

Claude Code has quickly become one of the go-to coding assistants for many developers and teams. I’ve been using it as part of my day-to-day workflow, and over time I’ve noticed that it hasn’t just changed how I code, but also how I approach building software.

This is not meant to be a set of best practices or anything definitive—just a collection of things that have genuinely helped me so far, in case they’re useful to someone else as well.

I’ve found my way of working with it gradually shifting:

• from using it for isolated tasks

• to being more intentional about planning and context

• to using it for refinement and quality improvements

• and finally toward thinking more automation-first in general

1. Getting comfortable with sessions and keeping context

One of the first things that made a difference for me was just getting comfortable with how sessions work, and how to recover or continue work without losing context.

/login helps you recover without losing context

If you ever need to switch accounts or your session expires, you can use:

/login

This lets you reauthenticate without losing your current context.

Useful when:

• switching subscriptions or accounts

• dealing with expired sessions

• recovering access without restarting your work

Small thing, but I’ve found it helps maintain flow.

claude --resume is a safety net (with one catch)

Another thing that has been really helpful is being able to resume sessions.

You can use:

claude --resume

to return to a previous session.

This has been especially useful when things go wrong:

• accidental terminal closes

• machine restarts

• terminal freezes (this has happened to me more than a handful of times)

It’s also useful when working on different things and wanting to keep contexts separated across sessions.

One thing I didn’t realize at first:

--resume is scoped per directory.

If you’re not in the same directory where you started the session, you won’t see it. I learned this empirically after thinking I had lost everything—when I was just in the wrong folder.

/btw helps you keep momentum

More recently, I’ve also found /btw useful.

It lets you ask questions or leave comments without interrupting the current work.

Instead of breaking the flow of a task, you can surface clarifications while the assistant continues working.

It’s a small thing, but it helps keep iteration smooth.

There are many other commands and I haven’t explored most of them yet, but I’m curious to keep discovering more over time.

2. Learning to guide the assistant better

Plan before implementing

I’ve found it works much better to align on a plan before jumping into implementation.

Before coding, I usually ask Claude to outline:

• the approach

• the scope

• the main steps

This tends to lead to more predictable outcomes and fewer surprises later.

Otherwise, you risk getting code that technically works but doesn’t match how you actually wanted things to be structured or behave.

Provide the right context, not more context

Coding assistants have gotten really good—but the outcome is still very tied to the input.

When it makes sense, I try to include things like:

• ticket context (title + description)

• PRDs or specs

• related PRs or discussions

• incident reports

• logs or traces

• specific files or references

The goal is to help build the right context around the problem.

That said, this is very dependent on what you’re building. For simpler tasks, you don’t need much input to get a correct implementation.

But as things get more complex, the difference becomes obvious.

It’s not about adding more input—it’s about adding the right input.

I like to think of it as getting an incident report with no repro steps or logs—you’d be lost. And the same applies to the agent.

Challenge limitations instead of accepting them

Sometimes the agent will say it can’t do something and suggest doing it manually in another terminal.

In those cases, I don’t always take that at face value.

There have been situations where:

• it actually can do it within the current context

• it has done similar things before

• or the limitation isn’t entirely clear

So instead, I try to push a bit:

• “Can you try doing this directly?”

• “What exactly is preventing you from doing it here?”

Not in a forceful way, but just to better understand what’s going on and avoid unnecessary manual work when possible.

Use Claude for refinement, not just implementation

Another part of how I use Claude is not just to build things, but to refine and improve them.

This can include:

• system architecture

• code structure and conventions

• testing strategy

• performance considerations

• maintainability and scalability

• security and documentation

These are all things I used to think through more manually, and now I find it helpful to involve the agent in that process as well.

It doesn’t replace thinking, but it helps get to a more polished result faster.

Preferences help, but don’t always persist

Another thing I do is ask the agent to keep certain preferences in mind.

This might include:

• coding style

• architectural choices

• naming conventions

• testing expectations

It can help reduce repetition and keep things more aligned with how I like to work.

That said, it’s not perfect. It doesn’t always remember or apply these consistently across sessions, so I do find myself repeating things.

I do think this is an area where things can improve, and I’m curious to explore better ways of handling this over time.

3. Shifting toward automation-first thinking

One of the bigger shifts for me has been moving away from doing things manually by default.

Now I tend to delegate a lot of repetitive or operational work to the assistant:

• creating feature branches

• opening pull requests

• drafting documents

• running repetitive git tasks

• setting up GitHub workflows

And more generally, it’s changed how I think about work.

Now when I see something manual, my first thought is:

can this be automated?

Sometimes that leads to:

• writing a small shell script

• creating aliases

• setting environment variables

• or adding a GitHub workflow to handle it

Individually these are small improvements, but over time they reduce a lot of friction.

4. Using different tools depending on the stage of work

Another thing I do sometimes is use non-coding agents, like ChatGPT, for earlier stages of thinking before switching to Claude for implementation.

This has been especially useful for:

• brainstorming ideas

• light planning

• product and UX thinking

• system architecture design

Not all work starts with code. Some of it benefits from a more open-ended space before getting into implementation details.

Once things feel clearer, I then move into Claude to actually build, refine, and execute.

It’s a simple separation, but I’ve found it helps me keep better structure between:

• thinking and shaping the problem

• and actually building the solution

Final thoughts

These are just some of the things that have helped me so far while working with Claude.

What stands out most to me is that this is still evolving. The more I use it, the more I notice small adjustments in how I think about building, structuring, and automating work.

Some of these things I’ve learned through trial and error, and others have come more naturally as I’ve kept incorporating AI into my day-to-day workflow.

I’m sure this will continue to evolve over time—and I’d be curious to hear how others are approaching it as well.