These days, application developers can take their pick from a vast menu of architectural solutions. We can choose from the well-understood to the experimental, and from blended solutions in between. Several powerful middle-ground technologies that emerged during the cloud revolution have really come of age. Here we’ll take a look at putting together three of the most impressive: GitHub, Vercel, and Firestore.

Each of these is an important tool in its own right that can be used to attack specific problems. In combination, they not only meet the needs of several important application scenarios, but they have a superpower—the ability to dramatically shorten the distance between development and deployment.

There is nothing quite as gratifying as putting your hands on just the right mix of tools for a given need.

A ‘no-ops’ stack built for speed

If your primary goal is sheer development velocity, you would be hard-pressed to top this architecture. This “no-ops” stack collapses the distance between your local IDE and a globally distributed production environment. You are essentially trading the overhead of managing VMs and load balancers for the sheer speed of committing code and watching it deploy automatically.

While each component is highly flexible, adopting them requires a specific, event-driven mindset. There are a few finicky bits to manage, mostly around routing environment variables securely and designing around stateless back-end functions. But the constraints are obvious and well-documented.

Before we look more closely, let’s quickly identify the kinds of apps that are a perfect fit here, along with those that are workable and those that really merit a different approach.

• The sweet spot (deploy and go): AI-mediated applications, asynchronous game back ends, and real-time collaborative B2B dashboards. This architecture perfectly absorbs the unpredictable latency of LLM APIs and instantly syncs state across multiple clients without requiring you to build custom WebSocket infrastructure.
• The middle ground (workable, with trade-offs): Headless e-commerce, moderate IoT telemetry, and apps requiring scheduled batch processing. You will encounter friction if your catalog relies on deeply relational SQL constraints, or if your background reporting jobs take longer than a few minutes and hit serverless execution limits.
• The danger zone (look elsewhere): High-frequency trading, fast-paced action multiplayer games, heavy data ETL pipelines, and core financial ledgers. Serverless architectures cannot natively hold open the persistent WebSockets required for twitch-reflex data, and heavy compute tasks will abruptly time out.

We should mention that these categories are not mutually exclusive. Many enterprise applications, such as a full-scale e-commerce platform, straddle these lines. You might use Vercel and Firestore to build a lightning-fast, reactive storefront that handles ephemeral user state like shopping carts, while simultaneously “stitching in” a managed SQL database like Supabase or PlanetScale. This hybrid approach allows you to maintain the relational integrity required for back-office inventory and financial ledgers and pair it with the front-end velocity this stack provides.

GitHub: the bedrock

I don’t need to introduce you to GitHub. It is a central element of the development landscape. I still remember CVS and SVN with a certain nostalgia, but the enhancements of Git speak for themselves. When combined with the orchestration powers of GitHub, it is no wonder that virtually the whole industry has adopted this type of platform.

Git plus GitHub gives you an enormous amount of power already, in terms of how you can organize and automate your projects. But there is a next-level experience in combining GitHub and Vercel. For JavaScript-based projects, you can take simple GitHub pushes and turn them into instantly deployed clients and serverless functions. It is one of the cleanest and least fiddly ways to move from raw code on your local machine to a globally deployed, full-stack architecture.

Vercel: the nexus

Vercel is more than just a deployment host. It is a control plane that ties this high-velocity, no-ops architecture together. Alongside GitHub and Firestore, Vercel’s deeper strength is its ability to act as an orchestration layer between your reactive front end and external stateful services.

Vercel has a great amount of facility in fine-tuning what branches go to what environment and helpful features like instant rollback. You can just log into Vercel’s dashboard for your project and see the history of deployments and any errors and logs. It’s a simple menu choice to roll back to a historical version or compare one version against another.

When you “stitch in” third-party services (such as a managed SQL database like Supabase or a payment processor like Stripe), Vercel’s serverless functions become the lightweight interface, and Vercel’s the adapters handle the communication. You offload the integration logic (the service layer) to Vercel’s global Edge Network, keeping your UI and back end clean, responsive, and decoupled. 

In short, Vercel allows you to get the speed of the “no-ops” development life cycle without sacrificing the complex transactional integrity required for some applications like enterprise inventory systems.

Firestore: the datastore

Firestore is an extremely lightweight, NoSQL, cloud datastore. It has a great deal of add-on power, but its core value proposition is that it accepts virtually any data you stuff into it and it provides event-driven subscriptions to data changes.

These two capabilities together make Firestore about as straightforward a solution to a managed back end as you can imagine. You subscribe to collections or even fields and then you simply stick “unstructured” data (read: JSON with variable fields) in and the client waits for the changes it is interested in.

This is so streamlined that one can just point the browser (or native mobile app) directly at Firestore and listen for events. Which immediately raises the question of identity, for auth and for data visibility, but hold on—Firestore’s third superpower is that it has an authentication module that actually works. What I mean is, it is actually pretty simple and yet confidently secures your app.

Sometimes auth solutions seem either too simple (and yet opaque) or too mired in the nitty gritty. Firestore auth will let you do some basic configuration and start using a reasonable auth almost immediately. 

Not to belabor the point, but having a realistic and attainable auth solution elevates your stack to a production grade—one that can handle many real-world applications. Firestore auth plays nicely with other important APIs, like Stripe. Typically, auth is a major feature that feels like off-roading in a Honda Civic, but Firestore’s approach to auth, added to this particular stack, feels like a normal speed bump. It’s just another component you plug in, rather than a tentacled alien you weave into the your code.

The limits of the velocity stack

This architecture combines components that are optimized for flexibility. That same character also introduces distinct limitations. Understanding these is essential before committing production workloads.

The serverless life cycle

Serverless functions are spun up to handle requests. They close out soon afterward and lose any state. For that reason, they cannot natively hold open persistent WebSockets. If your system requires continuous, sub-millisecond, bidirectional streams—like a real-time multiplayer action game or a high-frequency trading dashboard—pure serverless will fight you all the way. You are forced to introduce a third-party managed WebSocket service to route messages back to your stateless endpoints via HTTP webhooks.

The execution time ceiling

Vercel (like all serverless platforms) enforces strict timeouts on operations. While enterprise tiers might grant you up to 15 minutes, standard functions often time out after 10 to 60 seconds. Long-running tasks like video transcoding, database scripts, or orchestrating multi-step AI agent workflows, which might take 20 minutes to resolve, will run up against these limits. Heavy-lifting tasks must be offloaded to a dedicated, long-running service like Google Cloud Run, or broken into smaller, asynchronous chunks via message queues.

The cold start reality

While the industry has made massive strides in minimizing initialization times—particularly with lightweight edge networks—traditional Node.js-based serverless functions still experience cold starts. If a function has not been invoked recently, or if traffic spikes require a new instance to spin up concurrently, the first request will take a noticeable latency hit as the container provisions and the code loads.

API instead of RAM

In a traditional server environment, you can store transient data in global RAM, allowing subsequent requests to access shared context instantly. In the serverless model, every request might hit a fresh container. Therefore, all shared context must be externalized. Although Firestore serves brilliantly as the state manager, relying on a database for high-frequency, sub-millisecond, ephemeral caching introduces network latency and per-operation costs. That said, using a shared RAM state on a server is non-trivial also, unless you are using a single app server and VM (because high-availability or fail-over requirements will lessen the RAM win on a traditional server).

Tuning for velocity and control

Every architectural decision is a trade-off. There are no cost-free choices. By adopting the GitHub, Vercel, and Firestore stack, you are explicitly maximizing feature velocity over fine-grained control.

You lose the ability to tweak the underlying operating system, hold open persistent sockets, or run hour-long back-end scripts. In exchange, you gain an architecture that scales from zero to global distribution instantly, requires virtually no devops maintenance, and perfectly absorbs the asynchronous, event-driven realities of modern application development.

For the right application—whether it is a fast-moving prototype or an enterprise AI copilot—this stack doesn’t just save time; it fundamentally changes how quickly a small team (or a single person) can impact the market. You stop worrying about build chains, load balancers, and server patches, and you focus on the central mission: shipping features.

The first time I heard someone say their AI now wrote 80% of their tests, I asked the obvious question. Eighty percent of what?

After 20 years building and leading test automation for consumer-scale platforms, my honest answer turned out to be eighty percent of the typing, not eighty percent of the engineering. The remaining twenty was where the work still lived. Budgeting for two percent of leftover effort was the mistake. When the real number was closer to thirty, that gap was the difference between a pipeline that shipped and one that quietly built up a queue of half-trusted features nobody could rely on.

This piece is about that gap. As an independent research project on LLM-augmented testing methodology, I built a six-stage agentic pipeline that takes a design in Figma and produces running tests in WebDriverIO, connected end to end over the Model Context Protocol. It works. It has been useful. And the parts that broke surprised me, because they were not the parts the hype cycle tells you to worry about.

How I wired a six-stage pipeline over one protocol

The pipeline runs six stages in sequence, each owned by a different agent, with every handoff crossing MCP.

Six-stage agentic test pipeline: design capture → requirements writer → ticket opener → code generator → test-case writer → automation generator. Each stage carries an MCP handoff and a provenance stamp.

The end-to-end trace links a pull request back to a Jira ticket, a requirements section and a Figma frame. Each artifact is stamped with the agent that produced it, the model it used and the inputs it was given.

MCP is the boring middle that makes any of this work. The cliché is that MCP is “USB-C for AI”: one open protocol, any tool. Like most analogies, it is about eighty percent right. The part that matters is the eighty: I do not have to write a custom adapter for every system the agent talks to. One MCP server per tool and every agent talks to all of them the same way.

Typed handoffs between agents are my own architecture, layered on top of MCP rather than provided by it. Each agent writes a typed artifact the next agent reads. Each handoff is logged with provenance. When something went wrong six stages in, I could replay the chain. Without that discipline, a multi-agent pipeline is a debugger’s worst day. You know the test plan is wrong. You cannot tell whether the mistake came from the Figma read, the requirements interpretation or the ticket scaffolding. With it, I could point at exactly which stage went sideways and which inputs it was looking at when it did. The pattern lives in a public MIT-licensed reference implementation for any reader who wants to run it.

The sixteen-minute number is the marketing number. I ran the full chain end to end in about sixteen minutes on a synthetic net-new screen, Figma in, automation suite out. That repeated across my runs; it is not a demo trick. But sixteen minutes is the part of the story most fun to tell and least useful to learn from. It is what gets quoted in the all-hands. The hours that come after, when a human reviews each handoff, are where the work actually lives.

What actually broke in production-style runs

The failures that stalled my pipeline were rarely the ones I expected.

I expected hallucinated APIs. I got them: the agent confidently called endpoint names that sounded right but did not exist. I expected sparse-spec-in, sparse-spec-out, where a Figma frame with no annotations produced a requirements doc with vague acceptance criteria, every time. I expected locator drift, the common UI-automation failure mode where a renamed component silently breaks an entire test suite. There is solid outside writing on non-determinism in tests covering this whole family of failure modes, and the agent inherited every one.

What I did not expect, and what kept the pipeline down longer than any of the above, was the plumbing.

The model backend timed out under load. It lost credentials silently and started returning empty strings, which the agent then read as confidence. A duplicate consumer on a shared long-poll API endpoint produced an HTTP 409 conflict that broke delivery without throwing anything visible. One unguarded exception inside one agent aborted a whole shared scheduler run and took the other agents in the registry down with it. The single worst incident cost me three hours to find. An environment variable had silently rotated overnight; every agent in the fleet was returning structurally valid but semantically empty requirements docs; the downstream stages were dutifully generating tests against nothing.

None of those are model bugs. They are infrastructure. The agent literature, which is what I went looking through when I started this work, mostly does not talk about them.

The fix was not better prompts. It was circuit-breaker-style review checkpoints between stages and what I now call the four-guard discipline: four small guards I consider non-negotiable on any unattended agentic pipeline. The bulkhead pattern from microservices is the most consequential. An unhandled exception inside one agent can no longer abort the shared run; the offending agent fails fast with a structured error and the others keep going. Paired with that, a pure-data fallback ensures a model timeout produces a deterministic output explicitly marked as degraded mode, rather than an empty string the next stage will misread as confidence. A single-owner lease sits on every shared external endpoint, the cure for the duplicate-consumer incident that ate one of my Sunday afternoons. The cheapest guard was the last to arrive: a one-line synthetic canary every agent has to produce a known correct response to before any real work begins, so a credentials rotation or silent backend failure trips an alert before downstream stages have generated artifacts against garbage.

None of these guards is novel. They are textbook stability patterns at a new boundary: the seam between the LLM agent and the rest of the system, which most of the existing agent literature still treats as a solved problem.

The 20% you don’t see, and when not to do this

Here is the part the demo videos leave out. Even when the pipeline works, the human time per stage does not go to zero.

Human review time per ticket across five pipeline stages: code review 60-180 min, automation review and flaky-fix loop 30-90 min, ticket architecture and sequencing 30-60 min, test data and environment 15-30 min, requirements review 20-30 min. Net: the human still spends 20-30% of the original effort, almost all of it reviewing rather than creating.

Net of all that, the human still spends twenty to thirty percent of the original effort, almost all of it reviewing rather than creating. The pipeline saves seventy to eighty percent, not ninety-eight. The trap is budgeting for the two percent you do not save.

When does this kind of pipeline make sense? In my experience, when the Figma is richly annotated and acceptance criteria are clear up front; when there is review capacity to absorb the work the pipeline shifts onto humans; when the stack is well represented in the training data; and when the feature is net-new rather than a deep edit of legacy code. When does it not? When the design lives on a whiteboard. When the integration touches old code with hidden contracts. When the path is regulated or safety-critical. When there is no senior reviewer who can hold the line. When the work is exploratory and writing the spec is the actual point of the exercise.

Teams I have seen succeed with agentic pipelines budget for the rework explicitly, staff the review queue and treat the saved hours as capacity for harder problems rather than headcount they can release. Teams I have seen struggle did the opposite: declared victory at the demo and quietly accumulated a backlog of half-trusted features the next quarter had to clean up.

The right unit of measurement is not how much the pipeline generates. It is how much of what it generates a human still has to touch before you would ship it. Call it the 80/20 rework rule: measure the rework, not the generation. The teams that get the rework number right are the ones whose AI investments compound. The teams that stop counting at the headline percentage are the ones that own the cleanup six months later.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

When an HTTP request is too long or complex to be encoded in its URI using GET, developers have long resorted to using the POST method as a workaround. However, this can create issues; while GET requests are defined as safe and idempotent, POST does not necessarily share those characteristics.

To combat the problem, the Internet Engineering Task Force (IETF) has published a proposed standard HTTP request method, QUERY (RFC 10008), which bridges the two functions, taking the best of each.

A safe method is defined as one which is “essentially” read-only, where “the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server,” the IETF standards document states. And when a request is idempotent, no matter how many times it is retried, the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request.

POST requests do not always fulfill those criteria. But QUERY requests do. The input to the QUERY operation is, like POST, passed as the content of the request, rather than as part of the request URI as it is with GET. Unlike POST, QUERY allows functions such as caching and automatic retries to operate, precisely because it is safe and idempotent.

Read-only in disguise

“RFC 10008 matters because it gives the web’s favorite workaround a protocol identity,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. “Developers have disguised read-only questions as POST commands for two decades; QUERY carries the question in the request body while declaring it safe to retry and cache. The significance is machine-readable intent; retry engines, caches, and autonomous agents act on what a method declares, not on what documentation intends. Under automation, semantics become policy.”

“GET works while a request fits comfortably in a URI, and stops working the moment a developer needs deep filters, long identifier sets or an entire query document,” Gogia explained. “URIs also attract exposure through histories, bookmarks, and access logs, and encoding every input combination into the address quietly turns each permutation into a distinct resource.”

“POST solves the size problem and withholds the promise,” Gogia said. “Its generic semantics admit creation, mutation, and side effect, so no cache, retry engine, or gateway is entitled to assume that a given POST is repeatable or reusable.”

But while QUERY answers the long-running POST-for-search problem, the new method comes with some gotchas. As software engineer Rickvian Aldi noted in a blog post, “The cautious version is: it answers the semantics, not all the deployment work. Front-end code still needs stable query keys. Servers still need validation and cache-control headers. Infrastructure still needs to allow the new method.”

New standards take time

And that will take time; standards are often slow to be adopted. And before QUERY can be widely used, other standards such as the HTML forms standard need updating. That exercise is already in progress by groups such as the Web Hypertext Application Technology Working Group.

“Publishing an RFC as a Proposed Standard doesn’t mean the whole ecosystem supports it the next day,” said open source developer Daniele Teti in a blog post. “It’s the first rung of the IETF standards track: the specification is stable and ready for implementation, but it takes time for browsers, servers, proxies, CDNs, and client libraries to actually adopt it.” No major browsers support QUERY as yet, although, on the server side, Node.js and Go support the method.

Gogia pointed out that the authors of RFC 10008, engineers at Cloudflare, Akamai, and greenbytes, recognize this.

“The retreat route is designed into the standard itself,” Gogia said. “The Location bridge exists so that a QUERY can collapse back into a GET the moment it meets infrastructure that never learned, and the document says as much when it notes that clients can switch to GET for subsequent requests to simplify processing. Read that way, the equivalent resource is less a philosophical concession than a contingency plan, and it is the feature most likely to carry the method through its awkward years.”

For decades, software engineering has been plagued by “productivity theater.” Every few years, the industry aligns around a new vanity metric — usually one that latches onto whatever technology happens to be in vogue at the time. For a discipline rooted in creativity and problem-solving, this is a poor way to demonstrate progress. Yet, we find ourselves in this position once again. The pattern is often the same: reach for something we can easily count, and in doing so, lose sight of what we are actually trying to achieve.

Quantity over quality: the wrong measurement, every time

I recall when I was coming up as a software engineer in the 1990s, a small number of companies took up the practice of paying their engineers by each line of code. This may have been productivity theater at its worst, leading to negative incentives, inefficient processes, and just generally bad engineering. Developers were rewarded for writing far more code than the problems they were facing required — classic “quantity over quality” — and the result was bloated, brittle codebases that were all but impossible to maintain. The goal — to create reliable software that solved real user problems — got buried under the incentive to produce.

Then in the 2000s, the rise of Agile brought us story points, an abstract way to estimate task complexity, effort, and risk relative to other work. Rather than answering “How long will this take?,” story points were meant to answer, “How big is this compared to what we’ve done before?” This approach sounds good in theory, but in practice, some development teams learned to game the system by inflating estimates, over-engineering solutions to look productive, and losing sight of whether the work they produced actually created value. Once again, the metric became the goal, and the actual goal — delivering outcomes that mattered to the business — became secondary.

Every one of these metrics failed for the same reason: they measured effort instead of value.

Quantity in the age of AI

Today, “tokenmaxxing,” a trend in which developers and teams optimize for consuming as many AI model tokens as possible, treats raw consumption as an equivalent for output. As I see it, this is the latest flawed productivity metric to make its way into the world of software engineering. Tokenmaxxing is nothing more than another vanity metric, and is just as useless as using “lines of code” or inflated “story points” as a benchmark.

Tokenmaxxing is the result of a few different behaviors, including:

• Prompt flooding: stuffing massive codebases, documentation, and context into every prompt, burning tokens on context the model doesn’t actually need.
• Agent swarms: running multiple AI agents in parallel to maximize code output, regardless of whether the work is coordinated or coherent.
• Background loops: keeping AI sessions or agents running continuously in the background, racking up token spend without clear ownership of what is being produced — or why.

Now, it is no secret that AI is reshaping how software is developed, and these behaviors are the result of that reshaping. Providing AI with codebases, running multiple agents at once, and even relying on coding assistants for help all have their uses. But when we lose control of the changes we are making and why we are making them, we find ourselves facing a new version of the same old problem: measuring engineering productivity with the wrong metrics.

A more useful question to ask isn’t, “How many tokens did we spend?” but rather, “What problem did we actually solve, and for whom?”

Spending resources without goals

Yes, AI is giving software engineers the ability to do more with less, to move quickly, and to experiment in ways that were previously out of reach. But leaning on AI to perform productivity, rather than deliver it, is a trap that will cost us in code quality, team capability, and business credibility.

As a CTO, I am all for experimenting with AI. I want to use it to make our programs better, stronger, and future-proof. What I don’t want is for it to drive us toward excess while leaving us with little to show for it.

The test I keep coming back to is simple: does this AI-generated output help us ship something that matters? Does it reduce friction for a user, close a gap in a workflow, or improve reliability for a customer? If the answer isn’t clear, then we are spending resources — both human and computational — without a defined goal. And that is not engineering. That is activity.

Spec-driven development: where value gets defined

It is time to adopt newer approaches like spec-driven development, a method where engineers write detailed specifications first and AI generates code against them. Rather than relying on prompt flooding and agent swarms and hoping AI produces the best result, we need to shift toward defining requirements, reviewing AI-generated output, and orchestrating systems with intent.

But spec-driven development is more than a methodology. It is the place where engineering intent and business value get defined together. The spec is where you answer, “Why does this matter, and what problem are we solving?” before a single token gets spent.

Software engineers have long taken pride in writing elegant code, and I would hate to see AI cheapen that pride rather than elevate it. In an AI-first world, the craft shouldn’t disappear; it should simply move upstream. The spec is where elegance lives now, and it deserves the same attention to detail we once reserved for the code itself.

At its core, software engineering is about defining, analyzing, and resolving technical challenges. If we are willingly giving all of that up to AI, we will lose the integrity of our discipline and the ability to prove our value. Using the maximum number of tokens to produce code isn’t impressive. Using a well-crafted, intentional prompt to solve a specific problem? That’s the work worth celebrating.

Stop performing productivity and start delivering it

We are at an inflection point. Many organizations are defaulting to activity-based metrics, measuring how much AI is being used rather than whether it is improving delivery, product quality, or business outcomes.

The question worth asking is not, “How much AI did we use this sprint?” It is “What value did we deliver for our users, our team, or our business?” Was it the ability to resolve a critical bug more quickly? Reduced cycle time on a high-value feature? A customer workflow that now takes minutes instead of hours? Those are outcomes. Those are the things worth measuring.

AI can help us deliver meaningful outcomes faster, but only if we use it with the same rigor and intent we expect from every other engineering or business decision. Don’t let it become another form of productivity theater. The most successful engineering organizations in the age of AI won’t be the ones that consumed the most tokens, they’ll be the organizations that never lost sight of why they were building in the first place.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.