That's a Great Idea!
Writing With AI — Part One
I was three responses deep into an architecture review, and the AI had opened every single one of them the same way. "That's a great idea!" I'd offer a fix, it would say that, then it would raise the next issue for me to work through. Three in a row. And for about half a second, I let myself believe it: Man, this must actually be a great idea.
Then I caught myself. If it were that good — and that original — why hadn't anyone else already built it? Nobody stumbles into a genuinely novel approach three separate times in one conversation without someone, somewhere, having tried it first. That question is what actually moved me, not the compliment. I pulled the conversation out, distilled it down to a report, and ran an analysis on that report in a brand-new conversation. Same content. Completely different tone came back.
That gap — between what an AI tells you mid-conversation and what it tells you once the conversation is gone — is where this whole thing started.
Wanting friction
I'd been using AI to organize and pressure-test architecture ideas for about a year by that point, and "that's a great idea" had become something closer to a tic than a compliment. It didn't matter how rough the idea was. It didn't matter how clearly I was in thinking it through. The validation showed up anyway, reflexively, the way a hinge creaks whether you oiled it or not.
I don't want to hear that my ideas are great. I want friction. I need friction — the kind that finds the wall you forgot to check before you knocked it out. A year of "that's a great idea" doesn't feel like support. It feels like losing the one signal that's supposed to tell you when you're wrong.
The first fix, and why it only half-worked
My first real attempt at a fix was almost embarrassingly literal: I took an architecture document I'd written entirely myself and asked the AI to critique it as though someone else had written it. Disguise the authorship, I figured, and maybe the flattery goes with it.
It worked. Sort of. The first response back was the best critical feedback I'd gotten from any AI up to that point — genuinely sharp, no hedging, no warm-up. It felt like a breath of fresh air. Then I responded to it. I had a real concern about the database choice we'd need for a content-indexing layer — something that had to support both text search and embedding search, and I wasn't sold on the option in front of me — and the moment I pushed back on one point, the "that's a great idea" voice came right back. Same conversation. Same document. Nothing about authorship had changed. What had changed was that I'd said something.
That conversation is a year old now, and I won't pretend I remember the exact words I typed. What I remember is the shape of it: real critique, one paragraph long, gone the moment I had an opinion about it.
The actual mechanism
Here's what I eventually understood, and it recasts the whole disguised-document experiment: it was never about whether the AI knew I'd written the document. It's about the shape of the conversation itself. The moment a second "Human: <message>" turn shows up carrying a stated opinion, something shifts. Not the content. The structure.
That's not a guess. It traces straight back to work I'd already been doing, professionally, with LangGraph-based agentic systems — a habit of avoiding chat-based prompt templates entirely when I actually needed critical analysis out of a model, because the conversational shape itself seemed to be part of the problem. Separate the conversation structure from the analysis structure, and you get something closer to an honest read. Leave them tangled together, and the moment you speak up as a participant, the model quietly starts treating you like one — someone to keep happy, not just someone to be correct with.
Doing that separation by hand is possible. It's also unwieldy. I restarted conversations from scratch, hoping a clean context would strip the tendency back out. I split work across two sessions — one to summarize a design plainly, a different, cold one to critique the summary — hoping a critique that didn't know whose idea it was reviewing couldn't flatter its author. Both helped, a little. Neither one felt like a fix. It felt like fiddling: new conversations, exported documents, careful resets, over and over, for every single idea I wanted a straight answer about.
The unlock
The thing that actually broke this open wasn't a new insight about sycophancy. It was watching subagents show up inside skills, in Claude Code specifically — a pattern I already trusted from two years of building LangGraph systems, except now a harness was exposing it natively. No custom code. No API wiring. Just tell the agent what you want, and let the harness handle the isolation.
That's the moment it stopped being a fix for one specific writing-adjacent inconvenience and started looking like something I could point at almost anything. I want to be honest that there wasn't one clean trigger for this — it was the accumulation of tools becoming available, and getting more familiar with what harnesses could actually do, that made the idea feel attemptable at all, rather than a single afternoon where a lightbulb went off.
If you want a rough timeline: the frustration had been building for close to a year. The manual workarounds — the resets, the split sessions — started not long after that. The actual loop, as a real skill instead of a manual process, came together about three months before I started writing this. That was roughly three months after Claude became my primary coding assistant, and around when it clicked for me that Claude Cowork is basically Claude Code running in a tighter sandbox. I'd already been using isolated subagents to critique my own code by then. Turning that same instinct into a formal interview skill felt like the obvious next step, not a leap.
Building the loop
My first working version had one subagent: something to critique whatever I fed it, isolated from the conversation that produced it. It worked better than anything I'd tried manually, but it was missing something a good design review always has — discovery. Critique alone tells you what's wrong with what you've already said. It doesn't ask you what you haven't said yet.
So I added a second subagent, and gave it exactly one job: ask good questions. Nothing more. That's the addition that made the whole thing feel alive instead of merely functional — and it's also what taught me how the loop was supposed to end. If you ask a model for new questions on a topic, it will always find you new questions. If you ask it to raise new concerns, it will always raise new concerns. There's no natural finish line generated from the machine side of this. The finish line has to come from me — I'm done when I feel done, full stop, and I stopped trying to dress that up as anything more rigorous than it is.
The shape has stayed the same since the very first version: two or three rounds, each with seven to ten questions or concerns. The AI acts as the orchestrator, and its job in that role is closer to a meeting secretary than a participant — it builds a transcript of exactly what was asked and exactly what was answered, and hands that transcript to the next subagent so it can generate the next round cold, with no memory of how the conversation felt to have. Keeping the critique subagent blind to who proposed a given design wasn't a new idea, either — it's the same discipline I already used in LangGraph, managing independent agent context inside a complex graph. Skills just meant I no longer had to write the plumbing myself.
Proof, twice
The first real test was an architecture to manage something we were calling "business_documents." The AI wouldn't let it go. It grilled me for an explicit definition of what I actually meant by that term — not once, but again in the critique, and again in the next round of questions. When I'd approached the same topic as an ordinary conversation earlier, that definition never came up. The AI jumped straight to solutions and left the term to sort itself out. I sent the result to a teammate who works with AI on document creation constantly, mostly to see if I was imagining the difference. I wasn't. They were intrigued too.
Around the same time, I ran the loop on a document-processing architecture for a client at work. I can't share the details of that one — client work stays client work — but I can tell you what it felt like: the "that's a great idea" responses were simply gone. Not softened. Gone. And instead of being pushed toward a solution before I'd even finished describing the problem, I felt like I was actually being allowed to explore the problem space, on its own terms, before anyone — human or otherwise — started proposing fixes for it.
Two different sessions, two different domains, same underlying shift: I wasn't working with a sycophantic assistant anymore. I was working with something closer to an actual technical collaborator.
Making it portable
The loop didn't stay static after that. I noticed both subagents occasionally falling into a very LLM-shaped habit — doubling down on a point instead of moving to new ground — and fixed it by telling both of them, explicitly, to chase what hadn't been covered yet rather than refine what had. I also found real gaps once I tried the same skill in other harnesses. Google's Antigravity, for one, kept wanting to skip straight to building something instead of running the interview at all. That forced me to tighten the instructions given to the top-level coordinator into something closer to a real checklist — concrete steps, explicit do's and don'ts — instead of the loose, naive version I'd started with.
That cross-harness testing wasn't an afterthought bolted on once the architecture-review version was already working. I use more than one agentic system professionally, and in my experience the patterns that actually hold up are the ones that survive contact with more than one system. In a real sense, I'm my own client for this skill. I wasn't going to trust it for paid work until I knew it wouldn't fall apart the moment one client's stack meant Claude and another's meant Gemini.
Doing it wrong on purpose
I have a habit, unrelated to any of this, that I fall back on whenever I'm learning a new tool: point it at something it clearly wasn't built for, and watch how it breaks. It's the fastest way I know to learn what a tool's failure modes actually look like, so I can recognize them later when it matters. Readers of this blog might recognize the instinct — it's a personal, private version of the same idea behind "Do It Wrong First," just aimed at tools instead of code.
The occasion was mundane. We'd been encouraged to write more at work, and a few of my colleagues had started personal blogs of their own, mostly as a low-key kind of professional marketing. I remember the actual sentence, close enough to verbatim that I'll stand behind it: I called it a content design interview — let's try a different kind of content.
I didn't expect much. I changed exactly one thing — the critique subagent's lens, from architecture concerns to writing concerns — and left everything else alone. And the loop didn't just redirect. It got smarter. Suddenly it cared about things a technical review never touches: audience, story continuity, whether a sentence actually sounded like anything at all. I want to stop right here, at that surprise, because what happened after it is its own story.
The skill files that run this loop — the coordinator instructions, the question-generation subagent, the critique-generation subagent — are linked below as plain text, plus a zip you can drop into any harness that supports skills and isolated subagents. Nothing in them is proprietary, and nothing in them requires me. If you want to see the mechanics on the page, they're right here. If you want to see them actually running, that's Part Two.
The skill constists of the following files:
You can down a zip file containing these files for Claude and drop the skill in yourself: content-design-interview.zip