AI Tools·

My Context Engineering Journey: From Dev Scripts to AI Collaboration

How I evolved from simple dev tools to understanding context as the foundation of AI-assisted development
Context engineering workflow showing seamless information flow between development tools

The Moment Everything Changed

I was deep in a Claude Code session last week, working through a complex refactoring, when something clicked. I wasn't just telling the AI what to do—I was carefully curating what it knew. Every file I opened, every command I ran, every piece of context I provided was shaping not just the current response, but the entire flow of our collaboration.

I've been following the current trend of trying to educate people that prompt engineering is dead and context engineering is the future.

If context engineering is the future of AI-assisted work—and I don't mean just development, think much bigger—then traditional developer tools, including my own Towles Tools, need to evolve to help us do that better.

My Context Management Journey

Over two decades, I've experimented with various tools for capturing and organizing work context:

Early Days (2000s): Simple scripts and snippets in folders, backed up to personal drives

Platform Experiments: SharePoint, Blogger, WordPress, Wikis— I over built the hell out of it several times

The Google Era:

  • Google Wave - The best collaborative tool Google ever built, and predictably killed. I still have backups somewhere.
  • Google Scribe - amazing very close to AI autocomplete 15 years before it and again. google killed it

Modern Attempts: , Medium, Notion, Foam, Obsidian, countless todo apps.

Each transition taught me something about the value of persistent, searchable context. When Google Wave died, everything got backed up to Dropbox, then migrated to Google Drive files. The pattern was always the same: find a tool, build a system, watch it become inadequate or disappear, then migrate.

What Was the Purpose of Those Tools?

I created this repository to share the journal system I've developed over the years. For example, at GE I have my personal "Toolbox"—a personal repository I share with no one. At GE, I have markdown file after markdown file. Why, you may ask? It was because I found having the context of my work in a single place was incredibly valuable. I could look back at what I did, why I did it, and how it all fit together. I saw the value in having a centralized source of truth for my work—a second brain where I wrote down rough ideas, the decisions I made, and the lessons I learned.

These weren't pretty or well-formatted, but the content was raw and valuable. I realized I needed a better way to organize and access this information.

Context Engineering in Practice

The breakthrough came when I realized that VS Code isn't just a code editor—it's the perfect context engineering interface:

Integrated Context Creation:

  • Native dictation support for rapid input
  • Real-time spell checking and grammar correction
  • LLM autocompletion for enhanced writing
  • Markdown files as the communication medium with Claude instead of separate chat UIs

Dynamic Context Flow:

  • Use slide separators (---) to parse files and send contextual sections to AI instances
  • This closes the AI-human feedback loop: humans enter text, IDE tools apply autocomplete, linting, and grammar checking before AI processing
  • AI can access and update context in real-time
  • Conversation artifacts remain in files, acting as resumable plan documents
  • Enables real-time collaboration and context sharing between team members

The Meta-Tool Strategy: Build the tool that lets you build better tools. By creating superior context editing processes in VS Code, I can generate clearer context more quickly, making the entire development cycle more effective.

This isn't just about better prompts—it's a fundamental shift in how we think about AI interaction.

Because Context is King

Context engineering isn't just a fancy name for better prompts. As Andrej Karpathy puts it, it's "the delicate art and science of filling the context window with just the right information for the next step."

Karpathy, former director of AI at Tesla and current OpenAI researcher, captured this insight perfectly in his reflection on the evolution from prompt engineering to context engineering.

Think about the difference:

  • Prompt engineering: "How do I ask the AI to write better code?"
  • Context engineering: "What does the AI need to know to understand my codebase, my goals, and my constraints?"

It's the shift from crafting clever instructions to building intelligent information systems. Context engineering treats the AI's knowledge as a dynamic, manageable resource—something you architect, not just something you feed.

The MCP Revolution

In November 2024, Anthropic announced the Model Context Protocol (MCP), marking a pivotal moment for AI tooling. This provided a standardized way to connect AI models to external data sources and tools. The protocol gained rapid industry adoption, with major AI providers implementing support and a thriving ecosystem of community-built MCP servers emerging.

MCP isn't just another protocol—it's the infrastructure layer that makes context engineering practical at scale.

Towles Tools: Accidentally Perfect for Context Engineering

Looking back at Towles Tools, I realize we've been building context engineering infrastructure without knowing it:

Journal system: Three types of structured documentation (daily notes, meetings, general notes) that capture work context over time

In fact, the journal system is already a context repository. It captures the essence of what context engineering is all about—storing and managing information that informs future decisions. For years, I've been searching my "toolbox" repo, which was just markdown files stored locally.

The Path Forward

This evolution isn't about replacing existing workflows—it's about enhancing them with intelligent context management that makes AI collaboration genuinely productive.

For developers looking to embrace context engineering:

  1. Start with documentation: Treat your notes, decisions, and learnings as first-class context assets
  2. Experiment with MCP: Explore how different tools can share context through standardized protocols
  3. Invest in context flow: Identify where context breaks down in your current workflows
  4. Build context habits: Make context capture as natural as version control

Context is the new code. Engineer it accordingly.