From requirement to pull request: my flow for building Full Stack features with Codex and Claude

Coding agents help more when they work inside a flow with context, boundaries, acceptance criteria, and technical review. The real gain is not asking them to “build this feature”, but turning the request into something implementable and verifiable.

Context

One thing I keep noticing when working with AI in development is that response quality depends less on a perfect prompt and more on the quality of the context that exists before it.

When the task is small, asking for a component, a function, or a focused refactor can work well. But when the change crosses frontend, backend, business rules, states, validation, data, and project patterns, a loose request becomes a bet.

The problem with asking for code too early

The problem is not AI writing code. The problem is AI writing code without knowing which patterns the project already uses, which components should be reused, which files should not be changed, what behavior needs validation, and what is out of scope.

• Project context before the prompt.
• Problem before solution.
• Explicit scope and out of scope.
• Small, verifiable acceptance criteria.
• Agent plan before implementation.
• Human review after generated code.

The flow that makes the most sense to me

The first step is recording context: stack, folder structure, component patterns, restrictions, validation commands, and documents that guide the change. This reduces the space for the agent to invent architecture from scratch.

Then comes the spec. It does not need to be huge, but it needs to answer the basics: what exists today, what problem needs to be solved, who is affected, what behavior is expected, what should not be touched, and how we will know it is done.

Before implementation, I prefer asking for a plan. A good plan says which files seem relevant, which approach will be used, which risks exist, which steps will be executed, and how the change will be validated.

A better request example

Instead of simply asking “create a feature to summarize reports with AI”, a more useful request describes context, involved layers, and criteria.

1# Feature: asynchronous report summary23## Technical context4- Frontend: Vue 3 + TypeScript5- Backend: FastAPI6- Processing: queue + worker7- Persistence: ai_jobs table89## Scope10- Create POST /reports/:id/summary endpoint11- Register job with pending status12- Process job in the worker13- Validate the structured AI response14- Show pending, processing, completed, and failed in the UI1516## Out of scope17- Authentication18- Billing19- Admin panel20- Multi-file support2122## Acceptance criteria23- The user can start the summary24- The UI shows the current job status25- Failures return a controlled message26- The response is saved only after schema validation27- Logs record provider, model, latencyMs, and status

• Context: Vue/TypeScript frontend, FastAPI backend, and asynchronous processing.
• Scope: endpoint to register the request, queue, worker, status persistence, and frontend display.
• Out of scope: authentication, billing, admin panel, and multi-file support.
• Criteria: visible status, understandable error, validated response, and minimum logs for model, time, and status.

Review is still part of the work

Reviewing AI-generated code is not only about looking for syntax errors. I look at adherence to project patterns, duplication, naming, coupling, error handling, security, responsiveness, accessibility, interface states, and impact on unrelated files.

At the end, a good pull request needs to leave traces: what changed, why it changed, how it was validated, which risks exist, and which pending items remain.

The technical prompt I would use

1Before implementing, inspect the codebase and return a plan.23Respond with:41. Files that need to be read.52. Files that will probably change.63. Data contracts involved.74. Technical risks.85. Plan in small steps.96. Validation commands.1011Do not change code yet.12If you find relevant ambiguity, stop and ask.

PR review checklist

• Does the diff change only files within scope?
• Are frontend/backend contracts explicit?
• Were loading, error, empty, and success states handled?
• Are there enough logs to debug failures?
• Do error messages avoid leaking sensitive details?
• Does the implementation reuse existing patterns/components?
• Were build, generate, or test commands executed?

Conclusion

The best use of Codex, Claude, and coding agents is not outsourcing thinking. It is creating a flow where AI helps execute, compare alternatives, find inconsistencies, and accelerate repetitive parts while the developer keeps context, judgment, and responsibility.