The workflow stabilized. Here's what moved.
The tooling stabilized in 2026 around a few durable patterns. If your setup is 6–7 months old, the biggest shifts are: a hand-written agent context file, spec-and-plan-before-code, and treating verification as a structural step rather than trusting the agent's judgment. Here's the short version.
Anchor the agent with a hand-written AGENTS.md
Write your AGENTS.md by hand. AI-generated ones measurably hurt performance in most tested settings.
AGENTS.md is now the de-facto context file read by Codex, Cursor, and most agents: a README written for the agent, not humans. Put it at the repo root, plus nested copies for sub-packages the agent should treat differently.
Write it by hand
An ETH Zurich study tested this directly: 5/8tested settings where LLM-generated files reduced task success&+20–23%extra inference cost from those files
In 5 out of 8 tested settings, LLM-generated files reduced task success rates, agents took 2.45 to 3.92 additional steps per task, and inference costs increased by 20% to 23%, while developer-written context files help, but modestly (Augment Code). The mechanism is straightforward: a follow-up experiment removed all other documentation from the repository, and under those conditions LLM-generated files improved performance, confirming that LLM-generated context files are redundant with existing documentation agents already access independently, duplicating content and adding cost without adding signal.
Include only what an agent can't infer
- Build/test/lint commands, exact flags included
- Directory responsibilities and architectural boundaries
- A "do not touch casually" list: migrations, generated types, auth
- Your Supabase migration workflow
- Hard rules: route handlers stay thin, business logic lives in
services/, validate all external input at the boundary, authorize before loading or mutating protected resources
Keep it short and current. Keep the file short enough that every line is genuinely load-bearing, and prioritize executable commands and explicit boundaries over narrative description (Augment Code). A stale AGENTS.md is worse than none.
If you ran /init or asked Codex to generate your AGENTS.md six months ago, rewrite it yourself. Delete anything the agent could already infer from your README, package.json, or file tree.
Spec and plan before you let it write code
The leverage is in the spec, not the prompt. Review the plan before the diff exists.
The dominant 2026 workflow is spec-driven: write a short spec (intent + constraints + acceptance criteria), have the agent produce a plan, review that, then let it implement. Agents are excellent at writing code and terrible at guessing what you meant, so the payoff comes from front-loading intent rather than iterating on output.
For anything non-trivial in a complex SaaS, sketch the architecture yourself and let Codex fill in the CRUD, endpoints, and components that follow existing patterns. A plan-mode or reviewed-plan step catches wrong-direction work before it costs you a big diff.
If you've been going prompt → code → review, insert a plan → review step in between. It's the single highest-leverage change on this list for a complex, single-maintainer codebase.
Make verification structural, not vibes
A green "verified" checkbox is not evidence anything ran. Gate the agent's work with CI, not its own say-so.
Without tests, an agent verifies its own work with its own judgment, which is unreliable in a complex codebase. The known 2026 failure mode: an agent marks a "verify" task done while substituting manual-testing instructions for an actual test.
The loop that closes the gap
- Write (or have the agent write, then you check) the test first
- Confirm it fails
- Implement until it passes
- Run the full suite before accepting, not just the new test
Wire lint, typecheck, and tests into CI on every PR so the agent's work is gated by something other than its own report.
If your CI doesn't block merges on the full suite yet, that's the gap an agent will eventually walk through.
Keep diffs small and parallelize with worktrees
Small, single-purpose PRs are the unit of agentic work. Worktrees are the clean way to run more than one at a time.
Small, single-purpose PRs are the unit of agentic work: they're reviewable, revertable, and keep the agent's context focused. When you want to run multiple Codex sessions at once without them colliding, use git worktrees: each session gets an isolated checkout in its own folder.
This is the clean replacement for stashing and branch-juggling, and it lets you have one agent implementing while another reviews.
If you're still stashing to switch between agent tasks, worktrees remove the friction and let parallel sessions run safely.
You own the review, especially security
Security pass rate on AI code is stuck around 56% while volume surges. Review capacity, not generation, is now the bottleneck.
Across all languages, CWEs, tasks, and models tested, the average security pass rate remains at 56%, and roughly 44% of AI code generation tasks introduced a risky security vulnerability in tests (Veracode).
The gap is stark: given no security-specific prompting, models produce code that compiles about 100% of the time, but on security they fail nearly 44% of the time, introducing a vulnerability from the OWASP Top 10 (TheNextWeb). And it's not improving: the average security pass rate across models is 56%, barely changed from 55% in the first report, meaning security performance has stayed flat while the amount of AI-generated code entering pipelines has surged.
The bottleneck is now review capacity, not generation. Practical stance:
- Use a second agent as a first-pass reviewer (security, consistency, defects) to triage at scale
- A human owns final sign-off on judgment-heavy and security-critical paths
- For your stack: personally review anything touching Supabase RLS policies, auth flows, service-role keys, and payment paths
Types + tests + an AI review + your own eyes. Never let generated code near secrets or RLS without a human pass.
Codex writing more of your codebase is fine. Codex being the last set of eyes on an RLS policy is not.
Context and MCP hygiene
Every connected tool is context budget and attack surface. Connect what you use, prune the rest.
Give the agent tools, not tabs: connect the MCP servers it actually needs (Supabase, GitHub, your error tracker) so it reads real state instead of guessing, and prune the ones you don't use.
- Keep prompts scoped to one task; start a fresh session when you switch context rather than letting a long thread drift
- Commit the agent config (AGENTS.md, MCP setup, prompt/skill files) to the repo so it's versioned and shareable
Audit your MCP connections the same way you'd audit OAuth scopes. Unused servers are pure downside.
Set up now for the second developer
Agentic conventions are what a new hire onboards into. Codify them while it's cheap and solo.
You're solo today but adding someone in 3–4 months, and the agentic conventions are what a new hire onboards into. Do it now while it's cheap:
- Keep AGENTS.md as the single source of shared agent conventions
- Standardize on per-developer API keys / virtual keys, never a shared org key, so cost and access are attributable and revocable
- Adopt a required-review rule on PRs (a second developer or a second agent)
- Write down your spec → plan → implement → verify loop so it's a team process, not tribal knowledge in your head
The teams scaling agentic coding well in 2026 treat "who is accountable for AI-generated code before it ships" as an explicit role, not an accident.
Every convention you formalize now is one less thing you have to explain, badly, in month one with a second engineer already mid-sprint.
Your instincts are the moat
Your instincts as a pre-AI engineer are the moat here: the best engineers in 2026 aren't the fastest coders, they're the best at not blindly trusting AI code. Keep the spec tight, the diffs small, and the review honest, and adding a second developer becomes a config change rather than a rewrite.
Sources: Anthropic 2026 Agentic Coding Trends Report · AGENTS.md best practices, Augment Code · OpenAI Codex best practices for 2026, Maxim · Spec-Driven Development 2026 guide · Veracode 2026 GenAI Code Security Report