Topic

AI-Native Organization in Practice: From Loop Engineering to Graph Engineering

After personally consuming 36 billion tokens per month, I found that the bottleneck was no longer model capability—it was human attention. This talk shares how I designed and implemented a four-layer Engineering Loop during the R&D transformation of QQ Speed. The approach builds Agent-friendly context, binds SDD to requirements, and divides human attention into three modes: decision-making before execution, release during execution, and review after execution. This increased single-person concurrency from 5 to 20. Graph Engineering addresses a broader question: if one Agent can do something right, how can an entire group of people and Agents do it right consistently? The session will also provide a full postmortem of three major failures: a 200K-context breakdown, a runaway recursion exceeding 7,000 levels that consumed 734 million tokens and cost $533, and a 44,000-line change produced in a single day that was ultimately never merged. These failures led to six hard guardrails now embedded in the engineering workflow. Outline 1. Why Loops: From Prompts and Harnesses to Engineering Loops Four stages of abstraction: from hand-written Agent loops, to task-oriented Agents, to /loop declarations that define wake-up conditions, and finally /goal declarations that define verifiable end states—moving the control plane from application code into the Harness. Where it started six months ago: using a single natural-language instruction to batch-handle issues, scheduling automated patrols every 30 minutes during the workday, and allowing Agents to create branches, make changes, and submit merge requests autonomously overnight. A critical distinction: loops inside the Harness correct the current task, while an Engineering Loop uses feedback to improve the next iteration of the system. A four-layer engineering framework: second-level Hooks, minute-level CI Events, hour-to-day-level SDD, and organization-level Graphs, with a clear division of what humans need to inspect and what Agents can handle autonomously. 2. Layer One — Loop Agent Context: Ensuring Deterministic Errors Do Not Survive a Second Iteration Using AI to develop tools that constrain AI: building a golangci-lint module plugin in one day and compiling six non-negotiable logging conventions directly into the binary. Why linters work better than simply adding more rules: the more rules a model is asked to follow, the lower its compliance rate. Detection followed by automated correction creates lasting enforcement. Three principles for PostToolUse Hooks: cross-CLI compatibility across different event formats, flock-based queuing to prevent concurrency races, and timeout behavior aligned with the 120-second execution limit. Three engineering trade-offs for pre-commit checks: scan only packages containing staged files, always revalidate after automatic fixes, and prohibit bypassing checks with -n while maintaining an auditable allowlist. 3. Layer Two — Loop CI Workflow: Turning Red Lights from “Call a Human” into “Call an Agent” The lifecycle of a merge request: push, MR creation, lint self-healing, review comments, approval, rebase and merge, and nightly changelog generation—seven event-driven stages. CI failure self-healing: failed stages trigger an Agent, which compresses thousands of lines of logs into actionable context, fixes the issue directly on the branch, and automatically reruns the pipeline until it turns green. Multi-Agent Review Loops: inline questions trigger OpenCode to respond in the original discussion thread, while rejected feedback automatically creates follow-up issues linked to comment anchors and build logs. Real-world results and boundaries: 153 out of 1,616 MRs followed the auto-approve path, representing 9.5% of all MRs, with an average merge time of 8.5 minutes and a median of 2.2 minutes. Hard gates remain, and humans must step in when confidence is insufficient. Unattended scheduled workflows: worker Agents automatically reproduce and fix issues, while Git conflicts are automatically rebased and semantically merged. When resolution fails, the full context is preserved in the discussion. 4. Layer Three — Loop Development Workflow: Dividing Human Attention into Three Modes Three iterations of ~/workflow: YAML moves state outside the chat, Mermaid maintains only the process skeleton, and the clarify SKILL.md was reduced from 191 lines to 66. Decision before execution: every one-sentence requirement is expanded to clarify four essentials—scope, constraints, acceptance criteria, and risks. No code is written before the design is approved. Attention release during execution: separating generation from verification improves test effectiveness. A risk-driven suite of 668 test cases, combined with cross-model validation, reduced clusters of “same wrong answer” failures from 31–49% to 6%. Concurrency engineering: increasing single-person concurrency from 5 to 20 through a six-stage P/A/T/B/G/R prompt lifecycle. Three workspace modes—persistent sessions, isolated parallel work, and shared parallel work—converge through a unified /conflict mechanism. Review after execution: the same prompt is sent through 10 deep-review paths across four models. Findings are classified into code defects, insufficient testing, Harness defects, and design issues, then fed back respectively into linters, tester skills, skill constraints, and clarification templates. How to know whether a loop is improving: focus on declining metrics such as MR comment volume, the proportion of repeated comments, and time spent on pre-execution clarification—not simply “how much code was written.” 5. Layer Four — Graph Engineering: If One Agent Can Do It Right, How Can a Group Do It Right? Applying the vocabulary of graph engineering: State, Node, Edge, and Runtime as four explicit engineering objects. Agent graphs are typically not DAGs, so recovery points, human gates, and tracing must be deliberately designed. Simply copying an individual loop creates exercise, not productivity. Connecting multiple people’s loops into a graph requires explicit file ownership, isolated worktrees, and consistent review standards. From giving people a fish, to teaching them how to fish, to giving them the motivation to fish: providing an SDD framework copies an answer; open-sourcing DSH plugin implementations copies a method. Across nine repositories, a three-layer composable plugin architecture makes capabilities installable, combinable, and testable. A counterexample as evidence: the feature-ugc project did not copy the SDD workflow directly, yet independently converged on the same concepts—parallel_group, sub-Agent isolation, and file-based handoff—resulting in eight commits and production deployment across three business domains in five days. 6. Failures and Brakes: Three Incidents, Six Guardrails, and Controlled RSI Incident One: When 200K Context Was Not Enough. A single-task exploration consumed 270K context, while similar tasks reached 670K tokens. The solution was to split work along three dimensions: responsibility, phase, and trigger. Incident Two: Two Nights with the Same SDD. Under normal conditions, the workflow completed in eight minutes. In a runaway case, recursion exceeded 7,000 levels, consuming 734 million tokens and costing $533. The difference was not task complexity—it was the presence or absence of explicit termination conditions. Incident Three: 44,000 Lines in One Day. Of the generated code, 44% was executable business logic and 56% was defensive hardening. After 27 review rounds and 193 findings, the change was ultimately not merged. The loop had executed precisely against the wrong boundary I had given it. Six hard guardrails embedded into the workflow: define the boundary on one page first; enforce a 3,000-line/40-file change budget; separate tools from business logic; define boundaries before parallelizing; delete before adding; and record BLOCKED states truthfully. Closing: the inner loop delivers tasks, while the outer loop improves the system that produces improvements. A loop without feedback is merely repetition—human in the loop, human builds the loop. Key Takeaways A four-layer Engineering Loop framework that can be applied directly: second-level Hooks, minute-level CI events, hour-to-day-level SDD, and organization-level Graphs, with a clear attention-allocation model for what humans should inspect and what Agents should handle autonomously. Implementation details rather than abstract concepts: practical patterns for PostToolUse Hook compatibility, queuing, and timeouts; incremental pre-commit scanning; CI failure self-healing; auto-approve policies; and a complete feedback loop that turns MR comments into input for the next Agent iteration. A measurement framework that goes beyond lines of code: declining metrics including MR comment volume, repeated-comment ratio, and pre-execution clarification time, supported by real-world baselines such as a 9.5% fast-lane rate, an 8.5-minute average merge time, single-person concurrency increasing from 5 to 20, and 668 risk-driven test cases. Three complete postmortems and their real costs: a 200K-context breakdown, a 7,000+-level recursion that consumed 734 million tokens and $533, and a 44,000-line change that was ultimately abandoned—along with the six guardrails derived from these failures. An organizational path from individual Loops to team Graphs: file ownership, worktree isolation, consistent review standards, unified /conflict resolution, and three strategies for scaling capabilities—from copying answers, to copying methods, to creating the conditions for new Loops to emerge. A reusable decision framework: when humans should be in, on, or out of the loop, which workloads benefit from parallelism and which do not, and when to install brakes on an autonomous workflow—avoiding the trap of turning Token Maxing into the next Goodhart’s Law metric.