Beyond the AI Hero: Building Sustainable Team Delivery in the Agent Era

One Person Moves Fast, But the Team May Not Catch Up

A hypothetical scenario illustrates the gap: a developer skilled in AI-assisted coding rapidly delivers a bulk-import feature, but critical business agreements live only in their chat session, test entry points are known only to them, and exception handling relies on their personal explanations. When they are absent, another member taking over a new import format must redo requirement clarification, test exploration, and error correction — erasing the time saved.

Personal efficiency is a team asset; exclusive knowledge ownership is a dependency the team must manage. Organizations cannot demand all time be spent on features while expecting shared capabilities to emerge spontaneously.

Sharing Sessions Can Start, But Formal Responsibility Sustains

Training and success stories show possibilities, but a single session does not embed practices into daily work. Understanding "retries must not duplicate writes" differs from having a maintained test entry, verified conventions, and confirmed usability for the next task.

Clarifying Three Categories of Responsibility

R&D Lead : Define improvement goals, allocate time and authority, resolve cross-team blockers.

Team Lead and Business Delivery Team : Select concrete problems, drive business owner confirmation of rules, own technical delivery responsibility.

Platform or Developer Productivity Maintainers : Provide shared execution, verification, and recording capabilities; maintain integration interfaces.

Platform capabilities (including Harness — tools, context, rules, verification environments) make testing, permissions, and recording default, but cannot decide business meaning. Post-deployment operational responsibility belongs to the convention owner, not by default to the delivery team or platform maintainers. Small teams may combine roles; the key is that the work is planned, has a named maintainer, and dedicated time — not perpetually "when we have bandwidth."

Authority needs boundaries: maintainers can fix shared test entry points but must not lower a project's acceptance criteria just to pass checks. Who maintains shared capabilities and who confirms business outcomes must be explicit.

Use a Real Handover to Test If Capability Stays in the Team

Document count does not prove handover readiness. A direct test: have another member complete a moderate change using existing artifacts. For the import feature, ask them to add a new input format — they should locate data conventions, reuse validation and retry logic, run required tests, and explain behavioral impacts. The original author may review but must not guide verbally. Recurring stalls reveal gaps: unclear design, hidden tool entry points, or unintelligible verification results.

This reduces re-explanation of already-settled details while preserving necessary discussions for new business questions. It also validates backup reality: a name on a list is not proof; actual completion of a change and exception handling is.

Hiring and Developing People Requires Assessing Distinct Capabilities

AI usage skill, engineering judgment, and collaboration ability cannot be merged into a single "senior" label. Some excel at prompting agents but cannot articulate failure handling; others have strong architecture experience but are unfamiliar with structuring AI tasks; some have both but hoard critical work.

In hiring, give a concrete import task with business context, allow AI use, then ask the candidate to explain the solution, show verification evidence, describe retry handling after partial failure, and leave a handover note. Observe whether they clarify limits, accept challenge, and fill gaps. One exercise cannot fully judge but identifies support directions. Tool fluency ≠ mature engineering judgment; a seemingly complete implementation still requires evidence review.

For onboarding, avoid letting juniors only hand designs to models and wait for output. Assign them a scoped end-to-end change: propose a solution, explain exceptions, demonstrate tests, reviewed by an experienced member. AI can assist each step, but cannot replace the junior's understanding of what they delivered.

Team Size Follows Responsibility; Automation Depth Follows Risk

Whether AI shrinks the team depends on business scope and operational burden. Prototypes, internal tools, and continuously served systems cannot share the same staffing assumptions. Even with fewer people, responsibilities — requirement confirmation, design judgment, quality checks, production support, personnel backup — persist. They can be combined or supported by platforms/external services, but faster coding does not make them disappear.

Example: changing an import page's prompt text differs in risk from altering retry-time data processing rules. The former may proceed through automated checks; the latter involves duplicate writes and data recovery, demanding richer verification and business sign-off. Therefore, avoid uniform "fully autonomous" mandates or identical manual approval for every minor tweak. Decide automation depth per task based on impact scope, reversibility, and verification adequacy.

Agent execution logs provide traceability; the organization must still define who receives alerts, who decides recovery, and who owns follow-up. An automated process that stops with no one to take over remains a delivery gap.

Start in One Team to Make Improvement Non-Voluntary

Organizational change need not begin with restructuring. Pick one recurring task class, assign a maintainer, allocate necessary time, enable a second person to truly take over, and observe shifts in delivery and maintenance load. The previous article discussed recording benefits; here the maintainer uses usage and cost data to propose adjustments, the R&D lead coordinates resources to continue, adapt, or stop; business-risk changes still require the responsible owner's confirmation. Otherwise metrics become just another report.

Summary

The goal is for AI to let developers own more complete work, while ensuring those capabilities do not stay isolated with individuals. Teams need experts to blaze trails, others to take over, shared capabilities to have maintainers, and newcomers to develop judgment. Only when the organization can stably absorb and extend the strengthened individual capability can continuous benefit be realized.

Reference: InfoQ, Fu Yuqi & Tina: "Stop Fixing Code, Fix the System: DevOps Father Says Organizational Change in Agent Era Is Harder Than Technology", 2026-08-06. https://www.infoq.cn/article/hLA2I6DD1v0ou0sE8KKB. This article uses the organizational collaboration perspective from that piece as a starting point. The import feature, handover scenarios, and hiring exercises are hypothetical; responsibility divisions and implementation suggestions are personal analysis, not validated organizational transformation outcomes.