Apply Occam’s Razor: Reducing Overengineering in Luna/Codex Prompts

Summary

The poster recommends explicitly asking Codex to use Occam’s Razor to reduce Sol’s overengineering; the rule can likewise serve as a boundary-setting prompt when Luna handles coding tasks. Comments add important limitations: simplicity does not mean removing module boundaries; clear responsibilities still matter. If there are already many skills, plugins, or conflicting rules, adding this prompt alone may not solve harness problems.

Original prompt

Apply Occam's Razor
- Prefer the simplest design and implementation that fully satisfies the
  current, demonstrated requirements.
- Do not add abstractions, layers, configuration, extension points, dependencies,
  or infrastructure for hypothetical future needs. Introduce them only when
  concrete requirements or repeated patterns justify their cost.
- Before adding code, consider whether the goal can be met by deleting,
  consolidating, or reusing existing code.
- When multiple approaches are correct, choose the one with fewer concepts,
  moving parts, and maintenance obligations, unless evidence shows that a more
  complex approach is necessary.
- Treat patterns and principles as tools, not goals. Do not apply SOLID, design
  patterns, or architectural boundaries in ways that make a small solution more
  complicated than the problem requires.

Corrections in the comments

The goal should be the simplest design that still preserves clear responsibilities and boundaries.

A lot of these prompts work fine in isolation because it’s good advice, doesn’t mean the agent won’t wander or get conte… This is a necessary excerpt; read the original source for full context.

You have to tell it specifically to use Occam's razor. Otherwise, it may still over-engineer even if the instructions ar… This is a necessary excerpt; read the original source for full context.

Usage boundaries

This prompt constrains complexity only; it does not replace project conventions, tests, or security checks. When using it, add task-level completion criteria such as “first inspect the existing implementation, list the affected files, and stop after completing the tests” to prevent the model from misinterpreting “simplest” as removing necessary responsibility boundaries.