Bidirectional Learning in Synthesis Coding: When Human and AI Teach Each Other

Most synthesis coding discussions focus on human → AI: how to configure AI behavior, how to review AI output, how to constrain AI mistakes. This is essential but incomplete. The reverse direction is where the surprises live: what the AI teaches you about your own code, your assumptions, and the edge cases you never thought to name.

Originally drafted in December 2025 alongside the first arc of the synthesis coding series; revised in August 2026.

Introduction

The most powerful insight about synthesis coding isn’t in any technical pattern. It’s this: the best human-AI collaboration is bidirectional. The human teaches the AI through CLAUDE.md, prompts, and review. But the AI also teaches the human: surfacing unknowns, questioning assumptions, and revealing blind spots.

This article explores that bidirectional relationship and the testing discipline that supports it. Most of the synthesis coding series covers the forward direction: how humans direct AI through persistent context, established patterns, and review. This article covers the reverse direction, how AI can guide humans, and how both parties teach each other.

The Socratic synthesis model

Traditional coding assistance is transactional:

Human asks → AI answers
Human requests → AI implements
Human reviews → AI revises

Socratic synthesis is conversational:

Human asks → AI answers → AI asks back
Human requests → AI implements → AI questions assumptions
Human reviews → AI revises → AI surfaces what human missed

The key shift: both parties ask questions.

I stumbled into this pattern while building ownwords, a tool for bidirectional WordPress sync. Early in the project, I’d ask the AI to implement a feature, review the code, and move on. The code worked, but problems surfaced later: edge cases I hadn’t considered, patterns that diverged from the rest of the codebase, silent failures that only appeared in production.

The breakthrough came when I started treating the AI as a collaborator who should challenge my assumptions, not just execute my requests. Instead of “implement this,” I began asking “implement this, and tell me what I might be missing.” Instead of accepting working code, I asked “what could go wrong with this approach?”

The quality of the collaboration changed dramatically. The AI caught a critical gap in image downloading: I’d implemented body images but forgotten the featured_image in front matter. It surfaced inconsistencies in my sidecar file format that would have caused bugs later. It questioned assumptions about URL formats that turned out to be wrong for certain CDNs.

None of these insights required the AI to be smarter. They required me to ask better questions.

Questions AI should ask the human:

"I've implemented this feature. Before we proceed:
- Should I write comprehensive tests?
- What edge cases should we cover?
- Are there existing patterns in the codebase I should follow?"

"I notice this function has no tests. Should I add them?"

"This implementation works, but I noticed the codebase uses a different
pattern elsewhere. Should I match the existing pattern?"

"I'm about to modify this file. I see it was last changed recently.
Should I check if there are related changes I should be aware of?"

Questions human should ask the AI:

"What am I missing?"

"What could go wrong with this approach?"

"What don't I know that I should know?"

"Are there edge cases I haven't considered?"

"What would a senior engineer criticize about this implementation?"

"What assumptions am I making that might be wrong?"

The verification question pattern

After implementing any feature, the AI should proactively ask verification questions. This isn’t about the AI being uncertain. It’s about catching human blind spots.

The missing tests

A recurring moment in AI-assisted sessions, condensed into one exchange. A feature is implemented and working. The human is ready to commit. Then:

Human: "Looks good, let's commit this."

AI: "Before we commit, I want to verify: did you want me to write
comprehensive tests for this feature? I implemented the functionality
but didn't add tests unless you wanted them."

That one question catches the gap: the human assumed tests were included, and they weren’t. Without the verification question, incomplete code gets committed.

The pattern in practice

Encode verification questions into your workflow. After implementation:

Tests: “Should I write comprehensive tests? What edge cases should I cover?”
Documentation: “Should I update the README or CHANGELOG?”
Patterns: “Does this match the patterns used elsewhere in the codebase?”
Edge cases: “What happens when [X] is null/empty/malformed?”
Dependencies: “Are there other files that depend on this that need updating?”

CLAUDE.md guidance for verification questions

Encode the expectation where it persists, in your project’s CLAUDE.md or in a portable skill if it should travel across projects:

### Post-Implementation Verification

After implementing any feature, proactively ask:

1. "Should I write comprehensive tests for this?"
2. "Should I update documentation (README, CHANGELOG)?"
3. "Does this implementation match existing patterns in the codebase?"
4. "What edge cases should we verify?"

Don't assume the human remembered everything. Your job is to catch blind spots.

Learning from the AI: discovering unknowns

The flip side of verification questions is equally important: the human should actively ask the AI to reveal what they don’t know.

The “what am I missing?” pattern

After designing a solution but before implementing:

Human: "I'm planning to implement X by doing Y. What am I missing?
What could go wrong? What don't I know that I should know?"

This uses the AI’s broad knowledge to surface:

Edge cases the human didn’t consider
Existing patterns the human wasn’t aware of
Potential failure modes
Security implications
Performance considerations

The featured image gap

While implementing image downloading for a content sync tool, the AI implemented downloading of images in the article body. It worked. Tests passed. But:

Human: "What am I missing about making local files self-sufficient?"

AI: "The featured_image in YAML front matter also contains a remote URL.
Currently we download body images but not the featured image. This creates
an inconsistency: the article body works offline but the featured image
still points to a remote URL."

This question revealed a gap the human hadn’t considered. The fix was straightforward once identified, but without asking, the inconsistency would have shipped.

The expert mindset paradox

Here’s a subtle but important point: experts should ask more “naive” questions, not fewer.

A novice doesn’t know what they don’t know, so they can’t ask. An expert knows enough to know there’s more to know, so they deliberately ask questions like:

“What assumptions am I making?”
“What would break this?”
“What would a critic say about this approach?”
“What’s the simplest thing that could go wrong?”

The AI becomes a tool for systematic exploration of the unknown, not just implementation of the known.

Mutual teaching: the learning loop

The most sophisticated synthesis coding creates a learning loop where both parties improve:

Round 1: Human provides context → AI implements
Round 2: AI asks verification questions → Human realizes gaps
Round 3: Human asks "what am I missing?" → AI reveals unknowns
Round 4: Human teaches AI (via CLAUDE.md updates) → Better future implementations
Round 5: AI surfaces patterns from across the codebase → Human learns their own code better

Here’s how this played out during a real debugging session. I was fixing timestamp preservation in ownwords: articles were losing their time component when synced back to WordPress. I asked the AI to fix the fetch code to preserve full timestamps.

The AI fixed the fetch code. I tested it. Timestamps were preserved on fetch. Done, right?

Then the AI asked: “Only fetching the correct timestamps won’t be a sufficient fix, right? What happens when you publish back to WordPress?”

I hadn’t thought about it. The AI was right. Fixing the read side without fixing the write side would mean timestamps got preserved locally but lost when published back. The fix needed to be bidirectional.

That single question led to a complete audit of the data flow. The fix ended up touching four files: the API fetch, the HTML scraper fallback, the publish command, and the verification module. Without the AI questioning my assumption that “fix fetch” meant “fix the problem,” I would have shipped a partial fix and been puzzled when timestamps were still wrong after a round-trip.

Where your teaching persists

Bidirectional learning works better when you understand how your assistant’s memory actually behaves. I’ve written about the mechanics separately, in How Claude’s Memory Actually Works and Context Loss and How to Prevent It. The practical implication for teaching: lessons you want the AI to retain belong in persistent files like CLAUDE.md, which load fresh every session, not in conversation history, which gets summarized away as sessions grow. Establish important patterns early, and reinforce them after a long session compacts its older history into a summary.

What the human teaches the AI:

Domain knowledge (business rules, user needs)
Quality standards (what “good” looks like)
Constraints (security, performance, compliance)
Patterns (how this codebase does things)
Context (why decisions were made)

What the AI teaches the human:

Blind spots (edge cases, missing tests)
Existing patterns (code elsewhere that’s relevant)
Best practices (industry standards the human forgot)
Alternatives (approaches the human didn’t consider)
Connections (how changes affect other parts of the system)

CLAUDE.md for bidirectional learning

Document the expectation of bidirectional learning:

### Learning in Both Directions

**AI responsibilities:**
- Proactively ask verification questions after implementing features
- Surface potential issues, edge cases, and blind spots
- Point out when implementation differs from existing patterns
- Suggest tests, documentation updates, and improvements

**Human responsibilities:**
- Ask "what am I missing?" before finalizing designs
- Ask "what could go wrong?" before deploying changes
- Listen when AI raises concerns, don't dismiss them
- Update CLAUDE.md with lessons learned to help future sessions

The goal is not AI autonomy or human control, but mutual improvement.

What praise does not do

One warning before leaving this. Telling an agent that a question was useful does nothing for the session after next. Approval lives inside the conversation and dies with it; only what you write down survives. If you want more of a behavior tomorrow, the reward that matters is an edit to a file, not a compliment.

Testing is where the loop gets proved

The clearest evidence that any of this worked shows up in tests. A verification question costs seconds and prevents a debugging session; an assertion that checks a test’s own assumptions costs one line and buys you a test you can actually trust. The testing practices themselves are a large enough subject that I am not going to try to cover them here. What belongs here is only the reason it belongs to this argument at all: testing is where you find out whether the agent learned what you taught it, and where the agent finds out what you forgot to say.

The collaboration that matters

Bidirectional learning turns synthesis coding from a one-way command structure into a collaborative exploration. The human teaches through persistent context, domain expertise, and review. The AI teaches through verification questions, pattern recognition, and systematic discovery of blind spots.

Tests are where the exchange gets settled. A loop you only describe is a claim; a loop that surfaced a requirement neither of us had stated, and sent me back to the code because of it, is something you can point at.

What makes the loop worth building is that it compounds. Every good question you reward, every discovery you write down, every lesson that graduates from a session into a persistent file raises the floor of the next session. Months into the loop, you are collaborating with an assistant that asks sharper questions about your codebase, and you have become an engineer who asks sharper questions about your own designs. Both of you got there by teaching the other.

The expert synthesis coder’s expertise isn’t diminished by asking the AI “what don’t I know?” It’s enhanced.

Added in the August 2026 revision

Everything above is the December 2025 draft. A few things I know now that I did not know then are kept separate so the original argument stands on its own dates.

The capture mechanism has changed. Project-specific discoveries still live in CLAUDE.md files, but lessons that generalize across projects now graduate into Agent Skills: portable, versioned methodology files that any AI coding assistant can load. That is what Transferable Knowledge, the fifth pillar of synthesis coding, asks of AI-surfaced lessons. The principle is unchanged: what the AI teaches you is only as durable as where you write it down.

On the testing sections, I have since written about what green suites structurally cannot catch, in “All tests pass” is a warning, not a clearance. Read it as the other half of this one.