Summary: Coding agents have made writing code nearly free, so lines of code stop mattering. But the cost did not vanish, it moved to tokens, and that bill is climbing fast. The way to control it is an efficient data layer that uses open-source models freely and never reprocesses data it has already processed. There is also one thing an agent cannot vibe-code into existence: a correct, efficient, multimodal data layer. Storage, orchestration, serving, and materialization at runtime, especially for video and other media, are the parts that break in week two and force a rewrite when you finally hire a real engineer. The same way an Agent Harness wraps the LLM, a data infrastructure harness wraps your data. Pixeltable is that harness: it encodes hard-won best practices into a handful of declarative primitives so the code an agent writes is production-ready, and token-efficient, by default.
Code Is Cheap Now. Tokens Are Not.#
Something fundamental shifted with the latest generation of coding agents. You can describe a feature and watch 10,000 lines of code appear. You stop reading every diff, and you stop caring how many lines a change takes. The marginal cost of writing code has collapsed toward zero.
But the cost did not disappear. It moved. The same agentic tools that make lines of code free have made tokens the new line item, and that bill is climbing fast. Per-token prices have fallen roughly 98% since 2022, yet enterprise AI bills have tripled, because agentic workflows burn far more tokens per task. One industry analysis put per-developer token consumption up about 18.6x in nine months, and a single orchestrated agent run can cost roughly 30x what a simple 2023 API call did.
The numbers are not hypothetical. Uber reportedly burned through its entire 2026 AI coding budget by April. Microsoft pulled Claude Code licenses after engineers were each spending $500 to $2,000 a month on tokens. One developer torched $4,200 in a single weekend on a runaway refactoring loop, and one company ran up a reported $500M bill in a month after forgetting to set usage limits. This is exactly why so many companies now cap how much their developers can spend, route easy tasks to cheaper or open-source models, and watch per-seat token budgets like a hawk.
This inverts the old economics of software. Software used to be expensive to build and cheap to run; agent-built software is cheap to build and expensive to run. Frontier models like Claude and GPT are powerful but pricey, and there are only two real levers to collapse that cost: lean on open-source and smaller models wherever they are good enough, and stop wasting tokens reprocessing data you have already processed. Both are infrastructure decisions, not prompt decisions.
Meanwhile, the framework debate is over. When code was expensive, your choice of framework was a long-term bet. Now an agent can scaffold the same app in FastAPI, Next.js, or whatever you point it at, in minutes. The framework is no longer a competitive advantage because everyone has the same generation engine. Anyone can vibe-code a new SaaS in ten minutes.
So if the framework no longer differentiates you, and lines of code are free but every token costs real money, what actually matters? Two things: the experience you give your users, and whether your system keeps working, efficiently, as data, models, and requirements change underneath it. Both come down to the data layer.
What Coding Agents Can't Vibe-Code#
An agent will happily generate a script that calls an API, writes a row to Postgres, and uploads a file to S3. What it will not do, because it is not a coding problem but a distributed-systems and infrastructure problem, is architect a data layer that handles:
- Blob storage for raw media, with deduplication and references that stay consistent.
- A relational store for structured metadata, kept in sync with that media.
- Orchestration that knows what depends on what, and only recomputes what changed.
- Serving that exposes all of this as endpoints without hand-written glue.
- Materialization at runtime: turning a declaration of intent into actual stored, indexed, queryable results, incrementally, as data arrives.
This is the unglamorous machinery underneath every AI application. It is also where most of the real engineering lives. The reason an agent can't generate it reliably is that it isn't a localized function you can write in one pass. It is a set of architectural properties, storage, orchestration, and retrieval working as one system, that have to be designed in from the start. Bolt them on later and you are rewriting.
"But My Agent Can Just Stitch Services Together"#
Here is the obvious objection: the agent doesn't have to build the data layer, it can just wire up services that already exist. And that is true. A whole wave of tools now surfaces every capability as a clean API plus a CLI: a managed Postgres with auth and storage, serverless functions and instant deploys, memory-as-a-service, vector-search-as-a-service, ephemeral sandboxes to run untrusted code, even bots so your app can talk to users through Telegram or Slack. Each one is genuinely excellent, and, crucially, agent-friendly: a terminal command and a documented API are exactly what an agent needs for machine-to-machine setup, no console clicking required.
Every component of the workflow has become a service, and the vendors providing them are all racing to become the new AWS: a small set of composable macro-services an agent can assemble from a CLI and reason about on its own. This is great. It removes a mountain of undifferentiated setup, it is friendly to machine-to-machine orchestration, and it lets you move fast. We have written admiringly about exactly this pattern: what Vercel did for frontends, where deploying code infers the infrastructure, is the model everyone is now chasing. You can wire seven services together and be chatting with users through Telegram by the afternoon.
But stitching services does not remove the hard problem. It relocates and fragments it. Every capability you delegate is another boundary your data has to cross, another place where state can silently drift out of sync, and another integration your agent has to glue together, version, and keep consistent. You move fast, yes, but you are accumulating glue code, and tokens, faster, not less. The question is not whether your agent can assemble the macro-services in ten minutes. It can. The question is whether the result is a system that holds together at scale, or just more vibe code spread across more vendors, each with its own failure surface and bill.
And for the data plane specifically, there is no single clean service that hands you storage, orchestration, retrieval, and runtime materialization as one coherent thing that stays consistent under change. That is precisely where the stitched-together approach starts to crack, and it cracks hardest on the messiest data of all.
Why Video Is the Canary in the Data Mine#
Nowhere is this clearer than with video. Very few people actually wrangle media data directly, because it is genuinely difficult. Consider what it takes to make a single video "understandable" by a model:
- Decode the video and extract frames at a sensible rate, without exploding storage or compute.
- Detect the scenes and keyframes that actually carry information, instead of processing every redundant frame.
- Extract and transcribe the audio track, and align it with the visual timeline.
- Iterate on the right pattern to reduce the video down to the set of images, audio segments, and text that faithfully represents it.
- Compact and summarize all of that into a coherent description, and keep it efficient and scalable as the library grows.
Doing this well, at scale, is painful and close to impossible with the ad-hoc tools most teams reach for. This is the real bottleneck: not the intelligence of the model, but the data management around it.
This is exactly why you see the emergence of video-understanding APIs from the frontier labs. When a team like Google's Gemini group ships a video API, the convenience you experience, "pass a video, get an understanding", exists precisely because they have absorbed all of that wrangling on your behalf: the frame extraction, the keyframe detection, the scalable and efficient reduction of a video to a representation a model can reason over. The API is the visible tip of an enormous amount of invisible data engineering. Most developers never have to think about it, which is the point.
Pixeltable makes that same class of work easy in your own infrastructure. Frame and keyframe extraction, transcription, embedding, and summarization become a handful of declarative views and computed columns, with incremental updates and lineage handled for you. You get the lab-grade data plumbing without being a lab.
An API Call Is a Commodity. Your Pipeline Is the Moat.#
You can absolutely call a video-understanding API from Pixeltable in a single computed column, and sometimes that is exactly the right move:
But ask yourself what your competitive advantage actually is. If your entire product is one API call that anyone can make, you have no moat. The labs that own those APIs can replicate your feature on a slide. Your edge is the experience you build around the data: how you chunk, retrieve, combine modalities, ground answers in your own corpus, and let users iterate. That is your pipeline, and your pipeline lives or dies on the data layer underneath it. Owning that layer, rather than renting a single endpoint, is what compounds over time.
Week Two, and the Engineer You Finally Hire#
Here is how the cheap-code story usually plays out. You vibe-code a multimodal app in an afternoon. The demo is impressive, the first users arrive, and a few of them start paying. Then week two happens: adding a document re-embeds everything, a deleted file leaves zombie vectors behind, a rate limit at 3am crashes a 500-video job halfway through, and there is no way to roll back a change that made retrieval worse.
So you do the sensible thing and hire an engineer to make the codebase maintainable and scalable. They open the repo, look at the pile of generated glue scripts, and say what every engineer says: "What is this? I have to rewrite everything." Now you are spending even more tokens, your traffic is growing, your API and infra bills are climbing, and your new hire is rebuilding the foundation instead of shipping features. The maintenance tax, which is most of the real cost of software, lands all at once.
The trap isn't that the agent wrote bad code. It is that the agent optimized for time-to-first-demo, while production requires time-to-iterate. The code that wins one is hostile to the other, unless the hard parts were never the agent's job in the first place.
The Data Infrastructure Harness#
The industry already named the layer that wraps an LLM to make it operate reliably: the Agent Harness, which handles the loop, tool execution, context, and state. The data layer needs the same idea. Call it a data infrastructure harness: the layer that wraps your data so that storage, orchestration, serving, and retrieval of multimodal data are handled correctly and efficiently, no matter who, or what, is writing the application code on top.
Pixeltable is that harness. As maintainers of an open-source multimodal data library, we built it so that the best practices we learned the hard way, the things you only discover after wrangling media data at scale, are encoded directly into a small set of core primitives. You declare what you want; the runtime materializes the infrastructure. This is the same move Vercel made for frontends: your declaration is the spec, and the platform provisions accordingly.
- Tables and media columns manage blob storage and metadata as one consistent store.
- Views and iterators (document chunking, frame extraction, audio splitting) orchestrate media decomposition.
- Computed columns run your models on insert, with batching, rate limiting, caching, and retries built in, so you never pay twice for the same token.
- 25+ provider integrations mean you can route to open-source and local models (Ollama, llama.cpp, Mistral) or frontier APIs (Claude, GPT, Gemini) by changing one line, picking the cheapest model that is good enough for each column.
- Embedding indexes give you vector search that lives inside the table and stays in sync.
- FastAPIRouter turns those declarations into production endpoints with no hand-written glue.
Day One With Pixeltable#
Here is the video pipeline from above, but built as a data infrastructure harness rather than a single API call. It extracts frames, describes them with a vision model, and makes the whole thing searchable, and it is both the prototype and the production system:
Add a second video and only that video is processed. Delete one and its frames, descriptions, and index entries are cleaned up together. The agent writing this code did not have to know anything about distributed systems; it just used the right abstraction.
What You Get for Free#
Because the data infrastructure harness owns the hard parts, the same declarative definition gives you the properties that vibe-coded glue never provides:
- Incremental computation: only new or changed rows flow through the pipeline, so you never re-spend tokens reprocessing data that has not changed. You iterate on data, not infrastructure.
- Versioning and lineage: every change is tracked, every output traces back to its inputs, and you can revert or time-travel.
- Synchronized deletes: remove a source and its derived media, embeddings, and index entries vanish atomically. No zombie vectors.
- Error recovery and caching: failed API calls retry with backoff, and already-computed results are cached and never re-run. In a world where one runaway loop can cost thousands, not paying twice for the same token is a real line item.
- Schema-driven serving: the same schema that runs on your laptop runs in production, exposed via FastAPIRouter with no separate "production pipeline."
This is the difference between a tool and infrastructure, and who owns the multimodal data plane is the question that decides whether your app survives its own success.
Vibe-Code the App. Don't Vibe-Code the Data Layer.#
Coding agents are extraordinary at the application layer: your routes, your UI, your business logic, your prompts. Let them run there. But the data infrastructure underneath, the storage, orchestration, serving, and multimodal wrangling, is not something to regenerate from scratch with glue code. It is the part that breaks in week two and forces a rewrite when you scale.
Start on the harness from day one. When the code an agent writes is add_computed_column() instead of a 200-line ETL script, it is production-ready by default, because the abstraction made the right decisions on your behalf, including the ones that keep your token bill from spiraling: caching, incremental computation, and the freedom to route to open-source models. You ship as fast as any vibe-coded prototype, what you ship keeps working, and it does not bankrupt you in tokens as it scales.
pip install pixeltable
Ready to build on a data infrastructure harness? Start with the Quick Start, set up your AI coding tool for Pixeltable, explore the Pixelbot reference app, or browse more use cases. Everything is open source under Apache 2.0.
