Peggy Wu's Life Lab | Claude Code Didn't Change My Coding. It Changed How I Work.

 

Lately, whenever I get together with friends, our conversations somehow end up revolving around AI tools such as Claude Code, Codex, ChatGPT, and Copilot.

When I stop and think about it, Claude Code has quietly become an indispensable part of my daily work over the past few months. One of my teammates recently joked that the person he talks to most every day is no longer his family or coworkers. It's Claude Code. 😄

Like many people, I started by experimenting. Over time, I gradually found a workflow that fits the way I work. It has saved me a significant amount of time and made many repetitive or tedious tasks much easier.

But looking back, the biggest benefit wasn't learning a new tool. The more interesting change was how it gradually changed some of my work habits.

Here are the three changes I've noticed the most.

1. I've Become More Protective of My Focus

When I first started using Claude Code, I loved the feeling of doing multiple things at once. One agent was analyzing a problem, another was gathering information, and a third was writing code. At the same time, I was replying to Slack messages, reviewing Jira tickets, and discussing pull requests with Copilot or Claude.

For a while, it felt incredibly productive.

There was even a period when I had several Claude Code windows running simultaneously, each handling different tasks in the background. I've always been fairly confident in my ability to multitask, so watching everything move forward at the same time felt rewarding. My output increased, and I genuinely felt like I was operating at a higher level than before.

The problem was that something else increased as well: my fatigue.

After a few weeks, I started noticing that I felt mentally drained at the end of the day. Sometimes the feeling even carried over into the next morning. There were nights when I went to bed knowing I had accomplished a lot, yet my brain felt completely exhausted.

Eventually, I realized what was happening.

Claude Code was reducing the effort required to execute tasks, but it wasn't reducing the effort required to manage attention. Every time I switched contexts, jumped between conversations, or tried to remember where I had left off, there was still a cognitive cost.

Once I recognized that, I started making deliberate adjustments. I stopped checking every running agent every few minutes. I became more comfortable focusing on one important task at a time. Instead of letting multiple windows constantly compete for my attention, I tried to be more intentional about where my focus went.

After a few weeks, I noticed a meaningful difference. The quality of my work became more consistent, and my energy levels felt much more sustainable.

The irony is that Claude Code gave me more ability to multitask. What it ultimately taught me was the value of focus.

2. I Spend More Time Thinking Before I Start

If you give me a problem, my instinct is usually to jump in and start solving it immediately.

That tendency became even stronger when I first started using Claude Code. Everything felt fast. Ideas could be tested instantly. If something didn't work, I could simply change direction and try again.

To be honest, it felt a bit like getting a new toy as a child. You don't read the instructions. You just start playing and figure things out along the way.

The problem is that many of the apparent time savings weren't actually savings. I was simply postponing the thinking.

If I hadn't fully understood the requirements, clarified the edge cases, or defined what success looked like, I would eventually spend the time anyway through revisions and rework.

One experience stands out clearly in my memory. I enthusiastically started implementing a solution, only to realize halfway through that I had misunderstood a key requirement. Most of the work I had already completed needed to be redone. It was frustrating, but it taught me an important lesson.

The problem wasn't Claude Code.

I simply hadn't thought things through.

These days, whenever I'm working on something more complex, I take a different approach. Before I start building anything, I spend some time organizing my thoughts. If there are known requirements, I try to document them clearly and answer a few simple questions:

• What problem are we actually trying to solve?

• What approach, logic, and steps make the most sense?

• What does success look like?

It's essentially a lightweight design document. Nothing formal or complicated. Just enough structure to make sure the direction is clear.

Then I ask Claude to review the plan. I encourage it to challenge assumptions, point out risks, and ask questions. Quite often, those questions reveal gaps in my own thinking that I hadn't noticed.

Only after the plan feels solid do I move into execution.

The biggest benefit isn't speed. It's avoiding unnecessary rework. More importantly, it has reminded me that productivity often depends less on execution and more on the quality of thinking that happens before execution begins.

3. I Spend More Time Working on Real Bottlenecks

If you asked me about the biggest benefit I've gained from the past few months, my answer wouldn't be automation.

It would be perspective.

For the first time in a long while, I feel like I have more room to think beyond the immediate task in front of me.

When work gets busy, it's easy to focus entirely on execution. Is the feature finished? Is the bug fixed? Has testing been completed? Before long, every day becomes a race to get through the next item on the to-do list.

But the longer I've worked as a manager, the more I've realized that the biggest obstacles to team productivity rarely live inside the code itself.

More often, they live inside processes, communication, and organizational structure.

Recently, during one-on-one meetings, I've started asking a simple question:

What's the biggest thing slowing you down right now?

The answers vary. Sometimes it's technical. Sometimes it's procedural. Sometimes it's a cross-functional issue. Sometimes it's something surprisingly simple.

I remember one discussion where I initially assumed we were dealing with a difficult technical challenge. After digging deeper, we discovered that the real issue was unclear ownership between teams. The problem had been slowing progress for weeks, and no technical solution was going to fix it.

Many of the most important bottlenecks require communication, alignment, judgment, and prioritization. Those are still very human challenges, and they remain an important part of leadership.

The time Claude Code saves me doesn't necessarily lead to more coding. Instead, it gives me more opportunities to focus on things I've always known were important but never seemed urgent enough to prioritize.

Final Thoughts

Looking back, what stands out most isn't how much faster things have become, although they certainly have. Research is faster. Writing is faster. Coding is faster. Testing ideas is faster.

But as execution becomes easier, other constraints become more visible.

Focus.

Thinking quality.

Communication.

Alignment.

These things haven't become less important. If anything, they've become more important.

When everyone has access to powerful tools, the difference is no longer just who can move faster. It's who understands what matters, who can identify the right problem, and who can focus their energy where it creates the most value.

For me, that's been the biggest lesson of the past few months. Claude Code didn't simply change how I write code, it changed how I think about work. And it left me with a question I'm still exploring:

As more routine work becomes easier, where is my time most valuable?

I don't have a perfect answer yet.

But I suspect that question matters far more than learning the next tool.