Raw

The speaker’s central claim is that coding agents will not produce major acceleration inside an unchanged SDLC: teams must move people from line-by-line implementation toward setting boundaries, supplying feedback, and running agent work as both engineering and research. This is an experienced practitioner’s view, not evidence that the model will work for every team.

**For conventional software, autonomy needs deliberate control and feedback.** The speaker says a Cursor license alone did not change behaviour: developers used defaults, needed three to six months to learn, and resisted abandoning familiar tools and practices. Their proposed response is to retain human control over accountable interfaces—contracts, APIs and databases—while agents generate and check the surrounding implementation. Feedback from tests, browser/server behaviour and users is presented as the mechanism that lets agents self-correct; they argue agent review should feed coding agents directly, rather than create another queue of comments for humans. [00:02–00:12]

**The process bottleneck shifts from coding to handoffs and broad ownership.** If each role works faster with an agent, the speaker argues that Agile handoffs become the limiting delay. They contrast a classical team that can spend a month without code with a “product engineer” who can ship a mobile app and website in days, while acknowledging such people are scarce. Their practical interim model is smaller, T-shaped teams covering more roles, backed by mandatory testing and feedback loops. [00:10–00:12]

**Agent systems require two disciplines, not a standard delivery team alone.** The talk divides the work into engineering—integrations, MCP, deployment and agent access rights—and research—datasets, benchmarks, metrics and evaluation methods. The speaker claims a team needs both capabilities, either in one unusually broad person or in complementary roles. They recommend framing an agent as business functions, with inputs, outputs, controls and integrations, using IDEF0 language; this reportedly helped teams start ambiguous work and cut an overgrown agent with roughly 100 tools down to its necessary functions. [00:14–00:20]

**Managing agents means managing experiments, not treating every failure as a Jira bug.** The speaker says agent errors should become evaluation data and hypotheses to test against agreed business metrics. In this model, a sprint contains experiments as well as features, and clients need visibility into what was tested and what failed. They cite the ML System Design Doc as a useful record of experiments and decisions, but note it requires disciplined documentation culture. [00:20–00:22]

**Services and governance must adapt to agents as a new actor.** The speaker argues existing services are designed for people, whereas agents need suitable entry points, permissions and security controls. They offer the example of a compromised shopping agent using a retailer’s MCP server, and raise recovery and protection questions without claiming answers. They also cite an incident in which an open-source assistant filled a disk and then deleted its own skills and memory during cleanup, supporting their warning that infrastructure guardrails remain necessary. [00:22–00:26]

For next week’s review, the most testable claims to bring are: where our human approvals must remain; whether our feedback signals are usable by agents; which handoffs persist after agent adoption; whether agent work has explicit evaluation and experiment loops; and whether our services, permissions and operational guardrails recognise agents as distinct actors.