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 on 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 always 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?

The Stories We Tell Each Other About The Future

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, everyone currently in the industry is empowered to continuously improve our software, and 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 ETFs 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.

Gotta Go Fast

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.

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 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, I think this could 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 reward talent, except for maybe a few people at the top.²

Or maybe none of this will happen. We’re still early; code generation sucked a year ago; and it might turn out that all that will really happen is that the average 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 could happen just from businesses pursuing their rational self-interest, and despite the best intentions of the people who feel empowered by our new coding technologies.

Postscript

I shared this post with Joe on Slack. Our conversation:

Joe Duncko: To respond to your article - I think what you might be getting at is that there are two kinds of organizations: organizations where technology is a cost center, and organizations where technology is their differentiator. The ones who view tech as a cost center are already moving development overseas. The ones that view tech as a differentiator will embrace it in a way that makes their engineers and businesses more efficient. There probably will be less of a middle ground like there is today.

Mitch J: i agree that tech can be a differentiator - i just don’t know if the stuff that claude code or codex can do can be a differentiator, since everyone has access to it and best practices for using it can probably be trained into it. maybe it’ll turn out that best practices won’t be that easy to automate and a lot of human judgement will still be required to use it, i don’t know.

and efficiency is good for people on the consumption side of a good, but it usually comes from squeezing people on the production side, lol

Joe Duncko: Just because it isn’t hard doesn’t mean it’s not a differentiator.

Mitch J: i do see what you mean there - if choices around whether and how to invest in coding allows a business to appeal to a different market than its competitors, it can be a useful thing even if investing in coding isn’t “hard” and doesn’t require as much human talent.

There probably is room for some places to chase the “new golden age of software development” dream while others go the “coding is overhead” route. We’ll see how that balances out.

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. ^

2. 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.” ^