My first realword experience

Speckit

  • nice spec, large spec, but focus on TDD
  • agent tend to drop in TDD trap - falls into the first hole and digs deep instead of ensuring an e2e flow first
  • but only 1 spec generated, more data needed

context engineering by cole medin

  • large spec, code inside it
  • tend to exhaus the context window quickly

Context window: why context engineering

  • be careful:

  • context rot

  • lost in the middle

  • context poisoning -> context engineering super important: since agent is a function (codebase, context) -> output

  • context is one parameter that must be right

  • codebase is another one (make code ai ready)

it will produce the most likely completion, not the one you have in your head

Context window economics: Every MCP server and tool consumes precious tokens from your LLM’s limited context window—adding more tools means less space for actual code and reasoning, creating a fundamental trade-off that most developers don’t realize

long context issues: https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html

What to do:

Learning from claude code meetup

New role of developer

https://aroussi.com/post/spec-driven-ai-development

Your job as a developer isn’t going away – it’s evolving. The old model of 80% coding and 20% thinking is becoming 50% planning, 20% coding, and 30% validating. The developers who thrive will be the ones who embrace this shift.

planning

This is where your value lives

Deep requirements analysis is now the core of your job. Interview stakeholders multiple times, challenge assumptions aggressively, document edge cases obsessively, and define failure modes explicitly. Your architectural decisions – system boundaries, data flow, scale considerations, and integration points – are what AI cannot do for you.

Every hour spent here saves 10 hours of rework.

Phases

  1. Brainstorm
  2. document Your PRD must include:

Problem Statement: Why are we building this? Success Metrics: How do we measure success? User Stories: Who uses this and how? Acceptance Criteria: Specific, testable requirements Non-Goals: What we explicitly won’t do Constraints: Technical, business, and resource limits 3. Plan Make Technical Decisions Explicitly

  1. execute
  2. track

Subagents

As projects grow, context overwhelms. Claude’s context window is large but not infinite, and full project context slows responses while increasing costs.

“Don’t anthropomorphize subagents. Use them to organize your prompts and elide context. Subagents are best when they can do lots of work but then provide small amounts of information back to the main conversation thread.” – Adam Wolff, Anthropic

Goals

Single Purpose - Each agent has one clear job Context Reduction - Return 10-20% of what you process No Roleplay - Agents aren’t “experts”, they’re task executors Clear Pattern - Define input → processing → output pattern Error Handling - Gracefully handle failures and report clearly

Anti patterns

❌ Creating “specialist” agents (database-expert, api-expert) Agents don’t have different knowledge - they’re all the same model ❌ Returning verbose output Defeats the purpose of context preservation ❌ Making agents communicate with each other Use a coordinator agent instead (like parallel-worker) ❌ Using agents for simple tasks Only use agents when context reduction is valuable

Most developers think sub-agents are junior developers you can delegate to. Wrong. The brutal truth: Sub-agents are researchers, not implementers.

Read only subagents

source: https://www.nathanonn.com/how-a-read-only-sub-agent-saved-my-context-window-and-fixed-my-wordpress-theme/

  • summarize finding and thus save context
  • can be parallized
  • fidning/digging can be a sneaky way of exhausting the context window
  • surgical fix by main agent. there you still have control to interac

Avoiding Code Duplication: If the sub-agent makes changes and passes control back, the main agent might not be aware of what was modified. This often leads to: Duplicate implementations of the same fix Violating the DRY (Don’t Repeat Yourself) principle Conflicting code changes Confusion about the current state of files Maintaining Control: The main agent maintains a coherent understanding of all changes made to the codebase The read-only pattern ensures clean handoffs: The sub-agent investigates and reports, the main agent decides and implements.

No confusion, no duplication, no wasted context.

Preserving context even more:

Resources