From React UI to Full Backend: How I Built an Inventory Management System with AI Agents

Building a production-grade system has traditionally meant long cycles of frontend design, backend scaffolding, API contracts, and business rule enforcement. But with the right AI tools, much of this work can now be automated.

In this post, I’ll share how I used Google AI Studio and OpenAI Codex Agent to go from a React UI for an Inventory Management System (IMS) to a complete Java + Spring Boot + MySQL backend — with domain modeling, DTOs, business logic, and even cross-tenant data sharing.

🔧 The Tools That Made It Happen

1. Google AI Studio

• Rapidly prototyped and iterated on the IMS frontend.
• Centralized all API calls into services/api.ts so the backend contract was crystal clear.

1. OpenAI Codex Agent

• Analyzed the repo, ran the UI, and mapped APIs from services/api.ts.
• Combined this with a Software Business Logic Spec I provided.
• Generated backend code (entities, services, controllers, Flyway migrations).

🛠️ Structuring for Success

Two deliberate choices set the stage:

• Centralized API layer (services/api.ts) I instructed my frontend team to put all API calls in one file. This meant Codex Agent had a single source of truth for UI–backend interaction. No scattered code, no ambiguity.
• Business Logic Specification Alongside the repo, I prepared a document describing rules like:
• SKUs must be unique.
• Stock cannot move if insufficient quantity exists.
• Pools cannot be deleted if stock remains.
• Transactions must be atomic and auditable.

This gave Codex Agent both the contract and the rules.

🤖 Round 1 with Codex Agent

I ran Codex Agent with my prompt:

You are a senior full-stack architect and backend engineer.  
You have access to a repository that contains a complete React-based Inventory Management System (IMS).  

Your tasks are:  

1. **Run the React UI** locally (`npm install` then `npm start`).  
   - Observe how the UI behaves.  
   - Capture all API calls (from `services/api.ts`).  
   - Identify the expected inputs, outputs, and workflows.  

2. **Reverse-engineer the business logic**:  
   - For each API (Pools, Locations, Items, Stock Lots, Transactions, Permissions, Users, Roles),  
     document the **business rules, constraints, and workflows**.  
   - Build the **domain model** showing relationships (e.g., Locations -> Stock etc.).  

3. **Generate backend code** in **Java + Spring Boot + MySQL**:  
   - Create entities, repositories, services, and controllers matching the frontend contract.  
   - Implement business logic (e.g., unique SKU, stock checks, transactional stock movements).  
   - Implement audit trail via `stock_movements` table.  
   - Provide **Flyway migrations** for schema setup.  

4. **Output deliverables**:  
   - API specification (OpenAPI/Swagger).  
   - Business logic & domain modeling document (Markdown).  
   - Complete Spring Boot backend project (Maven).  

Constraints:  
- Use **Spring Boot 3.x**, **Java 17+**, **JPA/Hibernate**.  
- Database: **MySQL** with **Flyway migrations**.  
- REST endpoints under `/api/v1/*`.  
- Controllers must align with frontend API calls (`services/api.ts`).  
- Services must enforce validations and transactional logic.  

Goal:  
Deliver a **production-ready backend implementation** that the IMS React frontend can use without modification.

The result?

• DTOs that matched the frontend.
• Business logic enforcing my rules.
• Repositories and controllers aligned with api.ts.

But… the code was rudimentary. It didn’t fit neatly into my existing backend framework.

🔄 Round 2 — Teaching the Framework

To fix this, I gave Codex Agent more context: I integrated a data-sharing framework to allow tenants to securely share stock reports.

• My framework outline: class and method definitions, no implementations.
• An example class already implemented using the framework.
• A strict instruction:

Use the data-sharing framework style as a guide -- use {{DomainEntity using framework}} as your reference point.  
Follow its class structure and method signatures.  
Do not alter the business logic — only adapt it to the framework conventions.

This worked brilliantly. Codex Agent regenerated the code, but this time it:

• Matched my architecture.
• Respected my framework’s abstractions.
• Preserved all the business logic.

Now, instead of code I had to refactor, I had production-ready components that dropped into my system seamlessly.

⚠️ Lessons Learned

While Codex Agent did a lot of heavy lifting, it wasn’t perfect:

• The generated business logic was only ~70–80% accurate.
• Some bugs and logical gaps crept in (for example, corner cases in stock movement validation).
• The spec wasn’t always followed exactly — Codex interpreted rules loosely in places.

This meant that while the essence of the logic was correct, I still had to review, refine, and fix the code.

💡 Takeaway: Codex Agent is a great accelerator, but not a substitute for careful engineering oversight.

📦 The Final Deliverables

By combining Google AI Studio + Codex Agent + framework adaptation, I had:

• React UI with all APIs in services/api.ts.
• DTOs perfectly aligned with the frontend.
• Business logic services: stock checks, SKU uniqueness, audit trails, transaction safety.
• Flyway migrations: schema for items, pools, locations, stock snapshots, stock movements.
• Controllers matching the frontend contract.
• Multi-tenant data sharing APIs for stock reports.

All in a fraction of the time a traditional approach would take.

⚡ Why This Matters

Traditionally, building such a system would involve weeks of:

• Requirement workshops
• API contract writing
• Manual scaffolding
• Endless backend–frontend sync

With this workflow:

• Google AI Studio → prototype UI quickly.
• Codex Agent + api.ts → infer contracts automatically.
• Business Logic Spec → enforce real-world rules.
• Framework examples → generate code in the right style.
• Data-sharing framework → enable advanced features like multi-tenant reporting.

I went from a frontend-only repo → full-stack IMS application in days, not months.

✅ Final Thoughts

AI didn’t replace me as a developer — it accelerated me.

By giving Codex Agent the right context (APIs, business logic, framework), I transformed it from a code generator into a system builder.

This experiment shows that UI-driven + Spec-driven + Framework-guided backend generation isn’t just possible — it’s practical.

Would you try this workflow for your next project?

✍️ If you enjoyed this experiment, follow me for more real-world stories about AI-powered development.