Role shifts across the agentic software lifecycle

Origin. On September 28, 2026, Dru asked for this within the Agentic Software area (path agentic-coding), not a separate area: how are product, design and engineering roles changing, and how do downstream marketing, sales and support roles change?

Research questions. Who defines customer intent and acceptance criteria when coding agents can implement larger features? What becomes of prototyping, design decisions, technical architecture, review, release authority, QA and incident ownership? Can domain specialists directly make or steer product changes, and what new collaboration and accountability follows? How do marketing launch timing and assets, sales product knowledge and demos, and support triage and feedback loops change when software can be altered more quickly? Investigate shifts in skills, apprenticeship, bottlenecks and organizational boundaries rather than presuming headcount reductions.

Dru’s September 30 conversation and October 1 clarification. In the manager-workflow discussion, Dru said summaries cannot solve the volume of asks: even good agent digests leave him and the team too much to follow. He wants agents to answer and close routine requests themselves, within a leader’s explicit principles and boundaries, so that the leader leaves the critical path. On October 1, 2026, discussing the Taobao external-support post, he clarified that by autonomous loop closure he meant internal AI usage, not primarily customer-facing support. Research internal team/organizational requests and their action rights first; do not recast his operating thesis as a customer-support automation claim. It is a hypothesis, not evidence yet of reliable agent closure. See corrected closure question and planning and tracking.

First-person role example, October 1. Neil Ebrey at Bitmovin, a senior software engineer in Support who calls himself a nontraditional software engineer, says he designed and shipped the agent system that now handles some customer tickets. He moved from internal Zendesk summarization through agent-assisted bug reproduction to bounded customer-facing triage and closure. This is support as builder and authority designer, not merely a downstream consumer of an engineering ticket—but its external-ticket closure does not directly test Dru’s internal-requests thesis. No original request cohort, code review record, customer acknowledgement, repair ownership or independent assessment of his ability to maintain the system. In contrast, Linear’s duplicate-canonical issue transitions keep a human CX notification step after merge; these are two distinct products and closure policies.

Implication to test. Translate principles into inspectable decision rights rather than another reporting ritual: which internal asks agents can resolve, which information or system changes they may make, what evidence establishes requester acceptance, where uncertainty or risk triggers a specialist, and who can reverse an error. Compare manager attention and end-to-end internal requester outcomes—including wrong answers, reopenings and repairs—before and after; distinguish personal confidence from warranted autonomy. Study customer-facing role changes separately. The review-autonomy evidence describes specialized architectural and test investments behind optional human PR review, not blanket permission to remove accountable owners.

Evidence to seek. Firsthand organizational examples with before/after roles, decision rights, handoffs and consequences; counterexamples where speed increased coordination load or uncertainty; measured gains versus aspiration. Link to planning and tracking, review responsibility and value and human time.

Administrative correction. A standalone area was created in misunderstanding and marked superseded. All substantive work belongs here.