How Agile Architecture Spikes Are Used in Shift-Left BDD

More Details about Spikes

There are many benefits of spiking: getting to know the unknown unknowns, discover risks, reduce complexity, provide proof for proving or disaproving a theory. Taking a deep dive into the idea behind the solution can help in getting better at understanding potential architectual solutions and the likelyhood of will it work.

A spike is not there to provide a finished working product, or even an MVP, it’s purpse is mainly to test a theory, so even though this concept is used (in the long run) to produce working software, the code writen for spikes is often disgarded after it has served it’s purpose. Spiking usually is done by ignoring architecture styles (which might seem odd at first as it can help in discovering the righ archictectural approaches for the system we are building), coding style, design patters and general clean coding practices in favor of speed. So even though the spike may not directly produce software that will be delivered to the customer, in the long run it still helps us ship better code in the end.

Spiking is a good tool for handling risk, by discovering unknown risks, and it provides a great way to learn and reduce complexity. A risk a spike exposes early is also the kind of risk that drives risk based testing, where test effort follows the biggest unknowns. A very common approach is to come up with spikes around a theory and to follow the code by a small number of simple tests. Even though the spikes are often seen as discardable code, we don’t really just throw them aside. While they don’t end up in the actual code which gets delivered, they provide useful insights and can serve as documentation to show how a certain solution was reached.

A Simple Example Let us assumen that we have a new feature we need to develop, we need to allow the users to be able to save a photo in their profile, to do that a developer can make a spike where the following could be done:

• Have the JavaScript on the Front-end communicate with the database
• Setup a database server locally
• Setup a NodeJS (or another server)
• Use ODBC (Open Database Connectivity) API to connect to the DB
• Test the spike
• Run a few sample queries
• Test the CRUD functionality

What is mentioned in this simple example is all we need for a spike, it does not require any detailed documentation. The developer working on a spike will need to do some googling, run a few commands from the terminal, write a few lines of code for each theory. The spike would provide a posible direction for solving the challenge at hand, it can also include links for resources used, install scripts and the actual produced code to be used a blurprint. Trying things out is way more beneficial than simply theretisizing about them. The team was able to reduce the risk related to this feature, in this example especially on the technical integration side, and even discovered new risks such as accessing the DB using local JS.

Key Takeaway: An architecture spike trades finished code for a fast answer, so the team learns whether an approach works before the story is estimated.

How does this impact testing?

Allowing us to explore, spikes helps with identifying the unknown unkwonwns, so in a sense spikes are a tool for early testing, and they fit naturally into shift left testing. By getting answers to what works and what will not work, we avoid a lot of potential issues, and delays, by probing the requirements to distill them further. In turn, there are less bugs to report, fix, verify and keep track of. Also, the earlier the testing is done, the more economical and fast it will be.

Challenging a specification with working code is the same instinct behind behavior driven development. A spike answers the technical half of that question while the scenarios answer the behavioral half.

Key Takeaway: Running a spike before a story is built removes bugs that would otherwise be written, reported, fixed and retested later in the cycle.

Can QA use spikes?

There is no real reason why not to. Testers use spikes to try out, and experiment with, different approaches to automating part of the system under test, in order to determine the best approach. The habit is close to exploratory testing, except the subject is the toolchain rather than the product. An architecture spike can help us in trying out different testing tools, such as new frameworks and libraries, give us a first hand experience of how a certain tool would behave with out system, when we try to automate some business rule, for example. Spikes are generally regarded as technical tasks (different than user stories) usually under an epic, that is in early development stages.

Key Takeaway: A tester can use an architecture spike to compare automation frameworks against the real application before the team commits to one of them.

How Do AI Coding Agents Change Architecture Spikes?

AI coding agents shorten the build half of a spike, not the thinking half. An agent writes the throwaway prototype in minutes, but the team still chooses the question the spike has to answer.

Agents such as Claude Code, Cursor and GitHub Copilot run terminal commands, install packages and wire a local service, which is exactly the rough work a spike asks for. Model Context Protocol servers extend that reach by letting an agent query a database or an internal API directly during the experiment.

The risk is that generated code reads as confident and correct without ever having run against the real dependency. A spike is only worth its time-box if it produces evidence, so the execution output is the deliverable and the code is not.

Four practices keep an agent-assisted spike honest:

• Spike question and time-box: Fix both before the agent starts, so the session ends with an answer instead of a half-built feature.
• Command output as proof: Ask for the commands the agent ran and what they printed, not only the code, and reject any result it could not execute.
• Real dependency over mocks: Point the agent at the actual database driver or the actual API version, not a stand-in.
• Ruled-out options: Record every approach the agent tried and abandoned, because it sharpens the next estimate as much as the working one.

Used this way, an agent widens how many theories a team can test inside one iteration. It does not remove the judgement about which theory matters.

Key Takeaway: An AI coding agent makes a spike cheaper to build, but the spike still only counts as evidence once the code has run against the real dependency.

Conclusion

So the wrap this up, spikes in Agile are one of the tools which allows us to do what Agile is intended to do in the first place: short, quick feedback cycles give us answers early in the development process, we focus on doing and trying instead od long overly-detailed planing. That is not to say that code architecture does not matter in Agile (as we know, in Waterfall architecture is very important and usually done in the design phase), in Agile we just use a different approach. Agile practice, such as spikes, allow us to get an idea about architectural solutions that may work, as well as info about the ones that may not work.

Software produced in the above mentioned manner, help us reduce risk in our user stories, enabled the team to discover right solutions using collaboration, constructive discussion, frequent experimentation and compromise. In a informal sense, a lot of people happen to be using spikes without even realizing it! As long as you are trying to identify the unknown unknowns, have short feedback cycles and you’re trying to determine technical and also functional risks, you are doing Agile. Spikes help in situations where the requirements are not certain and there are many unknowns that need answers. If you are preparing for an interview, you can go deeper with these BDD interview questions.