# If you thought the speed of writing code was your problem, you have bigger problems - Andrew Murphy

## Executive summary

The talk argues that focusing on increasing code writing speed via AI is optimizing the wrong metric. Drawing on the Theory of Constraints, the speaker asserts that the true bottleneck in software development is rarely the engineer's typing speed. Instead, throughput is limited by upstream processes (like discovery and requirements gathering) or downstream processes (like code review, CI/CD, and deployment). Engineers should use any 'spare capacity' gained from AI coding to improve tooling, fix tech debt, and optimize the identified process bottleneck, rather than simply writing more code.

## Key takeaways

- The Bottleneck is Not Coding Speed: The throughput of a system is determined by its single constraint (Theory of Constraints). If coding is not the bottleneck, increasing code output (e.g., using AI) will only create massive Work In Progress (WIP) and worsen the problem by creating more unreviewed PRs.
- Focus on the Full Value Chain: The value of code is in its utilization, not its creation. The most critical metrics to track are cycle time (idea to production), wait time (PR review time, scoping time), and deployment frequency, rather than lines of code or commits.
- Optimize the Constraint, Not the Code: If the bottleneck is Discovery, the focus should be on improving idea validation and requirements gathering. If the bottleneck is Review, the focus should be on improving review processes, not just writing more code.
- Leverage AI for Process Improvement: Instead of using AI to write more code, use it to aggregate disparate data (e.g., usage logs, product research) during the Discovery phase, or to automate deterministic checks (like database migrations) that can be implemented in tooling.

## Technical details

- Theory of Constraints (TOC): Every system has exactly one constraint, and the system's throughput is determined by that constraint. Optimizing anything that is not the constraint actively makes the system worse.
- Software Development Lifecycle (SDLC) Bottlenecks: The process flow includes Discovery, Prioritization, Coding, Review, CI/QA, and Deployment. The bottleneck can shift: if coding is optimized, the bottleneck often moves to Discovery or Review.
- Static Code Analysis vs. LLMs: For programmatic checks (e.g., flagging a database migration in a PR), deterministic static code analysis tools are often superior to relying solely on LLMs, as they are cheaper and more reliable for specific checks.
- Lean Principles in Software: The concept of 'waste' applies to software, including 'rework' (e.g., forgetting context on old PRs) and 'mental energy' (the waste of having to repeatedly relearn context).

## Practical implications

- Map the entire feature journey (ideation to customer hands) to identify where the longest wait times occur.
- Focus on improving the process bottleneck (e.g., Product Management defining scope, or QA/Reviewing PRs) rather than increasing coding output.
- Use 'spare capacity' (time above the current bottleneck) to invest in tooling, fixing flaky tests, and improving CI/CD processes, rather than writing new features.
- Adopt cross-cutting, user-centric teams that contribute across multiple codebases to break down organizational silos.

## Topics

Software Architecture, Build Process Optimization, Product Management, DevOps, AI Integration, The Goal, The Phoenix Project

Source: https://www.youtube.com/watch?v=kSzbuPFjdQo