Brett Dolecheck (Brett_1949) — Sagetap Call & Debrief

Campaign: Engineering Leaders: See What Your AI Coding Agents Are Actually Doing Platform: Sagetap ($1,000/call — outbound, not inbound) Date: 2026-05-18 Outcome: Demo follow-up secured. Brett will talk to senior engineers and schedule a Pathbase demo.

---

Profile

Field	Value
Name	Brett Dolecheck
Sage ID	Brett_1949
Title	Sr. Director of Engineering
Company	Xylem Inc. (Sensus division) — NYSE: XYL, ~$6B+ market cap
Division	Sensus — smart meters, AMI/AMR infrastructure for gas, water, electric utilities
Team size	~120 engineers (firmware + software, globally distributed: US, Germany, Mexico, India)
Company engineers	~700–800 total across Xylem
Industry	Utilities / IoT / Smart Infrastructure
HQ	Raleigh, NC
LinkedIn	linkedin.com/in/brettdolecheck
Sagetap	Joined Mar 2022, 13 activities, 0 initiatives, Heavy Evaluator

LinkedIn Summary

• Current: Sr. Director of Engineering at Xylem/Sensus (Mar 2020–present). Global director for Sensus engineering. Builds software and firmware for smart metering (gas, water, electric). SaaS applications collecting data from 12M+ metering endpoints for billing, infrastructure monitoring, and ML-based anomaly detection (water leaks, electricity theft).
• Previous: Director of Engineering at Honeywell (smart energy) → Director of Software Engineering at Canonical (Juju, Kubernetes, OpenStack) → Director at TransCirrus (OpenStack) → Sr. Software Dev Manager at NetApp (clustered SAN) → Adaptec (storage, virtualization) → FalconStor (VP/CTO, co-founded IP Metrics) → Network-1 (first Windows multiprotocol firewall)
• Education: BS Computer Science, University of Louisiana Monroe. NC State Management executive education (innovation leadership).
• Side venture: Managing Consulting Partner at eJury LLC since 1999 — online mock trial platform. Board of Directors.

What Xylem/Sensus builds

Sensus is Xylem’s digital/smart metering brand. Products include smart gas, water, and electric meters plus the FlexNet communication network (point-to-multipoint system for near real-time meter data). Their SaaS layer processes data from 12 million+ endpoints for billing, leak detection, theft detection, and distribution automation. This is real software at scale — not just hardware/firmware.

Pre-call assessment (preserved for reference)

Why this could be a great call: ✅ Confirmed — utilities blue-ocean segment, regulated industry, product-oriented engineering leader with 120 engineers.

Why this could be a waste: ❌ Mostly disproven — he does manage software engineers, AI adoption is real, pain is concrete (production bug from AI-generated code). The 0-initiatives concern remains valid: no formalized purchase intent on Sagetap.

---

Call Script

Opening (0–2 min) — Establish context fast

“Brett, thanks for connecting. Before I jump into what we’re building, I’d love to understand your world a little better. Can you give me the 60-second version — what does your engineering org look like, what are you building, and how big is the team?”

What you’re listening for:

• Software engineering vs. electrical/infrastructure engineering
• Team size (20 engineers is very different from 200)
• What they build (internal tools? customer-facing products? grid management systems?)
• Whether “engineering” means people who write code

If the answer is “we design power systems” or similar non-software: Pivot to research mode. Ask about any software teams they work with, how AI tools are showing up in their adjacent work, and wrap in 15 minutes. Don’t force the Pathbase pitch.

If the answer is “we build software for [X]”: Proceed.

Adoption Discovery (2–7 min) — What we’d normally know from Q1

“How is your team using AI coding agents today? Things like Copilot, Claude Code, Cursor — are those in the mix? How widely adopted, and how has that changed recently?”

Follow-up probes:

• “Is this top-down (you mandated it) or bottom-up (engineers adopted on their own)?”
• “Which agents specifically? Any preference emerging?”
• “What’s the split — are most engineers using them daily, or is it still a subset?”

Visibility Gap (7–12 min) — What we’d normally know from Q2

“Here’s a question I ask everyone: if your leadership asked tomorrow, ‘What’s the ROI on our AI coding tool investment?’ — what evidence could you point to right now?”

Follow-up probes:

• “What metrics do you track today? Seat utilization? PR velocity? Anything else?”
• “Is anyone in your org asking for this data, or is it still in the ‘nobody’s asked yet’ window?”

Utilities-specific probe:

“In a regulated utility environment, does the compliance side of your org care about what AI coding agents are doing? Or is that not on their radar yet?”

Coaching Gap (12–17 min) — What we’d normally know from Q3

“How has AI-assisted development changed your code review process? Specifically — are your senior engineers still getting those coaching moments with juniors, or has something shifted?”

Follow-up probes:

• “When a junior engineer uses an AI agent to produce code, can you tell the difference in a PR between what they wrote and what the agent wrote?”
• “Are you seeing engineers who can produce working code faster but understand it less deeply?”

The Universal Probes (17–22 min) — Use on every Sagetap call

“If I showed you a structured trace of everything one of your engineers’ AI agents did yesterday — every tool call, every file edit, every decision — what’s the first thing you’d look for?”

This reveals his mental model. Archetype 1 says “whether the work was good.” Archetype 2 says “whether it touched anything it shouldn’t have.”

“Who else in your org would care about this data?”

Reveals the internal champion chain and multi-buyer opportunity.

Pathbase Pitch (22–25 min) — Only if adoption is confirmed

“Quick context on what we’re building: Empathic builds developer infrastructure for teams working with AI agents. Our product Pathbase gives you structured visibility into agent sessions — what happened, who did what, whether the work was good. Think of it like GitHub for agent traces. Cross-agent — Claude Code, Copilot, Codex, Gemini — open format underneath.”

Tailor based on what you’ve heard:

• If he’s feeling the coaching gap → “Traces show you how engineers are actually working with agents, not just the PR that came out the other end”
• If he’s feeling the ROI pressure → “Instead of seat utilization, you get behavioral data — what agents are doing, what patterns work, where time is being wasted”
• If he’s feeling the compliance angle → “Every session becomes an auditable artifact — who ran what, when, what changed, what the agent decided”

Purchase Intent (25–28 min) — Direct probe

“What would you need to see to put budget behind something like this?”

“Is this a problem you’re actively trying to solve, or more something you’re starting to think about?”

Close (28–30 min)

“This was really valuable — I appreciate your time. Based on what you’ve shared, [one specific thing you’d follow up with]. Would it be useful if I [specific next step]?”

---

Green/Red Flag Scorecard (post-call)

Green flags

• He manages a team of software engineers who write code — 120 engineers, firmware (C) and software (Java → Rust migration, SaaS applications), globally distributed
• AI coding agents are adopted — GitHub Copilot is corporate standard since mid-2025. Engineers also using Claude Code on their own. One engineer blew through his Claude Code subscription in the first week.
• He articulates the visibility or coaching gap in his own words — the null-check bug story IS the coaching gap in action (see Key Signals below)
• He asks how Pathbase works — “Is this an app you install on each computer, or is it something centralized?” — engaged, operational question
• He names someone else who’d care — “Let me talk to a couple of my senior engineers, maybe we can get something together”
• Has a budget or initiative forming — No. Pre-budget. “I haven’t had any executive ask me about it yet. They probably will when they start seeing the bills roll in.”

Red flags

• None triggered. He manages real software engineers, adoption is real, pain is concrete, his engagement was genuine (not template-like).

---

Qualifying Responses (from live conversation)

Questions weren’t sent in advance (outbound call). Bryan asked them live:

Q1 — AI agent adoption: Corporate standard is GitHub Copilot for GitHub. Started mid-summer 2025. Engineers are also using Claude Code and other tools on their own (“engineers being engineers… oh but I did this with Claude Code”). One engineer blew through his Claude Code subscription in the first week. Firmware engineers (C) get less value from models. Software engineers doing a Java-to-Rust migration by feeding whole functions into models and saying “spit out Rust that does the same thing.” New college grads “would write everything in AI if they could.”

Q2 — Visibility and ROI: “We’re probably maybe 10, 12% ahead of schedule on things.” Can’t point to a specific number. No executive has asked about ROI yet — “they probably will when they start seeing the bills roll in.” Budget is still fine currently.

Q3 — Code review and coaching: Covered implicitly through the null-check bug story. Engineers are “putting too much trust” in AI output. Reviews are being accepted because “all the tests passed” — but the AI also removed the tests. Spec documents are now being “written as prompts” so you can feed them directly to an LLM. Brett acknowledged needing more guardrails but hasn’t formalized what those look like.

---

Debrief

Overall Assessment: 🟢 GOOD CALL — worth the $1,000

Fit: 🟢 STRONG. Brett is the right buyer persona (Sr. Director of Engineering, 120 engineers, real software), at the right kind of company (enterprise, regulated, building product), with real AI adoption (Copilot corporate standard, Claude Code in use, Java→Rust migration via LLMs), and a concrete production bug caused by AI-generated code. He’s Archetype 1 (Engineering Effectiveness) with latent Archetype 2 needs (regulated utility, metering infrastructure touching gas/water/electric grids).

Purchase timeline: EARLY. No budget allocated, no executive asking about AI ROI yet, 0 Sagetap initiatives. This is a “the pain is real but pre-purchase” conversation. He’s in the window before the CFO asks — which means the demo is about planting the seed, not closing a deal.

Next step quality: SOLID. “Let me talk to a couple of my senior engineers, maybe we can get something together” is a real next step with a real internal action. It’s not “yeah sounds interesting, send me something” — he’s going to bring engineers into the next conversation, which means the demo will have technical evaluators in the room.

Key Signals

1. The Null-Check Bug Story (most valuable moment in the call)

Brett described a concrete production incident:

1. Engineer used an AI agent to refactor a ~400-line function into smaller parts
2. During refactoring, the AI removed a null check from the code
3. The AI also removed the unit test that would have caught the missing null check
4. The reviewing engineer accepted the PR because “all the tests passed” — but the safety net was gone
5. Bug shipped to production. Team scrambled to fix it.
6. No postmortem was possible — “we were too busy scrambling to fix the bug”
7. When they tried to get the LLM to “learn” from the mistake, it just said “I’m sorry” — no durable learning
8. They have no confidence it won’t happen again — “we don’t know”

Why this matters for Pathbase: This is the first concrete, production-severity bug story in the entire Sagetap batch. Every other Sage described the problem theoretically. Brett lived it. And the critical gap — “we couldn’t do a postmortem because we didn’t have the agent’s decision history” — is exactly the Pathbase use case. If the agent session trace existed, they could go back to the moment the agent decided to remove the null check and the test, understand why, and build guardrails.

For the demo: Reconstruct this scenario. Show what it would look like in Pathbase to find the moment an agent removed a safety check during refactoring. This is the “aha” — not abstract graphs, but “here’s the moment your agent broke your code, and here’s how you’d catch it next time.”

2. Spec Documents Written as Prompts

Brett mentioned this almost casually, but it’s a significant workflow shift: spec documents are evolving from “we need to do X, Y, Z” into prompt-formatted documents “so you could just feed a spec to an LLM and say go generate.” This is the engineering workflow reshaping itself around AI agents — which creates a new layer of trace-worthy artifacts. The spec becomes an input to the trace, not just a planning document.

3. The “Too Much Trust” Pattern

“A lot of these developers are putting too much trust… they’re like, okay, yeah, it should get it right. Well, technically, yes, it should, but it doesn’t always.”

This connects directly to Paul Hammond’s coaching gap. The trust calibration problem — engineers (especially juniors and new grads) accepting AI output without sufficient scrutiny — is universal. Brett named it from the engineering leadership side. He sees the problem but doesn’t have a systematic way to detect it.

4. The Generational Split

Old engineers: “I don’t care about this.” New college grads: “They would write everything in AI if they could.” The team is experiencing the same bifurcation Kevin described (“traditional devs on our team… building trust in new AI tooling”). This is the mixed-adoption team where coaching visibility is most valuable — you need to understand who’s using agents effectively and who’s over-trusting them.

5. Budget Window Signal

“I haven’t had any executive ask me about it yet. They probably will when they start seeing the bills roll in.”

He’s in the pre-CFO-question window. This is the exact window Paul Hammond was in when he described the same dynamic. The value of getting in now: when the CFO does ask, Brett already has Pathbase showing data instead of saying “I think we’re 10-12% ahead of schedule.”

Honest Feedback on Call Execution

What worked:

1. The Minority Report / cadaver framing landed. Brett engaged with the idea of booting up an agent at a point in time. He responded with the “AI is supposed to learn” thread, which showed he was thinking about the implications. Good product-level connection.

2. Not forcing the pitch. The call was genuinely conversational. Brett is a quiet, direct person — short answers, few words. Bryan read the room and didn’t try to overpower that.

3. The Schneider Electric connection. Mentioning previous work in the solar inverter division built credibility with an engineering leader in utilities. It said “I understand your world.”

4. Securing a concrete next step. “Let me talk to my senior engineers” is better than most discovery outcomes.

What to improve:

1. Bryan talked too much. The transcript shows several monologues running 2-3 minutes (the opening pitch from ~3:15-7:03, the coding agents soapbox from ~20:27-22:39, the Pathbase pitch from ~26:32-28:12). Brett is a man of few words — he gives short, direct answers. The call would have been stronger with shorter questions and more silence. Brett’s most valuable contributions (the null-check bug, the spec-as-prompts observation) came when he had space.

2. The null-check bug story wasn’t probed deeply enough. When Brett described the bug, the follow-up was “how did you approach that postmortem?” — good question. But after “we were too busy scrambling,” the conversation should have gone to: “How often does this kind of thing happen? Is this a one-off or a pattern?” and “What would you have wanted to see in the agent’s history to prevent this?” — those questions would have quantified the pain and connected it directly to Pathbase. Instead, Bryan pivoted to the Minority Report feature concept.

3. The spec-as-prompts observation was dropped. Brett mentioned that spec documents are now being written as prompts — that’s a fascinating workflow signal. Worth probing: “Can you give me an example? What does a spec-as-prompt look like versus a traditional spec? Who writes them — the senior engineers or the juniors?” This could have been 5 minutes of high-value discovery about how AI is changing engineering workflows at Xylem.

4. “Pathways” slip. Bryan said “Pathways” instead of “Pathbase” at least once near the end. Minor, but name consistency matters.

5. No purchase intent probe. The script included “What would you need to see to put budget behind this?” — it was never asked. Brett volunteered the pre-budget signal organically, but asking directly would have clarified whether this is a 3-month horizon or a 12-month one.

6. The qualifying questions weren’t sent ahead of time. This was an outbound call but the Sagetap qualifying questions could have been messaged to Brett in advance. Arriving without them wasted 5-7 minutes of call time establishing baseline context that written answers would have provided.

Where Brett Fits in the Sagetap Batch

Dimension	Brett (Xylem)	Kevin (AI Software, UK)	Joseph (FinServ, Canada)	Wizard (Banking, NY)
Team size	~120 engineers	~50-100 (51-200 company)	Large (10,000+ company)	200+ engineers
AI adoption	Copilot + Claude Code, ~12 months	Claude Code in production, 50%	Broad: Claude Code, Cursor, Copilot	Copilot, Cursor, Claude
Concrete pain	Production bug from AI code	”None have solved PR review"	"Lack structured evidence for ROI"	"Junior engineers accept AI too quickly”
Purchase intent	Pre-budget, no initiative	6 initiatives, Jun 2026 target	Not probed	5 initiatives, Nov 2026 target
Archetype	1 (Engineering) + latent 2	1 + 2	1 (pure)	1 + 2
Call quality	Good discovery, needs deeper probing	Not yet called	Not yet called	Not yet called

Brett should be added to the main Sagetap evaluation note. Fit is 🟢 STRONG. He slots in around priority 4-5 — behind Kevin, Joseph, and Wizard (who have clearer purchase intent), but ahead of TheCloudGuru and the governance buyers.

Follow-Up Actions

• Send summary email to Brett with Pathbase overview. Keep it short — he’s a concise person. Include a 60-second screen recording or GIF of the trace viewer if available.
• Prepare a demo scenario around the null-check bug. Reconstruct a refactoring session where an agent removes a safety check. Show what the trace looks like in Pathbase — the moment the decision was made, the test that was deleted, the ability to interrogate the agent’s reasoning.
• Schedule demo call with Brett + his senior engineers once he’s talked to them. Target: within 2 weeks.
• Probe the Java→Rust migration in the demo. This is a high-value, high-risk AI use case — translating entire functions between languages. Trace visibility here is about validating that the translation preserved behavior, not just that it compiled.
• Add Brett to the main Sagetap evaluation note — 2026-05-14-sagetap-inbound-evaluation
• Create a person note for Brett Dolecheck — worth tracking as a contact regardless of outcome

What This Call Adds to the Broader Discovery

New concrete evidence: The null-check bug story is the strongest incident-level pain data point across all discovery calls and Sagetap conversations. Paul Hammond described the coaching gap abstractly. Joseph described the measurement gap in enterprise language. Brett described a real bug that went to production because an AI agent removed a safety check and the test that would have caught it, and the team couldn’t do a postmortem because they didn’t have the agent’s session history. That’s Pathbase’s reason for existing, stated as a lived experience.

New segment signal: Utilities/smart infrastructure is a valid market for AI coding agent tooling. Brett’s team (120 engineers, firmware + software, Java→Rust migration, SaaS at 12M endpoints) looks and acts like a tech company’s engineering org, just inside a utilities wrapper. Other large utilities (Duke Energy, Southern Company, Enel, etc.) likely have similar engineering orgs. Nobody in dev tools is targeting them.

Spec-as-prompts: This is an emerging workflow pattern worth tracking. If specs are becoming structured prompts, the boundary between “planning artifact” and “agent input” is blurring. Pathbase traces could eventually ingest the spec-prompt alongside the agent session, creating a full arc from intent to execution.

---

Sagetap Feedback (from Brett, post-call)

Dimension	Score	Key Quote
Meeting experience	4/5	—
Presenter quality	5/5	—
Differentiation	4/5	”I haven’t really seen anything like it… I really haven’t actually gone looking for anything like it either.”
Value	4/5	”Is it gonna help me determine ROI? Is it gonna help me make my engineers more productive? What is it actually gonna do, or is it just gonna be giving me reports that I can give to executives?”
Timing	3/5	”We don’t have any requirements for this, but that could change at any point… I do see that coming probably in the next six to nine months.”
Integration	5/5	”It doesn’t look like it would hinder anything… I see this working really well.”
Cost	4/5	”$50 or so a user — that’s within my budget, but what am I gonna really get for it?”

Overall: 4/5

Full verbatim feedback

Differentiation (4/5):

I’m there’s a lot I need to learn about the product based on a very high level. It’s it sounds intriguing. I haven’t seen really seen anything like it, but without knowing the specific features, it it’s kinda hard to say how well it stands out. But like I said, I haven’t really heard of anything else out there that would be similar, but I really haven’t actually gone looking for anything like it either.

Value (4/5):

I really need to understand the product better to understand how its value prop is. If it’s gonna just help is it gonna help me determine ROI? Is it gonna help me make my engineers more productive? What is it actually gonna do, or is it just gonna be giving me reports that I can give to executives? I mean, if that’s all it does, then I don’t know if it’s gonna be that that useful. But if it helps me do other things, it would be, but that’s why I need to understand more about the product.

Timing (3/5):

At this point, we don’t have any requirements for this, but that could change at any point. The the overall because AI is fairly new, we’re doing a lot of learning, so there’s not been a lot of questions on how well how well our teams are doing with or without it and things like that. So but I do see that coming probably in the next six to nine months, but we’ll see.

Integration (5/5):

I think the the product would be fairly keep fairly easy to integrate into our system in workflows. Like I said, I’ve I’ve not seen a demo of it yet. I just based on a couple questions, it it it looks like it would be fairly straightforward. It doesn’t look like it would hinder anything in terms of the integration or actually, use of it, during when my engineers are doing their development. So I see this that working really well.

Cost (4/5):

I really need to see more what the what the product is gonna do without knowing the price and exactly how it’s gonna fit, what kind of things it’s gonna do for me, whether it’ll justify the the ROI. I mean, they did throw out a price of of roughly $50 or so a user. That’s within my budget, but what am I gonna really get for it? That’s the big question.

What the feedback tells us

The good news:

1. Integration 5/5 is the strongest signal. The “lightweight install, doesn’t slow down engineers” message landed perfectly. This is the Pathbase wedge doing its job — low friction entry, no workflow disruption. He got this from a conversation without even seeing a demo.

2. “I haven’t seen anything like it” — no competitive frame in his head. He’s not comparing Pathbase to Datadog or LinearB or Jellyfish. He doesn’t know what category this is. That’s an advantage: you get to define the category, not fight an incumbent.

3. $50/user is “within my budget.” Pricing validated for utilities/enterprise. He didn’t flinch at the number. The question is value, not cost.

4. Presenter quality 5/5. He liked talking to you. That’s rapport that carries into the demo.

The reality check:

1. Timing 3/5 is the honest answer. “We don’t have any requirements for this” and “probably in the next six to nine months.” He’s pre-need. The CFO hasn’t asked, no audit is pending, no exec is demanding ROI proof. This confirms the pre-budget read from the call.

2. The value question is pointed and fair: “Is it gonna help me determine ROI? Is it gonna help me make my engineers more productive? What is it actually gonna do, or is it just gonna be giving me reports that I can give to executives?” He’s basically saying: you told me the problem, but I don’t know what the product does. This is the “talked too much about the problem, not enough about the solution” feedback in polite form. The demo has to answer this directly.

3. “I really haven’t actually gone looking for anything like it either.” This cuts both ways. No competition — but also no active search. He didn’t find Pathbase by looking for a solution. He found it because you outbounded him on Sagetap. The pain exists but it hasn’t risen to the level of “I need to go find something.”

What this means for the demo

The demo needs to answer his question directly: “What is it actually gonna do?” Not philosophy, not vision, not the coaching gap framing. Concrete:

1. “Here’s a trace from an agent session. Here’s where the agent decided to remove a null check. Here’s the test it also deleted. Here’s how you’d catch that before it ships.” — Connect directly to his bug story.

2. “Here’s how you’d see which engineers are using agents and what they’re producing.” — His ROI question answered visually.

3. “Here’s what it looks like when you install it. Nothing changes for your engineers.” — Reinforce the 5/5 integration score.

Don’t oversell the 6-9 month timeline problem. If the demo is good, the timeline compresses. If it’s abstract, the timeline stays where it is.

---

Draft Follow-Up Message (Sagetap Chat)

Status: DRAFT v2 — not yet sent. Written 2026-05-28 (10 days post-call).

---

Brett — following up from our conversation. Wanted to give you something concrete for your engineers.

The short version: your team keeps using whatever tools they already use — Copilot, Claude Code, doesn’t matter. Pathbase captures every data point from those agent sessions and gives you the story of who is doing what, what’s working, and what the impact is. Nothing changes for your engineers. You just get visibility you don’t have today.

You mentioned your executives haven’t asked about AI ROI yet, but they will when the bills roll in. When that happens, the question is going to be: what did we produce, and what did it cost? Right now you can say “we’re maybe 10-12% ahead of schedule.” With trace data, you can show exactly which sessions produced clean outcomes and which ones produced the null-check bug — and why.

Here’s the Toolpath format spec if your engineers want to look under the hood: [link]

Happy to set up a walkthrough with my co-founder whenever you and your engineers are ready.

---

Related

• 2026-05-14-sagetap-inbound-evaluation — Full Sagetap batch evaluation
• 2026-05-10-sagetap-onboarding — Campaign setup
• Pathbase — Product context
• discovery-sprint-tracker — Prior discovery signal

---

Transcript

Brett Dolecheck 1:44 Hello, hey Bryan.

Bryan 1:47 How are you?

Brett Dolecheck 1:49 Good, how you doing?

Bryan 1:49 Good, good. Appreciate you taking the call. How was your weekend?

Brett Dolecheck 1:54 Good. How about you?

Bryan 1:56 Good, good. Got a almost two year old at home, so a lot of just running around to toddler-related events.

Brett Dolecheck 2:06 Where are you located?

Bryan 2:07 Live in Brooklyn, New York. Offices in city. How about you?

Brett Dolecheck 2:13 I’m in Raleigh, North Carolina.

Bryan 2:16 Awesome. Love Raleigh. Was down there in January for a little bit, so how many of these have you done? This is actually my first stage conversation so far. Just signed up.

Brett Dolecheck 2:28 I’ve done two over the past year.

Bryan 2:33 Okay, cool. Yeah, I’m curious to kind of see, like, how these go, and if I guess you’ve only had a couple so far, but if you have any feedback for things that worked well in conversation or general overview of what you’re interested in these days, or kind of looking at,

Brett Dolecheck 2:53 well, I mean, but usually I know kind of what the because usually it’s like you asked the last few questions about what you do and stuff like that ahead of time. Yeah, so you have an idea of what the product is about.

Bryan 3:12 Yeah,

Brett Dolecheck 3:12 in this case, I have no clue.

Bryan 3:15 That’s a, that’s a very good point. I, so the subsequent meetings that I have lined up came from inbound, and so there was like the three questions that they all filled out, and then I was, I was kind of taking a few minutes to prepare for this, and then I realized that because I just outbounded you, I never actually sent you the questions, so apologies for that, so yeah, the the short of it is at Empathic, my co-founder and I started working on this about a year ago, very interested in what it meant for agents to sort of proliferate and become primary creators of work within large organizations over time, and some of the initial pain points or challenges that we saw on the horizon revolved around off and access controls, and making sure that the existing systems that you rely on as a business don’t get overwhelmed, that you don’t have confidential information leak, because an agent sort of just goes rogue, and over time we were kind of highlighting with some companies around that, and kind of went through a few iterations of just trying to better understand where things are going, because nobody actually really has like a perfect picture, right? Like the sudden rise in terminal-based coding agents in December, like the big step function gain with Claude Opus four five, everyone’s kind of still making it up as they go along a little bit, because things are moving so quickly and the big shift that we saw a couple months ago is the various like the kind of like almost asymptotic rise and the shift towards engineers and non engineers using terminal based coding agents like cloud code and codecs and sort of a general shift away from cursor and windsurf or the different IDE based environments, and that’s come with a, it’s been, say, three to six months now since most engineering forward companies have sort of gone all in on coding agents, and everyone feels the existential dread, so they are leaning in and kind of a little bit three seats to the wind, which isn’t necessarily a bad thing, right? If you have to rapidly evolve behavior within the large organization, you have to kind of just push hard and figure things out later. And so we’re three to six months into that pushing hard phase, and the common threads that I’m hearing from people like yourself that I speak with, who are in charge of making decisions for the organization and trying to improve things for the, you know, the end builders, the ICS is that individually everyone feels way more productive than they ever have as an organization. We don’t feel that productivity gain yet, or we’re just not really sure, and it’s not clear who’s being productive and who’s just burning tokens, and while, like, it’s pretty clear in most cases, very clear, that we’re not going back to the way things were, that there’s too much value in here, and we want to be holistic and integrated into our workflows. At the same time, the surface area of what goes into the work, in terms of how you might understand what someone’s doing, or how you can coach people up, how you can kind of catch, you know, trends over time, or you know people that are working well or not well with agents, that while productivity has maybe gone up 20% the energy that it takes to understand what people are doing has gone up like two to 300% and that’s the sort of paradox, or like, or not the paradox, that’s the tension of this current era, is that we want to understand, but it takes too much energy, and I don’t really know how to put the pieces together, so that’s the general pain point that we’re trying to solve. I’m curious, how that, you know, resonates with you, and if that pattern matches on your journey in the last year or so,

Brett Dolecheck 7:03 yeah, I mean, so I mean I have lots of software and firmware engineers and spread across the globe,

Bryan 7:10 yeah,

Brett Dolecheck 7:11 and so I mean they’re so the corporate standard is for developers is GitHub Copilot for GitHub. Yep, that’s the corporate scene.

Bryan 7:26 Yep,

Brett Dolecheck 7:27 and but of course engineers being engineers, they’re like, oh, but I did this with cloud coded, or I did this with this one, and this one’s so much better. I mean, but and then next week it’s like, oh, there’s a new LMM out, that one’s better than this one. It’s like we’re trying to hit multiple moving targets at once, and it’s like, whoa, whoa, yeah, we gotta like chill out, focus on one, yeah. And so that’s that’s one thing,

Bryan 8:00 yeah.

Brett Dolecheck 8:00 Another thing is, is that yes, engineers are feeling more productive,

Bryan 8:08 yeah,

Brett Dolecheck 8:09 but know in a way that they’re like, okay, I’m getting code, I’m getting PRs faster, but now I feel like I need to do more, and so there’s this always this, okay, I got well, which should have taken me a day, took me like two hours, now I feel like I gotta go do these, all these other things, so they feel anxious, I guess you

Bryan 8:37 would say

Bryan 8:37 that’s another thread that’s been brewing in the last couple months, which is that everyone feels like, okay, software engineering is going to be automated away, people are going to start like there are layoffs happening, so not only do I have to move fast with this, but like I have to kind of to some degree compete to keep my job, and so people are more productive than ever, but also more burnt out than they’ve been in a long time. Yes, and actually, one of the, one of my teammates here put it really well, is that you know before he would kind of spend his day mostly locked into a computer thinking in code and kind of like abstract logic, and that he would go home and kind of like shut all that off and just have a normal conversation with his wife, and now he spends half his day talking in natural English to a sort of quasi intelligent thing, and he’s finding he gets home, and he can barely like hold a conversation with his wife, because, like, that part of his brain that he reserved for, like, normal human contact is completely drained over the course of a day working in building with, with LLMs.

Brett Dolecheck 9:36 I mean, I, I wanted to get, get into an argument with one, it’s like,

Bryan 9:41 yeah,

Brett Dolecheck 9:41 okay, this is a computer, I don’t need to argue,

Bryan 9:45 there’s no reason for me swearing at the software right now, but yeah, I’m swearing, yeah, in there,

Brett Dolecheck 9:52 and the other thing is, is that some of a lot of these developers are, they’re putting, I guess you would say, too much trust. They’re like, okay, yeah, it should get it right. Well, technically, yes, it should, yeah, but it doesn’t always. Yeah, I mean, we found a bug just the other day where they engineered, I don’t know which model he used, but it, it refactored some code and pulled out an if null statement, yeah, and pulled out the test, yeah, that went with it too, yeah. So, so basically the engineer that did the PR said, “Oh, all the tests fell, it’s doing what it needed to do now. Okay, and next thing we, we got it, next thing you know, we got a bug because it didn’t check for null now,

Bryan 10:40 yeah,

Brett Dolecheck 10:40 because the AI ripped it out.

Bryan 10:43 Yeah,

Brett Dolecheck 10:43 and it’s like we can’t just wholesale say, yep, if AI did it, it works. Hell,

Bryan 10:51 how did you approach that postmortem? Were you able to kind of go back into the prompt history at that moment in time when it made that change?

Brett Dolecheck 11:00 No. Well, no, we were too busy scrambled you to try to get the plug. No, we didn’t, because basically it was a, it was a like a 400 buying function. Yeah, and and we were like, okay, let’s refactor that and break it up into parts, so when it broke it up, it, it just, I don’t know why it decided it didn’t need to check for null now. Yeah, and it still really did,

Bryan 11:30 right?

Brett Dolecheck 11:30 And everything else was fine,

Bryan 11:33 yeah,

Brett Dolecheck 11:34 but, but yeah, we, that’s another issue that, that I’m happy,

Bryan 11:40 yeah. There’s an interesting feature that we’re working on, which is the ability to essentially boot up a cadaver of an agent, right? And when you, if you can structure the history of the code that was contributed and the agent’s history and like the humans kind of prompting of that agent, you can actually kind of pretty closely reconstruct the exact kind of like go back in time to when that engineer was working with that agent, and you can kind of, I don’t know, if you remember the movie Minority Report, sort of be like, agent, you are about to commit a grievous error, can you explain to me why you might do this, and interestingly, I think that will help unlock a lot of, like, understanding of, you know, what, like, you can say what kind of controls we put in place, so you don’t make this mistake, and you can always do that after the fact with a fresh agent session, looking at the version history, but there’s something kind of like, you have that moment in time where everything is just sort of like in the right state to properly, properly post mortem and properly put in place guardrails for the future.

Brett Dolecheck 12:45 Well, see, and one of the things, like I mean, artificial intelligence is supposed to learn,

Bryan 12:52 yeah.

Brett Dolecheck 12:52 And so we point, I mean,

Bryan 12:54 for them, not for you,

Brett Dolecheck 12:56 exactly. And, and, and so, when we, when we put the code back in, and said, and basically it was like the snow was removed, and basically the LLM said, “Oh, I’m sorry, okay? Did you learn anything from that? Or it’s like, yeah, I’m sorry, on to the next.

Bryan 13:18 How do we know it’s not gonna make that mistake again, we don’t

Bryan 13:22 know it almost definitely would, given the same opportunity, because something in this optimization, yeah, yeah,

Brett Dolecheck 13:28 exactly. And so it’s like, I, it’s good, and it’s got its issues,

Bryan 13:37 yeah, yeah, that’s the current, that’s the current state of the times with all this,

Brett Dolecheck 13:42 so how can you help me?

Bryan 13:44 So I mean, I have a very.. I’ve been a founder for 10 years now, worked with a lot of Fortune 500 I have a very solutions-oriented mind. I love jumping into, like, fixing problems as soon as I hear them. I’ve also learned to try to ask more questions and do some proper discovery before diving into the deep end of solutions, I kind of hinted at one of the solutions that we have, which is this ability to potentially boot back up an agent at the moment in time, and this is useful both for like the work that you’re doing yourself or if somebody is reviewing your code and wants to better understand how you arrive at certain conclusions or how decisions were made, they can actually speak with the agent or annotate that session and then ask you to kind of go back, and there’s some interesting things you can do once you properly capture and structure the history of the work, essentially, like, you know, the code, or it could be knowledge work, right? Could be creating documents or other things like that. If you capture that history appropriately, you can do a lot of very powerful things that aren’t really achievable currently. That’s the general shape of what we’re building, and yeah, if it’s okay with you, like, I’d love to kind of go through. I can give you the three questions that I primed my other upcoming calls with, just to kind of.. I think we kind of half covered them, perhaps. But also, it’d be great, I sort of dove into what I’m doing. I’m curious to learn a bit more about you, your background, the company that you’re at, you know, the size of engineering org, and you mentioned using GitHub Copilot, and people kind of also audibleing and doing their own thing, which is totally typical these days. So, yeah, love to learn a bit more about that, the general landscape of what you’re working with.

Brett Dolecheck 15:19 So, yeah, so I mean I’m the senior director of engineering at Xylem, the division I’m in. We build gas, water, and electric meters. So I got firmware engineers, I got software engineers writing all kinds of code all over the globe. My got a team, I got 120 something engineers for the whole company. I think we probably have seven 800 engineers. The rest of the company builds water pumps, all kinds of stuff. So, what else do you want to

Bryan 15:58 know? No, that’s good general context. Yeah, and as a side note, I worked at Schneider Electric as my last job before going to business school, and I was working on the, like, the solar inverter division. But yeah, it’s it’s interesting to see all these existing industries that are very critical to things we take for granted every day, and it’s also very easy when you’re in the tech world, to kind of like be in the bubble of like writing software that does software to do software, and like what is the actual end goal of all this, and it’s very clear that the end goal of the stuff you’re working on, which is nice. I think at the same time working on stuff in like writing firmware, for example, there’s not as much out there in the open source world on that front, so LMS really, really struggle with things like that, just like they struggle with Cobalt, and even Java, to some degree. Like, despite being on for a long time, a lot of like legacy Java code is like kind of was very like closed source and all that. So, has that been a challenge for you? And are your engineers even using Copilot or Fog for the firmware writing, or just the control plane?

Brett Dolecheck 16:59 They use it some, I mean, there’s the because it’s all in C, yeah, they, the models don’t do as well as if it was like Java or Rust or something like that, yeah, software engineers, yeah, we’re doing, we’re actually converting a lot of our code from Java to Rust, and they’ll just take a whole function, feed it into a model, and say spit out Rust that does the same thing. Yeah,

Bryan 17:29 yeah, it’s

Bryan 17:30 great. As somebody who wrote Rust for a long time, at like, I never really kind of got past the intermediate level as a Rust engineer. LMS are really great at writing Rusk. It’s a lot easier. Do you code much yourself these days, or primarily just managing people?

Brett Dolecheck 17:48 Yeah, I don’t get to do a whole lot. I mean, and one of the things that I’ve seen with the engineers is that they’re able to, they’re able to spend more time doing spec documents,

Bryan 18:02 yeah,

Brett Dolecheck 18:03 and it’s interesting to see how the spec doc have the way they’re written is changing, where it used to be okay, we needed to do this and this and this, now it’s almost like the spec document is being written as prompts, so that you could just feed a spec to an LLM and say go generate,

Bryan 18:24 yeah,

Brett Dolecheck 18:25 which, yeah, that might work,

Brett Dolecheck 18:29 yeah, we’ll see,

Bryan 18:30 yeah. I mean, it’s great if you have like a greenfield new thing that you’re testing out, right, some new dashboard that you want to deploy for customers or something, or if you want to kind of test an idea quickly, naturally, like, if you let an LLM write code for, you know, overnight and come back with something, it’ll look amazing at first glance, and then actually breaking down what it did, and like, did it miss that, you know, that like, if no, you know, test, right, like it, yeah, it’s kind of like accordion problem of like, like you’re expanding the amount of stuff being created, and like then you have to kind of get another LLM to actually interpret all that work and kind of compress it back down to like the human context window, which is really, really big challenge. So, the okay, so the three questions that I primed up on the profile on Sage Tap, I think we covered the first one, but just for posterity’s sake. How does your engineering team currently use AI coding agents, Cloud Code, Copilot, Cursor, Codex? How widely adopted are they across the team, and how has that changed in the last six months? I think we covered that, but I’m curious about, like, what was the timeline for your adoption of AI agents.

Brett Dolecheck 19:46 We started probably in mid last summer,

Bryan 19:51 yeah,

Brett Dolecheck 19:52 and everybody was, because we use GitHub, it was kind of a natural, as you just start with Copilot for GitHub,

Bryan 20:00 yeah,

Brett Dolecheck 20:01 but then as things, as, as engineers got more used to it, they’re like, oh, but there’s this one, and then there’s that one, yeah, so, so, yeah, it’s, it’s definitely increased, I mean, some of the, I would say more like me, old engineers are like, I don’t know, so much about, I don’t care about this, but new college grads, hell, I think they would write everything in AI if they could.

Bryan 20:27 Yeah, that’s another like very hard, like long brewing problem now, which is people coming into the workforce without having kind of like the scar tissue of building software over time and never having the experience of maintaining software that was written years ago are in a weird place, like they are maybe ahead of the curve in terms of like learning how to work data with AI, but they’re just they’re missing some of the structural pieces that keeps it from, you know, going off the rails or spending three months on something, realizing, like, oh, this is fundamentally broken, the AI just kind of tell me the whole time that this is a good path, right, because that’s another challenge. I will say, like, and this is me extending on the soapbox a little bit, I think for most, in most cases, it’s a good thing to have engineers trying and even building critical code in different tooling, because the landscape is shifting so quickly, and you want to, to some degree, you want to be exposed to the latest models, and if you know when Codex five five came out, that was a pretty big step function change in the quality of code. Similarly, or conversely, Claude 47 when it came out, felt like a regression to a lot of people, unless you have some engineers that are kind of trying different things, so you might miss out, or like, you know, miss out on new things that are substantial improvements in terms of like the quality of the output or the quality of the documentation and the understanding and the reasoning of the system, and also there is a significant upfront cost, both from like a human cognitive load standpoint, but also poking holes in your assumptions of like how reliable your software development lifecycle is, and when you try to switch from Copilot to Cloud Code to Codex, and try to have all these things working coherently towards a shared end goal, it forces you to kind of create, for example, like documenting skills, or just documenting general workflows, or creating, you know, new better testing that kind of keeps them on the rails. I think it’s sort of, it’s a forcing function for some good general, like engineering practices, that that is kind of a pattern I’ve seen with, with a lot of good engineers lately.

Brett Dolecheck 22:39 Yeah, and that’s, I think we need to put some more, I don’t know, guard rails around it, but just so that we, as we learn things that we’re actually, we’re actually learning from them and not just saying reacting to them,

Bryan 22:55 yep, yep,

Bryan 22:56 and there’s no, there’s no like reliability or no real true determinism in any of this, you’re sort of accepting it’s like the nature of the beast with a stochastic system is that like everything can feel reliable and we haven’t had any bugs in a month and then suddenly like a new model comes out or just something changes and all of a sudden you know it’s just it’s sort of like a ripple, ripple effect into everything that everyone’s doing, but let’s see. The second question that I’ve been asking is, what visibility do you have today into how your team is actually using AI agents, and if your leadership asked, what’s the return on investment on our AI tooling spend? How would you address, like, what evidence could you point to right now for the value of what people are doing with AI?

Brett Dolecheck 23:54 I can definitely see that, well, we’re getting more done, and if I had to quantify it, I mean, I don’t have any, I can’t point to a specific number, but I can just say we’re probably maybe 10 12% ahead of schedule on things.

Bryan 24:15 Yeah,

Brett Dolecheck 24:16 so I’d say that’s pretty good indication.

Bryan 24:20 Yeah,

Brett Dolecheck 24:20 now if you equate that to I’ve got one engineer, he’s blown his clod coat

Bryan 24:29 subscription, right?

Brett Dolecheck 24:31 He blew it the first week, put in an ROI on it, it’s still cheaper than an engineer. Yeah, I can’t quantify that. I haven’t had any executive ask me about it yet. They probably will when they start seeing the bills roll in. Exactly, that’s usually when they, they start asking questions, is when they, when somebody’s budget goes over, right now I’m still doing fine on my budget, yeah, but yeah, I mean that answer your question,

Bryan 25:14 yeah, I’m curious, so like who makes decisions, for example, like, okay, we’re using Copilot as our standard AI agent tool set. If you were to pull in, you know, I could ask you more questions if we had more time about your general observability stack, and like, if using Datadog, or you know, whatever it may be, where to, like, think, like, when and how do those decisions usually get made? Are those, like, a CTO level decision, or is it sort of left to, you know, directors and VPs to make decisions? Like,

Brett Dolecheck 25:46 yeah, I mean, it’s, it’s pretty much, I mean, they’ll kind of come out with a over our overall arching, we need to go in this direction type thing,

Bryan 25:56 yeah,

Brett Dolecheck 25:57 but then each business unit is kind of up to their own to do with what they,

Bryan 26:01 that makes sense. Yeah, so the third question again, mostly covered it, but how has a shift to AI assisted development changed your team’s code review process, engineering quality practices, and how you coach and develop engineers? What’s working? What’s broken? I think I heard a bit of that from the conversation so far, but if anything else jumps out at you, that’s the third question.

Brett Dolecheck 26:29 No, I think we probably covered it. Yeah,

Bryan 26:32 so it’s always a hard thing in 30 minutes to kind of get to a sense of, like, is there a good fit here, and you know it’s it’s been helpful for me to just hear from you, and I haven’t done too much solutioning or pitching at a high level. I think what we’re working on can be really valuable to your team, and we are very focused on a software layer that does not require like radical changes on Yarn. In fact, the primary input to our system is just the agent session traces that are coming off of Copilot and Cloud Code, and everything else. So, we take those in, we structure them as graphs in our own internal representation, which is an open format, so you can build your own tooling on top of it, and then our sort of new flagship product that we’re launching this week is essentially kind of like a GitHub for agent session traces, but what we’re doing that’s different than anyone else out there is creating these graphs as like unified graphs with both the like the git commit history and the agent session history and the ability to kind of continue to build and add other contexts graphs over time and having to be a really rich substrate for things like understanding which engineers are working most effectively or give me the last 10 times that a tool call failed across the organization like what were the what was the last prompt before the last you know time that an agent simply stalled out, kind of like being able to sort of interrogate, and I mentioned the workflow before about booting up an agent at a point in time and diving in, and sort of like figuring out why this commit was made. So that’s a

Bryan 28:12 general shape.

Brett Dolecheck 28:13 So, is this an app you install on each computer, or is it, or is it something centralized and everything just runs through it,

Bryan 28:21 yeah. So, if you have, if engineers are working in cloud development environments, we could install the session, like you know, ingestion thing to those environments automatically, like you said. A lot of people are probably just working on their laptops or their workstations with cloud code, whatever it may be, and so we have a like a Mac OS, or, you know, like a native app for whatever OS, but Mac OS is the first one to build that is used to upload those traces to our, to our, like, you know, our GitHub, like, service called Pathbase, and then that can also just be an automated thing, so they could install an agent that is sort of just always kind of monitoring for agent activity and pushing that up to pathways.

Brett Dolecheck 29:05 Okay, and so you mentioned Verizon. So, what, what kind of things that Verizon, what, how has your product helped them? I guess

Bryan 29:17 I didn’t, or we haven’t done anything with Verizon, I’m not sure, trying to think what I might have mentioned that sound like Verizon

Brett Dolecheck 29:26 in the very beginning of our conversation. I thought you said Verizon, maybe you said was it Verizon or what?

Bryan 29:34 I’m honestly, I’m not sure. Yeah, we’re not working with Verizon. We did a pilot with another telco last summer, but it was something kind of unrelated to this.

Bryan 29:44 Okay,

Bryan 29:44 so yeah, we’re pretty early. We’re launching with some design partners now. It’s free to use for the time being, right? It’s sort of the GitHub like model where it’s free to use for like your own private sort of like repos essentially, and then as we kind of build out the team functionality, you know, looking at something like a 20 to $50 ahead, you know, GitHub type licensing structure, so if it’s interesting for you to maybe have another conversation, we’ll love to connect, can set up a 30 minute call just to, you know, to kind of take you to the system, give you a demo of what we’re working with, and kind of pick up the conversation from there, if you’re up for it.

Brett Dolecheck 30:23 Yeah, let me, let me, let me talk to a couple of my senior engineers, maybe we can get something together.

Bryan 30:29 Yeah, that’d be great. I’ll send you a quick, quick summary of this call, and just a couple more notes on Pathways specifically that you can share with them to kind of get their take on it. Would love to get their perspective as well.

Bryan 30:42 Cool. Sounds

Bryan 30:42 great. Well, lovely meeting you. Awesome. Kicking off the week with a phone call, and we’ll talk to you soon.

Brett Dolecheck 30:49 Absolutely.

Bryan 30:50 All right. Cheers. Bye, bye.