One Person + AI = A Team? The 'Individual Team' Golden Trio

Introduction: From Honeymoon to the Trough of Disillusionment

AI coding has passed its honeymoon and entered a "trough of disillusionment" — it no longer looks magical, and pitfalls abound. Crossing this trough requires solid engineering details, not new directions. This talk covers three parts: (1) the programmer's new paradigm — turning AI's raw capability into personal throughput; (2) from individual to team — the TeamAI "golden trio" (Spec, Skill, Test Asset); (3) a longer-term reflection on what changes and what stays constant in the AI era.

01 The Programmer's New Paradigm: Context Engineering

Background & Pain Points

Five major blocks in large-scale AI adoption: (1) legacy system AI-ification, (2) daily work platform AI-ification (IDEs, internal tools), (3) code/document knowledge asset AI-ification, (4) managing AI-generated code volume exceeding human review capacity, (5) organizational/talent challenges. This talk focuses on block 2 — the developer work environment — because it yields visible gains and touches every engineer.

Three real bottlenecks observed: (1) individual productivity gains (40-60% by mid-2026, ~46% in the speaker's team) don't automatically become end-to-end flow gains; (2) AI code quality lacks good governance/evaluation; (3) complex legacy scenarios with heavy technical debt remain hard for AI.

Three Real Code Examples: Why AI "Means Well but Does Harm"

Time-slice handling: In a high-concurrency scenario, the team deliberately pushed a time slice one slot later to buy buffer. Claude Code repeatedly "corrected" this as a bug, not recognizing the intentional design.

Connector ID mapping: A connector translated external system IDs to internal business IDs via string-based hard-coded mappings (e.g., 1→1, 2→4). AI couldn't grasp the domain logic — it saw only meaningless number swaps.

Cache refresh trade-off: Most tables cached every 5 minutes; a few needed 1-minute refresh. The team used if-else to balance time vs. space. AI kept "suggesting better solutions" ignoring the explicit trade-off.

These are private knowledge embedded in code — invisible to AI without explicit context.

Chat vs. Agent Mode

In Copilot-style "Coding with Chat", humans intervene heavily and catch issues. In "Coding with Agent" (long-horizon coding), the agent acts autonomously; problematic changes can drown in massive diffs, making review nearly impossible. Traditional good-code practices (domain modeling, design patterns, layered architecture, comments/logs/exceptions) formed a known playbook; the new era lacks a consistent, effective way to define "good".

Context Engineering: More Engineering Than Prompt Engineering

Prompt engineering is art (natural language). Context engineering structures what the agent sends to the LLM into five blocks: Input info (system prompt) , Conversation history , Project memory (specs, progress), Knowledge (code, docs), Tool calls . Most context assembly is delegated to the agent, but that's exactly where leverage lies.

Trace tool is essential. Install a local trace collector (e.g., SQLite + simple UI) to log every request/response, inspect payloads, measure interaction counts, latency, token usage. SQL queries reveal agent behavior; alerts can flag anomalies.

Context length sweet spot: METR data shows solvable task length doubles ~every 7 months. Model performance peaks at 45-55% context utilization; beyond that, "stagflation" degrades intelligence. Managing context is therefore critical.

Five Pillars in Practice

1) Tool Calls: Changing Tools Often Yields Immediate Gains

Agents heavily use CLI tools for code retrieval — mainly git and grep. But grep is semantic-driven and lacks symbolic understanding; Claude Code still lacks LSP/AST support, so it "reads" code linearly, bloating context with poor results. Two tool-improvement strategies:

Post-call rewrite: Run local tool, then compress/rewrite output. Representative: rtk — mature, stable, rewrites common commands.

Tool replacement: Replace grep with AI-native tools using hybrid retrieval (symbolic AST + semantic embeddings). More flexible, larger improvement space, but less mature.

Comparison: rewrite-type (rtk) = mature/stable; replacement-type = more flexible/larger upside.

2) Knowledge Base, Conversation History & Project Memory

Knowledge base in three flavors: local project code, cross-project centralized, semantic-level (e.g., fast context). Team currently uses first two.

Conversation history splits into long-term and short-term. Long-horizon tasks produce huge, sparse histories. Built-in compact does truncation, discarding early intent and next actions. Team uses pi-vcc for semantic folding : compress "how we found it" (curl→fail→retry→read 7 times) into "what we know", anchoring core directives, freeing context for actual output. Compression rules are customizable per team.

Project memory extracts true decisions from chat fragments and scattered docs into a human-readable, manually editable Markdown directory: project intro, spec, decision log, tombstones (confirmed bad practices), candidate memory (planned but not started), entity table (team-specific terms ≠ common names). Serves both agents and humans.

3) Site Cleanup: Keep the Workspace Clean

Long-horizon tasks leave abandoned code/docs when plans change or bugs are fixed. Cleanup splits into doc cleanup (semantic, needs LLM + templates) and code cleanup (LSP-based dead-code detection). Known AI-generated garbage patterns (e.g., Claude Code's typical leftovers) are codified; cleanup runs automatically via hooks or manually via slash commands.

Core Mindset: Offload, Minimize, Retrieve, Isolate — and Polish Your Loop

Four core actions: Offload — progressive loading, keep stuff in files, load on demand (infinite space); Minimize — only current-problem info in context; Retrieve — fast, accurate local fragment loading; Isolate — decompose complex problems into simple ones for clearer context. All tooling serves these four.

Validation requires a personal Loop : daily practice + trace tool (to pinpoint which of the five pillars failed) + adjust tool config/usage + iterate toolbox.

02 TeamAI Golden Trio: Turning One Person into a Team

From Vibe Coding Chaos

Vibe Coding (non-technical builders creating apps via chat) went viral but hit real incidents: runaway LLM calls/token costs, rm -rf disasters, privilege escalation. Without constraints, Vibe Coding stays at shallow toy apps, never reaching production scale. Business development lives on ambiguity — "I need an approval flow" actually means multi-level countersign, return, transfer. Chat logs are leaky funnels; ambiguity is the killer.

Three Agent-Facing Tools: Spec, Skill, Test Asset

Spec — defines "what to do" (intent, decisions, plan, execution) as Markdown files. Markdown becomes as important as code: humans write Spec, AI writes code. Flow: Vibe (diverge) → Spec (crystallize) → Build (execute). Spec is the code; code is just compile output.

Skill — defines "how to do" as reusable code/capability modules. Not a single SKILL.md but a directory: markdown/, scripts/, references/, assets/.

Test Asset — verifies "is it correct" via continuous automated validation. Stricter TDD guards the baseline: AI tends to hack tests green, violating TDD spirit.

All three use Markdown as the core human-agent medium. Team built IDE plugin for Markdown review (during human-agent dialogue, not just PR) and a stronger Markdown validator for richer semantics.

Production-Grade Skill Development

Five principles: (1) Pattern-driven (choose pattern first; anti-pattern = one template for all), (2) Constraints upfront (explicit prohibitions for weak-model errors), (3) Description = index (include user keywords, not internal workflow summary), (4) Config externalized (business data in references/assets, never inline in SKILL.md), (5) Quantifiable verification (each skill has evals.json; improvements must pass holdout).

Five patterns: Tool Wrapper (ad-hoc expert), Generator (produces deliverables), Reviewer (judges completeness/compliance), Inversion (recursive questioning for complex problems), Pipeline (wraps above for real-world complexity). Selection heuristics: fixed input structure? need scoring? need user context? need strict verification?

Front matter must be written for triggerability (activation by LLM), not readability. Only one pattern allowed per skill.

Gate constraints ("guards"): 6 general (G1-G6) + pattern-specific, ~15 total. Examples: output only raw SKILL.md (no fences, no self-eval), front matter = metadata only, no root-level files, no custom metadata.pattern, no code execution. Derived via RL from real usage. Validation lifts: tool-wrapper +162.9%, reviewer +153.9%, pipeline +169.1%, inversion +45.5%, generator +37.9%, avg +113%. Harmless on top models.

Static docs failed; team built an online evaluation service : package skill, submit, auto-check gates & test cases. Runs in pipeline or ad-hoc. Local test-case generation is hard; centralized evaluation solves it.

Real Case: Rapid-Requirement Semi-Automation

Two requirement types: project (complex, long) vs. rapid (≤3 days, ~60% of load). Rapid flow = "human at both ends, AI unattended in middle" across three stages:

Front: Requirement Decomposition (Human A)

Convert PM tool + product tool + dev knowledge base into Markdown. Key hurdle: database knowledge. Solution: code-ify DB knowledge — create ORM-like entities, place in codebase for AI learning (dedicated repo). Outputs: Task (standard), Open Spec (requirement-relevant subset), auto-dev.yaml (dev rules: isolation, execution, TDD, review intensity, ready/pause strategies).

Middle: AI Unattended Execution (N Agents)

Five-state machine: Open → Design → Build → Verify → Archive → Summary. Not all steps use Open Spec; some use auxiliary tools. Inner TDD loop (red→action, green→next). Dispatch to concrete coding agents. Critical quality gates (8 red lines from the ~15 guards): single-file diff < 20 lines (else escalate to project flow); all four knowledge bases (product, dev-doc, code, DB) must be accessed; full execution trace recorded and passed downstream as acceptance evidence.

Back: Integration Test & Test Assetization (Human B)

Human reviews MR, merges, runs real integration tests (even though AI ran unit tests). Test asset challenge: QA skill gap — many still use mind maps. Solution: don't break flow — accept mind maps, auto-convert to Markdown, scheduled job structures into test targets/cases. One slash command deploys to test env, integrates with micro-environments. Docs → Robot Framework scripts for execution.

Breakthrough: Self-healing as baseline. Traditional UI automation brittle; locator changes break tests. Now test scripts hold zero UI locators. HealListener does hierarchical self-healing: as long as "batch search merchant ID" text exists, position/id/xpath changes don't matter. If business logic unchanged, test heals. First time self-healing moved from aspirational to table-stakes.

Become an "Individual Team" First, Then Human-Agent Collaboration

Two-phase TeamAI rollout: Phase 1 — role boundaries dissolve; each engineer becomes a "full-stack + expert" composite (e.g., architect AI enables full-stack + PM). Phase 2 — automated agents (PM Agent, Java Agent, Python Agent, Page Agent, Test Agent, CI/CD Agent, Code Security Agent…) join as team members alongside humans. Rapid-requirement automation exemplifies Phase 2. Phase 1 (individual team — every programmer builds personal agent suite matching their style) is prerequisite for Phase 2.

03 What Changes and What Doesn't in the AI Era

"What Wall Is This?" — The Technologist's Mental Habit

Non-technologists brainstorm ways over/through a wall (tunnel, ladder, fly). Technologists first ask: "What wall is this?" It's a wall inside a maze; we're in the center. Asking reveals the maze structure — walk around, crawl through. This habit — abstracting business domain into technical domain, mapping — comes from experience + understanding objective laws (abstraction ability). That's why technologists own deep reasoning problems.

Technology's Essence: Bottom Layer Changes, Recursive Structure Stays

Technology = purposeful programming of tools per principles → infinite applications. It's a recursive hierarchical tech stack + engineering practices around it. Diagram: top = value creation (efficiency, agility, new business value); bottom = business domains, layered architecture, domain knowledge, engineering systems. Bottom layer changes (cloud, distributed, mobile, now AI); top structure stays stable . If you excel at the stable layer, you have enduring advantage — just combine it with the new bottom.