Over the last year or two of working with coding agents, I’ve noticed a shift in how we approach spikes. We start with a question, ask an agent to explore it, and quickly end up with something that looks surprisingly complete. It runs. It might have tests. We can demo it to the team. At that point, it is tempting to ask the agent to clean up a few things and turn the spike into production code.
I understand the appeal. But I think we can lose a lot of the value of a spike when we move directly from “this works” to “let’s keep it.”
In 2022, I wrote about creating spikes with lasting value. A spike is a bounded experiment to explore a problem, evaluate possible solutions, and understand the work ahead. My emphasis was on preserving what we learned. With agents doing more of the implementation, I think that requires even more intentional effort.
Why spikes feel different
The distance between articulating an idea and having reasonable code to explore it has become much shorter in my work. An agent can take on much of the implementation, including changes that would previously have made an experiment too expensive to pursue.
I think this also changes how we view the application itself. Existing structures feel more malleable when we can ask an agent to reshape them. A change that once required a substantial investment now feels like something we can try and adjust as we go.
Then there is the cost of keeping the result. If producing the spike was cheap, bringing it into line with our patterns seems like it should be cheap too. Add some tests, clean up the interfaces, and work through the remaining issues. It might be a large pull request, but the feature is already there.
That reasoning makes sense if the remaining work is cleanup. The trouble is that we may still have unanswered questions about the design underneath it.
What I need to learn from a spike
Historically, much of my learning happened while I was working through the code. I would try to extend an interface and discover that it represented a different business concept than I expected. I would change the data model and find another workflow relying on the old behavior. Those discoveries helped me understand what needed to change and which decisions needed a conversation with the team.
When an agent does that work, I need to deliberately recover that understanding. A polished demo tells me something useful about whether an approach can work. It gives me much less confidence about whether the tradeoffs are appropriate for our application.
Code can compile and pass tests while still representing the business rules incorrectly. The tests may simply reinforce the same assumption that shaped the implementation. I have yet to find a way to document a system so completely that an agent never loses relevant context or misinterprets a requirement.
By the end of a spike, I want to understand how the proposal changes our model of the application. I want to know what decisions belong with the product owner, what assumptions need to be challenged, and what other developers will need to understand before building on the work.
Use the time to explore more approaches
I still go into a spike expecting the code to be disposable. It may be more polished than my earlier experiments, and I may use it to demonstrate an idea. That polish does not commit me to its design.
Instead, I would rather use the lower cost of experimentation to explore several approaches. Depending on the problem, that might mean three to seven spikes, each investigating a different way to achieve the same goal. The number depends on the uncertainty and the time available. Each experiment needs a question worth answering.
For example, suppose a feature needs a new date calculation. I might explore calculating the value from existing data, storing it on an existing record, or introducing a separate concept that owns the scheduling rules. Each approach could produce the same result on screen while making different commitments about where the data lives and how it stays correct.
As I compare those approaches, I want to answer a few questions:
- What changes in the data model, and which existing assumptions does that affect?
- Where do the business rules live, and who is responsible for enforcing them?
- How does the approach affect other workflows and work we expect to do later?
- Which decisions do we need to discuss with the team or product owner?
This gives me something concrete to compare. I can explain why one approach fits our system better and what we would be accepting by choosing it.
Turn the findings into a plan
Once I have explored the approaches, I step back from the individual branches. I review the changes, extract the useful ideas, and write down the tradeoffs and unresolved questions.
Agents can help here too. I can point an agent at several spike branches and ask it to identify common changes, compare where each approach puts the business rules, or propose a sequence of implementation steps. I still need to check that comparison against the code and my understanding of the application.
The result should be a plan that I can discuss with the team. It may combine ideas from several spikes. It may also require a business decision before we can proceed. Either way, I want the implementation to follow those decisions deliberately, without inheriting every choice made while getting an experiment to run.
Make the implementation tell a story
From that plan, I break the work into cohesive changes. If the feature requires date utilities, I might start with their interface, implementation, and tests as one piece of work. Next, I might extend an existing interface to accept the data we now need. Later changes can introduce the agreed model changes, implement the business behavior, and connect it to the rest of the application.
Each piece should give a reviewer a manageable step from the system they know toward the system we are building. I generally aim for a couple hundred lines or fewer when the work allows it, while keeping each logical change together.
Whether those pieces are individual commits or separate pull requests matters less to me than what they communicate. PR stacks can help organize delivery, but the stack alone does not explain the design. Each change needs a purpose, and the sequence needs to show how those changes build toward the feature.
That also helps other developers understand how the work affects their own ongoing work. They can see an interface being extended, understand why a business rule is moving, and question a decision while its scope is still clear. Reviewing thousands of lines of accumulated experimentation makes that much harder.
I want my team to come away able to reason about the new functionality and make informed decisions about what comes next. That shared understanding is part of finishing the work.
Agents have given me room to try more ideas and make those ideas tangible much earlier. I want to spend some of that time comparing approaches, understanding their consequences, and building a clear path for the team to follow. When I finish a spike, the most useful thing I can bring back is an explanation of what we learned and how it should shape the work ahead. I am not looking for spikes to move forward faster, but instead they should be more thorough.