What Codex is allowed to touch what you should never delegate how to structure prompts how to version features (v1, v2, v3)
For your Med Manager project, I would treat Codex as a junior-to-mid developer who can work very fast, while you stay in control of architecture and product decisions.
Project Operating System
Roles
You = Product Owner
Decide:
- What feature to build
- What problem it solves
- What data should be stored
- What screens should exist
- What fields users should see
Examples:
- Should a condition have severity?
- Should prescriptions link to medications?
- Should inactive conditions be called « resolved »?
These decisions should come from you, not Codex.
ChatGPT = Architect / Reviewer
Use me for:
- Database design
- Laravel best practices
- Reviewing Codex plans
- Debugging errors
- Feature prioritization
- Security review
- Portfolio strategy
Examples:
- « Should severity be integer or enum? »
- « Should prescriptions be linked to medications? »
- « How should reminders work? »
Codex = Implementation Engineer
Use Codex for:
- Writing migrations
- Updating controllers
- Creating Blade views
- Refactoring code
- Running tests
- Generating documentation
Examples:
- Add severity field throughout the app
- Create medication report PDF
- Standardize Conditions views
What Codex Is Allowed to Touch
Safe
Controllers:
app/Http/Controllers/*
Views:
resources/views/*
Models:
app/Models/*
Migrations:
database/migrations/*
Routes:
routes/web.php
Tailwind styling
Validation rules
Filtering/sorting logic
PDF generation
What Codex Should Not Change Without Permission
Ask Codex to never modify these unless explicitly instructed:
Authentication
app/Models/User.php
Login
Registration
Password reset
Middleware
Permissions
Core Infrastructure
config/*
bootstrap/*
vendor/*
.env
Existing Database Data
Never tell Codex:
« Clean database »
« Drop old tables »
« Remove unused columns »
without reviewing first.
Prompt Structure
This structure works very well.
Project: Laravel 12 Med Manager
Goal:
Add severity field to conditions.
Requirements:
- severity enum
- values: critical, high, medium, low, controlled
- default = medium
- show in conditions index
- show in conditions create/edit forms
- sortable in controller
Constraints:
- do not modify authentication
- do not modify doctors module
- do not modify medications module
- preserve existing functionality
Deliverables:
- migration
- model updates
- controller updates
- blade updates
After implementation:
Provide summary of files changed.
This dramatically reduces mistakes.
Feature Versioning
Never build giant features.
Build vertically.
v1 = Works
Minimal version.
Example:
Severity field:
- migration
- create
- edit
- list
Done.
v2 = Useful
Add productivity features.
Example:
Severity:
- filters
- sorting
- colored badges
v3 = Professional
Advanced features.
Example:
Severity:
- dashboard charts
- severity trends
- PDF reporting
- alerts
Example: Medication Reminders
v1
Store reminder time.
08:00
20:00
Nothing else.
v2
Daily schedule view.
v3
Email/SMS notifications.
Git Workflow
Before every Codex task:
git add .
git commit -m "working state before severity"
Then let Codex work.
If Codex breaks something:
git restore .
or
git reset --hard HEAD
and you’re safe.
One Rule That Will Save You Hours
Never ask:
« Improve the application »
Instead ask:
« Improve the Conditions module only. Do not modify any other files. »
Scope is everything.
The most successful way to use Codex on a growing project is:
- Discuss feature with me.
- We define the exact scope.
- Commit current state to Git.
- Give Codex a precise task.
- Review changes.
- Commit again.
That process scales well whether the project stays a portfolio app for your mother or eventually becomes a real SaaS product.
