Nobody Agrees About Agentic Development

At Convex's Abstract conference, moderator James Cowling (Convex) joins Jean-Denis Greze (Town), David Cramer (Sentry), and Theo Browne (T3 Chat and T3 Stack) to debate what agents change about software engineering. The useful disagreement is not whether agents can write code, but how they change the need for review, the development of architectural judgment, and the organization of engineering work. These are practitioners' accounts and forecasts, not a controlled productivity study.

This English summary is an editorial translation/paraphrase of the saved French auto-generated captions. The capture API exposed no English track at capture time. Names and affiliations follow the video's description; the original audio was not independently checked.

Faster implementation does not settle the review question

• Productivity depends on which work was expensive. Cramer reports internal gains from coding tools and easier access to information, without a comparable transformation in Sentry's production-facing market. Greze gives a more specific mechanism: Town can delegate integrations after formalizing their contracts, while an engineer with product and design skills can iterate without repeated handoffs. He still distinguishes rapid feature exploration from subsequent engineering work, where agents can break existing abstractions. Browne says his small team's large open-source project would not be viable without agents helping contributors and triaging pull requests. These are different workloads, not comparable speedup measurements. 02:42–08:23(opens in a new tab)
• Review boundaries follow consequences, not just confidence in the model. Greze describes blocking review around APIs, authentication, stored data, encryption, and access rights. For other product changes, feature recordings and automated tests provide evidence of behavior without requiring the same inspection. Cramer asks how serious a mistake would be and how quickly it could be reversed; he says Sentry still requires review for production systems. Cowling says Convex reviews all code and stresses review's roles in architecture and developing engineers, beyond finding bugs. The panel does not establish a universal case for abandoning review. 08:23–11:32(opens in a new tab)
• Browne's alternative is to make errors cheaper, not merely to read less. He describes agents testing changes, checks that catch problems before deployment, and clear architectural boundaries that leave less room for improvised solutions. His argument is that much higher code volume should prompt better detection and recovery systems rather than a proportional increase in human review time. His high pull-request throughput is a self-reported operating example, not proof that the same approach is safe for every system. 11:32–14:24(opens in a new tab)

Architecture and learning remain contested

• Cheap experiments can accelerate learning; cheap patches can also accumulate complexity. Cramer argues that agents can solve isolated problems while missing unstated constraints and the context needed to keep a whole system coherent. Browne counters with using agents to build load tests for several candidate architectures: cheaper experiments let him reject ideas he would previously have avoided implementing. Greze adds that cheaper refactoring changes which imperfections are tolerable, but sufficiently tangled code can still become expensive for agents to repair. The disagreement is about how to use faster iteration, not whether architecture matters. 14:24–22:02(opens in a new tab)
• The learning opportunity still requires deliberate inquiry. Browne suggests asking agents to explain a codebase, while acknowledging that their explanations can be wrong and recommending conflicting perspectives. 11:32–12:36(opens in a new tab) Greze emphasizes looking beyond passing tests to future features and whether the next agent can extend the design cleanly. Browne also suggests comparing accepted and rejected changes and identifying recurring reviewer concerns. He describes unusually capable young contributors, not a representative outcome for all junior engineers. Cramer counters that motivated young people already learned through open source; tools do not remove the need for care and ownership. 22:02–26:42(opens in a new tab)
• Ownership means preventing recurrence, not just closing the bug. Cramer's incident-review example contrasts fixing one defect with redesigning the system or adding checks so that the failure does not recur. He connects shallow post-mortems and poor agent-generated pull requests to the same failure of engineering responsibility. His claim is that good agent-assisted work remains possible, but is not automatic. 24:53–26:42(opens in a new tab)
• Lower creation costs can make rejection easier—but not for everyone. Cowling worries that generated plans and code become psychological anchors: once an artifact exists, it starts to feel like the settled answer. Browne reports the opposite response: cheaper generation makes it easier to close unsuitable pull requests, keep only useful commits, and discard alternative designs. This is a difference in working habits, not evidence that agents universally eliminate attachment to code. 26:42–30:56(opens in a new tab)

Distribution and openness after code gets cheaper

• A defensible business needs more than an implementation. Greze treats future competitive advantages as unresolved, while proposing customer relationships and network effects—value that depends on other people or agents using the same system—as candidates. Browne emphasizes distribution: reaching the right users and delivering something they keep using. Cramer notes that switching vendors was already possible when the savings justified it, even before agents made migration easier. Predictions about consolidated AI interfaces and weaker switching costs remain forecasts, not settled market outcomes. 30:56–38:40(opens in a new tab)
• Source access helps both customization and vulnerability discovery. Cramer values public development and community while retaining a “fair source” licensing approach; that is not a claim that all his software has an unrestricted open-source license. Browne argues that visible code helps agents understand, modify, and repair software, while acknowledging that backend source access can also help attackers find weaknesses. He reports useful community security fixes and predicts that cloning and vulnerability discovery will increasingly affect closed software too. Neither claim establishes that publishing source automatically makes a system secure. 39:35–43:31(opens in a new tab)

Closing advice: Browne encourages following curiosity into projects that were previously too expensive to explore. Greze emphasizes building something that improves another person's day. Cramer recommends learning alongside capable builders and demonstrating care through public work and feedback. Cowling closes by defining engineering as solving people's problems under constraints, rather than simply writing code. 45:27–48:50(opens in a new tab)