HanLHo. - Fractional Architect & Software Product Engineer - bdd

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.

Test Naming Guidelines

2025-06-26T00:00:00+00:00

TLDR: Below are test naming guidelines that help me write consistent, clear test names.
This is quick post with the Test Naming Guidelines I have been using to make my test names consistent across multiple projects. I use also these with LLMs when writing tests or refactoring multiple tests to this style.
I used one of my personal projects as a basis to develop, refine and structure these guidelines with help from an LLM.
Below are the guidelines.
Format</h2>
[subject]_should_[expected_behavior]_[optional_when_condition] </code></pre> Components</h2> Subject: The component, feature, or system under test Examples: user</code>, api</code>, filter</code>,time_report</code></li> </ul> Expected Behaviour: What should happen, described as an action or outcome Examples: return_success</code>, validate_input</code>, fail_with_error</code></li> </ul> Optional When Condition: Include only when necessary for clarity or disambiguation Format: when_[condition]</code> </li> Examples: when_input_valid</code>, when_user_authenticated</code> </li> </ul> Guidelines for When Conditions</h2> Include when_[condition]</code> if:</h3> Essential for understanding: The condition is crucial to know what's being tested </li> Multiple variants exist: Similar tests with different conditions need distinction </li> Specific circumstances: The behavior only occurs under particular conditions </li> </ul> Omit when_[condition]</code> for:</h3> Basic/default behavior: Standard functionality that doesn't require special conditions </li> Self-evident scenarios: Cases where the expected behavior already implies the context </li> Overly obvious conditions: When the condition adds no meaningful information </li> </ul> Examples</h2> Good (concise when appropriate): health_check_should_return_200 user_should_be_created </code></pre> Avoid (unnecessarily verbose): health_check_should_return_200_when_request_valid // "valid" is implied by 200 response user_should_be_created_when_data_provided // data is obviously needed </code></pre> Good (meaningful distinctions): user_should_login_successfully_when_credentials_valid user_should_be_rejected_when_credentials_invalid </code></pre> Principle</h2> Keep test names as short as possible while maintaining clarity. The when_</code> clause is a tool for disambiguation, not a mandatory requirement. Key Takeaways</h2> Architecture benefits from being grounded in implementation. Adding a Verification section to your ADRs creates feedback loops and improves their quality. The verification section serves as more than a checklist. It: Connects architecture with implementation </li> Provides a mechanism for feedback in both directions </li> Reveals when decisions aren't being acted upon </li> Makes ADRs more actionable and effective </li> </ul> This grounding helps prevent architectural decisions from remaining theoretical or becoming shelfware.
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.

HanLHo. - Fractional Architect & Software Product Engineer - bdd

AI’s Opportunity: Pacing Control Loops with Development

Test Naming Guidelines

Principle</h2> Keep test names as short as possible while maintaining clarity</strong>. The when_</code> clause is a tool for disambiguation, not a mandatory requirement.</p>

Notes on 🚀 TDD, Where Did It All Go Wrong

Principle</h2>
Keep test names as short as possible while maintaining clarity</strong>. The `when_</code> clause is a tool for disambiguation, not a mandatory requirement.</p>`