From Behavioral Adaptations to Context Engineering

A while ago I was experimenting with a concept I labeled “Behavioral Adaptations” - the idea that AI systems work better when they can dynamically modify their behavior based on performance feedback rather than relying on static instructions. I even mentioned this in a Hacker News comment, wondering if there was already a name for what I was building.

Turns out I was tapping into something the industry calls “context engineering.” But that realization led me down a rabbit hole that changed how I think about working with AI entirely.

The Broader Conversation

Back in 2022/2023 when I started messing around with LLMs, “prompt engineering” was everywhere. People were literally getting hired for their ability to talk to ChatGPT. Which honestly felt ridiculous - how specialized could typing into a text box really be?

But then I’d watch someone coax incredible output from GPT-3 with the right incantation, while my straightforward requests got garbage. So clearly something was happening. The weird part was how much of the popular advice felt like psychological manipulation - threatening the AI, bribing it with imaginary money, roleplaying elaborate scenarios. It worked, but it felt wrong.

I think I was hung up on expecting these things to be oracle-like. They’re not. They’re prediction engines that pattern-match based on what you feed them. Once I internalized that, everything changed.

What I didn’t realize at the time was that my behavioral adaptations experiments were actually exploring advanced principles of what’s now called “context engineering” - dynamically modifying not just what information the AI sees, but how it’s instructed to process and act on that information.

Industry Leaders Thinking Similarly

Turns out I wasn’t the only one moving in this direction. Tobi Lutke recently described context engineering as “the art of providing all the context for the task to be plausibly solvable by the LLM.” Andrej Karpathy went deeper, calling it “the delicate art and science of filling the context window with just the right information.”

Phil Schmid and Simon Willison have written about why this framing makes more sense than “prompt engineering.” Reading their work helped me understand that what I was experimenting with was part of a larger shift in how we think about AI system design.

Traditional Prompt Engineering vs. What I Was Actually Doing

graph LR
    A[Write Initial Prompt] --> B[Get Poor Result]
    B --> C[Try Different Prompt Tricks]
    C --> D[Still Poor Result?]
    D -->|Yes| E[More Prompt Variations]
    D -->|No| F[Done]
    E --> C

This was the old approach - fiddle with wording, try different “tricks,” hope something works.

The Context Engineering Approach I Evolved Into

graph LR
    A[Identify Task] --> B[Gather Relevant Context]
    B --> C[Include Files/Data/History]
    C --> D[Send to AI]
    D --> E[Analyze Output]
    E --> F[Edit Previous Message]
    F --> G[Add Missing Context]
    G --> D
    E -->|Good Result| H[Done]

After spending way too many hours daily working with these models, my workflow evolved into something completely different. When I get crappy output, I don’t fiddle with prompt phrasing anymore. Instead, I go back and surgically add the missing pieces - files the AI should have seen, background it’s missing, examples that clarify what I want.

It’s iterative information curation. The AI tells me what it doesn’t understand through its mistakes, and I fix the context. Sometimes I’ll upload an entire project directory, relevant docs, conversation history, whatever. I’m basically building the AI’s working memory for the specific task.

But what I was experimenting with in behavioral adaptations took this further - not just providing better information, but dynamically adjusting how the AI processes that information based on what works and what doesn’t.

The Key Difference

graph LR
    subgraph "Prompt Engineering"
        A[Focus on<br/>Prompt Wording] --> B[Trial & Error<br/>with Phrases]
    end
    
    subgraph "Context Engineering"
        C[Focus on<br/>Information Architecture] --> D[Systematic<br/>Context Assembly]
    end
    
    subgraph "Behavioral Adaptations"
        E[Focus on<br/>Dynamic Behavior] --> F[Adaptive<br/>Context Modification]
    end

The shift from trying different prompt phrasings to systematically engineering context feels like the difference between debugging by adding print statements versus actually understanding your program’s state. And behavioral adaptations might be exploring the next step - systems that understand and modify their own state.

What I’m Still Exploring

This isn’t about finding magic incantations or even just better information architecture. It’s about building systems that can learn and adapt their behavior based on real-world performance. My behavioral adaptations experiments suggest there might be something interesting here - AI systems that don’t just access the right information, but dynamically adjust how they process and act on it.

What’s interesting is that while everyone was debating whether prompt engineering was real, I found myself exploring what might be adjacent to context engineering. The industry is still figuring out where this all leads, but the early experiments feel promising.

Whether this becomes a distinct discipline or just another aspect of context engineering remains to be seen. But the shift from static instructions to adaptive behavior feels significant - like we’re moving from programming AI to collaborating with systems that can learn and improve their own performance.

Edwin

Menu

Context Engineering