How I Structure Codex / ChatGPT Workflows Inside Real Engineering Projects.

I’ve been tightening how I use Codex / ChatGPT inside real engineering projects.

Not as a magic code generator.

Not as “vibe-driven autocomplete.”

As a structured engineering assistant that needs context, boundaries, and review.

The biggest lesson so far:

AI becomes useful when the project gives it a clear operating model.

For that, I keep two things separate:

1. Repo-wide agent rules live at the project root.
2. Codex-specific workflows live under .codex/

Example scaffolding:

project/ AGENTS.md (https://www.linkedin.com/redir/redirect?url=http%3A%2F%2FAGENTS%2Emd&urlhash=jh-H&trk=article-ssr-frontend-pulse_little-text-block)

.codex/ README.md (https://www.linkedin.com/redir/redirect?url=http%3A%2F%2FREADME%2Emd&urlhash=JPtp&trk=article-ssr-frontend-pulse_little-text-block)

tasks/
  README.md
  senior-engineer-chatgpt-codex-workflow.md
  ci-debugging.md
  pr-review.md
  refactor-plan.md
  documentation-update.md

exec-plans/ README.md TEMPLATE.md active/ .gitkeep completed/ .gitkeep

decisions/ README.md TEMPLATE.md ADR-0001-codex-operating-model.md

quality/ DEFINITION_OF_DONE.md TESTING.md CODE_REVIEW.md QUALITY_GATES.md

operations/ COMMANDS.md LOCAL_VS_CONTAINER.md RECOVERY.md

references/ .gitkeep

generated/ README.md .gitkeep ```

Minimal explanation:

AGENTS.md (https://www.linkedin.com/redir/redirect?url=http%3A%2F%2FAGENTS%2Emd&urlhash=jh-H&trk=article-ssr-frontend-pulse_little-text-block) sits at the project root because it defines how coding agents must behave in the repository: what to read, what not to touch, how to report work, and when to stop instead of guessing.

.codex/ README.md (https://www.linkedin.com/redir/redirect?url=http%3A%2F%2FREADME%2Emd&urlhash=JPtp&trk=article-ssr-frontend-pulse_little-text-block) explains what this Codex workflow layer is and how it should be used.

.codex/tasks/ contains reusable task briefs: CI debugging, PR review, refactoring, documentation updates, and other repeatable workflows.

.codex/exec-plans/ is for complex work that needs a living implementation plan. Active work stays in active/, completed work moves to completed/, so the reasoning is preserved instead of disappearing into Git archaeology.

.codex/decisions/ stores AI-workflow ADRs: durable decisions about how Codex is allowed to operate inside the project.

.codex/quality/ defines what “done” means: tests, review rules, validation gates, and evidence required before claiming completion.

.codex/operations/ documents how commands are actually run.

In particular, it makes the boundary explicit between host-side repository actions and container-side application/runtime actions.

Version control and forge operations usually belong on the host: git, gh, glab, pull requests, merge requests, issue commands, release commands, and similar repository-facing operations.

Application work belongs in the project runtime environment: tests, builds, package managers, migrations, linters, framework CLIs, and service commands.

That boundary matters because the host is not the application runtime.

Pretending otherwise is how dependency soup gets served with a straight face.

.codex/references/ holds supporting material Codex may need to read but should not treat as executable instruction.

.codex/generated/ is only for generated artifacts that support the Codex workflow itself.

It is not where generated project code goes.

Generated clients, protobuf output, ORM files, API bindings, frontend build artifacts, migrations, or application source generated by project tooling must stay wherever the actual project architecture says they belong.

.codex/generated/ is for things like generated Codex summaries, derived workflow references, generated prompt indexes, generated documentation maps, or other AI-assistance artifacts.

In other words:

Generated project code belongs to the project.

Generated Codex-support material belongs under .codex/generated/

Tiny distinction.

Massive blast radius if ignored.

The important part is not the number of files.

The important part is that every file has one job.

That matters because AI agents are fast, useful, and occasionally confident in the way only a machine with no mortgage can be confident.

Used badly, AI creates chaos faster.

Used well, it helps senior engineers move faster without lowering standards.

The model accelerates execution.

The engineer preserves judgment.