Context, and the "stupid zone"
Context management IS the job now . . .
Great news, a number of foundation models now have a 1M token context window. Bad news, it doesn’t matter. Get into the “stupid zone” (typically somewhere above 40-50% of context window) and your super smart intern is going to start to act like someone who stayed up all night taking Adderall for the last two nights and is just starting to crash.
Thinly sliced tasks
Nothing is more important right now than the thoughtful use of context. If you’re building code, not only do you need to decompose the app into small, thinly sliced units of business value, you also need to decompose the process into small, incremental steps. You might have steps for competitive research, positioning, experiment design, creating a Product Requirements Document, creating one or more Architectural Decision Record, creating an ops plan, writing the various pieces of the code, reviewing the code (multiple agentic reviewers for the various dimensions of quality - naming, architecture, cyclomatic complexity, duplication, performance, security, etc) and deploying the app.
Deliberate compaction
Whenever you have a problem, step 1 is to become thoughtful about context management and appropriate compactions. Sure, most foundation models will auto-compact conversations when context usage gets too high, but usually the model is already well into the stupid zone, and secondly a generalized algorithm for compressing context is unlikely to work well for specific types of conversations.
If you’re trying to describe your business goals, vision, mission, culture, values and OKRs are great, compact representations that can be passed to future sessions. If you’re trying to specify code, a robust PRD is a proven artifact for transferring that context from product to engineering. it works equally well for providing the necessary context for an agent in a fresh context window to know exactly what it needs to build.
If you’re not thinking deeply about robust, structured verifiable (typed) artifacts for transferring concise but comprehensive context between steps in your production workflow (from business vision to production code), you’re probably going to prove to yourself that agentic engineers can’t ship good code.
What kinds of documents and formats are you using for persisting intermediate artifacts from business vision to code?