AI Hype and the Theory of Constraints
Coding is not the bottleneck.
Let's talk about AI Hype and the Theory of Constraints. From a business perspective, the key metric is "lead time." The time it takes to get an idea to the point where it's producing revenue ("in the customer's hands"). That process involves a complex web of processes, dependencies, and communication, though it can be linearized to some extent. Imagine that it is linear for the sake of argument—a chain of activities starting with exploration and market research, going through strategic (and some tactical) planning, architecture, analysis, tech research, and other thinking, coding, testing, feedback and modification, and operations, ending up with sales, distribution, and support. Add politics and bureaucracy, not having required skills on the teams, etc., to the mix as well.
That whole tangle is called the "value stream." The lead time is controlled by the slowest element in the value stream—the bottleneck (or "constraint"). You can attempt to clear the constraint, but more often than not, all that does is uncover a formerly hidden constraint. More to the point, putting effort anywhere other than the constraint is a waste of time and money. All that does is pile up "inventory" (work that's done and paid for but isn't producing revenue—a financial liability) in front of the constraint, or create excess capacity (people with nothing revenue-producing to work on) behind it. Firing people in the "excess capacity" region is extremely risky because, once you break the bottleneck, not having enough people in those areas creates a new bottleneck, and you will have accomplished nothing. Given that the bottleneck is often upstream of coding, any cost savings you see from firing devs are illusory (and temporary). The cost of adding the devs back when you need them far outweighs any illusory savings.
Coding speed is rarely, if ever, the bottleneck. Even if the fantasy that AI will speed coding by 100% or more were true, it would not decrease lead time. Firing half of your people because of an immagined 100% improvement in the other half will also not relieve the bottleneck. The only way to decrease lead time is to improve the entire system of work. Knee-jerk firing will not do that.
One thing that AI "vibe coding" does reasonably well is create throwaway prototypes, which gives you a way to put something new in front of your customers (or at least a very small subset of them) quickly to get feedback. The word "throwaway" is the critical part of that first sentence, though. You'll definitely have to replace that "vibe" version with something that's production quality. I should add that this works best with something that's entirely standalone. I would not set the LLM loose on my existing system without serious supervision, so I wouldn't modify existing capabilities in this way unless I could isolate that capability entirely from the main body of the system.
I'm wondering how a (perceived) speed-up in coding would affect the product management function. We always have more ideas than we can build, so we select for the most promising avenues. A speed-up allows you to build more but not better things, because you're presumably already prioritizing your best options?