Two CTOs at a Bar
An overheard conversation. Names changed. Details composite.
MARA is the CTO of a 400-engineer fintech. She rolled out Cursor company-wide six months ago. DEV is the CTO of a 180-engineer healthtech. He has not. They are two beers in.
MARA: So you're really not letting your team use Cursor yet.
DEV: I'm not blocking it. I'm not rolling it out. There's a difference.
MARA: That's the same thing in practice. Half your team is already paying out of pocket and not telling you.
DEV: Probably more than half. I've seen the expense reports get creative.
MARA: So just roll it out.
DEV: The day I formally roll it out is the day I own what they paste into it.
MARA: Wrap it. Self-hosted scrubber, audit log, allow-list of repos. Done.
DEV: Cost me a quarter to build that. Cost me another quarter to maintain it once a model provider changes its API and the scrubber breaks silently.
MARA: Meanwhile your engineers are thirty percent faster.
DEV: That's the part I want to talk about. Because I don't think they are.
MARA: [laughs] Come on.
DEV: I'm serious. The studies that say thirty percent — what are they measuring?
MARA: Pull request throughput. Lines of code. Time to first commit on a ticket. Pick one.
DEV: Right. All of which go up. And then?
MARA: And then? We ship faster.
DEV: Do you ship better? Or do you ship more?
MARA: [pause] Both. Mostly more.
DEV: More of what, though.
MARA: Features. Bug fixes. The work you'd be doing anyway, just done faster.
DEV: Or, the work you'd be doing anyway plus a long tail of stuff someone wouldn't have built without the tool. Some of which is good. Some of which is a new microservice no one needed because the AI made it cheap to make a new microservice.
MARA: That's a process problem. Not a tool problem.
DEV: It's both. The tool changes what's cheap to do. What's cheap to do gets done more. What gets done more isn't always what should be done more.
MARA: OK. Steelman it. What does the tool change that you'd actually want to push back on?
DEV: It changes who knows the code. My senior engineers used to know the codebase because they'd spent years building it. My juniors used to know small parts of the codebase because they'd been guided through it by the seniors. Now everyone has a tool that pretends to know the codebase. Which means everyone trusts it a little. Which means the depth of understanding across the team is shallower than it looks.
MARA: Or — everyone gets up to speed faster.
DEV: Up to speed at what? Reading code the tool wrote? That's not understanding the system. That's reading.
MARA: [drains glass, signals for another] OK. So you think there's a knowledge debt building up.
DEV: I think there might be. And nobody is measuring it because the metric everyone's looking at is throughput. Throughput is going up. So we're declaring victory.
MARA: What would you measure instead?
DEV: I don't know yet. Time to root-cause a production incident, maybe. Bus factor on a critical path. Number of times someone has to revert a change in the first week. Things that show whether the team actually understands what's running.
MARA: Those are hard to measure.
DEV: Yeah. The hard things are usually the ones worth measuring.
[A long pause. The second round arrives.]
MARA: Here's where I'll give you something. The other thing I worry about. Pricing.
DEV: Go on.
MARA: I'm paying twenty bucks a seat right now. Four hundred engineers. That's a hundred grand a year. Pocket change.
DEV: And in eighteen months?
MARA: In eighteen months, the vendor knows my engineers can't work without it. They know which features my team uses every day. They know my procurement cycle. They have all the leverage.
DEV: What's the over-under?
MARA: I'd guess we get a fifty to a hundred percent price increase within two years. Maybe more if the agentic features actually become load-bearing in my dev workflow.
DEV: Have you modeled it?
MARA: I've modeled what it would cost to take it away.
DEV: And?
MARA: It would be a riot. Six months of throughput loss. People would quit.
DEV: So you're locked in.
MARA: I'm locked in.
DEV: And every productivity gain you got, you got at the cost of being locked in.
MARA: Yeah.
DEV: So is the productivity yours, or is it theirs?
MARA: [long silence] That's a clean way to put it.
DEV: It's the same question as cloud lock-in. Same question as Oracle in 2005. Same question every time. You take the gain because it's right there. You pay for it later and you don't get to pick when.
MARA: What's the alternative? Self-host an open-weight model and pretend that's the same product?
DEV: Not the same product. Not as good. Maybe close enough.
MARA: Close enough for whom?
DEV: For an engineer who's been doing this for fifteen years and has good taste. For an engineer with two years of experience, the gap is bigger.
MARA: Which is most of my company.
DEV: Which is most of everyone's company. That's the lock-in mechanism. The product is most useful for the people with the least leverage to switch.
MARA: [exhales] Yeah.
[The bartender brings the check. Neither of them touches it.]
MARA: I'm not going to roll it back.
DEV: I know you're not. I wouldn't either, in your seat.
MARA: But you're going to keep not-rolling-it-out.
DEV: I'm going to keep telling my team they can use it for non-PHI work, on company-paid licenses, through our scrubber, in repos that are tagged for it. And I'm going to keep talking about why some of our code is going to keep being written without it.
MARA: That's a lot of asterisks.
DEV: I'm in a regulated industry. The asterisks are the job.
MARA: [smiles] You ever notice that's the answer to everything in healthtech?
DEV: Yes. And it's getting more true, not less.
[They split the check. They walk out. Mara goes left, toward the BART station. Dev goes right, toward the parking garage.]
The conversation doesn't resolve because the question doesn't resolve. There are two real positions here, and the right answer depends on which industry you're in, what your engineers are working on, how much of your leverage you're willing to trade for speed, and whether you trust the vendor to be a partner in eighteen months or to act like a vendor.
Most of the public debate about AI coding tools is about the engineers — whether they're faster, whether they're better, whether they'll be replaced. The leadership debate is upstream of that. It's about who captures the value, and about whether the value is what the dashboards say it is.
Dev's skepticism has evidence behind it. In METR's randomized controlled trial, published in July 2025, sixteen experienced open-source developers completing 246 tasks in repositories they knew well took 19% longer when AI tools were allowed, while believing afterwards that the tools had made them about 20% faster. The 2024 DORA report found that a 25% increase in AI adoption was associated with an estimated 7.2% decrease in delivery stability. Neither result settles the question for your team. Both are reasons to measure outcomes rather than throughput before deciding whose balance sheet the gain is on.
If you're rolling these tools out today, you are betting that the price holds, that the lock-in is acceptable, that your team's understanding doesn't erode in ways you'll notice too late. Those bets might be fine. They might be the right bets. But they are bets. The press releases will not call them that.
Two CTOs at a bar, two beers in, can call them that. That's why these conversations happen at the bar.
If you're the one making this call, Dev's measures are a reasonable start: time to root-cause an incident, bus factor on critical paths, and first-week reverts. For the tool choice itself, see our honest comparison of Cursor, Copilot and Claude Code; for what to check on every AI-authored change, see What AI-Generated Code Structurally Skips.
Sources
METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (July 2025): randomized controlled trial, 16 developers, 246 tasks; 19% longer with AI allowed. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
DORA / Google Cloud, Accelerate State of DevOps Report 2024 (October 2024). https://dora.dev/research/2024/dora-report/
Part of the Engineering Leadership guide — ShiftQuality's complete map to leading engineers.
