"Copilot Wrote It" Is Not an Acceptable Code Review Response

[maya_builds]

I need to share something that happened in a code review yesterday, because I think it represents a dangerous pattern that’s emerging in the AI era.

The context: Junior engineer submits a PR for a critical payment processing feature. Code looks clean, tests pass, architecture seems sound.

The code review exchange:

Me: “Can you walk me through how this handles failed transactions?”

Engineer: “Sure, it retries up to 3 times with exponential backoff.”

Me: “Great. And what happens if all three retries fail?”

Engineer: long pause “I… I’m not totally sure. Copilot generated that part.”

Me: “Okay, can you look at the code and tell me?”

Engineer: scrolls through code for 2 minutes “It looks like it logs an error and returns null?”

Me: “Right. So if a customer’s payment fails after 3 retries, we return null to the frontend. What does the frontend do with null?”

Engineer: “Um… I don’t know. That’s a different team’s code.”

This Is Not a Code Review Problem. It’s a Mental Model Problem.

Here’s what scared me about this exchange: the engineer couldn’t explain their own code because they never built a mental model of how the system works.

They treated AI-generated code like a black box. Input: “handle payment retries.” Output: some code that compiles. Ship it.

But software isn’t just code that compiles. It’s a system where each component affects others. If you don’t understand how your code fits into the broader system, you can’t reason about failure modes.

The Downstream Disaster

Want to know what happened next?

The code shipped. Three days later, we had a production incident:

• Payment processor had an outage
• Our retry logic exhausted attempts and returned null
• Frontend received null and… displayed “Payment successful ✓”
• Because the frontend engineer also didn’t understand the contract and assumed null meant “no error”

Customer complaints: “I was charged but the order never processed!”
Support tickets: 400+ in 6 hours
Revenue impact: $50K+ in refunds and support costs

Two engineers, both using AI effectively from a “does the code work?” perspective, both lacking the system-level understanding to predict this failure mode.

“Copilot Wrote It” Is Not an Acceptable Response

After that incident, I instituted a new rule:

“Copilot wrote it” is not an acceptable answer in code review.

If you submit code you can’t fully explain—line by line, edge case by edge case, system interaction by system interaction—it doesn’t ship. Period.

I don’t care if the tests pass. I don’t care if it looks correct. If you can’t explain it, you don’t understand it. And if you don’t understand it, you can’t own it in production.

The Psychological Safety Problem

Here’s the uncomfortable part: this engineer is smart and hardworking. They weren’t being lazy. They genuinely thought that “AI generated code that passes tests” was sufficient.

Why? Because nobody taught them otherwise.

In fact, in many orgs (including ours, until recently), the implicit message was: “Ship fast. AI helps you ship fast. Use it.”

We never said: “AI helps you ship fast, but you’re still responsible for understanding every line.”

So when I said “you need to explain this before it ships,” the engineer felt like I was moving the goalposts. And in a sense, I was—we hadn’t set clear expectations about AI usage and ownership.

What “Owning Your Code” Means in the AI Era

I’ve been thinking about what it means to “own” code when AI generates significant portions of it.

Here’s my current definition:

You own code if you can:

1. Explain why it works (not just that it works)
2. Predict how it fails under various conditions
3. Debug it when it breaks in production
4. Explain its interactions with other parts of the system
5. Justify the trade-offs (performance, readability, maintainability)

If you can’t do those five things, you don’t own the code. The AI does. And AI doesn’t get paged at 2am when it breaks.

The Bigger Pattern: Superficial Understanding at Scale

What worries me is that this isn’t isolated. I’m seeing variations of “I don’t know, AI wrote it” across multiple teams:

• “Can you explain this regex?” — “No, but it works.”
• “Why did you choose this algorithm?” — “AI suggested it.”
• “What’s the time complexity?” — “Um… AI didn’t say.”
• “How would you debug this?” — “I… I’d ask AI to debug it?”

Each individual case is small. But at scale, this is how you build systems where nobody fully understands how anything works.

And that’s terrifying.

The Contract We Need

I think we need a new social contract between engineering teams and AI:

AI can generate code. Humans must understand code.

That means:

• Use AI to accelerate implementation:
• Use AI to explore solutions:
• Ship AI-generated code you don’t understand:
• Accept “AI wrote it” as explanation:

Is this slower? Yes.
Is it worth it? Absolutely.

Because the alternative is what we experienced: a production outage caused not by bad code, but by two engineers who couldn’t reason about how their code interacted because neither understood their own implementations.

The Question I’m Wrestling With

Here’s what I don’t have an answer to: How do we teach engineers to treat AI as a tool, not as an authority?

Right now, when AI generates code, many engineers treat it as more correct than code they’d write themselves. They trust it implicitly. They don’t question it.

But AI makes mistakes. AI doesn’t understand your specific system context. AI doesn’t know your edge cases or business requirements.

Humans need to be the authority. AI should be the assistant.

How do we create that mindset shift?

For engineering leaders: Have you encountered “Copilot wrote it” as an explanation in code reviews? How did you respond? And how do you teach engineers to own AI-generated code?

This feels like the defining challenge of engineering leadership in 2026.

[cto_michelle]

Maya, this story is horrifying—and I’m saying that as a CTO who’s seen plenty of production incidents.

But what really gets me is this: the problem wasn’t technical. It was organizational.

The Real Root Cause: Unclear Ownership Model

Your payment processing incident had two engineers, both using AI, both shipping code that individually “worked,” but together created a catastrophic failure.

The breakdown wasn’t in the code. It was in the accountability model.

Let me map out what happened:

1. Backend engineer used AI to generate retry logic, didn’t understand the null return case, assumed frontend would handle it correctly
2. Frontend engineer received null, didn’t understand the contract, assumed null meant success
3. Neither engineer owned the end-to-end flow

This is a systems integration failure. And it’s getting worse in the AI era because AI optimizes for local correctness (does this function work?) not global correctness (does this system work?).

We Need “System Ownership,” Not Just “Code Ownership”

Your five criteria for owning code are excellent. But I’d add a sixth:

6. Can you trace how your code affects other parts of the system?

In your payment example:

• Backend engineer should have asked: “What does the frontend do when I return null?”
• Frontend engineer should have asked: “What does null mean in the backend’s contract?”

Neither asked because they were optimizing for shipping their isolated component, not for understanding the integrated system.

The Legal and Security Implications

Here’s the part that keeps me up at night as a CTO: “Copilot wrote it” is not just unacceptable in code review. It’s legally and contractually untenable.

Consider:

• Security vulnerabilities: If AI generates code with a SQL injection flaw and an engineer ships it without understanding it, who’s liable when customer data is breached?
• Compliance violations: If AI generates code that violates GDPR or HIPAA, and the engineer can’t explain what the code does, how do we prove compliance to auditors?
• Intellectual property: If AI trains on copyrighted code and generates similar patterns, and engineers don’t understand it well enough to evaluate originality, are we liable for infringement?

“I don’t know how this works, AI wrote it” is not a defense in any of these scenarios.

As CTOs, we’re ultimately accountable. If an engineer ships AI-generated code they don’t understand, and it causes harm, I’m the one explaining to the board why we allowed that.

The Policy I’m Implementing

After reading your post, I’m drafting a formal AI usage policy for our engineering org:

AI Code Generation Policy (Draft)

Allowed:

• Using AI to generate initial implementations
• Using AI to explore architectural options
• Using AI for boilerplate and scaffolding
• Using AI to explain unfamiliar patterns

Required before shipping AI-generated code:

• Line-by-line comprehension of implementation
• Documentation of edge cases and failure modes
• Validation of system-level interactions
• Ability to explain in code review without referencing AI

Prohibited:

• Shipping code you cannot fully explain
• Accepting “AI generated this” as sufficient justification
• Merging code without understanding its system-level impact
• Deferring debugging responsibility because “AI wrote it”

Consequence for violation:

• First time: Mandatory mentoring session on AI usage and code ownership
• Second time: Performance improvement plan
• Third time: Role reassessment (this might be too harsh?)

The Mindset Shift You’re Asking About

You asked: “How do we teach engineers to treat AI as a tool, not as an authority?”

I think the answer is consequences + culture.

Consequences: When code ships that the engineer can’t explain and it breaks in production, that engineer owns the incident response and the post-mortem. Not a senior. Not the “AI expert.” The person who shipped it.

That’s not punishment—it’s accountability. You learn to understand code deeply when you’re the one who has to fix it at 2am.

Culture: We need to normalize asking “why” and “how” about AI suggestions. In our leadership meetings, I’ve started asking: “Did you verify that AI suggestion, or did you trust it?” And I model this by sharing times when I questioned AI and found it was wrong.

The System-Level Understanding Gap

Your payment incident reveals a deeper problem: AI is really good at generating locally optimal code, but terrible at understanding system-level constraints.

AI doesn’t know:

• What your frontend expects from your backend
• What your monitoring systems need to observe
• What your customer support team needs to debug issues
• What your compliance team needs to audit

Only humans know those things. And if humans defer to AI without adding that context, systems break in subtle, cascading ways.

The Insurance Analogy

Here’s how I explain this to non-technical executives:

“Would you let an AI file your taxes without understanding what it’s claiming? What if it generates a return that looks correct but contains errors that trigger an audit?”

Most executives immediately say: “No, of course not. I’d review it carefully.”

“Okay. Now apply that to production code that handles customer payments.”

Suddenly the “AI wrote it” defense sounds absurd.

For other CTOs: Are you implementing formal AI usage policies? What consequences are you setting for engineers who ship code they can’t explain?

This feels like the kind of leadership decision we need to make now, before a major incident forces our hand.

[vp_eng_keisha]

Maya, your payment incident is exactly the kind of systems-thinking failure that terrifies me as someone responsible for team culture.

Michelle’s point about system ownership is critical. But I want to address the psychological safety issue you mentioned, because I think that’s the root cause.

The Engineer Wasn’t Being Lazy—They Were Following Incentives

You said: “This engineer is smart and hardworking. They genuinely thought that ‘AI generated code that passes tests’ was sufficient.”

Of course they did. Because that’s what we taught them.

Let’s map out the implicit incentive structure in most engineering orgs (including mine until recently):

What we say:

• “Understand your code deeply”
• “Own your features end-to-end”
• “Think about edge cases”

What we measure:

• Story points completed
• PRs merged
• Features shipped

What we celebrate:

• “Sarah shipped 3 features this sprint!”
• “Team velocity is up 40%!”
• “We hit our roadmap commitments!”

What we DON’T celebrate:

• “Sarah spent 2 days understanding AI-generated code before shipping it”
• “Team velocity is down because engineers are asking more questions”
• “We delayed a feature to ensure deep comprehension”

The engineer who said “Copilot wrote it” was optimizing for what we actually incentivize, not what we say we value.

We Need to Make Understanding Visible and Valuable

Here’s what we’re piloting at my EdTech company:

“Understanding Awards” (Yes, Really)

Once per quarter, we give awards (public recognition + $500 bonus) for:

• “Best ‘I Don’t Know Yet’ Moment”: Engineer who paused a PR to deeply understand AI-generated code before shipping
• “System Thinker Award”: Engineer who caught a cross-system integration bug in code review
• “Debugging Detective”: Engineer who diagnosed and fixed a complex production issue in record time

These aren’t participation trophies. They’re strategic signals about what we value.

Early results (2 quarters in):

• Engineers now brag about understanding code deeply, not just shipping fast
• “I need more time to understand this” is seen as responsible, not slow
• Code review discussions shifted from “does this work?” to “do you understand how this works?”

The “Explain to the Team” Ritual

We also implemented something inspired by academic paper presentations:

Monthly “Deep Dive” Sessions:

• One engineer per team presents a complex piece of code (often AI-generated)
• 30-minute format:
  • 10 min: Explain what the code does
  • 10 min: Explain why it works and what could break it
  • 10 min: Team Q&A challenging the explanation
• Key rule: You must explain it without referring to “AI suggested this”

This serves two purposes:

1. Forces presenter to build deep understanding
2. Models for the team what “owning code” looks like

The uncomfortable part: Some engineers initially hated this. Feedback: “This feels like a performance, not learning.”

But after 3 months, the culture shifted. Engineers started volunteering to present because it was seen as a credibility signal.

Michelle’s Consequences Framework: A Word of Caution

Michelle, I understand the impulse to create consequences for shipping unexplained code. But I’m concerned about unintended effects.

If the consequence for saying “I don’t understand this code” is a performance improvement plan, engineers will hide their lack of understanding.

They’ll learn to perform understanding—nod in code reviews, write superficial documentation, use confident language—without actually building comprehension.

I’ve seen this pattern in other contexts (performance reviews, incident post-mortems). When stakes are high, people optimize for appearing knowledgeable, not becoming knowledgeable.

An Alternative: “Accountability Without Punishment”

What if instead of consequences for not understanding, we create structures that make understanding inevitable?

Examples:

• Mandatory “teach-back” sessions: Before shipping AI-generated code, engineer must teach it to a peer (not a code review—a teaching session)
• On-call rotation requirement: You can’t be on-call until you can debug code you didn’t write (creates natural incentive to understand all code)
• “Authorship includes debugging”: Whoever ships a feature is automatically assigned the first bug report on that feature (you learn real fast to understand your code)

These create accountability through natural consequences (you have to debug what you ship) rather than imposed consequences (PIP for not explaining code).

Maya’s Question: “How Do We Teach Engineers to Treat AI as a Tool, Not as an Authority?”

I think the answer is model it, repeatedly, at every level.

As a VP, I use AI daily. But in team meetings, I explicitly share:

• “I asked AI for a solution, but then I validated it against our specific context—here’s what I found”
• “AI suggested this approach, but I think it’s wrong for our use case because [reason]”
• “I used AI to generate the initial draft, then spent 2 hours refining based on what I know about our system”

The message: AI is a tool I use, but I’m the authority on our system.

When leaders model this behavior, it becomes culture.

The Meta Question: Are We Solving the Right Problem?

Here’s what I keep coming back to: Maybe “Copilot wrote it” isn’t the problem. Maybe “we never taught engineers what ownership means in the AI era” is the problem.

In the pre-AI era, ownership was implicit:

• If you wrote it, you understood it (because writing forced understanding)
• If it broke, you fixed it (because you wrote it)
• Ownership = authorship

In the AI era, authorship ≠ understanding.

So we need to explicitly teach what ownership means now:

• You don’t need to type every character (AI can help)
• But you need to understand every decision
• And you need to be able to debug every failure

That’s a mindset shift that requires active teaching, not just policy enforcement.

For other engineering leaders: How are you making “deep understanding” visible and valued in your culture? What rituals or structures have worked?

[eng_director_luis]

Maya, this resonates deeply with what I’ve been wrestling with in my team’s bug rotation program.

The payment incident you described—two engineers, both optimizing locally, neither thinking systemically—is exactly what our debugging-first onboarding tries to prevent.

Let me share how we’re addressing the “Copilot wrote it” problem structurally.

The “System Mapping” Exercise

When new engineers join our team (or when experienced engineers join a new domain), we require them to complete a “system mapping” exercise before they write any code:

Format:

1. Draw (by hand or digitally) a diagram showing:
   • Your component/service
   • All components it depends on
   • All components that depend on it
   • Data flows between them
   • Failure modes at each boundary
2. Present to the team for feedback
3. Update based on feedback
4. This diagram must be referenced in every PR that touches cross-system interactions

The goal: Force engineers to think about system-level effects before generating any code (with or without AI).

Example from last month:

Junior engineer was implementing a new API endpoint. Their system map showed:

• Frontend calls this endpoint
• Endpoint queries database
• Returns JSON

During the presentation, a senior asked: “What happens if the database is slow?”

Engineer: “Uh… it times out?”

Senior: “Right. And what does the frontend do with a timeout?”

Engineer: “I… I don’t know.”

That conversation happened BEFORE any code was written. So when the engineer used AI to generate the implementation, they already knew to ask: “How should I handle database timeouts in a way that frontend can interpret?”

The “Contract Review” Before Code Review

Building on the system mapping, we implemented “contract reviews” before code reviews:

Format:

• Engineer writes a short doc (5-10 min effort) describing:
  • What does my code accept as input?
  • What does my code return as output?
  • What does my code do with errors?
  • What does calling code expect?
• This happens before implementation
• Team reviews the contract, not the code
• Once contract is approved, implementation can proceed

Why this works:

In Maya’s payment example:

• Backend engineer’s contract would have said: “Returns null on failure”
• Team review would have asked: “Does frontend handle null correctly?”
• Gap would have been caught before either engineer wrote code

Michelle’s Legal/Security Point Is Existential

Michelle mentioned legal liability for “Copilot wrote it” code. This is real and underappreciated.

At our fintech company, we’re subject to SOC 2 and PCI compliance. During our last audit, the auditor asked:

“Can you explain how this code prevents SQL injection?”

Engineer: “It uses parameterized queries.”

Auditor: “Good. Can you show me where in the code?”

Engineer: scrolls through code “Um… here, I think? AI generated this part.”

Auditor: “So you can’t definitively confirm that this code is SQL-injection-proof?”

Engineer: “The tests pass…”

Auditor: “That’s not an answer. Either you can explain the security properties of this code, or we have to flag this as a compliance risk.”

That audit finding cost us 3 weeks of remediation work and nearly delayed a major contract.

The lesson: “Copilot wrote it” is not audit-defensible.

Keisha’s Point About Incentives Is Everything

Keisha, you’re absolutely right that consequences create performative understanding, not real understanding.

But I want to push back on one thing: accountability without consequences isn’t accountability. It’s wishful thinking.

The challenge is finding consequences that drive learning, not hiding.

Here’s what we do:

“Debugging Ownership” Rule:

• If you ship code (with or without AI), you respond to the first production incident related to that code
• You’re not alone—seniors support you—but you lead the debugging and write the post-mortem
• This isn’t punishment. It’s a learning opportunity.

Results:

• Engineers really care about understanding code before it ships (because they know they’ll have to debug it)
• Post-mortems include “what I wish I’d understood better during implementation” sections
• Incident resolution times improved because engineers already have context

The “Explain It to Product” Standard

Maya mentioned explaining code in customer-facing terms. We formalized this:

“Product Impact Review” (required for all features):

• After code review passes, engineer presents to product manager
• Format: “Here’s what this code does for users. Here’s what could go wrong from a user perspective.”
• Product manager asks questions
• If engineer can’t answer, code goes back for deeper understanding

Example from last week:

Engineer: “This feature caches API responses for 5 minutes.”

Product: “Great. What happens if the data changes during those 5 minutes?”

Engineer: “Users see stale data.”

Product: “Is that acceptable for this use case?”

Engineer: “I… I’m not sure. Copilot suggested 5 minutes. Should I make it configurable?”

That’s the conversation that prevents the production incident Maya described. Product and engineering together reasoning about edge cases.

The Cultural Shift: “I Don’t Know Yet” > “I Think It Works”

Keisha’s “Understanding Awards” are brilliant. We’re adopting a similar practice:

Monthly shoutouts in all-hands for:

• “Best ‘I Don’t Know Yet’ moment”: Engineer who said “I need more time to understand this before shipping”
• “System Thinker of the Month”: Engineer who caught a cross-system failure mode in review
• “Debugging Hero”: Engineer who resolved a complex incident quickly because they deeply understood the code

These aren’t token awards. They’re strategic culture signals.

Maya’s Question: “How Do We Teach AI as Tool, Not Authority?”

My answer: Make the human the authority through structural requirements.

• System mapping: Human defines the system context that AI doesn’t know
• Contract review: Human defines the interface contract before AI generates implementation
• Product impact review: Human explains user impact that AI can’t understand
• Debugging ownership: Human owns the consequences of shipping code

At every step, the human is the decision-maker. AI is the implementation assistant.

For engineering leaders: How are you structurally enforcing system-level thinking before code generation? What pre-implementation rituals work for your teams?

[product_david]

Product perspective here, and I need to be blunt: your payment incident cost $50K+ in refunds and support. That’s a product failure, not just an engineering failure.

And it’s a failure I’m seeing more frequently across the industry as AI-generated code becomes normalized.

The Customer Trust Erosion

Maya, you focused on the technical breakdown. Let me share the customer-facing impact:

What customers experienced:

1. Payment appears to succeed (green checkmark, confirmation message)
2. Money is charged to their account
3. Order never ships
4. They contact support: “Where’s my order?”
5. Support investigates: “Your payment failed, but we showed success”
6. Customer: “But you charged me!”
7. Refund process takes 5-7 business days

From the customer’s perspective: Your company charged them money, lied about order success, and now they have to wait a week to get their money back.

That’s not a bug. That’s a broken promise that erodes trust.

And here’s the thing: this happened because two engineers optimized for “does my code work?” instead of “does the end-to-end customer experience work?”

The ROI of “Understanding Before Shipping”

Luis mentioned that system mapping and contract reviews happen before implementation. That feels slow. Product managers hate it (I did initially).

But let me share the business case:

Cost of Maya’s payment incident:

• Customer refunds: $32K
• Support team overtime: $8K
• Engineering emergency response: $6K
• Customer churn (estimated): $15K
• Total: $61K

Cost of Luis’s pre-implementation reviews:

• System mapping exercise: 2 hours
• Contract review meeting: 1 hour
• Product impact review: 30 min
• Total: 3.5 hours per feature

Even if we shipped 20 features per quarter, that’s 70 hours of upfront review time. At $150/hour blended rate, that’s $10,500.

$10.5K investment to prevent $61K incidents. That’s a 6x ROI.

And that’s just one incident. Maya’s payment issue was caught quickly. Imagine if it had gone undetected for a week.

The Misaligned Metrics Problem

Keisha nailed it: we measure what we say we value, and right now, we measure velocity.

Here’s what my product team measured last quarter:

• Features shipped: 24
• Velocity (story points): 312
• Roadmap completion: 98%

Here’s what we should have measured:

• Features shipped without critical bugs in first 30 days: 16 (67%)
• Customer-facing incidents caused by poor understanding: 8
• Support ticket volume from product bugs: 423

When I showed these numbers to our CPO, the response was: “But we hit our roadmap targets.”

That’s the problem. We’re declaring victory based on “did we ship?” not “did it work for customers?”

The Product Review Gate I’m Proposing

Inspired by Luis’s “Product Impact Review,” I’m proposing a formal gate:

“Customer Impact Assessment” (required before launch):

Engineer + PM + Support rep sit together and walk through:

1. What is the happy path customer experience?
2. What are 5 ways this could fail from a customer perspective?
3. What does the customer see/experience when it fails?
4. Can support diagnose and resolve customer complaints with available tools?
5. If the engineer can’t explain failure modes, feature doesn’t launch.

This isn’t about slowing down shipping. It’s about not shipping broken experiences.

Michelle’s Compliance Point Has Product Implications Too

Michelle mentioned SOC 2 and PCI audits flagging “I don’t know, AI wrote it” as compliance risks.

From a product perspective, compliance failures have direct revenue impact:

• Delayed enterprise contracts (customers require SOC 2)
• Blocked payment processing (PCI non-compliance)
• Reputational risk (security breaches, data leaks)

When an engineer says “Copilot wrote this code, I’m not sure how it works,” they’re not just creating a technical risk. They’re creating a business continuity risk.

That’s unacceptable at any level, but especially for payment processing, auth systems, data handling, and compliance-critical features.

The “Ship Fast vs. Ship Right” False Dichotomy

Here’s the message I keep hearing from engineering: “You’re asking us to slow down. Product wants speed.”

That’s a false trade-off.

Shipping fast but broken is slower than shipping slightly slower but right, because:

• Broken features require hotfixes (interrupts other work)
• Customer support tickets consume product/engineering time
• Incidents create emergency all-hands and post-mortems
• Refunds and churn cost revenue

Maya’s payment incident probably consumed 40+ hours of engineering time in emergency response, debugging, hotfixing, and post-mortem. That’s way more than the 3.5 hours Luis’s pre-implementation reviews would have cost.

The Incentive Realignment

If I, as a product leader, want engineering to prioritize understanding over velocity, I need to change how I measure success:

Old product metrics:

• Features shipped per quarter
• Velocity trend
• Roadmap completion percentage

New product metrics (proposed):

• Features shipped without major bugs in first 30 days
• Customer satisfaction score (post-launch survey)
• Support ticket volume per feature
• Incident rate attributable to insufficient understanding

If these become the metrics I’m held accountable for, then I’ll prioritize system understanding, contract reviews, and debugging-first culture—because those directly improve my metrics.

But if my bonus is tied to “features shipped,” I’ll keep pressuring engineering to ship fast, understanding be damned.

That’s the cultural shift required at the executive level, not just the engineering level.

The Ask From Product to Engineering

If engineering commits to:

• System mapping before implementation
• Contract reviews before code generation
• Deep understanding before shipping

Then product commits to:

• Measuring quality, not just velocity
• Protecting engineering time for comprehension
• Celebrating “shipped right” over “shipped fast”

For other product leaders: How are you adjusting your metrics to prioritize understanding and quality over pure velocity? What conversations have worked (or failed) with your engineering partners?