{"slug": "from-prompt-to-production-building-a-serverless-cloud-pipeline-with-google", "title": "From Prompt to Production: Building a Serverless Cloud Pipeline with Google Antigravity", "summary": "A developer used Google Antigravity, an AI coding agent, to build and deploy a serverless event-driven document pipeline on Google Cloud, wiring Cloud Storage notifications through Pub/Sub to a Python Flask service on Cloud Run that streams metadata into BigQuery. The agent handled most of the code generation, but the developer reports that the highest-value moments came from pausing to make design decisions, such as choosing push subscriptions, BigQuery streaming inserts, and HTTP 500 versus 200/204 failure handling, surfaced through the agent's pre-code questioning step. OCR in the pipeline is simulated, with plain text files getting real word counts and tags while PDFs and images receive synthetic results.", "body_md": "If you've watched an AI coding agent build a to-do app in two minutes, you've probably asked yourself the obvious next question: *sure, it can make a demo, but can it ship something real?*\n\nTo find out, I gave **Google Antigravity** a real cloud job: build an event-driven document pipeline on Google Cloud, deploy it, and prove it works. It did most of the typing. But the most important moments were the ones where I had to stop and think, and that's the trade-off this post is about.\n\nThis post accompanies my DevFest Onitsha 2026 talk, and follows the official [Build and Deploy to Google Cloud with Antigravity](https://codelabs.developers.google.com/build-and-deploy-gcp-with-antigravity) codelab.\n\nHere is the link to the Demo on Youtube. [Watch Demo](https://youtu.be/B0KYFPdOMIQ)\n\nBy the end of this article, you will be able to:\n\n`/grill-me` and the Implementation Plan to catch mistakes before any code exists\n**Worth knowing:** billing is on for this project. Use a dedicated project, so cleaning up later is as simple as deleting it.\n\nGo to [Google Cloud Console](https://console.cloud.google.com/), Sign in/Sign Up, Then open up the cloud console.\n\nThe idea is simple: **upload a file, get searchable metadata in BigQuery.** No server sits around waiting. Work happens only when an event arrives.\n\n```\n  [ You upload a file ]\n           │\n           ▼\n  ┌──────────────────┐\n  │  Cloud Storage   │  1. Ingest: the file lands in a bucket\n  └────────┬─────────┘\n           │  bucket notification (new file)\n           ▼\n  ┌──────────────────┐\n  │     Pub/Sub      │  2. Trigger: the event becomes a message\n  └────────┬─────────┘\n           │  push subscription\n           ▼\n  ┌──────────────────┐\n  │    Cloud Run     │  3. Process: Python reads the file,\n  │  (Flask service) │     extracts tags and word count\n  └────────┬─────────┘\n           │  streaming insert\n           ▼\n  ┌──────────────────┐\n  │     BigQuery     │  4. Store: one row per document, ready for SQL\n  └──────────────────┘\n```\n\nThink of Pub/Sub as the messenger. It says, \"A new file just arrived. Somebody deal with it,\" and Cloud Run is the somebody.\n\n**Note:** in this build, OCR is **simulated**. Plain text files get real word counts and tags. PDFs and images get synthetic results. That keeps the focus on the pipeline itself, and I'll show where real AI fits in section 6.\n\nCreate a new project in Antigravity and add an empty folder, such as `google-cloud-serverless-app`. \n\nBefore typing a single prompt, open the project settings and set:\n\nThat second setting is the important one. The agent can write code and run terminal commands against a real cloud project, so we want it to show its work and wait for approval.\n\nHere's the prompt from the codelab. Notice it doesn't say *\"build me a cool app.\"* It names each part of the architecture and the exact fields to store.\n\n```\n/grill-me\n\nI want to build a serverless event-driven document processing pipeline on Google Cloud.\nArchitecture:\n- Ingestion: Users upload files to a Cloud Storage bucket.\n- Trigger: File uploads trigger a Pub/Sub message.\n- Processor: A Python-based Cloud Run service receives the message, processes the file (simulated OCR), and extracts metadata.\n- Storage: Stream the metadata (filename, date, tags, word_count) into a BigQuery dataset.\n```\n\n`/grill-me` tells the agent to ask questions before it writes any code, and it suggests an answer for each one. These were the decisions that shaped my build:\n\n| Decision | What I chose | \n|---|---|\n| How events reach Cloud Run | Cloud Storage notification → Pub/Sub → push subscription | \n| Framework | Flask with Gunicorn | \n| Storage | BigQuery streaming inserts | \n| Failure handling | HTTP 500 for temporary errors, 200 or 204 for permanent ones | \n| Endpoint access | Public, unauthenticated ( **prototype only** ) | \n\nThe failure-handling answer is the one I'd frame and hang on the wall:\n\n```\nSomething went wrong while processing a message\n        │\n        ├── Temporary? (BigQuery hiccup, network blip)\n        │        └── ❌ return 500 → Pub/Sub retries\n        │\n        └── Permanent? (the file no longer exists)\n                 └── ✅ return 200/204 → stop retrying\n```\n\nWithout the second branch, one bad message keeps coming back forever. That's called a **poison pill**, and it's easy to miss on a first draft.\n\n**Worth knowing:** I chose a public endpoint because it's quick to test. Keep that in mind, because we'll come back to it.\n\nAfter the questions, Antigravity produces an **Implementation Plan** artifact, and no code exists yet. Read it. Check the project ID, region and resource names, and comment directly on anything that's wrong. \n\nThink of it as reviewing a design doc before the first commit: it's the cheapest moment to fix a mistake.\n\nWhen it looks right, click **Proceed**.\n\nThe agent now writes the application and its deployment scripts. Every so often it pauses to ask permission for a terminal command. Read each one before you approve it, because this is where you stay in control.\n\nYour file names may differ, but you should end up with something like this:\n\nBefore anything touches the cloud, the agent generates and runs a local test suite with mocks, including a simulated upload, a missing file and a temporary BigQuery failure. In my run, 11 tests passed.\n\n```\npytest tests/ -v\n```\n\n**Note:** passing tests with mocks proves the logic works in isolation. It doesn't prove the pipeline works on Google Cloud. That comes next.\n\nConfirm gcloud is pointing at the right project, then give the agent the shortest prompt of the whole build:\n\n```\nDeploy the application for me\n```\n\nBefore deployment, Antigravity will generate a Deployment Plan Artifiact.\n\nThe deployment comes down to two variables and two layers:\n\nDeployment is handled across two layers:  and \n\n`Variables:`\n\n`GCP_PROJECT` and `GCP_REGION`.\n`Layers:`\n\n`Dockerfile (Root Directory)` Container Packaging (for building the Cloud Run image).`terraform/ Directory` Terraform Infrastructure as Code (for provisioning and wiring all Google Cloud resources).\nThat's the whole architecture from section 1, wired together.\n\nWhen the deployment finishes, Antigravity gives you a **Walkthrough** artifact: what it built, where it lives and the live BigQuery output from the test run. That's useful, but my rule is simple: *trust, but verify.*\n\nCheck out these useful commands for uploading to cloud storage and querying BigQuery.\n\nUpload a file of your own: Here, I added a pdf file to my project folder and uploaded the pdf file (NeedsWants_Worksheet.pdf) to cloud storage\n\nI also asked Antigravity to create and upload a demo file:\n\n**Note:** use the bucket, dataset and table names from your own Walkthrough. The agent may name them differently on each run.\n\nIf a new row appears, voila! A file went in, an event fired, a container woke up and a row came out. Check the status column too: plain text files should show real extracted text, while PDFs take the simulated OCR path.\n\nThen do a quick tour of the console:\n\nA BigQuery query proves the pipeline works, but nobody wants to open a terminal every time they check their documents. So I gave the agent one more task: a simple frontend to view the output.\n\nI used the prompt suggested in the codelab:\n\n```\nCreate a Flask web application that connects to BigQuery. It should display a table of the processed documents (filename, upload_date, tags, word_count) and allow me to filter the results by tag\n```\n\nThe same loop applied: the agent asked a few questions, produced a plan, and I reviewed it before any code was written. A few minutes later, I had a page listing every processed document, with a tag filter at the top.\n\nThis is where the pipeline starts to feel like a product. Upload a file to the bucket, refresh the page, and a new row appears, with no SQL needed.\n\n**Worth knowing:** the frontend reads from BigQuery, so it needs permission to query your dataset. Use your own credentials while testing locally, and give it a dedicated service account with read-only access if you deploy it.\n\n**Note:** if you deploy the frontend, don't make it public by default. It shows every document's metadata, so the authentication advice in the next section applies here too.\n\nLet me be honest about the word in the title. We reached a **production environment**, but this isn't **production-ready** yet. Before real users touch it, here's what I'd change, in order:\n\nThe nice part is that every one of these can start the same way the pipeline did. For example:\n\n```\nHarden this pipeline. Require authentication on the Cloud Run service and configure\nthe Pub/Sub push subscription to use an authenticated service account. Add a\ndead-letter topic for messages that fail 5 delivery attempts. Show me the\nimplementation plan first.\n```\n\nDescribe it, review the plan, then verify the result.\n\nFrom there, the codelab suggests more ideas: lifecycle rules that move old files to cheaper storage, and Eventarc for richer event routing.\n\n**Worth knowing:** when you're done experimenting, clean up. If you used a dedicated project, deleting it is the simplest way to stop all charges.\n\nSo, can an AI agent ship something real? Yes. But look at what made the difference: the prompt was the smallest part. The real work was describing the system clearly, setting guardrails, reviewing the plan, questioning the security choice and verifying the result yourself.\n\n**AI can write the code. Engineering judgment is still your job.**\n\nIf you want a next step, try the smallest possible version: run the [codelab](https://codelabs.developers.google.com/build-and-deploy-gcp-with-antigravity), upload one file of your own and watch the row appear. Then pick one item from section 6 and build it with the same describe, review, verify loop.\n\nWhat would you add to this pipeline first: real Gemini processing, a dashboard or a dead-letter queue? Let me know in the comments.\n\n*I'm Caleb Duff, a GDG Cloud Organizer. I share more on cloud and AI on YouTube at [Techie From The Future](https://www.youtube.com/@calebdduff). You can also find me on [LinkedIn](https://www.linkedin.com/in/duffcaleb/) and on X as @duffygoogle.*", "url": "https://wpnews.pro/news/from-prompt-to-production-building-a-serverless-cloud-pipeline-with-google", "canonical_source": "https://dev.to/gdg/from-prompt-to-production-building-a-serverless-cloud-pipeline-with-google-antigravity-264l", "published_at": "2026-11-13 12:39:27+00:00", "updated_at": "2026-11-13 12:51:38.849190+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "ai-infrastructure"], "entities": ["Google Antigravity", "Google Cloud", "Cloud Run", "BigQuery", "Pub/Sub", "Cloud Storage", "Flask", "DevFest Onitsha"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/from-prompt-to-production-building-a-serverless-cloud-pipeline-with-google", "markdown": "https://wpnews.pro/news/from-prompt-to-production-building-a-serverless-cloud-pipeline-with-google.md", "text": "https://wpnews.pro/news/from-prompt-to-production-building-a-serverless-cloud-pipeline-with-google.txt", "jsonld": "https://wpnews.pro/news/from-prompt-to-production-building-a-serverless-cloud-pipeline-with-google.jsonld"}}