HanLHo. - Fractional Architect & Software Product Engineer - tdd

AI’s Opportunity: Pacing Control Loops with Development

2026-02-04T00:00:00+00:00

What caught my attention in the book Vibe Coding by Gene Kim and Steve Yegge is the idea that, as LLMs and coding agents change how we build software, control loops—tests, reviews, and other signals that tell you whether a change behaves as expected—should be faster and more integrated into development feedback loops than before. My intuition says this makes perfect sense.

For example, when there is a dedicated test stage or a QA role that tests after the fact, that role inevitably struggles to keep up with the speed of development. Over time, this makes it increasingly difficult to sustain a 'testing after the fact' organisation of quality.

So how do we solve this?

Some may think that introducing AI by implementing it at the test level after the fact, could be the solution. However, at the rate of development I see and read about, this approach will be hard to keep up with. One either has to accept not fully taking advantage of what AI can help development with, or rethink how testing is integrated into the development process.

Put bluntly: if AI lets you produce a feature in hours but the first meaningful acceptance signal only arrives days later in a separate stage, quality assurance become the bottleneck.

To me, the logical consequence is a stronger shift towards automated quality controls, including acceptance tests and code reviews at the least. I refer to acceptance tests here as writing executable specifications of expected behaviour (in domain language) before or alongside the code. This implies that testing has to move earlier in the development chain because of AI.

AI is an opportunity to start writing acceptance tests if you have not yet. It pushes us to invest time in strategic test design, testing against stable contracts, testing from a behavioural point of view, and isolating test descriptions from the actual implementation.

Put differently, the shift in development practices that LLMs are causing should inspire more adherence to testing best practices, not less. That is, if you want to keep on adding new features, fix and prevent bugs, and keep up the pace of development.

More broadly, to keep benefiting from AI over time, we should shift towards tightly coupled feedback loops embedded in everyday development. This is not limited to testing but also applies to, for example, reviews. In that sense, AI doesn’t remove quality practices; it raises the stakes if you don’t have them.

If testing 'shifts left', team structures must change as well. This evolution points towards smaller, more autonomous teams where testing, development, and feedback are inseparable rather than sequential.

AI presents us with an opportunity: not faster quality control after the fact, but to design systems, processes, and teams that make quality the fastest path forward, so control loops can keep up with the increasing pace of development loops.

Notes on Preparatory Refactoring

2024-12-06T00:00:00+00:00

Notes inspired by Emily Bache's short Youtube video Design Better Code with Preparatory Refactoring in TDD | Demo</a>.
A preparatory refactoring is a refactoring to make future changes to accommodate new requirements easy. By definition, current behavior should not be changed. Instead of using tests to drive changes, you use them to verify you are not breaking existing behavior.
A practical tip: add a pending test as a mental note to remember the goal of your refactoring. Say you have a new requirement coming in. TDD's mantra Red-Green-Refactor would require you to write a failing test first. However, it turns out, the current design is not really well-suited to accommodate this change. This means you may be facing Red status for a while if you decide to keep the test in. In addition, when you start refactoring to change the design, you may accidentally break existing functionality. This means you will have tests that are failing expectedly and unexpectedly. When refactoring you would ideally only see the tests fail when you made a mistake. An in-between approach could be: add the test for the new behavior, see it fail, set it to 'pending' and then proceed with the refactoring.
Green-Refactor-Green instead of Red-Green-Refactor. Preparatory refactoring does not mean we cannot use small steps to do the refactoring. Make a small change to the code, see the test still pass, continue; if a test fails roll back or fix. Green-Refactor-Green, keep an eye on your pending test.
Two further resources which include an example of how one could approach such a refactoring:

Video: Design Better Code with Preparatory Refactoring in TDD | Demo</a> by Emily Bache. </li>

Blog post: An example of preparatory refactoring</a> by Martin Fowler. </li> </ul>

Notes on TDD & DDD From the Ground Up Live Coding

2024-11-14T00:00:00+00:00

Some short notes from Chris Simon's Talk TDD & DDD From the Ground Up Live Coding</a>
When choosing the right testing level, developers face an important trade-off. Higher-level tests provide better coverage for refactoring, but make it harder to pinpoint the exact location of failures. Finding the right balance is crucial for maintainable tests.
Domain modelling through traditional entity diagrams can lead to hidden assumptions. Event storming, by contrast, helps create more explicit models that better reflect how systems change over time. This approach brings us closer to the actual domain and helps reveal important details we might otherwise miss.

Notes on 🚀 TDD, Where Did It All Go Wrong

2024-11-14T00:00:00+00:00

My short notes on 🚀 TDD, Where Did It All Go Wrong</a>.
Still a lot of testing wisdom in this talk (re-watched 6 years after publication).
Focus on behaviour</h2>
Behaviour should be your primary focus when writing tests. The need for a new test should arise from new behaviour or requirements. While TDD is often contrasted with BDD, Kent Beck's early work already emphasised the importance of focusing on behaviour.
When writing tests, be mindful of coupling. Your tests should not all fail when you change your code. Write tests against public contracts where possible. In my experience, you can deviate from this rule if your unit under test has a stable internal contract.
This approach leads to better 'refactorability'. For a practical demonstration, I recommend watching TDD & DDD From the Ground Up Live Coding by Chris Simon</a>.
ATDD tools are not worth it if business is not actively participating</h2>
While I have promoted the use of ATDD (Acceptance Test Driven Development) tools like Gherkin, I must agree, the burden of translating between natural language and code can be 'horrible', to the point where internal frameworks are implemented to manage this complexity.
More importantly, the effort may not be worthwhile without an engaged business analyst or product owner. In my experience, business stakeholders rarely show interest in participating. While I've questioned whether I could have done more to encourage engagement, this talk confirms this is a common challenge. Though disappointing to acknowledge, as the practice appears promising on paper, this seems to be the reality we face.
That said, the consistent style these tools promote can still be valuable in test writing.
If you had success using Gherkin or similar tool I would be interested in learn how.
Do not forget about Refactor</h2>
The TDD-cycle is Red-Green-Refactor. First fix the problem, then improve the design. The central idea is to decouple thinking about the problem from thinking about the design. The Refactor step is where the design is improved and is an integral part of the cycle.
This methodical approach leads to more maintainable code, contrasting with the approach of the 'Duct-tape Programmer' (this talk) or 'Tactical Tornado' (Ousterhout</a>) approach.
When you can improve the design without changing tests, you have achieved good decoupling.