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.