u/0_2_Hero

The problem: when researching files, Codex often pulled thousands of lines of unrelated code into context.

That polluted the context window, made the model worse at the actual task, and caused me to hit usage limits much faster.

Codex and other LLM coding agents use shell commands to inspect files. They often try to protect context with line limits, but line limits are not safe.

A simple command like:

head -n 20

can still blow up your context if the output is one giant line.

I hit this with a 5MB+ SQLite file that had no newline.

The fix: byte-cap unknown command output, I added to my AGENTS.md(short version):

## Command Output

Protect context usage. **Any command with unknown or potentially large output must be byte-capped.**

Default pattern:

```bash
COMMAND 2>&1 | head -c 4000
```

Another big saving was not to run tests, type checks, and full validation suites after every single task, I added a rule about when to run validations.

I did a few Evals on this prompt on tasks like discover, web development, and tasks like "understand this repo before we get started", and the context saving is around 50%, sometimes more, sometimes less.

I put the full AGENTS.md context engineering prompt that I use when coding in a repo, including rules for command output, using subagents, reducing complexity, and validation rules.

I also changed my system prompt in codex, using a slightly modified version of GPT5s base prompt but stripped unrelated things like coding video games, and web design instructions(it sucks at web design), you can view that here: AGENTS.md patterns for coding agents

After building a lot of marketing websites and reviewing conversion data, I’ve become less convinced that “beautiful” websites are what actually drive leads.

Visual design matters, but I’ve seen the highest-performing sites usually have a few boring traits:

- Clear headline

- Obvious CTA

- **Familiar page structure**

- Minimal animation

- Clear service/location targeting

- No clever navigation

- Real photos, reviews, and proof close to the CTA

The sites that look impressive in a portfolio often add friction for real users. Visitors usually are not studying the design. They are trying to answer basic questions:

Can this company do what I need?

Do they serve my area?

Can I trust them?

How do I contact them?

My current view: the best local business websites are simple, fast, familiar, and specific. “Simple” does not mean cheap-looking. It means the user never has to think about what to do next.

Here’s an example of a “simple” design for a general contractor and home remodeling company in Bellevue, Washington: https://www.thewalldoctor.com