Wanleung's Workshop

Original Article was published on Medium:...

原文原刊於Medium: https://medium.com/hong-kong-linux-user-group/how-to-type-chinese-cangjie-quick-on-pop-os-24-04-with-the-cosmic-desktop-178627ac335f好多朋友升級到Pop!_OS...

In short: A coding rule from a 1990s university computer science class — where the hard constraint was the size of a CRT screen — turned out to be one of the most practical pieces of advice I’ve ever...

https://www.youtube.com/watch?v=LKHf54jqwvABecause of AI, I could finally complete this song.The Lyrics I had written for some years but I couldn't complete the whole song because lack of melody...

Code: github.com/wanleung/ai-dev-teamIn short: The pipeline’s own AI agents opened a pull request with 7 critical bugs — code that couldn’t run at all. This post dissects exactly why it happened and...

As the system grew, every new pipeline type — bug fixes, documentation, features — needed its own Python script and GitHub Actions workflow. This post covers how all of them were unified into a single watcher process where a GitHub label determines which pipeline runs. Adding a new pipeline now means writing one YAML file.

Standard mode and TDD mode cover most use cases, but sometimes you want a custom sequence — run two review loops in a row, skip deployment tests, or run a domain-specific agent you added yourself. This post covers pipeline.yaml: a separate config file that lets you define any stage sequence with explicit loop blocks, and a drag-and-drop GUI that builds it without hand-editing YAML.

The standard pipeline writes code first, then tests. This post covers a TDD mode that flips the order: QA writes tests before the engineers see the problem, then engineers implement against those tests, then a fix loop runs until the suite is green. It also covers how this forced a proper stage registry — replacing hardcoded stage sequences with a configurable system.

The original pipeline was hardwired to GitHub Models. This post covers how I extracted every LLM backend into its own class with a shared interface, added a relay that automatically falls back to the next backend on connection failure, and what I learned about building resilient AI infrastructure around unreliable upstream APIs.

Seven posts of technical depth, but what does it all mean? This closing post steps back to reflect on the lessons learned, how this project vindicates what Builder.ai was attempting, where the remaining hard problems are, and what I’m building next.