How Claude Code Changed the Way I Work (Design First, Code Second)

I've been using Claude Code for more than I initially expected. I started using it like 4 months ago, and it has definitely changed the way I work.

Not in the way you might think. It's not that I write code faster now. It's that I barely start by writing code at all.

How I Used to Work

Before Claude Code, my process was pretty standard. I'd get a requirement, and I'd start writing code. That was my way of exploring the problem.

While writing, questions would pop up in my head. I'd stop, think, research, find the answer, and go back to the code. The code would morph bit by bit as I figured things out. Maybe I'd write some tests for some parts, maybe not. Most of the time I was just using code as a way to explore the problem and possible solutions.

This process could take a while. And at the end, I was never really sure if I had landed on the best solution or just the first one that worked.

The Shift: Designing Before Building

Now, I have the initial requirement, and from the start, I go to Claude. But not to write code. To brainstorm.

First, we explore possible solutions together. I describe the problem, and we bounce ideas back and forth. What are the options? What are the trade-offs? What are we not seeing?

Then I pick the most promising direction, and we dig into the details. I have an interview skill that makes Claude ask ME questions about the solution. And man, I'm usually surprised by the questions. Things I didn't think about. Edge cases I missed. Assumptions I was making without realizing it. That process alone makes me think deeper about the solution than I ever did before.

The Design Document

From these explorations, I build a design document. But this is by no means a final document. It's a starting point.

I read it carefully. I start asking questions about it to Claude, making clarifications, improving it. I ask for examples. I ask about edge cases. I make sure the document is as clear as possible, so that when implementation starts, there's no ambiguity left.

I also keep a list of concerns and open questions at the end of the document. The idea is to solve all of them before writing a single line of implementation code.

It seems like a lot of work. But for complex problems, this is gold. By the time I'm ready to implement, I have a clear understanding of the problem AND the solution. No more "figure it out while coding."

The Feedback Loop

Here's where it gets even better.

I share this design document with my team. I ask for feedback. And I usually get good stuff, concerns I didn't think about, questions that reveal gaps in my understanding. Maybe I just didn't have enough context about a certain part of the system, or maybe I simply missed something.

The fun part is I take this feedback, go back to Claude, and start the brainstorming process again. But this time, with all the previous context and feedback baked in. Each iteration builds on everything before it.

I've created 3 to 5 different solutions for the same problem this way, each one taking into account the previous context and feedback, with pros and cons for each. The result is almost always a much better solution than the first one. And it forces me to think more deeply, looking for the simplest solution that solves the problem, not just the first thing that came to mind.

The Agents

I have 4 agents that I use during design and implementation:

• Laravel Architect - focused on the design and architecture of the solution
• Pest TDD Expert - focused on writing tests and making sure the solution is testable
• Security Expert - focused on security concerns and making sure the solution is secure
• Browser Testing Expert - focused on writing browser tests and making sure we cover all user interactions

I ask these agents to review the design and the implementation plan, and give me feedback and suggestions. This is really helpful, because they can point out things I might have missed, or suggest better approaches I hadn't considered.

I also created a "Laravel Taste Validator" skill, which has a growing list of principles and best practices for Laravel development. I ask Claude to review the design and implementation plan against those principles. I usually get good ideas about how to use Laravel features in a better way, things I wouldn't have thought of on my own.

The Implementation

With the polished design document and the implementation plan ready, I start building with Claude.

When the implementation is complex and has many steps, I execute the plan step by step. After each step, I review the code, validate it with the agents and the taste validator. When I'm happy with the code, I commit and tell Claude to move to the next step. This way, I make sure I'm on the right track and I'm not wasting time implementing something that's going to need a rewrite.

When the implementation is simpler, I tend to just implement the whole thing and review the code at the end. But even then, I run it through the agents and the taste validator before committing.

What Changed

The outcome of this process is that I end up with much better solutions. Well designed. Well tested. Secure. Following best practices. And more importantly, solutions that I have a deep understanding of. Solutions I'm confident about.

I feel like I'm learning a lot more than before. Every brainstorming session, every interview question Claude asks, every piece of feedback from the agents, it all pushes me to think deeper. I'm becoming a better developer not by writing more code, but by thinking more carefully about the problems I'm solving.

Coming Back to Our Roots

Here's the thing. Our job as developers was never to write code. It was to solve problems in the best possible way. Code was just the tool we used to express the solution.

But we spent so much time in the mechanics of writing it, debugging syntax, researching APIs, wiring things together, that the actual problem-solving got squeezed into the margins. The thinking happened between the typing, not before it.

Now, with tools like Claude Code, the mechanics are handled. And what's left is the part that always mattered most: understanding the problem deeply, designing the right solution, and making sure what gets built is actually good.

This isn't a shift to some new role. It's coming back to what development was always supposed to be about. We can finally spend most of our time on the actual work.

The code is the output. The thinking is the work.