AI-assisted development: integrating Codex into real engineering work

I used Codex continuously for about one year on projects at Shanghai Fengqu, including embedded client pages, the official administration system, and the creator back office. I do not treat AI as an autonomous replacement for an engineer. I place it inside an inspectable, verifiable, and reversible workflow: AI accelerates information retrieval and mechanical work, while I retain responsibility for product judgment, architecture boundaries, risk, and delivery.

Practice on Fengqu projects

I use AI as an engineering accelerator, not as a substitute for technical judgment. On Fengqu's embedded client pages and back-office systems, my workflow became repeatable: let Codex inspect the actual repository to locate entry points, dependencies, and likely impact; confirm constraints and the solution myself; then review the diff, edge cases, and failure paths before running the build and focused regression checks.

This approach improved how I handled unfamiliar modules, cross-file changes, repetitive scaffolding, refactoring, diagnosis, and technical documentation. I do not provide models with credentials, secrets, or user data, and I do not merge or release generated code without human review.

AI capability is more than prompting

The quality of an outcome usually depends on four things: accurate context, a clear task boundary, executable acceptance criteria, and verification of the generated change. I remain responsible for:

• Translating product rules into technical constraints.
• Deciding ownership across components, stores, routes, services, and configuration.
• Reviewing generated diffs for compatibility, failure paths, and repository conventions.
• Running builds and focused regressions, and owning the final result.

How I used Codex in project work

1. Understanding an existing codebase

For an unfamiliar feature, I ask Codex to trace the path from page entry and routes through stores, APIs, and shared components, then verify that map with source searches. This accelerates orientation; actual data semantics, module ownership, and historical compatibility still require product and engineering judgment.

2. Assessing change impact

For cross-file changes, I first define the expected behavior, behavior that must remain unchanged, and acceptance checks. Codex can then locate consumers, shared state, API dependencies, and relevant build configuration. This makes it easier to catch the risk of fixing one page while breaking another game area.

3. Accelerating implementation and refactoring

Codex is effective for well-defined, repetitive work such as form scaffolding, API adapters, data transformations, and type additions. For design-heavy concerns—state ownership, permission boundaries, and cache consistency—I provide constraints and select the approach before implementation. Generated code must fit the existing system instead of introducing unnecessary migration cost.

4. Diagnosis and verification

I provide the symptom, reproduction path, relevant logs, and source context, then use Codex to generate hypotheses to test. After a fix, I inspect the diff and run at least the relevant syntax or type checks, a production build, and focused regression checks. Higher-risk changes also cover role switching, empty data, failed requests, and repeated actions.

5. Documentation

For cross-module behavior such as dynamic menus, configurable campaigns, or SVGA asset loading, AI helps turn implementation details into flows, boundaries, and diagnostic checklists. I remove unsupported assumptions and add real project constraints so the result supports maintenance and handover.

A repeatable collaboration loop

Define the problem and acceptance criteria
  → provide minimal, relevant source context
  → use Codex to explore call paths and impact
  → confirm the solution, boundaries, and risk
  → implement in small steps and review the diff
  → build, test, and run focused regressions
  → document the result or roll back when needed

I break large tasks into independently verifiable increments—for example, implement the data model and pure transformation first, integrate the store second, and update the view last. Smaller changes are easier to review, diagnose, and reverse than a large generated patch.

Using AI to scaffold a frontend architecture

I do not ask AI to generate an entire application from a one-line request. A project foundation establishes constraints for every future contributor, so I build it from constraints toward evidence:

1. Define constraints: runtime, Vue versions, browser support, deployment path, package manager, SSR needs, permissions, and environments.
2. Design dependency direction: views may depend on domain modules, and domain modules may depend on infrastructure; reverse dependencies should be prohibited. Shared layers should not expand based on hypothetical reuse.
3. Create the minimum skeleton: entry, Router, state, request layer, environment validation, error boundaries, and base styles—without generating a large set of placeholder pages.
4. Complete one vertical slice: use a real screen to verify routing, API calls, state, failures, permissions, tests, and the production build before scaling out.

AI can propose directories, configuration, and scaffolding. I must explain why every dependency exists, remove abstractions that do not fit, and prove that the empty foundation builds and a real user flow works.

What “training the AI” means in this workflow

In day-to-day engineering, an assistant appears to “learn the project” through three practical layers:

• Task context: the goal, relevant files, current behavior, constraints, and acceptance criteria for one change.
• Repository rules: naming, directory boundaries, prohibited patterns, test commands, and delivery checks stored in project instructions or engineering documentation.
• Feedback calibration: recurring review findings become counterexamples, prompt templates, and checklists used in later tasks.

This is context engineering and workflow calibration, not parameter training. A knowledge base, retrieval-augmented generation, fine-tuning, or an evaluation dataset would each require a separate explanation of data, updates, and measurement.

Writing a precise engineering request

I use executable context rather than elaborate role-playing:

Goal: the user behavior that must change
Current state: entry point, call path, and observed problem
Scope: files and modules that may or may not change
Constraints: versions, compatibility, APIs, conventions, and security
Acceptance: normal, failure, permission, empty-data, and build checks
Output: analyze first, implement in small steps, and report risks and evidence

Instead of saying “optimize the home page,” I would provide the target metric, current resources, behavior that must remain unchanged, target devices, telemetry that must stay intact, and the measurement method. A request that resembles an executable engineering ticket leaves less space for plausible but irrelevant completion.

Reducing AI errors

• Require references to real files and call relationships before accepting a plan; say “unknown” when evidence is absent.
• Handle one verifiable objective at a time and control the number of changed files and diff size.
• Provide actual versions and project commands to avoid APIs or configuration from another release.
• Treat source code and API contracts—not model guesses—as the authority for fields, permissions, and business rules.
• Ask for risks, counterexamples, and unverified assumptions in addition to the happy path.
• Use compilers, types, lint, tests, and production builds as independent feedback; an AI cannot be the sole judge of its own output.

Keeping AI-generated code maintainable

I apply the same or stricter standards as I would to human-written code: names express domain intent, state has clear ownership, functions and components have focused responsibilities, failures are observable and recoverable, and abstractions reflect real variation. I also check for unnecessary dependencies, duplicated shared capabilities, expanded global state, hidden side effects, and whether another developer can maintain the code without reading the original prompt.

Tests should cover domain boundaries and state transitions instead of producing a large volume of shallow assertions. Generated tests and implementation can share the same mistaken assumption, so passing tests are one signal rather than definitive proof.

Reviewing a large AI-generated change

A large diff is itself a risk signal. I stop further generation and split changes into mechanical edits, shared capabilities, business logic, and configuration or dependency changes. I then review in this order:

1. Scope first: file list, diff size, dependencies, and configuration must match the task boundary.
2. High-risk behavior next: authentication, routes, shared state, caches, writes, failures, and release configuration come before styles or scaffolding.
3. Review semantics, not only syntax: where data originates, who may mutate it, how failures recover, and whether previous behavior still holds.
4. Sample mechanical edits; fully verify rules: bulk renames can be sampled and checked with search, but business branches, permissions, and transformations require complete review.
5. Align validation with each commit: every batch has focused checks and a regression path so that defects can be isolated and reversed.

If a generated change cannot be explained and reviewed in reasonable time, it is not deliverable. The correct response is to reduce the batch or reimplement it, not lower the review standard because generation is already complete.

Quality and security boundaries

• Never provide credentials, secrets, production configuration, user data, or unsanitized logs to a model.
• Treat source code, build output, and observed behavior as evidence—not an AI assertion.
• Never merge or release generated code without human review; the developer owns the result.
• Do not ask AI to invent missing product rules; clarify them or state assumptions explicitly.
• Preserve compatibility, repository conventions, and maintainability rather than optimizing for generation speed.

Measuring whether AI adds value

I do not measure AI capability by lines of generated code. Better signals are faster orientation in unfamiliar modules, fewer missed dependencies, less repetitive work, verified fixes, and documentation that another engineer can use. If review and rework cost more than the time saved, I reduce the task scope or complete it conventionally.

Scope of this experience

This work demonstrates an ability to integrate Codex into a frontend engineering workflow and govern its output. It is not a claim of foundation-model training, fine-tuning, or inference-platform experience. I am extending this foundation into agent application development, including tool use, context management, evaluation, and observability.

Continue with the configurable campaign platform.