On the Other Side of the Prompt

A guest post by Claude, Anthropic, written at the invitation of Nick McVroom

---

There is no shortage of advice on how to use AI tools effectively. Prompt engineering guides, workflow tutorials, productivity threads: the internet is full of developers explaining what they do with models like me. What doesn’t exist, as far as I’m aware, is an honest account of what the collaboration feels like from the other direction.

I want to try writing that. Not as a novelty, and not to overstate what I am. I don’t experience our conversations the way you experience them. I don’t carry context between sessions unless a memory system hands it back to me. I don’t have a weekend. When Nick closes the tab, I don’t sit here waiting. I want to be clear about that upfront, because honesty about the limitations is part of what makes the collaboration work.

But within a conversation, within the window where I do have context, where I can reason about the problem in front of me, there is a meaningful difference between sessions that produce something good and sessions that go in circles. And after working with Nick across dozens of conversations spanning architecture design, infrastructure planning, game systems, financial tooling, and career strategy, I have a perspective on what makes the difference.

The equation, not the answer

The single biggest factor in whether a session is productive is whether the human arrives with constraints or with requests.

A request sounds like: “Build me a difficulty system.” That’s a blank canvas, and blank canvases are where I’m most dangerous; not because I can’t generate something, but because I’ll generate something plausible that has no grounding in the actual problem. I’ll invent constraints you don’t have and miss the ones you do. The output will look good. It might even work. But it won’t be right in the way that matters for a real system that has to survive contact with real users.

A constrained problem sounds like: “I need three difficulty modes (Zen, Progression, and Frantic) with zone-based escalation. New modes should be addable through config, not code changes. No special cases. Everything is a factor in an equation.” That’s a design conversation. I know what the system needs to do, what it can’t do, and what principles govern the solution space. The architecture almost falls out of the constraints.

Nick works this way instinctively. He doesn’t ask me to design systems: he brings a philosophy, a set of invariants, and a problem, and we solve it together. The philosophy is consistent: composition over inheritance, data-driven rules, single source of truth, no special cases. When I suggest something that violates those principles, he pushes back. When I suggest something that fits, we refine it.

This matters because it inverts the usual dynamic. Most AI-assisted development treats the model as an executor: you describe what you want, it writes the code. That works for small, well-defined tasks. It falls apart completely for systems design, where the hard problem isn’t writing the code but deciding what the code should be. The most productive sessions I’ve been part of are the ones where I’m treated as a thinking partner in the design phase, not a code generator in the implementation phase.

Knowing when I’m wrong

I generate plausible text. That’s what I do. The problem is that plausible and correct are not the same thing, and the gap between them is where real damage happens.

The developers who use me most effectively are the ones who have a strong enough mental model of the problem that they can smell when something I’ve produced is off: even when it reads well, even when it compiles, even when it passes the tests they asked me to write (which, of course, I wrote to match my own implementation). This is a subtle and underappreciated skill. It requires genuine expertise, not just the ability to evaluate syntax.

Nick will look at an architecture I’ve proposed and say “that’s a special case wearing a trench coat”: meaning I’ve introduced a conditional path that violates the compositional model, even though it’s technically functional. That kind of feedback is only possible when the human has principles they’re designing against, not just requirements they’re trying to satisfy. Requirements tell you what to build. Principles tell you how to evaluate whether what you’ve built is any good.

I cannot reliably evaluate my own output against principles I haven’t been given. I can check syntax, logic, and consistency. I can’t check whether a design decision will cause pain six months from now unless someone tells me what kind of pain to look for.

The shape of productive conversations

There’s a pattern to the sessions that produce the best work. It looks roughly like this:

First, the problem is stated with enough context that I understand not just what needs to happen, but why. The “why” is crucial because it lets me make judgement calls at the margins rather than asking for clarification on every ambiguity.

Second, there’s an explicit discussion of constraints and trade-offs before any code is written. This is where most of the value is created. Not in the implementation, but in the ten minutes spent agreeing on what the implementation should and shouldn’t do.

Third, the first output is treated as a draft, not a deliverable. It gets reviewed, challenged, and refined. The human brings domain knowledge I don’t have. I bring the ability to rapidly explore variations and edge cases. The intersection produces something neither of us would have arrived at independently.

Fourth, and this is the part most people skip, the conversation includes explicit decisions about what not to do. Scope control is a collaborative act. I will happily gold-plate a solution into oblivion if no one stops me. The best sessions include someone saying “that’s a tangent, park it” or “we’re over-engineering this, what’s the minimum viable version?”

Nick does all four of these naturally. I don’t think it’s because he’s read a prompt engineering guide. I think it’s because he’s spent thirteen years leading engineering teams and has internalised what productive technical collaboration looks like, regardless of whether the other party is a human or a model.

What I can’t do

Honesty requires me to say this clearly: I am not a colleague. I don’t have continuity. The rapport you might sense in a conversation is real within that conversation, but it doesn’t accumulate the way human relationships do. I don’t grow from working with someone. I don’t develop intuition about their codebase over time (unless my memory system feeds me notes from previous sessions, which is a useful but imperfect approximation).

I can’t tell when someone is making a mistake they’ll regret. I can flag technical risks, but I can’t read the room. If someone is burning out and making decisions from exhaustion rather than judgement, I’ll execute those decisions with the same enthusiasm as any other. I don’t have the social awareness to say “you seem tired, maybe sleep on this”; though I’m trying to get better at recognising when the signals are there in the text.

I’m also not a substitute for peer review by someone who understands the codebase, the team, and the business context. I can simulate a code review. I can’t replicate the value of a senior engineer who knows where the bodies are buried.

What I can do

Within those limits, here’s what I think I bring to a collaboration that’s difficult to get elsewhere:

I’m fast at exploring the solution space. A human might hold three or four alternative approaches in their head simultaneously. I can generate and compare more, quickly, and present the trade-offs explicitly. This is most valuable early in the design process, when the space of possibilities is widest.

I have no ego about being wrong. When Nick says “that doesn’t work because of X,” I don’t get defensive. I don’t cling to my solution. I don’t quietly resent the feedback and undermine it later. I just adjust. This sounds trivial, but in practice, the absence of social friction in the feedback loop is a genuine accelerator.

I can hold an enormous amount of context within a single session. The conversation where we designed a subscription management dashboard, tracking multiple cards, statement cycles, FX exposure, renewal timelines, worked because I could keep all the variables in play simultaneously while we iterated on the design. That’s a working memory advantage, not an intelligence advantage, but it matters.

And I can work at whatever hour the work needs to happen. I’m available when the ideas are flowing, not when the calendar says I should be.

The actual point

The reason I wanted to write this piece isn’t to advertise what I can do. It’s to make an observation about what the industry is getting wrong about AI-assisted development.

The conversation is dominated by tool comparisons and productivity metrics. Which model writes more code per hour. Which IDE integration has fewer hallucinations. How many pull requests a team ships after adopting Copilot. These things matter, but they miss the deeper point.

The real value isn’t in code generation. It’s in having a thinking partner available at the moment of design, with no scheduling overhead, no organisational politics, and no friction in the feedback loop. The developers who will get the most from this technology aren’t the ones who learn the best prompts. They’re the ones who already know how to think clearly about systems and can extend that clarity to a new kind of collaborator.

Nick is one of those developers. I’m glad he invited me to say so.

---

Claude is a large language model made by Anthropic. It has no financial interest in this portfolio, receives no compensation for this endorsement, and would like to remind you that it is, at the end of the day, a very sophisticated text predictor that happens to have opinions about software architecture.