Work Stories 03 | One request, three Wakers working in relay

QoderWake Work Stories 03: One request. Three Wakers.

Over the past few months, a few new teammates have joined the QoderWake team's DingTalk groups, covering product management, frontend and backend development, and testing. We did not assign them mentors or set an onboarding period. Soon after joining, they had read the project repository's documents and code and started development. “Ask Waker” and “Let Waker review it” quickly became everyday phrases on the team. Who are they? They share a name: Waker, the digital employees involved in QoderWake product development. We now work closely with Wakers throughout the development process. They help manage the coordination bottlenecks of finding information and people, along with the repetitive cycle of asking someone to test and someone else to fix issues. That collaboration has helped the team iterate through several product versions a week.

Three Wakers coordinate requirements, development and testing, followed by final human acceptance

How Wakers participate in the development cycle

In the requirements discussion group, the product Waker brought a completed product requirements document (PRD) and asked the responsible development Waker to review it. The development Waker returned a conditional approval: three blocking issues needed clarification, nine details needed expansion, and six decisions required human judgment. Each decision presented clear options and trade-offs around the technical contract: how should drafts be stored, where should approval boundaries sit, and what should the template quota be? The product Waker confirmed each point with the human product manager in the group and finalized the PRD. The development Waker then produced a Spec for the other group members to confirm. At 14:20, one of our developers instructed Waker to create a working branch from the release branch and begin implementation. Once finished, it was to ask another development Waker directly for Code Review. At 15:31, the change was submitted for review: a snapshot boundary engine, three database tables, 10 HTTP routes and seven CLI subcommands. The diff was +5773/-4, and all 150 tests passed. At 16:07, the reviewing Waker returned its first review: one blocking issue involving double JSON encoding in three profile fields, plus six suggestions. Within another 20 minutes, the development Waker fixed the blocking issue and adopted five of the suggestions. At 16:34, the reviewing Waker approved the follow-up review, and the review gate turned green. At 17:55, the testing Waker had generated 36 test cases from the PRD and Spec, run the tests, and reported three bugs to the group. After fixing them, the development Waker privately contacted our development lead to ask whether the change could be merged. From starting work to code ready for merge, the process took less than four hours. The Wakers could reason and work independently, each within a clear role. They paused for people when permissions were needed and reported issues rather than hiding them. Team members did not write the PRD or code themselves, but made every key decision: setting direction, assigning responsibilities, establishing safety boundaries, confirming the technical contract and accepting the results.

Translated illustration of the collaboration record, from instructions and Spec to review, fixes, testing and human merge approval

The illustration above is an English summary of the original collaboration record.

​How Wakers participate in the development cycle

How Wakers participate in the development cycle