As a delivery lead, data-layer troubleshooting has historically been developer work: SQL fluency, comfort operating in a production database, and the confidence to investigate without breaking anything. For an accounting-based client, when their data didn’t reconcile or make sense, that question went to a developer.
AI changed that for me in one engagement this year. This post covers how I set up AI-assisted access to a client’s data layer, what it’s delivered for the project and the client, and what I think it signals for delivery roles broadly.
How I Set Up AI Access to the Data Layer
Here’s how we set it up:
Harness.
I used Cursor, working with the actual repo the way a developer would, but with AI layered on top. That mattered because the AI needed the codebase as context, not just the database in isolation. A discrepancy usually only makes sense once you can see the logic that produced it. Claude can serve the same function and may be a more approachable interface for someone without a development background.
Database Access.
I created a read-only connection to the project’s database. This was deliberate. It’s what made it safe to explore, ask questions, and let the AI help interpret the data without any risk of altering production.
Configuration.
I set up skills describing how the AI should interpret the database structure alongside the codebase. I also gave it that operational context about the client’s systems that it wouldn’t have had by default. It was the kind of institutional knowledge the product owner would likely provide. I gave it specific knowledge on how the client not only views but interprets the data and results.
Source Data.
The client had a large volume of source files in SharePoint. I connected the AI to those external files so it could pull in reference data and check it against system data for inconsistencies. That cross-referencing is exactly the kind of task that’s tedious and error-prone by hand. However, it’s straightforward once the AI has access to both sides of the comparison, and it’s where the setup delivered some of its clearest value to the client.
Domain Knowledge.
None of this works on its own. I have substantial knowledge of this client’s existing operations, which lets me judge whether an AI-surfaced answer actually makes sense. The tooling extended my reach into the technical layer, but there’s no substitute for knowing the client’s business. The AI can surface a pattern, but it can’t tell you whether that pattern is actually a problem for this client.
The result wasn’t just database access. It was database access paired with enough surrounding context that the answers were usually trustworthy on the first pass, not something I had to hand off for verification.
What AI-Assisted Troubleshooting Added
The clearest gain was speed. Reconciliation and troubleshooting that used to require a developer round-trip could happen in the time it took to ask the question. This also freed up developer capacity because I didn’t need to pull them into something that would cause a context switch.
It also changed the client relationship. Being able to answer a data question live, in a call, instead of following up later, changes how a client experiences the engagement. The impact on their operations was significant enough that the client asked us to help them get set up the same way, to enable faster reconciliation and investigation on their own end.
Where This Is Headed for Delivery Teams
This engagement changed how I see my own contribution to a team going forward. What’s shifting is the technical floor for participating in certain kinds of work. Tasks that used to route to engineering by default, because they required developer tooling and knowledge, can now be shared with non-technical teammates. That raises everyone’s contribution and understanding of the project.
I’d expect this to show up industry-wide less as “delivery leads learning to code” and more as an expansion of who’s expected to operate and interact with technical layers on a project. That could look like data querying, contributing to basic UI code updates, or something else entirely. For any organization built around data and apps (which, let’s be real, is nearly everyone) there’s a real argument for investing in this kind of setup deliberately for non-technical staff.