Joe Duncko, who’s an engineering director I’ve known from hackathons and local meetups for a couple of years, recently wrote a piece for his blog: Organizations Adapt to the Cost of Iteration. He argues that:

• Businesses have historically been hesitant to add new software features to their products because of the time investment that’s required to implement them;
• Also, it’s been hard to iterate and improve features because of the delay that a lengthy implementation process creates between having an idea and getting user feedback on it;
• And now that coding agents make it quicker and easier to write new software, businesses should be more willing to try new ideas, instead of subjecting them to lengthy approval processes.

I think that this makes sense on its own terms, and it’s the kind of change that a lot of people in the software development world are hoping for. But, I don’t know that it’ll be an easy sell to the people who run companies. I want to take a quick step back, analyze this take from a holistic standpoint, and try to figure out the risk/reward calculation that an organization faces when it strives for higher velocity. I think the basic question is just this: in the future, will organizations move at the pace of software development, or will software development move at the pace of organizations?

Either A New Golden Age, Or A Shaky Bronze One

Here are two potential futures for software development:

1. Maybe we’ll enter a new golden age of computing, where software engineering as a discipline becomes insanely productive, as everyone currently in the industry turns their attention to churning out features to improve the lives of a grateful public. Agent-driven coding results in apps that load faster, work on more devices, and never have weird edge-case bugs in their UI.
2. Or maybe, software production will cease to become a bottleneck for businesses in terms of time and costs, new features and capabilities will stop being a competitive advantage for businesses since competitors can copy them almost instantly; and so, organizations will stop investing in software engineering, treat it mainly as overhead, and aim to make their apps “just good enough.”

I can’t predict the future, so I don’t know if either of these worlds will come about. (If I could, I’d be telling you which BDCs to invest in.) But I’m both more worried about and more sympathetic to the second possibility than the people I see talking about this kind of thing online are.

There’s an eternal yen for velocity among technologists, partially because of the fear of being outcompeted by people or companies who move more quickly (like how Paul Graham’s startup Viaweb famously beat its competition by releasing features faster¹), and partially because it’s just so boring and frustrating when things take a long time to make (“babe, are you ok? it’s already q4 and you’ve barely touched your ‘2025 roadmap’”).

But I’m not sure that rational self-interest within businesses will make them value velocity; the risk-reward calculation seems less certain than that.

Stories You Told Me About The Future

1. I don’t think that many of the people who are enthusiastic about using agents to move faster right now are worrying enough about the human-level risk factors. New projects or approaches to a problem in an organization tend to take on a life of their own: they need to be evangelized and socialized throughout the org, they become a part of random people’s jobs, and you get new hires who can’t imagine doing things any other way. These are all things that can, despite how quickly software itself can move, slow down operations and make things hard to change in the future. I think this is the fundamental reason why, in my experience, people in leadership and executive roles tend to be very conservative about committing to new initiatives; they don’t want hasty decisions to reverberate throughout the rest of the organization.

2. Here’s a really dumb question: how many features do your users need? It isn’t super defensible to keep paying for people’s time and Claude Code’s tokens if there isn’t a straight line you can draw between the stuff getting shipped and customer satisfaction. The CEO of Uber recently made headlines when he articulated a newly ambivalent stance on their emphasis on the use of AI: “there’s more that is getting shipped, but it’s very hard to draw a line between one of those stats and ‘Okay now we’re actually producing like 25% more useful consumer features.’” You can spend more engineering time on just making apps better, and some companies will, but it’s been proven that customers will tolerate some pretty sketchy experiences if it gets them a cheaper product or a faster ride; if you don’t believe me, look at Amazon.com on a tablet.

3. However: I do think that in some competitive environments, shipping quickly will be a significant advantage. The reason why is probably tied to the point I found most interesting in Joe’s original post: shipping stuff lets you learn things. If you have a new company that does Uber for Plant Watering, which has an app that lets your customers hail someone to water their plant while they’re out on vacation, and you ship a new feature that allows them to schedule plant-waterings at different intervals based on how hot it is where they are, you might learn a lot about how many of your users’ plants are directly exposed to the weather, which might make you realize you can diversify into more services, like Uber for Moving People’s Plants Out of the Sun When It’s Really Hot. In an environment where AI agents implement features really quickly, your competitors can probably easily copy your features, but you can still gain information from the way that your users respond to them.

4. But again, this is risky, since an initiative to cater to users whose plants are way out in the middle of their yards might take on a life of its own within your company, with people whose careers are riding on it succeeding, even if there aren’t that many of that kind of customer. And in a lot of cases, you can probably, like, just send out a survey to find out how many people’s plants are in the middle of their yard.

Becoming Overhead

In general, this might lead to a landscape where software engineering is treated like overhead, kind of like legal work is now; where lawyers have contracts and terms of service, software engineers will have specs.

Individual engineers might become more interchangeable, even across organizations; as the space matures, alpha from using LLMs “better” will be thin on the ground. There will be less incentive to try to acquire and nurture new talent, except for maybe a few people at the top.

On Substack, Dan Davies has a true story about a bicycle factory that switched from assembling bikes by hand to a production line model. The hand-assembly process was very detail-oriented and required skilled workers, who were paid based on the amount of pieces they put together in a day, and “some of them got very good indeed at what they did… [most could do eight an hour, but] some of them could do thirty. According to people I interviewed at the factory, it was like watching a dancer, the speed they moved at, always picking the right component first time and moving tools from one hand to the other.” But in a production line system, “someone who works really fast is just piling up half-completed bicycles in front of the next station… The dancing martial arts masters’ human capital was gone – their specialised skills were adapted to a different system.”

And maybe this example will prove irrelevant to software development. We’re still early; code generation sucked a year ago; and it might turn out that all that really happens is that the yearly roadmap will start seeing some progress before the end of Q2.

But I do think that there’s a decent chance that software engineering ends up less valued, less invested-in, and less determinative of the pace that a business moves at, and all without even really meaningfully improving the experience of software for customers. This can happen while businesses are pursuing their rational self-interest, and despite the best intentions of the people who feel empowered by new coding technologies.

Footnotes

1. Paul Graham says that Viaweb released features faster than its competitors because at Viaweb, they were writing code in Lisp. I do not know if I believe this. To my knowledge, no one else has ever beat their competitors to market by using Lisp. But this general narrative, of a startup winning against a lot of big competitors primarily by outpacing them with releases, is the kind of thing that a lot of startups and individuals are constantly trying to achieve, especially right now with coding agents. ^