What happened
OpenAI published a developer blog post telling builders to revisit the instruction files they hand their coding agents now that GPT-6 Astra is out. Astra targets long coding and computer-use tasks.
The post targets anyone who has built up an AGENTS.md file (a plain-text instructions file that agents like Codex read at the start of a session to learn a project’s conventions), “skills” (named, reusable instruction bundles an agent pulls up for a specific kind of task, like handling a database migration), or detailed standing task prompts over the past year. OpenAI’s point: the handholding you added for earlier, weaker models can now actively work against a more capable one.
What OpenAI says to change
Drop the blanket instructions. OpenAI writes that requiring the agent to read a full architecture document before every edit is “excessive for a typo fix.” The same applies to instructions that push the model to run tests every single time. OpenAI says Astra checks its work without repeated reminders, so an instruction written for a model that needed that nudge can now make it over-test simple changes and waste time doing it.
Make skills narrow and specific. Instead of a trigger like “use when working with databases,” OpenAI recommends something closer to “use when adding or changing a migration, or reviewing its rollout.” A vague trigger forces the model to guess whether a skill applies. A precise one tells it exactly when to reach for it.
Structure skills as routers, not recipes. OpenAI calls this “progressive disclosure”: the main file for a skill should be a short index pointing to more detail, not a long document the model has to read in full every time it’s invoked. The model pulls in the deeper instructions only when the task actually needs them.
Point to reference files by task, not by default. Rather than telling the agent to read every project file up front, OpenAI suggests mapping specific files to specific situations, for example “architecture.md for service boundaries, database.md for schema changes, deployment.md when preparing a deployment.” The agent opens only what the current task calls for.
Define which work can continue without another pause. If your instructions tell the agent to pause and ask before continuing in situations where you’d actually be fine letting it keep going, OpenAI says that guardrail now costs more than it protects. It recommends defining what “done” looks like for a task explicitly, then letting Astra work through to that point. Its example permits local tests with disposable fixtures and no production access. Keep approval requirements for actions you still need to review.
Why it matters
OpenAI wrote this advice for Codex and Astra, but the same instruction-file problem applies to other coding agents. Anyone maintaining an instructions file for a coding agent, whether that’s AGENTS.md, Claude Code’s equivalent CLAUDE.md, or a similar setup file, is maintaining a document written against whatever model was current when they wrote it. Models get more capable every few months. Instructions rarely get revisited on that same schedule.
An instructions file that over-specifies stops being neutral once the underlying model improves. Extra required reading burns time and tokens (the units a model is billed and rate-limited on) doing work a task doesn’t need. Redundant “please double check” instructions can push a model that already double-checks into doing it twice. A stop condition can interrupt work you have already authorized. Define that scope clearly rather than assuming a newer model needs no boundaries.
Who should care
Anyone with a maintained AGENTS.md, a library of skills, or a set of standing task prompts they reuse across coding-agent sessions, especially if that file was written more than a few months ago or before your current model’s most recent upgrade.
What builders should do next
Pick your longest-standing skill or instruction file and read it as if seeing it for the first time. For each instruction, ask whether it’s telling the model to do something it would already do on its own, or gating a decision more tightly than the task actually needs.
Try a task the file covers, such as a small feature change with its affected tests. Run it from the same starting code in separate branches with the original and trimmed instructions.
Compare correctness, steps taken, token usage and any early stop. Fewer steps with the same correctness suggest that some instructions may be redundant. If the trimmed version misses a necessary check, restore that instruction. Check other tasks before removing a rule that protects a different workflow.
End of article