AWS, Vercel, and Amdahl's Law

A developer argues that generative AI has made build-deploy speed far more important, shifting the AWS-Vercel tradeoff in favor of Vercel, citing Amdahl's Law. The author notes that while both stacks remain viable, the indirect effect of AI on the development loop increases the relative benefit of faster deployment, though the post is a personal perspective rather than a comprehensive comparison.

Many applications can be built and deployed with either a Vercel-based stack or an AWS-based one. Here's a rough view of some tradeoffs: This is nowhere close to a complete comparison of AWS and Vercel, and I'm sure many people would argue with some of those claims. It's even a bit of a category mistake to frame a comparison as "AWS vs. Vercel:" they do different things, and you can call AWS from a Vercel-governed project perfectly well.<sup 2 fn-2 </sup For present purposes, it's less important that I'm right and more important that I take the situation to be: Rightly or wrongly, I have taken the AWS-Vercel decision to rest primarily on a tradeoff between better build-deploy speed and other benefits. The importance of build-deploy speed, however, has gone way up for me, because of Amdahl's Law https://en.wikipedia.org/wiki/Amdahl%27s law : generative AI has made everything else I do so much faster that the speeding up the build-deploy part of the development loop has much greater maximum benefit. This is, I think, a nice example of how generative AI, in completely restructuring the development loop, affects programmers' lives in both direct and indirect ways. I haven't much changed my opinion of either tool, but I'm now much more eager to be using Vercel. Some further notes: ...and even if you don't, if you're like almost any AWS user I've ever seen. ↩ fnref-1 I'm also using "Vercel" to mean something like "Vercel and the add-ons it makes very easy to use." So, in particular, I tend to think of Neon-as-used-through-Vercel as part of Vercel proper. ↩ fnref-2 Of the many, many caveats I'd like to discuss here, I only have time for a few. First, "good-enough" is how I think about the build and deployment performance; I think that the performance of S3, DDB, and certain other core AWS services as much, much better than good enough. Second, when I say that costs are reasonable, I mean reasonable from the perspective of the 2026 market; I am old enough that the cost of most AWS services seems comically low. Third, when I say you can do things through the CLI in reasonable ways, I don't mean that the APIs are a model of brilliant API design but rather that, in an AI-first world, you can consistently get the results you need with the CLI. ↩ fnref-3 This is separate from the main cost-of-coffee effect I discuss there, which has to do with the structure of work and the fact that it's so much easier to do make meaningful engineering progress in the, say, 10 minutes you'd spend at leisure. ↩ fnref-4 Not exactly for Hawthorne's reasons, but that's another post. ↩ fnref-5