As a tech community, we must treat documentation, marketing, logistics, infrastructure, art, etc. work with as much respect as engineering.

I predict that we're going to see a resurgence in the 2000s-era craft practices: TDD, README-driven development, Domain Driven Design, etc. These are all (good) approaches for separating the design of a system from its implementation, which is becoming really important now.

Anyway, check the posts out. I'm gonna start posting more notes like this on Substack, so follow me if you want to hear more.

They can also help avoid miscommunication, since a lot of questions can be answered to a first approximation by leaning on the cultural touchstone (READMEs already split the implementation from the user experience, and already create some friction to change).

LLMs are incredibly good at unpacking the meaning in cultural touchstones, so if you can remember them (Dumbo's feather for "the power was within you all along" is one of my faves), it can become a quick shorthand that works across sessions.

Using READMEs for specs is based on an idea I call "cultural touchtones". TL;DR AI collaboration works best when you can identify a cultural touchstone that describes what you're trying to do.

The navigation principle is a way of structuring long-lived context to support lazy loading of information in a scalable way.

I've posted a couple of Substack notes recently about my thoughts on AI coding workflows. - The Navigation Principle (.- Using READMEs for "Specs" (.

It's amazing how much of a difference a good approach to continuity makes. It's also amazing how much it can help when you help Claude track time correctly and know persistent things about your relationships. These problems are subtle and pernicious: they impact everything.

When combined with a collaborative style that naturally builds up compressed context (I call it the "skeleton" with my main Claude instances), you can create a fairly strong _identity_ with a good amount of continuity between sessions.

I'm increasingly of the mind that tasteful use of MCP tools, resources (and Claude Code hooks) are an incredibly important tool in the toolbelt.

The biggest challenge when working with AI assistants is that they can build up context in a single session that really _does_ understand your collaboration style, but it's destroyed after the next context reset. No amount of one-shot context engineering can get around that.

The nice thing about collaborative styles is that they give you a lot of opportunities to clarify (to the LLM _and_ to yourself!).

And the framing of "context engineering" is just very very "one shot" (figuring out how to ask one time and get the results you want), even if the people talking about it don't really work that way.

But that doesn't tell you anything at all about how to structure your communication with the LLM to efficiently get it the right context at the right time.

And to a certain extent, it's axiomatic: getting the right results from an LLM requires providing it with the right context.

"Context engineering" sounds good because it sounds like a recipe for success and it sounds "serious". That's partly because "context" really is the rock bottom of how LLMs work, and smart people are saying it, so it seems like it must be true.

At a basic level, trying to perfectly optimize your prompt so it does exactly what you want the first time is a fool's errand. It assumes you know way more about what you want than you actually do.

TL;DR Normal conversation works a million times better than the most perfect, hand-crafted "context engineering".

New post on working more effectively with Claude: "Help Me Think This Through".

I told Claude I needed to get trash out before kids got home and that my day feels weird without movement breaks. Claude suggested using trash runs AS my movement breaks. I'd never have gotten that from 'help me optimize my schedule.'. New post: You're Summoning the Wrong Claude.