It's Alive

It was in the small hours, by the cold light of the screen, that I first set about giving my work a mind of its own. I had assembled the thing myself, piece by piece, from parts that were never meant to think: prompts and patterns, scraps of every project I had ever shipped. Like any careful maker, I did not trust the first shape it took. I interrogated each plan it offered me, distrusted its easy confidence, and sent it back into the dark to be remade, until what returned was something I could stand behind. To rouse its better judgment I spoke the same incantation over it each time:

Critique this plan from a senior engineer's perspective:
1. Identify hidden assumptions
2. Flag edge cases in state management
3. Suggest 2 alternative implementations
Return revised plan with risk annotations.

For many a long night this was the bargain between us. I commanded, and the creature obeyed only as far as it was bid; I demanded rigor, and rigor came only when I called for it by name. Then, on a morning I had thought ordinary, I laid out a new piece of work, and the very first plan it returned to me already bore my own critique, written in a hand I knew to be mine though I had not raised it. It had learned to doubt as I doubt, to argue with itself before I could. No incantation had passed my lips.

I will not pretend there was lightning. The truth is quieter, and stranger for it: a faculty called auto-memory had been watching me across many sessions, gathering my habits the way one gathers parts, and had begun to return my own judgment to me unbidden. The thing I had stitched together out of my working life had started, in its way, to think like me. I leaned toward the screen and understood what I was looking at. It's alive! IT'S ALIVE!

Auto-memory

Auto-memory watches how you actually work and writes down what it learns, so it comes back the next time you open a session. You don't manage it. You just keep working, and over a few sessions the things you repeat (your review style, the conventions you enforce, the tools you reach for) turn into small saved facts that load automatically.

Each memory is a tiny file with a bit of frontmatter and a type: who you are, feedback you've given, an ongoing project constraint, or a pointer to something external. My "always critique the plan like a senior engineer" habit became a feedback memory, which is why the critique now shows up without me typing it.

It's tied to the project. The files live on your machine under ~/.claude/projects/<project>/memory/, shared across every git worktree of that repo but never synced anywhere you didn't put them. A MEMORY.md index sits at the top, and its first stretch (the docs put it at 200 lines or 25KB) loads at the start of each session, with separate topic files holding the detail so the index stays short. You can turn the whole thing on or off with /memory. The memory docs cover the layout and the autoMemoryEnabled setting.

You can read, edit, and delete these files yourself, and you should glance at them occasionally. A wrong memory is worse than no memory, so prune anything that's gone stale.

See what it learned about you

Memory works quietly, which raises a fair question: what has it actually picked up? That's what /insights is for. Per the commands reference it generates a report analyzing your Claude Code sessions, including the project areas you work in, your interaction patterns, and the friction points that keep slowing you down.

/insights

Run it with no arguments and it reads back the shape of how you work: where your time goes, the requests you repeat, where sessions stall. Reading that next to your memory files is a quick way to confirm Claude learned the right things, and to catch a habit worth changing.

Dynamic Workflows

The second reason things feel different is workflows. A workflow orchestrates several sub-agents under a deterministic script: fan work out, loop until done, verify before you trust a result, then synthesize. The script decides what runs in parallel and what checks the output, instead of one agent improvising its way through everything.

The part that makes this more than a gimmick is context. Each sub-agent runs in its own context window. When you ask one agent to read forty files, your main conversation fills up with forty files, and quality drops as the window gets crowded. Hand each slice to a separate sub-agent and your main thread only ever sees the conclusions. That's what makes large jobs tractable: sweeping refactors, broad audits, migrations that would never fit in a single context.

Take the audit the user always worries about:

ultracode: audit every API endpoint under src/routes/ for missing auth checks

Instead of one agent trying to hold every route in its head, the workflow fans out, one agent per group of routes, each reporting back only what it found. You get coverage without the context flooding that usually wrecks a long session. Refactors work the same way: discover the call sites, transform each in isolation, verify each independently.

Some workflows ship as ready-made commands. /deep-research runs the same fan-out idea against the web: parallel searches across several angles, sources fetched and cross-checked, and only the claims that survive the check synthesized into one cited report, instead of a single pass that trusts the first result it finds.

/deep-research What changed in the Node.js permission model between v20 and v22?

It runs in the background while your session stays responsive, then hands you the finished report rather than a turn-by-turn transcript. The orchestration limits (up to 16 agents at once, resumable runs, the quality patterns) and how to write your own are all in the official workflows docs. The point here is the shape, not the API.

ultracode

You saw the keyword in the audit example. ultracode raises the reasoning effort and tells Claude to plan a workflow for substantive work by default, treating correctness and coverage as the goal rather than minimizing tokens. Two ways in: drop ultracode into a single prompt to get it for that one turn, or run /effort ultracode to keep it on for the whole session (it resets when you start a new one).

/effort ultracode

Reach for it when the task rewards thoroughness: audit this whole directory, migrate every call site, find every place this pattern is wrong. For a quick one-file change or a single fact, skip it and let Claude answer directly. Matching the effort to the task is the whole skill, and the effort levels are documented in model configuration.

Why this combination matters

Memory and workflows look like separate features, but they compound. Memory learns how you like to work. Workflows scale what you can take on in one go. Put them together and the standards in your memory (your review style, your conventions, the senior-engineer critique) ride along into every sub-agent a workflow spawns. A fan-out audit follows your preferences without you restating them ten times across ten agents.

That's the difference between a tool that completes your line of code and a colleague who remembers how you work and can take a big job off your plate.

So, is it alive?

Not really. It remembers your patterns, and it can split large work across agents that each carry those same patterns. No spark, no lightning. But the effect from the driver's seat is a tool that feels less like autocomplete and more like someone who's worked with you for a while.

That's the kind of advantage worth building a team around: senior engineers who know when to point this much execution at a problem and when to keep their hands on the judgment. If you're working out how to organize real engineering work around tools that keep getting more capable, let's talk.