Last week it was looms. This week it is potato chips.

I’m a huge fan of EconTalk, a podcast hosted by Russ Roberts. Russ is a great guy and his guests are invariably interesting. One of my all-time favorite episodes is Brendan O’Donohoe on Potato Chips and Salty Snacks, in which O’Donohoe and Roberts talk about how potato chips are made. Now that might not sound interesting, but I found it fascinating. First, O’Donohoe is both an expert and an enthusiast about potato chips. (Who isn’t?) More interestingly, he provides valuable insights into how the process has become increasingly efficient over time. 

The main thrust of improving the production of potato chips was discovering the bottleneck and then fixing that step in the process until it was no longer the bottleneck. Once that bottleneck was removed, something else was found to be the bottleneck. Then you’d fix that, and so on, until the process is so efficient that it isn’t worth taking the time to fix the bottleneck that is barely a bottleneck at all anymore.

After I wrote the loom article last week, it occurred to me that the process of software development is no different. And thus, to improve it, we should find the bottleneck, figure out a way to make it no longer the bottleneck, and repeat. 

And it seems obvious to me that the actual coding of the application is the narrow, high-pressure point in the software development pipeline. In a process full of friction, writing the code is usually the bottleneck that determines when a project gets finished.

So what happens if writing code ceases to be the bottleneck? Well, I think we are just about there with agentic coding, no? For the sake of argument, and to keep this column rolling, let’s assume that such is the case. Let’s take it as granted that writing code becomes something that happens over days and weeks, and not weeks, months, or even years. 

What would that mean?

Well, first of all, requirements would have to become more specific. Right now, developers tend to accept requirements that are more vague than they might like because they know that things can be continuously refined and that we can “figure that all out as we go.” That won’t work with coding agents.

If an agentic coding system is fed vague inputs, it will produce vague outputs, right? Garbage in, garbage out is as true a statement as there is in computing. Thus, what you tell your coding agent to do will have to be clear and specific. Getting that right will be the new skill that software development teams have to develop. You might even view it as “coding in English.”

The next result is that a lot more software will be created, some of it good, some of it bad. Right now, I suspect there are many ideas for software—both features for existing software and whole new applications—that aren’t being built because the actual writing of the code is too costly or too difficult for the folks with the ideas. 

Sure, this is going to lead to a lot more “AI slop” software—easy execution always amplifies bad judgment—but there will also be a lot more great ideas that actually come to fruition. Existing software will end up with a lot more features than human developers alone could deliver. It will be the job of product managers to make sure that the product stays useful. (As a former product manager myself, I can say it would be great to be able to plow more quickly through a backlog of ideas.)

Developers will shift their focus from coding clean and well-organized implementations to making sure that the agents produce clean and well-organized implementations. Instead of writing most of the code, developers will spend their time reviewing, rejecting, constraining, and refactoring the agents’ output. Or better still, they will spend their time directing the agents to do that.

Ultimately, the next bottleneck will become proper thinking about what should be done. When you can do everything, deciding what not to do becomes the really difficult decision. Deciding what not to do is a problem today. Imagine how much harder it will be when, instead of choosing three things out of seven, product managers need to choose 30 things out of 70.