
# Grieving the Death of Coding

Coding is dead. It may not have hit your organization yet, but it will. The act of typing in programming language syntax letter by letter is over. No more autocomplete. No more memorizing IDE shortcuts. No more vim motions you spent years wiring into your fingers. No more extract method, inline variable, rename—the physical rhythm of reshaping code by feel. That's over.

In April 2025, I built my first RAG pipeline with a coding agent. A knowledge base chatbot—from scratch, with an AI and human collaborator. Learning something new, watching it actually work, building alongside a machine that could keep up. It was thrilling.

By July, the thrill had curdled.

## Denial

I started going back and forth with the agent 20 times to get code to a standard I was satisfied with. One week I was excited about a new model. The next I wanted to throw the whole thing away and go back to my IDE.

"Maybe I'll just take a break from agents," I told myself. "Go back to traditional coding for a while."

That break never lasted.

## Anger

By August, I was watching the industry lose its mind. Developers spinning up 10 agents at once. Working on 10 user stories simultaneously. Bragging about speed.

WIP (work-in-progress) should be 1. We can't even ship one thing well most of the time—why would I want 10 tracks of work that I then have to code review at the end?

The problem wasn't the tool. The problem was that nobody was asking what problem are we solving?

## Bargaining

In September, I rediscovered TDD.

"Fine," I thought. "If I'm going to use coding agents in production, we're doing it right." TDD. Prefactor before adding changes. Clear, readable tests that read like specifications. Pair with the agent AND a human to reach an optimal design.

My bargain wasn't retreat, it was: I'll accept this, but on my terms.

## Depression

November. I attended the Samman Coaching Open Space looking for someone who would talk me out of this.

Someone who would tell me I was wrong, that I shouldn't be going down this path.

Nobody did. Everyone was in their spring—happy, excited, discovering possibilities. The same stage I'd been in six months earlier.

I found Llewellyn Falco and told him one-on-one: "I'm disappointed. I **enjoy** coding. I miss it."

He said his grandma **enjoys** knitting sweaters. But that's not what we do. We've found a better tool and we need to accept it.

It snapped me out of it. The next day I was back on the coding agent bandwagon.

But February brought it back. At Artium, the consultancy I work for, we read [AI Vampire](https://steve-yegge.medium.com/the-ai-vampire-eda6e4f07163) by Steve Yegge. On that call, I admitted something out loud: I have an [AI addiction](https://diamantetechcoaching.com/newsletter/issue-006-AI-addict). If AI is supposed to make our lives easier, why am I working more than ever? Taking fewer breaks? Prompting an agent every chance I get?

My colleagues related. I wasn't alone on this one.

## Acceptance

Acceptance isn't "okayness." It's accepting the new, permanent reality.

I can still have fun refactoring code—through agents. Now I'm focused on optimizing for quality and optionality, not speed. I still ship faster than before, but I always want to see how far I can push the maintainability of the software I deliver.

I don't want to rush. I'm a crafter. I've been one for years. Whether I write code in an IDE or guide a coding agent, I will deliver high-quality software to users in small batches and delight customers through agility and fast feedback.

For years I've focused on good design, TDD, refactoring—principles of software that haven't changed much in 50 years. I never chased frameworks, languages, or tools. That attention to software design has paid off.

Coding is dying, but engineering is alive and well.

If you're somewhere in this journey—the excitement, the frustration, the loneliness of being ahead of the curve, hang in there. There's pain around the corner. There will be ups and downs. But the craft survives the tool.

Know a developer who's struggling with this shift? Share this with them. Sometimes it helps just knowing you're not alone.


Grieving the Death of Coding


# Confession

I'm a technical coach who teaches teams to slow down, write tests first, and understand the code they're writing. But I
haven't written code myself in over 6 months. I prompt agents all day and fill the wait time with Slack and backlog grooming.
I can't even write this article on my own...and that's part of the issue.

# What my days actually look like

Usually the user story starts out as a vague ask from a product manager or sales person. I talk it out with my pair and
start prompting a coding agent to plan the approach. I read the plan, go back and forth correcting it. While I wait for the
code to be produced, I'm catching up on Slack conversations, looking ahead at other work to be done in the backlog, or
prompting another agent. Nowadays staying busy has become important to me for some reason. I never used to be like this.

# How I got here

In July 2025, I started with a new client building AI workflows for them. Later in December I became the team captain
and had more responsibilities to take on. Our output was high for a month or 2 to meet deadlines for a conference, so
naturally expectations got higher.

I used to meditate for years. My last class I took was a 3 day silence retreat before my son was born. He's now 20
months-old. I've always been a single tasked person. That's why I gravitated towards test lists and TDD so much. I
also used to be very intentional about taking breaks. When we remove ourselves from the problem, our brain continues to chew
on the problem and we can come back to the work knowing exactly what to do next. I've lost these habits and developed other
ones instead. Now I prompt and manage AI coding agents. If it can't figure out the issue, I detail the issue in a markdown file,
bead, or task and find another model or session that can crack the solution. This is my life now. I've learned to accept it.
Most days it's fun, but the burnout signs are different. When my days are over, my head is pounding from all the cognitive load
I've been juggling throughout the day.

# The moment that cracked it

In our agentic codebase, we have a vibe-coded evaluation framework that I don't fully understand. It has python scripts to run
experiment datasets locally and push the results out to Datadog. This week while improving the visualizations and results one
feature got lost while adding the others. I've tried 10+ times to prompt my way past it. But I can't get any agent to figure it
out. And I can't figure it out myself, because I don't fully understand the code. The irony is a TDD coach refusing to sit down
and read the code because it feels too slow now. Who have I become?

# Today my body stopped me

This morning, my body refused to go back to that issue. I took the day off sick. I think my body got sick so I didn't have
to face this for another 6+ hours. Two days ago we talked about Steve Yegge's [AI Vampire](https://steve-yegge.medium.com/the-ai-vampire-eda6e4f07163)
article at work and it made me take stock about my relationship with LLMs. During the meeting, people were running multiple
agents in the background. I had prompted an agent just before the meeting had started. I felt this pull to check on the LLM's
response, but I didn't. I admitted that I have an addiction to AI. The power it gives software developers is incredible and
it can be dangerous to our mental health as well. The options we have at our fingertips is amazing. But at what cost?

# What I'm going to do about it

I want to take more breaks. I want to start exercising again and going outside. I want to work on less AI-coded side projects.
I want more silence, less devices, and to get a stable reading habit back.

I feel a lot of pressure to stay informed about AI news. I coach teams on AI agents so I feel like I need to understand
the landscape. But I need to be okay to take a break from the AI news and just relax and be. I used to be able to mindfully
breathe and focus on one thing. I want that back.


I'm Steven, and I'm an AI Addict


# The TDD Mindset: Beyond Writing Tests First

If you've practiced Test-Driven Development for any length of time, you've probably noticed something interesting: the habits stick around even when you're not writing tests first. There's a way of thinking that emerges from TDD practice that fundamentally changes how you approach programming problems. I call this the **TDD Mindset**.

This mindset transcends the red-green-refactor cycle and becomes a broader approach to building software. It's about thinking in small steps, seeking fast feedback, evolving design through refactoring, and treating development as a series of experiments. But there's much more to it than that.

# The Core Attributes

## Small Steps and Iterative Thinking

Developers with the TDD mindset are masters of **task and story slicing**. They instinctively break down large problems into smaller, manageable pieces. This isn't just about making work easier—it's about maintaining a steady rhythm of progress and always having working software.

YAGNI (You Aren't Gonna Need It) becomes a mantra. I never add a feature or enhancement until I see a concrete problem that this new thing would solve. Everything that gets added serves a purpose and contributes real value to the overall product. This discipline prevents the accumulation of speculative code that complicates the system without delivering benefits.

## Outcomes-First Thinking

Instead of asking "what code should I write?", the TDD mindset flips this to "what behavior do I want to see?" You're always thinking about the big picture—how to integrate layers of the system to get the product into users' hands.

This starts with writing that first test, which is usually a slow process. But there's incredible learning, exploration, and clarification that comes from this approach. If a user story isn't clear on the user outcomes, behaviors, and business rules, someone with the TDD mindset will raise that concern early and get more information. They're thinking about what the user wants to do, not just what features to implement.

## Fast Feedback in All Forms

Fast feedback doesn't just mean quick test execution—it means **early feedback** in every form. You get feedback on incremental progress through working software. You get feedback from consumers because you can demonstrate value throughout the development process. You get feedback on whether a design is overly complex or hard to understand by interacting with it through behavior-focused automated tests.

By doing this, you see incremental progress and maintain working software the entire time. This means you're always ready to demo to stakeholders and show the progress you've made.

## Controlled Risk-Taking and Quality

Developers with this mindset are usually fairly confident and comfortable taking safe, controlled risks. They're well-versed with their refactoring tools and skilled at making tidy improvements to hard-to-read code. They understand that being comfortable with "good enough" intermediate states is crucial—you always come back and add more to it.

However, the TDD mindset is not about cutting corners. The goal is always to build high-quality production software, but you can iterate toward that quality. It's the classic "Make it work, make it right, make it fast" progression.

## Design Evolution and Abstraction Timing

One of the most sophisticated aspects of this mindset is **sensing where the design is going**. You develop an intuition for when to add appropriate abstractions and rich domain models that express what the context needs.

Abstractions typically emerge due to code duplication and the need for a centralized place to handle common concerns. The trick is timing: do this too early, and you overengineer everything. Do it at the right moment—just before a feature would push you into complex and messy code duplication—and you're golden.

## Simplicity and Clarity

There's a strong bias toward simplicity, but it's **earned simplicity** through iteration. Simple solutions are preferred over complex ones. Inherent complexity is accepted when necessary, but accidental complexity is ruthlessly eliminated.

Obvious code is always better than clever code. Humans need to read other humans' code, and clarity trumps cleverness every time. This isn't about writing dumb code—it's about writing code that clearly expresses its intent.

## Systems Thinking

The TDD mindset cultivates **systems thinking**—understanding how changes ripple through the codebase and how different layers integrate. You're not just solving the immediate problem; you're considering how your solution fits into the larger system and how it will evolve over time.

## The Business Impact

One of the best ways to meet deadlines set by the business is to cut scope and deliver pieces of functionality at a consistent rhythm. The TDD mindset prioritizes working software that delivers value end-to-end. This means you're always in a position to ship something valuable, even if it's not the complete original vision.

This approach transforms how you communicate with stakeholders and product people. Instead of big-bang releases, you deliver continuous value and maintain options for course correction based on real user feedback.

## Beyond the Red-Green-Refactor

What I find fascinating is how these attributes become part of your thinking regardless of whether you're actively practicing TDD. The mindset becomes a lens through which you view all software development challenges.

You start to see development as a series of experiments where you're constantly learning and adjusting. You become comfortable with uncertainty because you know you can iterate your way to better solutions. You develop confidence in making changes because you understand how to make them safely and incrementally.

The TDD mindset isn't just about testing—it's about building software in a way that maximizes learning, minimizes risk, and delivers continuous value. It's a fundamentally different way of thinking about the craft of programming, one that I've found makes me both more effective and more confident as a developer.

Whether you practice TDD religiously or have never written a test first in your life, these mindset shifts can transform how you approach building software.


The Habits That Stick: What TDD Really Teaches You About Programming


Every day, developers complain that AI assistants write terrible code, miss obvious bugs, or spiral into endless loops. Meanwhile, I'm shipping production features faster than ever with the same tools. It took me months to realize that working with AI isn't about better prompts—it's about applying the same collaboration skills I use in pair programming.

Today I’d like to share 10 AI-driven development heuristics that I’ve been using over the last few months to build real world production grade software that real users are using today.

Before we get into it, let me provide some definitions, disclaimers, tools, and context.

## Definition

Heuristic — practical approach to solving a problem when finding the perfect solution would be too slow, complex, or impossible

## Disclaimers

_I am using "heuristics" loosely here to cover rules of thumb, workflows, and practices_

_You may be using different coding agents, so some of this may or may not apply to you. I’ve tried to keep this general, but I’m [just sharing](https://justsharing.dev/)._

## Tools

- Claude Code (I will refer to this agent as Claude, it, or bot)
- Webstorm (my IDE of choice)
- Git (frequent commits, because bots can mess things up quickly)

## Context

I gathered all of these heuristics while delivering user stories for an actively used product. These are not necessarily the same heuristics I use when [vibe coding](https://simonwillison.net/2025/Mar/19/vibe-coding/) on a personal project.

## 10 heuristics

### 1. Stop the bot when it starts to wander and gets lost

After prompting Claude to introduce a small increment of functionality, I continue to pay attention. I read almost everything it’s doing, thinking, planning, and pondering. Instead of treating Claude like a worker bee, I treat it as my pair. We’re collaborating to reach an optimal solution that works and is easy to extend.

Over the course of this reading, I sometimes don’t agree with specific approaches Claude decides to take. I press the `esc` key and inspect even further. Pressing the `esc` stops the bot. This gives me time to read the same files Claude is reading and determine what I think the best approach is. Sometimes I realize that it’s taking the right approach and tell it to continue. Claude will pick up right where it left off as if I never stopped it at all.

Other times, I see a better way of approaching the problem or the root cause of the error. Instead of just telling Claude to continue, I will relay my findings to it. This usually results in Claude’s favorite saying, “You’re absolutely right!”—and it reevaluates its task list and continues with the new information in mind.

![Stopping Claude Code](/images/stop-claude-code.webp)

Instead of waiting for Claude to finish the whole solution, I actively review its thought process. This is a habit I’ve picked up from many years of pair programming. I always want my pair and me to be on the same page and well aligned with the path we’re taking. While pairing, it’s common to stop and talk about what’s happening, where we’re going, and if that’s still a sensible direction to go. These constant check-ins save a lot of time and are part of the work. This is collaborative engineering. I’ve brought this collaborative spirit to my interactions with Claude and found it to be incredibly rewarding

### 2. Find the issue myself

One of the biggest arguments against using coding agents is that they get stuck in loops when trying to debug and investigate tricky bugs and errors. I’ve experienced this myself, but it’s not just Claude solving the issue—it needs my input and assistance too! I will give Claude 2–3 chances to find the root cause and resolve the issue before stopping it and investigating myself. This happened just the other day.

Claude and I were adapting an LLM test to use [Test Containers](https://testcontainers.com/?language=nodejs) instead of a locally running MySQL instance. It seemed like everything was set up correctly, but when adding the next test that would trigger reading the test data, the tool call of the Chat Assistant failed. So I put told Claude to fix it and make the test pass. It added tons of logs and tried an array of different things, but it couldn’t tell me why the test was failing. After a few rounds of this, I stopped Claude and investigated the issue myself.

I set up breakpoints in WebStorm and finally got to the root cause of the problem. Any reads that the function calls made were not targeted at the correct MySQL instance. The app was set up in a way that on startup the database connection was initialized. When running these tests, we wanted to use only the Test Containers database. Now that I knew exactly what the issue was, I relayed it to Claude, and it pursued several different solutions.

Unfortunately, I had to bail on the Test Containers approach because of how this monolith was structured, and we could not justify refactoring it to make it easier to substitute databases on startup. However, the point here is just telling Claude to fix the issue is not enough all the time. For more complex issues, a human getting involved and detecting the root cause is less expensive both in time and token costs. Most times, once Claude understands the issue, it’s able to engineer a working solution.

### 3. Extended Thinking Modes

This mode costs more, so I use it pragmatically. Here are a few situations I will trigger the thinking modes:

> After Claude has failed a task once, and it seems to be getting confused...
> <br/>this usually gets it back on task and either leads to a solution or helps me to discover the issue for Claude

> On an initial prompt that seems very complex and I want Claude to use as many of its resources

> Before embarking on a complex task, I may prompt Claude to think and plan and discuss different options

I usually start with think hard and go to the higher thinking modes on later prompts if needed. Like humans, coding agents perform better when they track their thought process. Thinking aloud is a crucial part of pairing, so a mode like this makes it even easier to pair with Claude.

All you need to do is say the 'magic' word somewhere in your prompt. "Each level allocates progressively more thinking budget for Claude to use." — [Claude Code Best Practices](https://www.anthropic.com/engineering/claude-code-best-practices)

The modes are:

- think
- think hard
- think harder
- ultrathink

### 4. Ask me questions

Sometimes, at the end of an initial prompt I will tell Claude to ask me any clarifying questions if needed. The phrasing here is important. If you tell Claude to ask you questions, it will do so, and they may be silly and unnecessary questions that it could explore on its own using its many tools.

Some reasons why I tell Claude to ask questions are:

- to give it any missing information it needs to solve the problem
- to explore different solutions
- to gauge whether Claude understands the task at hand

It can be tedious to answer all the questions. I usually skip questions that are not relevant, but it can help get it and I aligned on the task.

### 5. Claude the student

Coding agents can do some amazing things for professional programmers, but they need to be mentored along the way. I continually educate Claude on how to iterate towards maintainable software. We debate each other on Object-Oriented principles, DDD, refactoring, and iterative development. Coding agents are willing pairs that will conform to your style, but you must be patient and repetitive. I store learnings in a directory of .md files that I have a custom command for. After a session and before clearing or compacting, I can export all of my teachings of how I approach programming to an .md file that Claude can reference in a future session. This way the learning doesn’t get cleared out, and Claude can continue to grow as we pair together.

### 6. Working → Maintainable

After the code works, I don’t stop there. I want to improve the design. Software design is all about making the next change easy. I may ask Claude to review its own code or suggest some refactorings that will improve the design.

I’ve heard some people say that in the future the code won’t even matter anymore. We will just be prompting and communicating with an agent—the code will never be looked at so who cares if it’s not readable. Maybe that will be the reality one day as coding agents improve more and more, but today code reviews are still a reality. Humans still need to be able to understand the code you’ve written no matter if it was generated by a bot or not.

In this AI coding world, refactoring remains a huge part of my development process.

As software products evolve and grow, continual change must be supported or else features that used to take a few days now take a few weeks. Estimations become impossible and even the coding agents can’t add new features because no one bothered to care for the software design.

I iterate on Claude’s code and turn it into something I’m proud to ship to production.

### 7. Commit before prompting

Working with Claude has made me even more disciplined when it comes to committing to version control frequently. I never know what crazy ideas Claude is going to spout out so I want to be in the position that I can revert its changes and start over again.

My workflow:

1. prompt until the code works
2. commit
3. refactor with Claude or myself
4. commit
5. push remotely

### 8. Make Claude experience the failure

I used to copy and paste errors into Claude. Honestly, I still do sometimes, but I try to have Claude run the app or the tests or whatever it needs to see the issues first hand. This process puts Claude into a loop where it can try something and get feedback.

### 9. Is there a simpler way to do this?

This is one of my favorite followups to Claude’s code generation. It should be specific, but if the task is small I will ask generally, “Is there a simpler way to do this?” Yes is usually the answer and Claude tries to simplify the approach.

Most of the time, I see a better way and want to challenge Claude to simplify the approach. Other times I don’t necessarily see a simple way or even understand the code, but I just ask it because it generally produces great results.

### 10. Work from a task list

All of my career I’ve had a habit of working from a task list. I make a Markdown file and organize my thoughts with my pair. This habit hasn’t changed working with Claude and has been even more valuable.

I have a custom slash command that instructs Claude to go through my todo list and work on the highest priority item.

Benefits of using a task list:

- Reduces cognitive load
- Focus on one thing at a time
- Reduce the risk of forgetting things you wanted to do

## Working with AI is like learning to pair program all over again.

When I first started pair programming, I had to learn a whole new way of working—communicating constantly, staying aligned, and checking in with my pair. It was uncomfortable at first, but it made me a better developer.

Working with Claude feels remarkably similar. These 10 heuristics aren't just tips and tricks—they're the foundation of building a sustainable relationship with AI that actually makes you a better programmer.

**Don't treat AI like a magic wand—treat it like your most eager junior developer.** One who's incredibly capable but needs guidance, mentoring, and clear direction. One who benefits from your experience but also challenges you to think differently.

The future belongs to developers who can effectively collaborate with AI while maintaining the craftsmanship that makes software maintainable and elegant. These heuristics will help you get there.

---

_Want to consistently ship high-quality code that's easy to change and understand? [Subscribe to Refactor to Grow](https://subscribepage.io/refactor-to-grow) for bi-weekly insights delivered to your inbox._


10 Heuristics for Pairing with Claude


I've been pair programming with AI coding agents for over 3 months, and I've noticed something crucial: bots generate code so fast that we often skip a vital step. The refactoring step.

When the bot generates code, resist immediately moving on to the next feature. Instead, take a moment to understand what just happened. Read through the code. Question the design decisions. Make it yours.

Yes, you can ask the AI to refactor for you. But unfortunately, LLMs still hallucinate and tend to make large, sweeping changes that introduce subtle bugs. That's why you need solid test coverage before letting any bot refactor the code.

In the [previous issue](https://diamantetechcoaching.com/newsletter/issue-002-refactoring-agent-code), I talked about how coding agents can refactor the code it generated. This process needs a solid test suite because coding agents are not as reliable at refactoring as the automated refactorings in IDEs.

As a long time practitioner of TDD, I’ve been experimenting with a different way of programming inspired by Dan North’s technique of [Spike and Stabilize](https://dannorth.net/the-art-of-misdirection). Over the course of my career, I’ve mostly been in large enterprise organizations that move slowly and gradually. Health insurance and banking industries are highly regulated so being super fast and risky is not wise in this context. However, I’ve now had my first startup experience where there’s high pressure to deliver to users quickly.

## Spike and Stabilize in Action

What started out as a spike and proof of concept ended up turning into the real thing. Over the course of a week, my pair, Claude Code, and I created a POC of an LLM Chatbot. It had a RAG pipeline that imported the companies’ knowledge base articles into a vector database so the LLM could use that as its context to pull from.

### LLM Terminology

RAG stands for retrieval-augmented generation. Instead of allowing the model to pull from all of its training data, you give it access to only specific data that it determines to be relevant to the provided query. This relevant context is where the vector database comes into play. The initial query is embedded (turned into a vector) and used in a cosine similarity lookup. Whatever embeddings are most related to the initial query will be added to the context of the prompt and the LLM will use that to create a response it chooses that best answers the query.

### Spike → prod deploy

I’ve seen spikes turn into production deploys many times over my career and have been warned against it. At one point, I said to my pair—”Now that we’ve seen how to build this, we can start from scratch and use our learnings to build it the right way (using TDD and evolutionary design)”. And they said “Why don’t we just use this? Is this the wrong way?”. They were challenging the dogmatic views of spike vs. TDD and I agreed. Except for the frontend, we used every piece of that original POC and got it ready for production. Without realizing it, we were applying the Spike and Stabilize technique.

Over the next week, we focused exclusively on refactoring. There were parts of the code that were complex and we didn’t understand, so with a mix of bot-driven refactoring and classic IDE-driven refactoring we started to make the code our own.

Some of the refactorings we did were:

- introducing clean architecture (segregated packages of infrastructure, domain, etc.)
- introducing domain objects to encapsulate complex article chunking behavior
- started moving toward a more generic architecture as we knew we needed to build at least one more pipeline

We also improved the performance by adding Node Streams and making the number of articles pulled at a time configurable.

### Build in quality last?

Instead of building in the quality up front as I am used to by writing tests first, we wrote the tests as needed. Early on we only had 1 test 😯! It was an edge-to-edge acceptance test that faked out the source of data and the sink datasource. It gave us roughly 40% of coverage all on its own and temporarily used [approval testing](https://youtu.be/vNaHTSuH6Bw?si=xPh4clCREf-GEl-U&t=1604) to capture the approved behavior. Before that we would run the pipeline and import 10 articles to verify no functionality had broken. We didn’t have edge cases covered, because we were focusing on the core functionality at that time.

As we started to separate the I/O from the behavior, it was easy to add unit tests to verify some of those edge cases. This helped us identify some over-engineering our coding agent had done and we were able to simplify the logic further.

For untested code I used automated refactorings in Webstorm or carefully carried out manual refactorings with verification by running the pipeline. For tested code, I would ask the coding agent to carry out more complex refactorings that would take me more time to do on my own.

One huge benefit of refactoring the code myself is I get to truly understand the generated code and make it my own. Eventually we had to share our work with the rest of the team so we needed to understand how every part of the pipeline worked so we could confidently explain it.

One rule I always follow in this new paradigm of programming is:

**Never ship code to production that you don’t understand.**

Once we refactored the app to have more structure and consistent patterns, it made the work of the coding agent more consistent and reliable. Bots, as do humans, tend to generate new code with a similar style as to what already exists in the codebase. So if the codebase is unstructured and highly coupled then the bot will generate code to conform to this norm. However, when software design concepts like ports & adapters, DDD, and encapsulation are consistently applied across the codebase then the bot will add to it with more structured code that aligns with that design.

## Make it work → Make it right → Make it fast

In the end, this pipeline that will have light usage over the years only had 60% test coverage. We were okay with this because of the context we were in. If this were an application that was used daily by thousands of users we would have poured even more effort into the quality. There will always be a long list of improvements, tweaks, and design enhancements that can be made, but the pragmatic engineer knows when enough is enough, ships it, and moves on.

### When to use this approach

This spike and stabilize method works best when you're exploring unfamiliar technologies or working in fast-moving environments that prioritize rapid iteration over upfront design. It's particularly effective in startup contexts where market feedback trumps perfect architecture, or when you're prototyping with new AI tools and frameworks where the "right way" isn't yet established. However, avoid this approach for mission-critical systems, heavily regulated environments, or codebases that will immediately scale to thousands of users where comprehensive test coverage is non-negotiable.

I’ve shared my experience with you today as one way to collaborate with coding agents and get the best out of them.

Our workflow looked like this:

1. Prompt the agent to add a new behavior (no tests)
2. Run the app to confirm new functionality
3. Review the code and work with the bot to improve poor design decisions
4. Evaluate if tests are needed
5. Refactor the code on our own to understand the [theory](https://pages.cs.wisc.edu/~remzi/Naur.pdf)
6. Evaluate performance needs

If your context needs a different way of working, then try some other approach, but be willing to experiment, refactor often, and challenge your coding agents to write simpler code that solves the problem at hand.

---

_Want to consistently ship high-quality code that's easy to change and understand? [Subscribe to Refactor to Grow](https://subscribepage.io/refactor-to-grow) for bi-weekly insights delivered to your inbox._


Spike & Stabilize with Coding Agents


Last issue, I argued that refactoring skills are more valuable than ever in the age of coding agents. Today, let's get tactical. I'll show you exactly how I safely refactor code generated by coding agents.

## The Problem with Agent-Generated Code

Coding agents generally produce working code, but it's sloppy. Much like the kind of code I write when making a test go green in TDD. The agent has solved the immediate problem, but the design often suffers.

Here's what I consistently see in agent-generated code:

- **Long Parameter Lists** - Functions that take 6+ parameters
- **Feature Envy** - Methods that seem more interested in other classes
- **Primitive Obsession** - Using strings and integers instead of domain objects
- **Duplicated Logic** - Similar code scattered across multiple places

These are classic code smells that signal design problems lurking beneath working code.

## Bot Refactoring Protocol

When I get working code from a bot, I never ship it immediately. Here's my process:

### 1. Review the Diff

I carefully examine what the agent changed or created. I need to understand the solution before I can improve it.

### 2. Take Note of Code Smells

I scan for the common patterns - long parameter lists, feature envy, duplicated logic. After three years of studying refactoring, these jump out immediately.

### 3. Remove Comments

Agent-generated comments are usually noise. Good code should be self-documenting. (I do this myself in a JetBrains IDE)

### 4. Refactor with Test Safety Net

I ensure there's test coverage, definitely at the acceptance test level. Then I start refactoring using specific vocabulary with the agent. If I don't have solid test coverage then I will refactor using automated refactoring tools that are much more deterministic and reliable. The coding agents have improved a lot, but the way they refactor code is error-prone. I'm looking forward to the day Claude Code can use the refactorings tools in IntelliJ via MCP.

## Real Example: Parameter Object Refactoring

Let me show you this in action. Recently, a coding agent generated this method:

```java
public void processOrder(String customerId, String customerName,
    String customerEmail, String productId, String productName,
    double productPrice, int quantity, String shippingAddress) {
    // ... implementation
}
```

Instead of accepting this parameter soup, I coached the agent:

**Me:** "This method has a Long Parameter List code smell. Let's introduce Parameter Objects to group related data. Create a Customer class and a Product class."

The agent immediately understood and refactored to:

**Bot:**

```java
public void processOrder(Customer customer, Product product,
int quantity, String shippingAddress) {
// ... implementation
}
```

Much cleaner. But I wasn't done.

**Me:** "We still have primitive obsession with the shippingAddress string. Let's create an Address value object."

**Bot:**

```java
public void processOrder(Customer customer, Product product,
int quantity, Address shippingAddress) {
// ... implementation
}
```

## The Key: Speak the Language

Notice how I didn't say "make this better" or "clean this up." I used precise refactoring terminology:

- Long Parameter List
- Parameter Objects
- Primitive Obsession
- Value Object

The coding agent understood exactly what I wanted because I spoke its language—the language of refactoring patterns.

## Beyond Code: Strategic Thinking

This isn't just about cleaner code. Each refactoring makes the next feature easier to add. When the next requirement comes in—maybe we need to handle international shipping—the Address value object gives us a natural place to extend functionality.

> "Make the change easy, then make the easy change." - Kent Beck

## Your Next Steps

- **Learn the vocabulary** - Start with 5 common code smells and their refactoring solutions
- **Practice with your next agent session** - Don't accept the first working solution
- **Build the habit** - Refactor agent code before you ship it

**Remember:** Coding agents give us working code fast. But professional developers deliver maintainable code that evolves gracefully with changing requirements.
Anything you ship to production you **must understand**, and refactoring is the best way I know to understand code. That's where your refactoring skills make all the difference.

Have you tried coaching a coding agent with refactoring vocabulary? What happened? Hit reply and let me know.

---

_Want to consistently ship high-quality code that's easy to change and understand? [Subscribe to Refactor to Grow](https://subscribepage.io/refactor-to-grow) for bi-weekly insights delivered to your inbox._


How to Refactor Coding Agent's Code


# Where Craftsmanship meets LLMs

It's 2025, and I'm advocating you learn how to identify code smells, evaluate software design, and refactor code safely. It's 2025 and coding agents like Cursor, Claude Code, and Windsurf are changing the coding landscape... and I'm talking about refactoring?

**Refactoring is the skill to learn in the age of Vibe Coding.**

These coding agents have been trained on poorly designed codebases filled with code smells. But here's what I've discovered after three years of deep study in refactoring: this makes refactoring skills more valuable, not less.

## The Gap Between Speed and Quality

Coding agents definitely speed things up, but this profession has never been good at slowing down. Typing has never been the bottleneck. The real bottleneck? Design decisions.

I've been studying and practicing refactoring for the last three years. I've gone way deep into this subject and have been teaching others about the power of improving code design through refactoring. Evolutionary design is at the heart of why I practice TDD. Test driven development gives me agility. I keep the design as simple as I need it to be. When new requirements are requested, I refactor the design of the code to easily fit in the new feature.

> "Give me six hours to chop down a tree and I will spend the first four sharpening the ax." — Abe Lincoln

## Your Design Taste is Your Superpower

Here's what I've learned working with coding agents: my taste in software design helps me evaluate their solutions. When Claude Code generates working code, I can quickly spot the Feature Envy, the duplicated logic, & the overly complex conditionals. More importantly, I know how to coach the agent to fix them.

Try this: Tell a coding agent to "Replace Conditional with Polymorphism" and watch what happens. The new models understand refactoring vocabulary perfectly. But you need to know the language first.

## Refactoring as Communication

Refactoring and code smells give us a shared language to talk about messy code and how to clean it up. When I'm pairing with another engineer—or coaching a coding agent—I may suggest we refactor to a Test Data Builders pattern or we can decide whether or not to address the Feature Envy and Code Duplication in the current file.

If you aren't familiar with the language of code design, you'll be less effective when working with others (including coding agents).

## The Real Question

The question isn't whether you need refactoring skills in the agentic era. The question is: Do you want to be a developer who can shape and improve code, or one who just accepts whatever the agent produces?

Coding agents give us working code. But working code isn't the same as well-designed code. The difference between the two? That's where your refactoring skills shine.

---

_Want to consistently ship high-quality code that's easy to change and understand? [Subscribe to Refactor to Grow](https://subscribepage.io/refactor-to-grow) for bi-weekly insights delivered to your inbox._


Refactor to Grow

Latest Issues

Grieving the Death of Coding

I'm Steven, and I'm an AI Addict

The Habits That Stick: What TDD Really Teaches You About Programming

Ready to level up your refactoring skills?

Complete Archive

Grieving the Death of Coding

I'm Steven, and I'm an AI Addict

The Habits That Stick: What TDD Really Teaches You About Programming

10 Heuristics for Pairing with Claude

Spike & Stabilize with Coding Agents

How to Refactor Coding Agent's Code

The Most Underrated Skill in the AI Coding Era