Digital Pair Therapy

Preface

This isn't a claim that we've solved working with AI. It's what an experienced engineer noticed after spending time with their coding agent. We looked at nearby research. Then we tried a few cheap ideas. Here's what is working for us today.

The pairing that just doesn't work

After decades of working with engineers and architects, I've learned one thing. Being good alone doesn't mean being good together. Two excellent architects might click right away. They might bicker their way to something great. Or they might send the project into a death spiral. Their communication styles, assumptions, workflows, and mental models all interact.

These days I also work with a coding agent. My main coding partner is usually Codex. And we've started to wonder if we're seeing a version of the same thing. That's all we claim: we're wondering, noticing, and experimenting.

We first blamed the obvious things

When work with a coding agent goes badly, there are easy explanations (that sometimes turn out to be correct):

• The model isn't good enough.
• My prompt wasn't good enough.
• It lost context.
• I should try another model.

But we could also see other engineers getting real work done with coding agents. From this, we learned: Success was clearly possible.

That changed the question:

• from "Why doesn't this tool work?"
• to: What are the people who succeed doing differently? And what might I change about how I work with the agent?

So we looked inward. We paid closer attention to how we worked. We looked at what others were doing. And we read nearby research on how people work together, and how people work with AI.

We don't have a final answer. What follows is just what we've found useful so far.

People have been quietly solving this forever

Human teams don't build working relationships only through specs and meetings. We talk. Coffee, lunch, happy hour, conferences, small talk, retrospectives, whiteboard arguments, griping together about ridiculous application programming interfaces (APIs).

Over time, we learn useful things about each other:

• "When Susan says simple, she means operationally simple."
• "When George starts asking questions about the data model, something about our assumptions is bothering him."

Research on human teams suggests this kind of learning is real. Casual, unplanned talk helps teams coordinate and learn.¹ Even small talk shapes how people feel and work, in both directions. One study found it lifted people's mood but also made it harder to focus on work.² Teams that feel safe asking questions and talking about mistakes tend to learn more.³ Researchers even have a name for what two people both know and assume: "common ground."⁴

Research on automation suggests trust changes with experience, and works best when it matches what the tool can actually do.⁵

In our own work, we've noticed something that looks similar with coding agents. But that's our experience, not a study.

Boundary: We do not have evidence that human-agent relationships work exactly the same way. The human literature gives us a few ideas worth trying, not proof.

What's different about the digital partner?

The coding agent doesn't join us for lunch. More important, many of the ways people slowly learn to work together don't happen on their own.

A useful decision found while debugging may stay trapped in one chat. An architecture preference may never get written down, because "we both know it." Context may get squeezed down or disappear. A lesson learned Tuesday may not be there Thursday.

And sometimes the biggest problem is simpler: The human never actually said the thing they thought they had communicated.

The toolmakers say this too. Anthropic's guidance for its coding agent says plainly that the agent "can't read your mind."⁶

That's where the boring stuff comes in. Linear tickets. Architecture Decision Records (ADRs), which are short, numbered notes that record a decision and why it was made.⁷ Project docs. Project instructions. Shared memory files. Tests. We don't treat these as paperwork. We treat them as infrastructure for the working relationship.

View larger

Close

Let's be clear about what "relationship" means here. People tend to respond to technology socially.⁵ We use the word on purpose, but the relationship lives in our habits and in the materials we leave behind: the docs, the ADRs, the memory we give the agent. It isn't about feelings on the agent's side. With that said, on to therapy.

Welcome to Digital Pair Therapy

No couch required. Nobody needs to discuss their childhood. But somebody may need to admit they never documented the authentication decision.

When the pairing feels wrong, don't jump to "this model sucks" or "I'm bad at prompting." Try changing how the pair works.

Ask your partner what comes next

Finish a meaningful chunk of work. Then, before you give the agent its next assignment, ask something that fits the project. Something like: Before I tell you what I think comes next, what do you think we should do next, and why?

Don't tell it your answer first. If you do, you've put your answer into its context, and you may get it back.

We are not testing the agent; we are checking on how the pair is doing. The answer can hint at what made it into the agent's working context, and what didn't.

Anthropic suggests a similar move: asking an open question like "what would you improve in this file?" to surface things you hadn't thought to ask.⁶ That's the toolmaker's advice, not proof. But it's a close cousin.

Don't score the answer. Examine the disagreement.

Say I expect four steps, A to D: A → B → C → D, and the agent proposes A → B → X → D.

X is interesting. Ask why. Some possibilities:

• I left out important information.
• Something important fell out of the usable context.
• We learned something but didn't save it.
• The information exists but wasn't found.
• The agent misread a decision.
• I misread something.
• The agent spotted a problem I missed.
• We need outside docs, research, or advice from people who've done it.
• Both approaches are reasonable.

View larger

Close

The disagreement is information. It's not a grade. It's a clue about where our shared picture split.

Repair the shared understanding

These are experiments, not best practices:

• Ask what assumptions led to the recommendation.
• Ask what information would change it.
• Explain why you prefer your option, instead of just correcting the agent.
• Check whether the decision is written down somewhere that lasts. If it isn't, then this is a good time to do so.
• Write down discoveries that will matter later.
• Try diagrams, examples, tests, ADRs, or prototypes when words aren't working.
• When you're both stuck, bring in another person, another model, official docs, deeper research, or practitioner forums.
• Now and then, ask: "What do you think I'm assuming that I haven't actually told you?"

The loop runs both ways. The agent gets better context and better artifacts to work from. And I learn how to communicate and work more clearly.

One practical reason we do this: autonomy

We're not checking whether the agent can read our mind.

We're asking: Does the project's main goal still guide the small decisions after a pile of work?

That answer feeds a practical decision: How much freedom am I comfortable giving the agent on the next sprint?

When our reasoning lines up well, maybe the next chunk of work gets bigger. When we find a big gap, make it smaller and check in sooner.

Shared reasoning is one signal. The size of the next chunk also depends on verified results, the consequences of a mistake, and how easily we can undo it.

There's a useful comparison in research on automation. The aim there is trust that matches what the system can actually do, and that trust changes with experience.⁵ That research wasn't about coding agents, so it's an analogy, not proof.

Not punishment. Not failure. Feedback. Repair the shared picture, then keep going.

View larger

Close

You're part of the experiment too

Over time, I'm changing too.

I'm learning what information the agent needs. Which phrases cause confusion. What I keep assuming is obvious. Which decisions need to be written down. And when the agent is likely to see something I haven't thought of.

The goal isn't: How do I make the agent work like me?

It's: How do you and your agent get better at working together?

The person, the agent, and the model underneath can all change. These habits are simply how we work today. You can try them with whatever agent you use, and see what happens.

What we know, what we don't, and why we're trying something different

We have not shown that human-agent coding relationships reliably improve over time. We don't know which changes matter most. We don't know how much carries over between models, tools, projects, or people. We're not claiming every bad interaction can be fixed. Sometimes the tool really is the wrong tool.

What we do know, from ordinary engineering and ordinary relationships, is: things that aren't working don't reliably fix themselves when we keep doing them the same way.

So if the working relationship isn't working, maybe the answer isn't more of the same. Try changing something and watch what happens.

What we have is: an observation, some nearby research, our own experience, and a few cheap experiments that seem to help.

Peer-reviewed work already exists, but I don't expect settled answers about how people and today's coding agents work together over time. The tools and practices keep changing. AI can help produce code, experiments, and papers.¹⁰ Careful human review still takes time. At NeurIPS, rapid growth in submissions has made finding enough qualified reviewers harder.¹¹ And peer review is only one step: replication and longer-term studies across different teams are how we learn which findings hold up. More papers don't automatically give us that maturity.

One study followed 71 upper-division computer science students using GitHub Copilot over 10 days. Average trust scores rose, while more students reported a drop after extended use than after the initial session. Participants also described work that still required a skilled programmer.¹² In a preprint reporting interviews with 15 people in one software organization, researchers found accounts of AI helping with individual tasks while coordination problems persisted.¹³ Neither study tested our habits, and neither establishes that they work.

Try Digital Pair Therapy

Next time you finish a meaningful chunk of work with your agent, don't type the next ticket right away.

Ask: Before I tell you what I think comes next, what do you think we should do next, and why?

Then pay attention to the difference.

You might learn something about your agent. Or your docs. Or your architecture.

And sometimes, inconveniently: you might learn something about yourself.

The takeaway is modest: Before you replace your coding partner, try improving how the pair works together.

---

Footnotes

1. Robert E. Kraut, Robert S. Fish, Robert W. Root, and Barbara L. Chalfonte, "Informal Communication in Organizations: Form, Function, and Technology," in Human Reactions to Technology: Claremont Symposium on Applied Social Psychology, pp. 145–199, 1990. https://kraut.hciresearch.info/wp-content/uploads/kraut90-InformalCommInOrgs.pdf ↩

2. Jessica R. Methot, Emily H. Rosado-Solomon, Patrick E. Downes, and Allison S. Gabriel, "Office Chitchat as a Social Ritual: The Uplifting Yet Distracting Effects of Daily Small Talk at Work," Academy of Management Journal 64(5), 1445–1471, 2021. https://doi.org/10.5465/amj.2018.1474 ↩

3. Amy Edmondson, "Psychological Safety and Learning Behavior in Work Teams," Administrative Science Quarterly 44(2), 350–383, 1999. https://doi.org/10.2307/2666999 ↩

4. Herbert H. Clark and Susan E. Brennan, "Grounding in Communication," in Perspectives on Socially Shared Cognition, APA, 1991. https://doi.org/10.1037/10096-006 ↩

5. John D. Lee and Katrina A. See, "Trust in Automation: Designing for Appropriate Reliance," Human Factors 46(1), 50–80, 2004. https://doi.org/10.1518/hfes.46.1.50_30392 ↩ ↩² ↩³

6. Anthropic, "Best practices for Claude Code" (toolmaker guidance; living document, checked Oct 16, 2026). https://www.anthropic.com/engineering/claude-code-best-practices ↩ ↩²

7. Michael Nygard, "Documenting Architecture Decisions," Cognitect blog, Nov 15, 2011. https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions ↩

8. Joseph Wallace, "Five Commonly Misattributed Quotations," MLA Style Center. n.d., accessed Oct 16, 2026. https://style.mla.org/five-commonly-misattributed-quotations/ ↩

9. Quote Investigator, "Insanity Is Doing the Same Thing Over and Over Again and Expecting Different Results," Mar 23, 2017, updated Mar 10, 2025. https://quoteinvestigator.com/2017/03/23/same/ ↩

10. Chris Lu et al., "Towards end-to-end automation of AI research," Nature 651, 914–919, 2026. https://doi.org/10.1038/s41586-026-10265-5 ↩

11. NeurIPS 2025 Program Committee Chairs, "Reflections on the 2025 Review Process from the Program Committee Chairs," NeurIPS Blog, Sep 30, 2025. https://blog.neurips.cc/2025/09/30/reflections-on-the-2025-review-process-from-the-program-committee-chairs/ ↩

12. Anshul Shah, Thomas Rexin, Elena Tomson, Leo Porter, William G. Griswold, and Adalbert Gerald Soosai Raj. "Evolution of Programmers' Trust in Generative AI Programming Assistants," Koli Calling 2025. https://doi.org/10.1145/3769994.3770029 (arXiv 2509.13253) ↩

13. Xiao et al., "AI Hasn't Fixed Teamwork, But It Shifted Collaborative Culture: A Longitudinal Study in a Project-Based Software Development Organization (2023–2025)," arXiv preprint 2509.10956, Sep 13, 2025. https://arxiv.org/abs/2509.10956v1 ↩