AI-Assisted Payment Detail

Overview

I wanted to explore what a modern AI-assisted development workflow could look like when building a real product feature, not just generating isolated pieces of code.

For WorkTrak, I evolved the payment experience from a simple TimeEntry.status = paid model into a proper Payment Batch workflow with its own lifecycle, history, detail view, and audit trail.

The interesting part was not only what I built, but how I built it with AI.

The Problem

The original payment model treated individual time entries as paid or unpaid. That made it difficult to answer basic questions:

• What exactly was included in a payment?
• Which entries belonged to the same payment?
• What was the payment state?
• What hours were actually paid?
• What happened if a completed payment needed to be changed or reversed?

I introduced PaymentBatch as a first-class business entity so a payment could preserve its own identity, included work entries, payment date, status, and payable-hour information.

I Did Not Start With Code

Before asking an AI coding agent to implement the feature, I used ChatGPT as a product and engineering thinking partner.

Together, we explored:

• Payment lifecycle models
• Draft versus Paid states
• Reopen versus Revert behavior
• Audit requirements
• Payment Detail information hierarchy
• Business rules
• API and domain architecture
• Implementation phases
• QA strategy

The work was intentionally broken into smaller phases instead of asking AI to build the entire feature in one pass.

Product Decisions First

One of the most important decisions was making the payment lifecycle explicit:

Draft -> Paid -> Reopened -> Paid

with Reverted as a terminal outcome.

That lifecycle became the foundation for the UI. Different states expose different actions:

Draft

• Edit
• Delete
• Complete Payment

Paid

• Reopen
• Revert

Reopened

• Edit
• Complete Review
• Cancel Review

Reverted

• Read-only

This meant the interface reflected the business rules instead of simply exposing a collection of buttons.

Designing the Payment Detail

The Payment Detail page became the central place to understand and manage a payment.

It surfaces:

• Employee
• Payment date
• Payment status
• Total hours worked
• Total hours to pay
• Included work entries
• Payment audit timeline
• Contextual actions

I prioritized Total Hours to Pay over Total Hours Worked because it is the number most directly connected to the payment decision.

For included entries, the interface uses a dense table on desktop and cards on mobile while preserving the same information hierarchy.

ChatGPT + OpenCode

I used AI at two different levels.

ChatGPT - Think

ChatGPT helped me:

Plan -> Compare -> Question -> Decide

I used it to explore product behavior, define business rules, reason about architecture, break the work into implementation phases, and review the resulting feature.

I did not simply accept its recommendations.

For example, decisions such as replacing Pending with Draft, treating Cancel Review as an action instead of a state, and deferring authentication were deliberate product decisions rather than blindly generated implementation.

OpenCode - Build

Once the direction was clear, I moved into the repository with OpenCode.

The implementation was performed incrementally across the actual product codebase, touching:

• React components
• TypeScript domain models
• Application use cases
• API repositories
• DTOs and mappers
• Backend controllers
• Database migrations
• Payment lifecycle
• Audit events
• Responsive UI
• Tests

The work included components such as PaymentBatchDetail, PaymentHistory, payment dialogs, status badges, and reusable entry/list components.

AI Generated Code. I Still Owned the Result.

One of the most useful parts of the workflow was discovering that an implementation could be technically correct but product-incomplete.

For example, the payment lifecycle could exist in the backend while the UI still did not expose the complete workflow.

That led to additional iterations connecting:

API -> repository -> use cases -> Employee workflow -> Payment Detail -> UI synchronization -> Audit Timeline

The AI helped accelerate implementation, but I remained responsible for identifying what was missing and deciding what needed to change.

Verification

I treated AI-generated implementation as something to verify, not something to trust automatically.

The feature went through multiple layers of validation:

• Frontend and backend builds
• Backend lifecycle tests
• Domain assertions
• Transaction and rollback validation
• Concurrency checks
• Migration checks
• Lint and diff validation
• Structured manual QA scenarios

The final validation covered payment creation, editing, completion, reopening, review, reverting, audit history, calculations, invalid actions, responsive behavior, accessibility scenarios, and regression cases.

During deployment, a production issue exposed a missing database migration. Instead of changing application code blindly, I traced the problem to the deployment environment and applied the required migration.

What I Learned

AI-assisted development is not about asking an AI to build something and accepting the result.

For me, the workflow looks more like:

Product thinking

-> AI-assisted planning

-> Human decisions

-> AI-assisted implementation

-> Review

-> Testing

-> Iteration

The biggest productivity gain is not that AI writes code faster. It is that I can move faster between thinking, building, testing, and refining while keeping ownership of the product and the final implementation.

Stack

React · TypeScript · React Router · Tailwind CSS · shadcn/Radix UI · REST API · AI-assisted development

AI Tools

ChatGPT · OpenCode