Prompt Wars Attempt 2 – From AI Demo to Real System

#ai #programming #api #learning

In my first attempt at Prompt Wars, I built a working AI solution.
It was functional. It responded correctly. But it didn’t feel like a real system.
That was the biggest lesson.
So for my second attempt, I changed my approach completely.
The system combines deterministic decision logic with AI reasoning, ensuring reliable outputs without hallucination.

The Shift in Thinking
Instead of asking: “How do I build this feature?”
I started asking: “How would this work in a real production system?”
That one change made everything different.

What I Built
I created an enhanced version of:
Smart Stadium AI Assistant
The goal:
• Reduce crowd congestion
• Help users navigate efficiently
• Provide real-time intelligent suggestions
But this time, the focus was not just output…
It was decision-making.

Core Architecture
I designed the system with clear layers:
User Input
→ Context Builder
→ Real-time Data (Firebase pattern)
→ Historical Data (BigQuery pattern)
→ Decision Engine
→ Vertex AI (reasoning)
→ Final Response
Each component has a role.
This made the system structured and scalable.

Tech Stack

Frontend
HTML5, CSS3 (Glassmorphism UI)
Vanilla JavaScript (no heavy frameworks)
Custom SVG for stadium visualization

Backend
Node.js
Express.js

AI & Decision Layer
Rule-based Decision Engine (custom logic)
Vertex AI (intent classification + reasoning)

Data & Simulation
Firebase (simulated real-time crowd data)
BigQuery (simulated historical analytics)

Deployment
Google Cloud Run (containerized Node.js service)
Google Cloud Build (image build & deployment)

Key Improvements Over Attempt 1

Decision Engine (Game Changer)
Instead of directly generating responses, I added a decision layer.
• Rule-based logic (shortest vs least crowded)
• Priority handling (normal vs high congestion)
• Fallback logic for edge cases
This ensured:
The system decides first, then responds
Real-time + Historical Intelligence
I simulated Google Cloud patterns:
• Firebase → live crowd data
• BigQuery → historical trends
• Vertex AI → reasoning
Now decisions are based on:
current situation + past patterns
Smarter Responses
Responses are no longer generic.
Example:
Recommended: Food Stall 2 (East Gate)
Crowd: Low (12%)
Reason: Nearby stall has 78% congestion
Alternative: Food Stall 1 (closer but high wait time)
This adds:
• clarity
• trust
• intelligence
Edge Case Handling
Real systems don’t break under pressure.
So I handled:
• Extreme crowd spikes (>85%)
• Empty stadium scenarios
• Invalid user inputs
The system adapts instead of failing.
Clean & Modular Code
Instead of one big file, I structured it as:
/engine → logic (context, decision, simulation)
/services → integrations (Firebase, BigQuery, Vertex AI)
/routes → API handling
/public → frontend
This improves:
• readability
• maintainability
• scalability

Deployment
I deployed the application using Google Cloud Run.
Why Cloud Run?
• Stateless architecture
• Auto-scaling
• Simple deployment
This made the system closer to a real-world setup.

Live App:https://smart-stadium-ai-986344078772.asia-south1.run.app/

Biggest Learning
My first version was:
“An AI that answers questions”
This version became:
“A system that makes decisions”
That is a huge difference.

What Could Be Better
• UI can be improved (more realistic map experience)
• More real integrations instead of simulated patterns
• Better performance optimization
But the foundation is now strong.

Final Thoughts
If you are building AI projects, don’t stop at:
• generating responses
• connecting APIs
Focus on:
How decisions are made
That’s what separates:
• demos
from
• real systems

Thanks for reading
If you have suggestions or feedback, feel free to share.
Always learning, always building