HanLHo. - Fractional Architect & Software Product Engineer - developer-experience

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.

Continuous Deployment for Personal CLI Tools

2025-03-25T00:00:00+00:00

Git pre-push hooks can automate local installation of your personal CLI tools, creating a development workflow where your working environment always has the latest version of your code.
When developing CLI tools, for example for personal use, I often want to run the latest version locally to quickly identify issues and get a feel for changes. Constantly installing updates manually or running from source creates unnecessary friction. This article shows how to automate this process using Git pre-push hooks.
A Simple Solution: Local Continuous Deployment</h2>
Automatically installing an updated CLI command locally whenever you push changes to your repository creates a featherweight continuous deployment pipeline. This keeps your local environment in sync with your latest code changes with minimal effort.
What Are Git Hooks?</h2>
Git hooks are scripts that Git executes before or after events like commit, push, or receive. Pre-push hooks run automatically before your code is pushed to a remote repository.
Implementation: Git Pre-Push Hooks</h2>
The implementation is straightforward. Use git's pre-push hooks to trigger installation automatically:

Edit the git pre-push</code> hook file:</li> </ol> vim .git/hooks/pre-push </code></pre> Make it executable:</li> </ol> chmod +x .git/hooks/pre-push </code></pre> Add installation commands to the hook:</li> </ol> #!/bin/sh install.sh exit $? # Propagate the exit code </code></pre> The install.sh</code> script in this example should contain whatever commands you would normally use to install your CLI tool locally. If you use build tools like make</code> or just</code>, you can call those commands directly. For a tool written in Rust your install.sh</code> script may contain: cargo install --path . </code></pre> This approach automatically rebuilds and installs your application on every push to the repository and ensures you're always using the latest version without any manual steps. Note: This works best when developing directly on the main branch. If you work with feature branches, you'll need to consider which version you want running locally at any given time. </li> For added robustness, you can extend this approach to run tests or lint your code before installation. </li> Hooks are not pushed to your repository by default. You will need to set them up on each development machine. </li> </ul> Thank you for reading, Hans

HanLHo. - Fractional Architect & Software Product Engineer - developer-experience

AI’s Opportunity: Pacing Control Loops with Development

Continuous Deployment for Personal CLI Tools

What Are Git Hooks?</h2> Git hooks are scripts that Git executes before or after events like commit, push, or receive. Pre-push hooks run automatically before your code is pushed to a remote repository.</p>

What Are Git Hooks?</h2>
Git hooks are scripts that Git executes before or after events like commit, push, or receive. Pre-push hooks run automatically before your code is pushed to a remote repository.</p>