Thought Casting

Patterns of thought are the new code

I spent last weekend at Foo Camp, which is an old Silicon Valley tradition, resurrected for the AI moment. This is a group of invited tech weirdos like myself, spending a few days together talking about whatever we wanted to discuss, in this case, almost entirely building things with AI, and what seems to be happening with AI more broadly in society. I followed up with a day of just a smaller group that focused purely on the coding part of it.

A few things stood out to me. One, of course, is that even with this crowd of early adopters, accomplished engineers, and entrepreneurs, there is a persistent sense of being overwhelmed. No one can really keep up with all of the things that are happening, beat by beat. That sounds bad, but it probably isn’t. There was also a lot of sharing of ideas and techniques, and, generally speaking, folks are moving in the same direction.

That was maybe the second surprising thing, how much we all have found in common as we work to understand these tools. Some folks are at earlier stages (someone suggested “moving beyond the prompt” to harnesses. Yep, been working on that for a bit now), but out at the edge, to a large degree, we are all finding the same patterns.

What’s curious to me is that a new kind of “programming” is emerging. It’s hard to describe succinctly, because it’s like building something out of thoughts themselves. Call it “thought casting” maybe. With this kind of work, the thing that is important isn’t the code or the tool, or even the harness you’re using, it’s the pattern of thought itself, the structure.

My “dev machine” is one example of this: the idea of getting more leverage from the system by having it build something small that builds something large. That’s almost like connecting a small gear to a large one. You have that idea in your head about how it will change the rate something moves, but it doesn’t matter what the precise ratio is. The idea of gearing is what matters.

I started to build a pattern library to try to capture some of these ideas. They’re not quite at the same point of refinement as the “fundamental machines” we all know (the lever, the screw, the inclined plane etc), but they’re helpful. I don’t know how large the library will become. I built it to be friendly both for humans and agents, and I am going to start using it myself. A few of the patterns that keep reappearing:

The Clean-Slate Spawn. When you hand a task to a fresh agent, give it an empty context and only the distilled brief, not your whole history. Inherited history carries every wrong turn and reversed decision alongside the signal, and the subagent can’t tell which is which. You spawn accuracy, not background.

The Interviewer. Put a skeptical intake in front of intent, one that asks why before how, refuses to build until it can restate your goal in its own words, and emits a short spec you can reject. It compiles an impulse into a specification. The first prompt is never the spec. It’s the raw material the interviewer works on.

The Ablator. Every scaffolding step was added to patch something a model once couldn’t do, and capability outruns habit, so yesterday’s load-bearing prop is today’s tax. Periodically have a stronger model find steps to delete, prompts to shorten, nodes to merge, then remove them as an experiment. If quality holds, it was tax. If it drops, you just re-earned the step. The graph is pruned, not preserved.

There are more in the library (a sentry that watches a running agent for drift, an adversarial reviewer built to have the independence a self-review can’t, a way to demand proof instead of a status report). These patterns feel like the new form of code, to me - cognitive machines that are generalizable, repeatable, composable, and scalable. The spirit of code, but not code as we have thought of it. The pattern is the thing, “cast” into a shape you can hand to someone else.

Another thing that was striking, talking with folks over the weekend, was how often a firm rule we all had as engineers and engineering leaders has now been reversed or made obsolete. The most striking one is “it’s a waste of time to rewrite something from scratch”. So many times over the decades, I’ve had to dissuade engineers from starting over on a hard codebase. Now, this is often the best thing to do. The old code is a useful spec now in a way it wasn’t, and the machines are so fast and so complete that they won’t miss details. Often they will find new ones.

Combining these things is what makes it a bit disorienting these days. Not only are you working at an entirely new level of abstraction (and a high level at that), but many of your instincts are also eroding or are even incorrect.

Here’s the cautionary tale, though. Twice this week, I’ve gotten bad or dangerous advice from a company’s AI tools (not the one I work for, but I am not going to name names). At one point, following that advice would have caused me to create a dangerous consumable, and in the other, a feature that was actively pushed on me hallucinated something that actually panicked me.

I think this is cargo-cult thinking. Some product teams out there (like the folks I was with) are thinking deeply about the affordances and behaviors of these new tools, and are building really remarkable things (strikingly, the group I was with contained no engineers from this company). But other groups are just imitating, like the Pacific Island “cargo cults” of post-WWII, imitating the form and behavior without deep understanding, to disastrous effect. I use AI and know it to be a powerful, if complex, tool, but the experience with this company’s tools led me to turn off their AI tools permanently. User trust is hard to get back once you lose it.

The people at Foo Camp and the team that nearly shipped me something dangerous are doing the same thing. Both are copying. One is copying the understanding and one is copying only its shape, and from the outside, for a while, the two are indistinguishable.

A lever works whether or not you understand it. A cargo-cult runway does not. That is the whole difference between those two, and it is not a small one.