We built our own sales intelligence tool a few years back. It uses Diffbot KG as a primary data source. It didn't take off.

Turns out, the sales intelligence SaaS space is just a race for the least intact moral compass, and we didn't feel like dealing with that.

That said, it's pretty low maintenance and our sales team uses it. So we kept it up. Every now and then I'll get a DM from them. Here's today's:

Hey @Jerome - @jballard and I have been trying to retrieve emails for contacts at a specific company since yesterday, but it’s not returning any results — it simply redirects back to the original Email & Phone button.

Weird. I was able to reproduce the issue, and traced the error in our production logs.

File "/<redacted>/leadbot/contacts_lookup.py", line 474, in getEmailDomain 
sdom, dom, suf = extract(emailDomain) # just get the "root" domain 
^^^^^^^^^^^^^^ 
TypeError: cannot unpack non-iterable ExtractResult object

Looks straight forward enough. I tracked the line down in VSC, then pasted the error into Claude Code (via the VSC plugin) as a cold prompt. Here's Claude:

ExtractResult is a named tuple, so it unpacks fine — but only into its fields in order: subdomain, domain, suffix. The issue is likely a newer version of tldextract changed the ExtractResult to include a 4th field (is_private), making 3-value unpacking fail.

Eh. I didn't like that answer. I refused its edit and told Claude to verify this behavior for tldextract==5.3.0, which I pulled from requirements.txt.

It ran tldextract on a separate shell, finding that it's still returning a 3 field named tuple. In addition, it also found a registered_domain property that could be substituted in instead.

Claude already struck once, so I once again declined this edit and looked up the property myself.

It did exist once until it was deprecated in 5.3.0, functionally renamed to top_domain_under_public_suffix. I passed this URL to Claude.

Confirmed — ExtractResult was migrated from a namedtuple to a dataclass in v5.0.0, so tuple unpacking no longer works. The fix is to access fields directly:

Something's off about all this. Why does the code use the named tuple instead of an easily accessible property? Why is Claude burning tokens chasing its own tail?

⌥-click, my favorite VSC shortcut, to the rescue. Looking through the tldextract source in my site-packages directory, I found what I was looking for:

__version__ = '3.1.2'

I'm surprised Claude didn't pick up on the version mismatch. None of its greps ever accessed tldextract's source directory. I also gave it plenty of "hints" about the version I was targeting.

Guess I still have a job.

Stats

Token usage stats and cost compiled using npx ccusage.

• Days Working on Task: 1
• AI Dev Evolution Stage: 2
• Total Input Tokens: 1,365
• Total Output tokens: 3,523
• Total Tokens (including cache): 1,786,990
• Total API Cost: $1.01

Nevermind I figured it out.

See you on Vibe Log #3.