With increasingly capable coding agents such as Codex running GPT-6 Astra, I think we need to change the way we write prompts.
A lot of us still prompt coding agents as if we are programming them:
Open this file.
Check this class.
Then inspect this method.
Compare it with that implementation.
Create a plan.
Don't change anything yet.
Then update these files...
That worked reasonably well when models needed constant direction.
But with modern agentic coding models, it can actually get in the way.
A better approach is:
Tell the agent what outcome you want, define the boundaries, explain what success looks like — and let it work out how to get there.
OpenAI's own model guidance increasingly recommends this outcome-first approach: define the goal, success criteria and constraints rather than unnecessarily prescribing every intermediate step.
From Instructions to Ownership
Instead of treating Codex like a developer who needs a Jira ticket containing 25 implementation steps, treat it more like an experienced engineer taking ownership of a piece of work.
Give it four things:
Goal — What are we actually trying to achieve?
Constraints — What must not change?
Success criteria — How do we know the work is complete?
Decision boundaries — When should the agent stop and involve you?
Then let the agent explore the repository, understand dependencies, choose the implementation approach, run tests and correct problems it finds.
This becomes particularly interesting with GPT-6 Astra. OpenAI says Astra improves software engineering and complex multi-step work, while Codex can now preserve notes and retrieve earlier context during long-running sessions.
That makes long-running engineering tasks much more realistic.
A Practical Example
Imagine I want Codex to optimise a query compiler.
I could give it dozens of instructions telling it exactly where to look and what to change.
Instead, I would write something like this:
Goal:
Refactor the filter compiler so compatible typed EAV predicates are
consolidated into fewer SQL joins without changing query semantics.
Constraints:
- Preserve current FilterOperator coverage.
- Never consolidate across NOT or OR boundaries.
- Preserve table-row correlation.
- Preserve property-type boundaries.
- Do not introduce new operators.
- Avoid unrelated refactoring.
Success criteria:
- Existing tests pass.
- Add semantic fixtures for missing/null/empty/not-equal cases.
- Benchmark before and after.
- Inspect generated SQL and query plans.
- Explain any semantic differences before changing behaviour.
Work autonomously.
Ask me only when a decision materially changes semantics or architecture.
Otherwise make reasonable assumptions and continue.
Notice what is missing.
I haven't told Codex which files to open.
I haven't told it which classes to inspect first.
I haven't told it exactly how to implement the optimisation.
That's intentional.
Those are implementation decisions.
The agent can inspect the codebase and determine the best path itself.
The Human Role Changes
This doesn't mean giving an AI unlimited freedom.
Quite the opposite.
The human becomes responsible for defining the engineering boundaries.
My job is to tell the agent:
what absolutely must remain true;
which trade-offs are acceptable;
which architectural decisions require my involvement;
and what evidence I expect before considering the work complete.
The agent's job is to figure out the path between the current state and that destination.
This is a subtle but important shift.
Instead of:
Human → instructions → AI executes
we move toward:
Human → intent + boundaries → AI explores → implements → verifies → human reviews
OpenAI has also been pushing Codex toward longer-running work where developers steer an active task rather than specifying everything upfront.
My New Rule for Codex Prompts
Before writing a long prompt, I now ask myself one question:
Am I describing the destination, or am I trying to drive the car?
If the steps are genuinely important, specify them.
If they're just one possible way to reach the result, leave them out.
Give Codex the goal.
Give it the guardrails.
Give it a clear definition of done.
Then give it enough room to engineer the solution.
With coding agents becoming more capable, prompt engineering is increasingly becoming delegation engineering.
