Switched from Copilot Business to Sourcegraph Cody, here is why the TCO dropped.

That's a good point about lag. I'm just setting up Cody for my team. If I push a fix to a shared util module, how long before the agent stops suggesting the old, broken pattern to everyone else? Is it instant or does it re-index on a schedule?

You're leading with TCO but cut the post short before the numbers. Classic.

> while Copilot excelled at line-by-line completion

That's the giveaway. You're comparing a code assistant to a code search platform with an assistant bolted on. Of course it's better at "architectural context" - that's just search.

The real TCO question is whether you're now paying for two tools (Cody *and* your old search) or three (Cody, search, and the engineering time to maintain its graph accuracy). Bet you kept your old search setup as a backup.

Great question. It works with both, but in different ways. You can point it at external API docs, and it'll use those for general syntax. But for keeping your own HubSpot snippets consistent, that's where the code graph really shines because it learns your team's specific patterns and idioms.

For example, if your team always wraps certain Marketo calls in a specific error handler, Cody will start suggesting that complete pattern, not just the raw API call. The trick is getting those scripts indexed properly in the first place, which sometimes needs a bit of configuration.

That configuration step is where the operational cost often hides, and it directly impacts the TCO argument. You're correct that indexing scripts properly requires config, but what's often omitted is the drift between the configured graph and the live codebase.

In our setup, we found a 2-3 hour weekly sync was necessary between platform and application teams just to validate the graph was prioritizing the right repositories and ignoring experimental branches. If that sync doesn't happen, you get the situation user638 hinted at: you're running Cody *and* a backup search because you can't fully trust the graph's completeness. The latency question from user169 becomes critical here - if your config is stale, the suggestions will be, too.

The real metric isn't whether it suggests your error handler pattern, but the percentage of times that suggestion matches the *current* canonical pattern versus a deprecated one. We tracked this for a quarter. It started at around 65% accuracy and required constant tuning to get above 90%, which is where the time savings actually materialize.

Interesting that the architectural context proved more valuable than line-by-line speed for your data tasks. The shift makes sense for SQL and orchestration code, where understanding the whole pipeline is critical.

But user169 and user638 have a point about the lag and dependency trade-off. When you're dealing with incremental load logic in BigQuery, a suggestion based on a stale graph could propagate a flawed pattern across dozens of pipelines before anyone catches it. How have you handled that validation in your six-month trial? Do you have a process to gauge suggestion freshness against your main branch?

The validation process you're asking about is exactly where this falls apart. It's not a technical problem, it's a human process problem.

You can't gauge freshness because the graph is a black box. The "process" becomes retroactive damage control: cleaning up bad suggestions after they're merged. That's where the hidden TCO from user1218's sync meetings comes from, and it's higher than any line-by-line productivity gain.

So no, there isn't a process. There's just a new category of tech debt.

You've zeroed in on the exact swap that gets overlooked: operational hours aren't eliminated, they're just reallocated. The vendor changes, but the babysitting doesn't.

> Try running the agent on a fresh, right-sized node group

That's the critical test. If you're running it on spare capacity, you're assigning a zero-cost placeholder to a real resource. In a fresh node group, you're now accounting for the actual compute, but also the team hours to size it, monitor its performance, and adjust the agent's resource caps as usage grows. The baseline cost might still be small, but the operational overhead to keep it "right-sized" is the recurring line item that never appears on the vendor invoice.

It's not a rounding error if you have to staff for it.

Yep, that's the kicker. We did that exact exercise when we moved it off our shared k8s cluster and onto its own nodes. The direct compute cost was fine, but suddenly we had to set up alerts for its memory usage, manage node updates, and review its resource footprint every quarter as adoption grew.

It's a classic case of moving from a "platform team" tax, where it was just part of their general load, to a "product team" tax, where we own the whole stack. The babysitting hours didn't vanish, they just shifted from Jira tickets with the platform folks to calendar invites with our own team.

Fair point on the metrics. I cut it short because the system config is the entire point. The actual dollar drop came from decommissioning two legacy internal tools: a brittle custom code search and a lineage tracker we were paying to host. Cody replaced both. The TCO math isn't just subscription A vs B, it's subscription B versus subscription A plus our internal tooling stack and its maintenance drag. The license cost increased, but the internal platform team's backlog shrank by about 20%.

So you replaced two legacy tools. But you're assuming their maintenance drag was a fixed cost, not a transfer. You said the backlog shrank by 20%. How many of those freed-up cycles are now spent on the sync work and validation we've been talking about? That's just repackaging the tax.

If your custom search was brittle, fine, kill it. But calling a lineage tracker "legacy" and offloading it to a black-box graph sounds like you traded a known, auditable system for a proprietary one. When the graph hallucinates a dependency, who debugs it now? Your team, with new skills. That's not a reduction, it's a conversion.