Should we standardise on Claude Code or Codex?

I use both. Codex reads AGENTS.md directly and Claude Code reads it through a one-line import, so the shared instructions carry over. I often let one write and the other review, which puts two different sets of blind spots on the same change. The workflow around them decides more of the outcome than the choice between them.

Do we still need RAG and a vector database?

For the code itself, rarely. Claude Code finds code with grep and file reads instead of an embedding index, and that approach never goes stale. For large bodies of prose, such as years of support tickets or contracts, a retrieval index still helps. I start without one and add it when an agent keeps missing something a search should have found.

How do we stop agents from making the same mistake twice?

Each repeated mistake becomes a line in the instruction file, a hook, or a test, depending on what it costs when it happens again. A wrong command belongs in the instruction file. A broken convention belongs in a lint rule or a hook. A bug belongs in a test, because a test is the one of the three the agent can't skip.

What would you set up first?

One short, shared AGENTS.md with the real build and test commands, and a test suite the agent can run without help. Those two give an agent a way to check its own work, which matters more than any prompt. Memory, skills, and multi-agent review all build on them, and I'd put the whole stack in place in one sprint rather than drip it in. How long would an agent in your repository take to find the right test command today?

All guides

Guide

Setting up an AI-assisted development workflow

How I set up Claude Code, Codex, and similar agents for a team: instruction files, prompts, retrieval, shared memory, and multi-agent code review.

An AI coding agent is a model in a loop. It reads files, runs commands, and edits code until a check passes or it runs out of ideas. The model matters less than what surrounds it: the instructions it reads, the context it can reach, the memory it keeps between sessions, and the checks it has to pass. I've set this up across more than a dozen of my own repositories on Claude Code and Codex, and the same few layers keep deciding the outcome.

The evidence on speed is still thin. METR's randomised trial in early 2025 found that experienced open-source developers took 19% longer with AI tools, while believing they'd been faster. Its February 2026 follow-up called its own new data an unreliable signal, partly because developers increasingly refused to work without AI. I read that as a measurement problem and a setup problem at once. The teams I see getting real gains didn't switch to a better model, they built a better harness around it.

This is an engineer's reading of tools and threats that change from month to month. I wrote it from my own setups and the sources named in each section, checked on 9 November 2026. It isn't legal advice. Versions, prices, and defaults move fast, so I recommend checking each tool's current documentation before copying a setting.

Does it apply to you?

If one of these lines describes your team, the rest of this guide applies. If none does, the agents are probably already earning their place. A thirty-minute call is a quick way to hold the setup up against the patterns below.

We use Claude Code, Codex, Cursor, or Copilot, and each developer has set it up differently.
Our agents keep repeating the same mistakes: the wrong test command, an old pattern, a library we removed last quarter.
We're opening more pull requests than we can review, and a lot of them come from an agent.
Our decisions, runbooks, and product context live in Notion, Confluence, or a wiki that no agent can reach.
We want agents to run longer tasks unattended, and we don't trust them to yet.

What the setup needs

Instruction files: short, shared, and owned

Every agent reads a file of standing instructions when a session starts. Claude Code reads CLAUDE.md, while Codex and dozens of other tools read AGENTS.md, a format the Agentic AI Foundation at the Linux Foundation now looks after. I write the shared rules once in AGENTS.md and import them from CLAUDE.md, so every tool on the team reads the same text. The file holds what an agent can't infer from the code: the real build and test commands, the conventions that look wrong but are deliberate, and the places it must never touch.

I used to think a longer file made a smarter agent. Then I measured one of my own: 563 lines, with about 400 of them a map of the directory tree and the critical rules sitting at the bottom. Anthropic's guidance for Claude Code is to keep the file short and prune it, because it competes with the task for the model's attention. I now treat it like code, with an owner, a review on every change, and anything mechanical moved out into a hook or a test.

Prompts as specifications

The prompts that work best read like a good ticket: the goal, the constraints, the files that matter, and the check that proves it's done. In January 2026, Andrej Karpathy posted notes on how coding models fail. They guess instead of asking, they overbuild, and they edit code nobody asked them to touch. Forrest Chang turned those notes into four rules that a lot of teams now paste into their instruction file: think before coding, simplicity first, surgical changes, and goal-driven execution.

The last rule carries the most weight for me, because a task phrased as a failing test lets the agent loop without a human in the middle. For anything that touches more than a couple of files, I also separate planning from editing. Claude Code's plan mode and Codex's read-only sandbox both let the agent read and propose without changing anything. I correct the plan, which is cheap, before the agent writes code, which isn't. Two or three concrete examples of the pattern I want do more than a page of rules.

Less code by default

Ponytail, a skill for Claude Code, Codex, and other agents, pushes simplicity further. It tells the agent to reuse what the codebase, the standard library, or the platform already has before it writes anything new. It never cuts validation, security, or accessibility to get there. Its authors report 53% less code on their own benchmark, while an independent JetBrains test across 80 paired tasks measured 15% less code and about 10% lower cost. I run it alongside the Karpathy rules and treat the published numbers as a ceiling, not a forecast.

Less code matters more with agents than with people. Every line an agent adds is a line a human has to review, test, and secure later. The smallest diff that fully solves the task is also the easiest one to check.

Context and retrieval, just in time

Anthropic's engineering team calls the core problem context rot: a model's recall drops as its context window fills, well before the hard limit. Claude Code's documentation builds its best practices on that one constraint. The fix is to load less up front and retrieve more on demand. An agent with grep, a file reader, and a test runner finds the relevant code itself, so I rarely build a vector index over a repository.

Classic RAG still earns its place for knowledge that isn't code: API documentation, past incidents, product decisions, and contracts. I expose those through an MCP server with read-only scopes, so the agent queries the source when it needs it and every access lands in a log. Subagents carry the rest. A subagent explores in its own context window and returns a short summary, which keeps the main session clear for the actual change.

Memory as a maintained wiki

Agents start each session with no memory, so whatever a team learns has to live in files. In April 2026, Karpathy described an LLM wiki: raw sources in one folder, and a set of interlinked Markdown pages that the agent writes, updates, and checks for contradictions. The links between pages form a small knowledge graph that a human can read in any Markdown editor. For a codebase, I keep three kinds of page: decisions with their reasons, a glossary of domain terms, and runbooks for the work that keeps coming back.

The discipline is in the upkeep. A session that settles a decision updates its page, and a scheduled pass flags pages that are stale or contradict each other. Team memory belongs somewhere shared, such as Notion or the repository, not in one developer's local agent settings. At the scale of a few hundred pages, I find a wiki easier to trust than a vector database, because a human can review every change to it.

Hooks, skills, and permissions

Instructions are advisory, and the model follows them most of the time. Hooks are deterministic: a script that runs before or after a tool call, every time. I put anything that must always happen into a hook or a CI check, such as formatting, a secrets scan, or a block on edits to migration files. Skills cover the middle ground, as packaged procedures the agent loads only when a task needs them.

Permissions belong in a settings file in the repository, with an allow list of the exact commands the work needs. I've reviewed agent settings that allowed a push to any branch and any Node command, with a single deny rule for rm -rf /. That isn't a guardrail. My guide to securing AI-generated applications covers the setup for agents that run unattended.

A second agent as the first reviewer

Agents now write code faster than people can review it, and a model reviewing its own work starts from the same assumptions that produced it. My answer is to hand the review to a different agent entirely. Claude Code writes the change, and Codex reviews it with its own model, its own instructions, and no memory of the session that wrote the code. When Codex writes, Claude Code reviews, so neither tool signs off on its own work.

The reviewer gets the diff, the AGENTS.md, and read-only access to the repository, and nothing from the writer's session, so it judges the code rather than the reasoning behind it. I split its work into narrow passes for correctness, security, and over-engineering, after the deterministic scanners have run. Every finding has to name a file, a line, and a concrete failure case, or it never reaches the human reviewer. The writing agent then fixes what survives, and a human makes the final call on the merge.

How I help

The engineering behind the guide. Each one starts with a map of the platform as it runs today.

Book a call

Platform engineering

I make the cloud you already run calmer, cheaper, and understood by more than one person on the team.

AI-built app security review

I review the app your AI coding agent wrote, from secrets and sign-in to the cloud account behind it, and rank what to fix first. From €500.

AI integration

I put language models to work on the problems that matter in your product and back office, and I ship them to production.

NIS2

What the NIS2 directive asks of a startup's cloud platform, how to tell whether a company is in scope or a supplier to one that is, and what to fix first.

DORA

What the Digital Operational Resilience Act asks of a fintech's cloud platform, and what its contract rules mean for suppliers to banks and insurers.

EU AI Act

How the EU AI Act sorts AI systems into risk tiers, which tier your product is likely in, when the rules apply, and what they mean for the way a team builds.

GDPR

What the GDPR asks of a startup's cloud platform in engineering terms: controller or processor, the records to keep, and the controls that prove it.

EU data residency in the cloud

How to keep customer data in EU regions on AWS, Azure, and Google Cloud, what still leaves, and the controls that prove it to a customer or auditor.

Securing AI-generated apps

What changes when an agent writes the code: the new attack paths, the controls that close them on AWS, Azure, and Google Cloud, and the EU reporting clock.

GitHub best practices (free)

A free guide to GitOps guardrails on GitHub: rulesets, independent reviewers, required pull requests and checks, Conventional Commits, and branch names.

Should we standardise on Claude Code or Codex?: I use both. Codex reads AGENTS.md directly and Claude Code reads it through a one-line import, so the shared instructions carry over. I often let one write and the other review, which puts two different sets of blind spots on the same change. The workflow around them decides more of the outcome than the choice between them.
Do we still need RAG and a vector database?: For the code itself, rarely. Claude Code finds code with grep and file reads instead of an embedding index, and that approach never goes stale. For large bodies of prose, such as years of support tickets or contracts, a retrieval index still helps. I start without one and add it when an agent keeps missing something a search should have found.
How do we stop agents from making the same mistake twice?: Each repeated mistake becomes a line in the instruction file, a hook, or a test, depending on what it costs when it happens again. A wrong command belongs in the instruction file. A broken convention belongs in a lint rule or a hook. A bug belongs in a test, because a test is the one of the three the agent can't skip.
What would you set up first?: One short, shared AGENTS.md with the real build and test commands, and a test suite the agent can run without help. Those two give an agent a way to check its own work, which matters more than any prompt. Memory, skills, and multi-agent review all build on them, and I'd put the whole stack in place in one sprint rather than drip it in. How long would an agent in your repository take to find the right test command today?

Let's talk.

A 30-minute call, no pitch. We look at your current setup, your stage, and the thing that's bothering you about it. I give a straight opinion on what to change, what to leave alone, and whether the problem is the one it looks like. What's the one thing in your stack you'd fix tomorrow?

Book a call See pricing

Prefer email or phone? hello@netninjas.eu or +31 6 45984313