DEV Community: Kingson Wu

Rethinking How We Learn in the Age of AI

Kingson Wu — Fri, 02 Oct 2026 05:44:45 +0000

1. A New Way of Learning

For a long time, learning something new meant finding a good book or course and following the path designed by someone else—from the fundamentals to the advanced topics.

That made sense when access to knowledge was expensive.

But AI changes this equation.

For people who already have substantial experience, the problem is often not that they know nothing about a new subject. They already have years of knowledge, mental models, and experience that can serve as a starting point.

The real challenge is figuring out what they actually need to learn, how the new concepts connect to what they already know, and where their understanding is incomplete or wrong.

This makes a different approach possible:

Instead of starting from page one, start with a question.

Tell the AI what you already know and what you are trying to understand. Let it identify the relevant concepts, explain the missing pieces, ask questions, challenge your assumptions, and adjust the depth based on your responses.

Matt Pocock's teach skill is an interesting example of this direction. Rather than simply asking an AI to explain something, it turns the interaction into an ongoing learning process, using goals, learning history, questions, exercises, and feedback to help determine what to learn next.

The underlying idea is quite different from simply asking AI to summarize a textbook:

Don't just consume a predefined curriculum. Let AI help organize the learning process around your questions, existing knowledge, and actual gaps.

Traditional learning often looks like:

Course → Knowledge → Exercises → Exam

AI-assisted learning can look more like:

Question → Dialogue → Understanding → Practice → Feedback → Correction → Deeper Exploration

The knowledge itself hasn't changed. The path through the knowledge has.

And this may be particularly valuable for experienced learners. Instead of spending weeks going through things they already understand, they can start from what they know and focus their time on the missing pieces and the connections they haven't made yet.

This doesn't mean traditional books, courses, or systematic study are obsolete. They remain important, especially when building foundational knowledge.

But they are no longer the only possible entry point.

We don't always have to learn everything first and solve problems later. We can start with a problem and learn our way through it.

2. Making AI a Learning Interface

I've been experimenting with this idea myself and created a learning resource for studying LLMs with AI:

Understanding LLMs for Software Engineers · Understanding LLMs for Software Engineers

A systems-first guide for software engineers to understand LLM principles, mechanisms, and boundaries.

kingson4wu.github.io

The idea is slightly different from a conventional learning website.

It is designed not only for humans to read, but also for AI tools to navigate and use as a knowledge base.

The material includes a structured knowledge map, relationships between topics, learning indexes, and different entry points based on questions. It can be used with different AI tools such as ChatGPT, Claude, or Codex.

Instead of:

Start from Chapter 1 → Read everything → Take notes → Move on

you can try:

Ask a real question → Let AI locate the relevant knowledge → Discuss it → Let AI challenge your understanding → Go deeper into the source material when necessary.

I think this is only an early example of what learning might look like in the AI era.

Learning materials don't have to be something we simply read anymore. They can become a knowledge base that AI and humans use together to explore, understand, and verify ideas.

FastProxy: A Go Blueprint for Enterprise-Grade Service Proxies

Kingson Wu — Wed, 17 Sep 2025 07:20:07 +0000

In a world where multi-cloud topologies and zero-trust philosophies are rapidly becoming table stakes, east-west traffic governance is no longer optional. FastProxy delivers a security-first, high-throughput service proxy implemented entirely in Go, packaging encryption, integrity checking, traffic governance, and observability into a compact runtime. This article introduces the project from an engineering perspective and highlights the Go fundamentals you can master by exploring its codebase.

Mission and Positioning

FastProxy’s primary goal is to provide trustworthy, low-latency channels for service-to-service communication while enforcing consistent security policies. It can be embedded directly in business processes, deployed as a sidecar, or run as a centralized ingress/egress gateway—making it a natural fit for microservices, serverless functions, and data pipelines.

Key differentiators include:

Integrated Security: End-to-end encryption/decryption, signature validation, rate limiting, and auditability baked into the data path.
Performance-Driven Runtime: A Go and FastHTTP core optimized for protobuf payloads and designed for throughput.
Modular Architecture: Components such as center, in-proxy, out-proxy, and server can be mixed and matched to suit different topologies.
Observability by Default: Structured logging, metrics, and CI-backed coverage reports ensure operational transparency.

Architecture at a Glance

FastProxy cleanly separates control-plane orchestration from the data-plane path:

Center: Manages service metadata, configuration, and policy distribution.
InProxy / OutProxy: Apply security checks, flow control, and decoding for inbound and outbound traffic respectively.
Server: Hosts business logic or forwards to existing upstreams, speaking HTTP/HTTPS and protobuf.
Client SDK: Provides ergonomic Go integrations, enabling embedded deployments.

This division enables runtime policy changes without redeploying workloads and supports multi-tenant, multi-environment rollout patterns.

Go Engineering Learning Map

FastProxy’s repository covers many of the foundational skills required for professional Go development. The following themes offer a structured way to learn from the project.

1. Modular Design and Package Boundaries

The project relies on Go Modules to manage dependencies (go.mod) and uses packages such as common/, inproxy/, and outproxy/ to partition responsibilities. Studying this layout illustrates how to plan large-scale Go systems.

2. Configuration and Resource Management (`embed.FS`)

inproxy/inproxy.go demonstrates embedding configuration artifacts directly into binaries:

// inproxy/inproxy.go
//go:embed *
var ConfigFs embed.FS

Inlining templates and banners avoids external dependencies during deployment and showcases Go’s straightforward resource bundling.

3. Concurrency and Synchronization Primitives

common/server/server.go offers a compact showcase of Go’s concurrency toolset:

quit := make(chan os.Signal, 1)
signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM, syscall.SIGQUIT, syscall.SIGHUP)
<-quit

var ctx context.Context
if p.shutdownTimeout > 0 {
    var cf context.CancelFunc
    ctx, cf = context.WithTimeout(context.Background(), p.shutdownTimeout)
    defer cf()
} else {
    ctx = context.TODO()
}
var done = make(chan struct{}, 1)
go func() {
    if err := p.svr.Shutdown(ctx); err != nil {
        p.logger.Error("proxy server shutdown error", zap.Any("err", err))
    }
    done <- struct{}{}
    p.wg.Done()
}()

Goroutines handle asynchronous startup and graceful shutdown.
Channels propagate OS signals and shutdown notifications.
sync.WaitGroup and sync.RWMutex coordinate shared state and lifecycles.

These patterns demonstrate how concurrency primitives collaborate inside production services.

4. Context-Driven Lifecycle Management

The codebase relies on context.Context to propagate cancellation and deadlines, most notably when enforcing graceful shutdown with context.WithTimeout. This underlines the central role of context in orchestration logic.

5. Interfaces, Dependency Injection, and Logging Abstractions

common/logger defines a logging interface, while common/server employs the functional options pattern to inject logger.Logger implementations. Together they show how Go interfaces and options create loosely coupled, testable components.

6. High-Performance Networking

FastProxy supports both the standard net/http stack and github.com/valyala/fasthttp, bridging them with fasthttpadaptor. The design illustrates how to balance ease of use with extreme performance within Go’s networking ecosystem.

7. Testing and Quality Assurance

The repository contains rich *_test.go coverage, pre-generated coverage reports (coverage-*.out), and automation scripts such as golangci-lint.sh. These assets demonstrate how to build CI-ready unit, integration, and linting pipelines.

8. Build and Automation Tooling

A pragmatic Makefile wraps common build, test, and lint workflows, providing a template for integrating Go tooling into reproducible development processes.

Suggested Learning Path

To leverage FastProxy as a learning vehicle, consider the following progression:

Read the README and Wiki to form a mental model of the component relationships.
Run the examples/ directory to see embedded usage and configuration in action.
Study common/server to understand service startup, concurrency management, and graceful shutdown mechanics.
Dive into inproxy / outproxy to observe how encryption, signature verification, and flow control are enforced.
Customize policies by extending configuration or option hooks to internalize the functional options pattern.

Final Thoughts

FastProxy is more than a ready-to-deploy service proxy—it doubles as a comprehensive Go engineering playbook. By exploring its modules, concurrency patterns, security posture, and observability story, you can cultivate the skills required to deliver production-grade Go services. Pair the source code with its test suites, iterate with hands-on experiments, and translate these lessons into your own engineering toolkit.

ForgeFlow: Engineering-Grade Automation For AI CLIs Inside tmux

Kingson Wu — Tue, 16 Sep 2025 05:52:14 +0000

ForgeFlow automates interactive AI CLIs (e.g., Gemini, Codex) inside a tmux
session using a clean “adapter + rules” architecture. It detects prompts
and processing states, sends the right commands, and keeps going until tasks
converge — with logs, extensibility, and sensible recovery behavior.

This guide covers:

How to install and use ForgeFlow (focus)
Architecture overview, key interfaces, and ANSI support
Extending with custom rules and adapters
A simple flow diagram in Markdown

Who It’s For

Developers who live in the terminal and use AI CLIs
Teams that want a repeatable driver for long-running, iterative tasks
Anyone who needs logging and simple extensibility without reinventing the loop

Requirements

macOS/Linux
Python 3.9+
tmux installed and on PATH

Install And Run

Dev install (pinned tooling):
- pip install -e .[dev] -c constraints-dev.txt
Runtime install:
- pip install -e .
Makefile helpers:
- make dev-install — install dev deps with constraints
- make lint / make fmt / make test
- make setup-hooks — optional Git hooks
Typical run:

forgeflow \
--session qwen_session \
--workdir "/abs/path/to/your/project" \
--ai-cmd "qwen --proxy http://localhost:7890 --yolo" \
--cli-type gemini \
--poll 10 \
--timeout 2000 \
--log-level INFO \
--log-file forgeflow.log
Switch adapters:
- --cli-type gemini or --cli-type codex (claude_code is a placeholder)
Use project-specific rules:
- Add {project}_rules.py or {project}.py in your project root or in examples/
- Run with --project myproject
- forgeflow \ --session qwen_session \ --workdir "/abs/path/to/your/project" \ --ai-cmd "qwen --proxy http://localhost:7890 --yolo" \ --project myproject \ --cli-type gemini
Logging:
- --log-file forgeflow.log writes file logs
- --no-console disables console logging
- --log-level supports DEBUG/INFO/WARNING/ERROR

Python API

from forgeflow.core.automation import Config, run_automation

cfg = Config(
session="qwen_session",
workdir="/abs/path/to/your/project",
ai_cmd="qwen --proxy http://localhost:7890 --yolo",
cli_type="gemini",
poll_interval=10,
input_prompt_timeout=2000,
log_file="forgeflow.log",
log_to_console=True,
project="myproject", # optional
log_level="INFO",
)
run_automation(cfg)

Rules: Project-Level Customization

File naming:
- {project}_rules.py or {project}.py
Function name (recommended):
- build_rules() -> list[Rule]
Minimal example:

examples/myproject_rules.py

from forgeflow.core.rules import Rule

def build_rules() -> list[Rule]:
def done(output: str) -> bool:
return "All tasks have been completed." in output
```
  return [
      Rule(check=done, command=None),  # stop
      Rule(check=lambda out: "API Error" in out, command="continue"),
      Rule(check=lambda out: True, command="continue"),
  ]
```
Rule behavior:
- Rules are evaluated in order, the first matching rule returns its command.
- If command is None, automation stops.

Architecture Overview

Core loop (forgeflow/core/automation.py)
- Creates/attaches tmux session
- Determines adapter by --cli-type
- Captures tmux output, checks “prompt vs. processing”, evaluates rules
- Timeout recovery: ESC → progressive Backspace until prompt → send continue
- Logging level configurable; file and console outputs supported
tmux I/O (forgeflow/core/tmux_ctl.py)
- Encapsulates tmux operations: session creation, send keys, capture pane
- capture_output(include_ansi=False) supports capturing raw ANSI when needed
Adapters (forgeflow/core/cli_adapters/*)
- Interface CLIAdapter:
  - is_input_prompt(output) -> bool
  - is_input_prompt_with_text(output) -> bool
  - is_task_processing(output) -> bool
  - is_ai_cli_exist(output) -> bool
  - wants_ansi() -> bool — ask automation to capture pane with ANSI codes
- Implementations: gemini.py, codex.py (claude placeholder present)
- Adapter resolution via get_cli_adapter(cli_type)
Rules (forgeflow/core/rules.py)
- Rule(check: Callable[[str], bool], command: str | None)
- Default rules and next_command(output, rules)
Rule loader (forgeflow/core/rule_loader.py)
- Dynamically loads {project}_rules.py or {project}.py from workdir or examples/

ANSI Utilities For Smarter Detection

Some CLIs render distinct prompt colors or attributes. You can opt-in to
capture ANSI and parse it in your adapter:

Adapter opt-in: def wants_ansi(self) -> bool: return True return True
Utilities (forgeflow/core/ansi.py):
- strip_ansi(text) -> str — removes all ANSI escape sequences
- parse_ansi_segments(text) -> list[Segment]
  - Splits text into styled segments (tracks SGR attributes)
  - Supports bold, dim, italic, underline, blink, inverse, strike
  - Supports FG/BG basic (30–37/90–97/40–47/100–107), 256-color, truecolor
- split_segments_lines(segments) -> list[list[Segment]]
  - Split by newline while preserving styles

Example usage in an adapter:

from forgeflow.core.ansi import parse_ansi_segments

class MyAdapter(CLIAdapter):
def wants_ansi(self) -> bool:
return True

  def is_input_prompt(self, output: str) -> bool:
      # Example heuristic: find a red prompt marker at end of screen
      segments = parse_ansi_segments(output)
      text = ''.join(seg.text for seg in segments)
      return text.rstrip().endswith('>')  # combine with color checks

if needed

This keeps default behavior unchanged while enabling color-aware rules when
helpful.

Simple Flow Diagram

flowchart TD
A[Start forgeflow] --> B[Create/attach tmux session]
B --> C[Ensure AI CLI running]
C --> D{Capture output
(ANSI optional)}
D --> |prompt & idle| E[Evaluate rules -> command]
E --> F[Send text + Enter]
F --> G[Sleep 2s]
G --> D
D --> |prompt has text| H[Send Enter]
H --> G
D --> |processing| I[Wait poll interval]
I --> D
D --> |timeout| J[ESC + progressive backspace]
J --> K[Send "continue"]
K --> D
E --> |None| L[Stop]

Troubleshooting

“tmux is required but not found”
- Install tmux and ensure tmux -V succeeds
CLI not detected as running
- Check --ai-cmd and allow a few seconds post-launch
No project rules
- Defaults are used; add custom rules for better convergence

Repository And License

Repo: https://github.com/kingson4wu/ForgeFlow
License: MIT

Driving AI CLI Tools to Write Code: A Semi-Automated Workflow

Kingson Wu — Tue, 16 Sep 2025 04:14:12 +0000

Lately, I’ve been experimenting with a semi-automated programming workflow.

The idea is simple: let AI tools continuously write code in a controlled environment, while I stay in charge of architecture, quality, and reviews. Think of it as engineering field notes — practical patterns and lessons learned.

Why Semi-Automation?

We already have plenty of AI coding tools — Claude Code, Gemini CLI, QWEN, and many others that integrate with CLI workflows. They boost productivity, but manual prompting step by step isn’t enough.

Instead, my approach is to:

Use scripts to orchestrate and manage AI tools;
Keep sessions alive with tmux;
Automatically send structured prompts, collect responses, and keep the AI working until a task is done.

The goal: a tireless “virtual developer” coding 24/7, while I focus on design, architecture, and quality control.

The Overall Approach

This workflow has four main stages, each anchored by human review. That’s the secret sauce for keeping things sane.

1. Project Initialization: Specs and Skeleton First

Before coding, you need solid guidelines and structure. That’s what makes semi-automation possible.

Create a new GitHub repository.
Start with a baseline project doc (e.g., cpp-linux-playground), then rewrite it for your tech stack (e.g., TypeScript) and save as PROJECT.md.
Plan ahead:
- Tech stack (languages, tools, standards)
- Task verification (tests, QA)
- Static analysis & code quality tools
- Project structure
- Git commit conventions

👉 Pro tip: rename docs/ to something more precise (like specifications/) to avoid random file dumping.

AI can help draft this documentation, but every detail should be human-approved.

2. Break Tasks Into Detailed Specs

Every feature or bug fix deserves its own spec under @specifications/task_specs/.

No coding yet — just detailed planning.
Each spec should define:
- Functional description
- Implementation steps
- Inputs and outputs
- Test cases
- Edge cases and risks

This reduces ambiguity and dramatically improves AI’s code quality.

3. Automate the Coding Process

With specs in hand, the real semi-automation begins:

Use Python scripts to orchestrate AI CLI sessions.
Keep sessions running via tmux.
Send structured prompts to AI tools (Claude, Gemini, QWEN, etc.).
Enforce these rules:
- Never auto-commit code
- Run validation after every iteration
- Sync project progress into TODO.md, linked from PROJECT.md

Workflows can borrow from ForgeFlow, which demonstrates prompt pipelines and programmatic handling of AI responses.

👉 Pro tip: If a task runs for more than an hour, send an “ESC” signal to re-check progress.

4. Clear Definition of “Done”

A task is done only when:

All code matches the plan;
Unit tests pass;
Automation scripts and prompts are updated;
Build and test pipelines run cleanly;
Git changes are committed;
The next task can begin.

At the very end, the AI should respond with nothing but “Done.”

Project Example: `ts-playground`

ts-playground
This project serves as:
A structured playground for mastering TypeScript;
A CI/CD-enabled environment;
A practical use case of AI-assisted, semi-automated programming.

Semi-Automation vs. Full Automation

This workflow is semi-automated, not fully automated — intentionally:

Specs and architecture still need human input.
Prompts and scripts are evolving — you won’t cover every case at first.
Code quality checks remain essential — AI output isn’t always stable.

Semi-automation is cheap, reusable, and controlled. Full automation would require multi-agent systems and heavy context management — overkill for now.

Why Context Management Matters

The AI stays productive only if the project context is well-structured:

Organize guidelines by category and directory;
Keep task specs structured for easy reference;
Feed the AI only the relevant context per task.

This way, the AI acts like a real assistant instead of just a fancy autocomplete.

A Bit of Philosophy

This workflow reframes roles:

AI = the “coder + assistant,” executing granular tasks.
You = the “tech lead,” designing systems, reviewing work, and managing quality.

AI doesn’t replace developers. Instead, it amplifies us — pushing humans toward higher-level thinking, decision-making, and problem-solving.

TL;DR

Semi-automated programming in plain English:

Set up a strong project skeleton and docs.
Break work into reviewable, detailed specs.
Automate execution with Python scripts, tmux, and AI CLIs.
Define “done” clearly and iterate.

It’s a practical, low-cost way to experiment with AI-driven coding — perfect for solo developers or small teams who want speed without losing control.