My work focuses on architecture and modeling. When I explain a domain distinction, correct an assumption, or review an implementation, that judgment can become part of my agent's memory. Over time, its analysis, code generation, and PR reviews increasingly reflect that specialization.
A meat proxy is someone who passes requests to an AI and forwards the output without contributing meaningful judgment. Niklas Gruhn's criticism is fair: if I submit code I don't understand or post review comments I haven't checked, I'm making someone else do that work.
Reducing the developer's role to forwarding requests misses how their expertise carries forward.
I explain why two concepts need separate models. We work through who owns a state transition and which invariants must hold. I reject a plausible implementation because it misrepresents the domain. With memory enabled, the harness can retain those decisions and their reasons, then apply them to later tasks.
The agent inherits useful parts of the developer's expertise as a side effect of doing the work.
The harness is the software around the model: its instructions, tools, context management, and execution controls. Memory carries relevant history across tasks. The model doesn't need to be retrained for that history to affect its output; the harness changes the context it receives. This is the mechanism behind agentic memory.
That inherited context becomes a recognizable working personality: which questions the agent asks, which distinctions it preserves, and what evidence it looks for. In my setup, those habits increasingly reflect my focus on domain boundaries, ownership, and lifecycle.
Take a PR that combines two domain concepts because their fields look similar. If we previously established that those concepts have different owners or lifecycles, that reasoning should inform the review. An agent with that history can investigate whether the proposed simplification breaks the domain model. The developer's earlier explanation contributes to a new decision without having to be repeated in the prompt.
The same domain knowledge carries into implementation. Analysis surfaces the distinction, code preserves it, and review checks it. Memory lets those activities draw on the expertise developed along the way.
Another developer might spend that same time on query planning or concurrency. Their explanations and corrections would build a different body of memory. The model and tools could be identical, while the agents ask different questions, spot different problems, and produce different implementations. They inherit different specializations from their developers.
To get this benefit, know how your harness handles memory. Check whether
it's enabled, what gets retained, how it's reused, and how to inspect or
correct it. In Codex, /memories controls whether a chat can use existing
memories and contribute to future ones; generation happens in the
background. See the
memory documentation.
A short instruction like "review this PR" increasingly draws on architecture and modeling judgments we've already worked through. I still own the work, and my expertise keeps contributing across tasks.
Calling that blind orchestration leaves out the specialization the developer has already built into the system.