An $800 Build Bill and the Hidden Decisions in AI Coding

I had a great month of AI-assisted coding and shipped several products, but a Vercel bill of about $800 after two weeks surprised me. I was building Journey Kits, and my coding assistant recommended Vercel for deployment. I had focused on shipping quickly and did not stop to examine the services, configuration or costs.

My first issue was the build machine. I found the project using Turbo, a high-resource option, even though my small project did not need it. Vercel documented Turbo and on-demand concurrent builds as defaults for new Pro projects at that time; settings vary by plan and may change, so the experience should not be generalized to every account.

The screen shows Turbo at $0.126 per build minute and Elastic starting at $0.0035 per CPU minute. These measure different units: an Elastic build can use multiple CPUs, so the latter is not necessarily its total price per elapsed minute. These are the figures shown in April 2026, not a current quote. Vercel later [announced a Turbo price reduction](https://vercel.com/changelog/reduced-pricing-for-turbo-build-machines), with rollout beginning April 27.

I was also deploying dozens of times a day, sometimes starting another build while a previous one was still running. Those overlapping or duplicate builds consumed resources. I disabled on-demand concurrent builds for the project so builds would queue, and I could wait or cancel a superseded build. Charging depends on plan, machine and concurrency settings, so the same change will not produce identical savings for everyone.

I should have checked these settings, but I was moving quickly and following my AI coder’s recommendations. I also had not asked why builds took minutes. After I posted about the bill, Theo and other people suggested looking at the build process itself. A billed build that runs for more time can increase cost, so optimizing duration matters alongside the selected rate.

I report that the changes brought my ongoing charges down from hundreds of dollars a week to a few dollars, with further room for improvement. The deployment list shows earlier builds taking more than three minutes and later examples around a minute, including one under a minute. Those are observations from this project, not a guaranteed outcome or a controlled breakdown of each change.

A suggestion was to use GitHub hooks for the build and Vercel for deployment, which I say I also adopted. The clip does not fully specify the resulting pipeline or prove which individual change caused each saving. Moving work to another service can shift costs and still requires appropriate checks and deployment controls.

I remain a fan of Vercel. A support representative suggested opening a ticket, and at the time I had not yet done so; I hoped a refund might be possible, while recognizing that I had not checked the settings. The lesson I take from the bill is to slow down enough to understand configuration and tradeoffs.

The video is sponsored by Recall. I discuss its knowledge-base and context tools, including search, media references, API and MCP integration. Those are sponsor claims presented in the video, not independent tests of the product; the promotional discount mentioned there was time-limited.

More broadly, I see a change in AI coding after Claude Opus 4.5 arrived in late 2025: coding agents made it possible for me to build products in days that might previously have taken months. I cite other developers who describe writing or reviewing less code manually. These are observations about particular workflows, not evidence that every developer or team works that way.

The same speed changes how I choose dependencies. My agent frequently recommends services such as Vercel, Resend, Fly.io and Railway, and I often accept the suggestion without checking plans or configuration. That leaves questions about reliability, fit, support and the risk of relying on a provider unanswered. My personal projects are relatively low stakes; production services may need much closer evaluation.

I describe generative-engine optimization as making a service discoverable in AI-generated recommendations. A Resend founder’s post reports crossing two million users after reaching one million four months earlier. The post does not establish that AI recommendations alone caused the growth, although I think being recommended by coding agents can help a service reach more builders.

The opportunity is that more people can create software and build more quickly. The tension is that we can also delegate decisions while understanding less of the implementation. I point to a social-media count of features shipped by AI companies in early April 2026 as an illustration of pace; it uses the poster’s selected categories and is not a comprehensive productivity comparison.

I worry that reviewing every line becomes difficult as generated code grows. I call it physically impossible, but that is my assessment of scale rather than a universal proof: teams can combine targeted human review, automated checks, tests and other controls. Even natural-language specifications can be long, and the deployed behavior does not always match what I thought I requested.

In my experience, coding products increasingly make conversation and the resulting product more prominent than source code. I compare older editor-centered workflows, autocomplete and chat with newer Cursor, Codex and Claude Code interfaces. This is a design interpretation of the interfaces shown in 2026; code and changes can still be opened and reviewed.

The Cursor example places chats in the main view and can show the resulting product in a browser. In the Codex example, changed files and added or deleted line counts appear in the conversation, with the code accessible by opening the changes. I like seeing the product, but the extra step can make it easier to overlook what was implemented.

Some people compare the shift to earlier layers of abstraction: developers moved from low-level instructions toward more readable languages, and now can describe a goal in natural language. My concern is that an imprecise request or explanation may differ from the behavior actually delivered. Code has formal syntax and execution rules, but programs can still contain defects or unexpected behavior.

Models are improving at coding and interpreting intentions, and I expect more workflows where AI writes and reviews much of the code. That does not mean a natural-language summary automatically proves correctness or that all frontier teams never read code. The practical issue is whether someone can verify the behavior, dependencies and consequences of what is shipped.

Human-readable languages such as Python and Ruby make software easier for people to work with than raw machine instructions. I speculate that future AI systems might use representations better suited to machines than to people, with an AI explanation translating the result back into natural language. That is a possible future, not an established direction or proof that humans could not inspect it.

That scenario worries me because the explanation might be incomplete or inaccurate. Returning to my bill, I think fundamentals still matter: understand why a service was chosen, what its configuration means and which design tradeoffs it introduces. People building production systems should invest in understanding and verifying them.

If you are new to building with AI, learning the basics can help you make those decisions. I am shipping more and enjoying it, but I also feel uneasy when I know a product mostly works without fully understanding it. That tension is what the surprise bill made concrete for me.