Pair Programming with AI in Golang: Claude Code, Cursor, Copilot

 1Model A: Developer as Driver, AI as Navigator
 2
 3Developer: writes code
 4AI: "The error handling here is lacking. Also check nil before using order."
 5Developer: "Ah right, thanks"
 6AI: "Also, this function is already > 50 lines — consider extracting a method"
 7
 8Model B: AI as Driver, Developer as Navigator
 9
10Developer: "Implement the CancelOrder usecase per this spec: @specs/order/cancel-order.md"
11AI: writes code
12Developer: "Hmm, this part doesn't handle concurrent cancel correctly"
13AI: "You're right. Add SELECT FOR UPDATE? Or optimistic locking?"
14
15Model C: Turn-based (most effective for complex features)
16
17Developer: "We're going to implement a flash sale. I propose this approach: [...]"
18AI: "That approach is solid, but there's a concern: [...]. Consider: [alternative]"
19Developer: "OK, I agree with the alternative. Start from the domain entity first."
20AI: [implements domain entity]
21Developer: [reviews, tweaks minor things]
22AI: [implements usecase]
23Developer: [reviews, approves]
24AI: [implements repository + handler]
25Developer: [final review, runs tests]

 1# An effective session opener (not straight to the task):
 2
 3claude
 4> Good morning! Our pair session today:
 5>
 6> 1. Context: I'm implementing the flash sale feature
 7>    for Santekno Shop (see CLAUDE.md for context)
 8>
 9> 2. Today's target:
10>    - Finish the FlashSale domain entity and the ClaimVoucher usecase
11>    - Start the FlashSale repository (PostgreSQL)
12>
13> 3. Current state:
14>    - Domain entity: 50% done (struct + basic methods exist)
15>    - Usecase: not started
16>
17> 4. Blockers I have:
18>    - Not sure about the concurrency approach for the claim counter
19>      (Redis INCR vs PostgreSQL SELECT FOR UPDATE vs optimistic locking)
20>
21> Before we start coding, help me think through the blocker in point 4.
22> Which approach fits this case best?

 1claude
 2> I'm stuck on a design decision. Let me explain:
 3>
 4> Problem: A flash sale voucher must be atomic — no overselling.
 5> 100 vouchers, possibly 1000 concurrent requests.
 6>
 7> Approaches I'm thinking of:
 8> A. PostgreSQL SELECT FOR UPDATE:
 9>    Pro: simple, consistent
10>    Con: row lock, could become a bottleneck
11>
12> B. Redis INCR with an atomic counter:
13>    Pro: fast, designed for this
14>    Con: must handle the Redis-down scenario
15>
16> C. Kafka-based queue:
17>    Pro: can handle spikes
18>    Con: high latency (the user waits)
19>
20> I lean toward B because of high concurrency, but I'm worried about the
21> Redis failure scenario. What do you recommend?
22
23# The AI doesn't immediately implement — it helps evaluate the tradeoffs
24# The developer still decides, the AI helps think through
25
26# The AI response is usually:
27# "For a time-sensitive flash sale, the Redis approach (B) is indeed
28#  more appropriate. For the Redis failure scenario, consider:
29#  1. Circuit breaker: if Redis is down → fall back to PostgreSQL SELECT FOR UPDATE
30#  2. Redis Sentinel or Cluster for HA
31#  3. A Lua script for atomic check-and-increment..."

 1# For a Go developer new to patterns:
 2
 3claude
 4> I'm learning the context package in Go. Implement CancelOrder
 5> with proper context handling, AND explain every decision you make.
 6>
 7> Specifically explain:
 8> - Why context.WithTimeout, not context.WithDeadline?
 9> - Why must ctx be passed to the pgx.Pool query, not context.Background()?
10> - What happens if ctx is cancelled in the middle of a DB transaction?
11>
12> Implement while explaining. I want to understand, not just copy code.
13
14# Claude will generate code WITH commentary:
15# "We use context.WithTimeout because we know the maximum acceptable
16#  duration (5 seconds), not an absolute deadline time..."

 1Developer: "Implement CancelOrder with retry logic built in"
 2
 3AI: "Implementation with retry:
 4
 5func (uc *CancelOrderUseCase) Execute(...) error {
 6    for i := 0; i < 3; i++ {
 7        err := uc.tryCancel(ctx, input)
 8        if err == nil { return nil }
 9        time.Sleep(time.Duration(i) * time.Second)
10    }
11    return err
12}
13"
14
15Developer: "I disagree with retry in the usecase layer.
16           Retry should be in the infrastructure layer (HTTP client, Kafka publisher).
17           The usecase must be idempotent — the caller decides on retry."
18
19AI: "You're right. This violates separation of concerns. Retry logic
20     should be in the caller (HTTP retry middleware or Kafka consumer retry).
21     The usecase just needs to return a specific error:
22     - ErrDBTemporaryUnavailable for a db timeout (retriable)
23     - ErrOrderAlreadyCancelled for a business rule (not retriable)
24     The caller can decide based on the error type."
25
26Developer: "Exactly. Update the implementation without retry, but make sure
27           the returned error types are clear about retry-ability."

 1# Pattern for a complex problem that needs extended thinking:
 2
 3claude
 4> We have a serious problem in production:
 5> A flash sale voucher was oversold 15x (1500 vouchers claimed, max 100).
 6>
 7> System: Go, PostgreSQL, Redis.
 8> The race condition happens when the Redis INCR and the PostgreSQL INSERT
 9> are not atomic.
10>
11> Let's pair debug this:
12>
13> 1. First we explain the current implementation
14>    @internal/usecase/order/cancel_order.go
15>
16> 2. Then we trace the scenario that causes the oversell
17>
18> 3. Then we propose and evaluate solutions
19>
20> 4. Then we implement the best solution
21>
22> Start from step 1 — trace the current code together.
23
24# The AI will:
25# - Read the code
26# - Identify the race window
27# - Propose a fix (a Lua script for atomic check-and-increment)
28# - Implement the fix
29# - Propose a test that reproduces the bug and verifies the fix

 1# AI as a "second opinion" partner:
 2
 3claude
 4> I want to review a teammate's PR before approving.
 5> Help me think through this:
 6>
 7> [paste PR diff or a specific section]
 8>
 9> I have concerns about:
10> - Line 45: error handling that feels off
11> - Line 78: this looks like an N+1 query?
12>
13> But I'm not 100% sure. Help me validate my concerns.
14> If the concerns are valid, how do I explain it to the teammate constructively?

 1Pair programming with AI can be very engaging but needs time boxing:
 2
 3Recommended time structure:
 4
 5FOCUSED PAIR SESSION (2-3 hours):
 6  0:00-0:10  Warm up: context setting, blockers
 7  0:10-0:40  Block 1: implement feature A
 8  0:40-0:50  SHORT BREAK + review what was built
 9  0:50-1:20  Block 2: implement feature B
10  1:20-1:30  Break
11  1:30-2:00  Block 3: tests, review, cleanup
12  2:00-2:15  Session wrap: commit, document decisions
13
14SOLO PAIR SESSION (45-60 minutes):
15  0:00-0:05  Context setting
16  0:05-0:40  Focused implementation
17  0:40-0:50  Review and commit
18  0:50-0:60  Quick debrief: what was learned?
19
20Warning signs that the session needs to end:
21  - Already > 3 hours without a significant break
22  - The AI starts to "forget" context (responses less relevant)
23  - The developer feels too passive (the AI does all the thinking)

 1Risk of AI pair programming: the developer becomes too passive.
 2
 3Signs of an unhealthy dynamic:
 4  X Developer always accepts AI suggestions without evaluating
 5  X Developer can't explain the code the AI generated
 6  X Developer can't code without the AI
 7  X Developer has no opinion about design decisions
 8
 9Healthy dynamic checks:
10  OK Developer challenges AI suggestions occasionally (see 15.5)
11  OK Developer can explain every line the AI generated
12  OK Developer occasionally codes without the AI (build muscle)
13  OK Developer makes the final architecture decisions
14
15Exercise: "Solo Friday"
16  Every Friday, one task is done without AI assistance
17  Goal: maintain baseline coding skill
18  Track: is the solo-task quality degrading over time?

 1# AI pairing is very valuable for onboarding a new developer:
 2
 3# New developer (NDE) prompt:
 4claude
 5> I just joined the Santekno team. This is my first task:
 6> [paste task from Linear/Jira]
 7>
 8> Please help me:
 9> 1. Understand the scope of this task
10> 2. Find existing code that's similar as a reference
11> 3. Make an implementation plan
12> 4. Guide me through the implementation step by step
13> 5. Review my implementation and give feedback
14>
15> I'm familiar with PHP/Laravel but new to Go.
16> If there are important Go vs PHP differences, please explain.

 1# When a pair session needs to be continued tomorrow or by someone else:
 2
 3claude
 4> Before we finish today, help me document:
 5>
 6> 1. Current state: what's done, what's not
 7> 2. Decisions made and why
 8> 3. Unresolved questions still outstanding
 9> 4. Clear next steps to continue tomorrow
10> 5. Code that needs special attention and why
11>
12> Format it as a HANDOFF.md I can commit to the repo
13
14# Claude generates HANDOFF.md
15# Commit to the feature branch
16# Tomorrow (or someone else): read HANDOFF.md → immediate context

 1Anti-pattern 1: Passive passenger
 2  The developer just accepts all AI output without review
 3  → Code that isn't understood goes into production
 4  Fix: the developer must be able to explain every line
 5
 6Anti-pattern 2: Context overload
 7  The developer pastes the entire codebase + all docs into one session
 8  → The AI is overwhelmed, response quality drops
 9  Fix: targeted context suited to the task
10
11Anti-pattern 3: No commitment to output
12  The AI generates 200 lines of code → the developer pushes immediately
13  → No review, no testing
14  Fix: always go build + go test before committing
15
16Anti-pattern 4: Endless discussion (analysis paralysis)
17  50+ exchanges about the "best approach" without ever implementing
18  Fix: time-box the discussion phase (max 10 minutes), then implement and evaluate
19
20Anti-pattern 5: Ignoring an AI suggestion out of ego
21  "I know better than the AI"
22  → Miss valuable insights
23  Fix: evaluate the suggestion objectively, not on ego
24
25Anti-pattern 6: Using AI for every task
26  Even for a task that could be done in 2 minutes without AI
27  → Context-switch overhead > actual benefit
28  Fix: AI for tasks > 15 minutes, manual for simpler ones

 1Ranked by quality as a "pair partner":
 2
 31. Claude Code (94/100 overall, best for pairing)
 4   - The deepest reasoning
 5   - Can explain why, not just how
 6   - Long context retention
 7   - Can run verification commands
 8   Best for: complex problem solving, learning sessions
 9
102. Cursor (87.8/100)
11   - Visual: the developer sees the code change directly
12   - Good for: bulk implementation pairs
13   - Composer as "the AI implements, the developer approves"
14   Best for: multi-file implementation sessions
15
163. GitHub Copilot (80.2/100)
17   - Inline suggestions as a real-time pair
18   - @workspace for contextual questions
19   - Smooth for coding flow without context switch
20   Best for: daily coding flow, no need for deep dialogue
21
224. Windsurf (84.2/100)
23   - Cascade for long sessions (the AI remembers context)
24   - Good for debugging sessions that span several days
25   Best for: extended debugging pair sessions
26
275. AWS Kiro (88/100)
28   - Spec-driven pairing: develop the spec together, implement together
29   Best for: new feature planning + implementation
30
316. Gemini (78.8/100)
32   - Good for large codebase exploration
33   Best for: codebase discovery sessions

 1How do you measure whether pair programming with AI is effective?
 2
 3Quantitative:
 4  - Task completion time (solo vs AI pair)
 5  - Code quality score (AI review after the session)
 6  - Post-merge bug rate from pair sessions vs solo
 7
 8Qualitative (weekly survey):
 9  "How confident are you in the code produced by the pair session?"
10  "Did the pair session help your understanding of the problem?"
11  "How effective was the communication with the AI in this session?"
12
13Healthy ratio:
14  60-70% of tasks with an AI pair
15  30-40% of tasks solo (maintain coding muscle)

 1# AI as an architecture partner:
 2
 3claude
 4> We need a design decision for a flash sale ordering system.
 5> Let's explore it together, not implement immediately.
 6>
 7> Problem: 100,000 concurrent users during the flash sale.
 8> We need a system that is:
 9> 1. Fair: first come, first served
10> 2. Reliable: no overselling
11> 3. Fast: response < 500ms
12>
13> I propose two approaches:
14> Approach A: [describe]
15> Approach B: [describe]
16>
17> Please:
18> 1. Identify the strengths and weaknesses of each
19> 2. Identify failure scenarios I might miss
20> 3. Propose a trade-off matrix
21> 4. Recommend an approach with justification
22> 5. If there's a better approach C, propose it
23>
24> We don't implement yet — just think through.

 1# Situation: production down, need a FAST hotfix
 2
 3# A pressure situation needs a reliable pair:
 4claude
 5> URGENT: production is down. This error shows up in the log:
 6> [paste error + stack trace]
 7>
 8> This is a critical path: order creation is failing for all users.
 9> I need:
10> 1. Immediate diagnosis: what's causing this error?
11> 2. Quick fix: the minimum change that's safe to stop the bleeding
12> 3. Root cause: why could this happen after the earlier deploy?
13> 4. Proper fix: what needs to be fixed properly in the next sprint?
14>
15> Priority right now: #1 and #2 (immediate fix first)

 1# Senior developer as navigator, AI as "fast-learning junior":
 2
 3# Senior: "We're implementing a flash sale. Before code, explain to me
 4#           the approach you propose and why."
 5# AI: [explains the approach with tradeoffs]
 6# Senior: "Good point about Redis. But you didn't mention
 7#           circuit breaker. Why?"
 8# AI: [acknowledges and adds circuit breaker to the proposal]
 9# Senior: "OK, implement per the approach we agreed on."
10# AI: [implements]
11# Senior: [reviews, catches a subtle bug]
12# AI: [acknowledges and fixes]
13
14# What happens here:
15# The senior transfers expertise via dialogue (not just code review)
16# The AI "learns" the team's conventions from the exchanges
17# The output code is better than "AI implements directly without dialogue"

 1After every significant pair session (> 1 hour), spend 5 minutes reflecting:
 2
 3What worked:
 4  + An AI that immediately understood the requirement without much clarification
 5  + An AI that caught an error before I ran the test
 6  + An AI that proposed an alternative I hadn't thought of
 7  + A session that was productive from start to finish
 8
 9What didn't work:
10  - An AI that generated code with the wrong pattern (missed CLAUDE.md)
11  - Context lost in the middle of a long session
12  - Me being too passive (not challenging the AI)
13  - A task too big for one session
14
15Action items:
16  → Update CLAUDE.md for patterns that are frequently missed
17  → Break a big task into smaller sessions
18  → Commit more often as checkpoints
19  → Challenge the AI at least once per session (make it a habit)

 1# Pairing is not only for writing — also for reading existing code:
 2
 3claude
 4> I need to understand this code before modifying it:
 5> [paste a complex function or module]
 6>
 7> Help me understand:
 8> 1. What this function does (high level, one sentence)
 9> 2. What is its data flow? (input → processing → output)
10> 3. What edge cases do I need to watch for when modifying?
11> 4. What dependencies do I need to know about?
12> 5. What could break if I modify X?

 1# AI PAIR SESSION TEMPLATE
 2
 3## Date: [date]
 4## Developer: [name]
 5## Session Goal: [one sentence]
 6## Time budget: [X hours]
 7
 8## Context (paste into the AI at the start of the session):
 9> Our pair session today. Context:
10> - Project: Santekno Shop (see CLAUDE.md)
11> - Task: [task description]
12> - Current status: [what already exists]
13> - Blockers: [what needs to be thought through first]
14> - Completion target: [what must exist at the end of the session]
15>
16> Start by helping me think through [blocker] before implementing.
17
18## Session Log (fill during the session):
19- [timestamp]: Decision: [what was decided]
20- [timestamp]: Concern raised: [by whom, about what]
21- [timestamp]: Pivot: [why, to what]
22
23## End of Session:
24What's done: [list]
25What's pending: [list]
26HANDOFF: [can be continued by anyone who reads this]

 1Before starting:
 2[ ] CLAUDE.md has been read by the AI (or explicitly referenced in the prompt)
 3[ ] The task/spec is clear and available
 4[ ] Git branch created: git checkout -b feature/X
 5[ ] Test environment ready
 6
 7During the session:
 8[ ] Commit every 30-45 minutes (checkpoint)
 9[ ] Challenge the AI at least once (healthy disagreement)
10[ ] Run go test after every significant change
11[ ] Take a short break every 1 hour
12
13After the session:
14[ ] All tests pass: go test -race ./...
15[ ] Code reviewed (AI self-review)
16[ ] Committed with meaningful messages
17[ ] HANDOFF.md created if it will be continued
18[ ] Document key decisions (ADR if significant)

 1For a team that wants to adopt AI pairing as culture:
 2
 3Week 1: Individual exploration
 4  Each developer tries AI pairing for 1 task
 5  No pressure, no judgment
 6  Share the experience in the weekly retro
 7
 8Week 2-3: Pair with observation
 9  2 developers pair (one coding, one observing)
10  Observe: how do they interact with the AI?
11  Share learnings
12
13Week 4: Define team norms
14  "We agree that AI pairing is used for X situations"
15  "We don't agree that AI pairing is for Y situations"
16  Document in the team handbook
17
18Month 2+: Measure and iterate
19  Track metrics (15.14)
20  Adjust norms based on data
21  Update CLAUDE.md based on the patterns that emerged

 1AI pair programming is very valuable for remote teams:
 2
 3Challenges of traditional remote pair programming:
 4  - Scheduling across different time zones
 5  - Poor connection quality during screen share
 6  - A lack of a sense of presence
 7  - Hard to "tap on the shoulder" to ask for help
 8
 9AI pairing as a complement:
10  Solo developer + AI pair = productive without scheduling overhead
11
12  But you still need occasional human pairing:
13  - Weekly human pair session (not daily)
14  - For major architecture decisions
15  - For onboarding and knowledge transfer
16  - For complex bugs that need domain expertise
17
18Recommendation for a remote team in Indonesia:
19  Monday morning: Team sync (30 minutes) — task distribution, blockers
20  Monday-Thursday: Individual work + AI pairing (the majority)
21  Friday morning: Human pair sessions (optional, voluntary)
22  Friday afternoon: Retro + knowledge sharing from AI pair sessions

 1Exercise 1: The 20-Question Pair (Day 1 onboarding)
 2  New developer: 20 questions about the codebase to the AI
 3  The AI answers based on the actual code
 4  Goal: understand the codebase structure within 2 hours
 5
 6Exercise 2: The Architecture Debate
 7  Developer proposes a design, AI critiques, developer defends or changes
 8  At least 3 back-and-forth exchanges before implementing
 9  Track: did the design change from start to finish?
10
11Exercise 3: The Blindfold Review
12  The AI implements something, the developer reviews WITHOUT the AI
13  Only after the review is done: the AI explains why it implemented it that way
14  Goal: maintain independent code-reading skill
15
16Exercise 4: The Handoff Challenge
17  Developer A pairs with the AI until 50% done
18  Developer B reads HANDOFF.md and continues with the AI
19  Goal: validate handoff quality and async continuity

 1Relevant books:
 2  "The Pragmatic Programmer" — pair programming principles
 3  "Clean Code" — the code quality AI pairing should enforce
 4  "Team Topologies" — how teams interact, including AI-assisted
 5
 6Articles:
 7  Ardan Labs Blog — Go best practices the AI should follow
 8  Iman Tumorang's articles — software architecture from an Indonesian perspective
 9
10Communities:
11  Gophers Indonesia (Discord) — the Indonesian Go developer community
12  r/golang — the global Go community
13  Claude Discord — Claude Code users sharing tips
14
15Practice:
16  Every Monday morning: a 30-minute AI pair session with one new task
17  Every Friday afternoon: reflect and update CLAUDE.md based on learnings
18  Monthly: a retrospective on AI pairing effectiveness in the team