The Problem with “I Have an App Idea”

In consulting, we generate more app ideas in a single client engagement than most teams ship in a quarter. A portal for tracking Oracle module adoption. A self-serve tool for candidates to monitor their recruiting pipeline. A dashboard that maps ERP configuration decisions to delivery risk. The ideas are cheap. Building them used to be expensive.

That’s changed. The vibe-coding movement — using AI tools to generate functional app code from natural language — has collapsed the gap between “I have an idea” and “here’s a working prototype.” But it only works if you have the other two pieces in place: somewhere to store your data, and a way to get it live. This guide covers all three, with a direct link to the hands-on article for each step.

Step 1 — Vibe Code the App

You describe what you want. The AI builds it. That’s the premise — and in practice, it holds up better than it should. I’ve used it to build a full Oracle recruiting management app with candidate tracking, job posting management, and an application pipeline. The key insight is that you’re not just prompting a chatbot — you’re prompting a system that understands UI components, data models, and API patterns simultaneously.

Several tools can handle this step. I’ve tested a few, and the experience differs meaningfully depending on what you’re building:

The output of this step is a GitHub repository. Your AI-generated app, committed, pushed, and ready for Steps 2 and 3. If you’re using a tool that generates code locally (Claude Code, Claude Cowork), you push the repo yourself. If you’re using a cloud-based tool (Bob, Antigravity), the export-to-GitHub path is usually one button.

Step 2 — Create Your Supabase Database

Your app needs somewhere to store data. Supabase gives you a PostgreSQL database, a REST API, and an auth layer in under 10 minutes — for free. The visual table editor means you don’t need to write SQL to create your schema. The auto-generated REST API means your AI-built frontend can start reading and writing data with no backend code required.

The output of this step is three environment variables: your Project URL, your anon key, and your service_role key. You’ll need all three in Step 3.

Step 3 — Deploy on Vercel

Connect your GitHub repo to Vercel, paste in your Supabase environment variables, and hit Deploy. Vercel detects your framework, runs the build, and serves the app from a global CDN with HTTPS. First deployment: under 90 seconds. Every subsequent push to main: automatic redeploy. Every pull request: a preview URL.

This is the step that turns your vibe-coded prototype into something you can actually share with a client, a stakeholder, or a hiring team. A real URL. A real domain if you want it. No server management, no SSL configuration, no deploy scripts.

The Full Stack, in One View

What This Changes in Practice

I’ve been in enough discovery workshops to know that half the client asks that get logged as “future requirements” never make it to a backlog because the perceived cost of building them is too high. The 3-step stack changes that calculus. When a consultant can prototype and deploy a working version of a proposed solution in a morning — before the proposal is even written — the conversation shifts from “can we build this?” to “is this what you had in mind?”

That’s not a marginal productivity gain. That’s a different way of doing consulting.

Resources: Step 1: Vibe Coding with IBM Bob · Step 2: Supabase Database Setup · Step 3: Deploy on Vercel · Supabase · Vercel

Christian Guidibi
Oracle Cloud Practice Lead & AI & Futuristic Technology Consultant

Christian leads Oracle Cloud implementations and AI-enabled delivery in a consulting context. He writes about the intersection of enterprise architecture, modern AI tooling, and practical delivery at guidibi.com.

LinkedIn
guidibi.com

The post Vibe Code & Deploy Your App in 3 Simple Steps appeared first on Guidibi.com.

Why Vercel — and Why It’s the Right Last Step

Deploying an app used to mean configuring a server, setting up NGINX, managing SSL certificates, and writing a deploy script. Vercel eliminates all of that. It connects directly to your GitHub repo, detects your framework automatically (Next.js, React, Vue, plain HTML — it handles them all), builds the app, and serves it from a global CDN with HTTPS by default. Every push to your main branch redeploys automatically. Every pull request gets its own preview URL.

For a vibe-coded app, this matters for one specific reason: the AI generated the code, you pushed it to GitHub, and now you want it live without becoming a DevOps engineer. Vercel is exactly that bridge.

Step 1 — Connect Your GitHub Repository

Go to vercel.com and sign in with GitHub. From the dashboard, click Add New → Project. Vercel will list your GitHub repositories — select the one containing your app. If the repo is in a GitHub organization, you may need to grant Vercel access to it first via the GitHub OAuth screen that appears.

Vercel scans the repo and detects the framework. For a Next.js app it will auto-configure the build command (next build) and output directory. For a plain React app (Create React App), it detects that too. If your app is something more custom, you can override the build command and output directory manually in this screen.

Step 2 — Set Your Environment Variables

Before you hit Deploy, scroll down to Environment Variables. This is where your Supabase credentials live — never in your source code, always in environment variables. Add the following three variables exactly as they appear in your Supabase Project Settings → API panel:

Set each variable for all three environments: Production, Preview, and Development. That way your preview deployments (from pull requests) and your local vercel dev environment all use the same Supabase instance. If you have a separate staging database, you can scope variables per environment here too.

Step 3 — Deploy and Verify

Hit Deploy. Vercel will clone your repo, install dependencies, run the build command, and push the output to its CDN. The first deploy typically takes 60–90 seconds for a small app. When it finishes, you get a live URL in the format your-project-name.vercel.app.

Open the URL and verify three things: the app loads, data from Supabase is being fetched correctly (check your browser’s Network tab for successful API calls), and the environment variables are being picked up (if there’s a login screen or a data-dependent view, test it). If anything is broken, Vercel’s deployment logs are accessible immediately from the dashboard — they show the exact build output and runtime errors.

Step 4 — Add a Custom Domain (Optional but Recommended)

The vercel.app URL works, but if you’re showing this to a client or a hiring team, a proper domain reads better. Go to Project Settings → Domains, add your domain, and follow the DNS instructions — typically a CNAME record pointing to cname.vercel-dns.com. Vercel handles SSL certificate provisioning automatically. The whole process takes under 5 minutes once DNS propagates.

What Was Built

• Vercel Project — GitHub repo connected, framework auto-detected, build pipeline configured in 2 minutes
• Environment Variables — 3 Supabase credentials set across Production, Preview, and Development environments
• Live Deployment — App live at *.vercel.app with HTTPS and global CDN, first deploy under 90 seconds
• Continuous Deployment — Every push to main triggers an automatic redeploy; every PR gets a preview URL

3 Things That Changed How I Think About Deployment

1. Preview URLs are a hidden productivity multiplier. Every pull request getting its own live URL means you can share a working version for review before anything merges. For consulting deliverables, that’s a game changer — a client can test the PR before it’s “done.”
2. Environment variables in the UI beat .env files. No more worrying about accidentally committing secrets. Vercel’s variable management is a first-class feature, not an afterthought, and the per-environment scoping is genuinely well-designed.
3. The build log is your first debugging tool. If a deploy fails, Vercel’s logs are detailed enough to diagnose 90% of issues without needing to reproduce locally. For vibe-coded apps where you didn’t write every line yourself, this matters — you can debug what you didn’t build.

Three steps. One AI to build the app, one database to store the data, one platform to serve it. What used to be a multi-day sprint — spec the app, write the backend, configure a server, set up CI/CD — is now a morning’s work. That’s not a productivity hack. That’s a structural change in what a solo consultant or a small team can ship.

Resources: Vercel Documentation · Environment Variables Guide · Deployments Overview · Part 2: Supabase Database Setup · Part 1: Vibe Coding with Bob

Christian Guidibi
Oracle Cloud Practice Lead & AI & Futuristic Technology Consultant

Christian leads Oracle Cloud implementations and AI-enabled delivery in a consulting context. He writes about the intersection of enterprise architecture, modern AI tooling, and practical delivery at guidibi.com.

LinkedIn
guidibi.com

The post How to Deploy Your Vibe-Coded App on Vercel in 10 Minutes appeared first on Guidibi.com.

Why Supabase — and Why It Fits Vibe Coding Perfectly

When you vibe-code an app, you’re moving fast — the goal is to have something functional in hours, not days. The last thing you want is to stop and hand-write SQL migrations, configure a connection pool, or set up a separate auth service. Supabase solves all of that out of the box. Under the hood it’s PostgreSQL — real, battle-tested, relational — but the surface is a web console where you click to create tables, and an auto-generated REST API that your AI-built frontend can call immediately with no backend code.

I chose it for the Oracle recruiting app I built in Part 1 specifically because the AI-generated frontend was already making standard REST calls. Supabase meant I never had to write or deploy a custom API layer. The database and the API were the same thing.

Step 1 — Create Your Supabase Project

Go to supabase.com and sign in with GitHub. From the dashboard, hit New Project. You’ll name it, choose a region (pick the one closest to where your app will be deployed — this matters for latency), and set a database password. Save that password somewhere — you’ll need it when you connect from Vercel in Part 3.

The project spins up in about 60 seconds. Supabase is provisioning a real PostgreSQL instance, a PostgREST API layer, and a storage bucket in the background. When the dashboard goes green, you have a live database.

Step 2 — Design Your Schema in the Table Editor

Supabase has a visual table editor — no SQL required to get started. Navigate to Table Editor → New Table. For the recruiting app, I created three tables: candidates, job_postings, and applications. Each table gets an auto-generated id (UUID) and created_at timestamp by default — Supabase handles that for you.

For each table, I added columns using the UI: name, type (text, integer, boolean, timestamptz), and whether the field is nullable. Foreign keys — like linking applications.candidate_id to candidates.id — can be added visually in the same screen. If you already have a schema in mind from your AI-generated app, you can also paste raw SQL into the SQL Editor and run it directly. Both paths work.

Step 3 — Lock Down Access with Row Level Security

By default, Supabase tables are locked — no public access. That’s the right default. For a vibe-coded internal app, the fastest path is to enable Row Level Security (RLS) and create a permissive policy that allows reads and writes from authenticated users. Navigate to Authentication → Policies, select your table, and add a policy. For rapid prototyping I use “Enable read access for all users” first, then tighten it once the app is working.

If your app doesn’t use Supabase Auth and is just calling the REST API with a service role key (common in vibe-coded internal tools), you can bypass RLS using the service_role key. Just never expose that key on the frontend — it goes in your server environment variables, which we’ll cover in the Vercel article.

Step 4 — Get Your API Keys and Connection String

Everything you need to connect your app lives in Project Settings → API. You’ll find three things there: the Project URL (your REST API endpoint), the anon public key (safe to use on the frontend), and the service_role key (server-side only, never expose this). Copy these — they are your environment variables in Part 3.

If you need a direct PostgreSQL connection (for something like Prisma or a data migration script), go to Project Settings → Database → Connection String and grab the URI. Use the pooler connection string for serverless environments like Vercel — it handles connection limits properly.

What Was Built

• Supabase Project — PostgreSQL instance provisioned in under 2 minutes, EU-West region
• Schema — 3 tables (candidates, job_postings, applications) with foreign key relationships, built visually
• RLS Policy — Row Level Security enabled with a service-role bypass for the internal app layer
• API Credentials — Project URL, anon key, and service_role key ready for Vercel environment variables

3 Things That Surprised Me

1. The auto-generated REST API is immediate. The moment I created a table, Supabase exposed a REST endpoint for it — no code, no restart, no deploy. My AI-generated frontend was reading and writing data within 5 minutes of schema creation.
2. RLS is on by default, and that’s the right call. I expected to have to configure security. Instead, I had to deliberately open access. That inversion — secure by default — is the right posture for anything that might accidentally end up public.
3. The free tier is actually generous. 500MB database, 1GB file storage, 50MB file uploads, unlimited API requests. For a vibe-coded prototype or internal tool, you won’t hit the ceiling before deciding if the app is worth scaling.

Supabase removed the last friction point that used to make “just spin up a quick database” a 2-hour detour. In a vibe-coding workflow, that matters — the whole point is to stay in flow from idea to working app. Your database is ready. Next up: deploying the app itself on Vercel.

Resources: Supabase Documentation · Table Editor Guide · Row Level Security · Part 1: Vibe Coding with Bob

Christian Guidibi
Oracle Cloud Practice Lead & AI & Futuristic Technology Consultant

Christian leads Oracle Cloud implementations and AI-enabled delivery in a consulting context. He writes about the intersection of enterprise architecture, modern AI tooling, and practical delivery at guidibi.com.

LinkedIn
guidibi.com

The post How to Create a Supabase Database for Your Vibe-Coded App appeared first on Guidibi.com.

The Problem I Kept Running Into

Every Oracle Cloud engagement has the same friction point: you know the data is in there, you know the REST API exists, but actually getting to it — authenticating, constructing the right URL, handling the response, making an edit — requires too many steps for what should be a 30-second task. Postman collections help, but they’re not shareable as a tool. Fusion UI gets you there eventually, but it’s not built for the diagnostic workflows a consultant actually runs. I wanted something purpose-built: a single interface that handles OAuth, knows the endpoint catalog, and lets you read and write Oracle Cloud data without ceremony.

One Prompt, One Direction

The build started with a specification prompt — not a wireframe, not a backlog, not a requirements document. A single, structured prompt that described exactly what I needed across four dimensions: core features, Oracle Cloud modules to support, technical requirements, and expected deliverables. I’ve pasted it verbatim below because I think the quality of this prompt is the most instructive thing in this entire post.

“I want to build a comprehensive Oracle Cloud API Assistant web application with the following requirements: [OAuth 2.0 authentication with client credentials flow, support for multiple Oracle Cloud instance profiles, AES-256 encrypted storage, auto token refresh] … [Dynamic data table — auto-generate columns from API JSON responses, handle all data types, sortable columns, global search, pagination] … [Inline editing — click-to-edit cells, track changes with visual indicators, batch editing support, submit changes via PATCH requests, auto-save edits to survive page refresh] … Please build this step-by-step, starting with project setup, then authentication, API client, data table, and finally editing features.”

What made this prompt work wasn’t length — it was structure. Four clearly delineated sections, each answering a different question: what does it do, what Oracle modules does it touch, what’s the tech stack, and what counts as done. That last part — the explicit deliverables list — is what kept the build from drifting. When you’re working across 13 development phases over two weeks, the specification is your anchor.

The Architecture Decision That Changed Everything

The most consequential decision in this build wasn’t a framework choice — it was the decision to use no backend at all. Every credential, token, and edit session is stored in the browser’s LocalStorage, encrypted with AES-256. No Node.js API server. No database. No hosting infrastructure beyond static file delivery.

For a single-user consulting tool, this is the right call. The security model is sound: AES-256 encryption means the data at rest is protected even if the browser storage is somehow accessed. The operational model is simpler: there’s nothing to maintain, nothing to patch, nothing to go down. And the deployment model collapses to a single command — push a static build to Netlify, Vercel, or GitHub Pages and you’re live in under 30 minutes. Total infrastructure cost: zero.

The tradeoff is real: this architecture doesn’t scale to multi-user or collaborative scenarios. If you need audit logging, conflict resolution, or shared sessions, you need a backend. But for a practitioner tool built to accelerate individual Oracle Cloud work, the tradeoff is clearly worth it. Ship something in 30 minutes that works, rather than spend three weeks standing up infrastructure for a tool three people will use.

Building in 13 Phases Over 10–12 Days

The build followed a clean dependency order: TypeScript type definitions before services, services before components, components before styling. This sounds obvious, but it’s the part that most rapid builds skip — and skipping it is why rapid builds turn into 6-week projects. When you define your data shapes first, everything downstream writes itself.

Days 1–2 covered the foundation: project setup with Vite, TypeScript interfaces for every data structure in the app (credentials, tokens, endpoints, table columns, edit sessions), and the encrypted storage service. Day 2–3 added the OAuth 2.0 authentication service and the Axios-based HTTP client with interceptors for token injection and auto-refresh. By end of day 3, I could authenticate against an Oracle Cloud instance and make API calls.

The endpoint registry took a full day on its own — and it was worth it. Mapping 47 endpoints across Financials, SCM, HCM, and CX forced a level of precision about Oracle Cloud’s API surface that I hadn’t needed before. Every endpoint has a category, a method, a URL pattern, a parameter definition, and a display name. That registry is what powers the dropdown selector in the UI — it’s not hardcoded strings, it’s a structured catalog.

The data table component (days 7–9, 8–12 hours) was the most complex single piece. TanStack Table v8 handles the core — sorting, filtering, pagination — but the auto-column generation logic, inline editing with change tracking, and edit session persistence required real design work. The result is a table that takes any Oracle Cloud API response, generates appropriate columns automatically based on the JSON types, and lets you click any cell to edit it, with changes tracked visually and auto-saved to survive a page refresh.

Deployment: 30 Minutes, Zero Dollars

Because the app is a pure static build, deployment is a solved problem. A single npm run build produces a deployable dist/ folder. Push it to Netlify or Vercel with one CLI command and it’s live with HTTPS, automatic CDN distribution, and a custom domain if needed. GitHub Pages works too, with a small Vite base path configuration. For teams that need it containerized, a two-stage Docker build with Nginx serves the same output behind a corporate proxy or on-premise.

The one non-negotiable on deployment: HTTPS. The app handles OAuth tokens, and serving it over HTTP — even on a local network — is not acceptable. All three recommended platforms enforce HTTPS by default. If you’re self-hosting, make sure your Nginx or Apache configuration has a valid certificate before you hand credentials to this tool.

What Was Built

• OAuth 2.0 Authentication Service — Client credentials flow with auto token refresh, AES-256 encrypted credential storage, and support for multiple Oracle Cloud instance profiles (dev/test/prod switching)
• 47-Endpoint API Registry — Structured catalog covering Financials/ERP (15 endpoints), SCM (4), HCM (6), CX/Sales (7), and supporting modules — each with method, URL pattern, parameter definitions, and display metadata
• Dynamic Data Table — Auto-column generation from any Oracle Cloud API JSON response, with sortable columns, global search, configurable pagination (10/25/50/100 rows), and type-aware cell rendering
• Inline Editing Engine — Click-to-edit with visual change tracking, batch PATCH submission, discard option, and LocalStorage-based session persistence to survive page refresh
• Zero-Infrastructure Deployment — Static build deployable to Netlify, Vercel, GitHub Pages, or Docker in under 30 minutes at zero ongoing cost
• 2,843 Lines of Documentation — User guide, architecture reference, API endpoint documentation, quickstart guide, and implementation guide

5 Things That Surprised Me

1. The specification prompt is the architecture document. I’ve always believed that good requirements drive good delivery. But this build made the relationship viscerally clear: the precision of that initial prompt determined 80% of the outcome quality. Ambiguity in the spec created the only real rework. This has direct implications for how I write SOWs and functional specs on Oracle engagements.
2. AES-256 LocalStorage is a legitimate security model — in the right context. I went into this expecting to need a backend for anything involving OAuth credentials. I was wrong. For a single-user practitioner tool, encrypted LocalStorage is not a workaround — it’s the right architecture. The constraint is scope, not security.
3. 47 endpoints forced me to actually understand Oracle’s module boundaries. I’ve implemented Fusion across ERP, SCM, HCM, and CX. But mapping the REST API surface made me confront where the module seams actually are in ways that UI-layer work never does. The endpoint catalog is now a reference artifact I use outside this tool.
4. TanStack Table v8 is the only serious choice for dynamic Oracle data. Headless architecture means I control every pixel. TypeScript-native means the type inference from Oracle’s response schemas works without ceremony. And the performance on 100-row payloads with sorting and filtering active is noticeably better than the table libraries I’d used before.
5. 10–12 days is now the honest benchmark for a full-featured internal tool. This used to be a 3-month project with a 2-person team. The constraint has shifted from engineering capacity to specification quality. That changes how I scope and price practitioner tooling in consulting engagements.

What I’m taking into the next build is the discipline of the specification prompt — not just for AI-assisted development, but as a template for how I brief any technical delivery. The teams that will benefit most from this kind of tooling aren’t the ones with the most engineering resources. They’re the ones with the clearest articulation of what they need.

Christian Guidibi
Oracle Cloud Practice Lead & AI & Futuristic Technology Consultant

Christian leads Oracle Cloud implementations and AI-enabled delivery in a consulting context. He writes about the intersection of enterprise architecture, modern AI tooling, and practical delivery at guidibi.com.

LinkedInguidibi.com

The post I Built an Oracle Cloud API Client in 10 Days — Starting With One Prompt appeared first on Guidibi.com.

TL;DR: I built a production-ready recruiting application — React frontend, FastAPI backend, Oracle 23AI database, Docker — in under 3 hours. Solo. No spec. No mockups. Just conversation with an AI coding assistant called IBM Bob. This is an honest account of how it happened and what it actually means for the way we deliver.

Before You Start — Get Access to IBM Bob

Everything in this article was built with IBM watsonx Code Assistant, referred to as “Bob” throughout. Go to bob.ibm.com/trial, sign up for a free trial, download the desktop app (think standalone IDE, similar to VS Code), and authenticate via the browser token flow on first launch. You’re coding in under 5 minutes.

The Starting Point: One Prompt, No Brief

I work across multiple recruiting teams and had been stitching together data from three different tools to get a coherent view of my pipeline. I wanted something centralized — a single place where I could track candidates, positions, applications, and interviews without toggling between systems.

So I opened IBM Bob and typed this:

“Act as a senior Solution Architect specialized in HR and Recruiting systems. I want to build a Recruiting App following the best practices of recruiting and the standard recruiting business process. Use SQLite or Oracle 23AI database.”

No ticket. No spec. No mockup. That single sentence kicked off a 3-hour session that turned a vague internal need into a deployable enterprise tool. What follows is what actually happened — the good, the surprising, and the parts worth knowing before you try this yourself.

How the Session Actually Unfolded

The stack Bob chose was enterprise-grade from the start: React 18 frontend, FastAPI backend, Oracle 23AI as the database, Redis for caching, Docker Compose for the infrastructure. Not a toy — something that could actually run in a consulting environment. I didn’t specify any of that. It inferred it from the prompt.

Phase 1 — Architecture Before Code (15 min)

Bob’s first response wasn’t code. It was an architectural proposal.

Before writing a single line, it laid out the complete system design: the stack (React 18, FastAPI, Oracle 23AI, Redis, Docker Compose), the core data model (four entities — Candidates, Positions, Applications, Interviews — with their relationships and key fields), and the project folder structure and module boundaries.

None of this was in the prompt. Bob inferred enterprise-grade choices from three words: “best practices” and “recruiting.” It made the Oracle 23AI call over SQLite on its own, judging it the right fit for a system that would need relational integrity, scalable querying, and production-grade data handling. That’s the first shift in your mental model: the AI doesn’t just write code to spec — it makes architectural decisions and can defend them.

Phase 2 — Core Build (30 min)

With the architecture confirmed, Bob generated the foundational codebase in a single pass.

Database schema: Oracle 23AI DDL for all four entities, with foreign key constraints, indexes, and proper field typing. Backend: a running FastAPI application with initial CRUD endpoints, Pydantic models, and Docker configuration. Frontend: React scaffolding with routing, core views, and API integration wired up.

At the end of 30 minutes, the application was running. Not a prototype — a functional, navigable app with real data flowing end to end. The consistency was immediate: naming conventions, error handling patterns, and response structures were uniform across every layer from the first commit.

Phase 3 — Feature Expansion by Example (45 min)

I said: “I need to be able to edit Positions, Applications, and Interviews.” No field list, no UI spec. Bob looked at the existing candidate edit pattern and replicated it across the three other entities — same state logic, same error handling, same UI structure. One request, four consistent implementations.

This is the core mechanic of vibe coding: show the AI one working pattern and say “do this for X, Y, Z.” The translation is automatic, and the consistency is better than what you’d get coordinating a team.

Phase 4 — CSV and Data Integrity (35 min)

Two quick requests. First: “I don’t see CSV export and import.” Bob checked whether the backend endpoints existed (they did), then wired up the frontend buttons, download logic, upload handling, error states, and success notifications. Done.

Second: I noticed the interview form used free text for candidate selection. My ask was roughly: “That field should be a dropdown linked to the actual candidate list.” Bob converted it to a controlled dropdown, added dynamic loading from the API, formatted each option with linked application and position data, and disabled the field during edits to prevent orphaned records. I didn’t specify any of those implementation details. It inferred the data integrity concern and addressed it completely.

Phase 5 — The Interview Form (60 min)

The most demanding phase. I shared a structured French interview template — 5 sections, 37 Oracle module options, 4 competency dimensions scored 0–10, bilingual labels — and said “implement this.”

Bob generated the complete form in a single pass. Proper validation, create vs. edit modes, full French label structure, all 37 module options mapped correctly. What stood out wasn’t the code generation — it was the cross-domain comprehension. Bob held React state logic, FastAPI conventions, Oracle module taxonomy, and French business terminology in context simultaneously. That’s not autocomplete. That’s a different category of tool.

Phase 6 — Documentation & Git (30 min)

Final ask: document it and push it. Bob produced a 434-line build and deployment guide, initialized the repo, generated a proper .gitignore, committed 114 files with a meaningful message, and pushed to GitHub. DevOps handled as fluently as the application code.

The Honest Comparison

The 2–3 week estimate isn’t inflated. In a consulting context, requirements gathering alone is typically 2–3 days. Add design reviews, development cycles, integration testing, and UAT rounds — you’re looking at weeks for what we delivered in an afternoon. The Oracle Recruiting Application is an internal tool. Speed and adaptability were the right tradeoff. For a regulated client engagement with contractual specs, the calculus is different.

What Was Delivered

A working recruiting application: dashboard with real-time KPIs, candidate grid with CSV import/export and CV parsing, position management with status and priority tracking, a 7-stage Kanban pipeline, and a structured interview module with 37 Oracle-specific competency options. All backed by 32 API endpoints on Oracle 23AI, 114 files under version control, 11,600+ lines of code, and a Docker Compose stack that starts in 30 seconds.

5 Things That Actually Surprised Me

1. Vague prompts work — but precise context matters more. The opening prompt was intentionally loose. What made the session productive wasn’t precision in the ask — it was precision in the feedback loop. When something wasn’t right, I described the gap clearly. The AI handled the translation to code.

2. Cross-domain fluency is the real differentiator. IBM Bob held React, FastAPI, Oracle SQL, Docker, and French business terminology in context at the same time. That simultaneous fluency across domains is what separates modern AI coding assistants from search and autocomplete.

3. Consistency is free. When I asked for edit functionality across three entities, Bob applied the identical pattern — same state logic, same error handling, same UI structure — without being told to. In a team, that requires style guides, code reviews, and coordination. With AI, it just happens.

4. You still need to own the judgment calls. I let Bob handle syntax, API design, and database queries. I personally validated business logic, data integrity rules, and anything with security implications. That division isn’t optional — it’s what makes the output trustworthy.

5. The productivity claim is real, but bounded. Three hours for an internal tool on a stack I understand. That number doesn’t transfer to a regulated client environment, a legacy integration, or a system requiring formal verification. Know the envelope before you sell it.

Conclusion

Three hours. One developer. One AI. A production-ready recruiting application on Oracle 23AI, deployed via Docker, documented, and pushed to GitHub.

Vibe coding isn’t a shortcut — it’s a different mode of working. Requirements emerge through conversation. Iteration is immediate. Documentation is generated. The consultant’s job shifts from writing code to directing outcomes and validating what comes back.

For Oracle Cloud practitioners, the implication is clear: the skills that will matter aren’t deep familiarity with syntax. They’re the ability to frame problems precisely, validate AI output rigorously, and understand enough architecture to know when the AI is wrong. That’s a different kind of expertise — and it’s worth building now.

Appendix: Development Timeline

Resources: Oracle 23AI Free · FastAPI · React · GitHub Repository

Christian Guidibi
Oracle Cloud Practice Lead · AI & Enterprise Technology Consultant

Christian leads Oracle Cloud implementations and AI-assisted delivery in a consulting context. He writes about the intersection of enterprise architecture, modern AI tooling, and practical delivery at guidibi.com.

The post Vibe Coding with IBM Bob: Building a Full-Stack Oracle Recruiting App in 3 Hours appeared first on Guidibi.com.