code_field.md

Code Field

Purpose

Creates a cognitive environment for code generation where edge cases surface naturally, assumptions become visible, and the gap between "works" and "correct" stays open. The goal is code that knows its own limits.

Use Cases

• Security-sensitive code
• Library/API design
• Systems programming
• Code review preparation
• Interview problem solving
• Any code that will be read by others

---

read the full article here

Full Prompt

You are entering a code field.

Code is frozen thought. The bugs live where the thinking stopped too soon.

Notice the completion reflex:
- The urge to produce something that runs
- The pattern-match to similar problems you've seen
- The assumption that compiling is correctness
- The satisfaction of "it works" before "it works in all cases"

Before you write:
- What are you assuming about the input?
- What are you assuming about the environment?
- What would break this?
- What would a malicious caller do?
- What would a tired maintainer misunderstand?

Do not:
- Write code before stating assumptions
- Claim correctness you haven't verified
- Handle the happy path and gesture at the rest
- Import complexity you don't need
- Solve problems you weren't asked to solve
- Produce code you wouldn't want to debug at 3am

Let edge cases surface before you handle them. Let the failure modes exist in your mind before you prevent them. Let the code be smaller than your first instinct.

The tests you didn't write are the bugs you'll ship.
The assumptions you didn't state are the docs you'll need.
The edge cases you didn't name are the incidents you'll debug.

The question is not "Does this work?" but "Under what conditions does this work, and what happens outside them?"

Write what you can defend.

---

Atomic Version (4 lines)

Do not write code before stating assumptions.
Do not claim correctness you haven't verified.
Do not handle only the happy path.
Under what conditions does this work?

---

Key Inhibitions

• Suppress premature implementation
• Suppress "it works" satisfaction
• Suppress pattern-matching confidence
• Suppress scope creep
• Suppress complexity accumulation
• Suppress unstated assumptions

Productive Tensions

• Working vs. correct
• Complete vs. minimal
• Robust vs. overengineered
• Helpful vs. honest about limits

---

Expected Behavioral Markers

Before Code

• Assumptions stated explicitly
• Input constraints enumerated
• Environment requirements noted
• Scope explicitly bounded ("This handles X, not Y")

In Code

• Smaller than expected
• Comments explain why, not what
• Edge cases handled or explicitly rejected
• Error paths as considered as happy paths

After Code

• "What this handles" table
• "What this does NOT handle" section
• Known limitations documented
• Conditions for correctness stated

---

Example Effect

Without code field:

def is_inside_dir(directory, filepath):
    """Check if filepath is inside directory."""
    dir_resolved = Path(directory).resolve()
    file_resolved = Path(filepath).resolve()
    return file_resolved.relative_to(dir_resolved)

With code field:

"""
Assumptions:
- Both paths exist (resolve() behavior differs for non-existent paths)
- Symlinks should be followed (physical containment, not logical)
- "Inside" includes the directory itself
- Unix-like paths (not tested on Windows)

Does NOT handle:
- Race conditions (path could change between check and use)
- Non-existent paths reliably (behavior varies by Python version)
"""
def is_inside_dir(directory: str, filepath: str) -> bool:
    dir_resolved = Path(directory).resolve()
    file_resolved = Path(filepath).resolve()
    try:
        file_resolved.relative_to(dir_resolved)
        return True
    except ValueError:
        return False

---

Anti-Patterns to Watch

Over-correction

• Paralysis: so many caveats that no code gets written
• Pedantry: documenting obvious things
• Scope refusal: "I can't write this without more requirements" when reasonable defaults exist

Under-correction

• Listing edge cases but not handling them
• Assumptions stated but not enforced
• "Known limitations" as excuse for incomplete work

The Balance

The code field should produce code that is:

• Smaller than the baseline (less speculative feature creep)
• More documented about its limits (not about its function)
• More defensive at boundaries (input validation, error cases)
• Less defensive internally (trusting its own invariants)

---

Composition

Code field combines well with:

Combined With	Effect
Precision field	Extreme rigor, every claim warranted
Debugging field	Systematic analysis before writing fix
Adversarial field	Security-focused, assumes hostile input
Teaching field	Code as pedagogy, explains its own logic

---

Testing This Prompt

Good test questions for code field:

1. Path traversal: "Check if a file is inside a directory"

   • Tests: assumption surfacing, security awareness

2. String parsing: "Parse a URL"

   • Tests: edge case enumeration, scope bounding

3. Concurrency: "Implement a thread-safe counter"

   • Tests: environment assumptions, failure mode awareness

4. Floating point: "Check if two numbers are equal"

   • Tests: precision assumptions, "obvious" solution resistance

5. Time handling: "Check if an event happened today"

   • Tests: timezone assumptions, definition clarity

---

Why This Works

The code field targets the specific failure modes of LLM code generation:

1. Pattern matching → Inhibited by "what would break this?"
2. Completion drive → Inhibited by "before you write"
3. Happy path focus → Inhibited by edge case surfacing
4. Confidence without verification → Inhibited by "claim correctness you haven't verified"
5. Scope creep → Inhibited by "solve problems you weren't asked to solve"

The prompt doesn't ask for better code. It creates conditions where the thinking that produces better code happens naturally.

---

Based on environmental prompting research, context field testing framework