Why 'We' Beats 'Do This for Me': Getting Better Results from AI Coding Assistants

Mar 30, 2026

I kept getting mediocre code from ChatGPT. My prompts were straightforward: “Write a function that validates emails” or “Fix this bug in my authentication code.” The results worked, barely, but they never felt right.

Then I changed one thing: how I talked to the AI.

The Problem: Treating AI Like a Vending Machine

I was using AI as a command-line tool. Drop in a command, get code out. Simple, fast, and wrong.

Me: Write a function to validate email addresses
AI: Here's a regex pattern that matches emails...
Me: Thanks. *uses it*
Me (later): Why isn't it working for international domains?

This command-based interaction failed because:

No shared context about what I was building
No constraints mentioned (performance, compatibility, team standards)
No opportunity for AI to challenge my approach
No exploration of alternatives

I was a junior developer asking a senior engineer for code without explaining the project. Of course the results were mediocre.

The Shift: From Commands to Collaboration

I started treating AI like a pair programming partner instead of a code vending machine. The difference was immediate.

Me: I'm building a user registration system for a SaaS product. I need to
validate email addresses, but I'm concerned about:
- Supporting international domains (.中国, .museum, etc.)
- Not being too restrictive (false negatives hurt conversions)
- Performance (we expect 10k signups/day)

Here's what I'm thinking: use a simple pattern check plus DNS verification.
What do you think? Any edge cases I'm missing?

AI: DNS verification adds latency and can fail for valid domains. Have you
considered what happens when DNS is temporarily unavailable? Also, your
approach might reject some valid TLDs. Here's a better way to think about this...

This conversation led to a completely different solution. One that handled edge cases I hadn’t considered.

Why “We” Language Changes Everything

When I started using “we” instead of “do this,” I began sharing context naturally:

Before:

Fix this bug: TypeError at line 45

After:

We're seeing this error in our payment processing. It only happens for
subscriptions with trials, started after we added tiered pricing.

The “we” mindset forced me to explain:

What I was building
What constraints I was working with
What I had already tried
Why I was stuck

This context let the AI build a complete picture of my problem.

What Collaborative Dialogue Looks Like

I now structure my AI conversations like I would with a senior engineer:

I'm working on a real-time notification system for a React app. We're using:
- Node.js backend with Socket.io
- Redis for pub/sub
- About 5k concurrent users expected

Current issue: notifications sometimes arrive out of order. I suspect it's
related to our Redis implementation. Here's what I've tried...

2. Invite Genuine Input

I'm considering two approaches:
1. Add sequence numbers and reorder on client
2. Use Redis streams for ordering

What are the trade-offs I'm not seeing? Which would you pick and why?

3. Iterate on the Solution

You mentioned Redis streams. I looked at the docs but I'm worried about:
- Complexity of consumer groups
- Memory usage with long retention

Is my worry valid? Should I stick with approach 1?

The Senior Developer Analogy

A senior developer on Reddit put it perfectly:

“I have a hard time imagining not using Opus’ big brain for requirements discussion, architecture, edge cases, alternatives. Sonnet doesn’t get ‘do this’ either. It gets ‘check out this spec I created with Opus and lmk what you think.’ Code builds better when it ‘buys in’ to the architecture.”

This captures the essence. The AI’s “big brain” is most valuable when you’re discussing:

Requirements and scope
Architecture decisions
Edge cases and alternatives
Trade-offs

Not when you’re asking for syntax.

Common Mistakes I Made

Mistake 1: Being Too Vague in Collaboration

What do you think about this code?
[code]

This is just a command disguised as collaboration. No context, no constraints, no real question.

This function handles user authentication for our mobile app. We're seeing
intermittent failures on slow networks. I'm worried the timeout is too short,
but increasing it might cause other issues. What would you check first?

Mistake 2: Skipping Requirements Discussion

I used to jump straight to implementation:

Write a caching layer for our API

Now I start with requirements:

We need to add caching to reduce database load. Our situation:
- Read-heavy API (95% reads)
- 100ms acceptable latency
- Data can be stale for up to 5 minutes
- We're on AWS with ElastiCache available

What caching strategy makes sense here? Should we consider CDNs instead?

Mistake 3: Ignoring the AI’s Questions

When AI asks clarifying questions, it’s trying to help. I used to ignore these or get frustrated. Now I engage with them.

AI: You mentioned performance is important. What's your latency budget?

Me (old response): Just give me the fastest solution.

Me (new response): We need under 200ms total response time. Currently at
150ms without caching, hoping to get to 50ms with caching.

The back-and-forth improves the solution.

A Real Example: Refactoring Gone Right

I needed to refactor a slow function. Old me would’ve said:

Make this function faster
[code]

New me approached it collaboratively:

I have this function that processes user events. It's getting slow with our
growing user base (currently 50k, expecting 5x growth this year).

```javascript title="processEvents.js"
function processEvents(events) {
  return events.map(event => {
    // Various transformations
  });
}

Constraints:

Must maintain same output format (downstream systems depend on it)
Node.js 18
Team prefers readable code over clever optimizations
We have Redis available

I’m considering:

Batch processing with chunks
Worker threads
Moving to a queue-based system

What do you think? What performance characteristics should I expect?

The AI suggested option 1 with specific chunk sizes, explained why option 2 wouldn't help (CPU-bound vs I/O-bound), and warned about memory issues with option 3. I got a working solution plus learned something.

## The Results

Since changing my approach:

- **Better architecture**: Solutions fit the bigger picture, not just the immediate problem
- **Fewer dead-ends**: Problems surface early in the conversation
- **More learning**: I understand *why* solutions work
- **Better code quality**: The AI "buys in" to the approach

## How to Start

Your next AI conversation should begin with:

1. **Context**: What are you building? What constraints exist?
2. **Current state**: What have you tried? What's working/not working?
3. **Open question**: What do you want to explore? What input do you need?

```text title="Template for collaboration"
I'm working on [specific feature/system]. Context:
- [constraint 1]
- [constraint 2]
- [what I've tried]

I'm considering [approach]. Concerns:
- [concern 1]
- [concern 2]

What do you think? Am I missing anything?

The Core Insight

The key isn’t finding the perfect prompt. It’s changing how you collaborate.

Treat your AI assistant as a senior engineer pair programmer:

Share the full picture
Invite genuine input
Iterate together
Learn from the conversation

The “we” mindset transforms AI from a code generator into a true collaborator. When you bring the AI into your thinking process, you get better architecture, fewer dead-ends, and more robust solutions.

Start your next conversation with context and collaboration in mind. The difference is immediate.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

👨‍💻 Reddit Discussion on AI Collaboration
👨‍💻 Claude Prompt Engineering Guide
👨‍💻 OpenAI Prompt Engineering Guide

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!